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直接拿