抖音、騰訊、京東、阿里等大廠性能優化方案總結（含專案實戰分析及視頻）-有解無憂

?現在安卓系統無論是性能還是體驗上其實都不輸于iOS，只是因為手機廠商多而雜，他們會改原始碼，自定義系統，最后又過一遍不同開發水平工程師的手，導致很多手機即使在機器上面的跑分非常高，里面的APP運行也有卡頓現象，

而且這種卡頓會隨著產品的更新迭代，功能的越發復雜，UI頁面的越發豐富，變得更加嚴重，

但是，產品功能的更新需求，新功能的開發和UI的豐富都是用戶的需求，是不可逆的趨勢，在這樣的情況下，優秀的性能優化人才一直是幾大頭部互聯網公司高價競聘的物件，

今天在這里根據我自己多年的開發經驗來做一下安卓性能優化方案的總結，

性能優化的目的

流暢（解決：卡頓）
穩定（解決：記憶體溢位、崩潰）
低耗損（解決：耗電快、流量大、網路慢）
小安裝包（解決：APK過大）

性能優化的方向

布局優化
繪制優化
網路優化
APK優化
記憶體優化
卡頓優化
耗電優化
ListView/RecycleView及Bitmap/圖片優化
資料庫SQLite優化
啟動優化
資料結構優化
穩定性優化

性能優化方案

布局優化

本質： 減少View的層級，提高測量、布局和繪制的速度，

常用方案：

優先選擇LinearLayout布局可以減少View的層級（注意相同組件可能RelativeLayout繪制時間長）；
使用 < include > 標簽抽取常用的布局組件中的共同部分（便于復用）；
用 < ViewStub > 標簽加載不常用的布局，延遲加載（需要的時候在activity中加載出來）；
用 < Merge > 標簽減少布局的嵌套層次

繪制優化

本質：View的onDraw方法要避免執行大量的操作

常用方案：

onDraw中不要創建新的區域物件（避免產生大量的臨時物件占用過多記憶體）；

onDraw方法中不要做耗時的任務（盡量降低onDraw方法中的復雜度）

網路優化

本質： 減少流量消耗、電量消耗、用戶等待時間，提高用戶體驗，

常用方案：

盡量減少網路請求，能夠合并的就盡量合并
避免DNS決議，根據域名查詢可能會耗費上百毫秒的時間，也可能存在DNS劫持的風險，可以根據業務需求采用增加動態更新IP的方式，或者在IP方式訪問失敗時切換到域名訪問方式，
大量資料的加載采用分頁的方式
網路資料傳輸采用GZIP壓縮
加入網路資料的快取，避免頻繁請求網路
上傳圖片時，在必要的時候壓縮圖片

APK優化

本質： 減少安裝包體積，

常用方案：

減少應用中不必要的資源檔案，比如圖片，在不影響APP效果的情況下盡量壓縮圖片，有一定的效果
在使用了SO庫的時候優先保留v7版本的SO庫，刪掉其他版本的SO庫，
res資源優化
代碼優化
lib資源優化
assets資源優化
代碼混淆
插件化
7z極限壓縮

PS：詳細具體的操作實作實作原理，后文另外有專門的分析，

記憶體優化

本質： 避免記憶體泄漏、擴大記憶體，

常用方案（從不同方向討論）：

擴大記憶體：

一個是在清單檔案中的Application下添加largeHeap="true"這個屬性，另一個就是同一個應用開啟多個行程來擴大一個應用的總記憶體空間，
第二種方法其實就很常見了，比方說我使用過個推的SDK，個推的Service其實就是處在另外一個單獨的行程中，

記憶體泄漏（多方向討論）：

靜態變數導致的記憶體泄漏

辦法：將內部類設為靜態內部類或獨立出來；使用context.getApplicationContext()，

單例模式導致的記憶體泄漏

方案：傳參context.getApplicationContext()，

屬性影片導致的記憶體泄漏

方案：在Activity.onDestroy()中呼叫Animator.cancel()停止影片，

Handler導致的記憶體泄漏

方案：使用靜態內部類+WeakReference弱參考；當外部類結束生命周期時清空訊息佇列，

執行緒導致的記憶體泄漏

方案：將AsyncTask和Runnable設為靜態內部類或獨立出來；在執行緒內部采用弱參考保存Context參考，

資源未關閉導致的記憶體泄漏

方案：在Activity銷毀的時候要及時關倍訓者注銷，例如：

① BraodcastReceiver：呼叫unregisterReceiver()注銷；

②Cursor，Stream、File：呼叫close()關閉；

③Bitmap：呼叫recycle()釋放記憶體（2.3版本后無需手動），

Adapter導致的記憶體泄漏

方案：在構造Adapter時使用快取的convertView，

WebView導致的記憶體泄漏

方案：其實避免WebView導致記憶體泄漏的最好方法就是讓WebView所在的Activity處于另一個行程中，當這個Activity結束時殺死當前WebView所處的行程即可，我記得阿里釘釘的WebView就是另外開啟的一個行程，應該也是采用這種方法避免記憶體泄漏，

集合類泄漏

方案：在onDestry時回收不需要的集合，

PS：為什么會導致泄漏，以及泄漏的具體情況，更多原理，后文另外有專門的分析整理，

卡頓優化

本質： 優化UI、提高啟動跳轉還有回應的速度，

常用方案：

不在主執行緒進行網路訪問/大檔案的IO操作
繪制UI盡量減少繪制UI層次；減少不必要的view嵌套，可以用Hierarchy Viewer工具來檢測，后面會詳細講；
當布局是用的FrameLayout，可以把它改成merge，可以避免自己的幀布局和系統的ContentFrameLayout幀布局重疊造成重復計算(measure和layout)
提高顯示速度,使用ViewStub：當加載的時候才會占用，不加載的時候就是隱藏的，僅僅占用位置，
在view層級相同的情況下，盡量使用 LinerLayout而不是RelativeLayout；因為RelativeLayout在測量的時候會測量二次，而LinerLayout測量一次，可以看下它們的原始碼；
洗掉控制元件中無用的屬性;
布局復用.比如listView 布局復用
盡量避免過度繪制（overdraw）,比如：背景經常容易造成過度繪制，由于我們布局設定了背景，同時用到的MaterialDesign的主題會默認給一個背景，這時應該把主題添加的背景去掉；還有移除
XML 中非必須的背景
自定義View優化，使用 canvas.clipRect()來幫助系統識別那些可見的區域，只有在這個區域內才會被繪制，也是避免過度繪制．
啟動優化,啟動速度的監控，發現影響啟動速度的問題所在，優化啟動邏輯，提高應用的啟動速度，比如閃屏頁面，合理優化布局，加載邏輯優化，資料準備.
合理的重繪機制，盡量減少重繪次數，盡量避免后臺有高的 CPU 執行緒運行，縮小重繪區域，

耗電優化

本質： 減少電量消耗，

常用方案：

合理的使用wake_lock鎖，wake_lock鎖主要是相對系統的休眠(這里就是為了省電，才做休)而言的，意思就是我的程式給CPU加了這個鎖那系統就不會休眠了，這樣做的目的是為了全力配合我們程式的運行，有的情況如果不這么做就會出現一些問題，比如微信等及時通訊的心跳包會在熄屏不久后停止網路訪問等問題，所以微信里面是有大量使用到了wake_lock鎖，
使用jobScheduler2，集中處理一些網路請求，有些不用很及時的處理可以放在充電的時候處理，比如，圖片的處理，APP下載更新等等；
計算優化，避開浮點運算等，
資料在網路上傳輸時，盡量壓縮資料后再傳輸，建議用FlatBuffer序列化技術，這個比json效率高很多倍，不了解FlatBuffer，建議找資料學習一下，

Android性能優化總結

理論方面

Android的性能優化牽扯的知識點很多，除了上面講過的這些常用解決方案，底層原理也值得我們深入探討，此外還有性能監控還有工具的使用，

一篇文章難以詳盡，我根據自己多年的Android開發經驗把這些性能優化的底層原理還有各種問題的解決方案等都整理成了PDF檔案，