ABC 文件
ABC（Ark Bytecode，方舟字节码）是由鸿蒙的方舟编译器编译 ArkTS/TS/JS 生成的字节码文件，也就是可被解析执行的二进制文件，以 .abc 作为后缀名。
ABC 文件包含应用所有的逻辑，类、方法、字段、调试信息、字符串、字面量等数据都在其中，通过分析这个文件，就可以逆向鸿蒙应用。鸿蒙应用的反汇编和反编译器都是通过分析此文件来获取应用的所有信息，反汇编器由鸿蒙自带，名为 ark_disasm，反编译器目前在 Github 上有一个开源工具叫 abc-decompiler，它们的输入都是 ABC 文件。
未经保护的 ABC 文件能够被逆向出应用的所有信息，为了提升应用的安全性，防止核心逻辑被轻易逆向，开发者可以考虑使用专业的加固方案对 ABC 文件进行保护，如 Virbox Protector 就将支持鸿蒙应用的加固保护。
HAP
一个 HAP 是由代码、资源、第三方库及应用配置文件组成的模块包，分为 entry 和 feature 两种模块类型：
- entry ：应用的主模块。一个APP中，对于同一设备类型必须有且只有一个entry类型的HAP，可独立安装运行。
- feature ：应用的动态特性模块。一个APP可以包含一个或多个feature类型的HAP，也可以不含。只有包含Ability的HAP才能够独立运行。
一个 HAP 包的典型结构如下：
entry_default
├─ets
│ ├─modules.abc
│ └─sourceMaps.map
├─libs
│ └─arm64-v8a
│ └─libentry.so
├─resources
│ └─base
│ ├─media
│ │ ├─app_background.png
│ │ ├─app_foreground.png
│ │ ├─app_layered_image.json
│ │ ├─background.png
│ │ ├─foreground.png
│ │ ├─layered_image.json
│ │ └─startIcon.png
│ └─profile
│ ├─backup_config.json
│ └─main_pages.json
├─.pages.info
├─module.json
├─pack.info
├─pkgContextInfo.json
└─resources.index
ets 目录包含应用的核心代码，所有业务逻辑都在这里。其中，modules.abc 就是 ArkTS 源代码编译后的字节码，sourceMaps.map 则是各个源文件的一些信息。
libs 目录放置应用引入的 so 库，支持多架构，每个架构放到对应的目录下。
resources 目录放置应用的资源文件，图片、配置、页面信息、音频等等文件都在这个目录下面。
根目录下的配置文件共同构成了应用的核心元数据体系。module.json 文件定义了模块的基本信息、Ability 配置和权限声明。pack.info 记录了应用包的版本、目标设备等基础信息，pkgContextInfo.json 则详细描述了包的构建环境和依赖关系。resources.index 文件通过建立资源索引来优化资源加载性能，而 .pages.info 文件则维护着应用内部的路由导航信息。
以下是 pack.info 中的内容：
{
"summary": {
"app": {
"bundleName": "com.example.arks",
"bundleType": "app",
"version": {
"code": 1000000,
"name": "1.0.0"
}
},
"modules": [
{
"mainAbility": "EntryAbility",
"deviceType": [
"phone",
"tablet",
"2in1",
"wearable"
],
"abilities": [
{
"name": "EntryAbility",
"label": "$string:EntryAbility_label"
}
],
"extensionAbilities": [
{
"name": "EntryBackupAbility",
"forms": []
}
],
"distro": {
"moduleType": "entry",
"installationFree": false,
"deliveryWithInstall": true,
"moduleName": "entry"
},
"apiVersion": {
"compatible": 18,
"releaseType": "Release",
"target": 18
}
}
]
},
"packages": [
{
"deviceType": [
"phone",
"tablet",
"2in1",
"wearable"
],
"moduleType": "entry",
"deliveryWithInstall": true,
"name": "entry-default"
}
]
}
从这个文件可以清晰地看到应用的包名、版本、目标设备类型以及模块的关键信息。
HAP 包可以通过 hdc install package_name.hap 安装到手机上运行。
HAR 和 HSP
HAR（Harmony Archive）是静态共享包，可以包含代码、C++库、资源和配置文件。通过HAR可以实现多个模块或多个工程共享ArkUI组件、资源等相关代码。但它不能独立安装运行在设备上，只能作为应用模块的依赖项被引用。HAP引用HAR时，在编译构建过程中系统会自动合并两者的权限配置。因此开发者无需在HAP和HAR中重复申请相同权限。
HSP（Harmony Shared Package）是动态共享包，包含代码、C++库、资源和配置文件，通过HSP可以实现代码和资源的共享。HSP不支持独立发布上架，而是跟随宿主应用的APP包一起发布，与宿主应用同进程，具有相同的包名和生命周期。多个HAP/HSP共用的代码和资源放在同一个HSP中，可以提高代码、资源的可重用性和可维护性，同时编译打包时也只保留一份HSP代码和资源，能够控制应用包的大小。并且，HSP在运行时按需加载，有助于提升应用性能，对于同一个组织内部的多个应用之间，可以使用集成态HSP实现代码和资源的共享。HSP也不能独立安装运行在设备上，需要与依赖该HSP的HAP一起安装/运行。
它们二者的差异如下：
| 特性 | HAR (静态共享包) | HSP (动态共享包) |
|---|---|---|
| 代码合并方式 | 编译时复制到依赖的HAP | 运行时按需加载，物理隔离 |
| 包体积影响 | 增加每个依赖HAP的体积 | 应用内共享一份，优化整体体积 |
| 运行时行为 | 随主包启动加载 | 支持按需加载，提升启动速度 |
| 更新机制 | 随HAP更新而更新 | 可独立于宿主应用进行更新 |
| 典型场景 | 工具类、UI组件、通用Utils | 大型功能模块、插件化设计 |
APP
APP 是用于上架鸿蒙应用商店的文件，HAP 则不用于上架，通常是本地调试安装使用。
每个鸿蒙 APP 都包含一个或多个 HAP 文件，并且有一个 pack.info 文件用来描述文件属性。
大多数鸿蒙应用程序至少包含一个“Entry”类型的HAP文件作为应用程序的主要模块，以及附加的“Feature”类型的HAP文件用于实现应用程序的功能。
APP 包其实是一个压缩包，包含了所有需要分发的 HAP、HSP 以及签名信息，上架应用商店的 APP 包必须使用正式的发布证书进行签名，这与本地调试使用的调试签名不同，是应用安全性和完整性的重要保障。
总结
从开发到分发，鸿蒙应用的模块化体系清晰而高效：ArkTS/JS 源码被编译为 ABC 字节码；ABC 与资源、配置一起被打包成 HAP 或 HSP 模块；模块之间通过 HAR 共享静态代码；最终，所有必要的模块被签名并打包成 APP 文件，用于上架和分发。