Swift 首次调试断点慢的问题解法 | 优酷 Swift 实践

作者：段继统 & 夏磊

调试断点是与开发体验关系最为密切点之一，优酷iOS团队在外部调研时候发现，大量国内的iOS APP研发团队也遇到了类似的问题。考虑到国内Swift如火如荼的现状，我们尽快整理了该方案并通过本文分享出来，希望能在这个问题上帮助到大家。

前言

众所周知，Swift是苹果公司于2014年苹果开发者年会（WWDC2014）上发布的编译式新开发语言，支持多编程范式，可以用来撰写基于macOS、iOS、iPadOS、watchOS和tvOS上的APP。对于广大iOS开发同学来说，这也是研发未来iOS APP开发必须要掌握的语言技能。Swift语言在发布后的数年里得到了飞速发展，在2019年苹果发布了Swift5.0版本并宣告Swift ABI稳定。

在Swift5.0版本的ABI稳定后，Swift正式具备了完善的生产研发基础，优酷iOS研发团队也开始进行优酷iOS、iPadOS版本的Swift迁移。优酷在被阿里巴巴收购后，获得了大量集团移动基建和中间件的支持，因此优酷iOS App在持续演化数年后，基本成为标准的大型组件化工程，由数十个垂直团队负责各自业务并行开发。其中，优酷播放详情页场景是最重要的视频内容消费场景，也率先在2020年初开始业务页面框架、播放器框架及业务模块的Swift迁移。

2020年底，优酷iOS消费团队完成了业务页面框架和播放器框架的Swift化，这两个框架代码量较少，内部代码结果合理清晰，而且对外部依赖较少。因此在完全Swift化后，性能上得到了提升，并且得益于Swift的优秀语法，团队开发业务需求代码行数下降，团队效能也获得了增幅。整个过程都比较顺畅，也并未遇到明显的工程开发或者质量问题。

进入2021年后，在业务页面框架及播放器框架Swift版本的基础上，优酷iOS团队全面启动了业务层代码Swift迁移，而在这个阶段，Swift调试断点慢的问题开始出现并日趋严重。 在视频内容场景，核心主业务模块代码7万多行，外部依赖各种模块达200以上，在这个业务模块里，首次断点的时间恶劣情况下可以达到180秒以上，团队研发效率被严重制约。

2022年初优酷iOS团队完成了80%以上业务代码的Swift迁移，调试首次断点慢的问题已经成为业务场的效率瓶颈。在内部的研发幸福感问卷调查里，97%的iOS开发同学认为调试首次断点慢是目前研发过程的最大痛点，这个问题给iOS研发同学带来的挫败感，足以打消Swift的其他优势。因此，解决这个问题也成为优酷iOS团队年度首要目标。

调试首次断点慢现象及初步分析

Swift调试断点慢主要现象是，当Xcode工程运行起来之后，我们进行首次断点的等待时间会特别漫长。大部分情况下，工程首次断点生效后，第二次及后续断点的等待时间都十分短暂，基本可以认为无等待时间。不过从团队内部收集的情况来看，不同Mac电脑开发设备和不同的iOS设备表现不全一致，部分同学首次断点之后进行断点的等待时间也极其缓慢。

这个现象或者说问题在团队内部频繁出现后，我们首先与外部资深iOS开发团队交流，并附上了详细的工程文档。对方也基于反馈在内部进行了调查和验证，并最终给我们答复，表示内部并没有类似问题的发现。在交流过程中我们发现，其内部的大型APP工程模式都是传统的单工程模式，与国内的组件化多个工程模式截然不同。基于各方面汇总信息，我们对这个问题开始进行初步分析和解决。

从下表中可以分析，播放器框架模块和播放主业务模块情况结合断点时间来看，断点时间似乎与外部依赖数量呈现等比关系，所以可以初步断定断点时间和外部依赖数量存在较强的相关性。

另外还有一个现象，如果子工程和壳工程所依赖SDK的module没有对齐，lldb会很快断点生效，但是打印报错信息，同时无法po任何值。通过此现象也可以初步分析出来，在断点时lldb对子工程依赖的module进行了扫描。

但仅仅依赖表象分析还不够，所以后续的工作我们从两个方向着手，第一是从播放主业务模块的解耦测试，快速解耦播放主业务模块的外部依赖，测试耦合数量的减少对断点时间是否