前阵子发版后，老板盯着应用商店后台直摇头。安装包体积突破了 100MB，导致下载转化率直线下滑。这周我给自己定了个死任务：在不砍功能的前提下，把包体积压缩到一半。从代码拆分到资源压缩，这是一场与研发习惯的持久战。

拆离主包的动态下发
审查项目结构时，我吓了一跳：原本只给 10% 用户使用的短视频模块，居然占了 40MB 的空间，而且和主业务紧紧耦合在 Entry 模块里。
我们必须把这个模块抽离成 HSP（动态共享包）。建好 Library 后，将短视频相关代码全盘迁移过去。关键在于配置文件的改动：

json5

// 在短视频模块的 module.json5 中
"deliveryWithInstall": false, // 不随主包一起下载

配合主模块的依赖声明，在打包时，这部分代码就不会被打进基础安装包，而是等用户真正点击短视频入口时，系统再动态下发。这一招直接砍掉了接近 40MB 的体积。

资源格式的全面平替
代码剥离完，剩下的重灾区就是图片资源。几百张切图以 PNG 格式躺在工程目录里，单张动辄好几兆。
我写了个脚本，利用构建工具将所有的静态 PNG 无损转为 WebP 格式。鸿蒙系统原生支持 WebP 渲染，体积能直接缩减 30% 到 70%。对于不需要透明背景的大图，甚至可以直接转为 JPEG。仅仅这一项操作，又省出了将近 20MB。

多语言按需打包策略
项目为了出海，引入了十几套多语言资源。但在这个版本中，我们其实只面向国内用户。
在 module.json5 里，通过 resource 字段限制打包范围：

json5

"resource": {
  "locales": ["zh_CN", "en_US"] // 只保留中文和英文
}

没有被包含进来的小语种资源文件，在编译阶段会被彻底剔除，避免无意义的体积浪费。

开启代码混淆与资源摇树
以前为了防止报错，一直把混淆关着。这次开启 -enable-property-obfuscation 后，不仅代码变得连篇累牍难以阅读，构建工具还顺便启动了资源摇树（Tree Shaking）机制。
那些没有被代码引用的废弃图片、甚至是一些未使用的三方库组件，在编译时被识别出来并自动踢出了安装包。这里必须注意，开启混淆后，要仔细检查实体类的序列化代码，必要时在 obfuscation-rules.txt 中添加白名单，防止后端数据解析失败。

打开你的工程配置，检查是否有超过 1MB 的单张图片。如果有，尝试将其转换为 WebP 格式替换。随后查看构建产物报告，看看包体积有没有立竿见影的下降。