一文速通鸿蒙开发

应用程序包结构

1、一个应用可以包含一个或多个module，module是HarmonyOS基本功能单元，每个module都可以独立编译和运行；module分为ability和library两种类型，ability编译后为可安装的hap文件，library编译后为har或hsp

2、Hap:HarmonyOS安装的基本单位，分为entry和feature两种类型，在module.json5中的type字段进行配置

        (1)  Entry:应用主模块，用于配置入口界面、图标、主特性功能等，在同一个应用中，同一设备类型只能有一个entry类型的HAP

        (2)  Feature：动态特性模块，一个应用可以包含一个或多个此种类型的HAP，可以配置成按需下载安装或随着主模块一起下载安装。

3、Bundle、bundleName:由一个或多个.hap文件组合在一起称为Bundle，其中的bundleName是应用的唯一标识，该唯一标识在app.json5中进行配置。

4、.app文件：应用最终上架的文件格式，在云端分发和终端设备安装时，仍然是以HAP为单位进行分发和安装。

5、打包后的HAP文件结构包括ets、libs、resources等文件夹和resources.index、module.json、pack.info等文件

        (1)  ets目录用于存放应用代码编译后的字节码文件。

        (2)  libs目录用于存放库文件。库文件是HarmonyOS应用依赖的第三方代码（.so二进制文件）。

        (3)  resources目录用于存放应用的资源文件（字符串、图片等），便于开发者使用和维护。

        (4)  resources.index是资源索引表，由IDE编译工程时生成。

        (5)  module.json是HAP的配置文件，内容由工程配置中的module.json5和app.json5组成。

        (6)  pack.info是Bundle中用于描述每个HAP属性的文件，例如app中的bundleName和versionCode信息、module中的name、type和abilities等信息，由IDE工具生成Bundle包时自动生成。

多HAP机制

1、模块化管理，解耦，通过entry+feature组合，实现不同的设备安装不同的模块，例如有主模块+扫一扫+列表，其中手表不支持扫一扫，就可以把扫一扫独立为feature模块，选择不部署在手表上

2、方便应用资源共享，减少程序包大小。多个HAP都需要用到的资源（包括公共资源文件、公共页面等）以及so（shared object）文件可以放到单独的HAP中，其他HAP可以到该HAP中访问资源和so文件，也一定程度上可以减少应用程序包大小。

3、IDE开发视图

        (1)  AppScope:名称不可更改，该目录下存放全局资源和配置信息，资源文件名称不可与其他模块的资源名称相同。

                ①   Resource:放置应用的图标资源和应用名称字符串资源

                ②   App.json5:配置应用的全局信息，例如包名、应用图标、名称、SDK版本等

        (2)  entry或者feature目录：名称可自定义，业务开发模块。

                ①   Ets:开发者业务逻辑

                ②   Resource：放置该module所需使用的资源

                ③   module.json5：配置该Module的描述信息，如：Module的名称、Module的入口代码路径、包含的组件信息等

4、编译后的打包视图

        (1)  Ets：arkts编译后的打包文件

        (2)  Resource：AppScope下的资源文件会分别合入到module中。

        (3)  Module配置文件：AppScope下的app.json5文件字段分别合入到module.json文件中

5、每个开发状态的module都对应一个部署状态的HAP，所有HAP最终编译为一个app pack即可用于上架的.app文件

6、多HAP的开发调试与发布部署流程

7、App Pack（.app）文件不能直接安装在设备上

8、默认情况下，同一个包名下的所有UIAbility、ServiceExtensionAbility、DataShareExtensionAbility运行在同一个独立进程中，其他同类型ExtensionAbility分别运行在单独的进程，即hap和进程不是一一对应的。

9、只有系统应用才支持通过在module.json5文件中通过配置process标签来配置单独的进程

10、应用运行时，同一进程中的UIAbility组件被启动时，才会去加载对应的HAP的资源和代码。

11、多HAP运行在同一进程时，HAP之间的通信方式与同一HAP内的通信方式相同，使用线程间通信方式即可。

应用程序包更新流程

1、应用市场通知用户更新

2、应用内检测更新，然后跳转至应用市场进行下载

共享包

1、HAR：静态共享包，代码和资源跟随使用方编译，如果有多个使用方，在编译产物中则会有多个相同拷贝。通过HAR可以实现多个模块或多个工程共享ARKUI组件、资源等相关代码，不能独立安装，只能作为应用模块的依赖使用。

        (1)  HAR默认不开启混淆，需要在模块的build-profile.json5文件中的artifactType字段设置为obfuscation。

        (2)  HAR不支持在配置文件中声明abilities、extensionAbilities组件

        (3)  HAR不支持在配置文件中声明pages页面

        (4)  HAR不支持在build-profile.json5文件的buildOption中配置worker

        (5)  FA模型与Stage模型的HAR不支持相互引用

        (6)  Stage模型的HAR，不能引用AppScope内的内容。在编译构建时AppScope中的内容不会打包到HAR中，导致HAR资源引用失败

        (7)  待到出的文字在index.ets中配置，index.ets在oh-package.json5文件中通过main字段配置

        (8)  导入HAR依赖项目，在需导入的模块中oh-package.json5文件下的dependencies下，通过”文件夹名称”:”文件夹路径”

2、HSP：动态共享包，代码和资源独立编译，运行时，在同一个进程中也只会存在一份包文件。

        (1)  应用内HSP指的是专门为某一应用开发的HSP，只能被该应用内部其他HAP/HSP使用，用于应用内部代码、资源的共享。

        (2)  应用内HSP跟随其宿主应用的APP包一起发布，与该宿主应用具有相同的包名和生命周期。

        (3)  HSP是为了解决多个HAP引用相同的HAR，导致的APP包大小膨胀问题

        (4)  HSP是为了解决多个HAP引用相同的HAR，HAR中的一些状态变量无法共享的问题

        5)  HSP及其使用方都必须是Stage模型。

        (6)  HSP及其使用方都必须使用esmodule编译模式。

        (7)  HSP不支持在配置文件中声明abilities、extensionAbilities标签。

        (8)  HSP按照使用场景可以分为应用内HSP和应用间HSP，应用间HSP暂不支持。

快速修复

1、快速修复是HarmonyOS系统提供的一种不全量更新应用的情况下快速修复缺陷的一种技术手段。

2、快速修复的使用规则如下

        (1)  仅支持修复应用的TS和C++代码，对应的文件为.abc文件（TS编译后的文件）和.so文件（C++编译后的文件），不支持对资源的修复。

        (2)  不支持新增.abc文件和.so文件。

        (3)  快速修复包部署时要确保对应应用包已安装，如果未安装，则部署失败。

        (4)  快速修复包中配置的包名和应用版本号必须和已安装的包名和版本号应用相同，如果不同则部署失败。

        (5)  如果已经部署过快速修复包，新部署的快速修复包的版本号必须大于之前快速修复包的版本号，否则部署失败。

        (6)  快速修复包的签名信息和待修复的应用的签名信息必须一致，否则会部署失败。

        (7)  新的应用版本发布安装时，会清理掉快速修复包。

3、快速修复包格式包括.appqf(Application Quick Fix)和.hqf(Harmony Ability Package Quick Fix)两种。

4、快速修复包调试流程，IDE暂未集成快速修复的能力，只提供了命令行。

5、快速修复包发布部署流程

        (1) DevEco Studio：用于开发代码的项目工程的集成开发环境。在快速修复的工程中能够给予原应用的代码和修复问题后的代码生成快速修复包，并完成快速修复包的签名。

        (2) 应用市场服务器端：开发者将开发完成的快速修复包上架到该平台，平台会对上架的包进行签名验证、风险扫描和拆包重签名等，然后分发到客户端。

        (3) 应用市场客户端：用于接收应用市场服务器端分发的快速修复包，并触发安装快速修复包。

        (4) 包管理服务：设备上用于管理应用包及快速修复包安装和卸载的系统服务程序。

        (5) 快速修复引擎：设备上用于管理应用切换使用快速修复包的系统服务程序。如果应用正在运行，快速修复引擎接收到有快速修复包部署完成会通知应用切换快速修复包，进而使得应用使能快速修复包。

        (6) 文件系统：应用及快速修复包部署在设备上的位置。

ArkTS工程目录结构及应用配置文件

1、AppScope:存放全局资源和配置信息

        (1) resource:放置应用的图标资源和应用名称字符串资源

        (2) app.json5:配置应用的全局信息，例如包名、应用图标、名称、SDK版本等

                ①   应用的全局配置信息，包含应用的包名、开发厂商、版本号等基本信息

                ②   特定设备类型的配置信息

2、entry：工程模块，编译构建后为hap包

        (1) src > main > ets:用于存放ArkTS源码

                ①   entryability:应用/服务的入口，ability

                ②   page:页面

        (2) src > main > resource：放置该module所需使用的资源

        (3) src > main > module.json5：配置该module的描述信息，如：module的名称、module的入口代码路径、包含的组件信息等

        (4) build-profile.json5：当前的模块信息、编译信息配置项

                ①   Module的基本配置信息，例如Module名称、类型、描述、支持的设备类型等基本信息

                ②   应用组件信息，包含UIAbility组件和ExtensionAbility组件的描述信息

                ③   应用运行过程中所需的权限信息

        (5) hvigorfile.ts：模块级编译构建任务脚本，开发者可以自定义相关任务和代码实现

3、oh_modules：用于存放三方库依赖信息

4、build-profile.json5：应用级配置信息，包括签名、产品配置等

5、hvigorfile.ts：应用级编译构建任务脚本

资源分类与访问

1、base目录：该目录下的资源会被编译成二进制文件，并赋予资源文件ID，通过指定资源类型和名称访问，语法格式：$r('app.type.name')，例如:$r(‘app.string.name’)

        (1)  Element：用于存放字符串、颜色、布尔值等基础元素

        (2)  Media：媒体，如图片

        (3)  Profile：自定义配置文件

2、限定词目录：en_US和zh_CN是默认存在的两个限定词目录，其余限定词目录需要开发者根据开发需要自行创建，该目录下的文件意义同base目录

3、rawfile目录：支持创建多层子目录，子目录名称可自定义，支持各类资源文件，会被直接打包进应用，不会编译成二进制文件不会被赋予ID，通过指定文件路径和文件名使用，语法：$rawfile(‘filepath’)，其中filepath为rawfile目录下文件的相对路径，文件名需要包含后缀，路径开头不可以以"/"开头，例如$rawfile(‘test/a.txt’)

4、访问系统资源$r('sys.type.resource_id')

5、应用在使用资源时，会优先从限定词资源目录下寻找，寻找不到后再去base目录下寻找

6、rawfile是原始文件目录，不会根据设备状态去匹配不同的资源。

其它

1、在编译构建HAP时，DevEco Studio会从HAP模块及依赖的模块中收集资源文件，如果不同模块下的资源文件出现重名冲突时，IDE会按照AppScope->Hap自身->HAR的顺序进行覆盖。

2、鸿蒙开发包括FA模型和Stage模型，只介绍stage模型

参开链接

基于harmony开发指南整理

https://developer.huawei.com/consumer/cn/doc/harmonyos-guides-V2/start-overview-0000001478061421-V2

欢迎关注我的公众号