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包中的形态示意图
-
提供程序访问控制能力,详见[访问控制概述]。
访问控制概述
默认情况下,应用只能访问有限的系统资源。但某些情况下,应用存在扩展功能的诉求,需要访问额外的系统数据(包括用户个人数据)和功能,系统也必须以明确的方式对外提供接口来共享其数据或功能。
系统通过访问控制的机制,来避免数据或功能被不当或恶意使用。当前访问控制的机制涉及多方面,包括应用沙箱、应用权限、系统控件等方案。
应用沙箱
系统上运行的应用程序均部署在受保护的沙箱中,通过沙箱的安全隔离机制,可以限制应用程序的不当行为(如应用间非法访问数据、篡改设备等)。每个程序都拥有唯一的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直接拿
与相关Kit的关系
ArkUI: Ability Kit在UIAbility组件可以使用ArkUI提供的组件、事件、动效、状态管理等能力。
ArkTS:ArkTS提供了语言运行时相关能力。