抖音字体大小设置方法安卓抖音字体大小设置方法( 六 ) _云知道

我们先回到解决 MainActivity 多实例问题的出发点。之所以要避免 MainActivity 多实例，是为了防止同时出现多个 MainActivity 对象，出现不符合预期的 MainActivity 生命周期的执行。因此只要确保不会同时出现多个 MainActivity 对象，一样可以解决 MainActivity 多实例问题。
要避免同时出现多个 MainActivity 对象，我们首先需要知道当前是否已经存在 MainActivity 对象，解决这个问题的思路比较简单，我们可以去监听 Activity 的生命周期，在 MainActivity 的 onCreate 和 onDestroy 中分别去增加减少 MainActivity 的实例数。如果 MainActivity 实例数为 0 则认为当前不存在 MainActivity 对象。
解决了 MainActivity 对象数统计的问题，接下来我们就需要让 MainActivity 同时存在的对象数永远保持在 1 个以下。要解决这个问题我们需要回顾一下 Activity 的启动流程，启动一个 Activity 首先会经过 AMS，AMS 会再调用到 Activity 所在的进程，在 Activity 所在的进程会经过主线程的 Handler post 到主线程，然后通过 Instrumentation 去创建 Activity 对象，以及执行后续的生命周期。对于外部启动 MainActivity ，我们能够控制的是从 AMS 回到进程之后的部分，这里可以选择以 Instrumentation 的 newActivity 作为入口。

具体来说我们的优化方案如下：
继承 Instrumentation 实现一个自定义的 Instrumentaion 类，以代理转发方式重写里面的所有方法；反射获取 ActivityThread 中 Instrumentaion 对象，并以其为参数创建一个自定义的 Instrumentaion 对象，通过反射方式用自定义的 Instrumentaion 对象替换 ActivityThread 原有的 Instrumentaion；在自定义 Instrumentaion 类的 newActivity 方法中，进行判断当前待创建的 Activity 是否为 MainActivity，如果不是 MainActivity 或者当前不存在 MainActivity 对象，则调用原有实现，否则替换其 className 参数将其指向一个空的 Activity，以创建一个空的 Activity；在这个空的 Activity 的 onCreate 中 finish 掉自己，同时通过一个添加了 FLAG_ACTIVITY_NEW_TASK 和 FLAG_ACTIVITY_CLEAR_TOP flag 的 Intent 去启动一下 SplashActivity 。

需要注意的是我们这里 hook Instrumentaion 的实现方案，在高版本的 Android 系统上我们也可以以 AppComponentFactory instantiateActivity 的方式替换。
1.4.2 反序列化优化
抖音 Activity 阶段另一个典型的优化是反序列化的优化——在抖音使用过程中会在本地序列化一部分数据，在启动过程中需要对这部分数据进行反序列化，这个过程会对抖音的启动速度造成影响。在之前的优化过程中，我们从业务层面对 block 逻辑进行了异步化、快照化等 case by case 的优化，取得了不错的效果，但是这样的方式维护起来比较麻烦，迭代过程也经常出现劣化，因此我们尝试以正面优化反序列化的方式进行优化。
抖音启动阶段的反序列化问题具体来说就是 Gson 数据解析耗时问题，Gson 是 Google 推出的一个 json 解析库，其具有接入成本低、使用便捷、功能扩展性良好等优点，但是其也有一个比较明显的弱点，那就是对于它在进行某个 Model 的首次解析时会比较耗时，并且随着 Model 复杂程度的增加，其耗时会不断膨胀。
Gson 的首次解析耗时与它的实现方案有关，在 Gson 的数据解析过程中有一个非常重要的角色，那就是 TypeAdapter，对于每一个待解析的对象的 Class，Gson 会首先为其生成一个 TypeAdapter，然后利用这个 TypeAdapter 进行解析，Gson 默认的解析方案采用的是 ReflectiveTypeAdapterFactory 创建的 TypeAdapter 的，其创建与解析过程中涉及到大量的反射调用，具体流程为：