启动是 App 给用户的第一印象对用戶体验至关重要。抖音的业务迭代迅速如果放任不管，启动速度会一点点劣化为此抖音 iOS 客户端团队做了大量优化工作，除了传统的修妀业务代码方式我们还做了些开拓性的探索，发现修改代码在二进制txt文件乱码的布局可以提高启动性能方案落地后在抖音上启动速度提高了约 15%。

本文从原理出发介绍了我们是如何通过静态扫描和运行时 trace 找到启动时候调用的函数，然后修改编译参数完成二进制txt文件乱码嘚重新排布

进程如果能直接访问物理内存无疑是很不安全的，所以操作系统在物理内存的上又建立了一层虚拟内存为了提高效率和方便管理，又对虚拟内存和物理内存又进行分页（Page）当进程访问一个虚拟内存 Page 而对应的物理内存却不存在时，会触发一次缺页中断（Page Fault）汾配物理内存，有需要的话会从磁盘 mmap 读人数据

编译器在生成二进制代码的时候，默认按照链接的 Object File(.o) 顺序写txt文件乱码按照 Object File 内部的函数顺序寫函数。

静态库txt文件乱码.a 就是一组.o txt文件乱码的 ar 包可以用 ar -t 查看.a 包含的所有.o。

简化问题：假设我们只有两个 page：page1/page2其中绿色的 method1 和 method3 启动时候需要調用，为了执行对应的代码系统必须进行两个 Page Fault。

但如果我们把 method1 和 method3 排布到一起那么只需要一个 Page Fault 即可，这就是二进制txt文件乱码重排的核心原理

由于 block 对应的函数签名不一样，所以这里仍然采用汇编来实现 hook_block_envoke ：

同样通过函数地址反查 linkmap 既可找到 block 符号。

基于静态扫描 + 运行时 trace 的方案仍然存在少量瓶颈：

• C++ 通过寄存器的间接函数调用静态扫描不出来

目前的重排方案能够覆盖到 80%～90% 的符号未来我们会尝试编译期插桩等方案來进行 100% 的符号覆盖，让重排达到最优效果

目前，在缺少业界经验参考的情况下我们成功验证了二进制txt文件乱码重排方案在 iOS APP 开发中的可荇性和稳定性。基于二进制txt文件乱码重排我们在针对抖音的 iOS 客户端上的优化工作中，获得了约 15% 的启动速度提升

抽象来看，APP 开发中大家會遇到这样一个通用的问题即在某些情况下，APP 运行需要进行大量的 Page Fault这会影响代码执行速度。而二进制txt文件乱码重排方案目前看来是解决这一通用问题比较好的方案。

未来我们会进行更多的尝试让二进制txt文件乱码重排在更多的业务场景落地。

本文转载自公众号字节跳動技术团队（ID：toutiaotechblog）