剛剛過去的2020年底，華為發布了HarmonyOS 2.0手機應用開發者Beta版。對外界，HarmonyOS提出了為萬物互聯而生，讓體驗天生跨端，並且開發跨端應用就像單端一樣簡單。其中，「分布式應用框架」是了解HarmonyOS服務跨端開發最基礎的概念之一。
對於傳統生態——典型如Android，要實現APP在不同設備間的互通，開發者要做的工作很多：是從底層到上層，從通信、數據管理、文件服務到UI的各部分適配和修改。而HarmonyOS將UI以下的基礎服務做了封裝，開發者也因此輕鬆了不少。
HarmonyOS在理念上，就是讓原本孤立的設備，通過「分布式軟總線」串聯起來，並藉由「分布式數據管理」「分布式任務調度」等能力，將所有設備抽象為一個整體，構成虛擬的「超級終端」。數據在超級終端內自由流轉，用戶不需要在意文件或數據究竟在手機、PC還是大屏電視或其他硬體上。各種任務負載，也能由最適合的物理硬體去完成，甚至協同完成。
簡單地說，是用一個HarmonyOS系統來解決IoT所有的問題。與此同時，還能降低跨端開發的難度。HarmonyOS本身隱藏了更多分布式技術的實現細節，包括分布式軟總線、分布式數據管理等技術，都在系統服務層面做了抽象封裝。最終，面向APP開發者的分布式應用框架引入了Ability，Ability就成為理解多端開發的關鍵。
據華為消費者業務軟體部總裁王成錄博士介紹：「Ability相當於鴻蒙應用裡建築材料的最小單元，可以單獨運行在設備上，又可以根據能力的不同，在不同的設備上運行——這個能力，使我們能夠做到一次業務代碼的書寫，就讓應用跑在不同設備上的重要基礎。」
究竟什麼是Ability？針對不同設備場景的應用開發，HarmonyOS在面向APP開發者時的應用框架層，包括UI編程框架、用戶程序框架、Ability框架，都用於解決包括不同設備的形態差異、能力差異等問題。這三個框架所在的位置如下圖所示：
本文著重談的是其中的Ability框架。從HarmonyOS的開發者文檔來看，Ability是應用所具備能力的抽象。一個應用可以包含多個Ability，且HarmonyOS支持應用以Ability為單位進行部署。Ability也是應用跨端部署的「最小遷移單元」，它可彼此間聯合或單獨部署。
Ability可分為FA（Feature Ability）和PA（Particle Ability）兩種類型。不同類型為開發者提供不同的模板，實現不同的業務功能。不同的FA/PA，完成單一功能用戶程序，基於這樣的用戶程序可在多設備間調度、流轉、可分可合。
FA和PA是由系統統一調度的，可以被第三方程序調用集成。Ability的這種存在方式，就HarmonyOS生態構建來看，實現了功能結構的規範化與調用能力的傻瓜化。從這點來看，華為對於Ability的全局規劃，可能還有更長遠的生態構建目標。
也因此，Ability作為系統統一調度的單位，能夠實現無需安裝就使用，且自動更新；而應用開發的跨設備，則體現在，Ability本身是跨設備流轉的，能夠在不同的設備間接續，以及讓不同設備協同提供服務，也就是分布式技術的基礎。
FA（Feature Ability）的生命周期與邏輯接下來就來看看FA和PA這兩種Ability更具體的內容。FA（Feature Ability）支持Page Ability，而PA（元服務）則有Service Ability和Data Ability兩種。在config.json註冊文件中註冊Ability時，可通過配置Ability元素中的「type」屬性來指定Ability模板類型。（類似Activity在AndroidManifest.xml中註冊）
首先聊聊FA（Feature Ability）：FA當前主要就是Page Ability，提供與用戶交互的能力。一個Page可由一個或多個AbilitySlice構成；AbilitySlice則是指應用的單個頁面及其控制邏輯的總和。這比較類似於Android的Activity及其Fragment組件。
實際上，HarmonyOS中的每個頁面都可以用一個FA來表示。任何一個子頁面都可以用AbilitySlice來表示。嘗試在DevEco Studio創建一個HarmonyOS項目，自動生成的項目會包含一個MainAbility和一個MainAbilitySlice。
MainAbility作用為設置路由，子頁面MainAbilitySlice才真正負責頁面中有哪些組件，每個組件的UI等。AbilitySlice常見使用場景比如頁面有多種布局，需對頁面進行動態布局，每種布局對應一個AbilitySlice；頁面有多個tab，則每個tab對應一個AbilitySlice。比如新聞類APP，可能需要展示新聞列表的一個AbilitySlice，還需要一個展示新聞詳情的AbilitySlice。
上面這張圖是Page Ability的生命周期，其中的生命周期回調有onStart()、onActive()、onInactive()、onBackground()、onForeground()、onStop()。它與Activity對應的某些調用看起來類似，雖然可能並非一一對應的關係。
比如說onStart()在創建Page實例時觸發，且對該實例在其生命周期內僅觸發一次；Page在調用onStart()後進入INACTIVE狀態。這對應到Android開發Activity的onCreat()以及onStart()。交互、失去焦點、不對用戶可見、重回前臺、銷毀等狀態，分別對應了不同的回調。這裡不再詳述這幾種不同回調及對應狀態的具體細節，開發者可以查看HarmonyOS開發者文檔來具體了解。
相應的，AbilitySlice與其所屬Page，有著相同的生命周期狀態和同名回調。不過在同一Page中的AbilitySlice之間發生切換時，AbilitySlice本身表現為獨立於Page的生命周期變化，而Page自身的生命周期狀態不變。
在DevEco Studio建立的MainAbility中也能看到，頁面啟動自動調用onStart()，方法體中再調用setMainRoute()，路由到MainAbilitySlice。在MainAbilitySlice中，除了子頁面啟動時，同樣自動調用onStart()，內部方法體中的setUIContent()是用於設置子頁面UI內容的。UI內容則通過布局文件ability_main.xml來指定。
值得一提的是，Page是可以在同一用戶的不同設備間遷移的，最終做到分布式技術中跨端設備無縫切換的特性。這一點還將在下文詳述。
PA（Particle Ability）又是怎麼回事？說完FA，接下來就是PA了。PA有兩個能力，即Service Ability和Data Ability，也就是服務、數據。Service Ability提供後臺運行任務的能力（如音樂播放等）；Data Ability用於對外部提供統一的數據訪問抽象。這兩者是不提供UI的。
Service Ability可由其他應用或Ability啟動，即使用戶切換到其他應用，Service Ability仍將在後臺繼續運行。整體上和Android的Service有些類似。其生命周期具體如下：
形如前文提到的Page Ability，這裡不再贅述。值得一提的是，在創建一個Empty Service Ability時，更早版本的DevEco Studio嚮導配置會出現「visible」複選框。這個選項用於開發者選擇，該創建的Service是否對其他應用程式可見。最新版本似乎已經去掉了這一選項，不過visible屬性仍可以在config.json註冊文件中自行添加，默認為false，如下圖：
用startAbility()方法可啟動另外一個Ability。另外開發者可也以通過將Intent傳遞給該方法來啟動Service（Intent是對象間傳遞信息的載體，包括這裡的一個Ability啟動另一個Ability，或者前文Page Ability部分提到的AbilitySlice導航到另一個AbilitySlice，Intent指定啟動目標並攜帶相關數據）。不僅是啟動本地Service，也支持啟動遠程Service。
設置目標Service信息，通過DeviceId（設備Id）、BundleName（包名稱）以及AbilityName（待啟動的Ability名稱）的Operation對象進行。遠程Service的啟動，就要求前面提到的visible屬性為true。啟動遠程Service代碼示例：
除此之外，如果Service要與其他Service Ability，或者Page Ability交互，需要創建用於連接的Connection，通過connectAbility()就能連接了。具體內容可參加HarmonyOS的開發者文檔。
最後再來談談Data Ability。這個能力用來進行應用管理自身，以及其他應用存儲數據的訪問，並且提供和其他應用共享數據的方法。具體來說，Data既能用於同設備不同應用的數據共享，也支持跨設備不同應用的數據共享。看起來這應該就是HarmonyOS分布式數據管理的重要組成部分了。
具體的數據可以是資料庫也可以是儲存的文件。Data提供對數據的增、刪、改、查、打開文件等接口。這些數據的標識是通過URI地址進行的，格式如下：
創建Data Ability時，和Service一樣也有visible屬性可設置，用於明確是否允許其他應用訪問該Data。從註冊文件config.json中自動生成的代碼裡可以看到提供給外部訪問的URI，以及訪問該Data Ability時需要申請的訪問權限——這個權限應該是可以自定義的：
文件存儲和資料庫存儲的過程和方法，這裡不再多做介紹。而除了Data的創建，在Data的訪問上，通過DataAbilityHelper類即可訪問共享數據，可以是當前應用的，也可以是其他應用提供的。其中針對資料庫的Data創建和訪問，涉及到一系列的方法，具體的操作參見HarmonyOS開發者文檔，基本也是一看就明白的。
Ability怎麼做跨端開發？上面這些內容基本就把Ability的基本邏輯梳理清楚了，對邏輯有個大致概念後，具體開發就比較簡單的。不過更多人關心的，應該是用Ability如何做分布式跨端開發。
前文有關FA、PA的介紹中，多多少少也都談到了遠程或者跨端Ability切換或訪問。以Page Ability為例，前文就提到了跨設備遷移的問題，即將Page在同一用戶的不同設備間遷移。
王成錄博士在談京東直播購物跨端功能開發時，提到的實際上就是Page的遷移。當時王成錄博士說：「基於編程框架，一個人一天就能做這樣一個很好的應用體驗。對開發者而言，四條語句，調幾個函數，就能完成這樣的功能了。」
上面這張PPT包含的幾個步驟主要是，從設備A上的Page請求遷移；HarmonyOS處理遷移任務，並回調設備A上Page的保存數據方法，用於保存遷移必須的數據；最終HarmonyOS在設備B上啟動同一個Page，並回調其恢復數據方法。
這種形式的遷移，本質上屬於HarmonyOS中的「分布式任務調度平臺」。這個平臺可對多設備構成的超級終端提供統一的組件管理能力，為應用定義統一的能力基線、接口形式、數據結構、服務描述語言，以屏蔽應差異；支持遠程啟動、遠程調用、業務無縫遷移等分布式任務。
這套操作實現的，就是Ability跨設備的啟動/關閉、連接/斷開連接，以及遷移能力。不僅是Page，各種Ability的跨設備操作還另外有其設定。總結分布式開發的本質，對開發者而言也就是Ability自由調度、流轉、可分可合的邏輯。
在HarmonyOS 2.0手機應用開發者Beta發布活動上，華為還以暢連通話功能為例，提到了FA/PA設計案例。這項功能按特性總共拆分為5個FA、6個PA。PA的拆分原則為可復用/替換，基於設備間能力存在差異的考慮，以及可以跨設備調用。
經過上面的分析，這張列出FA與PA設計的架構圖應該就相當易於理解了。而Ability的存在，一方面顯得直觀，另一方面我們認為其核心還是在於針對分布式、跨端開發的簡單和友好：跨端開發過程，就和本地開發差不多，而且不需要涉及到往下（包括通訊）的層級。所以Ability才是HarmonyOS分布式技術存在的基礎，而華為在Ability的具體實現上應該是投入了海量精力的。
本文從HarmonyOS整體框架切入，對HarmonyOS中的「Ability」定義及工作原理進行了詮釋，旨在幫忙廣大開發者們進一步理解HarmonyOS核心特性的原理所在，可以說Ability是HarmonyOS入口多樣性以及生態開放性的基因所在，筆者相信自帶這樣基因的HarmonyOS在萬物互聯的時代，定會為應開發者們帶來更為廣闊的跨端交互創新空間。也正是這一系列分布式技術，為應用帶來了更多入口、更好體驗。
責編：Yvonne Geng