发现Activity泄露的两种方法:
一. 通过StrictMode模式来发现,如果有Activity泄露直接会闪退,不过这种方法有时过于严格了,会把一些延迟释放Activity的场景也算在内;
开启StrictMode需要在BaseActicity.onCreate() 加上:StrictMode.setVmPolicy(new StrictMode.VmPolicy.Builder().detectAll().penaltyLog().penaltyDeath().build());
二. 通过adb shell dumpsys meminfo 和 ddms 来确定泄露源,这种方法更精确,一般用于第一种方法发现具体的可疑Activity泄露,然后再通过这种方法再精确定位问题;
举个例子说一下方法2的具体流程
例 子的场景:由于小米系统首次启动联系人(PeopleActivity)的速度特别慢,所以我们采用了预加载的技术,在 Application.onCreate启动了PreloadPeopleActivity,之后用户在进入PeopleActivity 时,PreloadPeopleActivity会自动finish,详情可以阅读俊杰的预加载的文章。
1. 点击联系人PeopleActivity,然后打开ddms , 找到对应的进程com.miui.miuilite:csp,进入进程对应的heap视图,然后点击右边的"Cause GC"来手动触发进程的gc 。
2. adb shell dumpsys meminfo com.miui.miuilite:csp
可以看到 Activities: 3
说明当前csp进程有3个Activity实例,而我们只启动了PeopleActivity,之前的PreloadActivity也已经finish,所以这里肯定有Activity泄露!
3. 回到ddms, Dump HPROF file,然后点击OOL,输入 select * from instanceof android.app.Activity,点击右上角红色的执行按钮得到结果: