《鸿蒙应用开发实战培训》课件-第4章-鸿蒙应用程序开发基础

蒙蒙崛崛鸿鸿鸿蒙应用程序开发基础第四章起起目录目录CONTENTS项目中的文件包概述4.1DevEcoStudio及工程文件4.2章末知识概览4.3导图导图KNOWLEDGE4.1项目中的文件包概述前面介绍了如何创建鸿蒙的第一个应用程序，但是在程序中所包含的文件包、代码含义等细节还没有更为清晰的认识。本小节将给读者介绍鸿蒙开发快速入门的一些相关基础知识，掌握这些基础知识可以为学习其他中级知识奠定良好的基础。4.1.1使用场景和设计意义在设备的操作系统之上安装着各种应用软件，这些应用软件对应的文件包就可以称之为应用程序包。鸿蒙系统提供了程序包的开发、安装、查询、更新、卸载的管理机制。同时，鸿蒙系统还屏蔽了不同芯片平台的差异，所有的应用程序都可以在不同的芯片上安装和运行，这种设计可以让鸿蒙开发人员将自己的开发任务聚焦于开发本身，而不是芯片和程序之间的兼容问题。鸿蒙中的一个应用会有多个功能，在鸿蒙的设计中这些功能将按照不同的特性进行模块划分，这些被划分的模块称为Module，而在Module中其文件构成主要包括源代码、资源文件、第三方库、配置文件等等，每一个Module都可以进行独立编译来实现特定的功能。这种模块化开发思想可以使整个程序本身有用松耦合的特性，易于程序的开发、维护和扩展。一个应用需要适配多种设备类型，而在基于Module的方式中，每个Module都会标注所支持的设备类型，其中的一些Module支持所有设备，而有些Module则只支持部分设备，这种方式使得程序在应用市场中的分发可以针对设备类型而做出快速而精准的匹配和筛选，从而将不同的Module进行组合和部署到用户的目标设备上。4.1.1使用场景和设计意义这里需要明确HAP、Module和Ability三个概念，了解其设计用意和使用场景，以下是针对这三个概念的一些解释：（1）Ability：能力的意思，Ability是应用程序功能的基本单元。它定义了应用程序能够提供的服务或功能。Ability主要分为两种类型：FeatureAbility（FA）和ParticleAbility（PA）。FeatureAbility主要用于提供与用户交互的功能，而ParticleAbility主要用于提供后台任务和数据访问功能。（2）Module：模块的意思，Module是应用程序的组成部分，它包含了多个Ability。一个Module可以包含一个或多个Ability，这些Ability共同实现一个特定的功能或服务。Module是应用程序的构建块，它使得应用程序的开发更加模块化，便于管理和维护。（3）HAP：HAP是HarmonyOS应用包，一个HAP文件可以包含一个或多个Ability，这些Ability共同实现应用的功能，HAP包是Ability的部署包，也是应用安装和运行的基本单元。在理想的情况下，一个应用程序应该被拆分为多个独立模块，每个独立模块就是所谓的Module，每一个Module又由一个或多个Ability组成。一个或多个Ability以及相关的资源、配置等文件被打包成一个HAP文件，作为应用安装和运行的基本单元。总结来说，Ability是应用功能的基本单元，Module是应用功能模块的组织方式，而HAP是应用安装和运行的基本单元，包含了代码、资源和配置文件。4.1.1使用场景和设计意义那么应用程序中的module数量和转换之后的hap数量是什么关系呢？一个应用程序通常由多个模块（module）组成，每个模块在部署时都会转换为一个HAP文件。因此，如果程序中有四个模块，理论上在部署时它会转换成四个HAP文件，而实际情况可能会根据应用程序的设计和部署策略有所不同。例如，如果某些模块是相互依赖的，或者开发者希望将某些模块打包在一起以提高性能或简化部署过程，那么这些模块可能会被合并成一个HAP文件。另外，开发者也可能选择将某些模块作为独立的应用程序发布，每个模块对应一个HAP文件。总之，一个程序中的模块数量与最终生成的HAP文件数量之间的关系取决于应用程序的设计和开发者的决策。在大多数情况下，每个模块都会转换为一个HAP文件，但也可以根据需要进行调整。如图Module与HAP的转换关系所示。4.1.2应用包HAP的使用HAP（HarmonyOSAbilityPackage）是鸿蒙操作系统（HarmonyOS）中的一种应用包格式，它是鸿蒙应用开发的基础单元。HAP文件包含了应用的所有代码、资源、第三方库以及应用所需的配置信息。一个HAP通常包含内容如下表所示。包含内容举例代码资源包括应用的Java/Kotlin代码、C/C++原生代码以及HarmonyOS特有的ArkTS（ArkUI）代码。配置文件如config.json，这是HAP的核心配置文件，定义了应用的Ability、权限、模块信息等。资源文件如图片、布局文件、字符串资源等，这些资源用于支持应用的界面展示和国际化。第三方库应用可能依赖的第三方代码库。HAP也分为两种类型：EntryHAP和FeatureHAP。EntryHAP，也叫主HAP，它是应用的入口模块，用户可以直接安装和运行EntryHAP，并且一个鸿蒙应用至少包含一个EntryHAP；FeatureHAP，也叫特征HAP，它是应用的可选功能模块，可以按需下载和安装。FeatureHAP允许应用实现模块化，减少初始安装包的大小，一个应用通常包含0个或者多个FeatureHAP；4.1.2应用包HAP的使用——开发步骤在鸿蒙中，应用程序包可以只包含一个基础的entry包，也可以包含一个基础的entry包和多个功能性的feature包。HAP作为鸿蒙操作系统的核心应用包格式，其设计充分体现了现代操作系统对应用开发的高效、灵活和跨设备支持的需求。HAP的特点主要体现在其模块化的结构设计，支持应用的原子化服务和跨设备无缝流转，确保了应用的可扩展性和用户体验的一致性。模块化使得开发者能够将应用拆分成多个独立的功能单元，不仅便于管理和维护，还能实现按需下载和动态更新，显著减少了应用的初始安装包大小，优化了用户的下载和安装体验。此外，HAP的跨设备能力是其一大亮点，它允许应用在不同的硬件和软件平台上运行，利用HarmonyOS的分布式技术，实现了一套代码多端运行，大大提升了开发效率和应用的可访问性。同时，HAP还注重兼容性和安全性，确保应用能够在多样化的设备上稳定运行，同时保护用户的数据安全，为开发者提供了一个强大而可靠的应用开发平台。HAP的开发步骤见图所示：4.1.2应用包HAP的使用——设计理念作为鸿蒙系统的开发者，在设计HAP时需要进行模块化的理念设计，主要基于以下几方面的重要原因：灵活与扩展性模块化设计使得应用结构更加灵活和可扩展。每个HAP模块都是独立的功能单元，可以单独开发、测试和部署。这种设计可以使得整个应用中其他功能不受到任何影响的情况下，轻松地添加、更新或删除特定功能，从而快速响应市场和用户需求的变化。01跨设备兼容性鸿蒙系统致力于实现全场景智慧生态，支持多种设备的互联互通。通过HAP模块化，以针对不同设备的特性，如屏幕大小、处理器能力等，提供定制化的功能模块。这样不仅保证了应用在多种设备上的良好兼容性，还能为用户提供更加个性化的体验。02高效资源管理模块化设计有助于优化资源管理。在用户实际使用过程中，按需加载和卸载HAP模块，可以显著减少应用的内存和存储占用，提高运行效率。此外，这种按需加载的方式还能加快应用的启动速度，提升用户体验。034.1.2应用包HAP的使用——设计理念作为鸿蒙系统的开发者，在设计HAP时需要进行模块化的理念设计，主要基于以下几方面的重要原因：简化分布式开发鸿蒙系统的分布式特性要求应用能够在多个设备上协同工作。HAP模块化使得分布式开发变得更加简单，可以专注于特定模块在不同设备间的交互逻辑，从而实现无缝的跨设备协同。04易于维护与升级模块化降低了应用的整体复杂度，使得代码更易于理解和维护。在应用迭代过程中，可以针对性地更新某个模块，而无需重新部署整个应用，这不仅提高了维护效率，还减少了用户因更新带来的不便。05促进代码复用：通过模块化，可以将通用功能抽象成独立的HAP模块，这些模块可以在不同的应用或项目中复用，大大提高了开发效率，减少了重复工作。064.1.2应用包HAP的使用——HAP、APP、设备的关系鸿蒙系统中的APP概念和安卓一样，也指应用软件，它由一个或多个HAP包组成，HAP是鸿蒙应用的基本组成单元，包含了应用的具体功能模块，多个HAP共同构成了一个完整的鸿蒙APP，实现跨设备流转和分布式能力。而跨设备流转的体现则是不同的设备对有不同的Entry。从Entry与设备的关系来说，同一个鸿蒙应用可以在多个设备上运行，而每个设备上的应用实例都需要通过Entry来启动和运行。此外，Entry还负责根据不同设备的特性（如屏幕大小、输入方式等）来适配应用界面和功能，确保应用在不同设备上提供一致的用户体验。也就是说，Entry是鸿蒙应用在特定设备上的启动点和交互界面，它使得应用能够跨设备运行和协同。4.1.2应用包HAP的使用——HAP的创建在弹出的对话框中选择EmptyAbility模板，单击Next。那么如何创建一个HAP模块呢？只要按照如下步骤进行设计即可：创建工程，构建第一个ArkTS应用。在工程目录上单击右键，选择New——Module。在Ability配置界面，配置Abilityname，然后单击Finish完成创建。在Module配置界面，配置Modulename，选择ModuleType和DeviceType，然后单击Next。通过DevEcoStudio编译打包，生成单个或者多个HAP，即可对其进行调试。4.1.2应用包HAP的使用——HAP、APP、设备的关系从HAP的使用场景来说，分为：单HAP场景：单HAP场景下，应用的所有功能都封装在一个HAP包中。这意味着应用的代码、资源和配置文件都包含在一个HAP文件中，单HAP场景适用于小型应用或功能单一的应用。由于所有功能都在一个HAP包中，这种场景下的应用部署和管理相对简单。多HAP场景：在多HAP场景中，应用的功能被拆分到多个HAP包中。每个HAP包可以包含应用的一个或多个特性，或者一个主模块和多个特性模块，在多HAP场景中，应用的功能被拆分到多个HAP包中。每个HAP包可以包含应用的一个或多个特性（Feature），或者一个主模块（Entry）和多个特性模块。在多HAP场景中，应用的入口模块（Entry）通常包含应用的启动逻辑和核心功能，而特性模块（Feature）则包含应用的附加功能或可选特性。这种设计使得应用可以根据用户的需求和设备的能力动态地加载和卸载特性模块，从而实现应用的灵活性和个性化。单HAP场景和多HAP场景的选择取决于应用的大小、复杂性和功能需求。单HAP场景适用于简单、轻量级的应用，而多HAP场景则适用于需要模块化开发和动态特性支持的大型应用。4.1.2应用包HAP的使用——HAP的安装和调试开发者可以使用DevEcoStudio进行调试，或者使用hdc工具进行调试。在调试前，需要安装HAP，可以直接使用hdc安装，这里以Windows开发平台为例，参考命令如下：//安装、更新，多HAP可以指定多个文件路径hdcinstallentry.hap

feature.hap//执行结果installbundlesuccessfully.//卸载hdcuninstallcom.example.myapplication//执行结果uninstallbundlesuccessfully.

除了使用hdc来安装，还可以先执行hdcshell，再使用bm工具（包管理器）安装。以真机上的HAP文件路径为例：

//先执行hdcshell才能使用bm工具hdcshell//安装、更新，多HAP可以指定多个文件路径bminstall-p/data/app/entry.hap/data/app/feature.hap//执行结果installbundlesuccessfully.//卸载bmuninstall-ncom.example.myapplication//执行结果uninstallbundlesuccessfully.完成HAP安装或更新后，即可参考相关调试命令进行调试，具体可参考官方文档的调测调优部分。接下来看一个多HAP的示例演示，虽然至此还没有进行深入的技术学习，但是可以先大致对多HAP的场景设计有一个初步的认识。4.1.2应用包HAP的使用——多HAP开发示例在本实例中展示的是多HAP开发，其中应用包含一个entryHAP和两个featureHAP，两个featureHAP分别提供了音频和视频播放组件，entry中使用了音频和视频播放组件。三个模块需要安装三个hap包，最终会在设备上安装一个主entry的hap包。本例子中使用到了两个接口：应用上下文Context接口@mon媒体服务接口@ohos.multimedia.media安装步骤如下：4.1.2应用包HAP的使用——多HAP开发示例点击Build->BuildHap(s)/APP(s)->BuildHap(s)，构建三个模块的hap包。使用IDE安装多Hap包。点击entry->EditConfigurations，如图编辑页面所示。4.1.2应用包HAP的使用——多HAP开发示例选择DeployMultiHap勾选DeployMultiHapPackages后勾选audioFeature和videoFeature，点击Apply后运行项目，如图多HAP部署界面：点击audio，进入audio播放页面，可点击PlayAudio按钮，播放音频。点击video，进入video播放页面，可点击播放按钮播放视频。以下是工程目录的说明：4.1.2应用包HAP的使用——多HAP开发示例├──audioFeature/src/main/ets/│├──application││└──MyAbilityStage.ets│├──audioAbility││└──AudioAbility.ets│├──pages││└──index.ets//audio组件的实现页面│└──util│└──Logger.ts//日志工具├──audioFeature/src/main/module.json5//audio模块配置hap类型："type":"feature"│├──entry/src/main/ets/│├──application││└──MyAbilityStage.ets│├──mainability││└──MainAbility.ets│├──pages││└──index.ets//entry主应用入口，内含首页组件以及发起hap跳转逻辑│└──util│└──Logger.ts//日志工具├──entry/src/main/module.json5//entry模块配置hap类型："type":"entry"├──videoFeature/src/main/ets/│├──application││└──MyAbilityStage.ets│├──videoability││└──VideoAbility.ets│├──pages││└──index.ets//video组件的实现页面│└──util│└──Logger.ts//日志工具└──videoFeature/src/main/module.json5//video模块配置hap类型："type":"feature"这个例子中的三个模块分别是1个entry和两个feature。其中entry是应用程序的主模块，也可以理解为入口模块，也就是程序在运行的初期需要加载的第一个模块，此外这个模块必须存在，有且只有一个。然后通过entry模块进入到其他两个feature模块，它们其中一个为名字为videoFeature，另一个名字为audioFeature，这就是在工程中的多HAP使用场景。4.1.2应用包HAP的使用——多HAP开发示例之设计思路新创建两个Module作为将被跳转的HAP，分别命名为videoFeature，audioFeature。

配置每个HAP的type（类型），具体做法是：

把entry文件夹下的module.json5中type属性配置改为entry。

把videoFeature和audioFeature文件夹下的module.json5中type属性配置改为feature；

使用Want跳转到其他的Ability。

通过Want的配置中指定bundleName和abilityName来唯一确定一个Ability。在entry模块index.ets首页中，在按钮.onclick()事件内，通过Want配置显式拉起一个新的指定的Ability。语法如下（可以先不用注重语法细节）：此示例的设计思路如下：以配置videoFeature模块Want配置为例，在触发按钮事件中加入配置的Want：btn.onClick(()=>{this.context.startAbility({bundleName:BUNDLE_NAME,abilityName:AUDIO_ABILITY_NAME}} 在这里例子中，bundleName和abilityName的含义分别是:bundleName为appscope文件夹下app.json5中"bundleName":"com.samples.multihap"

abilityName为videoFeature模块src/main/module.json5中abilities：["name":"VideoAbility"]。4.1.3静态共享包HAR的使用HAR（HarmonyArchive）是静态共享包，可以包含代码、C++库、资源和配置文件。通过HAR可以实现多个模块或多个工程共享ArkUI组件、资源等相关代码。一般将它发布到OHPM私仓，供公司内部其他应用使用，或者发布到OHPM中心仓库，供其他应用使用。但是HAR包不能像应用模块那样单独在设备上安装和运行，其只能为应用模块的依赖项而被引用，同时，HAR可以依赖其他HAR，但是不支持循环依赖，也不支持传递依赖。4.1.3静态共享包HAR的使用接下来展示的是如何创建一个HAR模块：(1)将鼠标放在工程目录上，然后选择New>Module，在工程中添加模块。(2)在ChooseYourAbilityTemplate界面中，选择StaticLibrary，并单击Next,如图4-5

staticlibrary的创建。(3)在ConfigureNewModule界面中，设置新添加的模块信息，设置完成后，单击Finish完成创建。其中Modulename指的是模块的名字，Devicetype指的是支持的设备类型，Enablenative指的是是否创建一个用于调用C++代码的模块。如图4-6创建HAP模块的界面。4.1.3静态共享包HAR的使用(4)创建完成后，会在工程项目目录中生成库模块及相关文件，如图HAR模块的创建。(5)接下来进行模块编译，选中模块名，然后通过DevEcoStudio菜单栏的Build>MakeModule${libraryName}进行编译构建，生成HAR。这个生成的HAR就可以用于工程中其他模块的引用，亦或是将其上传到ohpm仓库，供其他开发人员下载使用，部分源码文件不需要打包到HAR时，可以使用ohpmignore文件，其作用是在打包时会自动忽略掉不需要的文件和文件夹，见图4-8模块打包操作。可以查看到编译好后生成的.har文件，见下图。4.1.3静态共享包HAR的使用在编译构建HAR时，请注意以下事项：（1）编译构建HAR的过程中，不会将模块中的C++代码直接打包进.har文件中，而是将C++代码编译成动态依赖库.so文件放置在.har文件中的libs目录下。（2）在编译构建HAR的过程中，会生成资源文件ResourceTable.txt，以便编辑器可以对HAR中的资源文件进行联想。因此，如果不使用DevEcoStudio对HAR进行构建，则DevEcoStudio的编辑器会无法联想HAR中的资源。（3）如果使用的自动化构建工具Hvigor为2.5.0-s及以上版本，在编译构建HAR的过程中，会将dependencies内处于本模块路径下的本地依赖也打包进.har文件中,在进行打包的操作后，发现部分的本地依赖，可参考官方网站给予的解决方案。4.1.4动态共享包HSP的使用鸿蒙操作系统中的HSP（HarmonySharedPackage）是一种动态共享库，它可以包含代码、C++库、资源和配置文件，实现代码和资源的共享。HSP不支持独立发布，而是跟随其宿主应用的APP包一起发布，与宿主应用同进程，具有相同的包名和生命周期。HSP的主要特点和使用场景如下：代码和资源共享：HSP允许多个HAP（HarmonyAbilityPackage）或HSP共用代码和资源，提高码、资源的可重用性和可维护性，同时编译打包时只保留一份HSP代码和资源，有效控制应用包大小。运行时按需加载：HSP在运行时可以按需加载，有助于提升应用性能。组织内部代码共享：同一个组织内部的多个应用之间，可以使用集成态HSP实现代码和资源的共享。4.1.4动态共享包HSP的使用解决HAR问题：HSP旨在解决HAR（HarmonyArchive）存在的一些问题，如多个HAP引用相同的HAR导致的APP包大小膨胀问题，以及HAR中的一些状态变量无法共享的问题。分布式应用场景：HSP文件用于打包和分发服务（如元服务或分布式能力服务），主要服务于分布式应用场景，支持多设备间的协同工作和数据共享。服务管理：HSP文件主要用于分布式应用的服务管理，在HarmonyOS生态中，设备间的协同工作是其核心亮点之一。通过HSP文件，开发者可以将某个服务的能力在多个设备之间共享，比如跨设备文件共享、分布式任务处理等。4.1.4动态共享包HSP的使用可以使用DevEcoStudio来开发动态共享包HSP，在应用/服务开发过程中部分功能按需动态下载，或开发元服务场景时需要分包加载，可使用HSP实现相应功能。当有多个安装包需要资源共享时，也可利用HSP减少公共资源和代码重复打包。HSP中有两种使用方式：应用内HSP：在编译过程中与应用包名（bundleName）强耦合，只能给某个特定的应用使用。集成态HSP：构建、发布过程中，不与特定的应用包名耦合；使用时，工具链支持自动将集成态HSP的包名替换成宿主应用包名。4.1.4动态共享包HSP的使用下表是两种HSP形态的对比图形态应用内集成态定义应用内HSP是专门为某一应用开发的动态共享包，只能在编译过程中与该应用的包名（bundleName）强耦合，只能被该特定应用使用。集成态HSP在构建和发布过程中不与特定的应用包名耦合；使用时，工具链支持自动将集成态HSP的包名替换成宿主应用的包名。使用范围仅限于内部其他HAP/HSP使用，用于应用内部代码和资源的共享。可以被多个应用共享使用，只要这些应用的签名相同。它是解决使用方的bundleName和签名之间强耦合问题的工具。发布方式随宿主应用的APP包一起发布，与宿主应用具有相同的包名和生命周期。同样随宿主应用一起发布，但可以在不同的应用间共享，提供更大的灵活性。优点专为单一应用设计，确保了应用内部的高效代码和资源共享，适用于需要严格内部管理和隔离的场景。提供了跨应用的代码和资源共享能力，增加了应用的灵活性和可重用性。特别适用于多个应用间需要共享相同功能或资源的场景。局限性由于与特定应用包名强耦合，灵活性较差，不能跨应用共享。需要处理不同应用间的包名和签名问题，可能增加构建和发布的复杂性。4.1.4动态共享包HSP的使用从上表可以看出，应用内HSP和集成态HSP在耦合性、使用范围、灵活性、复杂性和适用场景等方面存在显著差异。应用内HSP与特定应用包名强耦合，仅限于内部使用，适用于需要严格内部管理和隔离的场景；集成态HSP在构建和发布过程中不与特定应用包名耦合，可以跨应用共享，提供了更大的灵活性，特别适用于多个应用间需要共享相同功能或资源的场景。然而，集成态HSP在构建和发布过程中可能涉及更多的复杂性，需要处理包名和签名问题。因此，在选择应用内HSP还是集成态HSP时，需要根据具体的项目需求和应用架构来决定。注意，HSP及其使用方都必须是API10及以上版本Stage模型，并且HSP及其使用方都必须使用模块化编译模式，这里的模块化编译是在API10及以上版本的Stage工程默认开启的，它有助于缩短增量编译时间、减小编译后的包体积。4.1.4动态共享包HSP的使用首先先来创建HSP模块，在DevEcoStudio中，新建一个模块，然后在选择模板模板类型的界面，选择SharedLibrary,如图创建HSP模块。4.1.4动态共享包HSP的使用点击“next”之后，然后设置新添加的模块信息，在该界面中：“Modulename”代表模块的名字；“Devicetype”代表支持的设备类型；“Enablenative”代表是否创建一个用于调用C++代码的模块。4.1.4动态共享包HSP的使用设置完成后点击“finish”完成创建，这样就会在工程目录中生成库模块及相关文件，如图创建HSP模块时的项目目录结构。4.1.4动态共享包HSP的使用如果该模块开发完毕之后，对该模块进行编译：选中模块名，然后通过DevEcoStudio菜单栏的Build>MakeModule${libraryName}进行编译构建，生成HSP。在打包HSP时，会同时默认打包出HAR，在模块下的build目录下可以看到HAR文件和HSP文件，如图4-13编译之后生成的HAR和HSP文件。如果需要在应用内共享HSP，则可以将HSP共享包上传至私仓，在这之前需要先通过编译生成*.tgz包。这里需要先在DevEcoStudio中点击produce按钮，如图

release模式切换按钮。4.1.4动态共享包HSP的使用上图中看到的.tgz文件就是用来上传到私仓的文件，这个文件可以在应用中被共享使用。将编译模式切换为release模式，如图4-15模式切换界面。切换完模式，按照之前的编译操作，将该模块进行编译，会得编译后生成的tgz文件如图所示。4.1.5模块化单位Module——Ability类型的Module在鸿蒙系统中，Module（模块）是应用程序的基本组成部分，它们负责实现应用程序的功能。鸿蒙系统中的Module主要分为两种类型：（1）Ability类型的Module：entry类型的Module和feature类型的Module。它的作用定位是应用程序的功能和特性，每一个Ability类型的Module编译后，会生成一个.hap文件，通常称之为HAP包(HarmonyAbilityPackage)。HAP包可以独立的安装和运行，它是应用安装的基本单位，一个应用中可以包含一个或多个HAP包。而在Ability类型的Module中又包含如下两种类型：entry类型的Module：它是应用的主模块部分，包含应用的入口界面、入口图标和主功能特性，编译后生成entry类型的HAP。需要特别强调的是，每一个应用分发到同一类型的设备上的应用程序包，只能包含唯一一个entry类型的HAP。feature类型的Module：应用的动态特性模块，编译后生成feature类型的HAP。一个应用中可以包含一个或多个feature类型的HAP，也可以不包含。由此可知一个程序中由多个AbilityModule组成，而每一个AbilityModule在通过编译后要么是一个entry类型的HAP，要么是一个feature类型的HAP，程序编译后HAP文件类型的组成，如图所示。（2）Library类型的Module：StaticLibrary和SharedLibrary。（见下页）4.1.5模块化单位Module——Library类型的ModuleLibrary类型的Module：它的作用定位是模块之间的资源共享。同一个Library类型的Module可以被其他的Module多次引用，Library类型的Module充分体现了软件的模块复用设计思想，这种开发模式能够降低开发和维护成本。同时Library类型的Module分为Static和Shared两种类型，他们编译后都会生成共享包。针对Static和Shared两种类型的LibraryModule解释如下：StaticLibrary：静态共享库。编译后会生成一个以.har为后缀的文件，即静态共享包HAR。SharedLibrary：动态共享库。编译后会生成一个以.hsp为后缀的文件，即动态共享包HSP，值得注意的是，SharedLibrary在编译后也会生成一个.har文件，该文件用于记录HSP对外部的导出接口，应用中的其他模块需要通过.har文件来引用HSP的功能。下图展示的是Module编译过程。4.1.5模块化单位Module——HAR与HSP两种共享包的主要区别共享包类型编译和运行方式发布和引用方式HARHAR中的代码和资源会跟随着HAP包一起编译，如果有多个HAP包同时使用HAR，则这个HAR会有多个相同的拷贝。也因为这样，在遇到这种情况的时候，建议把代码加入混淆，保护代码资产。HAR文件除了可以被引用，还可以独立打包发布，供给其他应用来使用。HSPHSP中的代码和资源可以独立编译，在一个进程中运行时只会存在一份。HSP通常会和应用一起打包，用于在不同的应用之间共享，当前支持应用内和集成态HSP：应用态HSP：这种HSP只能在当前应用内使用，不能被其他应用引用。集成态HSP：这种HSP可以被发布到ohpm私仓（ohpm是鸿蒙系统的包管理器），并且可以被其他应用引用。4.1.5模块化单位Module——HAR与HSP被模块引用的情况上图可以看出Ability类型的Module是鸿蒙系统中的核心组件，负责定义应用的各项能力，包括用户界面、数据管理、通信功能等。这些Module可以独立运行，也可以与其他Module协同工作，以提供丰富的应用功能。Library类型的Module则是鸿蒙系统中的库文件，包含可重用的代码和资源，可以被多个Ability类型的Module共享，以提高开发效率和代码复用性。通过详细学习Ability和Library的概念、类型、生命周期、通信机制、依赖管理以及开发实践，可以系统地了解这两种Module类型，掌握它们在鸿蒙系统中的应用和开发方法。这将有助于鸿蒙开发人员更好地理解和运用鸿蒙系统的开发框架，提高开发技能和项目实践能力。4.1.6基础能力单元Ability“Ability”一次译为“能力”，正如它的含义，在鸿蒙中其表示程序所具备的能力。它其实是鸿蒙中的一个基础组件（名为Ability的Java类），是应用程序的基本功能单位，主要是用于实现特定的业务功能，而实现的方式就是通过对Ability类进行继承和扩展。总体来说（在FA模型下），Ability分为两种类型，一个是FeatureAbility（简称为FA），另一个是ParticleAbility（将成为PA）。FeatureAbility是面向用户的界面功能，它更偏向于前端，用于与用户进行交互。可以把它类比为Android中的Activity，是应用程序与用户交互的主要入口点。FeatureAbility可以提供以下特性：FeatureAbility通常以页面的形式展现，用于展示信息和响应用户操作。一个应用程序可以有多个页面，每个页面都是FeatureAbility的一个实例。FeatureAbility拥有完整的生命周期管理，包括创建、显示、隐藏、销毁等状态。用户可以在FeatureAbility中使用多种交互方式，如触摸、语音、手势等。ParticleAbility是面向其他Ability的服务功能，用于提供后台运行任务和数据处理能力。它类似于Android中的Service。ParticleAbility可以提供以下特性：lParticleAbility通常以服务的形式运行，可以在后台执行任务，如数据处理、文件下载等，而不需要与用户交互。lParticleAbility还可以作为数据提供者，允许其他Ability访问其提供的数据。4.1.6基础能力单元Ability无论是FeatureAbility还是ParticleAbility，它们都有以下共同点：分布式能力HarmonyOS的一个核心特性是其分布式能力，Ability可以在不同的设备上无缝迁移和协同，为用户提供连贯的体验。01FA模型FeatureAbility使用FA（FeatureAbility）模型，它定义了Ability的界面和用户交互逻辑，它也被成为元程序。02PA模型ParticleAbility使用PA（ParticleAbility）模型，它定义了Ability的服务和数据提供逻辑，它也被成为元服务。03生命周期管理HarmonyOS为Ability提供了详细的生命周期管理，确保Ability能够正确地响应系统事件和用户操作。044.1.6基础能力单元Ability（注意这里是FA模型下的ability分类）在开发HarmonyOS应用程序时，开发者需要根据应用的具体需求来设计FeatureAbility和ParticleAbility，以提供丰富和流畅的用户体验。HarmonyOS提供的开发框架和工具可以帮助开发者更容易地创建和管理这些Ability。综合来看，鸿蒙系统主要有三种Ability：PageAbility：PageAbility是应用中表示单个页面的组件，用于提供与用户交互的界面。它是HarmonyOS应用中用户可见的界面元素，类似于Android中的Activity。ServiceAbility：ServiceAbility是用于后台运行任务的组件，通常用于执行不需要用户交互的长时间运行操作。ServiceAbility类似于Android中的Service。DataAbility：主要用于管理数据，提供数据的增、删、改、查等操作。它类似于其他操作系统中的内容提供者（ContentProvider）或数据服务。FA模型下的ability分类stage模型下的ability分类4.1.6基础能力单元Ability（注意这里是FA模型下的ability分类）由以上可以看出，鸿蒙操作系统通过其核心组件Ability，为开发者提供了一套灵活的应用开发框架。其中，PageAbility模板负责用户界面的展示与交互，ServiceAbility模板处理后台运行的任务，而DataAbility模板则统一管理数据访问，确保了应用功能的丰富性和高效性。这三种Ability类型的协同工作，不仅满足了多样化的应用场景需求，还助力鸿蒙系统实现了全场景、多设备的应用生态。4.2DevEcoStudio及工程文件4.2DevEcoStudio及工程文件本章将介绍DevEcoStudio的各个界面，以及使用DevEcoStudio创建的各种工程的文件结构介绍。在DevEcoStudio中，可以创建三种不同的工程目录结构，它们分别是：ArkTS工程目录结构（Stage模型）C++工程目录结构（Stage模型）JS工程目录结构（FA模型）可以看出不同的目录结构取决于使用的是什么开发模型，那么这两个开发模型的区别是什么呢？4.2DevEcoStudio及工程文件FA是一个具有用户界面的功能单元，它代表了一个独立的功能模块，可以在分布式系统中被其他设备上的应用调用。FA强调的是功能的独立性和可分布式能力，它可以是整个应用的一部分，也可以是独立的功能模块;Stage是鸿蒙操作系统中的一种新的应用开发模型，它基于ArkUI框架，提供了声明式UI和状态管理的能力。Stage模型更注重于组件化和声明式编程，旨在提高开发效率和应用的性能。总结来说，Stage和FA在鸿蒙操作系统中是并行存在的两种开发模型，它们各自有不同的应用场景和优势。同时从鸿蒙的发展趋势来说，从HarmonyOS3.0以后，官方已经不建议使用Java语言了，更加推荐使用ArkTS来进行应用开发，因此后续的学习重点放到ArkTS会有更好的效果。4.2.1DevEcoStudio的界面介绍在DevEcoStudio中，右侧为代码编辑区，如图所示。下方为IDE的控制台，项目在编译、运行、日志打印、终端信息展示、服务信息展示等都可以在此控制台进行查看，如图4-22所展示的控制台区域。4.2.1DevEcoStudio的界面介绍在IDE的右侧边栏中还有Notifications和预览器的标签，其中Notifications会展示各种IDE中的动作提示，比如工程同步动作、运行端口信息等等。而预览器标签的作用是对某些视图文件进行预览，包括.ets文件、js文件、css文件、html文件、servicewidgets的json文件、AbilitySlice.java和Ability.java等。在IDE的上方是菜单栏区域，在这里可以对IDE进行一些基础的配置和对项目开发的一些选项操作，如图所示菜单栏。在使用DevEcoStudio时，刚开始不需要记住所有的菜单功能，很多菜单项都是随着开发工具的使用而慢慢熟知的，因此只要掌握关键的几个常用菜单项来进行基础配置和项目的开发就已经可以满足日常的开发需求了，当然如果读者有相关的IDE使用经验也是非常好上手的，因为IDE之间具有相通性，因此如果读者之前使用过类似于Vscode、IDEA的开发工具，那么使用DevEcoStudio的上手速速将会非常快。4.2.2ArkTS工程目录结构(Stage模型)——开发态包结构鸿蒙操作系统具有许多独特的技术特点和创新之处。鸿蒙系统的技术特点如下：·

.hvigor：存储构建配置文件信息。·

.idea：存储项目的配置信息。·

AppScope>app.json5：应用的全局配置信息。（由DevEcoStudio自动生成，不可更改）·

entry：应用/服务模块，编译构建生成一个HAP。o

src>main>ets：用于存放ArkTS源码。o

src>main>entryability：应用/服务的入口。o

src>main>pages：应用/服务包含的页面。o

src>main>resources：用于存放应用/服务模块所用到的资源文件，如图形、多媒体、字符串、布局文件等。o

src>main>resources>base>element：包括字符串、整型数、颜色、样式等资源的json文件。o

src>main>resources>base>media：多媒体文件，如图形、视频、音频等文件。o

src>main>resources>rawfile：用于存储任意格式的原始资源文件。o

src>main>module.json5：Stage模型模块配置文件，主要包含HAP的配置信息、应用在具体设备上的配置信息以及应用的全局配置信息。·

hvigor：前端构建配置文件信息，和基于Node.js的构建系统相关的文件夹·

oh_modules：用于存放三方库依赖信息，包含应用/服务所依赖的第三方库文件。·

.gitignore：Git版本控制中忽略的文件或目录列表。·

build-profile.json5：当前的模块信息、编译信息配置项，包括buildOption、targets配置等。·

hvigorfile.ts：模块级编译构建任务脚本。·

hvigorw和hvigorw.bat运行在不同操作系统中的（针对ohpm的）编译构建工具。·

perties：存储本地属性的文件。·

oh-package.json5：描述三方包的包名、版本、入口文件（类型声明文件）和依赖项等信息。4.2.2ArkTS工程目录结构(Stage模型)当开发人员需要声明式UI和状态管理时，则使用基于ArkUI框架的TypeScript开发模式，它适用于构建具有现代化前端体验的应用。TypeScript提供了强类型检查，可以帮助开发者在开发过程中捕捉到更多错误。同时，ArkTS支持声明式UI，可以简化UI代码的编写和维护。更为重要的是，华为官方推荐使用ArkTS语言作为后续的开发语言，所以ArkTS结构的项目应该更值得读者去学习和探究。虽然ArkTS工程项目比较复杂，但是可以大致分类为以下几种文件类型及用途，方便初学者记忆：配置文件：AppScore下的app.json5是用于声明应用的全局配置信息，比如应用Bundle名称、应用名称、应用图标、应用版本号等；模块包名下的src/main/module.json5，用于声明Module基本信息、支持的设备类型、所含的组件信息、运行所需申请的权限等。ArkTS源码文件：位置在模块明下的/src/main/ets，用于存放Module的ArkTS源码文件（.ets文件）。4.2.2ArkTS工程目录结构(Stage模型)资源文件：包括应用级资源文件（AppScopre/resources）、以及Module级资源文件（模块包/src/main/resources）。其他配置文件：用于编译构建，包括构建配置文件、编译构建任务脚本、混淆规则文件、依赖的共享包信息等。例如：build-profile.json5:

工程级或Module级的构建配置文件，包括应用签名、产品配置等相关信息。hvigorfile.ts：应用级或Module级的编译构建任务脚本，开发者可以自定义编译构建工具版本、控制构建行为的配置参数。obfuscation-rules.txt：混淆规则文件。混淆开启后，在使用Release模式进行编译时，会对代码进行编译、混淆及压缩处理，保护代码资产。oh-package.json5：用于存放依赖库的信息，包括所依赖的三方库和共享包。4.2.2ArkTS工程目录结构(Stage模型)另外更重要的是，不同类型的Module编译后会生成对应的HAP、HAR、HSP等文件，开发态视图与编译态视图的对照关系，如图：编译打包后每个模块下的est目录下的代码都会转化成abc文件，并且全局配置文件app.json5中的字段会与每个module.json5中的字段合并后放入编译后的module.json中。上图只标注了其中一个模块的合并情况，其他模块合并情况类似。4.2.2ArkTS工程目录结构(Stage模型)在鸿蒙操作系统的开发环境中，应用工程结构分为开发态和编译态两种视图。开发态展示了应用在开发过程中的组织结构，而编译态则展示了应用在编译后的结构。这种结构设计有助于开发者理解和管理应用的各个组成部分。从上图可以看出，在开发态下，应用工程由多个模块组成，包括AppScope、EntryModule、FeatureModule、SharedLibrary和StaticLibrary。每个模块都有资源目录和配置文件。例如，AppScope包含资源和app.json5配置文件，而各个模块则包含src/main目录、资源目录、ets目录和module.json5配置文件。这样的结构使得开发者可以清晰地组织代码和资源，便于开发和维护。编译态下，应用被编译成多个HAP（HarmonyOSAbilityPackage）包，每个包对应一个模块。例如，entry模块被编译成entry.hap，feature模块被编译成feature.hap，而libraryA和libraryB则分别被编译成libraryA.hap和libraryB.hap。每个HAP包中包含了ets、资源、配置文件（module.json）以及编译后的代码（xxx.abc）。此外，AppScope中的资源和配置文件也会被合并到相应的HAP包中。4.2.2ArkTS工程目录结构(Stage模型)这种从开发态到编译态的转变，确保了应用的各个模块在编译后能够独立运行，同时保持了资源和配置的一致性。通过这种方式，鸿蒙操作系统支持了模块化开发，使得应用的各个部分可以独立开发、测试和部署，提高了开发效率和应用的可维护性。以上是Stage模型应用程序的开发态包结构，接下来看下发布态包结构。在实际开发过程中，开发者需要熟悉这种工程结构，以便正确地组织代码和资源，确保应用能够顺利编译和运行。同时，理解开发态与编译态之间的差异，也有助于开发者在遇到问题时快速定位和解决问题。这种结构的设计，是鸿蒙操作系统支持高效开发和灵活部署的重要基础。4.2.2ArkTS工程目录结构(Stage模型)——发布态包结构当开发完一个应用程序之后，需要进行应用的打包和发布，每个应用中至少包含一个hap文件，也可能包含一些HSP文件，所有的hap和hap文件结合在一起称为Bundle，它对应的bundleName是应用的唯一标识，这个标识是在app.json5配置文件中声明的bundleName标签。当应用发布上架到应用市场时，需要将Bundle打包为一个.app后缀的文件，这个文件称为AppPack。通过DevEcoStudio工具自动生成一个文件，这个文件描述了app文件包中的每一个hap和hsp的属性，同时也包含bundleName、versionCode以及module中的name、type、abilitites等信息。这里要说明的是，AppPack虽然是发布到应用市场的基本单元，但是不能在设备上直接安装和运行，在应用签名、分发、安装时，都是以hap/hsp为单位进行签名、分发和安装。4.2.2ArkTS工程目录结构(Stage模型)——发布态包结构在鸿蒙操作系统中，应用的开发、编译、发布和上架部署遵循一个严格的流程：首先，开发者利用鸿蒙OSSDK在集成开发环境（IDE）中编写代码。完成开发后，通过IDE进行编译和打包，生成包含主模块（e