簡介

背景

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

開發前請熟悉鴻蒙開發指導文檔：[gitee.com/li-shizhen-skin/harmony-os/blob/master/README.md]

定義及目標

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

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

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

• 不同設備間的屏幕尺寸、色彩風格等存在差異，頁面如何適配。
• 不同設備的系統能力有差異，如智能穿戴設備是否具備定位能力、智慧屏是否具備攝像頭等，功能如何兼容。

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

說明：

• 應用開發不僅包含應用頁面開發，還包括應用后端功能開發以及服務器端開發等。
• 本文旨在指導開發者如何開發“一多”應用，服務器端開發不在本文探討范圍內。

基礎知識

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

方舟開發框架

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

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

• 聲明式開發范式 ：采用TS語言并進行聲明式UI語法擴展，從組件、動效和狀態管理三個維度提供了UI繪制能力。UI開發更接近自然語義的編程方式，讓開發者直觀地描述UI界面，不必關心框架如何實現UI繪制和渲染，實現極簡高效開發。同時，選用有類型標注的TS語言，引入編譯期的類型校驗，更適用大型的應用開發。
• 類Web開發范式 ：采用經典的HML、CSS、JavaScript三段式開發方式。使用HML標簽文件進行布局搭建，使用CSS文件進行樣式描述，使用JavaScript文件進行邏輯處理。UI組件與數據之間通過單向數據綁定的方式建立關聯，當數據發生變化時，UI界面自動觸發更新。此種開發方式，更接近Web前端開發者的使用習慣，快速將已有的Web應用改造成方舟開發框架應用。主要適用于界面較為簡單的中小型應用開發。

兩種開發范式的對比如下。

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

應用程序包結構

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

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

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

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

• Entry類型的HAP：應用的主模塊。在同一個應用中，同一設備類型只支持一個Entry類型的HAP，通常用于實現應用的入口界面、入口圖標、主特性功能等。
• Feature類型的HAP：應用的動態特性模塊。Feature類型的HAP通常用于實現應用的特性功能，一個應用程序包可以包含一個或多個Feature類型的HAP，也可以不包含。

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

部署模型

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

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

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

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

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

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

說明：

• 應用在不同泛類設備上的UX設計或功能相似時，可以使用部署模型A。
• 應用在同一泛類不同類型設備上UX設計或功能差異非常大時，可以使用部署模型B，但同時也應審視應用的UX設計及功能規劃是否合理。
• 本小節引入部署模型A和部署模型B的概念是為了方便開發者理解。實際上在開發多設備應用時，如果目標設備類型較多，往往是部署模型A和部署模型B混合使用。
• 不管采用哪種部署模型，都應該采用一次編譯。

工程結構

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

• common（公共能力層）：用于存放公共基礎能力集合（如工具庫、公共配置等）。
  common層可編譯成一個或多個HAR包或HSP包（HAR中的代碼和資源跟隨使用方編譯，如果有多個使用方，它們的編譯產物中會存在多份相同拷貝；而HSP中的代碼和資源可以獨立編譯，運行時在一個進程中代碼也只會存在一份），其只可以被products和features依賴，不可以反向依賴。
• features（基礎特性層）：用于存放基礎特性集合（如應用中相對獨立的各個功能的UI及業務邏輯實現等）。
  各個feature高內聚、低耦合、可定制，供產品靈活部署。不需要單獨部署的feature通常編譯為HAR包或HSP包，供products或其它feature使用，但是不能反向依賴products層。需要單獨部署的feature通常編譯為Feature類型的HAP包，和products下Entry類型的HAP包進行組合部署。features層可以橫向調用及依賴common層。
• products（產品定制層）：用于針對不同設備形態進行功能和特性集成。
  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包
    └── ...
    
`HarmonyOS與OpenHarmony鴻蒙文檔籽料：mau123789是v直接拿`

說明：

• 部署模型不同，相應的代碼工程結構也有差異。部署模型A和部署模型B的主要差異點集中在products層：部署模型A在products目錄下同一子目錄中做功能和特性集成；部署模型B在products目錄下不同子目錄中對不同的產品做差異化的功能和特性集成。
• 開發階段應考慮 不同類型設備間最大程度的復用代碼 ，以減少開發及后續維護的工作量。
• 整個代碼工程最終構建出一個[APP包]，應用以APP包的形式發布到應用市場中。

審核編輯 黃宇