性能

包体积要看链接进去的东西

业务代码往往不是大头。镜像、资源、被整包拉进来的依赖才是。

安装包变大，下载转化和更新意愿都会差。先拆开看：可执行文件、Asset Catalog、本地化、内嵌框架、on-demand 资源。只盯着自己写的 Swift 文件行数，没有意义。

可执行文件

生成 Link Map，按 .o 和库排序。突然多出来的几百 KB，经常是一个依赖用静态库把 JSON 实现、图片库、一套日志一起链进来了。Swift 泛型特化、协议的 witness table 也会膨胀，但那通常是细水长流，不如先处理整库链入。

• 没有用到的架构不要打进包。现在真机发布只留 arm64。
• 确认 strip 开着，调试符号在 dSYM 里，不在可执行文件里。
• 同一套代码被主工程和多个动态框架各编译一次，体积会乘。公共代码收成一个地方，或者接受静态链接后的合并。

资源和本地化

图片用 Asset Catalog，让 App Store 做切片。不要把 @1x、@2x、@3x 的大图再以文件形式拷进 Bundle。没用的本地化字符串、旧的启动视频、测试用的 JSON，用构建脚本扫一遍。

可选功能放 On-Demand Resources 或后台下载，不要为了“离线也能用”把全年素材打进首包。首包只留第一屏和没有网络时必须有的部分。

依赖

加一个 SDK 之前看它的二进制大小和它会不会再拉起别的动态库。启动时间和包体积经常是同一批库：动态库多，dyld 慢，包也大。能换成系统框架就不要再嵌一份。

# 粗看可执行文件里谁占地方。细查再用 Link Map。
nm -ajU MyApp | wc -l
size -m MyApp
# 资源
du -sh MyApp.app/* | sort -h

每次发版记三个数：IPA 大小、可执行文件大小、Asset 大小。只记 App Store 上的“下载大小”会把切片和压缩混在一起，回归时不好比。