Ability Kit简介

Ability Kit（程序框架服务）提供了应用程序开发和运行的应用模型，是系统为开发者提供的应用程序所需能力的抽象提炼，它提供了应用程序必备的组件和运行机制。有了应用模型，开发者可以基于一套统一的模型进行应用开发，使应用开发更简单、高效。

使用场景

应用的多Module开发：应用可通过不同类型的Module（HAP、HAR、HSP）来实现应用的功能开发。其中，HAP用于实现应用的功能和特性，HAR与HSP用于实现代码和资源的共享。
应用内的交互：应用内的不同组件之间可以相互跳转。比如，在支付应用中，通过入口UIAbility组件启动收付款UIAbility组件。
应用间的交互：当前应用可以启动其他应用，来完成某个任务或操作。比如，启动浏览器应用来打开网站、启动文件应用来浏览或编辑文件等。
应用的跨设备流转：通过应用的跨端迁移和多端协同，获得更好的使用体验。比如，在平板上播放的视频，迁移到智慧屏继续播放。
开发前请熟悉鸿蒙开发指导文档 ：[gitee.com/li-shizhen-skin/harmony-os/blob/master/README.md]

能力范围

提供应用进程创建和销毁、应用生命周期调度能力。
提供应用组件运行入口、应用组件生命周期调度、组件间交互等能力。
提供应用上下文环境、系统环境变化监听等能力。
提供应用流转能力。
提供多包机制、共享包、应用信息配置等能力，详见[应用程序包概述]。

应用程序包概述

在基于[Stage模型]开发应用之前，开发者需要了解应用的设计机制、应用程序包结构等基础知识。

应用与应用程序包

用户应用程序泛指运行在设备的操作系统之上，为用户提供特定服务的程序，简称“应用”。一个应用所对应的软件包文件，称为“应用程序包”。

当前系统提供了应用程序包开发、安装、查询、更新、卸载的管理机制，便于开发者开发和管理应用。同时，系统还屏蔽了不同的芯片平台的差异（包括x86/ARM，32位/64位等），应用程序包在不同的芯片平台都能够安装运行，这使得开发者可以聚焦于应用的功能实现。

应用的多Module设计机制

支持模块化开发： 一个应用通常会包含多种功能，将不同的功能特性按模块来划分和管理是一种良好的设计方式。在开发过程中，我们可以将每个功能模块作为一个独立的Module进行开发，Module中可以包含源代码、资源文件、第三方库、配置文件等，每一个Module可以独立编译，实现特定的功能。这种模块化、松耦合的应用管理方式有助于应用的开发、维护与扩展。
支持多设备适配： 一个应用往往需要适配多种设备类型，在采用多Module设计的应用中，每个Module都会标注所支持的设备类型。有些Module支持全部类型的设备，有些Module只支持某一种或几种型的设备（比如平板），那么在应用市场分发应用包时，也能够根据设备类型做精准的筛选和匹配，从而将不同的包合理的组合和部署到对应的设备上。

Module类型

Module按照使用场景可以分为两种类型：

Ability类型的Module： 用于实现应用的功能和特性。每一个Ability类型的Module编译后，会生成一个以.hap为后缀的文件，我们称其为HAP（Harmony Ability Package）包。HAP包可以独立安装和运行，是应用安装的基本单位，一个应用中可以包含一个或多个HAP包，具体包含如下两种类型。
- entry类型的Module：应用的主模块，包含应用的入口界面、入口图标和主功能特性，编译后生成entry类型的HAP。每一个应用分发到同一类型的设备上的应用程序包，只能包含唯一一个entry类型的HAP。
- feature类型的Module：应用的动态特性模块，编译后生成feature类型的HAP。一个应用中可以包含一个或多个feature类型的HAP，也可以不包含。

Library类型的Module： 用于实现代码和资源的共享。同一个Library类型的Module可以被其他的Module多次引用，合理地使用该类型的Module，能够降低开发和维护成本。Library类型的Module分为Static和Shared两种类型，编译后会生成共享包。

Static Library：静态共享库。编译后会生成一个以.har为后缀的文件，即静态共享包HAR（Harmony Archive）。
Shared Library：动态共享库。编译后会生成一个以.hsp为后缀的文件，即动态共享包HSP（Harmony Shared Package）。

说明：
实际上，Shared Library编译后除了会生成一个.hsp文件，还会生成一个.har文件。这个.har文件中包含了HSP对外导出的接口，应用中的其他模块需要通过.har文件来引用HSP的功能。为了表述方便，我们通常认为Shared Library编译后生成HSP。

HAR与HSP两种共享包的主要区别体现在：

共享包类型	编译和运行方式	发布和引用方式
HAR	HAR中的代码和资源跟随使用方编译，如果有多个使用方，它们的编译产物中会存在多份相同拷贝。	HAR除了支持应用内引用，还可以独立打包发布，供其他应用引用。
HSP	HSP中的代码和资源可以独立编译，运行时在一个进程中代码也只会存在一份。	HSP一般随应用进行打包，当前只支持应用内引用，不支持独立发布和跨应用的引用。

图1 HAR和HSP在APP包中的形态示意图
in-app-hsp-har

提供程序访问控制能力，详见[访问控制概述]。

访问控制概述

默认情况下，应用只能访问有限的系统资源。但某些情况下，应用存在扩展功能的诉求，需要访问额外的系统数据（包括用户个人数据）和功能，系统也必须以明确的方式对外提供接口来共享其数据或功能。

系统通过访问控制的机制，来避免数据或功能被不当或恶意使用。当前访问控制的机制涉及多方面，包括应用沙箱、应用权限、系统控件等方案。

应用沙箱

系统上运行的应用程序均部署在受保护的沙箱中，通过沙箱的安全隔离机制，可以限制应用程序的不当行为（如应用间非法访问数据、篡改设备等）。每个程序都拥有唯一的ID（[TokenID]），系统基于此ID识别与限制应用的访问行为。

应用沙箱限定了只有目标受众才能访问应用内的数据，并限定了应用可访问的数据范围。

应用权限

系统根据应用的[APL]等级设置进程域和数据域标签，并通过访问控制机制限制应用可访问的数据范围，从而实现在机制上消减应用数据泄露的风险。

不同APL等级的应用能够申请的权限等级不同，且不同的系统资源（如：通讯录等）或系统能力（如：访问摄像头、麦克风等）受不同的应用权限保护。通过严格的分层权限保护，有效抵御恶意攻击，确保系统安全可靠。

系统控件

系统提供了系统Picker、安全控件等临时授权的方式替代权限申请，在特定的场景中，应用无需向用户申请权限也可临时访问受限资源，实现精准化权限管控，更好地保护用户隐私。

[系统Picker]
由系统独立进程实现，在应用拉起Picker，并由用户操作Picker后，应用可以获取Picker返回的资源或结果。举例说明，当应用需要读取用户图片时，可通过使用照片Picker，在用户选择所需要的图片资源后，直接返回该图片资源，而不需要授予应用读取图片文件的权限。
[安全控件]
由系统提供UI控件，应用在界面内集成对应控件，用户点击后，应用将获得临时授权，从而执行相关操作。举例说明，当应用需要分享当前位置时，可使用位置控件，用户点击后，将会在本次前台期间获得精准定位的授权，可以调用位置服务获取精准定位。当发生灭屏、应用切后台、应用退出等任一情况时，临时授权结束。

亮点/特征

为复杂应用而设计
- 多个应用组件共享同一个ArkTS引擎（运行ArkTS语言的虚拟机）实例，应用组件之间可以方便的共享对象和状态，同时减少复杂应用运行对内存的占用。
- 采用面向对象的开发方式，使得复杂应用代码可读性高、易维护性好、可扩展性强。
- 提供模块化能力开发的支持。
原生支持应用组件级的跨端迁移和多端协同
Stage模型实现了应用组件与UI解耦：
- 在跨端迁移场景下，系统在多设备的应用组件之间迁移数据/状态后，UI便可利用ArkUI的声明式特点，通过应用组件中保存的数据/状态恢复用户界面，便捷实现跨端迁移。
- 在多端协同场景下，应用组件具备组件间通信的RPC调用能力，天然支持跨设备应用组件的交互。
支持多设备和多窗口形态
应用组件管理和窗口管理在架构层面解耦：
- 便于系统对应用组件进行裁剪（无屏设备可裁剪窗口）。
- 便于系统扩展窗口形态。
- 在多设备（如桌面设备和移动设备）上，应用组件可使用同一套生命周期。
平衡应用能力和系统管控成本
Stage模型重新定义应用能力的边界，平衡应用能力和系统管控成本。
- 提供特定场景（如服务卡片、输入法）的应用组件，以便满足更多的使用场景。
- 规范化后台进程管理：为保障用户体验，Stage模型对后台应用进程进行了有序治理，应用程序不能随意驻留在后台，同时应用后台行为受到严格管理，防止恶意应用行为。
- HarmonyOS与OpenHarmony鸿蒙文档籽料：mau123789是v直接拿