Android P正式版即將到來：後臺應用保活、消息推送的真正噩夢
一、前言
對於廣大Android開發者來講，Android O（即Android 8.0）還沒玩熱，Andriod P（即Andriod 9.0）又要來了。php
下圖上谷歌官方公佈的Android P發佈路線圖：html
Android P的最後一個開發者預覽版（即DP5）已如期發佈於2018年7月26日，根據上面這張發佈路線圖，相信Android P的正式版將很快到來。對於Andriod開發者來講，無論Andriod P有多少新功能或者特性（反正「我」用iPhone啊，哈哈），是否影響「我」擼的APP的運行纔是最要緊的事。android
自從Andriod 6.0以來，Android系統在省電管理這方面作的愈來愈好，對於開發者來講限制也愈來愈多，也直接致使了各類保活黑科技羣魔亂舞（別笑，就的就是「你」！）。但Android P官方公開的開發者資料來看，此版加入或強化的多項設備電量管理新特性，使得須要後臺消息推送、應用保活的APP變的愈來愈困難，黑科技恐將成爲歷史。web
學習交流：算法
- 即時通信開發交流3羣：185926912[推薦]安全
- 移動端IM開發入門文章：《新手入門一篇就夠：從零開發移動端IM》微信
（同步發佈於：http://www.52im.net/thread-1832-1-1.html）網絡
二、原先的APP爲何要搞各類保活黑科技？
其實搞保活的目的倒不是爲了幹什麼見不得人的壞事（但不排除動機不純的開發者），主要是像IM即時通信應用和資訊類應用等須要搞後臺消息推送、運動類應用須要在後臺實時監測用戶的運動數據等，由於如今愈來愈多的手機廠商爲了省電策略考慮，基本上若是你的應用沒有被加入白名單，一旦處於後臺就會被系統限制甚至幹掉，但使用APP的用戶纔不聽你這些解釋——反正「我」就要你的APP能如期正常運行，開發者也是不得已而爲之。架構
以消息推送爲例，當APP處於後臺或關閉時，消息推送對於某些應用來講很是有用，好比：併發
1）IM即時通信聊天應用：聊天消息通知、音視頻聊天呼叫等，典型表明有：微信、QQ、易信、米聊、釘釘、Whatsup、Line；
2）新聞資訊應用：最新資訊通知等，典型代碼有：網易新聞客戶端、騰訊新聞客戶端；
3）SNS社交應用：轉發/關注/贊等通知，典型表明有：微博、知乎；
4）郵箱客戶端：新郵件通知等，典型表明有：QQ郵箱客戶端、Foxmail客戶端、網易郵箱大師；
5）金融支付應用：收款通知、轉帳通知等，典型表明有：支付寶、各大銀行的手機銀行等；
.... ....
在上述的各類應用中，尤爲對於用戶接觸最多、最日常的IM聊天應用或新聞資訊來講，保活和消息推送簡直事關APP的「生死」，消息推送這種能力已經被愈來愈多的APP做爲基礎能力之一，由於移動互聯網時代下，用戶的「全時在線」能力很是誘人和強大，能隨時隨地即時地將各類重要信息推送給用戶，無疑是很是有意義的。
題外話：實際上，對於後臺消息推送能力，Android原版系統早就內置了系統級推送服務（跟iOS上的APNs服務是一個東西），它就是GCM服務（如今升級爲FCM了），但衆所周之的緣由，谷哥的服務在國內都是用不了的（你懂的）——無奈啊！
（有關GCM的介紹詳見：《移動端IM實踐：谷歌消息推送服務(GCM)研究（來自微信）》、《爲什麼微信、QQ這樣的IM工具不使用GCM服務推送消息？》、《求教android消息推送：GCM、XMPP、MQTT三種方案的優劣》）。
三、針對以往Android版本的各類保活技術回顧
搞Android端IM和消息推送服務的開發者都知道，Android P以前爲了搞定客戶的投訴：「爲何微信能收到消息而大家的IM卻不能?」，爲了解決這個「痛點」，廣大的Android開發者們只能讓各類黑科技輪番上場、各顯神通，最典型的：好比曾今在手機QQ上的1像素保活（雖然QQ官方從沒正面認可過）、後臺無限播放無聲音的音頻、應用互相拉活等，你們都耳熟能詳。
下面就是即時通信網整理過的各類典型保活需求和思路，能夠回顧學習一下：
《應用保活終極總結(一)：Android6.0如下的雙進程守護保活實踐》
《應用保活終極總結(二)：Android6.0及以上的保活實踐(進程防殺篇)》
《應用保活終極總結(三)：Android6.0及以上的保活實踐(被殺復活篇)》
《Android端消息推送總結：實現原理、心跳保活、遇到的問題等》
《微信團隊原創分享：Android版微信後臺保活實戰分享(進程保活篇)》
四、國內各類Android廠商級推送通道出現了
爲了響應Android原版中對省電策略、用戶體驗等設計，也爲了不各類保活亂象，國內主流的Android手機廠商在閹割了谷歌原版的GCM(FCM)推送通道以後（悲劇！），依靠自身的技術力量構建起來各家自有的推送通道。
下面是國內主流Android廠商的推送服務開發者入口：
1）小米消息推送服務；
2）華爲消息推送服務端（Huawei Mobile Services）；
3）魅族消息推送服務；
4）OPPO消息推送服務；
5）vivo消息推送服務（建設中..）。
看到上面這串廠商系統級推送通道列表，相信你已經露出了你那排潔白的牙齒了 ^_^。。。
若是劇情都能像都市愛情小說那樣——「男女主角今後過上了幸福美滿的生活...」，那就完美了！
可是（這個可是真的很討厭），不要高興的太早，理想狀況下對接廠商通道確實很爽，但現實很骨感。
對接廠商通道帶來的麻煩，遠比你想像的要多：
1）你得一家一家下載SDK、註冊開發者帳號、搞手機端對接、搞服務端對接；
2）各廠商的SDK都打包在一個APP裏，可能存在各類兼容性問題；
3）由於ROOM版本問題，即便同一個廠商的手機的同一套SDK也存在新舊ROOM的兼容性問題；
4）這一堆的SDK，各類jar包讓你的APP莫名變大了很多；
5）服務端要對接各類廠商的推送後臺，各家的技術水平、SDK水準、服務穩定性良莠不齊，對接起來難受吧；
6）有些手機小廠並無自已的推送通道，你自建的推送能道還不能扔。
凡此種種，對接廠商通道並不輕鬆。
不過：若是公司不排斥使用第3方通送方案的話，現階段這種混亂情況下，能夠考慮直接用第3方的服務，比騰訊的信鴿推送爲例（首先申明，我沒收信鴿的好處費，只是舉個例子！），信鴿推送的方案也是一家一家對接第3方的廠商通道道+自有通道（《[資訊] 信鴿新版上線：號稱Android首家統一推送服務》），對於開發者來講信鴿的實現思路其實跟咱們想的是同樣的。但好處是：別人有專門的團隊死磕這件破事，比你自已一我的帶來的效果要好多了。
五、萬衆矚目的「統一推送聯盟」上場了
爲了解決這些亂象，好消息是去年有政府背景的「統一推送聯盟」成立了（詳見《[資訊] 統一推送聯盟在京成立：結束國內安卓生態混亂》），廣大Android開發者真是翹首以盼。
但壞消息是好像進展並不順利（你們心知肚明啊，各廠商的利益很差均衡嘛），最近一次跟消息推送服務有關的活動仍是3個月前的《[資訊] 統一推送聯盟2018成員大會如期召開》。雖然進展不大，但總算仍是有但願，Android同行們再等等，總有Android端消息推送一統江湖的方案出現的那天。
六、Andriod P要來了，噩夢仍將繼續！
Android P中針對省是管理方面的改進，只會使得搞後臺保活、消息推送愈來愈麻煩，做爲Android開發者來講，瞭解這些新特性至少能讓自已內心有底，從而在技術上作到有的放矢。
Android P中電量管理特性主要體如今如下四個方面：
1）應用待機分組：Android P 新增應用待機分組功能，讓系統根據用戶的使用狀況而限制應用調用 CPU 或網絡等設備資源；
2）應用後臺限制：Android P新增後臺限制功能，若應用出現 Android Vitals 內所描述的不良行爲，系統將提醒用戶限制該應用訪問設備資源；
3）省電模式優化：Android P 優化了現有的省電助手功能，在啓用該功能後，系統將對全部應用的後臺運行實施加以限制；
4）低耗電模式：當用戶一段時間沒有使用設備時，設備將進入低耗電模式，全部應用都將受到影響。 Android P 並未針對低電耗模式做出任何更改。
*注意：不論應用程序的 target SDK 是否爲 Android P ，全部應用都受限於以上行爲變動。
接下來將逐一介紹這幾個特性。
七、Andriod P電量管理特性1：應用待機分組
應用待機分組是 Android P 新添加的一項電量管理功能，它能根據應用的使用頻率或者最近一次使用時間，對其資源請求進行優先級排序。應用待機分組一共有五個分組，系統會根據每一個應用的使用狀況，將其劃分至五個優先分組中的一個，而每一個分組對設備資源的調度各有不一樣的限制。
7.1 優先分組
系統將動態分配各個應用至不一樣分組，並根據需求從新分配所在分組。系統或會經過利用機器學習預加載的應用，從而預測各個應用的使用機率，而後將它們編配至相應的羣組中。若設備中沒有安裝此類系統應用，在默認狀況下，系統會根據應用的近期使用狀況進行等級劃分。應用活躍度越高，所處分組的優先級就越高，也就相應地更容易獲取設備資源。尤爲是，應用所處的的羣組決定了其所安排的任務 (job)，觸發標準鬧鈴以及接受高優先級Firebase Cloud Messagesing信息的頻率。這些限制僅在非充電狀態下才有效；當設備充電時，應用並不會受到系統限制。
*注意：設備廠商能夠自行規定非活躍應用的羣組劃分規則。請開發者不要試圖篡改應用所處的羣組，而是專一於改善應用行爲，確保應用被劃分至目標羣組後，依舊可以順利運行。您能夠調用 UsageStatsManager.getAppStandbyBucket()，查看應用當下所處羣組。
應用待機模式下共有如下五類羣組：
1）活躍 (Active): 應用正在被使用；
2）工做 (Working set): 應用使用頻率很高；
3）經常使用 (Frequent): 應用常常但不是天天被使用；
4）極少 (Rare): 應用偶爾被使用；
5）應用偶爾被使用 (App is not frequently used)。
此外，安裝後一次都未被使用過的應用將被劃分至 「從不」 這一特殊羣組，並受到十分嚴格的系統限制。
*注意：應用待機羣組限制不適用於低耗電模式白名單中的應用。
7.2 活躍 (Active)
活躍應用指用戶正在使用的應用，例如：
1）應用啓動了一個Activity；
2）應用正在運行前臺服務；
3）另外一個前臺應用已關聯至該應用 (經過同步適配器與前臺應用的內容提供器相關聯)；
4）用戶點擊了應用的推送。
在任務、標準鬧鈴以及FCM信息的資源調用上，活躍羣組應用免受任何系統限制。
7.3 工做 (Working set)
若應用的運行頻率很高，但目前並未處於「活躍」狀態，它就會被劃分至工做羣組，例如用戶經常使用的社交媒體應用。此外，該羣組還包括了那些被間接使用的應用。
工做分組內的應用會在任務 (job) 運行和鬧鈴觸發方面受到部分系統限制，詳情請查閱《附件: 電量管理限制》。
7.4 經常使用 (Frequent)
經常使用應用指用戶常用但不是天天使用的應用，好比用戶在健身房使用的打卡應用可能就屬於這一羣組。
系統對經常使用分組採用的限制更強，應用運行任務(job)和觸發鬧鈴的能力都會受到影響，並且接受的高優先性FCM消息也有數量上限，詳情請查閱《附件：電量管理限制》。
7.5 極少 (Rare)
若應用的使用頻率很低，它就會被劃分至該分組，酒店應用就是一個很好的例子——用戶只有在下榻這個酒店的時候纔會打開此應用。
該羣組下的應用在任務 (job)、鬧鈴和高優先性FCM消息的資源調用上都會受到嚴格的限制。此外，網絡訪問能力也會受到影響。詳情請閱讀《附件：電量管理限制》。
7.6 最佳實踐建議
若是您已經根據低耗電模式和應用待機模式的最佳實踐對您的應用進行過相關優化，您應該可以輕鬆應對新的電量管理特性。不過，部分應用行爲可能會受到這次特性變動的影響，沒法繼續正常運做。
1）請勿嘗試操控系統將您的應用分配至某一特定羣組。系統的分組規則可能會發生變化，並且設備廠商也能夠根據本身的算法自行開發分組應用。開發者須要確保本身的應用在任何羣組內都可以繼續流暢運行。
2）若是應用沒有 Launcher Activity，它可能永遠都不會切換至活躍分組。開發者可能須要從新設計應用並添加此類activity。
3）若是應用的推送不具有可操做性，用戶將沒法藉助與推送的交互將應用切換至活躍羣組。在這種狀況下，開發者可考慮從新設計推送功能，容許用戶響應。具體操做指南，請參照 Material Design 中有關推送設計的章節。
4）若應用在接受高優先級的 FCM 消息以後未能發送推送，用戶將沒法與應用產生互動並將其優先級提高至 「活躍」 等級。其實，高優先級 FCM 消息的惟一用途就是向用戶發送推送，所以這種狀況絕對不該該出現。若是您錯誤的將沒有與用戶進行互動的 FCM 消息設置爲高優先級，這種標記不當的行爲可能會致使其餘不良後果，好比：在應用耗盡高優先級消息額度以後，系統會把真正緊急的 FCM 消息當作「普通優先級」消息來處理。
*注意：若是用戶屢次忽略某條推送，系統會詢問用戶是否再也不接受此推送。請開發者不要只是爲了將應用保留在活躍羣組，而向用戶不斷髮送推送。若是一個應用下面有多個包，這些包可能分別屬於不一樣分組，各自的訪問權限也有所不一樣。在測試環節時，請開發者先將包劃分至不一樣分組，而後進行屢次測試，確保應用行爲無異常。
八、Andriod P電量管理特性2：後臺限制
當系統監測到應用消耗過多資源時，系統會通知並詢問用戶是否須要限制該應用的後臺活動。
目前有如下兩種狀況會觸發系統發送此通知：
1）頻繁使用喚醒鎖 (wake locks)：屏幕關閉後，局部喚醒鎖 (Partial wake lock) 連續開啓 1 小時；
2）過多的後臺服務：當應用目標 API 等級低於 26，且運行過多後臺服務。
設備廠商可自行決定具體採用的限制，好比：在 AOSP 構建上，除非受限應用運行在前臺，不然它將沒法運行任務 (job)，觸發鬧鈴或者訪問網絡。(請查閱《後臺服務限制》瞭解如何判斷應用是否爲前臺運行。) 詳細限制列表，請查閱《附件：電量管理限制》。
九、Andriod P電量管理特性3：省電助手優化
Android P 進一步提高了省電模式的性能，由設備廠商來決定其採用的具體限制。
好比：在AOSP構建上存在如下系統限制：
1）應用將更容易進入待機模式，系統不會一直等到應用處於「空閒」狀態才採起行行動；
2）不論目標API等級爲什麼，全部應用都會受到後臺執行限制；
3）屏幕關閉後，位置服務可能被禁用；
4）處於後臺的應用不能訪問網絡。
除此之外，Android P 還引入了多項針對設備的電量管理的優化，請閱讀《附件：電量管理限制》獲取進一步信息。
建議開發者在開啓省電模式的狀況下測試應用，您可在 Settings > Battery Saver 內手動開啓省電模式：
十、Andriod P電量管理特性4：低耗電模式
在低耗電模式下，應用對高耗電資源的使用權限將被推遲至下一個維護時段。具體限制請參照《附件：電量管理限制》。
進一步信息，請查閱《對低耗電模式和應用待機模式進行鍼對性優化》。
十一、本文小結
對於開發者來講，Android平臺向來以「亂」著稱，後臺保活和消息推送從各類黑科技，到廠商紛紛自建通道，再到統一推送聯盟。時至今日，該面對的問題依然沒有改觀，隨着Android P正式版的發佈，對於IM、消息推送服務等開發者來講，我的英雄主義式的技術黑科技愈來愈沒有發揮的空間，從長遠來說這是好事。
隨着時間的推動，分久必合的局面終將出現，Android平臺也必將愈來愈規範，Android P這樣版本只是這前進過程當中的陣痛，但願廣大Android開發者在Android技術進步的福利下能愈來愈輕鬆，不再用「開大招」琢磨各類非主流黑科技了。
附錄：更多相關技術文章
《iOS的推送服務APNs詳解：設計思路、技術原理及缺陷等》
《信鴿團隊原創：一塊兒走過 iOS10 上消息推送(APNS)的坑》
《Android端消息推送總結：實現原理、心跳保活、遇到的問題等》
《一個基於MQTT通訊協議的完整Android推送Demo》
《求教android消息推送：GCM、XMPP、MQTT三種方案的優劣》
《掃盲貼：淺談iOS和Android後臺實時消息推送的原理和區別》
《移動端IM實踐：谷歌消息推送服務(GCM)研究（來自微信）》
《爲什麼微信、QQ這樣的IM工具不使用GCM服務推送消息？》
《從HTTP到MQTT：一個基於位置服務的APP數據通訊實踐概述》
《基於WebSocket實現Hybrid移動應用的消息推送實踐(含代碼示例)》
《Go語言構建千萬級在線的高併發消息推送系統實踐(來自360公司)》
《瞭解iOS消息推送一文就夠：史上最全iOS Push技術詳解》
《基於APNs最新HTTP/2接口實現iOS的高性能消息推送(服務端篇)》
>> 更多同類文章 ……
- 1. Android 後臺應用保活、消息推送
- 2. 最終預覽版 Beta 4 現已發佈，Android P 正式版即將到來！
- 3. Android 11 最終 Beta 版發佈，正式版即將到來！
- 4. Google Jib 即將迎來正式版
- 5. 終於等到你！Android 11 最終 Beta 版發佈，正式版即將到來！
- 6. Android APP切換到後臺接收不到推送消息
- 7. 用websocket實現後臺推送消息
- 8. App消息推送的到達率多少纔是正常的？
- 9. android消息推送
- 10. android 推送消息
- 更多相關文章...
- • Scala 正則表達式 - Scala教程
- • PHP 正則表達式(PCRE) - PHP參考手冊
- • TiDB 在摩拜單車在線數據業務的應用和實踐
- • 常用的分佈式事務解決方案
-
每一个你不满意的现在，都有一个你没有努力的曾经。
- 1. 融合阿里雲，牛客助您找到心儀好工作
- 2. 解決jdbc(jdbctemplate)在測試類時不報錯在TomCatb部署後報錯
- 3. 解決PyCharm GoLand IntelliJ 等 JetBrains 系列 IDE無法輸入中文
- 4. vue+ant design中關於圖片請求不顯示的問題。
- 5. insufficient memory && Native memory allocation (malloc) failed
- 6. 解決IDEA用Maven創建的Web工程不能創建Java Class文件的問題
- 7. [已解決] Error: Cannot download ‘https://start.spring.io/starter.zip?
- 8. 在idea讓java文件夾正常使用
- 9. Eclipse啓動提示「subversive connector discovery」
- 10. 帥某-技巧-快速轉帖博主文章（article_content）