前言

講解的內(nèi)容大體包含，異步優(yōu)化，啟動(dòng)優(yōu)化，卡頓優(yōu)化，內(nèi)存優(yōu)化，ARTHook, 監(jiān)控耗時(shí)盲區(qū)，網(wǎng)絡(luò)，電量，瘦身及APP容災(zāi)方案等

性能優(yōu)化的系統(tǒng)學(xué)習(xí)方法

330頁(yè) PDF Android進(jìn)階核心筆記(對(duì)應(yīng)思維導(dǎo)圖)

性能優(yōu)化對(duì)應(yīng)學(xué)習(xí)思維導(dǎo)圖(對(duì)應(yīng)核心筆記)

性能優(yōu)化學(xué)習(xí)資料視頻(系統(tǒng)，對(duì)應(yīng)導(dǎo)圖和筆記)

• 學(xué)習(xí)資料

• 學(xué)習(xí)視頻

既然我們選擇了學(xué)習(xí)Android，那么我們能做的就是不斷提升自身的能力，我學(xué)每一塊都會(huì)自己做一張導(dǎo)圖，然后對(duì)于去找學(xué)習(xí)資料，視頻。這樣我學(xué)習(xí)下來，不僅有程序，有系統(tǒng)，學(xué)習(xí)效率還高。“精”一個(gè)點(diǎn)，就努力做到最好，這就是我對(duì)于Android的學(xué)習(xí)態(tài)度。如果也是走上了Android這條路，如果現(xiàn)在的你對(duì)性能優(yōu)化這塊感興趣，但是沒有一個(gè)明確的學(xué)習(xí)思路，我給你分享我實(shí)戰(zhàn)經(jīng)驗(yàn)總結(jié)，幫助你少走一點(diǎn)彎路。

有需要的朋友 私信【進(jìn)階】我免費(fèi)分享給你，當(dāng)然還是老樣子，如果你覺得對(duì)你有幫助，希望你能多多，點(diǎn)贊，轉(zhuǎn)發(fā)+關(guān)注，你們的支持就是我繼續(xù)的動(dòng)力。還有其他Android方面想學(xué)習(xí)的知識(shí)，可以留言。最多的我會(huì)發(fā)文章，并且分享對(duì)應(yīng)的資料給大家。

1.簡(jiǎn)介

本篇文章是該系列文章中的第一篇，主要介紹的是在一些一線大廠的實(shí)際項(xiàng)目中，如果APP發(fā)生卡頓是如何進(jìn)行定位問題的。主要介紹 程序的耗費(fèi)時(shí)間

2.測(cè)量時(shí)間方式

首先，如果要查看頁(yè)面加載花費(fèi)的時(shí)間有3種方式

adb命令查看

手動(dòng)打點(diǎn)的方式

traceView

3.adb命令

只需要一行命令，就可以查看加載頁(yè)面的時(shí)間。

adb shell am start -W 包名/包名.Activity復(fù)制代碼

使用后會(huì)顯示

ThisTime: 代表啟動(dòng)最后一個(gè)Activity的耗時(shí)

TotalTime: 代表啟動(dòng)所有的Activity的耗時(shí)

WaitTime: 代表AMS啟動(dòng)所有的Activity的耗時(shí)

注意點(diǎn)：該命令只能是獲取配置了的Activity, 其他的無效，因?yàn)锳ndroid組件中有個(gè) exported 屬性，沒有intent-filter時(shí)exported 屬性默認(rèn)為false，此組件只能由本應(yīng)用用戶訪問，配備了intent-filter后此值改變?yōu)閠rue，允許外部調(diào)用。

缺點(diǎn)： adb命令只能查看配置了的Activity，其他的無法查看，并且也無法精準(zhǔn)的查看其方法具體耗費(fèi)的時(shí)間，所以因?yàn)槠渚窒扌?并不能很好的解決我們問題，我們采用手動(dòng)打點(diǎn)的方式查看。

4.手動(dòng)打點(diǎn)

先看代碼

public class MyApplication extends Application { @Override public void onCreate() { super.onCreate(); initBugly(); initBaiduMap(); initJPushInterface(); initShareSDK(); ... } private void initBugly() throws InterruptedException { Thread.sleep(1000); // 模擬耗費(fèi)的時(shí)間 } private void initBaiduMap() throws InterruptedException { Thread.sleep(2000); // 模擬耗費(fèi)的時(shí)間 } private void initJPushInterface() throws InterruptedException { Thread.sleep(3000); // 模擬耗費(fèi)的時(shí)間 } private void initShareSDK() throws InterruptedException { Thread.sleep(500); // 模擬耗費(fèi)的時(shí)間 }}

代碼不用我說，項(xiàng)目中很常見，現(xiàn)在的問題是APP啟動(dòng)加載很慢, 那么如何精準(zhǔn)的查詢到具體耗時(shí)的方法？

long startTime = System.currentTimeMillis(); initBugly(); Log.d("lybj", "initBugly()方法耗時(shí)："+ (System.currentTimeMillis() - startTime)); long startTime = System.currentTimeMillis(); initBaiduMap(); Log.d("lybj", "initBaiduMap()方法耗時(shí)："+ (System.currentTimeMillis() - startTime)); ...

這樣可以嗎？當(dāng)然不行，耦合性太大，每一個(gè)方法都加，那么測(cè)試完了，刪除代碼也是個(gè)體力活，一不小心刪錯(cuò)一個(gè)，就會(huì)造成災(zāi)難性的問題，在實(shí)際項(xiàng)目中，比如中石油的一些項(xiàng)目，就會(huì)采用 AOP 的方式來測(cè)量方法的耗費(fèi)時(shí)長(zhǎng)。

4.1 AOP

AOP : Aspect Oriented Programming的縮寫，意為：面向切面編程

優(yōu)點(diǎn)：

針對(duì)同一問題的統(tǒng)一處理

無侵入添加代碼

這里我們使用的是Aspectj

4.2 Aspectj 的使用

1.添加依賴

根目錄的build.gradle里

buildscript { ... dependencies { ... classpath 'com.hujiang.aspectjx:gradle-android-plugin-aspectjx:2.0.0' }}

app項(xiàng)目的build.gradle及新建的module的build.gradle里添加

apply plugin: 'android-aspectjx'dependencies { ... implementation 'org.aspectj:aspectjrt:1.8.+'}

2.創(chuàng)建切面

@Aspectpublic class PerformanceAop { @Around("call(* com.bj.performance.MyApplication.**(..))") public void getTime(ProceedingJoinPoint joinPoint){ long startTime = System.currentTimeMillis(); String methodName = joinPoint.getSignature().getName(); try { joinPoint.proceed(); } catch (Throwable throwable) { throwable.printStackTrace(); } Log.d("lybj", methodName + "方法耗時(shí)："+ (System.currentTimeMillis() - startTime)); }}

看，根本無需修改任何工程代碼，就可以獲取運(yùn)行時(shí)長(zhǎng)了，點(diǎn)擊運(yùn)行顯示

AspectJ語(yǔ)法參考

缺點(diǎn)： 如果項(xiàng)目比較龐大，上百個(gè)方法，總不能全部打掉，然后一個(gè)一個(gè)的分析到底是哪個(gè)地方運(yùn)行時(shí)間過長(zhǎng)吧，所以我們需要一個(gè)比較直觀的工具，一眼就能看到具體哪個(gè)方法運(yùn)行時(shí)間過長(zhǎng)。

5. traceView的使用

5.1 特點(diǎn)

圖形的形式展示其執(zhí)行時(shí)間調(diào)用棧

信息全面，包含所有進(jìn)程

5.2 使用方式

Debug.startMethodTracing("文件名");Debug.stopMethodTracing();

在代碼中相應(yīng)位置的地方打入埋點(diǎn)即可， startMethodTracing 有3個(gè)構(gòu)造參數(shù)分別是

tracePath：文件名/路徑

bufferSize：文件的容量大小

flag：TRACE_COUNT_ALLOCS 只有默認(rèn)的這一種

代碼運(yùn)行完成后，會(huì)在

mnt/sdcard/Android/data/包名/files

生成一個(gè).trace后綴的文件，可以用Profiler添加打開它。

當(dāng)然也可以使用Profiler的錄制功能，但是因?yàn)橐獪y(cè)量啟動(dòng)時(shí)間，點(diǎn)擊錄制手速并不會(huì)那么的精準(zhǔn)，所以采用埋點(diǎn)的方式獲取trace文件進(jìn)行分析。

5.3 性能分析

打開文件后為上圖所示

5.4 時(shí)間模式

上圖標(biāo)簽 1 所示：wallclock time 和 cpu time

Wall Clock Time：從進(jìn)程開始運(yùn)行到結(jié)束，時(shí)鐘走過的時(shí)間，這其中包含了進(jìn)程在阻塞和等待狀態(tài)的時(shí)間。

Thread Time ：就是CPU執(zhí)行用戶指令所用的時(shí)間。

注意：如果線程A執(zhí)行函數(shù)b，但是因?yàn)楹瘮?shù)b加了鎖，線程A進(jìn)入等待狀態(tài)，那么wallclock time也是要計(jì)算時(shí)間的，而Thread time則只是計(jì)算CPU花費(fèi)在它身上的時(shí)間。

一般根據(jù)經(jīng)驗(yàn)來講wall duration時(shí)間久說明耗時(shí)多，然后看Thread time 這個(gè)值說明cpu花費(fèi)在其身上的時(shí)間多不多。不多的話基本可以直接異步(因?yàn)椴粨屨糃PU)多的話需要合理調(diào)度好執(zhí)行順序。

5.5 Call Chart

上圖標(biāo)簽 2 所示：Call Chart

它的作用就是可以很直觀的查看到底是哪里耗時(shí)比較久，x軸為調(diào)用的時(shí)間線，越寬的表示耗時(shí)越久，y軸為調(diào)用的深度，也就是調(diào)用的子方法。父類在最上面，很明顯initBottomTab()方法調(diào)用是最耗時(shí)的。

鼠標(biāo)懸浮可以查看耗費(fèi)時(shí)間，雙擊可以跳轉(zhuǎn)到相應(yīng)代碼

• 橙色：系統(tǒng)方法
• 藍(lán)色：第三方API(包括java語(yǔ)言的api)
• 綠色：App自身方法

簡(jiǎn)易圖如下：

5.6 Flame Chart

上圖標(biāo)簽 3 所示：Flame Chart 又稱之為火焰圖

y 軸表示調(diào)用棧，每一層都是一個(gè)函數(shù)。調(diào)用棧越深，火焰就越高，頂部就是正在執(zhí)行的函數(shù)，下方都是它的父函數(shù)。 x 軸表示抽樣數(shù)，如果一個(gè)函數(shù)在 x 軸占據(jù)的寬度越寬，就表示它被抽到的次數(shù)多，即執(zhí)行的時(shí)間長(zhǎng)。注意，x 軸不代表時(shí)間，而是所有的調(diào)用棧合并后，按字母順序排列的。

火焰圖就是看頂層的哪個(gè)函數(shù)占據(jù)的寬度最大。只要有"平頂"(plateaus)，就表示該函數(shù)可能存在性能問題。

練習(xí)1：

假如火焰圖如上圖所示，我們需要分析哪個(gè)函數(shù)嗎？

答：最頂層的函數(shù)g()占用 CPU 時(shí)間最多。d()的寬度最大，但是它直接耗用 CPU 的部分很少。b()和c()沒有直接消耗 CPU。因此，如果要調(diào)查性能問題，首先應(yīng)該調(diào)查g()，其次是i()。 另外，從圖中可知a()有兩個(gè)分支b()和h()，這表明a()里面可能有一個(gè)條件語(yǔ)句，而b()分支消耗的 CPU 大大高于h()。

與Call Chart區(qū)別

方法D對(duì)B(B1、B2和B3)進(jìn)行多次調(diào)用，其中一些調(diào)用B對(duì)C(C1和C3)進(jìn)行調(diào)用。如果用Call Chart表示，則為

因?yàn)锽1、B2和B3共享相同的序列調(diào)用者(A→D→B)聚合,如下所示。同樣,C1和C3聚合,因?yàn)樗鼈児蚕硐嗤男蛄姓{(diào)用者(A→D→B→C)注意不包括C2, 因?yàn)樗胁煌恼{(diào)用者序列(A→D→C)。

那么如果使用火焰圖，則表示：

也就是說，收集相同的調(diào)用序列的相同方法被收集并表示為火焰圖中的一個(gè)較長(zhǎng)的欄(而不是將它們顯示為多個(gè)更短的條)

5.7 Top Down

上圖標(biāo)簽 4 所示： Top Down 顯示一個(gè)函數(shù)調(diào)用列表，在該列表中展開函數(shù)節(jié)點(diǎn)會(huì)顯示函數(shù)的被調(diào)用方

看上圖右邊區(qū)域：

• Self:方法調(diào)用用于執(zhí)行自己的代碼而不是它的子類的時(shí)間量。
• Children：方法調(diào)用花費(fèi)的時(shí)間用于執(zhí)行其被調(diào)用者，而不是其自己的代碼
• Total：方法的Self和Children的時(shí)間的總和。這表示應(yīng)用程序執(zhí)行方法調(diào)用的總時(shí)間量

5.8 Bottom Up

上圖標(biāo)簽 5 所示： Bottom Up 顯示一個(gè)函數(shù)調(diào)用列表，在該列表中展開函數(shù)節(jié)點(diǎn)將顯示函數(shù)的調(diào)用方。

Bottom Up選項(xiàng)卡對(duì)于那些消耗最多(或最少)CPU時(shí)間的方法的排序方法很有用。可以檢查每個(gè)節(jié)點(diǎn)，以確定哪些調(diào)用者在調(diào)用這些方法上花費(fèi)最多的CPU時(shí)間。

• Self:方法調(diào)用用于執(zhí)行自己的代碼而不是它的子類的時(shí)間量。
• Children：方法調(diào)用花費(fèi)的時(shí)間用于執(zhí)行其被調(diào)用者，而不是其自己的代碼
• Total：方法的Self和Children的時(shí)間的總和。這表示應(yīng)用程序執(zhí)行方法調(diào)用的總和

簡(jiǎn)略圖如下

缺點(diǎn)： 在項(xiàng)目中用到的，最多的還是Call Chart 和 Top Down, 但是traceView的原理就是抓取所有線程的所有函數(shù)里的信息，所以會(huì)導(dǎo)致程序變慢， 所以常用的是SysTrace

SysTrace 作者用的不多，有興趣的朋友可以自行百度，用法和traceView的使用差不多，就不在分析了

總結(jié)

以上是生活随笔為你收集整理的android 北斗定位代码_大牛三步教你解决，BAT资深APP性能优化系列-卡顿定位问题,收藏哦的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。