strictmode android,（十三）Android 性能优化 StrictMode

小酌鸡汤

富贵必从勤苦得，男儿须读五车书。

StrictMode能检测什么呢？

StrictMode主要检测两大问题：线程策略(TreadPolicy)和VM策略(VmPolicy)。

StrictMode的工作原理？

StrictMode最常用于在应用程序的主线程上捕获意外的磁盘或网络访问，在该线程上接收UI操作并进行动画处理。使磁盘和网络操作脱离主线程可以使应用程序更加流畅，响应更快。通过使应用程序的主线程保持响应状态，还可以防止向用户显示ANR对话框。

请注意，即使Android设备的磁盘通常位于闪存中，但许多设备在该内存之上运行文件系统的并发性非常有限。通常情况下，几乎所有磁盘访问都是快速的，但是在某些情况下，某些进程在后台发生某些I / O时，访问速度可能会大大降低。如果可能的话，最好假设这种情况并不快。

ThreadPolicy线程策略

检测所有可能的问题，使用detectAll()开启；

调用速度缓慢的检测，使用detectCustomSlowCalls()开启；

磁盘读取操作，使用detectDiskReads()开启；

磁盘写入操作，使用detectDiskWrites()开启；

网络操作，使用detectNetwork()开启;

检测已定义资源类型和getter调用之间的不匹配的功能，使用detectResourceMismatches()开启；

检测未缓冲的输入/输出操作，使用detectUnbufferedIo()开启。

VmPolicy虚拟机策略

检测所有可能的问题，使用detectAll()开启；

检测Activity泄漏，使用detectActivityLeaks()开启；

权限检测，detectContentUriWithoutPermission()开启；

未关闭的Closable对象泄漏，使用detectLeakedClosableObjects()开启；

泄漏的Sqlite对象，使用detectLeakedSqlLiteObjects()开启；

检测实例数量，使用setClassInstanceLimit()开启。

等等……

StrictMode的使用原则和技巧

以名称开头的方法detect指定了我们应该寻找的问题。以名称开头的方法penalty指定了检测到问题时应采取的措施。

可以根据需要调用任意多个detect和penalty方法。顺序微不足道：所有措施都适用于所有检测到的问题。

StrictMode如何使用？

在Application，Activity或其他应用程序组件Application.onCreate() 方法执行前，添加StrictMode检测。

public void onCreate() {

if (DEVELOPER_MODE) {

StrictMode.setThreadPolicy(new ThreadPolicy.Builde()

.detectDiskReads()

.detectDiskWrites()

.detectNetwork() // or .detectAll() for all detectable problems

.penaltyLog()

.build());

StrictMode.setVmPolicy(new VmPolicy.Builde()

.detectLeakedSqlLiteObjects()

.detectLeakedClosableObjects()

.penaltyLog()

.penaltyDeath()

.build());

}

super.onCreate();

}

如果观测结果呢？

AS IDE中的logat中筛选StrictMode信息

adb logcat 进行筛选StrictMode信息

现在，就一起实操体验 StrictMode 吧~

(1)StrictMode实操环境(可选项，用自己的环境和代码也一样)

SamplePop环境如下：

Android Studio 4.0

Gradle version 6.1.1

Android API version 30

(2)举个栗子：主线程中的文件写入的检查

(2.1)代码启用全部的ThreadPolicy和VmPolicy违例检测

public class MainActivity extends AppCompatActivity {

@Override

protected void onCreate(Bundle savedInstanceState) {

//代码启用全部的ThreadPolicy和VmPolicy违例检测

StrictMode.setThreadPolicy(new StrictMode.ThreadPolicy.Builder().detectAll().penaltyLog().build());

StrictMode.setVmPolicy(new StrictMode.VmPolicy.Builder().detectAll().penaltyLog().build());

super.onCreate(savedInstanceState);

setContentView(R.layout.activity_main);

//执行模拟测试

writeToFileInMainThread();

}

/**

* 主线程写文件

*/

public void writeToFileInMainThread() {

File destFile = new File(Environment.getExternalStoragePublicDirectory

(Environment.DIRECTORY_DOWNLOADS).getPath(), “StrictModeTest.txt”);

try {

destFile.createNewFile();

destFile.setWritable(true);

OutputStream output = new FileOutputStream(destFile, true);

output.write(“IO operation”.getBytes());

output.flush();

output.close();

} catch (Exception e) {

e.printStackTrace();

}

}

}

(2.2)运行应用，观察logcat的输出：

StrictMode 主线程写文件

(2.3)解决StrictMode检查错误

/**

* 子线程写文件

*/

public void writeToFileInSubThread() {

new Thread(new Runnable() {

@Override

public void run() {

writeToFileInMainThread();

}

}).start();

}

(3)举个栗子：内存泄漏的检查

(3.1)让LeakActivity产生内存泄漏

public class LeakActivity extends AppCompatActivity {

@Override

protected void onCreate(Bundle savedInstanceState) {

super.onCreate(savedInstanceState);

setContentView(R.layout.activity_leak);

ActivityManager.getInstance().mActivities.add(this);

}

}

(3.2)ActivityManager中关于mActivities的部分实现

public class ActivityManager {

private static ActivityManager mInstance = new ActivityManager();

public ArrayList mActivities = new ArrayList<>();

private ActivityManager(){

}

public static ActivityManager getInstance() {

return mInstance;

}

}

(3.3)引发内存泄漏

不断从MainActivity打开LeakActivity，再返回，再打开，如此反复操作，引发内存泄漏。

public void onLeakActivityStart(View view) {

Log.d(TAG, “onLeakActivityStart: “);

startActivity(new Intent(this, LeakActivity.class));

}

(3.4)运行应用，观察logcat的输出：

StrictMode 内存泄漏

(4)举个栗子：自定义检测类的实例泄漏

(4.1)开启实例检测，当LeakActivity类出现多于一个实例时，就报告内存泄漏

StrictMode.setVmPolicy(new StrictMode.VmPolicy.Builder().setClassInstanceLimit(LeakActivity.class, 1).penaltyLog().build());

(4.2)运行应用，观察logcat的输出：

StrictMode 实例检测

(5)举个栗子：耗时调用(noteSlowCall)

(5.1)耗时调用检测，适用于自定义的任务执行类中，比如：

public class FastRunTask {

private static final int MAX_RUN_VALID_DURATION = 300;

public void execute(Runnable task) {

long startTime = SystemClock.uptimeMillis();

task.run();

long useTime = SystemClock.uptimeMillis() – startTime;

if (useTime > MAX_RUN_VALID_DURATION) {

StrictMode.noteSlowCall(“FastRunTask note slow call use time : [” + useTime + “]”);

}

}

}

(5.2)执行耗时任务：

public void onFastRunTask(View view) {

Log.d(TAG, “onFastRunTask: “);

FastRunTask fastRunTask = new FastRunTask();

fastRunTask.execute(new Runnable() {

@Override

public void run() {

try {

Thread.sleep(500);

} catch (InterruptedException e) {

e.printStackTrace();

}

}

});

}

(5.3)运行应用，观察logcat的输出：

StrictMode 耗时调用

(6)StrictMode小结

主要作用：查找可能会长时间运行的操作，例如您可能会无意中在主线程中执行的网络或数据库操作。

注意项：

StrictMode无法监控JNI中的磁盘IO和网络请求

应用中并非需要解决全部的违例情况，比如有些IO操作必须在主线程中进行。

通常情况下StrictMode给出的耗时相对实际情况偏高，并不是真正的耗时数据。

如何修复问题：如果你发现你的感觉有问题的违规行为，有各种各样的工具来帮助解决这些问题：线程，Handler，AsyncTask，IntentService等。

注意：StrictMode不是安全机制，不能保证找到所有磁盘或网络访问。尽管在执行Binder调用时确实跨进程边界传播了状态，但它最终仍是尽力而为的机制。未来的Android版本可能会执行更多(或更少)操作，因此您永远不要在发布的应用程序中启用StrictMode。

一起来启用 StrictModel 查看自己的项目吧~

小编的扩展链接

参考链接

状似明月泛云河，体如轻风动流波

举手之劳，赞有余香！ ❤ 比心 ❤