為什麼?

Android系統每個16ms發出VSYNC訊號,觸發對UI的渲染,要想達到介面流暢,必須實現60fps,也就意味著大多數的操作必須在16ms完成.

除了上面界面過於復雜導致渲染不能及時完成之外,還存在過度繪製問題.所謂過度繪製就是某個像素在同一幀的時間內被繪製多次.在多層次的UI介面中,如果不可見的UI也在進行繪製,那麼這些重合區域的像素就會被繪製多次,從而浪費大量的CPU和GPU資源.過度繪製也發生在背景重疊的情況下,例如Layout中有自己的背景,同時子View中又有自己的背景.

如何檢測?

使用HierarchyViewer來查找Activity中的佈局是否過於複雜
在開發者選項中開啟Show GPU Overdraw選項進行觀察是否存在過度繪製
##在開發者選項中選擇Profile GPU Rendering,選取On screen as bar
#使用TraceView觀察CPU執行情況

如何最佳化?

減少佈局的層級,合理的使用include,merge,ViewStub
自訂元件的onDraw()中避免大量創建臨時物件,例如String,以免頻繁觸發GC
自訂元件的onDraw()中,考慮使用canvas.clipRect()繪製需要被繪製的區域
#物件ListView這樣的元件容器,考慮使用convertView,使用ViewHolder,
#考慮使用效能較高的元件,例如推薦使用RecycleView來取代ListView,使用staticlayout來實現自動換行

#2.記憶體最佳化

##為什麼?

資源總是有限的,內存同樣也是一種資源.在Android當中,過度的/不恰當佔用內存資源,會導致應用頻繁被殺死,最終也會影響使用者的整體體驗.任何一名開發者,都應該將節省記憶體牢記心中.

如何檢測?

#如何最佳化?

合理的使用多進程,例如像音樂播放器類別,可以分為主進程和播放進程
使用非同步隊列時考慮有界隊列
如果你能明確知道HashMap的大小,那就再初始化時為其製定容量

3.電力最佳化

為什麼?

#電量是行動裝置非常寶貴的資源,身為開發者,有必要為使用者著想,減少電量的消耗.調查顯示通常只有30%左右的電量是被程式核心的功能所消耗,比如界面渲染,剩下的70%則是被上報資料,位置更新,後台通知所消耗.

如何偵測?

手機選項中透過檢視APP的電量消耗的統計數據
使用Battery Historian Tool來查看詳細的電量消耗

#如何最佳化?

##減少喚醒螢幕的次數與持續的時間,正確的使用WakeLock.
延遲非必須的操作到充電狀態時,比如日誌上報完全可以在夜間充電時完成,這點可以結合JobScheduler使用
使用感測器擷取資料時,一旦不需要記得取消註冊.
#減少網路通訊,合併通訊.
#合理使用定位功能,減少位置更新頻率以及根據實際情況使用不同精度的定位需求

4.網路最佳化

為什麼?

現在App幾乎都需要連網操作,做好網路優化一方面可以提高體驗,另一方面可以減少流量和電量的損耗.另外,無論是對用戶還是網絡服務提供者,網絡同樣是一種資源,任何開發者都不應該假設網絡資源是無限制的.

如何偵測?

使用Android Studio裡的Network Traffic Tools來檢視網路要求
使用Android Studio中的Monitor
#使用Fidder或Charles等抓包工具分析網路封包

如何最佳化?

5.啟動最佳化

#為什麼?

啟動優化看起來並不是那麼必要,但從心理學角度而言,越快的啟動速度往往給用戶以性能好,高效可靠的心理暗示,這就很容易讓用戶對其產生好感,為你後面打動用戶留下了餘地.

如何檢測?

使用adb shell am start -W [packageName]/[packageName.MainActivity]測量冷啟動時間

如何最佳化?

Activity的onCreate()中減少複雜且耗時的操作
Application的onCreate(),attachBaseContext ()中同樣減少複雜和耗時的操作,但是對於許多App在此處會執行大量組件和服務的初始化操作,如果可能考慮並行初始化
提供自訂啟動視窗,例如將一張圖片透過設定主題的方式顯示為啟動視窗.
最佳化佈局

##6.體積最佳化

為什麼?

#對使用者而言,無論是使用者空間或網路,亦或是時間,都是資源.體積優化就是為用戶節省資源的重要一環.如果你現在做的是SDK類產品,那麼體積優化同樣重要.

#如何檢測?

#使用Android Lint檢查沒有使用的資源

#如何最佳化?

減少不必要的依賴函式庫/Jar,在滿足需求的前提下優先選擇體積小的.
#使用Proguard工具進行程式碼瘦身,優化,混淆
減少so檔案的數量,根據實際情況提供so檔案
使用Gradle中的shrinkResource來將無用的程式碼和資源排除在APK安裝包之外
減少圖片資源的大小,考慮圖片壓縮或使用Vertor Drawable取代png/jpeg
有選擇的提供對應解析度的圖片資源
復用已經存在的圖片,多用透過程式碼對已有圖片進行變換的方式實現復用
使用外掛化技術(如果專案簡單就不要使用)

7.效能最佳化

7.效能最佳化

#如何偵測?

程式碼Review

##如何最佳化?
##任務並行化,對可能的任務進行並行操作,多藉助執行緒池而非直接使用執行緒
如何需要序列化資料,優先考慮Android自身提供的而非Java提供的Serializable
#選擇適當的資料結構,明確List/Set/Map/Stack操作的複雜度
使用Android提供更有效率的容器,例如使用ArrayMap來代替HashMap,此外還是有SparseBoolMap,SparseIntMap,SparseLongMap
使用靜態常數代替Enum類型,可以減少至少兩倍的記憶體消耗
使用物件池技術,例如提供想String一樣的物件池
使用快取技術
#字串拼接操作有限使用StringBuilder
對相關的演算法和邏輯進行最佳化,減少不必要的流程

採用JNI ,對計算量較大的邏輯將其協程so檔,如圖片處理

業務優化#########除了上述比較通用的優化方案之外,也應該花點時間放在業務優化上.很多時候,迫於時間壓迫,當前實現業務的方案並非最優.比如為了支持多張圖片上傳,很多人直接使用串行操作,儘管這樣做容易實現,但是卻並非最佳.###

由於每個產品的業務並不相同,也就很難有通用的優化方案,這裡又兩個目標值得思考:

如果有可能,串行業務並行化
如果有可能,簡化業務流程.將一大象關進冰箱的方法就是打開冰箱,將大象放進去,最後關閉冰箱。

之所以把業務優化放在最後的根本原因是業務優化的風險較高,需要團隊的整體配合來完成。

Android中圖片有四種顏色格式,分別是

對於Android應用優化大全

預設的是# ARGB_8888,其中ARGB分別代表的是透明度,紅色,綠色,藍色,每個值分別用8位元來記錄,也就是一個像素會佔用4byte,共32位元。
而ARGB_4444和以上很類似,但是每個值分別用4位來記錄,也就是一個像素會佔用2byte,共16位。
RGB_565則分別用5位元,6位元,5位元來記錄每個值,不存在透明度,每個像素會佔用2byte,共16位元.
ALPHA_8#:此像素只儲存透明度,會佔用1byte,共8位元。
在實際應用中而言,值推薦使用ARGB_8888#以及RGB_565#,如果你不需要透明度,那麼就選擇RGB_565,可以減少一半的記憶體佔用。