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

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

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

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

一、如何解决InputMethodManager内存泄漏

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

图1 inputMethodManager内存泄漏引用链

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

         项目中内存泄漏这块，使用的是MagnifierSDK(【SNGAPM】Magnifier SDK介绍)，其中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()内部实现机制比较清楚的话（如果不清楚，可参看 从源码角度剖析 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的时候要特别注意，这里不展开，具体可参见 从源码角度深入理解LayoutInflater.Factory 。installViewFactory中主要进行的是setFactory操作，其中上面的this 指的就是 LayoutInflaterFactory ，那LayoutInflaterFactory 又是什么了 ？

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

图11 LayoutInflaterFactory

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

图12  createViewFromTag()

       到此大家应该明白了吧 ，View 替换是在inflate 的createViewFromTag() 进行的，不同版本的实现又是通过setFactory 来实现的。

由上文知在installViewFactory 中 使用的是AppCompatDelegateImplV7，那AppCompatDelegateImplV7::onCreateView() 实现又是怎样的，如下图所示：

图13 AppCompatDelegateImplV7::onCreateView()

在createView 里面创建了AppCompatViewInflater

AppCompatViewInflater::createView 

        没错系统就是在AppCompatViewInflater中将部分系统View 全部替换成了 AppCompatView ，而在AppCompatxxx中会将普通的Context wrap 成TintContextWrapper ,到此整个View的加载过程讲完。

另外，这里补充一下 LayoutInflaterFactory 接口用途（实际开发中很少会使用）：

1）自定义的View，而不是让系统去创建，避免反射过程，提高性能；

2）在xml使用自定义的View时，可以不声明全限定名称；

3）更换系统View为自己定义的View（Appcompat库替换默认的系统View的方式）