背景

隨著終端設備形態(tài)日益多樣化，分布式技術逐漸打破單一硬件邊界，一個應用或服務，可以在不同的硬件設備之間隨意調用、互助共享，讓用戶享受無縫的全場景體驗。而作為應用開發(fā)者，廣泛的設備類型也能為應用帶來廣大的潛在用戶群體。但是如果一個應用需要在多個設備上提供同樣的內容，則需要適配不同的屏幕尺寸和硬件，開發(fā)成本較高。OpenHarmony系統(tǒng)面向多終端提供了“一次開發(fā)，多端部署”（后文中簡稱為“一多”）的能力，讓開發(fā)者可以基于一種設計，高效構建多端可運行的應用。

定義及目標

定義：一套代碼工程，一次開發(fā)上架，多端按需部署。

目標：支撐開發(fā)者快速高效的開發(fā)支持多種終端設備形態(tài)的應用，實現(xiàn)對不同設備兼容的同時，提供跨設備的流轉、遷移和協(xié)同的分布式體驗。

為了實現(xiàn)“一多”的目標，需要解決兩個基礎問題：

• 不同設備間的屏幕尺寸、色彩風格等存在差異，頁面如何適配。

• 不同設備的系統(tǒng)能力有差異，如智能穿戴設備是否具備定位能力、智慧屏是否具備攝像頭等，功能如何兼容。

從第4章開始將從UX設計、系統(tǒng)能力等角度，詳盡的解答上述問題。

說明：

• 應用開發(fā)不僅包含應用頁面開發(fā)，還包括應用后端功能開發(fā)以及服務器端開發(fā)等。

• 本文旨在指導開發(fā)者如何開發(fā)“一多”應用，服務器端開發(fā)不在本文探討范圍內。

基礎知識

為了更好的閱讀后面的章節(jié)，本小節(jié)主要介紹了一些基礎知識，方便讀者理解內容。

方舟開發(fā)框架

方舟開發(fā)框架（簡稱：ArkUI）提供開發(fā)者進行應用UI開發(fā)時所必須的能力。

方舟開發(fā)框架提供了兩種開發(fā)范式，分別是基于JS擴展的類Web開發(fā)范式（后文中簡稱為“類Web開發(fā)范式”）和基于ArkTS的聲明式開發(fā)范式（后文中簡稱為“聲明式開發(fā)范式”）。

• 聲明式開發(fā)范式：采用TS語言并進行聲明式UI語法擴展，從組件、動效和狀態(tài)管理三個維度提供了UI繪制能力。UI開發(fā)更接近自然語義的編程方式，讓開發(fā)者直觀地描述UI界面，不必關心框架如何實現(xiàn)UI繪制和渲染，實現(xiàn)極簡高效開發(fā)。同時，選用有類型標注的TS語言，引入編譯期的類型校驗，更適用大型的應用開發(fā)。

• 類Web開發(fā)范式：采用經典的HML、CSS、JavaScript三段式開發(fā)方式。使用HML標簽文件進行布局搭建，使用CSS文件進行樣式描述，使用JavaScript文件進行邏輯處理。UI組件與數(shù)據之間通過單向數(shù)據綁定的方式建立關聯(lián)，當數(shù)據發(fā)生變化時，UI界面自動觸發(fā)更新。此種開發(fā)方式，更接近Web前端開發(fā)者的使用習慣，快速將已有的Web應用改造成方舟開發(fā)框架應用。主要適用于界面較為簡單的中小型應用開發(fā)。

兩種開發(fā)范式的對比如下。

說明： 聲明式開發(fā)范式占用內存更少，更推薦開發(fā)者選用聲明式開發(fā)范式來搭建應用UI界面。

應用程序包結構

在進行應用開發(fā)時，一個應用通常包含一個或多個Module。Module是應用/服務的基本功能單元，包含了源代碼、資源文件、第三方庫及應用/服務配置文件，每一個Module都可以獨立進行編譯和運行。

Module分為“Ability”和“Library”兩種類型：

• “Ability”類型的Module編譯后生成HAP包。

• “Library”類型的Module編譯后生成HAR包或HSP包。

應用以APP Pack形式發(fā)布，其包含一個或多個HAP包。HAP是應用安裝的基本單位，HAP可以分為Entry和Feature兩種類型：

• Entry類型的HAP：應用的主模塊。在同一個應用中，同一設備類型只支持一個Entry類型的HAP，通常用于實現(xiàn)應用的入口界面、入口圖標、主特性功能等。

• Feature類型的HAP：應用的動態(tài)特性模塊。Feature類型的HAP通常用于實現(xiàn)應用的特性功能，一個應用程序包可以包含一個或多個Feature類型的HAP，也可以不包含。

說明： 關于Entry類型的HAP包、Feature類型的HAP包、HAR包、HSP包以及APP Pack的詳細介紹請參考應用程序包結構說明 。

部署模型

“一多”有兩種部署模型：

• 部署模型A：不同類型的設備上按照一定的工程結構組織方式，通過一次編譯生成相同的HAP（或HAP組合）。

• 部署模型B：不同類型的設備上按照一定的工程結構組織方式，通過一次編譯生成不同的HAP（或HAP組合）。

開發(fā)者可以從應用UX設計及應用功能兩個維度，結合具體的業(yè)務場景，考慮選擇哪種部署模型。當然，也可以借助設備類型分類，快速做出判斷。

從屏幕尺寸、輸入方式及交互距離三個維度考慮，可以將常用類型的設備分為不同泛類：

• 默認設備、平板
• 車機、智慧屏
• 智能穿戴
• ……

對于相同泛類的設備，優(yōu)先選擇部署模型A，對于不同泛類設備，優(yōu)先選擇部署模型B。

說明：

• 應用在不同泛類設備上的UX設計或功能相似時，可以使用部署模型A。

• 應用在同一泛類不同類型設備上UX設計或功能差異非常大時，可以使用部署模型B，但同時也應審視應用的UX設計及功能規(guī)劃是否合理。

• 本小節(jié)引入部署模型A和部署模型B的概念是為了方便開發(fā)者理解。實際上在開發(fā)多設備應用時，如果目標設備類型較多，往往是部署模型A和部署模型B混合使用。

• 不管采用哪種部署模型，都應該采用一次編譯。

工程結構

“一多”推薦在應用開發(fā)過程中使用如下的“三層工程結構”。

• common（公共能力層）：用于存放公共基礎能力集合（如工具庫、公共配置等）。

  common層可編譯成一個或多個HAR包或HSP包（HAR中的代碼和資源跟隨使用方編譯，如果有多個使用方，它們的編譯產物中會存在多份相同拷貝；而HSP中的代碼和資源可以獨立編譯，運行時在一個進程中代碼也只會存在一份），其只可以被products和features依賴，不可以反向依賴。

• features（基礎特性層）：用于存放基礎特性集合（如應用中相對獨立的各個功能的UI及業(yè)務邏輯實現(xiàn)等）。

  各個feature高內聚、低耦合、可定制，供產品靈活部署。不需要單獨部署的feature通常編譯為HAR包或HSP包，供products或其它feature使用，但是不能反向依賴products層。需要單獨部署的feature通常編譯為Feature類型的HAP包，和products下Entry類型的HAP包進行組合部署。features層可以橫向調用及依賴common層。

• products（產品定制層）：用于針對不同設備形態(tài)進行功能和特性集成。

  products層各個子目錄各自編譯為一個Entry類型的HAP包，作為應用主入口。products層不可以橫向調用。

代碼工程結構抽象后一般如下所示：

/application
├── common                  # 可選。公共能力層, 編譯為HAR包或HSP包
├── features                # 可選?；A特性層
│   ├── feature1            # 子功能1, 編譯為HAR包或HSP包或Feature類型的HAP包
│   ├── feature2            # 子功能2, 編譯為HAR包或HSP包或Feature類型的HAP包
│   └── ...
└── products                # 必選。產品定制層
    ├── wearable            # 智能穿戴泛類目錄, 編譯為Entry類型的HAP包
    ├── default             # 默認設備泛類目錄, 編譯為Entry類型的HAP包
    └── ...

說明：

• 部署模型不同，相應的代碼工程結構也有差異。部署模型A和部署模型B的主要差異點集中在products層：部署模型A在products目錄下同一子目錄中做功能和特性集成；部署模型B在products目錄下不同子目錄中對不同的產品做差異化的功能和特性集成。

• 開發(fā)階段應考慮不同類型設備間最大程度的復用代碼，以減少開發(fā)及后續(xù)維護的工作量。

• 整個代碼工程最終構建出一個APP包，應用以APP包的形式發(fā)布到應用市場中。