你可能有疑问，为啥要在onDestroyView()里清空Map，而不是onDestory()里？
答：考虑到Fragment复用的场景，具体如下：
replace() Fragment 后会执行 onDestoryView()，而不是执行onDestory()完全销毁，目的是在销毁视图的同时，保留View状态和Fragment成员状态，下次加载时可以直接走onCreateView()，更快加载以达到复用的目的。
关于View状态的保存机制，笔者也不是特别了解，大概瞄下TextView的源码(onSaveInstanceState 和 onRestoreInstanceState)，看到了实现Parcelable重写了一些方法，猜测是 序列化。而序列化和反序列化前后，对象实例是不相等的，此时Map里还保留这之前的键值对(id → 实例)，此时根据id拿到的View实例肯定是不对的，所以这里做了清空操作。
所以这里也没毛病，所以不是KAE的锅，虽然这里不涉及，但也把Adapter情况如何findViewById也过一下~
KAE不支持直接在adapter里直接用，需要在build.gradle添加下述实验性配置：
// 主要是为了启用LayoutContainer androidExtensions { experimental = true }
而调用方式其实分两种，第一种是这样：
看下字节码转Java：
直接findViewById的，看看另一种，让ViewHolder实现LayoutContainer的方式：
看字节码转Java：
原理同样是创建一个hashMap来保存引用，通过ViewHolder传进的View进行绑定，真要在adapter里用KAE，建议使用第二种。
在 《Kotlin Android Extensions遭废弃，官方推荐使用ViewBinding》 一问中说到KAE的问题：
除此之外空间换时间，用一个额外的HashMap来存储View实例，更重要的是这部分内容对大部分使用者而言是黑盒，有时会踩上一些莫名其妙的"坑"。
官方提了一嘴使用ViewBinding替代KAE，其实就是启用ViewBinding功能后，AS自动为每个布局文件生成一个对应的Binding类，在里面完成View绑定(包含判空)，文件输出目录：/build/generated/data_binding_base_class_source_out。
具体玩法可以参见：《kotlin-android-extensions插件也被废弃了？扶我起来》
0x3、灵光乍现的瞬间
排查完不是KAE的锅，那到底是什么原因导致的控件为空呢？排查进展一下子陷入了僵局，只能从用户行为入手了，友盟上不知道为何看到不到用户的行为日志。
好在有自家全埋点，打开 Kibana，过滤错误类型日志，找到错误日志，获取deviceid，然后查询用户行为。
通过分析多个用户报错的情况，我发现了一个规律：
都是一次首页的Loading，然后崩溃，而距离用户上次打开APP的时间一般都会很久。
脑子里突然蹦出一个想法，该不会是因为APP被回收，重新打开Activity重建的问题把，因为APP中有一个跟很多APP一样的鸡贼操作，虽然提示了 "再按一次退出程序"，但其实是调用moveTaskToBack()退到后台而已。
模拟APP被回收就简单了，AS跑下程序，来到出问题的页面，APP退到后台，直接在Logcat把程序干掉，接着重新打开程序，静待片刻，果然，崩溃了，看下日志信息：
好家伙，果然复现了，因为Activity重建导致的刷新控件为空，噼里啪啦跟组长解释一波崩溃的原因，然后应急处理方式就是调用前先判空，保证不崩溃先。
本来快到下班的点了(6点)，正常情况应该是吃点东西摸鱼等下班了，不过没搞清楚引发这个问题的具体原因，回家也是念念不忘，索性加班排查下吧。
0x4、加班加点排查
涉及Activity重建，那估计也跟Fragment生命周期，Fragment多层嵌套之类的脱不了干系，在BaseActivity和BaseFragment中把生命周期相关的回调都加上日志。
