說到 Android 系統(tǒng)手機，大部分人的印象是用了一段時間就變得有點卡頓，有些程序在運行期間莫名其妙的出現(xiàn)崩潰，打開系統(tǒng)文件夾一看，發(fā)現(xiàn)多了很多文件，然后用手機管家 APP 不斷地進行清理優(yōu)化 ，才感覺運行速度稍微提高了點，就算手機在各種性能跑分軟件面前分數(shù)遙遙領(lǐng)先，還是感覺無論有多大的內(nèi)存空間都遠遠不夠用。相信每個使用 Android 系統(tǒng)的用戶都有過以上類似經(jīng)歷，確實，Android 系統(tǒng)在流暢性方面不如 IOS 系統(tǒng)，為何呢，明明在看手機硬件配置上時，Android 設(shè)備都不會輸于 IOS 設(shè)備，甚至都強于它，關(guān)鍵是在于軟件上。

造成這種現(xiàn)象的原因是多方面的，簡單羅列幾點如下：

? ? 其實近年來，隨著 Android 版本不斷迭代，Google 提供的Android 系統(tǒng)已經(jīng)越來越流暢，目前最新發(fā)布的版本是 Android 8.0 Oreo 。但是在國內(nèi)大部分用戶用的 Android 手機系是各大廠商定制過的版本，往往不是最新的原生系統(tǒng)內(nèi)核，可能絕大多數(shù)還停留在 Android 5.0 系統(tǒng)上，甚至 Android 6.0 以上所占比例還偏小，更新存在延遲性。

? ? 由于 Android 系統(tǒng)源碼是開放的，每個人只要遵從相應(yīng)的協(xié)議，就可以對源碼進行修改，那么國內(nèi)各個廠商就把基于 Android 源碼改造成自己對外發(fā)布的系統(tǒng)，比如我們熟悉的小米手機 Miui 系統(tǒng)、華為手機 EMUI 系統(tǒng)、Oppo 手機 ColorOS 系統(tǒng)等。由于每個廠商都修改過 Android 原生系統(tǒng)源碼，這里面就會引發(fā)一個問題，那就是著名的Android 碎片化問題，本質(zhì)就是不同 Android 系統(tǒng)的應(yīng)用兼容性不同，達不到一致性。

? ? 由于存在著各種 Android 碎片化和兼容性問題，導(dǎo)致 Android 開發(fā)者在開發(fā)應(yīng)用時需要對不同系統(tǒng)進行適配，同時每個 Android 開發(fā)者的開發(fā)水平參差不齊，寫出來的應(yīng)用性能也都存在不同類型的問題，導(dǎo)致用戶在使用過程中用戶體驗感受不同，那么有些問題用戶就會轉(zhuǎn)化為 Android 系統(tǒng)問題，進而影響對Android 手機的評價。

性能優(yōu)化

今天想說的重點是Android APP 性能優(yōu)化，也就是在開發(fā)應(yīng)用程序時應(yīng)該注意的點有哪些，如何更好地提高用戶體驗。一個好的應(yīng)用，除了要有吸引人的功能和交互之外，在性能上也應(yīng)該有高的要求，即時應(yīng)用非常具有特色，在產(chǎn)品前期可能吸引了部分用戶，但是用戶體驗不好的話，也會給產(chǎn)品帶來不好的口碑。

那么一個好的應(yīng)用應(yīng)該如何定義呢？主要有以下三方面：
? ? ? 業(yè)務(wù)/功能
? ? ? 符合邏輯的交互
? ? ? 優(yōu)秀的性能

眾所周知，Android 系統(tǒng)作為以移動設(shè)備為主的操作系統(tǒng)，硬件配置是有一定的限制的，雖然配置現(xiàn)在越來越高級，但仍然無法與 PC 相比，在 CPU 和內(nèi)存上使用不合理或者耗費資源多時，就會碰到內(nèi)存不足導(dǎo)致的穩(wěn)定性問題、CPU 消耗太多導(dǎo)致的卡頓問題等。

面對問題時，大家想到的都是聯(lián)系用戶，然后查看日志，但殊不知有關(guān)性能類問題的反饋，原因也非常難找，日志大多用處不大，為何呢？因為性能問題大部分是非必現(xiàn)的問題，問題定位很難復(fù)現(xiàn)，而又沒有關(guān)鍵的日志，當(dāng)然就無法找到原因了。這些問題非常影響用戶體驗和功能使用，所以了解一些性能優(yōu)化的一些解決方案就顯得很重要了，并在實際的項目中優(yōu)化我們的應(yīng)用，進而提高用戶體驗。

四個方面

可以把用戶體驗的性能問題主要總結(jié)為4個類別：
? ? ? 流暢
? ? ? 穩(wěn)定
? ? ? 省電、省流量
? ? ? 安裝包小

性能問題的主要原因是什么，原因有相同的，也有不同的，但歸根到底，不外乎內(nèi)存使用、代碼效率、合適的策略邏輯、代碼質(zhì)量、安裝包體積這一類問題，整理歸類如下：

從圖中可以看到，打造一個高質(zhì)量的應(yīng)用應(yīng)該以4個方向為目標(biāo)：快、穩(wěn)、省、小。

快：使用時避免出現(xiàn)卡頓，響應(yīng)速度快，減少用戶等待的時間，滿足用戶期望。

穩(wěn)：減低 crash 率和 ANR 率，不要在用戶使用過程中崩潰和無響應(yīng)。

省：節(jié)省流量和耗電，減少用戶使用成本，避免使用時導(dǎo)致手機發(fā)燙。

小：安裝包小可以降低用戶的安裝成本。

要想達到這4個目標(biāo)，具體實現(xiàn)是在右邊框里的問題：卡頓、內(nèi)存使用不合理、代碼質(zhì)量差、代碼邏輯亂、安裝包過大，這些問題也是在開發(fā)過程中碰到最多的問題，在實現(xiàn)業(yè)務(wù)需求同時，也需要考慮到這點，多花時間去思考，如何避免功能完成后再來做優(yōu)化，不然的話等功能實現(xiàn)后帶來的維護成本會增加。

卡頓優(yōu)化

Android 應(yīng)用啟動慢，使用時經(jīng)?？D，是非常影響用戶體驗的，應(yīng)該盡量避免出現(xiàn)?？D的場景有很多，按場景可以分為4類：UI 繪制、應(yīng)用啟動、頁面跳轉(zhuǎn)、事件響應(yīng)，如圖：

這4種卡頓場景的根本原因可以分為兩大類：

? ? 界面繪制。
主要原因是繪制的層級深、頁面復(fù)雜、刷新不合理，由于這些原因?qū)е驴D的場景更多出現(xiàn)在 UI 和啟動后的初始界面以及跳轉(zhuǎn)到頁面的繪制上。

? ? 數(shù)據(jù)處理。
導(dǎo)致這種卡頓場景的原因是數(shù)據(jù)處理量太大，一般分為三種情況：
一是數(shù)據(jù)在處理 UI 線程，
二是數(shù)據(jù)處理占用 CPU 高，導(dǎo)致主線程拿不到時間片，
三是內(nèi)存增加導(dǎo)致 GC 頻繁，從而引起卡頓。
引起卡頓的原因很多，但不管怎么樣的原因和場景，最終都是通過設(shè)備屏幕上顯示來達到用戶，歸根到底就是顯示有問題，所以，要解決卡頓，就要先了解 Android 系統(tǒng)的顯示原理。

Android系統(tǒng)顯示原理

Android 顯示過程可以簡單概括為：Android 應(yīng)用程序把經(jīng)過測量、布局、繪制后的 surface 緩存數(shù)據(jù)，通過 SurfaceFlinger 把數(shù)據(jù)渲染到顯示屏幕上， 通過 Android 的刷新機制來刷新數(shù)據(jù)。也就是說應(yīng)用層負責(zé)繪制，系統(tǒng)層負責(zé)渲染，通過進程間通信把應(yīng)用層需要繪制的數(shù)據(jù)傳遞到系統(tǒng)層服務(wù)，系統(tǒng)層服務(wù)通過刷新機制把數(shù)據(jù)更新到屏幕上。

我們都知道在 Android 的每個 View 繪制中有三個核心步驟：Measure、Layout、Draw。具體實現(xiàn)是從 ViewRootImp 類的performTraversals() 方法開始執(zhí)行，Measure 和 Layout都是通過遞歸來獲取 View 的大小和位置，并且以深度作為優(yōu)先級，可以看出層級越深、元素越多、耗時也就越長。

真正把需要顯示的數(shù)據(jù)渲染到屏幕上，是通過系統(tǒng)級進程中的 SurfaceFlinger 服務(wù)來實現(xiàn)的，那么這個SurfaceFlinger 服務(wù)主要做了哪些工作呢？如下：
? ? ?響應(yīng)客戶端事件，創(chuàng)建 Layer 與客戶端的 Surface 建立連接。
? ? ?接收客戶端數(shù)據(jù)及屬性，修改 Layer 屬性，如尺寸、顏色、透明度等。
? ? ?將創(chuàng)建的 Layer 內(nèi)容刷新到屏幕上。
? ? ?維持 Layer 的序列，并對 Layer 最終輸出做出裁剪計算。

既然是兩個不同的進程，那么肯定是需要一個跨進程的通信機制來實現(xiàn)數(shù)據(jù)傳遞，在 Android 顯示系統(tǒng)中，使用了 Android 的匿名共享內(nèi)存：SharedClient，每一個應(yīng)用和 SurfaceFlinger 之間都會創(chuàng)建一個SharedClient ，然后在每個 SharedClient 中，最多可以創(chuàng)建 31 個 SharedBufferStack，每個 Surface 都對應(yīng)一個 SharedBufferStack，也就是一個 Window。

一個 SharedClient 對應(yīng)一個Android 應(yīng)用程序，而一個 Android 應(yīng)用程序可能包含多個窗口，即 Surface 。也就是說 SharedClient 包含的是 SharedBufferStack的集合，其中在顯示刷新機制中用到了雙緩沖和三重緩沖技術(shù)。最后總結(jié)起來顯示整體流程分為三個模塊：應(yīng)用層繪制到緩存區(qū)，SurfaceFlinger 把緩存區(qū)數(shù)據(jù)渲染到屏幕，由于是不同的進程，所以使用 Android 的匿名共享內(nèi)存 SharedClient 緩存需要顯示的數(shù)據(jù)來達到目的。

除此之外，我們還需要一個名詞：FPS。FPS 表示每秒傳遞的幀數(shù)。在理想情況下，60 FPS 就感覺不到卡，這意味著每個繪制時長應(yīng)該在16 ms 以內(nèi)。但是 Android 系統(tǒng)很有可能無法及時完成那些復(fù)雜的頁面渲染操作。Android 系統(tǒng)每隔 16ms 發(fā)出 VSYNC 信號，觸發(fā)對 UI 進行渲染，如果每次渲染都成功，這樣就能夠達到流暢的畫面所需的 60FPS。如果某個操作花費的時間是 24ms ，系統(tǒng)在得到 VSYNC 信號時就無法正常進行正常渲染，這樣就發(fā)生了丟幀現(xiàn)象。那么用戶在 32ms 內(nèi)看到的會是同一幀畫面，這種現(xiàn)象在執(zhí)行動畫或滑動列表比較常見，還有可能是你的 Layout 太過復(fù)雜，層疊太多的繪制單元，無法在 16ms 完成渲染，最終引起刷新不及時。

卡頓根本原因

根據(jù)Android 系統(tǒng)顯示原理可以看到，影響繪制的根本原因有以下兩個方面：

? ?繪制任務(wù)太重，繪制一幀內(nèi)容耗時太長。
? ? ?主線程太忙，根據(jù)系統(tǒng)傳遞過來的 VSYNC 信號來時還沒準(zhǔn)備好數(shù)據(jù)導(dǎo)致丟幀。