Android vitals 幫您解決應用質量問題

對於應用開發者而言，衡量應用成功最好的指標就是開心的用戶，並且是越多越好。達到這一目的的最佳途徑就是開發一個好應用，那麼什麼樣的應用才能被稱做是 「好」 應用呢？歸根結底就是兩件事：功能以及應用質量。前者取決於開發者的創造力以及選用的商業模型；然後者則可以被客觀測量及改善。

去年穀歌進行的一項內部調查顯示 Play Store 中超過 40% 的一星應用存在穩定性問題。另外一方面，對於性能卓越的應用，人們打分和評論每每愈來愈好，這讓它們在 Google Play 中的排名上升，下載量也隨之增長。不只如此，用戶參與度也更高，並且願意花更多的時間和金錢在這些應用上。

所以，解決應用穩定性問題可以顯著影響到應用成功與否。

經過對應用質量的客觀測量，開發者可以輕易發現應用亟待解決的穩定性問題，爲此咱們在 Google Play Console 添加了一款名爲 Android vitals 的新板塊。藉助 Android vitals，開發者無須添加額外工具代碼或者庫就能瞭解應用存在的性能及穩定性問題。當應用在大量設備上運行時，Android vitals 會收集與應用性能相關的匿名數據。經過這種途徑得到的信息量是其餘方式沒法匹及的，即便是硬件實驗室測試也不行。

Android vitals 能夠向開發者發送如下三種警告：崩潰、應用程序沒法響應以及渲染次數。這三種狀況都會直接影響到用戶體驗以及他們對應用的評價。此外，用戶可能不會將 「異常耗電事件」 這類不良行爲與您的應用直接聯繫起來。

這篇文章將探討其中如下兩個問題：

1.過分喚醒：過分喚醒會對電池壽命形成影響，並且在沒法及時充電的狀況下，可能致使用戶沒法繼續使用設備。此類行爲可能會讓用戶迅速卸載您的應用；

2.應用程序沒法響應 (ANR)事件：當應用的用戶界面卡住時候，此類事件會被觸發。在界面凍結時，若您的應用在前臺運行，會出現對話框提醒用戶 「關閉應用」 或者 「等待響應」。對用戶而言，此類行爲和應用崩潰同樣糟糕。他們可能不會立刻卸載您的應用，可是若是 ANR 問題一直不解決，就頗有可能會尋找其它替代應用。

過分喚醒

那麼，什麼是喚醒？何時又是喚醒 「過分」 呢？

爲了延長電池續航時間，屏幕關閉後，Android 設備會禁用主 CPU 內核，進入深度睡眠模式。除非用戶喚醒設備，設備最好能夠儘量長地保持這種狀態。不過，在發生某些事件的狀況下，仍是頗有必要喚醒 CPU 並向用戶發出警告 —— 好比說，鬧鐘觸發或者收到新消息。開發者能夠經過喚醒鬧鐘 (wakeup alarm) 來處理此類警告，不過也不必定非要這麼操做，在下文中會對此稍加解釋。到目前爲止，喚醒看上去彷佛是個不錯的東西，讓重要事情能引發用戶注意，不過要是喚醒太屢次就拔苗助長，電池壽命也會大打折扣。

Android vitals 如何顯示過分喚醒

Android vitals 可以幫助開發者瞭解本身的應用是否存在喚醒次數太多的問題。經過收集有關應用行爲的匿名數據，Android vitals 能夠顯示有多少比例的用戶在設備滿電以後，每小時經歷 10 次以上的設備喚醒。關鍵就是看有沒有紅色的圖標出現，若圖標出現，則說明應用已經越過了不良行爲門檻，屬於 Google Play 中表現最次的一檔應用，而您則需要想辦法改善應用行爲了。

除了喚醒鬧鐘，還有別的方法嗎？

開發者主要是經過 AlarmManager API 設定 RTC_WAKEUP 或 ELAPSED_REALTIME_WAKEUP 旗標，讓應用在特定時間或者在某一時間間隔後喚醒設備。該功能須謹慎對待，僅在沒有其它更優的任務調度和通知機制的狀況下才可以使用。在使用喚醒鬧鐘的時候，您須要考慮如下幾點：

• 若您須要顯示信息以響應來自網絡的數據，考慮經過使用 Firebase Cloud Messaging 等工具來實現消息推送。利用該機制而不是按期輪詢新數據，您的應用會僅在須要時才被喚醒。
• 若是您沒法使用消息推送並依賴按期輪詢，考慮使用 JobScheduler 或者 Firebase JobDispatcher (或者使用 SyncManager 來處理帳戶數據)。它們的 API 等級比 AlarmManager 高，並且在智能任務調度方面具有如下優勢：

-- 批量操做：批量操做任務而不是屢次喚醒系統進行操做，這使設備能更長時間處於睡眠狀態。

-- 標準：您能夠明確任務運行須知足的具體標準，如網絡可用性或者電池充電狀態。設定標準可以避免喚醒設備以及沒必要要的應用運行。

-- 持續性以及自動退避 —— 繼續執行任務 (即便在重啓後) 而且在失敗的狀況能自動重試。

-- 低耗電模式 (doze) 兼容性 —— 僅在低耗電模式或者應用待機模式未設定任何限制的狀況下，任務才能運行。

當且僅當消息推送以及任務調度對您的任務不適用時，您才能夠利用 AlarmManager 設定喚醒鬧鐘。換個角度來講就是，僅當您想要在特定時間觸發鬧鐘，不考慮網絡以及其它狀況，喚醒鬧鐘纔是必要的。

當 Android vitals 顯示過分喚醒時，您應採起何種對策？

爲了解決過分喚醒問題，您需要確認應用在什麼地方設定了喚醒鬧鐘，而後下降這些鬧鐘的觸發頻率。

那麼如何查看應用在哪些地方設了喚醒鬧鐘呢？您能夠打開 Android Studio 中的 AlarmManager 類，右擊 RTC_WAKEUP 或者 ELAPSED_REALTIME_WAKEUP 域，選擇 "Find Usages (查找使用)"，而後您就能看到項目中全部使用到此類旗標的事件了。仔細查看每一種事件，而後考慮可否改用更爲智能的任務調度機制。

您也能夠將 Find Usage (查找使用) 中的範圍設定爲 「Project and libraries (項目和庫)」，查看依賴項是否在使用 AlarmManager API。若是確實在使用，那麼您應該考慮使用別的庫，或者向依賴項開發人員報告錯誤。

若您認爲使用喚醒鬧鐘沒法避免，那麼若是您的鬧鐘標籤知足如下要求，Play Console 能夠提供更好的分析數據：

• 在鬧鐘標籤中包含包、類或者方法名稱。這也能夠幫助您輕鬆肯定在源中的哪些地方設定了鬧鐘；
• 不要使用 Class#getName() 給鬧鐘命名，由於 Proguard 會對此產生混淆。請使用硬編碼字符串；
• 不要向鬧鐘標籤添加計數器或者其它惟一標識符，由於系統可能會貴去掉這類標籤，並且沒法將它們計入有效數據內。

應用程序沒法響應

那麼，什麼是應用程序沒法響應 (如下簡稱爲ANR)？它又是怎麼影響到用戶的呢？

對用戶而言，ANR 就是指當他們試圖與應用進行交互時，但界面卡住的事件。界面卡屏幾秒後，會出現對話框讓用戶選擇繼續等待或者強行中止應用。

從開發者的角度來看，ANR 則是指應用運行的操做耗時太久，如磁盤或網絡 I/O，致使主線程阻塞。主線程 (有時候也被稱爲 UI 線程) 主要負責響應用戶事件以及每秒刷新 60 次屏幕。所以很關鍵的一點將任何可能延時主線程工做的操做轉到後臺線程。

Android vitals 如何顯示應用程序沒法響應？

Android vitals 能收集並利用應用 ANR 事件的匿名數據，提供多個級別的 ANR 具體報告。主界面上概述了您應用中 ARN 活動的概覽信息，顯示用戶至少經歷一次 ANR 事件的日對話比重，而且提供前一天以及前 30 天的狀況的單獨報告。同時也提供了不良行爲門檻。

打開詳情界面，即 ANR 比率頁面，您可以瞭解不一樣時間的 ANR 具體比例，以及針對不一樣應用版本、活動名稱、ANR 類別、以及 Android 系統下的 ANR 狀況。您能夠就 APK 版本代碼、支持設備、OS 版本以及時間，篩選查看這些數據。

應用程序沒法響應常見緣由

如上文所述，當應用進程影響到主線程時，ANR 事件會被觸發，而致使這種阻塞現象的緣由各有不一，較爲常見的有：

• 在主線程上執行磁盤或者網絡 I/O。這是迄今爲止致使 ANR 的最多見緣由。雖然大部分開發者認同不該該在主線程上進行讀寫磁盤或者網絡，可是有時候咱們就是忍不住這麼作。在理想狀況下，從磁盤上讀取幾個字節的數據並不會引起 ANR，可是這絕對不是什麼好主意。若是用戶的設備閃存很慢，若是其它同時進行讀寫的應用已經對設備形成了很大壓力，而您的應用還在排隊等着運行 「快速」 讀取操做, 這樣真的不夠明智，因此千萬別在主線程運行 I/O；
• 在主線程上運行長計算。那麼內存計算又是怎麼一回事呢？訪問時間長並不會對內存形成影響，較小的操做應該也沒什麼問題。可是若是您開始循環運行復雜計算而且處理大數據集，主線程就很容易發生阻塞了。您能夠考慮從新調整百萬像素大圖像的體積，或者在解析大 HTML 文本塊後，再將文本顯示到 TextView 中。總的來講，仍是讓應用在後臺運行此類操做比較合適；
• 向主線程另外一進程同步調用 binder：與磁盤或網絡操做類似，在線程間進行阻塞調用時，程序執行會被轉移到您沒法控制的地方。若是說其它進程忙碌，該怎麼辦？若是需要訪問磁盤或者網絡以響應您的請求，又該怎麼辦？此外，數據在轉移到其它進程前，需要通過打包 (parcel) 與解包 (unparcel) 兩個步驟，會消耗很多時間。所以，仍是建議從後臺線程進行進程間調用；
• 使用同步：即便您將複雜操做轉移到後臺線程運行，依舊需要與主線程溝通以顯示計算結果。多線程編程不容易，而且在使用同步鎖的時候，很難保證不出現阻塞執行。在最糟糕的狀況下，可能會出現死鎖問題，即不一樣線程相互卡死。最好不要本身設計同步，建議使用專門的解決方案，好比說 Handler，將不可變數據從後臺線程傳回主線程。

如何檢測應用程序沒法響應緣由

尋找觸發 ANR 的緣由不容易，咱們拿 URL 類舉個例子：

1. 您想看到 URL#equals (判斷兩個 URL 是否相同的方法) 阻塞線程嗎？SharedPreferences 又怎麼處理呢？
2. 若是您是在後臺讀取數值的話，您能在前臺調用 getSharedPreferences 嗎？

這兩種狀況都極可能致使長時間阻塞操做。幸虧咱們有 StrictMode，不用再本身瞎猜是什麼緣由致使 ARN 了。在調試構建的時候，您可使用這個工具捕捉主線程上的意外磁盤或網絡訪問。

您能夠在應用中使用 StrictMode#setThreadPolicy，自定義檢查項，包括磁盤和網絡 I/O 以及您經過 StrictMode#noteSlowCall 在應用中觸發的慢調用。同時，您也能夠本身選擇讓 StrictMode 經過何種方式告知已檢測到阻塞調用：應用崩潰、日誌記錄仍是顯示對話框？您可參看 ThreadPolicy.Builder class 獲取進一步信息。

一旦您消除主線程上的阻塞調用，請記得再上傳應用至 Play Store 前，關閉 StrictMode。

解決過分喚醒以及 ANR 問題可以提高應用質量及穩定性，提升應用評分，獲取更多好評，最終增長下載量。使用 Android vitals 讓您輕鬆快速地瞭解應用中亟待解決的問題。發現並解決代碼中的這些問題可能並不容易，可是您能夠利用工具和技術有效地完成工做。

點擊這裏您可查看 Android 和 Google Play 相關內容信息