HAP 打包与 native 库布局

HAP 是鸿蒙应用的分发格式。桌面移植工程的 HAP 有自己的特殊性：壳很小，native 库很重。这篇讲打包与库布局的纪律。

▍HAP 的结构
一个 HAP 里：ArkTS 编译产物、资源（图片、rawfile）、配置清单、native 库目录（按 ABI）、签名块。对移植工程，真正的大头是 native 库目录：几十上百个 so，从框架栈到应用本体全在里面。

▍库布局的三条纪律
一，运行时动态加载的库全部走预编译库目录整体收入，不进 hvigor 闭包——闭包机制会静默丢弃它不认识的库，装机后动态加载找不到模块是这类问题的标准症状。二，加载顺序按依赖拓扑：启动器按序动态加载，顺序错了是未定义符号报错。三，库清单白名单：打包脚本核对进包的库列表与预期一致，多一个少一个都报错——防两类事故：缺库装机崩、多库包膨胀（跟随链接把整个前缀拖进来是真实发生过的）。

▍ELF 的坑
打包工具链对 ELF 有两处危险动作：符号裁剪会把预编译库的段对齐重排成非法格式，设备加载即崩且无日志——裁剪选项必须关；权限段注入工具同样会破坏对齐，注入后要重跑对齐修复。另外，musl 加载器对动态段要求严格：NEEDED 条目带版本号在 Linux 上能忍，在 musl 上直接拒载，依赖名一律去版本号处理。

▍rawfile 与资源
应用携带的数据资产（字体、翻译、种子数据）走 rawfile 通道，首次启动部署到应用数据目录后使用。rawfile 里的文件在包内是原样存储的，注意隐藏文件（点开头）在部分打包通道会被过滤，资源命名避开。

▍体积治理
ABI 只留 arm64；按 ABI 无关的资源去重；大库做符号级裁剪要在打包前完成并验证；测试用的数据文件别进正式包。包体超过市场建议线要专项瘦身。

▍验收
出包后三查：包内库清单核对、装机加载全绿（无加载失败日志）、首启画面正常。三查过后这个包才叫可分发。

免费无广告的安装包可以在官网下载体验。