ios包体积管理方案

iOS 包体积优化是一个系统性的工程，需要从代码、资源、第三方库、构建配置等多个维度进行综合管理。下面我将梳理一个全面的 iOS 包体积管理方案。

一、包体积分析

在进行任何优化之前，必须先了解 App 体积到底由什么构成。

使用 Xcode 的 App Thinning Size Report
- 操作：Archive -> Distribute App -> App Store Connect -> 选择 Ad Hoc 或 App Store -> Next -> 在 "App Thinning" 步骤选择 "All compatible device variants" -> Next。
- 结果：Xcode 会生成一个 App Thinning Size Report.txt 文件，详细列出了你的 App 在不同设备上的下载大小（Download Size）和安装大小（Installed Size），并按文件类型（如可执行文件、图片、 frameworks 等）进行了分类。这是最权威的分析工具。
手动检查 IPA 内容
- 将 .ipa 文件后缀改为 .zip 并解压。
- 进入 Payload/YourApp.app 目录。
- 在这里可以直观地看到 Frameworks 文件夹（第三方库）、Assets.car（图片资源）、Main.storyboardc（编译后的故事板）等。使用 "显示简介" 或 du -sh * 命令可以快速找出体积最大的目录或文件。
第三方工具
- Sourcery：虽然主要用于代码生成，但其 measure 命令可以帮助分析代码和资源的大小贡献。
- LSUnusedResources：扫描项目中未被引用的图片、音频等资源。
- FengNiao (凤凰)[可用]：另一个非常好用的查找无用资源的工具。

二、资源优化（通常是最大的优化空间）

图片资源优化
- 使用 Asset Catalog：将所有图片放入 Assets.xcassets。这能让 Xcode 在打包时进行优化，并在上传到 App Store 后，Apple 的服务器会根据用户设备只提供 2x 或 3x 资源（Slicing）。
- 压缩图片：
  * 工具：使用 ImageOptim, Squoosh, TinyPNG, ShortPixel 等工具对图片进行无损或有损压缩。
  * 格式选择：
  * 对于有透明通道的图片，使用 .png。
  * 对于照片或没有透明通道的复杂图片，优先使用 .jpg，通常体积小很多。
  * 考虑使用新一代图片格式，如 AVIF (iOS 16+) 或 WebP (iOS 14+)，它们能提供比 PNG/JPG 更高的压缩率。
- 使用矢量图：对于图标、Logo 等简单图形，强烈建议使用 SVG 格式。可以通过 UIImage(named:) 直接加载（iOS 13+），或者使用 SF Symbols (iOS 13+)。矢量图无限缩放且文件体积极小。
- 清理无用图片：定期使用 LSUnusedResources 或 FengNiao 扫描并删除未被引用的图片。
代码与界面文件优化
- 清理无用代码：
  * 定期审查项目，删除不再使用的类、方法、属性。
  * 开启 Dead Code Stripping (在 Build Settings 中)，让编译器自动移除未被调用的代码。
- Storyboard 和 XIB 优化：
  * 合并或拆分过大的 Storyboard，避免单个 Storyboard 包含过多页面。
  * 检查并移除 Storyboard/XIB 中未使用的 IBOutlet 和 IBAction。
- 字体文件：
  * 只嵌入 App 中真正用到的字体，不要一股脑全加进去。
  * 如果只用到某个字体的部分字符（如数字、英文），可以使用工具对字体文件进行 “瘦身”，只保留需要的字符。
多媒体和数据文件
- 压缩音视频：使用 HandBrake 等工具对 App 内的视频进行压缩，在保证可接受质量的前提下减小文件大小。
- 按需下载：对于较大的视频、音频、离线地图数据包或游戏关卡等，不要打包进 IPA，而是在 App 首次启动后或用户需要时从服务器下载。

三、代码与架构优化

减少可执行文件大小
- 避免过度封装和冗余代码：保持代码简洁，警惕 “为了设计而设计”。
- 优化第三方库：
  * 评估必要性：每次引入一个库前，问自己是否真的需要它。很多功能（如网络请求、JSON 解析）用原生 API 就能实现。
  * 选择轻量级替代品：例如，用 URLSession + Codable 替代 Alamofire + SwiftyJSON (如果项目简单)。
  * 模块化引入：一些大型 SDK（如地图、统计）提供了模块化安装，只引入你需要的模块。
  * 避免动态库滥用：动态库（.framework）会增加 App 的启动时间和下载体积（因为需要包含 Frameworks 文件夹）。如果可以，优先选择静态库（.a）或直接将代码集成到主工程。
- Build Settings 优化：
  * Strip Debug Symbols During Copy：在 Release 模式下设置为 YES，移除可执行文件中的调试符号。
  * Deployment Postprocessing：设置为 YES。
  * Enable Bitcode：设置为 YES。这允许 Apple 在你上传后对二进制文件进行二次优化，通常能减小最终用户下载的大小。
  * Architectures：确保只包含必要的架构（如 arm64），排除 armv7 以支持旧设备。

四、构建与分发策略

采用 App Thinning
- Slicing：自动为不同设备型号提供不同的资源包。
- Bitcode：如上所述，允许 Apple 重新编译优化。
- On-Demand Resources (ODR)：对于非核心资源（如帮助文档、某个特定主题的图片、游戏的额外关卡），使用 ODR。这些资源不会包含在初始下载的 IPA 中，而是在 App 需要时由系统自动下载。
使用 Git LFS 管理大文件
- Git LFS (Large File Storage) 可以将大文件（如 PSD、大型素材库、.dSYM 文件）存储在外部服务器上，Git 仓库中只保留一个小的指针文件。这对于团队协作和保持仓库轻量化至关重要。

五、持续集成与监控

将包体积检查纳入 CI/CD 流程
- 在你的 Jenkins、GitHub Actions 或 GitLab CI 流程中，每次构建后都生成并解析 App Thinning Size Report。
- 设置阈值告警。例如，如果包体积超过 150MB，就触发一个警告或阻止合并，促使团队分析原因。
定期回顾与优化
- 包体积管理不是一次性的任务。在每个迭代周期结束后，都应该花一些时间回顾一下体积变化，分析新增功能对体积的影响，并进行持续优化。

总结

iOS 包体积管理是一个持续的、需要团队全员参与的过程。你需要：

分析：用 App Thinning Size Report 找到体积的 “元凶”。
优化：
- 资源：压缩、清理、使用合适的格式（SVG, WebP/AVIF）。
- 代码：清理无用代码，审慎引入第三方库。
- 配置：正确设置 Build Settings，开启 Bitcode。
策略：利用 App Thinning 和 On-Demand Resources 来减小用户的初始下载大小。
监控：将体积检查自动化，并定期回顾。

通过以上这些方法，你完全可以将一个几百兆的 App 优化到一个非常理想的大小。

《ios包体积管理方案》是转载文章，点击查看原文。