想讓安卓 APP 如絲般順滑？

隨着安卓手機市場佔有率的節節攀升，隨便在大街上找幾我的估計 80% 用的都是安卓手機吧！用安卓手機的人這麼多，不知道你們是否曾經感受到過 APP 卡頓、死機？是否遇到應用程序無響應、閃退？本文就爲你們解釋一下其中的緣由，如何經過幀數來監測 APP 流暢度及解決此問題。

爲什麼 APP 會運行緩慢

學過計算機的人都知道， APP 運行在操做系統上，操做系統依賴於系統的硬件，例如 CPU 、內存等，也就是說 APP 運行也是須要必定的環境的，因此要分析爲什麼 APP 運行緩慢也要從兩個方面來考慮：

1、APP 的運行環境

首先硬件配置越高產生 APP 發生運行緩慢問題的時間就會越晚，這個很好理解吧，就是花錢越多用的越舒服（貴手機通常都比便宜手機配置好的喲）。再者，如今人們的手機上，裝個 10~20 個 APP 應該是很正常的吧，APP 的每個頁面點擊返回鍵的時候默認都是關閉操做，但這個也能夠處理成不關閉。 APP 運營人員爲了保持 APP 的活躍度，會有一些推送、消息提醒等功能，這些都是在後臺運行的。也就是說即便你的 APP 關閉了，後臺依然有 APP 在佔用系統資源。這些佔用的資源從應用管理列表中能夠看見，它們以「進程」和「服務」的方式體現出來了，以下圖：

從圖中能夠看出，APP 即便在後臺也會消耗一些資源，試想，若是手機安裝的 APP 多了，手機資源剩餘的就比較少了，這樣 APP 運行慢也就不難理解了 。

2、APP 自己的質量問題

APP 是程序員開發出來的， APP 開發者自己對 APP 運行緩慢也負有不可推卸的責任。例如，在 UI 線程作了一些耗時的操做，會致使 UI 卡頓；從網絡請求的圖片沒有作緩存處理，下次仍下載圖片致使圖片顯示慢； API 兼容性處理得很差致使了閃退。。。

我就不自黑了，就寫這麼多吧！

如何讓 APP 流暢運行

知道了緣由，就能夠各個擊破！

首先 APP 運行和硬件環境有關，這個好解決，換一個好點的手機嘍，這樣說是有些欠穩當但真的能解決問題，平時使用的時候，也要儘可能少地安裝 APP ，不要覺得安裝 APP 的成本低就一味地安裝，APP 安裝的越多在後臺運行的程序可能也就越多，最後會過多地佔用系統資源。但有時這些因素都不能避免的狀況下，咱們該怎麼辦呢？

其實咱們還能夠採起下面的外科手術式的方法來解決這個問題：

一、使用 XX 清理大師終結不須要的進程，這裏的降溫其實也就是殺進程。以下圖:

二、按期清理垃圾，俗氣一下還拿 XX 清理大師來舉例子，以下圖，點擊垃圾清理以後的頁面，只需輕輕一點，以後再運行 APP 就會感受不同:

三、 上述的的方法能夠說只能解決一時的問題，治標不治本。聽說有些 APP 爲了逃避後臺進程和服務被殺死，攔截了手機開機、屏幕解鎖、網絡狀態變化、電量變化等事件，攔截了以後一旦發現進程沒有開啓就會自動把死掉的進程和服務重啓。對於消費者來講真是防不勝防！這裏介紹一個從系統層面解決的方法，限制後臺進程。具體操做是（拿小米手機舉例子），設置->其餘高級設置->開發者選項->後臺進程限制，以下圖:

如何檢測 APP 流暢度

在安卓 4.1 以前能夠說檢測很是困難的。例如這個老兄的文章： Android 應用程序 fps meter [幀數顯示]的分析。可是 Android 在發佈 4.1 JellyBean 版本的同時，推出了「 Project Butter」（黃油計劃）,這一計劃的目的是讓 Android 的操做變得更加流暢迅速、更加可靠穩定。谷歌提供了一個叫作「 GPU 呈現模式分析( Profile GPU rendering ) 」的工具，開啓這個功能後，系統就會記錄保留每一個界面最後 128 幀圖像繪製的相關時間信息。以下（打開步驟在開發者選項中找）：

這個時候，經過 adb shell dumpsys gfxinfo com.xxxx.xxx 能夠得到不少信息，這裏拿手機 QQ 舉例子，經過 adb shell dumpsys gfxinfo com.tencent.mobileqq 這個命令就獲得的數據以下：

Draw : 表示在 Java 中建立顯示列表部分中， OnDraw() 方法佔用的時間；

Process ：表示渲染引擎執行顯示列表所花的時間， VIEW 越多，時間就越長；

Execute ：表示把一幀數據發送到屏幕上排版顯示實際花費的時間，實際上是實際顯示幀數據的後臺緩存區與前臺緩衝區交換後並將前臺緩衝區的內容顯示到屏幕上的時間。因此這個時間，通常都很短；

PS： View 類包含 Surface （變量名 mSurface ），每一個 Surface 一般對應兩個 buffer ，一個 front buffer , 一個 back buffer ( 4.1 以後是 3 個，一個前，兩個後)。其中，back buffer 就是 canvas 繪圖時對應的 bitmap (研究 Android_view_Surface.cpp::lockCanvas )。所以，繪畫老是在 back buffer 上，須要更新時，則將 back buffer 和 front buffer 互換。

Draw + Process + Execute = 完整顯示一幀 ，這個時間要小於 16ms 才能保存每秒 60 幀。

這裏大體能看見幀數，可是操做起來比較麻煩，也不是很直觀。因此，若是有一款不那麼麻煩，對開發者友好的流暢度檢測工具對開發者來講簡直是一個福音，特別是 APP 發佈出去以後，APP 在不一樣的運行環境和在不一樣的操做環境下的真實體驗究竟如何，對開發者價值很是大。

若是你如今正所以而苦惱，那就不要擔憂啦！兄弟們開足了馬力，通過長時間地研究終於可讓你經過 OneAPM MI 產品的 Android SDK 來監測 APP 幀數啦！來試試吧，作開發的兄弟姐妹們！

OneAPM Mobile Insight 以真實用戶體驗爲度量標準進行 crash 分析，監控網絡請求及網絡錯誤，提高用戶留存。訪問 OneAPM 官方網站感覺更多應用性能優化體驗，想閱讀更多技術文章，請訪問 OneAPM 官方技術博客。