Android效能優化----卡頓優化
阿新 • • 發佈：2020-07-28
### 前言
無論是啟動，記憶體，佈局等等這些優化，最終的目的就是為了應用不卡頓。應用的體驗性好壞，最直觀的表現就是應用的流暢程度，使用者不知道什麼啟動優化，記憶體不足，等等，應用卡頓，那麼這個應用就不行，被解除安裝的概率非常大。所以說為了保證使用者留存率，卡頓優化是非常非常的重要。在這篇文章，咱們不討論是什麼原因造成卡頓，其實在前面寫的效能優化文章中，都是造成卡頓的原因，需要需要做好卡頓優化，最好從頭開始一步一步來處理。今天我們主要是介紹一些針對卡頓檢測的一些工具使用。
### 檢測卡頓常用工具
#### Systrace
Systrace這個工具在《佈局優化》一章節中已經介紹過了，這裡就不在贅述。地址：https://www.cnblogs.com/huangjialin/p/13353541.html
#### StrictMode的使用
StrictMode，嚴苛模式。StrictMode是在Android開發過程中不可缺少的效能檢測工具，它能夠檢測出在開發過程中不合理的程式碼塊，非常方便。
##### 策略分類
StrictMode分為執行緒策略（ThreadPolicy）和虛擬機器策略（VmPolicy）
##### 使用方式
``` stylus
//開啟Thread策略模式
StrictMode.setThreadPolicy(new StrictMode.ThreadPolicy.Builder()
.detectNetwork()//監測主執行緒使用網路io
// .detectCustomSlowCalls()//監測自定義執行緩慢函式
// .detectDiskReads() // 檢測在UI執行緒讀磁碟操作
// .detectDiskWrites() // 檢測在UI執行緒寫磁碟操作
.detectAll()
.penaltyLog() //寫入日誌
.penaltyDialog()//監測到上述狀況時彈出對話方塊
.build());
//開啟VM策略模式
StrictMode.setVmPolicy(new StrictMode.VmPolicy.Builder()
// .detectLeakedSqlLiteObjects()//監測sqlite洩露
// .detectLeakedClosableObjects()//監測沒有關閉IO物件
// .setClassInstanceLimit(MainActivity.class, 1) // 設定某個類的同時處於記憶體中的例項上限，可以協助檢查記憶體洩露
// .detectActivityLeaks()
.detectAll()
.penaltyLog()//寫入日誌
.build());
```
上面基本都註釋好了，這裡就不在一一說明了。如果我們在開發過程中，能夠通過StrictMode這個工具類來規避掉這些問題，那麼將會大大的減少很多效能相關的問題。
#### BlockCanary使用
我們先看看怎麼使用，然後在看BlockCanary
依賴
``` stylus
debugImplementation 'com.github.bzcoder:blockcanarycompat-android:0.0.4'
```
在application中
``` stylus
BlockCanary.install(mContext, appBlockCanaryContext).start();
```
appBlockCanaryContext類
``` stylus
/**
* BlockCanary配置的各種資訊
*/
public class AppBlockCanaryContext extends BlockCanaryContext {
/**
* Implement in your project.
*
* @return Qualifier which can specify this installation, like version + flavor.
*/
public String provideQualifier() {
return "unknown";
}
/**
* Implement in your project.
*
* @return user id
*/
public String provideUid() {
return "uid";
}
/**
* Network type
*
* @return {@link String} like 2G, 3G, 4G, wifi, etc.
*/
public String provideNetworkType() {
return "unknown";
}
/**
* Config monitor duration, after this time BlockCanary will stop, use
* with {@code BlockCanary}'s isMonitorDurationEnd
*
* @return monitor last duration (in hour)
*/
public int provideMonitorDuration() {
return -1;
}
/**
* Config block threshold (in millis), dispatch over this duration is regarded as a BLOCK. You may set it
* from performance of device.
*
* @return threshold in mills
*/
public int provideBlockThreshold() {
return 500;
}
/**
* Thread stack dump interval, use when block happens, BlockCanary will dump on main thread
* stack according to current sample cycle.
*
* Because the implementation mechanism of Looper, real dump interval would be longer than * the period specified here (especially when cpu is busier). *
* * @return dump interval (in millis) */ public int provideDumpInterval() { return provideBlockThreshold(); } /** * Path to save log, like "/blockcanary/", will save to sdcard if can. * * @return path of log files */ public String providePath() { return "/blockcanary/"; } /** * If need notification to notice block. * * @return true if need, else if not need. */ public boolean displayNotification() { return true; } /** * Implement in your project, bundle files into a zip file. * * @param src files before compress * @param dest files compressed * @return true if compression is successful */ public boolean zip(File[] src, File dest) { return false; } /** * Implement in your project, bundled log files. * * @param zippedFile zipped file */ public void upload(File zippedFile) { throw new UnsupportedOperationException(); } /** * Packages that developer concern, by default it uses process name, * put high priority one in pre-order. * * @return null if simply concern only package with process name. */ pub