[Revert] 恢复对 ChatFollowRecPageItemView 的修改，防止引入 bug 代圣达 2021/12/23, 15:43

Author: daishengda2018

源码分析/ARouter/Android 平台页面路由框架 ARouter.md

@@ -99,7 +99,7 @@ ARouter 大致有以下 7 个优势：
 
 ![](images/8905de115cb4434b70727fe9fabf62dd3e11d64b.png)  
 
-**拦截器**
+## **拦截器**
 
 分享完分组管理和按需加载之后，接下来分享一下关于拦截器的内容。原生的路由方案中存在的问题就是其无法在页面跳转的过程中插入一些自定义逻辑，而拦截器就是 ARouter 中提出的针对 AOP 思想的实现。
 
@@ -109,14 +109,16 @@ ARouter 大致有以下 7 个优势：
 
 直接讲拦截器可能不容易让大家理解，那么就用这样形象的比喻来解释一下，拦截器就是像是一个汉堡，汉堡中夹心的无论是生菜、牛肉还是芝士都像拦截器一样，当在做汉堡时就相当于在做 APK，打包了哪些模块就相当于在汉堡中放了哪些层，在吃的时候就会把这一层都咬掉，但是汉堡的每一层都有可能是芝士、牛肉或者铁片，当遇到某一层是铁片的时候就无法咬下去了，也就是被拦截住了。同样的拦截器就是需要当条件符合的时候才能让跳转流程继续执行，同样像汉堡一样，如果使用了太多的拦截器最终会导致汉堡变成了 “巨无霸”，所有的拦截器会在任意两次跳转之间生效，声明了大量的拦截器会影响整个跳转流程的性能，拦截器的更详细内容会在第三部分的最佳实践中继续为大家介绍。
 
-**InstantRun 兼容**  
+## **InstantRun 兼容**
+
 接下来分享一下 ARouter 如何实现对于 InstantRun 的兼容。市面上的框架一般对于这一部分的兼容都是缺失的，对于 InstantRun 的兼容从技术上看并不是非常难以实现的，在实现时只需仔细阅读 InstantRun 的源码就可以了。在实现对于 InstantRun 的兼容时是存在如下图所示的四种情况的，当 AndroidSDK 版本大于 21 的时候，会存在 SplitAPK 的特性支持的，会允许将一个 APK 切分成多个小 APK，当然其实这并不是 APK 的切分，而实际上是 Dex 的切分，也就每个依赖都会打包成小的 Dex 放在 APP + 包名的目录下的，这与传统情况下是不同的。
 
 ![](images/37d2e9bf06b818dbbd64b02a313f386d194ac8f0.png)  
 
 所以只需要参照这张表格并根据 AndroidSDK 和 GradlePlugin 的版本就可以解决了。如果 Android 版本超过 21 并且 Gradle 插件的版本超过 2.3.0，这时候就会支持 SplitAPK，从中可以获取所有 Dex 的位置，进而实现映射关系的加载。除此之外的三种情况都不支持 SplitAPK 的，这种情况下就需要看一下 InstantRun 的源码，就会发现在源码中原本应该存放业务代码的 Dex 的地方替换成了 InstantRun 的 SDK 的 Dex，而是将业务代码打包在一个 ZIP 中，此时只需要通过运行时的反射拿到 InstantRun 的 SDK 的一个类的 Path，而在获取 Path 时是存在静态方法的 getDexFileDirectory，只需要执行一下就可以知道当前版本将真实的 Dex 放在什么地方，通过对于这两种方式的兼容就可以实现对于 InstantRun 的兼容。
 
-**依赖注入的实现**  
+## **依赖注入的实现**  
+
 接下来分享依赖注入的实现，这一部分是路由框架在进行大规模组件之间解耦时比较重要的一点。其实依赖注入就是对于控制反转思想的实现，这部分服务端使用的比较多，客户端可能使用不是非常多。ARouter 对于依赖注入的实现主要分成如下图所示的两个部分。
 
 ![](images/880d332aa53f1758e1f68824a9f38db7c6bf7955.png)