InputMethodManager内存泄漏引发对View加载的探究-白红宇

InputMethodManager内存泄漏引发对View加载的探究

阅读量：4224 次

发布时间：2019-05-26

本文共 3507 字，大约阅读时间需要 11 分钟。

转载自：https://www.jianshu.com/p/bc79e01da6b0

本文主要以InputMethodManager内存泄漏为引，来探究在不同系统版本中View是如何被加载的，涉及以下几个方面：

（1）如何解决InputMethodManager内存泄漏；

（2）为何View.getContext() 是TintContextWrapper；

（3）不同系统版本中View是如何被加载的。

一、如何解决InputMethodManager内存泄漏

在企鹅FM最新版本开发中，正好负责项目性能监控（主要是ANR、内存泄漏等等）这一块，在内存泄漏这块发现有很多InputMethodManager泄漏的上报，引用链如下：

图1 inputMethodManager内存泄漏引用链

在很早之前就听说过InputMethodManager存在泄漏问题，查阅了一下相关资料，大多数是InputMethodManger中mServedView存在泄漏，而非图1中的mLastSrvView ，不太应该啊，难道是某个版本rom的特殊机型，对照相关邮件发现全部都是华为机型。

项目中内存泄漏这块，使用的是MagnifierSDK()，其中ActivityLeakSolution中有专门解决InputMethodManager泄漏的解决方法，如下图2所示：

ActivityLeakSolution::fixInputMethodManager

从上述解决方法中可以看出，主要针对的是mCurRootView、mServedView、mNextServedView，为什么添加这些，本文在这里就不展开讲解了。

后面在同事的提醒下发现项目中有专门针对华为机型进行处理的方法，方法原理简单粗暴，直接置空，破坏掉path to gc节点（同MagnifierSDK中ActivityLeakSolution::fixInputMethodManager处理方式一样）。

图3 针对华为mLastSrvView进行处理

既然同MagnifierSDK中ActivityLeakSolution::fixInputMethodManager处理方式一样，为何没生效了，回头再去图1中的引用链，从中发现了蛛丝马迹，RadioSearchActivity 是TintContextWrapper 中的mBase 引用，而TintContextWrapper::mContext 又是被SearchView$SearchAutoComplete引用，由此猜想图3中的view.getContext()==destContext条件可能失效。后续验证发现上图中View.getContenxt 确实是 TintContextWrapper 而非引用链中的RadioSearchActivity ，如下图4所示：

图4 查看 view.getContext()

二、为何View.getContext()是TintContextWrapper

为何View.getContext()是TintContextWrapper，而不是RadioSearchActivity。带着疑问去查看SearchView$SearchAutoComplete(这里的SearchView是使用support v7库)为何物，发现SearchAutoComplete直接继承AppCompatAutoCompleteTextView。

图5 SearchAutoComplete

在AppCompatAutoCompleteTextView 的构造函数中，会将传入的context(这里指的是RadioSearchActivity)wrap成TintContextWrapper，可以方便的实现Android Material Design 中的Tint。

图6 AppCompatAutoCompleteTextView

现在虽然弄懂了这个案例中View.getContext()是TintContextWrapper的原因，那是不是所有的View都存在这样的情况了，在什么时候会转化了，带着这些疑问去探究一下View是如何加载的。

三、不同系统版本中View是如何被加载的

总所周知，Activity 加载布局时，调用的是activity的setContentView()方法来加载布局；而在Fragment中，是直接通过LayoutInflater来加载布局的。如果大家对setContentView()内部实现机制比较清楚的话（如果不清楚，可参看），一定知道Activity加载布局也是使用LayoutInflater，因此可以认为Activity和Fragment加载布局方式一致。

由于目前官方推荐使用AppCompatActivity代替Activity，当前企鹅FM项目已全部替换成了AppCompatActivity，因此在这里的探究是基于AppCompatActivity来讲解的。

图7 AppCompatActivity

从图7可知，在AppCompatActivity::onCreate()中有一个AppCompat的代理类AppCompatDelegate(一个抽象类)，其具体实现如下，对应着不同版本的具体实现类。

图8 AppCompatDelegate实现类

接着看一下delegate.installViewFactory 内部实现(项目中存在support v22 和 v23，两者存在差异)，

图9 support v22

图10 support v23

从上可以看出v22 和v23 installViewFactory 实现存在微小差别，在使用Factory的时候要特别注意，这里不展开，具体可参见。installViewFactory中主要进行的是setFactory操作，其中上面的this 指的就是 LayoutInflaterFactory ，那LayoutInflaterFactory 又是什么了？

LayoutInflaterFactory 是一个接口，提供了一个耳熟能详的方法onCreateView 如下：

图11 LayoutInflaterFactory

onCreateView 这个回调是在createViewFormTag进行的，熟悉setContentView的同学一定清楚，在 public View inflate(XmlPullParser parser,@Nullable ViewGroup root, booleanattachToRoot)中会通过createViewFromTag()方法来创建View。