android应用内存泄露分析改善经验总结.docVIP

Android 应用内存泄露分析、改善经验总结 、八 、- 前言 通过这几天对好几个应用的内存泄露检测和改善，效果明显： 完全退出应用时，手动触发 GC ，从原来占有内存 100 多 M 降到低于 20M ；手动触发 GC 后，通过 adb shell dumpsys meminfo packagename -d 查看 Activity 和 View 的数量也趋 近于 0 了（没有做到归零是因为 SDK 中存在内存泄露，需 要中间层去处理） ；发现了一个 SDK 中的内存泄露 （ Android InputMethodManager 导致的内存泄露及解决方案） ；发现 一个 MTK Webview 的内存泄露 （org.chromium.android_webview.AwPasswordHandler.jav a 中 private static AwPasswordHandler sInstance = null 导 致的内存泄露 ）。 从结果来看我分析和改善内存泄露的方法是对的，这个过程 并不复杂，所以可以梳理总结出来作为分享。 原则 对于性能问题，分析和改善有必要遵循以下原则： 一切看数据说话，不能跟着感觉走，感觉哪有问题就去改， 很有可能会适得其反；性能优化是一个持续的过程，需要不 断地改善，不要想着一气呵成；对于性能问题，不一定必须 要改善，受限于架构或者其它原因某些问题可能会很难改善， 必须要先保证能用，再才考虑好用。改善后一定要验证，任 何一个地方的改动都需要验证，避免因为改善性能问题导致 其它的问题。 步骤 下面是我在针对内存泄露这个性能问题上的解决步骤： 优先处理常见的内存泄露问题 首先解决常见的内存泄露问题，这个过程可以借助 Android Studio 的 Analyze-Inspect Code 对代码做静态分析， 常见的 内存泄露问题有： 非静态内部类导致的内存泄露，比如 Handler ，解决方法是 将内部类写成静态内部类， 在静态内部类中使用软引用 /弱引 用持有外部类的实例， eg ： static class ExerciseHandler extends Handler{ private SoftReference exerciseActivitySoftReference = null; public ExerciseHandler(ExerciseActivity exerciseActivity){ exerciseActivitySoftRefer ence = new SoftReference(exerciseActivity); } @Override public void handleMessage(Message msg) { ExerciseActivity exerciseActivity = exerciseActivitySoftReference.get(); super.handleMessag e(msg); switch (msg.what) { case MSG_XX: exerciseActivity.***; default: break; } } } IO 操作后，没有关闭文件导致的内存泄露，比如 FileInputStream 、FileOutputStream 使用完后没有关闭，这 种问题在 Android Studio 2.0 中能够通过静态代码分析检查 出来，直接改善就可以了；自定义 View 中使用 TypedArray 后，没有 recycle ，这种问题也可以在 Android Studio 2.0 中 能够通过静态代码分析检查出来，直接改善就可以了；某些 地方使用了四大组件的 context ，在离开这些组件后仍然持 有其 context 导致的内存泄露，这种问题属于共识，在编写 代码的过程中就应该按照规则来，使用 Application 的 Context 就可以解决这类内存泄露的问题了，至于什么情况 下应该使用四大组件的 Context ，什么时候应该使用 Application 的 context 可以参见下表： application 使用场景 备注：大家注意看到有一些 NO 上添加了一些数字，其实这 些从能力上来说是 YES ，但是为什么说是 NO 呢？下面一个 一个解释： 1、数字 1 ：启动 Activity 在这些类中是可以的，但是需要创 建一个新的 task ，一般情况不推荐； 2、数字 2：在这些类 中去 layout inflate 是合法的， 但是会使用系统默认的主题样 式，如果你自定义了某些样式可能不会被使用； 3、数字 3 ： 在 Receiver 为 null 时允许， 在 4.2 或以上的版本中，