抖音 检测token 是否在线

我们知道，Android 低版本（4.X 及以下，SDK < 21）的设备，采用的 Java 运行环境是 Dalvik 虚拟机。它相比于高版本，最大的问题就是在安装或者升级更新之后，首次冷启动的耗时漫长。这常常需要花费几十秒甚至几分钟，用户不得不面对一片黑屏，熬过这段时间才能正常使用 APP。

这是非常影响用户的使用体验的。我们从线上数据也可以发现，Android 4.X 及以下机型，其新增用户也占了一定的比例，但留存用户数相比新增则要少非常多。尤其在海外，像东南亚以及拉美等地区，还存有着很大量的低端机。4.X 以下低版本用户虽然比较少，但对于抖音及 TikTok 这样有着亿级规模的用户的 APP，即使占比 10%，数目也有上千万。因此如果想要打通下沉市场，这部分用户的使用和升级体验是绝对无法忽视的。

这个问题的根本原因就在于，安装或者升级后首次 MultiDex 花费的时间过于漫长。为了解决这个问题，我们挖掘了 Dalvik 虚拟机的底层系统机制，对 DEX 相关处理逻辑进行了重新设计，最终推出了 BoostMultiDex 方案，它能够减少 80%以上的黑屏等待时间，挽救低版本 Android 用户的升级安装体验。

我们先来简单看一个安装后首次冷启动加载 DEX 时间的对比数据：

可以看到原始 MultiDex 方案竟然花了半分钟以上才能完成 DEX 加载，而 BoostMultiDex 方案的时间仅需要 5 秒以内。优化效果极为显著！

接下来，我们就来详细讲解整个 BoostMultiDex 方案的研发过程与解决思路。

起因

我们先来看下导致这个问题的根本原因。这里面是有多个原因共同引起的。

首先需要清楚的是，在 Java 里面想要访问一个类，必然是需要通过 ClassLoader 来加载它们才能访问到。在 Android 上，APP 里面的类都是由PathClassLoader负责加载的。而类都是依附于 DEX 文件而存在的，只有加载了相应的 DEX，才能对其中的类进行使用。

Android 早期对于 DEX 的指令格式设计并不完善，单个 DEX 文件中引用的 Java 方法总数不能超过 65536 个。

对于现在的 APP 而言，只要功能逻辑多一些，很容易就会触达这个界限。

这样，如果一个 APP 的 Java 代码的方法数超过了 65536 个，这个 APP 的代码就无法被一个 DEX 文件完全装下，那么，我们在编译期间就不得不生成多个 DEX 文件。我们解开抖音的 APK 就可以看到，里面确实包含了很多个 DEX 文件：

这样设置进去之后，果然不再出现 getDex 异常了。

小结

至此，无需等待 ODEX 优化的直接 DEX 加载方案已经完全打通，APP 的首次启动时间由此可以大幅减少。

我们距离最终的极致完整解决方案还有一小段路，然而，正是这一小段路，才最为艰险严峻。更大的挑战还在后面，我们将在下一篇文章为大家细细分解，同时也会详细展示最终方案带来的收益情况。大家也可以先思考一下这里还有哪些问题没有考虑到。

抖音/TikTok Android 基础技术团队是一个追求极致的深度技术团队，目前上海、北京、深圳、杭州都有大量人才需要。欢迎各位同学前来与我们共同建设亿级用户全球化 APP!

可以点击阅读原文，进入字节跳动招聘官网查询抖音 Android 相关职位「链接」，也可以联系 xiaolin.gan@bytedance.com 咨询相关信息或者直接发送简历内推！

欢迎关注字节跳动技术团队

以上就是抖音 检测token 是否在线的详细内容，更多内容请关注金符游戏其它相关文章！