产物瘦身：strip 与 so 合并

包体积是应用的第一印象：市场页面上那个数字直接影响下载意愿。桌面移植应用背着整个框架栈，体积治理是必修课。这篇讲瘦身的两板斧：strip 与 so 合并。

▍先测量
把包解开按体积排序：库文件、资源、字体、可执行。找出前十大，治理从它们开始。常见分布：框架栈库占一半以上、字体其次、图片资源第三。

▍strip 的正确姿势
符号剥离要分两步走：发布库做动态符号表的必要剥离（调试符号、注释），但保留动态符号表本身（运行时链接靠它）。工具链自带的剥离工具对交叉编译产物可用，但要警惕打包工具链的自动剥离——它会把预编译库的段结构破坏（这在打包篇有专述），统一在库构建侧做剥离，打包侧关闭自动动作。剥离后的库要重新验证加载。别忘保留剥离前的符号版本归档（符号包），崩溃回溯的命根子。

▍so 合并的取舍
小库合并成大库减少加载开销与体积冗余（重复的段头、元数据）。收益与代价：收益是动态加载次数减少（启动提速）、元数据开销摊薄；代价是合并边界要清晰（依赖关系乱的库合并后符号冲突）、更新粒度变粗（一个小改要换大库）。适合合并的是同框架同更新节奏的一族小库；应用本体与插件类保持独立。

▍资源与字体的瘦身
字体子集化是大头：中文字体全集二十多 MB，按应用实际用字做子集（注意生僻字与用户输入场景的兜底——编辑类应用不能激进子集化）。图片统一压缩格式与分辨率档位；测试资源与演示文件坚决不进包；翻译文件里没启用的语言剔除。

▍预算制度
定体积预算线（比如 200 MB 硬顶，150 MB 目标），每次发布对比，超线必须专项治理。瘦身成果要防回弹：新增依赖时评审体积影响，加一个库五 MB 的事故要有人拍板。

▍验收
瘦身后全功能回归（字体子集化的应用要专门测文字渲染覆盖）、包体对比报告进发布记录。

有疑问欢迎在本板块直接发帖，我们会逐条回复。