鴻蒙剝離 AOSP 不兼容 Android 熱門問題匯總，不吹不黑不吵

上周發了一篇《鴻蒙終于不套殼了？純血 HarmonyOS NEXT 即將到來》的相關資訊，沒想到大家「討（fa）論（xie）」的熱情很高，莫名蹭了一波流量，雖然流量對我來說也沒什么用，但幾百條評論也收獲了一些比較有意思的問題，這里統一挑出來匯總下。

??PS，不賣課不推廣不站隊，只考慮技術角度。

首先討論的前提是基于「HarmonyOS NEXT 版本，去掉了傳統的 AOSP 代碼，僅支持鴻蒙內核和鴻蒙系統的應用」的場景，既然是剝離，那就不是「不支持 apk 后綴安裝」的場景了，那么適配的工作量也就隨之而來。

目前已經有一些企業在進行適配或者已經適配的，適配的方式基本都是基于 skia 的場景去實現，因為 HarmonyOS NEXT 的渲染底層還是 skia ，所以做一些兼容轉化，游戲不用說，基于 OpenGL 和 unity 兼容難度相對不高，主要還是集中于 App 如何兼容的適配等問題上。

那么接下來就是一些有趣的熱門問題匯總

鴻蒙應用能安裝在 Android 系統上嗎？

鴻蒙現在用的是 ArkTs 和 ArkUI ，它們成了唯一指定語言和框架，按照目前的情況看，ArkUI 是無法直接用到 Android 系統，但是華為開源了另外一個項目 ArkUI-X ，ArkUI-X 擴展ArkUI 開發框架到多個 OS 平臺，所以從這個角度看，鴻蒙應用又可以運行到其他平臺。

不負責任的說，有點類似于 compose 和 compose-multiplatform 的關系。

當然，ArkUI-X 項目并不是從 0 開始，它和 Flutter 還是有一些緣分。

ArkUI-X 項目屬于 OpenHarmony 管理，而在 OpenHarmony 下存有 third_party_flutter 等項目依賴，ArkUI-X 里 Flutter 應該只是用于窗口管理和渲染管道到 skia ，沒用到 Dart 部分的 UI 框架，類似于之前提到的微信小程序 skyline 底層利用 Flutter 渲染輸出場景類似。

雖然 ArkUI-X 讓鴻蒙 App 可以運行到其他平臺，但是大家目前更多訴求是現有 App 可以繼續「兼容」到鴻蒙 Next。

鴻蒙 Next 升級會造成斷代嗎？會和WinPhone 一樣滑鐵盧嗎？

確實，一旦鴻蒙開始正式不支持 Android ，那么對開發者生態和用戶肯定會有直接的「沖擊」，這也是鴻蒙 Next 需要面對的最大門檻。

目前我個人理解，鴻蒙的策略就是先穩住大廠，盡量讓大廠能跟進「首發適配」，已知的小紅書、百度、美團、京東等企業都有一定鴻蒙基礎，一些團隊也許是基于 KPI ，也許是基于領導要求，都提前開始了鴻蒙 Next 的支持，所以鴻蒙 Next 在初步生態基礎上還是比當年的 WinPhone 好一些。

例如美圖曾經就有在 skia 層適配鴻蒙的《讓 Flutter 在鴻蒙系統上跑起來》

當然，鴻蒙肯定不會一上來就強制升級，到時候正式推送更新的時候，應該會有提示框告知用戶，我猜測會雙線「鴻蒙 4」和「鴻蒙 Next」共存維護一段時間，就是你不更新，可以繼續用打補丁的鴻蒙 4 過度較長的一段時間，過渡期和用戶維護還是需要的。

接下來是「個人屁話」時間，用于解釋另外一部分評論問題：

從目前來看，鴻蒙 Next 是個博弈，就是華為有存量用戶，也有新增用戶，就是博弈企業的產品愿不愿意放棄這部分市場份額：

之前的評論區說到的，如果網易音樂適配了，那 QQ 音樂是否會跟進？這是一個看誰愿意卷的問題。

目前華為市場份額大概 9.2%，鴻蒙現階段還只在國內，Counterpoint 披露的數據顯示，2023 年 Q1，在中國市場，鴻蒙操作系統的市占率為 8% 。。。。。而 2023 年第一季度，在中國市場，安卓系統占據 72% 市場份額，iOS為 20%，所以這是一個存量市場和新增市場的博弈。

華為手機銷量從 2.4 億臺（2019年）達到高峰后，跌至3,000萬臺（2022年），而 2023 Q1 開始對比 2022 逆勢增長41%，所以 2023 年給的目標手機出貨量是 4000 萬部。

這部分問題在于，它說多不多，但是你說它少，又不能完全忽視，畢竟有存量有新增。

扯遠了，這個話題最后說一下兩個擔心的問題：

升級到 Next 之后，應用數據是否支持升級兼容，在整個系統框架都剝離重組的情況下，原先應用的本地數據是否支持兼容或者遷移，這是一個非常影響升級指標的因素，或者說升級后丟失率多高。
App 后續支持也是一個風向標，應用廠商在鴻蒙上「首發」App 之后，是否能和 Android/iOS 平臺一樣及時迭代跟進，還是「又不是不能用」的維護躺平？

鴻蒙為什么可以通過 OTA 升級剝離 AOSP？如何兼容高通芯片的機器？

這是評論區一個熱門討論點之一，首先大家可能會覺得，自己如何更新自己的內核？看評論區有人的提到的就是「一個人如何舉起自己來」。

這里我也不知道鴻蒙更新的具體路線，根據我的理解和評論區的內容，這里做一些總結：

首先 AOSP 是基于 Linux 內核開發，也就是 AOSP 雖然有 Linux 內核，但是它是以特殊形式存在 AOSP 里，因為一些歷史 GPL 傳染性協議問題，AOSP 不是一個 GUN Linux發行版，所以 AOSP 和 Linux 內核可以分開處理。
類似于 OpenHarmony 使用 LiteOS 內核，HarmonyOS 這層殼可以在 LiteOS 與 AOSP 直接切換，「十分不嚴謹」的比喻：「Flutter 可以通過升級把底層渲染從 skia 更新到 Impeller」，這次 Harmony Next 提到的應該是替換為 “鴻蒙內核”與“華為方舟圖形引擎”。
類似 Android 的 bootloader 是支持 A/B 更新，可用于引導和傳遞需要加載對應內核：https://source.android.com/devices/tech/ota/ab/ab_implement?hl=zh-cn

以上這個主要是從技術層面介紹「一個人如何舉起自己來」的實現，僅作為猜測，不一定是鴻蒙的路子。

另外，華為現存高通芯片和麒麟芯片的機器，這些機器如何通過 OTA 升級支持到 Harmony Next ？麒麟不必說，高通如何可以直接說升級兼容？

這個就要說到原本 AOSP 里面的 HAL（Hardware Abstraction Layer）層的作用了，例如在 Android 8.0之后，framework 與 hal 進行了解耦， framework 存在于 system.img，hal 存在于 vendor.img，進行版本升級時，分為兩次升級。

SoC 廠商的兼容，可以通過適配 hal，將修改打包到 vendor.img, 生成OTA 升級包，推送到手機進行 OTA 升級(framework發生改變，hal 層發生改變) 。

具體可以參考： https://m.elecfans.com/article/2024563.html

這里有個關鍵詞，SoC 廠商的兼容，也就是到時候可能會是 mate40系列（麒麟）更早可以更新到 next，mate50 系列（高通）會相對晚一些。

剝離后的鴻蒙OS怎么樣？和原本 Android 還像嗎？開發方式如何？

這個問題大家還是比較關心，用評論區一位網友的總結就是：

“ ArkUI這玩意大量使用了napi, 邏輯幾乎都封裝在c++寫的framework里，說個笑話: 用他們的彈框組件改個圓角值都改不了，因為底層寫死了。

framework大量借鑒了Android(看ability啟動源碼可以很好復習activity啟動的八股文）, 權限和組件封裝又和iOS靠齊，可以說非常適合跨平臺開發踩坑。”

所以從 java 層面 Android framework 等的代碼已經不見了，Harmony Next 的 framework 基本封裝在 c++ 層，與平臺調用多數走 ffi 調用。

是不是有一種熟悉的味道？嗯，是 Flutter 的味道。

開發體驗上類似 Flutter/Compose 項目，如果硬要說，可能會是像是 SwiftUl 和 Compose 的優點縫合？主要是聲明式 UI開發，然后鏈式寫法和組件命名對于客戶端開發來說應該會很有熟悉感。

開發構建上，鴻蒙 Next 使用的 ArkTS 類似 Dart 構建模式，都是 AOT ，ArkTS 通過 ArkCompiler 構建并優化成機器碼：

ArkCompiler 利用 ArkTS 的靜態類型信息，進行類型推導并生成對象描述和內聯緩存，加速運行時對字節碼的解釋執行；AOT（Ahead-of-Time）Compiler 利用靜態類型信息直接將字節碼編譯生成優化機器碼…

之所以提一嘴這個編譯，是因為有如下圖類似的評論，質疑 ArkTS 是一種網頁應用的，所以也就當純做一個回應，雖然叫 TS，但是其實它并不能「直接」開發 Web。

順帶提一句，華為這次還是「明確」指出了，ArkTS 是在 TypeScript（簡稱TS）的基礎上進行自研的開發語言，就是不知道這個到了自媒體宣傳上會如何解讀了。

接著不得不提一句的就是 「三棵樹」，Flutter 開發應該對于這個很熟悉，官方的解釋是：

ArkUI3.1通過編譯期生成特定函數的方式將 UI 組件更新和數據變更進行細粒度地綁定，實現 UI 更新 Diff 算法從 COMPONENT 和 ELEMENT 樹形結構對比升級為單節點 NODE的函數式更新

從這里看，其實「ArkUI 對 Flutter 開發者確實很友好」。

最后，ArkUI 還提供了一些「高級UI組件擴展能力」大概就是:

XComponent 組件的 C++ 自繪制引擎接入（比如游戲引擎）能力
基于Web組件的 HTML5/Web 的渲染能

主要是為了滿足開發者在游戲、相機、地圖、瀏覽器等復雜應用場景的開發訴求，降低了這類應用移植的門檻。

關于這部分有待后續大家的體驗報告了，可以理解此時大概就是「又不是不能用」的情況。

是否會關閉側載？

其實這個問題我也很好奇，不過我也不確定，Harmony Next 是不是會讓自己生態「對齊」 iOS ，因為這個決定很大程度會影響它以后的命運。

我這里不負責任的猜測是很大概率會關閉側載，先說明這個我沒有任何依據，僅僅是一個猜測，因為既然都不兼容 Android ，那么作為一個全新的系統模式下，構建生態可以會因為「安全」和「合規」等考慮，按照目前「大環境」的理解，我更傾向它最終會關閉側載。

我只是更傾向最終可能會關閉側載，但是我不希望關閉側載。

現有 App 如何兼容 Harmony Next ？

純原生應用（Java/Kotlin + XML）模式直接兼容的可能性，或者說兼容方案目前我是看不到直接兼容的可能性，因為沒了 JVM ，沒了AOSP ，非響應式布局開發，直接兼容的成本不低于從頭再來。

跨平臺框架支持上：

Cordova/Ionic 等本身只需要 WebView 和 JSBridge 等相關支持，兼容反而不難，就是插件部分需要額外補充，成本相對較低
React Native / Weex 部分工作量偏重，前端標簽到原生控件映射的適配，還有樣式兼容會是一個「體力活」，插件生態也是一個問題
Flutter 因為前面提到過的種種原因，純 Flutter 兼容 Harmony Next 成本不會很高，但是未來可能會產生「分叉」，因為目前 Flutter 官方已經開始逐步采用自研 Impeller 替代 skia 渲染，這后續可能會和 Harmony Next 出現分叉，另外插件生態兼容會是一個特別頭痛的問題
uni-app/uts ，這個我不負責的猜測后面它自己就會直接適配了，絲毫不慌。

從更新的消息看，華為內部也主導適配目前的主流跨平臺方案，主動提供反向適配支持，估計后面就會有類似 Flutter for harmony 的社區支持，目前華為適配的跨平臺框架包括有：Flutter、ReactNative、Weex、Taro、uni-app、electron、qt 等等，都是基于 API10 (即 harmonyos next & open harmony 4 的 api)，后續應該者會開源出來交給社區共建。

HDC 現場的 NEXT 展示機也有相關案例：