Android P正式版即將到來：應用保活、消息推送的噩夢

08-22

來自專欄即時通訊技術分享198 人贊了文章

1、前言

對於廣大Android開發者來說，Android O（即Android 8.0）還沒玩熱，Andriod P（即Andriod 9.0）又要來了。

下圖上谷歌官方公布的Android P發布路線圖：

Android P的最後一個開發者預覽版（即DP5）已如期發佈於2018年7月26日，根據上面這張發布路線圖，相信Android P的正式版將很快到來。對於Andriod開發者來說，不管Andriod P有多少新功能或者特性（反正「我」用iPhone啊，哈哈），是否影響「我」擼的APP的運行才是最要緊的事。

自從Andriod 6.0以來，Android系統在省電管理這方面做的越來越好，對於開發者來說限制也越來越多，也直接導致了各種保活黑科技群魔亂舞（別笑，就的就是「你」！）。但Android P官方公開的開發者資料來看，此版加入或強化的多項設備電量管理新特性，使得需要後台消息推送、應用保活的APP變的越來越困難，黑科技恐將成為歷史。

學習交流：

- 即時通訊開發交流3群：185926912[推薦]
- 移動端IM開發入門文章：《新手入門一篇就夠：從零開發移動端IM》

（同步發佈於：http://www.52im.net/thread-1832-1-1.html）

2、原先的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三種方案的優劣》）。

3、針對以往Android版本的各種保活技術回顧

搞Android端IM和消息推送服務的開發者都知道，Android P之前為了搞定客戶的投訴：「為什麼微信能收到消息而你們的IM卻不能?」，為了解決這個「痛點」，廣大的Android開發者們只能讓各種黑科技輪番上場、各顯神通，最典型的：比如曾今在手機QQ上的1像素保活（雖然QQ官方從沒正面承認過）、後台無限播放無聲音的音頻、應用互相拉活等，大家都耳熟能詳。

下面就是即時通訊網整理過的各種典型保活需求和思路，可以回顧學習一下：

《應用保活終極總結(一)：Android6.0以下的雙進程守護保活實踐》
《應用保活終極總結(二)：Android6.0及以上的保活實踐(進程防殺篇)》
《應用保活終極總結(三)：Android6.0及以上的保活實踐(被殺復活篇)》
《Android進程保活詳解：一篇文章解決你的所有疑問》

《Android端消息推送總結：實現原理、心跳保活、遇到的問題等》
《深入的聊聊Android消息推送這件小事》
《為何基於TCP協議的移動端IM仍然需要心跳保活機制？》
《微信團隊原創分享：Android版微信後台保活實戰分享(進程保活篇)》
《微信團隊原創分享：Android版微信後台保活實戰分享(網路保活篇)》
《移動端IM實踐：實現Android版微信的智能心跳機制》
《移動端IM實踐：WhatsApp、Line、微信的心跳策略分析》

4、國內各種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首家統一推送服務》），對於開發者來說信鴿的實現思路其實跟我們想的是一樣的。但好處是：別人有專門的團隊死磕這件破事，比你自已一個人帶來的效果要好多了。

5、萬眾矚目的「統一推送聯盟」上場了

為了解決這些亂象，好消息是去年有政府背景的「統一推送聯盟」成立了（詳見《[資訊] 統一推送聯盟在京成立：結束國內安卓生態混亂》），廣大Android開發者真是翹首以盼。

但壞消息是好像進展並不順利（大家心知肚明啊，各廠商的利益不好均衡嘛），最近一次跟消息推送服務有關的活動還是3個月前的《[資訊] 統一推送聯盟2018成員大會如期召開》。雖然進展不大，但總算還是有希望，Android同行們再等等，總有Android端消息推送一統江湖的方案出現的那天。

** 20180805最新進展：統一推送聯盟於2018年8月初對外公開了《統一推送通道層介面規範》。夢想離現實又近了一步！

6、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 ，所有應用都受限於以上行為變更。

接下來將逐一介紹這幾個特性。

7、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 消息當做「普通優先順序」消息來處理。

*注意：如果用戶多次忽略某條推送，系統會詢問用戶是否不再接受此推送。請開發者不要只是為了將應用保留在活躍群組，而向用戶不斷發送推送。如果一個應用下面有多個包，這些包可能分別屬於不同分組，各自的訪問許可權也有所不同。在測試環節時，請開發者先將包劃分至不同分組，然後進行多次測試，確保應用行為無異常。

8、Andriod P電量管理特性2：後台限制

當系統監測到應用消耗過多資源時，系統會通知並詢問用戶是否需要限制該應用的後台活動。

目前有以下兩種情況會觸發系統發送此通知：

1）頻繁使用喚醒鎖 (wake locks)：屏幕關閉後，局部喚醒鎖 (Partial wake lock) 連續開啟 1 小時；

2）過多的後台服務：當應用目標 API 等級低於 26，且運行過多後台服務。

設備廠商可自行決定具體採用的限制，比如：在 AOSP 構建上，除非受限應用運行在前台，否則它將無法運行任務 (job)，觸發鬧鈴或者訪問網路。(請查閱《後台服務限制》了解如何判斷應用是否為前台運行。) 詳細限制列表，請查閱《附件：電量管理限制》。

9、Andriod P電量管理特性3：省電助手優化

Android P 進一步提升了省電模式的性能，由設備廠商來決定其採用的具體限制。

比如：在AOSP構建上存在以下系統限制：

1）應用將更容易進入待機模式，系統不會一直等到應用處於「空閑」狀態才採取行行動；

2）不論目標API等級為何，所有應用都會受到後台執行限制；

3）屏幕關閉後，位置服務可能被禁用；

4）處於後台的應用不能訪問網路。

除此以外，Android P 還引入了多項針對設備的電量管理的優化，請閱讀《附件：電量管理限制》獲取進一步信息。

建議開發者在開啟省電模式的情況下測試應用，您可在 Settings > Battery Saver 內手動開啟省電模式：

10、Andriod P電量管理特性4：低耗電模式

在低耗電模式下，應用對高耗電資源的使用許可權將被推遲至下一個維護時段。具體限制請參照《附件：電量管理限制》。

進一步信息，請查閱《對低耗電模式和應用待機模式進行針對性優化》。

11、本文小結

對於開發者來說，Android平台向來以「亂」著稱，後台保活和消息推送從各種黑科技，到廠商紛紛自建通道，再到統一推送聯盟。時至今日，該面對的問題依然沒有改觀，隨著Android P正式版的發布，對於IM、消息推送服務等開發者來說，個人英雄主義式的技術黑科技越來越沒有發揮的空間，從長遠來講這是好事。

隨著時間的推進，分久必合的局面終將出現，Android平台也必將越來越規範，Android P這樣版本只是這前進過程中的陣痛，希望廣大Android開發者在Android技術進步的福利下能越來越輕鬆，再也不用「開大招」琢磨各種非主流黑科技了。

附錄：更多相關技術文章

《iOS的推送服務APNs詳解：設計思路、技術原理及缺陷等》
《信鴿團隊原創：一起走過 iOS10 上消息推送(APNS)的坑》
《Android端消息推送總結：實現原理、心跳保活、遇到的問題等》
《掃盲貼：認識MQTT通信協議》
《一個基於MQTT通信協議的完整Android推送Demo》
《IBM技術經理訪談：MQTT協議的制定歷程、發展現狀等》
《求教android消息推送：GCM、XMPP、MQTT三種方案的優劣》
《移動端實時消息推送技術淺析》
《掃盲貼：淺談iOS和Android後台實時消息推送的原理和區別》
《絕對乾貨：基於Netty實現海量接入的推送服務技術要點》
《移動端IM實踐：谷歌消息推送服務(GCM)研究（來自微信）》
《為何微信、QQ這樣的IM工具不使用GCM服務推送消息？》
《極光推送系統大規模高並發架構的技術實踐分享》
《從HTTP到MQTT：一個基於位置服務的APP數據通信實踐概述》
《魅族2500萬長連接的實時消息推送架構的技術實踐分享》
《專訪魅族架構師：海量長連接的實時消息推送系統的心得體會》
《深入的聊聊Android消息推送這件小事》
《基於WebSocket實現Hybrid移動應用的消息推送實踐(含代碼示例)》
《一個基於長連接的安全可擴展的訂閱/推送服務實現思路》
《實踐分享：如何構建一套高可用的移動端消息推送系統？》
《Go語言構建千萬級在線的高並發消息推送系統實踐(來自360公司)》
《騰訊信鴿技術分享：百億級實時消息推送的實戰經驗》
《百萬在線的美拍直播彈幕系統的實時推送技術實踐之路》
《京東京麥商家開放平台的消息推送架構演進之路》
《了解iOS消息推送一文就夠：史上最全iOS Push技術詳解》
《基於APNs最新HTTP/2介面實現iOS的高性能消息推送(服務端篇)》
>> 更多同類文章 ……

（同步發佈於：http://www.52im.net/thread-1832-1-1.html）