Android应用内存泄露分析

Android应用内存泄露分析改善经验总结

通过这几天对好几个应用的内存泄露检测和改善，从结果来看我分析和改善内存泄露的方法是对的，这个过程并不复杂，所以可以梳理总结出来作为分享。

作者：佚名来源：安卓开发精选|2017-02-17 11:19

收藏

分享

前言

通过这几天对好几个应用的内存泄露检测和改善，效果明显：

∙完全退出应用时，手动触发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.java中private static AwPasswordHandler sInstance = null导致的内存泄露)。

从结果来看我分析和改善内存泄露的方法是对的，这个过程并不复杂，所以可以梳理总结出来作为分享。

原则

对于性能问题，分析和改善有必要遵循以下原则：

∙一切看数据说话，不能跟着感觉走，感觉哪有问题就去改，很有可能会适得其反;

∙性能优化是一个持续的过程，需要不断地改善，不要想着一气呵成;

∙对于性能问题，不一定必须要改善，受限于架构或者其它原因某些问题可能会很难改善，必须要先保证能用，再才考虑好用。

∙改善后一定要验证，任何一个地方的改动都需要验证，避免因为改善性能问题导致其它的问题。

步骤

下面是我在针对内存泄露这个性能问题上的解决步骤：

优先处理常见的内存泄露问题

首先解决常见的内存泄露问题，这个过程可以借助Android Studio的Analyze-Inspect Code对代码做静态分析，常见的内存泄露问题有：

∙非静态内部类导致的内存泄露，比如Handler，解决方法是将内部类写成静态内部类，在静态内部类中使用软引用/弱引用持有外部类的实例，eg：

1. static class ExerciseHandler extends Handler{

2.

3. private SoftReference exerciseActivitySoftReference = null;

4.

5.

6.

7. public ExerciseHandler(ExerciseActivity exerciseActivity){

8.

9. exerciseActivitySoftReference = new SoftReference(exerciseActivity);

10.

11. }

12.

13.

14.

15. @Override

16.

17. public void handleMessage(Message msg) {

18.

19. ExerciseActivity exerciseActivity = exerciseActivitySoftReference.get();

20.

21. if(null != exerciseActivity){

22.

23. super.handleMessage(msg);

24.

25. switch (msg.what) {

26.

27. case MSG_XX:

28.

29. exerciseActivity.***;

30.

31. break；

32.

33. default:

34.

35. break;

36.

37. }

38.

39. }

40.

41. }

42.

43. }

∙IO操作后，没有关闭文件导致的内存泄露，比如Cursor、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或以上的版本中，用于获取黏性广播的当前值。(可以无视);

4、ContentProvider、BroadcastReceiver之所以在上述表格中，是因为在其内部方法中都有一个context用于使用。

还有一种不属于内存泄露，但在分析内存泄露的问题时应该一并解决：同一个APP，将图片放在不同的drawable 文件夹下，在相同的设备上占用的内存情况不一样，具体可以参见：关于Android中图片大小、内存占用与drawable 文件夹关系的研究与分析。解决这个问题遵循以下原则就可以了：1、UI只提供一套高分辨率的图，图片建议放在drawable-xxhdpi文件夹下(放在xxxhdpi或者更高分辨率的文件夹下没有必要，权衡利弊，照顾主流设备即可)，