对于鸿蒙开发的初学者而言，了解 HarmonyOS 的一些基础理论知识尤为重要。
本篇文章汇总了关于鸿蒙移动应用开发的重要基础知识——HarmonyOS APP 和 HAP 的构成，希望能为鸿蒙开发的初学者们提供一定的帮助与启发。
一个 APP 由两种重要的元素组成——“HAP”与“pack.info”（一个 APP 通常带有多个 HAP）。
HAP 的全称为“HarmonyOS Ability Package”，它是 Ability 的部署包（即 HAP 内带有 Ability 组件），由于 HarmonyOS 的应用代码是围绕 Ability 组件展开的，所以鸿蒙应用开发的关键在于对 HAP 的实践与设计。
pack.info 由 IDE 编译生成，它有四个具体属性：
delivery-with-install：表示 HAP 是否支持随应用安装，如果配置为“true”，则表示支持随应用安装，如果配置为“false”，则反之。
name：表示 HAP 的文件名。
module：表示 HAP 的模块类型，分 entry 与 feature 两种，entry HAP 是主模块的 HAP，fea-ture HAP 是动态模块的 HAP。
device type：表示支持该 HAP 运行的设备类型。
HAP 是一个包含了代码，资源，第三方库和应用配置文件的模块包，它由 Ability，resourse，libs 和 config.json 这四个具体的部分构成。
前文也提到了，HAP 有两种模块类型，分别是 entry.HAP 与 feature.HAP。以下便是关于 Ability，resourse，libs 和 config.json 相关内容的介绍。
Ability 是个比较抽象的概念，它的定义是——一个应用所具备能力的抽象。前文提到过，HAP 中的相关应用代码是主要围绕 Ability 展开的，所以 HAP 中关于应用的代码主要用于构建相应的 Ability。
而 Ability 主要分两种类型：FA（feature Ability）和 PA（Paticle Ability）。
值得注意的是，FA 有 UI 界面（全称 User-Interface，指用户界面），而 PA 无 UI 界面。
总而言之，Ability 是应用组成的基本单元，在应用开发中占有重要地位，它能够为鸿蒙应用实现特定的业务功能。
libs 是一个重要的文件目录。要认识 libs，我们首先需要知道 HAR 的概念。
HAR，全称为 HarmonyOS Ability Resourse，可为 HAP 中的源代码，资源文件和 config.json 文件提供构建应用所需的所有内容。
而在 DevEco Studio 中，HAR 中的库文件主要储存在工程包的 libs 目录中。所以，libs 是用于存放 HAP 的库文件的核心目录。
resourses 是统一存放应用的资源文件（包括字符串，图片，音频等）的目录。
resourses 包括 base 目录与限定词目录：其中，base 目录用于定义颜色，圆角或图片；而限定词目录由一个或多个表征应用场景或设备特征的限定词组合而成，包括语言，文字，国家或地区，横竖屏，设备类型和屏幕密度等维度。
config.json 即为应用配置文件。应用的每个 HAP 的根目录下面都存在一个 config.json 文件，它主要涵盖了应用的全局配置信息，应用在具体设备上是配置信息和 HAP 包的配置信息。
值得一提的是：一个 APP 中可以包含多个 HAP，但必须含有 Entry.HAP；一个 APP 可包含多个 Feature.HAP，也可以不包含 Feature.HAP。
并且，只有包含 Ability 的 HAP 才能独立运行，图中的 FeatureB.hap 与 FeatureC.hap 内不含 Ability，故它们无法独立运行。另外，我们由图可以得出，HAP 由一个或多个 Ability 组成。
上面我们已经初步了解 APP 与 HAP 的内部结构。下面我们将详细地讨论 config.json 所包含的元素与子元素，以寻求对 HAP 的组成和工作原理更加深入的认识与理解。
配置文件的内部结构由 app，,deviceConfig 和 module 三部分构成，缺一不可。
app 对象的内部结构由 bundleName，vendor 和 version 三部分构成，当然也是缺一不可。
其中，bundleName 用于标识应用的包名，确保应用的唯一性，vendor 表示对应用的开发厂商的描述，version 则表示应用的版本号。这三者所涵盖的相关信息便构成了一个应用的全局配置信息。
deviceConfig 对象包含了具体设备上的应用配置信息，它的的内部结构可由 default（通用设备），phone（手机），tablet（平板），tv（智慧屏），car（车机），wearable（智能穿戴）等属性组成。
需要注意的是，deviceConfig 对象内一定要带有 default 属性，而其他的属性则可以被缺省。
phone 对象由四个属性组成，分别是 jointUserId，process，supportBackup 和 compressNativeLibs（图中未给出 jointUserId 与 process）。
其中，jointUserId 表示应用的共享 userId（通常情况下，不同的应用运行在不同的进程中，应用的资源是无法共享的，如果开发者的多个应用之间需要共享资源，则可以通过相同的 jointUserId 实现，前提是应用的签名相同），但当 API 的版本高于 3 时，该字段将不再予以配置。
process 表示应用或者 Ability 的进程名；supportBackup 表示应用是否支持备份与恢复，若对其配置为”false”，则不支持此功能。
CompressNativeLibs 表示 Libs 库是否以压缩存储的方式打包到 HAP 包，若配置为”false”，则 libs 库以不压缩的方式存储，那么 HAP 包在安装时就无需解压 libs，运行时会直接从 HAP 内加装 libs 库。
module 对象包含了 HAP 的五种配置信息：
package
name
description
supportedModes
deviceType
其中，package 表示 HAP 的包结构名称，它是采用反向域名格式命名的；name 表示 HAP 的包名，也采用反向域名的格式命名。
description 表示 HAP 的描述信息；supportedModes 表示应用支持的运行模式（当前仅定义了驾驶模式）；deviceType 表示允许 Ability 运行的设备类型（包括 phone，tablet，tv，car，wearable，liteWearable 等）。
module 对象的内部结构主要由 distro，ablilties，js，shortcuts，defPermissions 和 reqPermissions 共六个元素组成。
其中，distro 表示 HAP 发布的具体描述；abilities 表示当前模块内的所有 Ability；js 表示基于 JS UI 框架开发的 JS 模块集合；shortcuts 表示应用的快捷方式信息；defpermissions 表示应用定义的权限；reqPermissions 表示应用运行时向系统申请的权限。
distro 对象由 deliveryWithInstall，moduleName，moduleType 和 installationFree 四个属性构成。
其中，deliveryWithInstall 表示当前 HAP 是否支持随应用安装，若把此属性配置为 true，则表示支持此功能，若把此属性配置为 false，则反之。
js 对象由 name，pages，window，type 这四个属性构成。其中，name 表示 JS Conponent 的名字（默认值为 default）。
pages 表示 JS Conponent 的页面用于列举 JS Component 中每个页面的路由信息（页面路径+页面名称）。
window 用于定义与显示窗口相关的配置，并且：window 对象涵盖 designWidth 和 autoDesignWidth 这两个重要属性。
其中 designWidth 用于表示页面设计基准宽度，而 autoDesignWidth 用于表示页面设计基准宽度是否自动计算（当将其配置为 true 时，designWidth 项会被忽略，设计基准宽度由系统自动计算得出）。
type 表示 JS 应用的类型，若对其取值为 normal，则标识该 JS Component 为应用实例，若对其取值为 form，则标识该 JS Component 为卡片实例。
abilities 对象的核心属性包括七种：
name
launchType
visible
permissions
skills
type
orientation
其中，name 表示 Ability 的名称；launchtype 表示 Ability 的启动模式；visible 表示此 Ability 是否可被其他应用调用；permissions 表示其他应用的 Ability 调用此 Ability 时需要申请的权限。
abilites 的次要属性包括 description，icon，label，uri，readPermission，writePermission，mission，formsEnabled，forms九种。
其中，description 表示对 Ability 的描述，icon 表示 Ability 图标资源文件的索引；label 表示 Ability 对用户显示的名称；uri 表示 Ability 的统一资源标识符（对于 data 类型的 Ability 则不可缺省 uri）。
readPermission 表示读取 Ability 数据时所需要的权限；writePermission 表示向 Ability 写入数据时所需要的权限。
mission 表示 Ability 指定的任务栈（仅适用于 page 类型的 Ability）；formsEnabled 表示 Ability 是否支持卡片功能；forms 表示服务卡片的属性。
skills 对象的内部结构由 actions，entities 和 uris 三个属性组成。
forms 对象的内部结构由 name，description，isDefault，type 和 colorMode 五个属性组成。
其中，name 表示卡片的类名；description 表示卡片的描述；isDefault 表示该卡片是否为默认卡片（每个 Ability 有且只有一个默认卡片），若对其配置为 true，则该卡片设定为默认卡片，若对其配置为 false，则反之。
type 表示卡片的类型，共分为 Java（Java 卡片）和 JS（JS 卡片）两种；colorMode 表示卡片的主题样式，可取值为 auto（自适应），dark（深色主题）或者 light（浅色主题）。
我将阐述的最后一个元素是“HAP 与 HAR 的配置文件的合并”。如果应用模块中调用了 HAR，在编译构建 HAP 时，需要将 HAP 的 config.json 文件与一个或多个 HAR 的 cofig.json 文件合并为单个 config.json 文件。
在合并过程中，不同文件的同一个标签的取值可能发生冲突。此时则需要通过 mergeRule 来解决冲突。
以上便是对 config.json（即配置文件）所包含的元素与子元素的系统描述，相信读完这篇文章以后，你的心中也已经描摹好了一张关于 HAP 内部结构和功能的完整图谱。
鉴于笔者能力有限，文章如有错误和不足之处，希望读者批评指正。
👇扫码报名明晚的鸿蒙直播课👇
求分享
求点赞
求在看
