AndroidApp應(yīng)用性能優(yōu)化總結(jié)

最近大半年的時(shí)間里，大部分投在了某國內(nèi)新能源汽車的某款A(yù)ndroidApp開發(fā)上。
由于該App是該款車上，常用+重點(diǎn)應(yīng)用。所以車廠對(duì)應(yīng)用性能的要求比較高。
主要包括：

• 應(yīng)用冷啟動(dòng)達(dá)到***ms。
• 應(yīng)用熱(溫)啟動(dòng)達(dá)到***ms
• 應(yīng)用內(nèi)畫面切換響應(yīng)達(dá)到**ms
• 應(yīng)用內(nèi)動(dòng)效/動(dòng)畫/車模等交互時(shí)，畫面不能有延遲感等等。
• 應(yīng)用不能有內(nèi)存泄露，內(nèi)存穩(wěn)定在**MB
  諸如上面的內(nèi)容，還有一些，就不詳細(xì)列出來了。

因?yàn)橹皼]有直接做過AndroidApp開發(fā)，之前大部分時(shí)間在做Framework/System開發(fā)。所以對(duì)于應(yīng)用的性能優(yōu)化，相當(dāng)于站在系統(tǒng)角度，重新研究了一遍。

經(jīng)歷大半年時(shí)間后，曾經(jīng)作為系統(tǒng)側(cè)不理解應(yīng)用開發(fā)人員的某些東西，突然理解了。也更加覺得，如果在應(yīng)用開發(fā)前能有一個(gè)好的整體架構(gòu)設(shè)計(jì)，那很多事會(huì)半功倍。

這里總結(jié)一下，Android應(yīng)用總結(jié)時(shí)用到的一些方法。

啟動(dòng)性能優(yōu)化

冷啟動(dòng)和溫啟動(dòng)

Android應(yīng)用啟動(dòng)，主要指啟動(dòng)App到其顯示出第一幀的時(shí)間。大類上可以分為冷啟動(dòng)、熱啟動(dòng)兩種（細(xì)分的話，還有一種叫溫啟動(dòng)），兩種方式主要區(qū)別在于 App的進(jìn)程是否已被加載。
簡單理解
冷啟動(dòng)： Android系統(tǒng)Fork進(jìn)程，加載App資源，然后Activity被啟動(dòng)走Activity的生命周期(onCreate、onStart、onResume)等等。
熱啟動(dòng): AndroidApp的進(jìn)程已經(jīng)存在，App資源已經(jīng)加載完成。在這個(gè)前提下，啟動(dòng)App的時(shí)間（App畫面顯示。）

利用Trace加以分析

trace常用來分析啟動(dòng)的優(yōu)化，可以利用AndroidStudio自帶的Profile工具。也可以使用類似如下命令

# 抓取10S Trace，并保存在 /data/misc/perfetto-traces/trace_file.perfetto-trace文件中。
adb shell perfetto -o /data/misc/perfetto-traces/trace_file.perfetto-trace -t 10s sched freq idle am wm gfx view binder_driver hal dalvik camera input res memory

Anroid應(yīng)用執(zhí)行期間（比如啟動(dòng)，比如畫面切換）的動(dòng)作、每步消耗時(shí)間，會(huì)被記錄到Trace中。然后利用AndroidStudio自帶的工具，或者perfetto網(wǎng)站分析Trace。
如下圖，通過perfetto網(wǎng)站分析的Trace內(nèi)容。

分析Trace中主要耗時(shí)點(diǎn)，針對(duì)主要耗時(shí)點(diǎn)一般可以考慮如下優(yōu)化方向：

• 資源（比如圖片）加載時(shí)間是否過長？資源是否可以壓縮。
• 布局類型是否合理，布局內(nèi)容中是否可以寫死某些內(nèi)容避免動(dòng)態(tài)計(jì)算
• 布局中的資源是否可以用時(shí)加載（用于優(yōu)化啟動(dòng)速度）
• 布局嵌套是否過多？
• 是否可以利用多核特性（比如把操作分散到其他線程中，并行處理）
• 是否存在重復(fù)操作？
• 父類中是否存在多余的操作？
• 是否利用了緩存機(jī)制，讓某些對(duì)象（比如View）不會(huì)反復(fù)重新創(chuàng)建？
• Log日志輸出是否合理，是否過于頻繁？

如果系統(tǒng)提供的Trace不足，可以在應(yīng)用代碼中加入自定義Trace.

 Trace.beginSection("TAG")Trace.endSection();

通過仔細(xì)分析Trace，可以對(duì)應(yīng)用性能做很大的提升。

利用Log分析

這里的Log指，應(yīng)用自身的 Log，以及Android系統(tǒng)的Log。
應(yīng)用自身的 Log主要包括：

• Activity生命周期的Log
• 與外部交互的Log，比如外部接口是否耗時(shí)的分析。
• 加載某些比較大資源的log。

Android系統(tǒng)Log主要包括：

• 性能Log，events分區(qū)的log 。通過logcat -b events 輸出。性能Log中，會(huì)記錄Activity每一個(gè)階段的耗時(shí)。
• WMS、AMS、IMS的log，抓取windowmanageservice，和ActivitymanagerService的log，InputManagerservice的log，用來幫助分析應(yīng)用系統(tǒng)。

其他優(yōu)化手段

在通過Trace和Log分析應(yīng)用后，對(duì)于某些無法直接優(yōu)化其響應(yīng)速度的內(nèi)容，可以考慮

• 提前加載或初始化：放入Application中提前加載，對(duì)于熱（溫）啟動(dòng)方式有效。
• 異步加載：對(duì)于異步加載的情況下，有些時(shí)候需要使用 占位圖。
• 占位圖：比如加載某個(gè)動(dòng)效時(shí)，動(dòng)效無法立刻顯示。那么使用將動(dòng)效第一幀做成一個(gè)靜態(tài)圖，提前顯示。當(dāng)動(dòng)效加載完成并顯示后，再隱藏占位圖。
• 加入動(dòng)畫效果：比如加入淡入、淡出的效果，單純從視覺上優(yōu)化。

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

內(nèi)存優(yōu)化主要包括

• 應(yīng)用運(yùn)行時(shí)，內(nèi)存是否超過標(biāo)準(zhǔn)（過大）
• 應(yīng)用運(yùn)行時(shí)，內(nèi)存是否存在泄露情況

內(nèi)存優(yōu)化時(shí)，可以考慮幾個(gè)方面

• 縮減App包的大小。因?yàn)锳pp本身資源少了，內(nèi)存自然少。
• 考慮代碼中，是否存在不用的對(duì)象，是否可以用簡單對(duì)象（比如不用Hashmap之類）。當(dāng)然考慮的時(shí)候，也要考慮運(yùn)行速度。
• 利用內(nèi)存分析工具，分析內(nèi)存是否泄露。

比如shark-cli，利用該工具可以分析App是否存在內(nèi)存泄露。

shark-cli -p 包名

上面的命令輸出如下結(jié)果

.....
====================================
HEAP ANALYSIS RESULT
====================================
3 APPLICATION LEAKSReferences underlined with "~~~" are likely causes.
Learn more at https://squ.re/leaks.177 bytes retained by leaking objects
Displaying only 1 leak trace out of 3 with the same signature
....

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

穩(wěn)定性，主要是指App的健壯性。不會(huì)異常崩潰，不會(huì)閃白或者閃黑。
穩(wěn)定性，主要靠對(duì)應(yīng)用進(jìn)行測試，比如測試人員，比如自動(dòng)化工具等等。
工具的話，monkey是比較常見的工具，可以通過monkey模擬用戶的隨機(jī)操作。關(guān)于該用法，網(wǎng)絡(luò)上有很多說明。

Android應(yīng)用的性能優(yōu)化方法，不僅限于本文介紹的這些，還有很多優(yōu)化的方法?？偟膩碚f的話，其實(shí)就是讓應(yīng)用，不做多余的事情、使用恰當(dāng)?shù)馁Y源、提前加載以及充分利用并行。