萬物互聯時代，應用的設備底座將從幾十億手機擴展到數百億設備。全新的全場景設備體驗，正深入改變消費者的使用習慣， 同時應用開發者也面臨設備底座從手機單設備到全場景多設備的轉變，通過全場景多設備作為全新的底座，為消費者帶來萬物互聯時代更為高效澝便捷的體驗。新的場景同時也帶來了新的挑戰澞開發者不僅要支持更加多樣化的設備，還要支持跨設備的協作。不同設備類型意味著不同的傳感器能力、硬件能力、屏幕尺寸、操作系統和開發語言，還意味著差異化的交互方式。同時跨設備協作也讓開發者面臨分布式開發帶來的各種復雜性，例如跨設備的網絡通信、數據同步等。若采取傳統開發模式，適配和管理工作量將非常巨大。當前移動應用開發中遇到的主要挑戰包括：

• 針對不同設備上的不同操作系統，重復開發，維護多套版本；
• 多種語言棧，對人員技能要求高；
• 多種開發框架，不同的編程范式；
• 命令式編程，需關注細節，變更頻繁，維護成本高。

為了更好的抓住機遇，應對萬物互聯所帶來的系列挑戰，新的應用生態應該具備如下特征：

• 單一設備延伸到多設備：應用一次開發就能在多個設備上運行，軟件實體能夠從單一設備轉移到其他設備上，且多個設備間能夠協同運行，給消費者提供全新的分布式體驗；
• 厚重應用模式到輕量化服務模式：提供輕量化的服務，最小化資源消耗，一步直達， 快速完成消費者特定場景的任務；
• 集中化分發到 AI 加持下的智慧分發：為消費者提供智慧場景服務，實現“服務找人”；
• 純軟件到軟硬芯協同的 AI 能力：提供軟硬芯協同優化的原生 AI 能力，全面滿足應用戶高性能訴求；

以上就是鴻蒙生態應用開發白皮書里萬物互聯時代應用開發的機遇、挑戰和趨勢章節里的描述，代表了鴻蒙人的思考和出發點，接下來我們就簡單解讀下這些挑戰和趨勢是什么？

簡單解讀

具體挑戰是什么？

• 移動端我們有android，ios兩種主流操作系統，開發語言，接口，所有技術細節都不一樣，找兩者都會的工程師難，那應用廠商若是要做APP跑不同設備上就得用兩套班子，人力成本大；第二，android，ios分裂產品形態多，手表，PAD，手機，車機，電視，PC，未來可能更多，那同理對APP開發維護就是更大的挑戰，不同的交互，不同的UI，不同版本，不同團隊，如何保證產品一致，穩定，同步，體驗，挑戰巨大；第三再設想下未來，音箱，燈光，空調，冰箱，甚至是廣告牌，監視器，攝像頭，無人機，機器人所有的聯網智能設備，這種面向未來的開發我們要做什么準備？

下面我們就對這三進行具體分解，也就是上段所指的具體特征：

在應用開發側

• 對應用開發者，最直接的問題就是UI問題，如布局，樣式，交互等，這個其實大家都有方案，比如說自適應布局，當外部容器大小發生變化時，元素可以根據相對關系自動變化以適應外部容器變化的布局能力。相對關系如占比、固定寬高比、顯示優先級等。當前自適應布局有4種：[ 線性布局]、[ 層疊布局]、[ 彈性布局]、[ 相對布局]。自適應布局能力可以實現界面顯示隨外部容器大小連續變化；響應式布局，當外部容器大小發生變化時，元素可以根據斷點、柵格或特定的特征（如屏幕方向、窗口寬高等）自動變化以適應外部容器變化的布局能力。當前響應式布局能力有2種：[ 媒體查詢]、[ 柵格布局]。這部分基于華為豐富應用場景的支撐，以及對內容的深入理解，使用過程中大家應該能發現有些空間更智能，更好用；
• 對應用模型來說，原來android和ios上的原生應用都是厚重的，現在有些應用幾個G，10幾個G都有，平均尺寸也有幾百兆，而鴻蒙化的HAP則提出了新的設計方式，HarmonyOS的用戶應用程序包以APPPack （Application Package）形式發布，它是由一個或多個 HAP （HarmonyOS Ability Package）以及描述每個HAP屬性的pack.info組成。HAP是[ Ability]的部署包，HarmonyOS應用代碼圍繞Ability組件展開。HAR（HarmonyOS Ability Resources）可以提供構建應用所需的所有內容，包括源代碼、資源文件和config.json文件。HAR不同于HAP，HAR不能獨立安裝運行在設備上，只能作為應用模塊的依賴項被引用。HSP（HarmonyOS Shared Package）：這是一種新增的編譯產物。HSP 使得模塊可以以運行態復用的形式共享。相較于 HAR，當有多個 HAP 包依賴于同一個 HSP時，最終的打包產物中，HSP 只會存在一份。除了這三種應用包的格式，為了應用輕量化，HarmonyOS提出元服務概念，什么意思？簡單類比就是小程序，形式還是HAP的形式，但是用卡片方式展現，歸應用程序框架管理，入口多，易被喚出。最后，應用還分出各種Ability，這是應用程序框架中最基本的抽象單位，代表最小的應用功能單元。在現在主推的Stage模型中，Ability也分兩大類：
  • UIAbility：應用的主入口，對應桌面上的圖標。一個 UIAbility 實例對應一個任務。一個 UIAbility 中的通常包含多個ArkUI頁面；
  • ExtensionAbility：ExtensionAbility 有多個具體的子類型，例如：FormExtension
    用來開發萬能卡片， InputMethodExtensionAbility 用來開發輸入法等。
    

以上這兩點就是從功能和形式上解決了適配不同屏的問題，解決了應用大的問題，也解決了應用形態的問題，Ability的提出跟解決了界面和功能的問題。鴻蒙運用了解構的方式把大問題拆解成立一些小問題，然后加以實現和演進。當然這后面還包括工程、上架，這部分說起來就是另外一塊事情了，我們今天就不再深入分析。簡答分析下場景：

• 模式 1：應用或服務的 UI 自適應不同尺寸的設備屏幕，并且在不同設備的功能相同，可以實現多設備共享一個 HAP 包。這種場景下建議開發者通過一個模塊來開發，并配置該模塊支持多設備，然后再編譯構建生成一個 HAP，分發到不同類型的設備上運行。
• 模式 2：應用或服務的 UI、功能在不同設備間存在差異，無法實現 HAP 包多設備歸一。可根據實際情況設置不同模塊適用的設備類型，編譯構建多個 HAP 包，一起上架。HUAWEI AppGallery Connect 會自動提取 HAP 中的設備類型的配置信息，為對應的設備自動分發正確的 HAP 包組合。

在系統開發側

• 事件歸一抽象：不同設備間的交互方式等存在差異，如觸摸、鍵盤、鼠標、語音、手寫筆等，鴻蒙系統將不同設備的輸入映射成歸一交互事件，從而簡化開發者適配邏輯。以縮放交互為例，通過多指觸控的張合來完成縮放動作，在多設備場景下，縮放交互會出現多種不同的操作輸入方式，比如手表就是表冠旋轉，鼠標就是滾輪。
• 組件歸一響應：當應用部署在不同設備上供用戶使用時，需要支持多種 I/O 設備，界面呈現出相應的狀態為用戶提供正確的視覺引導。例如觸摸時顯示按壓狀態，鼠標特有的懸停狀態，鍵盤走焦狀態。渇蒙系統默認提供多種交互方式的組件實現，方便開發者支持多種輸入方式。
• 設備能力抽象：不同設備間的軟、硬件能力等存在差異，如設備是否具備定位能力、是否具備攝像頭、
  是否具備藍牙功能等，鴻蒙系統需要對設備能力進行邏輯抽象，并提供接口來查詢設備是否支持某種能力，方便開發者進行不同軟、硬件能力的功能適配。在鴻蒙系統中，使用SystemCapability（簡寫為 SysCap）定義每個部件對應用開發者提供的系統軟硬件能力。應用開發者基于統一的方式訪問不同設備的能力。
• 元服務開發：元服務是鴻蒙系統提供的一種全新的應用形態，具有獨立入口，用戶可通過點擊、碰一碰、掃一掃等方式直接觸發，無需顯式安裝，由程序框架后臺靜默安裝后即可使用，可為用戶提供便捷服務。元服務入口多，在服務中心可見，也能通過語音，NFC，攝像頭等聯動喚入，然后可以用戶無感安裝和卸載，即用即走；元服務還支持流轉，通過分布式軟總線的加持，元服務支持跨端遷移（將軟件實體從一個設備轉移到另一個設備，比如手機視頻遷移到智慧屏）或多設備協同（多個物理設備上的軟件共同完成一件事情，比如電視投屏+手機遙控，但是這個細分也好幾種，比如顯示協同，不同大屏和小屏顯示不同東西；交互協同，手機輸入，智慧屏顯示；算力協同）。

系統側開發想盡辦法提供一站式解決方案，抽象輸入，抽象交互，抽象數據，抽象硬件，無線壓縮所有的可見路徑，讓應用只聚焦業務。所以這部分對應用開發者來說就是統一接口，統一工程，統一規范；對系統開發者來說就是一個足夠具象的微服務森林，沒一個端到端的功能都需要仔細梳理并有彈性和生命力。系統側其實做了太多的工作，軟總線，分布式，ArkUI，應用管理，SA化，大量的細化，解耦工作才能使得應用即服務這樣的能力在系統層生根發芽。這部分說起來簡單，管理起來那正是千頭萬緒，而且隨著接入硬件形態的不斷增加、復雜，如何做兼容性，如何保證體驗，如何減低整個系統的可維護性，才是最大的挑戰?？梢钥闯鰜恚櫭筛采w千行百業的決心和勇氣，也可以預見系統的龐雜和勃勃生機。接入廠商的增多，鴻蒙原生應用的增多，希望大家能碰撞出更多的、更實用的場景和一多能力。

審核編輯 黃宇