HarmonyOS 应用开发 - 应用程序框架

一、 应用程序框架（Ability Kit）

!!#ff0000 提供了应用程序 开发和运行 的 应用模型!!，是系统为开发者提供的应用程序所需能力的抽象，提供了应用程序必备的组件和运行机制

使用场景

1. 应用的多 Module 开发： 应用可以通过不同类型的Module（HAP,HAR,HSP）来实现应用功能的开发
2. 应用内交互： 应用内不同组件之间可以相互跳转
3. 应用间交互： 当前应用可以启动其他应用，来完成某个任务或操作。（启动浏览应用打开网页，启动文件应用浏览或编辑文件等）
4. 应用间跨设备流转： 通过应用的跨端迁移和多端协同，获得更好的使用体验

能力范围

1. 提供应用进程的创建、应用生命周期销毁的能力
2. 提供应用组件运行入口、应用组件生命周期调度、组件间交互的能力
3. 提供应用上下文环境、系统环境变化监听等能力
4. 提供应用流转能力
5. 提供多包机制、共享包、应用信息配置等能力
6. 提供进程访问控制能力
7. 提供密码自动填充能力

特征

1. 为复杂应用而设计

• 多个应用组件共享一个 ArkTS 引擎实例，方便共享状态，同时减少内存占用
• 采用面向对象的开发方式，使复杂应用代码可读性高、易维护性好、可扩展性强
• 提供模块化的开发能力

3. 原生支持应用组件级的跨端迁移和多端协同
4. 支持多设备和多窗口形态
5. 平衡应用能力和系统管控成本

二、 应用模型

应用模型是系统为开发者提供的应用程序所需能力的抽象提炼，提供了!!#ff0000 应用程序必备的组件和运行机制!!。有了应用模型，开发者可以根据一套统一的模型进行应用开发，使应用开发变得简单、高效

1. 应用模型构成要素

• 应用组件
• 应用进程模型
• 应用线程模型
• 应用任务管理模型
• 应用配置文件

2. FA (Feature Ability) 模型和 Stage 模型

• FA: 从 API 7 开始支持的模型，已经不再主推
• Stage 模型： 从API 9 开始新增的模型，是目前主推以及会长期演进的模型。在这种模型中由于提供了 AbilityStage 和 WindowStage 等类作为应用组件和 window 窗口的"舞台"，因此成为 Stage 模型
• 两种模型的区别： FA 模型中每个组件独享一个ArkTS 引擎实例，而Stage 模型中，多个应用组件共享同一个ArkTS 引擎实例。因此在Stage 模型中，应用组件之间可以方便的共享对象和状态，同时减少复杂应用运行对内存的占用
• Stage 模型作为主推模型，开发者通过它能够更加便利的开发出分布式场景的复杂应用

项目	FA 模型	Stage 模型
应用组件	1. !!#0000ff 组件分类：!! - pageAbility 组件： 包含UI, 提供UI展示能力 - ServiceAbility 组件: 提供后台服务能力 - DataAbility 组件: 提供数据分享能力 2. !!#0000ff 开发方式：!! 通过到处匿名对象、固定入口文件的方式指定应用组件，开发者无法进行派生，不利于扩展能力	1. !!#0000ff 组件分类：!! - UIAbility: 提供UI能力，主要用于用户交互 - ExtensionAbility: 提供特定场景（卡片、输入法等）的扩展能力，慢猪更多使用场景 2. !!#0000ff 开发方式: !!采用面向对象的方式，将应用组件以类似接口的形式开放给开发者，可以进行派生，利于扩展
进程模型	!!#0000ff 有两类进程：!! 1. 主进程 2. 渲染进程	!!#0000ff 有三类进程!!： 1. 主进程 2. ExtensionAbility 进程 3. 渲染进程
线程模型	1. !!#0000ff 一个 ArkTS引擎实例的创建!!： 一个进程可以运行多个应用组件实例，每个应用组件实例运行在一个单独的ArkTS 引擎实例中 !!#0000ff 2. 线程模型：!! 每个ArkTS 引擎实例都运行在一个单独线程上（非主线程，主线程没有ArkTS引擎实例） 3. !!#0000ff 进程内共享对象：!! !!#ff0000 不支持!!	1.!!#0000ff ArkTS 引擎实例的创建：!! 一个进程可以创建多个应用组件实例，所有应用组件实例共享一个ArkTS引擎实例 2. !!#0000ff 线程模型：!! ArkTS 引擎实例在主线程上创建 3. !!#0000ff 进程内对象共享：!! !!#ff0000 支持!!
应用配置文件	使用config.json 描述应用信息、HAP信息 和应用组件信息	使用 app.json5描述应用信息, 使用module.json5 描述HAP信息、应用组件信息

**应用模型 **

三、 应用程序包结构

应用的多 Module 设计机制

1. 支持模块化开发： 将不同功能特性，按照模块来划分和管理； 将每个功能模块当作一个独立的 Module 进行开发。
   • Module 中包含源代码、资源文件、第三方库、配置文件等
   • 每个Module 可以独立编译，实现特定功能
2. 支持多设备适配： 在采用多 Module 设计的应用中，每个 Module 都会标注所支持的设备类型

Module 类型

根据使用场景分为两种类型

1. Ability 类型的 Module： 用于实现应用的功能和特性； 每个 Ability类型的Module编译之后都会生成一个 以 !!#0000ff .hap !!为后缀的文件，成为 HAP(Harmony Ability Package)包

   • HAP 包可以独立安装和运行，是应用安装的基本单位，一个应用中可以包含一个或者多个HAP包：
     • Entry 类型的 Module： 应用的主模块，包含应用的入口界面、入口图标和主功能特性，编译后生成HAP
     • Feature 类型的 Module: 应用的动态模块编译后生成feature 类型的HAP

2. Library 类型的 Module： 用于实现代码和资源共享

   • 同一个 Library 类型 的Module 可以被其他Module 引用多次
     -!!#ff0000 Static Library!!: 静态共享库， 编译后生成一个!!#0000ff .har !!为后缀的文件，即静态共享包 HAR(Harmony Archive)
   • !!#ff0000 Shared Library:!! 动态共享库。编译后会生成一个 !!#0000ff .hsp !!为后缀的文件，即动态共享包 HSP(Harmony Shared Package)