这是非常影响用户的使用体验的。我们从线上数据也可以发现,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 咨询相关信息或者直接发送简历内推!
欢迎关注字节跳动技术团队
以上就是小编带来的旧安卓手机运行不了抖音怎么办的全部内容,希望能够帮助到大家,更多抖音操作运营内容,请关注金符游戏。