技术的路，总是在摸索中前进
写这篇文章的时候，我正坐在公司茶水间的角落，手里端着一杯冷掉的美式。窗外北京的晚风已经带着一点秋天的凉意，手机震动了一下，是测试组发来的消息：“新版本上线后，用户反馈体验很流畅”。看到这句话，我不禁笑了笑，想起这半年来为了优化性能、提高用户体验所经历的一切。
作为一名有5年工作经验的iOS工程师，我参与过多个项目的开发和维护工作。从刚入职时跟着老大改Bug的小菜鸟，到现在能够独立负责模块设计甚至主导技术选型，一路走来磕磕绊绊不少，但更多的是成长与收获。
今天我想聊一聊我在实际工作中遇到的技术挑战，以及我们团队在探索过程中所做的尝试和思考。
背景：一个老项目的新问题
事情要从2023年初的一个旧项目说起。我们接手了一个已经运营了三年的社区类App，最初架构比较简单，采用的是MVC模式，大部分业务逻辑都在ViewController里完成。随着功能越来越多，代码量也迅速膨胀，到了后期维护起来非常吃力，尤其是页面卡顿严重、崩溃率上升的问题频频被用户吐槽。
我们做了详细的Crash日志分析和性能监控统计，发现主要问题集中在三个方面：
- 界面渲染卡顿：大量数据加载和UI刷新操作没有合理调度。
- 内存占用偏高：图片缓存策略不合理，导致OOM频繁。
- 网络请求管理混乱：多个接口并行调用无序，重复请求频发。
更麻烦的是，这个App的版本更新频率并不高，用户分布广泛，旧系统（如iOS 12）占比不小，对新技术的支持存在限制。
面对这些问题，我们需要重新思考整个App的架构和性能优化方向，而不仅仅是头痛医头式的“修修补补”。
探索：如何优雅地重构一个老工程？
首轮尝试 —— 局部重构+组件化
最开始，我们选择了局部重构的方式，先从一些高频交互页面入手，比如首页Feed流、用户个人中心页等。
我们在这些页面上尝试引入了：
- MVVM + Combine：用于更好地解耦ViewModel和View之间的关系
- UICollectionViewDiffableDataSource：代替老旧的reloadData机制，提升列表滚动流畅度
- SDWebImage + LRU缓存策略：对图片加载进行统一管理，减少重复下载
但很快我们就发现，这种“局部美化”的方式并没有真正解决根本问题。因为整个工程还是基于传统的MVC架构，各个模块之间依赖复杂，很难形成清晰的边界。
而且我们还遇到了兼容性问题。例如Combine只能支持iOS 13及以上，而项目需要兼容到iOS 12，这就导致我们不得不做一套条件编译的适配方案，增加了维护成本。
第二轮尝试 —— 架构升级 + 模块化治理
于是我们决定换个思路，从整体架构出发进行改造。目标是实现以下几个关键点：
- 分离业务逻辑与UI层，提高可测试性
- 明确模块间通信机制，降低耦合度
- 实现代码复用，避免重复造轮子
最终我们选择采用一种“轻量级的VIPER架构”，配合CocoaPods做模块化拆分。这里并不是完全照搬标准的VIPER模板，而是结合了团队实际情况进行了简化：
- View -> UIViewController
- ViewModel -> Interactor（处理业务逻辑）
- Presenter -> ViewModel（处理UI转换逻辑）
- Router -> Coordinator（负责导航跳转）
同时我们引入了R.swift来增强资源引用的安全性，使用SwiftLint规范代码风格，通过CI自动化流程保证每次提交的质量。
在模块划分上，我们将整个App划分为：
- Home模块（首页）
- Profile模块（用户中心）
- Message模块（消息通知）
- Common模块（基础工具&样式表）
每个模块内部职责明确，对外暴露服务接口。跨模块通信通过Protocol + Dependency Injection方式完成。
这样不仅提升了开发效率，也为后续的多人协作打下了基础。
实践中的小插曲：谁动了我的内存？
说到内存问题，我还记得有一次线上报警，用户反馈进入某个页面就闪退。我们查看Crash日志发现是因为内存爆掉了。
当时我们用了Instruments工具进行分析，发现一个诡异的现象：每次滑动列表，内存使用量就会“蹭蹭”上涨，但又不会立刻释放。
深入排查后才发现，是我们之前为了“省事”在UITableViewCell中持有了ViewModel对象，而ViewModel本身引用了网络请求的闭包。结果就是TableViewCell没被释放，整个链路上的对象都无法释放，造成了循环引用。
修复的过程也不复杂，只需要把ViewModel的持有改为弱引用即可。但这给了我一个深刻的教训：不要图一时方便而忽视内存管理的细节，尤其是在复杂的视图结构中。
效果总结：优化不是目的，而是手段
经过大半年的努力，我们完成了核心模块的重构，并陆续推送到线上。最终效果如下：
| 指标 | 优化前 | 优化后 | 提升幅度 |
|---|---|---|---|
| 页面首次加载时间 | 1.4s | 0.8s | ↓42% |
| 列表滑动帧率 | 45fps | 57fps | ↑26% |
| 内存峰值 | 320MB | 240MB | ↓25% |
| 崩溃率 | 0.7% | 0.15% | ↓78% |
更为重要的是，我们的代码质量有了显著提升。单元测试覆盖率从原来的12%提升到了45%，CI构建成功率稳定在98%以上。
更重要的是，现在新人加入团队后，可以更快地上手核心模块的开发，而不像以前那样“看着ViewController里的几千行代码发懵”。
我的一些建议与经验分享
在这次重构和性能优化的过程中，我总结出了一些个人的经验，也踩了不少坑，希望可以帮到你：
1. 技术选型不求“新”，只求“稳”
在老项目改造中，盲目追求新技术往往会导致更多兼容性和维护上的负担。比如我们虽然想用SwiftUI重写部分界面，但考虑到项目需要支持iOS 12，只能放弃。
选型时要充分考虑：
- 当前用户的系统分布情况
- 团队成员对新技术的熟悉程度
- 是否有足够的文档/社区支持
有时候，稳妥比激进更能带来长期收益。
2. 重构是一场持久战，别想着一蹴而就
很多同学刚开始重构就想一口气把整个项目推翻重来，结果往往是半途而废。正确的做法是：
- 选定几个关键路径优先重构
- 边重构边验证，每一步都保留回滚的能力
- 不要让重构阻碍日常需求的交付
3. 性能优化一定要结合数据分析
很多人优化只是凭感觉，比如觉得“这个地方加个预加载应该会变快”。但实际上如果不借助Instruments、Time Profiler、Allocations等工具去量化数据，很容易白忙一场。
4. 工程文化很重要，别忽略它
一个好的工程实践环境，比如规范的代码Review流程、完善的CI/CD机制、可靠的监控系统，不仅能提高效率，还能大大减少人为错误的发生。
尾声：技术探索，永远在路上
写了这么多，其实想说的是——技术从来都不是一劳永逸的事，尤其是在移动开发这个行业，变化太快了。每一个选择背后都有权衡，每一次优化都需要沉淀。
在这个过程中，我也深刻体会到了一句话：“工程师的价值，不在于他会不会写代码，而在于他有没有解决问题的能力。”
未来的路还很长，可能还会遇到各种各样的问题和挑战。但我相信，只要保持探索的精神，不断实践、不断总结，就能走得更远。
如果你也在经历类似的问题，欢迎留言交流。毕竟，一个人走得快，一群人才走得远。
最后，这张图是我调试性能时的截图，记录了一次成功的优化过程
调试性能时的截图，帧率明显提升 😊
技术这条路，我们一起走下去吧！
评论 0