簡介

背景

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

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

定義及目標

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

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

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

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

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

說明：

• 應(yīng)用開發(fā)不僅包含應(yīng)用頁面開發(fā)，還包括應(yīng)用后端功能開發(fā)以及服務(wù)器端開發(fā)等。
• 本文旨在指導(dǎo)開發(fā)者如何開發(fā)“一多”應(yīng)用，服務(wù)器端開發(fā)不在本文探討范圍內(nèi)。

基礎(chǔ)知識

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

方舟開發(fā)框架

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

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

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

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

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

應(yīng)用程序包結(jié)構(gòu)

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

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

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

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

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

說明： 關(guān)于Entry類型的HAP包、Feature類型的HAP包、HAR包、HSP包以及APP Pack的詳細介紹請參考[應(yīng)用程序包結(jié)構(gòu)說明]

部署模型

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

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

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

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

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

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

說明：

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

工程結(jié)構(gòu)

“一多”推薦在應(yīng)用開發(fā)過程中使用如下的“三層工程結(jié)構(gòu)”。

• common（公共能力層）：用于存放公共基礎(chǔ)能力集合（如工具庫、公共配置等）。
  common層可編譯成一個或多個HAR包或HSP包（HAR中的代碼和資源跟隨使用方編譯，如果有多個使用方，它們的編譯產(chǎn)物中會存在多份相同拷貝；而HSP中的代碼和資源可以獨立編譯，運行時在一個進程中代碼也只會存在一份），其只可以被products和features依賴，不可以反向依賴。
• features（基礎(chǔ)特性層）：用于存放基礎(chǔ)特性集合（如應(yīng)用中相對獨立的各個功能的UI及業(yè)務(wù)邏輯實現(xiàn)等）。
  各個feature高內(nèi)聚、低耦合、可定制，供產(chǎn)品靈活部署。不需要單獨部署的feature通常編譯為HAR包或HSP包，供products或其它feature使用，但是不能反向依賴products層。需要單獨部署的feature通常編譯為Feature類型的HAP包，和products下Entry類型的HAP包進行組合部署。features層可以橫向調(diào)用及依賴common層。
• products（產(chǎn)品定制層）：用于針對不同設(shè)備形態(tài)進行功能和特性集成。
  products層各個子目錄各自編譯為一個Entry類型的HAP包，作為應(yīng)用主入口。products層不可以橫向調(diào)用。

代碼工程結(jié)構(gòu)抽象后一般如下所示：

/application
├── common                  # 可選。公共能力層, 編譯為HAR包或HSP包
├── features                # 可選。基礎(chǔ)特性層
│   ├── feature1            # 子功能1, 編譯為HAR包或HSP包或Feature類型的HAP包
│   ├── feature2            # 子功能2, 編譯為HAR包或HSP包或Feature類型的HAP包
│   └── ...
└── products                # 必選。產(chǎn)品定制層
    ├── wearable            # 智能穿戴泛類目錄, 編譯為Entry類型的HAP包
    ├── default             # 默認設(shè)備泛類目錄, 編譯為Entry類型的HAP包
    └── ...
    
`HarmonyOS與OpenHarmony鴻蒙文檔籽料：mau123789是v直接拿`

說明：

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

審核編輯 黃宇