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

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

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

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

性能優(yōu)化

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

• 業(yè)務(wù)/功能

• 符合邏輯的交互

• 優(yōu)秀的性能

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

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

四個方面

可以把用戶體驗(yàn)的性能問題主要總結(jié)為4個類別：

• 流暢

• 穩(wěn)定

• 省電,、省流量

• 安裝包小

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

打造一個高質(zhì)量的應(yīng)用應(yīng)該以4個方向?yàn)槟繕?biāo)：快,、穩(wěn)、省,、小,。

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

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

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

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

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

卡頓優(yōu)化

卡頓根本原因

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

• 繪制任務(wù)太重,，繪制一幀內(nèi)容耗時太長,。

• 主線程太忙，根據(jù)系統(tǒng)傳遞過來的 VSYNC 信號來時還沒準(zhǔn)備好數(shù)據(jù)導(dǎo)致丟幀,。

繪制耗時太長,，有一些工具可以幫助我們定位問題。主線程太忙則需要注意了,，主線程關(guān)鍵職責(zé)是處理用戶交互,，在屏幕上繪制像素，并進(jìn)行加載顯示相關(guān)的數(shù)據(jù),，所以特別需要避免任何主線程的事情,，這樣應(yīng)用程序才能保持對用戶操作的即時響應(yīng)?？偨Y(jié)起來,，主線程主要做以下幾個方面工作：

• UI 生命周期控制

• 系統(tǒng)事件處理

• 消息處理

• 界面布局

• 界面繪制

• 界面刷新

除此之外，應(yīng)該盡量避免將其他處理放在主線程中,，特別復(fù)雜的數(shù)據(jù)計算和網(wǎng)絡(luò)請求等,。

1.布局優(yōu)化

布局是否合理主要影響的是頁面測量時間的多少，我們知道一個頁面的顯示測量和繪制過程都是通過遞歸來完成的,，多叉樹遍歷的時間與樹的高度h有關(guān),，其時間復(fù)雜度 O(h),，如果層級太深，每增加一層則會增加更多的頁面顯示時間,，所以布局的合理性就顯得很重要,。

那布局優(yōu)化有哪些方法呢，主要通過減少層級,、減少測量和繪制時間,、提高復(fù)用性三個方面入手?？偨Y(jié)如下：

• 減少層級,。合理使用 RelativeLayout 和 LinerLayout，合理使用Merge,。

• 提高顯示速度,。使用 ViewStub，它是一個看不見的,、不占布局位置,、占用資源非常小的視圖對象。

• 布局復(fù)用,?？梢酝ㄟ^ 標(biāo)簽來提高復(fù)用。

• 盡可能少用wrap_content,。wrap_content 會增加布局 measure 時計算成本,，在已知寬高為固定值時，不用wrap_content ,。

• 刪除控件中無用的屬性,。

2，避免過度繪制

過度繪制是指在屏幕上的某個像素在同一幀的時間內(nèi)被繪制了多次,。在多層次重疊的 UI 結(jié)構(gòu)中,，如果不可見的 UI 也在做繪制的操作，就會導(dǎo)致某些像素區(qū)域被繪制了多次,，從而浪費(fèi)了多余的 CPU 以及 GPU 資源,。

如何避免過度繪制呢，如下：

• 布局上的優(yōu)化,。移除 XML 中非必須的背景,，移除 Window 默認(rèn)的背景、按需顯示占位背景圖片

• 自定義View優(yōu)化,。使用 canvas.clipRect()來幫助系統(tǒng)識別那些可見的區(qū)域,，只有在這個區(qū)域內(nèi)才會被繪制。

3,，啟動優(yōu)化

通過對啟動速度的監(jiān)控,，發(fā)現(xiàn)影響啟動速度的問題所在,，優(yōu)化啟動邏輯，提高應(yīng)用的啟動速度,。啟動主要完成三件事：UI 布局,、繪制和數(shù)據(jù)準(zhǔn)備。因此啟動速度優(yōu)化就是需要優(yōu)化這三個過程：

• UI 布局,。應(yīng)用一般都有閃屏頁,，優(yōu)化閃屏頁的 UI 布局，可以通過 Profile GPU Rendering 檢測丟幀情況,。

• 啟動加載邏輯優(yōu)化,。可以采用分布加載,、異步加載,、延期加載策略來提高應(yīng)用啟動速度。

• 數(shù)據(jù)準(zhǔn)備,。數(shù)據(jù)初始化分析,，加載數(shù)據(jù)可以考慮用線程初始化等策略。

4,，合理的刷新機(jī)制

在應(yīng)用開發(fā)過程中,，因?yàn)閿?shù)據(jù)的變化，需要刷新頁面來展示新的數(shù)據(jù),，但頻繁刷新會增加資源開銷，并且可能導(dǎo)致卡頓發(fā)生,，因此,，需要一個合理的刷新機(jī)制來提高整體的 UI 流暢度。合理的刷新需要注意以下幾點(diǎn)：

• 盡量減少刷新次數(shù),。

• 盡量避免后臺有高的 CPU 線程運(yùn)行,。

• 縮小刷新區(qū)域。

5,，其他

在實(shí)現(xiàn)動畫效果時,，需要根據(jù)不同場景選擇合適的動畫框架來實(shí)現(xiàn)。有些情況下,，可以用硬件加速方式來提供流暢度,。

內(nèi)存優(yōu)化

一、 Android的內(nèi)存機(jī)制

    Android的程序由Java語言編寫,，所以Android的內(nèi)存管理與Java的內(nèi)存管理相似,。程序員通過new為對象分配內(nèi)存，所有對象在java堆內(nèi)分配空間,；然而對象的釋放是由垃圾回收器來完成的,。C／C++中的內(nèi)存機(jī)制是“誰污染,，誰治理”，java的就比較人性化了,，給我們請了一個專門的清潔工（GC）,。

二、Android的內(nèi)存溢出

 Android的內(nèi)存溢出是如何發(fā)生的?

 Android的虛擬機(jī)是基于寄存器的Dalvik,，它的最大堆大小一般是16M,，有的機(jī)器為24M。因此我們所能利用的內(nèi)存空間是有限的,。如果我們的內(nèi)存占用超過了一定的水平就會出現(xiàn)OutOfMemory的錯誤,。

為什么會出現(xiàn)內(nèi)存不夠用的情況呢？我想原因主要有兩個：

• 由于我們程序的失誤,，長期保持某些資源（如Context）的引用,，造成內(nèi)存泄露，資源造成得不到釋放,。

• 保存了多個耗用內(nèi)存過大的對象（如Bitmap）,，造成內(nèi)存超出限制。

常見內(nèi)存泄漏場景

如果在內(nèi)存泄漏發(fā)生后再去找原因并修復(fù)會增加開發(fā)的成本,，最好在編寫代碼時就能夠很好地考慮內(nèi)存問題,，寫出更高質(zhì)量的代碼，這里列出一些常見的內(nèi)存泄漏場景,，在以后的開發(fā)過程中需要避免這類問題,。

• 資源性對象未關(guān)閉。比如Cursor,、File文件等,，往往都用了一些緩沖，在不使用時,，應(yīng)該及時關(guān)閉它們,。

• 注冊對象未注銷。比如事件注冊后未注銷,，會導(dǎo)致觀察者列表中維持著對象的引用,。

• 類的靜態(tài)變量持有大數(shù)據(jù)對象。

• 非靜態(tài)內(nèi)部類的靜態(tài)實(shí)例,。

• Handler臨時性內(nèi)存泄漏,。如果Handler是非靜態(tài)的，容易導(dǎo)致 Activity 或 Service 不會被回收,。

• 容器中的對象沒清理造成的內(nèi)存泄漏,。

• WebView。WebView 存在著內(nèi)存泄漏的問題，在應(yīng)用中只要使用一次 WebView,，內(nèi)存就不會被釋放掉,。

優(yōu)化內(nèi)存空間

沒有內(nèi)存泄漏，并不意味著內(nèi)存就不需要優(yōu)化,，在移動設(shè)備上,，由于物理設(shè)備的存儲空間有限，Android 系統(tǒng)對每個應(yīng)用進(jìn)程也都分配了有限的堆內(nèi)存,，因此使用最小內(nèi)存對象或者資源可以減小內(nèi)存開銷,，同時讓GC 能更高效地回收不再需要使用的對象，讓應(yīng)用堆內(nèi)存保持充足的可用內(nèi)存,，使應(yīng)用更穩(wěn)定高效地運(yùn)行,。常見做法如下：

• 對象引用。強(qiáng)引用,、軟引用,、弱引用、虛引用四種引用類型,，根據(jù)業(yè)務(wù)需求合理使用不同,，選擇不同的引用類型。

• 減少不必要的內(nèi)存開銷,。注意自動裝箱,，增加內(nèi)存復(fù)用，比如有效利用系統(tǒng)自帶的資源,、視圖復(fù)用,、對象池、Bitmap對象的復(fù)用,。

• 使用最優(yōu)的數(shù)據(jù)類型,。比如針對數(shù)據(jù)類容器結(jié)構(gòu)，可以使用ArrayMap數(shù)據(jù)結(jié)構(gòu),，避免使用枚舉類型，使用緩存Lrucache等等,。

• 圖片內(nèi)存優(yōu)化,。可以設(shè)置位圖規(guī)格,，根據(jù)采樣因子做壓縮,，用一些圖片緩存方式對圖片進(jìn)行管理等等。

穩(wěn)定性優(yōu)化

Android 應(yīng)用的穩(wěn)定性定義很寬泛,，影響穩(wěn)定性的原因很多,，比如內(nèi)存使用不合理、代碼異常場景考慮不周全,、代碼邏輯不合理等,，都會對應(yīng)用的穩(wěn)定性造成影響,。其中最常見的兩個場景是：Crash 和 ANR，這兩個錯誤將會使得程序無法使用,，比較常用的解決方式如下：

• 提高代碼質(zhì)量,。比如開發(fā)期間的代碼審核，看些代碼設(shè)計邏輯,，業(yè)務(wù)合理性等,。

• 代碼靜態(tài)掃描工具。常見工具有Android Lint,、Findbugs,、Checkstyle、PMD等等,。

• Crash監(jiān)控,。把一些崩潰的信息，異常信息及時地記錄下來,，以便后續(xù)分析解決,。

• Crash上傳機(jī)制。在Crash后,，盡量先保存日志到本地,，然后等下一次網(wǎng)絡(luò)正常時再上傳日志信息。

耗電優(yōu)化

在移動設(shè)備中,，電池的重要性不言而喻,，沒有電什么都干不成。對于操作系統(tǒng)和設(shè)備開發(fā)商來說,，耗電優(yōu)化一致沒有停止,，去追求更長的待機(jī)時間，而對于一款應(yīng)用來說,，并不是可以忽略電量使用問題,，特別是那些被歸為“電池殺手”的應(yīng)用，最終的結(jié)果是被卸載,。因此,，應(yīng)用開發(fā)者在實(shí)現(xiàn)需求的同時，需要盡量減少電量的消耗,。

在 Android5.0 以前,，在應(yīng)用中測試電量消耗比較麻煩，也不準(zhǔn)確,，5.0 之后專門引入了一個獲取設(shè)備上電量消耗信息的 API:Battery Historian,。Battery Historian 是一款由 Google 提供的 Android 系統(tǒng)電量分析工具，和Systrace 一樣，是一款圖形化數(shù)據(jù)分析工具,，直觀地展示出手機(jī)的電量消耗過程,，通過輸入電量分析文件，顯示消耗情況,，最后提供一些可供參考電量優(yōu)化的方法,。

除此之外，還有一些常用方案可提供：

• 計算優(yōu)化,，避開浮點(diǎn)運(yùn)算等,。

• 避免 WaleLock 使用不當(dāng)。

• 使用 Job Scheduler,。

小結(jié)

性能優(yōu)化不是更新一兩個版本就可以解決的,，是持續(xù)性的需求，持續(xù)集成迭代反饋,。在實(shí)際的項(xiàng)目中,，在項(xiàng)目剛開始的時候，由于人力和項(xiàng)目完成時間限制,，性能優(yōu)化的優(yōu)先級比較低,，等進(jìn)入項(xiàng)目投入使用階段，就需要把優(yōu)先級提高,，但在項(xiàng)目初期,，在設(shè)計架構(gòu)方案時，性能優(yōu)化的點(diǎn)也需要提早考慮進(jìn)去,，這就體現(xiàn)出一個程序員的技術(shù)功底了,。

什么時候開始有性能優(yōu)化的需求，往往都是從發(fā)現(xiàn)問題開始,，然后分析問題原因及背景,，進(jìn)而尋找最優(yōu)解決方案，最終解決問題,，這也是日常工作中常會用到的處理方式,。