鸿蒙应用包体积瘦身实战：从120MB到65MB的HAP拆包与资源裁剪

上个月应用市场审核反馈，我们的鸿蒙原生应用安装包体积达到了120MB，虽然没超限，但下载转化率明显低于竞品。用户的耐心是有限的，包越大，流失越多。于是我们启动了一轮包体积专项治理，最终把HAP包压到了65MB，冷启动时间也顺带降了约200ms。记录一下完整的瘦身路径。

一、 先看清楚“胖”在哪里

DevEco Studio自带 AppAnalyzer 工具，可以直接分析HAP包内各目录的占比。我们跑了一遍，结果很扎心：

resources/rawfile 占 48MB（主要是内置的演示视频和两套高清引导图）

libs/arm64-v8a 占 32MB（三方SDK的so库）

resources/base/media 占 18MB（未压缩的PNG图标）

二、 三刀切下去

1. 资源动态化：rawfile 不该进包
那48MB的演示视频和引导图，完全没必要随包下发。我们改为首启动时从华为云OBS按需下载，本地只保留一张低分辨率占位图。仅这一项就砍掉了45MB。

typescript
// 首次启动时按需下载资源到沙箱，而非打包进HAP
import { request } from '@kit.BasicServicesKit';
import { fileIo } from '@kit.CoreFileKit';

async function downloadGuideVideo() {
  const file = fileIo.openSync(`${getContext().filesDir}/guide.mp4`, fileIo.OpenMode.CREATE | fileIo.OpenMode.READ_WRITE);
  await request.downloadFile(getContext(), {
    url: 'https://your-obs-bucket/guide.mp4',
    filePath: file.path
  });
}
2. so库精简：只保留arm64-v8a
鸿蒙NEXT设备全是ARM64架构，armeabi-v7a和x86的so库纯属历史包袱。在 build-profile.json5 中显式指定ABI过滤：

json5
"buildOption": {
  "externalNativeOptions": {
    "abiFilters": ["arm64-v8a"]
  }
}
这一刀又省了约10MB。

3. 图片资源：WebP + 按密度裁剪
把resources/base/media下所有PNG转为WebP（无损转换，肉眼无差别），体积平均降70%。同时检查resources目录，删掉了只在高密度屏使用的重复图，改用矢量图（SVG）替代简单图标。

三、 效果与反思

最终HAP从120MB降到65MB，下载转化率一周内回升了约12%。更重要的是，因为包内资源减少，应用安装后的首次启动IO读取量下降，冷启动时间从1.6秒降到了1.4秒。

总结一条原则：能动态下发的绝不进包，能矢量化的绝不位图，能单ABI的绝不多架构。 鸿蒙的资源管理机制很灵活，善用rawfile动态下载和ABI过滤，包体积控制其实并不难。