Google 以機器學習 (Machine Learning) 判斷應用程式使用頻率，要讓Wear OS穿戴裝置更省電
Google 以機器學習 (Machine Learning) 判斷應用程式使用頻率，要讓Wear OS穿戴裝置更省電
News from: iThome & Google Android Developers Blog
根據使用模式，應用程式會被放在5個優先順序桶中，排序應用程式執行的頻率、觸發警示的頻率以及接收高優先度Firebase Cloud Messaging（FCM）訊息的頻率。
Google釋出了最終版本的Wear OS API 28模擬器映像檔，Wear OS開發者可以用來開發支援Wear OS API 28版（也就是Android 9相對應的版本）的穿戴裝置App了。28版增加了三大新功能，包含新的通知串流、應用程式等待桶（App Standby Buckets）以及強化使用者資料隱私。
Wear OS API 28帶來更緊湊的通知顯示功能，現在可以在同一個螢幕畫面顯示多則通知，讓使用者能以有效率的方式處理通知串流。對於開發者來說，現在未展開的通知最多只能顯示3行文字，Google要求開發者使用更簡明的通知內容，並提到於Wear上3行可以顯示的資訊，已經比起手機上單行未展開的通知還要多了。
而且現在Wear OS API 28也不再支援自定義的通知布局，過去開發人員會使用setDisplayIntent來擴展通知串流中的自定義活動，但Google提到，開發者自定義布局通常不會考慮裝置的外型，很難隨著Wear OS的通知體驗發展而保持最新狀態，因此現在不再於通知中支援這個功能。Google也提醒開發者，應該要注意使用符合應用程式形象的顏色標記通知，並以簡潔的通知內容適應新的布局。
第二個新功能應用程式等待桶，這是Google在Android 9中新加入的電池管理功能，會根據應用程式近期使用狀況以及頻率，幫助系統選擇應用程式資源請求的優先順序。根據使用模式，應用程式會被放在5個優先順序桶中，系統根據應用所在的儲存桶，限制每個應用程式可以用的裝置資源。
5個優先順序分別為活躍（Active）、工作組（Working set）、頻繁（Frequent）、稀有（Rare）以及從未（Never）。系統會動態的將每個應用程式分配給各優先順序應用程式等待桶，而且根據需要重新分配應用程式。系統會使用機器學習決定每個應用程式被使用的方式，判斷預先載入的應用程式，假設裝置當前沒有系統應用程式執行，則系統會預設根據應用程式的使用時間，對應用程式進行排序。特別的是，儲存桶會決定應用程式執行的頻率、觸發警示的頻率以及接收高優先度Firebase Cloud Messaging（FCM）訊息的頻率。而這些限制只有在裝置使用電池供電時才有效。
Wear OS API 28的第三個新功能，便是強化使用者隱私，限制後臺應用程式存取裝置感測器，因此現在開發人員可能需要根據應用程式的需求，透過使用前臺服務以持續存取感測器資料。
Google特別提醒，新的通知串流政策將往前擴及Wear OS API 25以及更高版本的裝置。開發者可以利用API 28模擬器映像檔，現在就能知道新的通知行為。
-------------------------------------------------------------------------------
News from: iThome & Google Android Developers Blog
根據使用模式，應用程式會被放在5個優先順序桶中，排序應用程式執行的頻率、觸發警示的頻率以及接收高優先度Firebase Cloud Messaging（FCM）訊息的頻率。
Google釋出了最終版本的Wear OS API 28模擬器映像檔，Wear OS開發者可以用來開發支援Wear OS API 28版（也就是Android 9相對應的版本）的穿戴裝置App了。28版增加了三大新功能，包含新的通知串流、應用程式等待桶（App Standby Buckets）以及強化使用者資料隱私。
Wear OS API 28帶來更緊湊的通知顯示功能，現在可以在同一個螢幕畫面顯示多則通知，讓使用者能以有效率的方式處理通知串流。對於開發者來說，現在未展開的通知最多只能顯示3行文字，Google要求開發者使用更簡明的通知內容，並提到於Wear上3行可以顯示的資訊，已經比起手機上單行未展開的通知還要多了。
而且現在Wear OS API 28也不再支援自定義的通知布局，過去開發人員會使用setDisplayIntent來擴展通知串流中的自定義活動，但Google提到，開發者自定義布局通常不會考慮裝置的外型，很難隨著Wear OS的通知體驗發展而保持最新狀態，因此現在不再於通知中支援這個功能。Google也提醒開發者，應該要注意使用符合應用程式形象的顏色標記通知，並以簡潔的通知內容適應新的布局。
第二個新功能應用程式等待桶，這是Google在Android 9中新加入的電池管理功能，會根據應用程式近期使用狀況以及頻率，幫助系統選擇應用程式資源請求的優先順序。根據使用模式，應用程式會被放在5個優先順序桶中，系統根據應用所在的儲存桶，限制每個應用程式可以用的裝置資源。
5個優先順序分別為活躍（Active）、工作組（Working set）、頻繁（Frequent）、稀有（Rare）以及從未（Never）。系統會動態的將每個應用程式分配給各優先順序應用程式等待桶，而且根據需要重新分配應用程式。系統會使用機器學習決定每個應用程式被使用的方式，判斷預先載入的應用程式，假設裝置當前沒有系統應用程式執行，則系統會預設根據應用程式的使用時間，對應用程式進行排序。特別的是，儲存桶會決定應用程式執行的頻率、觸發警示的頻率以及接收高優先度Firebase Cloud Messaging（FCM）訊息的頻率。而這些限制只有在裝置使用電池供電時才有效。
Wear OS API 28的第三個新功能，便是強化使用者隱私，限制後臺應用程式存取裝置感測器，因此現在開發人員可能需要根據應用程式的需求，透過使用前臺服務以持續存取感測器資料。
Google特別提醒，新的通知串流政策將往前擴及Wear OS API 25以及更高版本的裝置。開發者可以利用API 28模擬器映像檔，現在就能知道新的通知行為。
-------------------------------------------------------------------------------
Wear OS by Google: final API 28 emulator with new redesigned UI
20 November 2018
Posted by Hoi Lam, Lead Developer Advocate
Today, we are launching the final API 28 emulator image for developers. This image will also contain the UI redesign we announced in August. You should verify that your app's notification works well with the new notification stream, and that your apps work well against changes previously announced for API 28.
What's new in API 28?
Here are the highlights of the API 28 emulator:
- New notification stream - You should make sure that your notifications are branded correctly, using color, and that the notification is sufficiently concise to fit into the new layout. Custom notification layout is no longer supported.
- App Standby Buckets - Wear OS prioritizes app requests for resources based on how recent and how frequently the apps have been used. Developers are advised to follow best practices to ensure that their app behaves well, whichever bucket the apps are in.
- User input and data privacy - To enhance user privacy, API 28 introduced new changes which limit background apps' access to device sensors. Depending on app requirements, developers may need to use a foreground service to enable continual access to sensor data.
Please note that changes related to the new notification stream are being rolled out to devices supporting API 25 and up. You can test how your notification will behave now, before roll-out is complete, by using the API 28 emulator image.
Keep your feedback coming
Just because we are now in release build does not mean that our work stops here. Please continue to submit all bug / enhancement requests via the Wear OS by Google issue tracker.
Finally, we are grateful for all of your valuable feedback during the developer preview. It played an important role in our decision making process - especially concerning App Standby Buckets. Thank you!
留言
張貼留言