StrictMode是一个开发者工具,常用于捕获在应用主线程中发生的磁盘I/O、网络访问违例等问题。
StrictMode主要检测两大问题:线程策略(TreadPolicy)和VM策略(VmPolicy)。
可以在应用的Application、Activity或者其他应用组件的onCreate方法中加入检测代码,如:
public void onCreate() {
if (DEVELOPER_MODE) {
StrictMode.setThreadPolicy(new StrictMode.ThreadPolicy.Builder()
.detectDiskReads()
.detectDiskWrites()
.detectNetwork() // or .detectAll() for all detectable problems
.penaltyLog()
.build());
StrictMode.setVmPolicy(new StrictMode.VmPolicy.Builder()
.detectLeakedSqlLiteObjects()
.detectLeakedClosableObjects()
.penaltyLog()
.penaltyDeath()
.build());
}
super.onCreate();
}
StrictMode有多种报告违例的形式,但要分析具体违例情况,还是需要查看日志。我们在此介绍两种方式,一种是在android studio IDE的logcat里查看:
另一种是在终端下,过滤StrictMode得到违例的具体stacktrace信息(手机要打开调试用的app),然后打开命令终端,使用adb命令来查看:
~$ adb logcat | grep StrictMode
如果发现有违例的行为,可以通过使用线程(threads)、Handler、AsyncTask、IntentService等帮助解决。提供一下些常用的措施:
1.首先Activity的onCreate方法中加上检测代码:
注:以下的代码启用全部的ThreadPolicy和VmPolicy违例检测
StrictMode.setThreadPolicy(new StrictMode.ThreadPolicy.Builder().detectAll().penaltyLog().build());
StrictMode.setVmPolicy(new StrictMode.VmPolicy.Builder().detectAll().penaltyLog().build());
2.这是引起违例的代码:
public void writeToExternalStorageInMainThread() {
File externalStorage = Environment.getExternalStorageDirectory();
File destFile = new File(externalStorage, "hello.txt");
try {
OutputStream output = new FileOutputStream(destFile, true);
output.write("I am testing io".getBytes());
output.flush();
output.close();
} catch (FileNotFoundException e) {
e.printStackTrace();
} catch (IOException e) {
e.printStackTrace();
}
}
logcat已告诉我们出现了违例和出现的位置。
4.解决这个违例
修改一下writeToExternalStorageInMainThread方法,将引起违例的代码都放在一个工作线程中去执行,如下所示:
public void writeToExternalStorageInMainThread() {
new Thread(new Runnable() {
@Override
public void run() {
File externalStorage = Environment.getExternalStorageDirectory();
File destFile = new File(externalStorage, "hello.txt");
OutputStream output = null;
try {
output = new FileOutputStream(destFile, true);
output.write("I am testing io".getBytes());
output.flush();
output.close();
} catch (FileNotFoundException e) {
e.printStackTrace();
} catch (IOException e) {
e.printStackTrace();
}finally {
if(output != null){
try {
output.close();
} catch (IOException e) {
e.printStackTrace();
}
}
}
}
}).start();
}
demo示例
通常情况下,检测内存泄漏,我们会使用MAT(Eclipse Memory Analyzer)工具对heap dump 文件进行分析。但是使用StrictMode,只需要过滤日志就能发现内存泄漏,更快捷方便。
1.首先,需要开启对检测Activity泄漏的违例检测,可以使用detectAll或者detectActivityLeaks():
StrictMode.setVmPolicy(new StrictMode.VmPolicy.Builder().detectActivityLeaks().penaltyLog().build());
2.写一段能够产生Activity泄漏的代码
public class LeakActivity extends AppCompatActivity {
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_leak);
if(MyApplication.IS_DEBUG){
MyApplication.sLeakyActivities.add(this);
}
}
}
3.MyApplication中关于sLeakyActivities的部分实现
public class MyApplication extends Application {
public static final boolean IS_DEBUG = true;
public static ArrayList<Activity> sLeakyActivities = new ArrayList<Activity>();
@Override
public void onCreate() {
StrictMode.setVmPolicy(new StrictMode.VmPolicy.Builder().detectActivityLeaks().penaltyLog().build());
super.onCreate();
}
}
4.引发内存泄漏的操作:
通过不断从MainActivity打开LeakActivity,再返回,再打开,如此反复操作,引发内存泄漏,下面是MainActivity的代码:
public class MainActivity extends AppCompatActivity {
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
TextView textView = (TextView)findViewById(R.id.tv);
textView.setOnClickListener(new View.OnClickListener() {
@Override
public void onClick(View v) {
startActivity(new Intent(MainActivity.this,LeakActivity.class));
}
});
}
}
5.当我们反复进入LeakyActivity再退出,在Logcat中过滤StrictMode就会得到这样的日志:
2019-04-04 19:49:43.502 32708-32708/com.wong.appmemoryleakydemo E/StrictMode: class com.wong.appmemoryleakydemo.LeakActivity; instances=7; limit=1
android.os.StrictMode$InstanceCountViolation: class com.wong.appmemoryleakydemo.LeakActivity; instances=7; limit=1
at android.os.StrictMode.setClassInstanceLimit(StrictMode.java:1)
分析日志:LeakyActivity本应该只存在一个实例的,但现在存在了7个,说明LeakyActivity发生了内存泄漏。
检测内存泄漏demo
我们还可以通过StrictMode自定义检测类的实例泄漏。从API 11 开始,系统提供的这个方法setClassInstanceLimit可以实现我们的需求。比如说有个类叫SingleAction.class,我们认为在运行时,它应该只有一个实例,如果多一个,我们就可以认为发生了内存泄漏:
1.开启违例检测,如下:
StrictMode.setVmPolicy(new StrictMode.VmPolicy.Builder().setClassInstanceLimit(SingleAction.class,1).penaltyLog().build());
上面代码就是说,当SingleAction类出现多于一个实例时,就报告内存泄漏。
StrictMode从API 11开始允许开发者自定义一些耗时调用违例,这种自定义适用于自定义的任务执行类中,比如自定义任务处理类MyTaskExecutor:
public class MyTaskExecutor {
public void execute(Runnable task){
task.run();
}
}
但是如果我们想跟踪每个任务执行的耗时情况,如果耗时大于500毫秒就通知我们,我们该怎么办呢?StrictMode的noteSlowCall方法可以实现这个功能,修改MyTaskExecutor,如下所示:
public class MyTaskExecutor {
public static long CAN_BEAR_TIME = 500;
public void execute(Runnable task){
long sTime = SystemClock.uptimeMillis();
task.run();
long cTime = SystemClock.uptimeMillis() - sTime;
if(cTime > CAN_BEAR_TIME){
StrictMode.noteSlowCall("slow call cost:"+cTime);
}
}
执行一个耗时1000毫秒的任务,测试一下:
package com.wong.timeconsumingviolation;
import android.os.StrictMode;
import android.support.v7.app.AppCompatActivity;
import android.os.Bundle;
public class MainActivity extends AppCompatActivity {
@Override
protected void onCreate(Bundle savedInstanceState) {
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);
MyTaskExecutor taskExecutor = new MyTaskExecutor();
taskExecutor.execute(new Runnable() {
@Override
public void run() {
try {
Thread.sleep(1000);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
});
}
}
在Logcat中过滤StrictMode就会得到这样的日志:
2019-04-04 20:27:27.020 6147-6147/com.wong.timeconsumingviolation D/StrictMode: StrictMode policy violation; ~duration=29 ms: android.os.StrictMode$StrictModeCustomViolation: policy=65599 violation=8 msg=slow call cost:1001
at android.os.StrictMode$AndroidBlockGuardPolicy.onCustomSlowCall(StrictMode.java:1397)
at android.os.StrictMode.noteSlowCall(StrictMode.java:2340)
at com.wong.timeconsumingviolation.MyTaskExecutor.execute(MyTaskExecutor.java:19)
at com.wong.timeconsumingviolation.MainActivity.onCreate(MainActivity.java:17)
at android.app.Activity.performCreate(Activity.java:7040)
at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1214)
at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2809)
at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2931)
at android.app.ActivityThread.-wrap11(Unknown Source:0)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1620)
at android.os.Handler.dispatchMessage(Handler.java:105)
at android.os.Looper.loop(Looper.java:173)
at android.app.ActivityThread.main(ActivityThread.java:6698)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.Zygote$MethodAndArgsCaller.run(Zygote.java:240)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:782)
从日志分析来看,我们已成功跟踪到耗时超过500ms的任务了。
注意上面的日志结果中的:duration=29 ms,并非耗时任务的执行时间,而我们自定义信息msg=slow call cost:1001包包含的时间才是真正的耗时。
自定义耗时违例demo