作者：michalliu，騰訊 WXG 客戶端開發(fā)工程師

華為鴻蒙OS有什么創(chuàng)新，是否自主研發(fā)完全開源，本文帶你深入鴻蒙的世界。

一、初識鴻蒙

國內(nèi)在計算機基礎(chǔ)核心領(lǐng)域缺乏建樹，一直沒有自主知識產(chǎn)權(quán)的操作系統(tǒng)。之前又出過多起諸如漢芯，紅芯瀏覽器等造假事件，猶如現(xiàn)實世界的“狼來了”，使國人對任何打著自主知識產(chǎn)權(quán)宣傳的產(chǎn)品都會戴著放大鏡去看，那么鴻蒙到底是不是個例外？

鴻蒙是個很泛的概念，鴻蒙不僅一個操作系統(tǒng)，還是一個生態(tài)。鴻蒙這個詞在不同的場景下指代不同的東西。根據(jù)華為官方IDE DevEco Studio 的應(yīng)用模板可以看出，目前鴻蒙支持的設(shè)備有手機，平板，電視，手表，汽車，以及相機等小家電等等，不同的技術(shù)棧開發(fā)的應(yīng)用支持的設(shè)備種類也不同。其中Java類型的應(yīng)用支持的設(shè)備類型最為豐富，JS類型的應(yīng)用其次，C++應(yīng)用支持的類型最少。

這些設(shè)備大體上可以分為嵌入式和非嵌入式兩種。根據(jù)應(yīng)用所需內(nèi)存大小又可以分為L0-L5六個級別：

在嵌入式領(lǐng)域， 鴻蒙指是一款嵌入式操作系統(tǒng)，鴻蒙的核心為LiteOS，系統(tǒng)只能在配套的硬件（開發(fā)板）上運行，并非通用的操作系統(tǒng)，OpenHarmony是其對外開源的版本，在2020年9月在gitee上開源OpenHarmony 1.0，關(guān)于這款系統(tǒng)華為自身的文檔比較欠缺，這里有較為詳細的開發(fā)者文檔。

在非嵌入式領(lǐng)域， 鴻蒙指的是一款叫鴻蒙的手機操作系統(tǒng)，最近網(wǎng)上熱議的“此應(yīng)用專為舊版鴻蒙打造”令人疑竇叢生。

因為截至目前鴻蒙只發(fā)布了一個版本，根本不存在所謂的舊版鴻蒙。由于鴻蒙的手機版操作系統(tǒng)并未開源，提示語又與android如此類似，不得不令人懷疑是字符串批量替換。那么事實真是字符串替換如此簡單嗎？下文將會予以分析。

總的來說，鴻蒙絕不僅僅指的是操作系統(tǒng)，華為的野心也絕不止于此，華為是要打造一個叫鴻蒙的生態(tài)，我們不排除未來會有鴻蒙SDK植入其它廠商的設(shè)備，使這些設(shè)備也具備運行鴻蒙應(yīng)用的能力，甚至是運行在傳統(tǒng)的Windows、Linux上的設(shè)備，那么這些設(shè)備也可以說是一個鴻蒙設(shè)備，是鴻蒙生態(tài)的一部分。

二、鴻蒙核心

經(jīng)調(diào)研，我們認為鴻蒙生態(tài)的核心是以下四點：

1、多設(shè)備兼容

即開發(fā)出來的應(yīng)用，可以覆蓋多種類型的設(shè)備，屏蔽底層OS的差異，類似目前火熱的Flutter所解決的問題。

2、卡片式應(yīng)用

在多設(shè)備兼容的基礎(chǔ)上帶來一致的，高性能的交互體驗。可以理解為跨設(shè)備，跨平臺，跨網(wǎng)絡(luò)的輕量Widget。

3、軟總線

在以上兩點的基礎(chǔ)上，降低設(shè)備間互聯(lián)互通的門檻。主要基于以下三點改進：

（1）設(shè)備間的發(fā)現(xiàn)和連接：從手動發(fā)現(xiàn)，進化成自發(fā)現(xiàn)：

（2）多設(shè)備互聯(lián)后的組網(wǎng)技術(shù)：軟總線組網(wǎng)-異構(gòu)網(wǎng)絡(luò)組網(wǎng)：

（3）多設(shè)備多協(xié)議間的高效傳輸技術(shù)：

4、通信安全

要實現(xiàn)設(shè)備間的互聯(lián)互通，那么安全無疑是特別重要的環(huán)節(jié)。這里的問題是如何保證正確的人使用正確的設(shè)備，消費正確的數(shù)據(jù)。即要解決如下三個問題：

（1） 如何保證消費者對設(shè)備的鑒權(quán)是安全的，保證設(shè)備是原廠生產(chǎn)，沒有被篡改的？（正確的設(shè)備）

（2） 如何保證消費者操作設(shè)備數(shù)據(jù)是安全的？(正確的人)?

（3）如何保證消費者數(shù)據(jù)安全?（正確使用數(shù)據(jù)）

鴻蒙在系統(tǒng)和數(shù)據(jù)通信安全方面有較為完善的考慮。

三、系統(tǒng)層分析

基于鴻蒙已經(jīng)開源的openharmony源碼統(tǒng)計，openharmony包含C代碼2KW行，C++ 500W行。

1、內(nèi)核部分

鴻蒙宣傳的微內(nèi)核，并未說明是哪個鴻蒙，華為目前已經(jīng)發(fā)布的內(nèi)核包括：

1、Linux 面向手機 (L5級別設(shè)備)?

2、LiteOS-a 面向有MMU的設(shè)備 (>=L1級別)?

3、LiteOS-m 面向無MMU的嵌入式設(shè)備 (L0級別)

目前行業(yè)內(nèi)對內(nèi)核進行分類主要是：

微內(nèi)核優(yōu)點：?

1、代碼量小，可以形式化驗證，可以減少bug量，幾乎可以0 bug，另外更加方便移植。?

2、各個系統(tǒng)組件或者服務(wù)如果存在問題可以直接重啟服務(wù)，減少核心組件異常對整個系統(tǒng)的破壞，并按需組織系統(tǒng)服務(wù)。

3、各組件可以按需加載（現(xiàn)在宏內(nèi)核也支持模塊動態(tài)加載卸載）。

4、可以規(guī)避GPL協(xié)議。

微內(nèi)核缺點：

1、所有資源獲取都需要通過IPC，IPC又必須陷入內(nèi)核，所以會導(dǎo)致頻繁的陷入內(nèi)核，或者多次拷貝，導(dǎo)致性能下降。當然IPC通信效率隨著深入研究與技術(shù)發(fā)展逐步提高。

2、對于中斷響應(yīng)，需要映射到用戶空間再處理，效率較低。

3、大量使用某些系統(tǒng)服務(wù)的時候，會導(dǎo)致進程上下文切換，增加系統(tǒng)負擔(dān)。

而目前開源出來的鴻蒙代碼 LiteOS-a按照業(yè)界對內(nèi)核分類依舊是宏內(nèi)核。至于華為是否存在微內(nèi)核但沒有開源，還是在實現(xiàn)鴻蒙過程中，又重新選擇了宏內(nèi)核，我們不得而知。

1.1 LiteOS-M

LiteOS-M和HW以前開源的Lite OS基本相同，進行部分結(jié)構(gòu)性調(diào)整，當前只適用于cortex-m3、cortex-m4、cortex-m7、risc-v芯片架構(gòu)，是純粹的RTOS系統(tǒng)，通過KAL與上層服務(wù)匹配。

1.2 LiteOS-A

LiteOS-A是HW基于LiteOS進行演進的，進行 多進程，多核，虛擬內(nèi)存，IPC等重新封裝，盡量類似于Linux，但是盡量簡化內(nèi)核實現(xiàn)。OpenHarmony LiteOS-A內(nèi)核架構(gòu)圖：

LiteOS-A是HW基于LiteOS進行演進的，進行 多進程，多核，虛擬內(nèi)存，IPC等重新封裝，盡量類似于Linux，但是盡量簡化內(nèi)核實現(xiàn)。

LiteOS-A相對于純粹的RTOS增強關(guān)鍵特性簡介：多進程： 基于task進行封裝，較為簡單的進程與線程調(diào)度（支持時間片和FIFO調(diào)度）；

多核： 全局鏈表、所有CPU共享，支持空閑輪詢調(diào)度（不支持負載均衡），可支持親和設(shè)置，可綁定核運行。

虛擬內(nèi)存：內(nèi)核靜態(tài)映射，靜態(tài)映射提升虛實轉(zhuǎn)換效率，最有區(qū)間分布（０－１G用戶空間，１－４G內(nèi)核空間，減少用戶態(tài)進程頁表項），用戶態(tài)通過缺頁異常按需獲取內(nèi)存。動態(tài)鏈接： 按需加載，多應(yīng)用共享代碼段，加載最小單元為頁，符號綁定，支持立即和延時綁定，加載地址隨機化，進程代碼段，數(shù)據(jù)段，堆棧段地址隨機化。并且運行標準ELF文件。

進程通信（IPC）： 支持標準的posix進程間通信，如Mqueue,pipe,fifo.signal。同時添加了Lite IPC（類似與Android binder但是簡單得多），ROM和RAM占用不超過30K，達到輕量，基于白名單控制的服務(wù)訪問權(quán)限，提升安全，通過內(nèi)存映射實現(xiàn)單次拷貝，實現(xiàn)高效。

系統(tǒng)調(diào)用： 通過MUSL實現(xiàn)系統(tǒng)調(diào)用支持syscall API和VDSO API。VDSO是減少系統(tǒng)調(diào)用開銷的方式，Linux也支持。保證服務(wù)與內(nèi)核分離。并且服務(wù)和應(yīng)用不能隨意訪問內(nèi)核。

權(quán)限管理： 進程粒度的權(quán)限劃分與管理，完成DAC訪問控制，以進程UID的配置，靈活劃分文件資源歸屬與管控，提供UGO（user,group,other）的權(quán)限分配，滿足基本的文件共享需求和Posix規(guī)范。

虛擬文件系統(tǒng)： VFS管理根目錄，掛載點內(nèi)目錄有FS管理。通過BCache和PCache提升文件系統(tǒng)讀寫速度。

POSIX標準庫： 基于Musl C的posix標準庫，當前支持1000+的標準Posix接口。用戶態(tài)使用全量Musl，C++使用libC++，內(nèi)核使用部分Musl。

以上特性都基本上基于Linux的簡化版本，保持內(nèi)核小型化，并且盡量擁有Linux的功能特性。

1.3 Linux

鴻蒙OS Linux內(nèi)核基于Linux 4.19版本內(nèi)核，添加如下功能。

• CVE補丁

補丁所涉及的CVE(Common Vulnerabilities and Exposures)安全漏洞是通過NVD (https://nvd.nist.gov/)官方機構(gòu)收集，且補丁已經(jīng)進入LTS 4.19.y分支或主線，主要涉及存儲(btrfs/scsi/)、網(wǎng)絡(luò)(net/bpf/mwifiex) 、驅(qū)動(xen/nfc)，對應(yīng)CVE列表參考commit信息中CVE字段信息。

• OpenHarmony特性

HDF驅(qū)動、binder ipc轉(zhuǎn)發(fā)功能等特性支持。

• 特定芯片架構(gòu)驅(qū)動補丁（比如Hi3516DV300）

vendor廠商提供的特定芯片架構(gòu)驅(qū)動代碼：

hisi_linux-4.19_hos_l2.patch: 在Hi3516DV300芯片上支持arm架構(gòu)的內(nèi)核啟動（DTS等）及對應(yīng)的drm/mmc等驅(qū)動的支持。

2、子系統(tǒng)

openharmony LiteOS-A包含如下子系統(tǒng)：

• 系統(tǒng)基本能力子系統(tǒng)集：為分布式應(yīng)用在多設(shè)備上的運行、調(diào)度、遷移等操作提供了基礎(chǔ)能力，由分布式軟總線、分布式數(shù)據(jù)管理、分布式任務(wù)調(diào)度、公共基礎(chǔ)庫、多模輸入、圖形、安全、AI等子系統(tǒng)組成。

• 基礎(chǔ)軟件服務(wù)子系統(tǒng)集：提供公共的、通用的軟件服務(wù)，由事件通知、電話、多媒體、DFX（Design For X） 等子系統(tǒng)組成。

• 增強軟件服務(wù)子系統(tǒng)集：提供針對不同設(shè)備的、差異化的能力增強型軟件服務(wù)，由智慧屏專有業(yè)務(wù)、穿戴專有業(yè)務(wù)、IoT專有業(yè)務(wù)等子系統(tǒng)組成。

• 硬件服務(wù)子系統(tǒng)集：提供硬件服務(wù)，由位置服務(wù)、生物特征識別、穿戴專有硬件服務(wù)、IoT專有硬件服務(wù)等子系統(tǒng)組成。

根據(jù)不同設(shè)備形態(tài)的部署環(huán)境，基礎(chǔ)軟件服務(wù)子系統(tǒng)集、增強軟件服務(wù)子系統(tǒng)集、硬件服務(wù)子系統(tǒng)集內(nèi)部可以按子系統(tǒng)粒度裁剪，每個子系統(tǒng)內(nèi)部又可以按功能粒度裁剪。

3、多內(nèi)核支持

如上圖所示，對于鴻蒙OS，其可以支持各種內(nèi)核（目前支持Liteos-m,LiteOS-a,Linux）。其通過KAL層對上層提供統(tǒng)一的API接口能力。

我們可以清楚的看到KAL 支持統(tǒng)一是通過支持POSIX和CMSIS（針對arm Cotex-m 的抽象，做到在RTOS層面的盡量統(tǒng)一）對底層內(nèi)核進行統(tǒng)一封裝。做到基于上層API的程序可以在相應(yīng)的CPU下編譯通用，強調(diào)只能編譯通用。

其中兼容POSIX的庫是Musl-libc。該庫是一個輕量級的C標準庫，設(shè)計作為GNU C library (glibc)、 uClibc或Android Bionic的替代用于嵌入式操作系統(tǒng)和移動設(shè)備。它遵循POSIX 2008規(guī)格和 C99 標準，采用MIT許可證授權(quán)，使用Musl的Linux發(fā)行版和項目包括sabotage，bootstrap-linux，LightCube OS等等，然后通過HDF來統(tǒng)一驅(qū)動模塊的編寫調(diào)試過程。以此來兼容驅(qū)動設(shè)備。

POSIX表示可移植操作系統(tǒng)接口（Portable Operating System Interface of UNIX，縮寫為 POSIX ），POSIX標準定義了操作系統(tǒng)應(yīng)該為應(yīng)用程序提供的接口標準。POSIX標準意在期望獲得源代碼級別的軟件可移植性。換句話說，為一個POSIX兼容的操作系統(tǒng)編寫的程序，應(yīng)該可以在任何其它的POSIX操作系統(tǒng)（即使是來自另一個廠商）上編譯執(zhí)行。

CMSIS（Cortex Microcontroller Software Interface Standard）標準，它是ARM同各個微控制器供應(yīng)商、工具供應(yīng)商和軟件解決方案一起開發(fā)的Cortex微控制器軟件接口標準。它使得微控制器和軟件供應(yīng)商可以使用一致的軟件結(jié)構(gòu)來開發(fā)Cortex微控制器的軟件。

CMSIS-RTOS是CMSIS的一部分，它本身是一種API規(guī)范，各廠商可以基于CMSIS-RTOS構(gòu)建自己的實時操作系統(tǒng)（RTOS）。由于基于CMSIS-RTOS的API是標準化的，所以基于這些API開發(fā)的應(yīng)用軟件，不需要進行額外的移植開發(fā)工作，就可跑在任何支持CMSIS-RTOS的OS上。隨著基于CMSIS-RTOS的中間件越來越多，支持CMSIS-RTOS后的OS也會因此獲得更多的中間件。

4、HDF驅(qū)動架構(gòu)

OpenHarmony驅(qū)動主要部署在內(nèi)核態(tài)，當前主要采用靜態(tài)鏈接方式，隨內(nèi)核子系統(tǒng)編譯和系統(tǒng)鏡像打包。

驅(qū)動框架交互流程

如上圖所示，發(fā)布設(shè)備服務(wù)，即在VFS創(chuàng)建固定的目錄或者設(shè)備節(jié)點，并且通過HDI進行抽象。

下列是相關(guān)系統(tǒng)的適配層，讓相應(yīng)的內(nèi)核支持HDF能力。然后驅(qū)動開發(fā)工程師通過　drivers_framework　提供的相關(guān)框架能力，編寫HDF支持的各種驅(qū)動，所以HDF統(tǒng)一驅(qū)動，是建立在對各種內(nèi)核集成的HDF　內(nèi)核支持驅(qū)動作為轉(zhuǎn)換層。所以如果有新的內(nèi)核需要適配，那么khdf需要根據(jù)相應(yīng)的內(nèi)核，進行移植，具有較大工作量。

相關(guān)源碼目錄是：

下圖是HDF-Framework層。用于支持HDF統(tǒng)一驅(qū)動的開發(fā)，加載生效或者卸載。

通過代碼中的uhdf/uhdf2可以看到，鴻蒙OS也在嘗試將部分驅(qū)動放入用戶空間，也就是向微內(nèi)核（或者混合內(nèi)核）方向演進。但如果是使用Linux內(nèi)核，通常也可以使用標準的Linux內(nèi)核驅(qū)動模型編寫驅(qū)動。只是不方便移植到其他的鴻蒙非Linux內(nèi)核的設(shè)備。不過不同的設(shè)備，其CPU與外設(shè)可能并不相同，分別編寫也可能。

四、軟總線分析

鴻蒙提供的標準軟件總線框架圖：

主要代碼目錄如下圖，lite和standard有一定差異。針對lite設(shè)備，只有發(fā)現(xiàn)，認證傳輸。

針對標準系統(tǒng)，則添加了組網(wǎng)，并且以client(SDK目錄)+Server(core目錄)的方式設(shè)計。

現(xiàn)在開源出來的openharmony方案總體約束為在同一局域網(wǎng)下進行軟總線互通。目前開源出來的還是TCP/IP協(xié)議建立的局域網(wǎng)。鴻蒙發(fā)布會描述的極簡協(xié)議統(tǒng)一層，我們并沒有看到。

軟總線的時序圖如下，Module可以看成分布式調(diào)度服務(wù)等，即其他使用軟總線的模塊。

對于pubulicService 對服務(wù)進行發(fā)布，實際同時對 軟總線進行初始化。（前提是WiFi已經(jīng)接入了WiFi的局域網(wǎng)）

傳輸在上面的publicService過程中創(chuàng)建的會話服務(wù) CreateSessionServer（）就是后續(xù)進行基于session會話服務(wù)的基礎(chǔ)。調(diào)用者并不需要關(guān)心IP等，只需要使用創(chuàng)建的sessionID 進行通信即可。

• g_sessionMgr->serverListenerMap[i] 用于存儲session。SessionListenerMap結(jié)構(gòu)中，最重要的是listener成員：onSessionOpened，是在會話創(chuàng)建時被回調(diào)的函數(shù)。

• onSessionClosed：是在會話結(jié)束時被回調(diào)的函數(shù)。

• onBytesReceived：是會話的數(shù)據(jù)到達的回調(diào)函數(shù)，注冊的模塊可以通過這個函數(shù)接收會話的報文，按照自己的格式進行解析，并執(zhí)行會話要求的動作。例如：在分布式調(diào)度模塊中，接收的數(shù)據(jù)解析后，可能是START_FA的命令。

相關(guān)的代碼：

在StartBus()函數(shù)會調(diào)用StartSession()函數(shù)創(chuàng)建基于TCP的socket的會話管理服務(wù)。

循環(huán)監(jiān)聽服務(wù)來連接，數(shù)據(jù)傳輸。

簡單總結(jié)，就是軟總線的傳輸，是基于COAP發(fā)布服務(wù)，等待超級終端通過softbus的session進行傳輸。當client要訪問某個設(shè)備（可以是遠程，可以是本地）的服務(wù)，首行連接遠程服務(wù)的session服務(wù)器，并發(fā)送數(shù)據(jù)。遠程的session服務(wù)通過onBytesRecived接收到數(shù)據(jù)，并回調(diào)給module。而是用module的目的。發(fā)送數(shù)據(jù)調(diào)用SendBytes，就可以基于sessionID發(fā)送。

這個過程中，module也好，還是遠程client的應(yīng)用也好，都不需要知道服務(wù)在哪個地方，有軟件總線進行處理即可，目前服務(wù)的發(fā)布只支持WiFi下的COAP。

在代碼中可以看到，未來支持的軟總線設(shè)備有BLE，COAP，USB三種類型。

我們推測軟件總線之下應(yīng)該還有一個針對復(fù)雜設(shè)備支持多層連接的適配層，以便屏蔽底層差異（當前只開源了WiFi和BT），包括支持上述設(shè)備的組網(wǎng)，路由以便構(gòu)建一張局域網(wǎng)。根據(jù)當前的開源代碼來看，主要還是基于wifi的局域網(wǎng)連接，其他形式自組網(wǎng)還未看到，但華為在通信這塊有很深的功底，我們這里相信這個目標可以達成。

基于目前公開的信息，軟總線架構(gòu)推測如下圖：

其中底層連接協(xié)議包括以太網(wǎng)、紅外線、4G/5G/WiFi、BT、NFC等各種通信能力。目前NFC主要用于華為Card的認證，協(xié)助多設(shè)備之間的認證。

五、應(yīng)用層分析

我們分別編寫了鴻蒙的JS及Java應(yīng)用，結(jié)合開放出來的部分源碼及文檔，對App安裝包進行了簡單的逆向分析。

1、開發(fā)環(huán)境

官方IDE DevEco Studio是基于開源的intellij的改造，能夠用于本地調(diào)試的模擬器只支持JS應(yīng)用。Java應(yīng)用截止目前只支持遠程模擬器（所謂分布式模擬器）不支持本地模擬器。運行遠程模擬器都需要賬號密碼登錄，賬號密碼需要注冊華為ID并實名認證，而實名認證需要上傳身份證照片或者銀行卡資料，遠程調(diào)試由于網(wǎng)絡(luò)和資源分配原因并不流暢，流暢度和畫質(zhì)方面不盡人意，開發(fā)體驗有點兒糟糕。

當然如果有真機，也可以使用真機進行開發(fā)調(diào)試，但華為這里又設(shè)了兩道門檻，開發(fā)鴻蒙應(yīng)用需要雙重簽名認證，除了應(yīng)用本身的簽名，還要對應(yīng)用工程進行簽名。這兩個簽名都需要在鴻蒙開發(fā)者網(wǎng)站上注冊，生成相應(yīng)證書后方可安裝到真機，步驟相當繁瑣。筆者搞這個簽名走各種注冊流程前后耗時一小時，對開發(fā)者不是很友好，好在配置完成后，后續(xù)可以直接使用，算是一次性勞動。

從目前的應(yīng)用開發(fā)流程上看，以后開發(fā)鴻蒙應(yīng)用有可能會對簽名服務(wù)進行收費，筆者不禁回想起了諾基亞，摩托羅拉時代，J2ME應(yīng)用證書簽名外包給第三方公司，一個應(yīng)用簽名收費2000元否則無法安裝到用戶手機，搞死生態(tài)的事情。生態(tài)還沒起來，應(yīng)用開發(fā)流程搞的如此復(fù)雜，希望華為借鑒這個歷史教訓(xùn)。

2、應(yīng)用框架

鴻蒙應(yīng)用UI框架有兩套，支持Java、JS，IDE里有默認的模板。這兩套框架的區(qū)別是，Java框架只支持鴻蒙Android系統(tǒng)，JS應(yīng)用既支持鴻蒙Android系統(tǒng)，也支持鴻蒙嵌入式系統(tǒng)。鴻蒙JS應(yīng)用在鴻蒙Android上是套了個Android應(yīng)用的殼，這個殼會構(gòu)建一個類似小程序的渲染環(huán)境，轉(zhuǎn)換為Android的原生控件渲染，下文有展開分析。JS應(yīng)用相比Java應(yīng)用，在排版能力，擴展性，兼容性方面存在一定的局限性，更適合做信息展示類的應(yīng)用。

對應(yīng)的也有，Java和JS兩套SDK，鴻蒙系統(tǒng)提供的名為Ability的應(yīng)用框架也分別有Java和JS的實現(xiàn)。應(yīng)用支持哪些設(shè)備，可以在應(yīng)用的config.json中聲明。

3、應(yīng)用格式

無論是js應(yīng)用還是java應(yīng)用，代碼最終編譯出來包均為hap后綴，這個hap是未經(jīng)hack的zip格式，可以使用標準的zip解壓工具進行解壓。

具體hap包的具體安裝使用上，SDK提供命令行工具 hdc：

hdc?shell?am?force-stop?com.example.myapplication hdc?shell?bm?uninstall?com.example.myapplication hdc?file?send?~/DevEcoStudioProjects/MyApplication/entry/build/outputs/hap/debug/entry-debug-unsigned.hap?/sdcard/entry-debug-unsigned.hap hdc?shell?bm?install?-p?/sdcard/ hdc?shell?rm?-rf?/sdcard/xxx hdc?shell?am?start?-n?"com.example.myapplication/com.example.myapplication.MainAbilityShellActivity"?-D hdc?app?install?xxx.hap

3.1、Java應(yīng)用

java應(yīng)用在開發(fā)時依賴以下SDK包，只能用來編譯代碼，SDK反編譯看不到源碼，也未開源。

根據(jù)文件命名，對其功能推測如下：

Java應(yīng)用解壓后的產(chǎn)物如下：

這些文件的作用如下：

Java應(yīng)用起來后用MainAbilityShellActivity承載，根據(jù)反編譯后的殼代碼分析，主要由HarmonyApplication完成對ability應(yīng)用運行環(huán)境的初始化。

Java應(yīng)用布局文件及顯示效果如下圖：

dump出UI的繪制方式(adb shell uiautomator dump)，可以看到鴻蒙雖然定義了一套應(yīng)用開發(fā)的DSL，但繪制部分還是用Android的UI控件來承載，非自繪UI。

<?xml?version='1.0'?encoding='UTF-8'?standalone='yes'??> <hierarchy?rotation="0"><node?index="0"?text=""?resource-id=""?class="android.widget.FrameLayout"?package="com.michalliu.myapplication"?content-desc=""?checkable="false"?checked="false"?clickable="false"?enabled="true"?focusable="false"?focused="false"?scrollable="false"?long-clickable="false"?password="false"?selected="false"?bounds="[0,0][1176,2328]"><node?index="0"?text=""?resource-id="android:id/decor_content_parent"?class="android.view.ViewGroup"?package="com.michalliu.myapplication"?content-desc=""?checkable="false"?checked="false"?clickable="false"?enabled="true"?focusable="false"?focused="false"?scrollable="false"?long-clickable="false"?password="false"?selected="false"?bounds="[0,0][1176,2328]"><node?index="0"?text=""?resource-id="android:id/action_bar_container"?class="android.widget.FrameLayout"?package="com.michalliu.myapplication"?content-desc=""?checkable="false"?checked="false"?clickable="false"?enabled="true"?focusable="false"?focused="false"?scrollable="false"?long-clickable="false"?password="false"?selected="false"?bounds="[0,72][1176,240]"><node?index="0"?text=""?resource-id="android:id/action_bar"?class="android.view.ViewGroup"?package="com.michalliu.myapplication"?content-desc=""?checkable="false"?checked="false"?clickable="false"?enabled="true"?focusable="false"?focused="false"?scrollable="false"?long-clickable="false"?password="false"?selected="false"?bounds="[0,72][1176,240]"><node?index="0"?text="entry_MainAbility"?resource-id=""?class="android.widget.TextView"?package="com.michalliu.myapplication"?content-desc=""?checkable="false"?checked="false"?clickable="false"?enabled="true"?focusable="false"?focused="false"?scrollable="false"?long-clickable="false"?password="false"?selected="false"?bounds="[48,115][528,196]"?/></node></node><node?index="1"?text=""?resource-id="android:id/content"?class="android.widget.FrameLayout"?package="com.michalliu.myapplication"?content-desc=""?checkable="false"?checked="false"?clickable="false"?enabled="true"?focusable="false"?focused="false"?scrollable="false"?long-clickable="false"?password="false"?selected="false"?bounds="[0,240][1176,2328]"><node?index="0"?text=""?resource-id=""?class="android.view.ViewGroup"?package="com.michalliu.myapplication"?content-desc=""?checkable="false"?checked="false"?clickable="false"?enabled="true"?focusable="false"?focused="false"?scrollable="false"?long-clickable="false"?password="false"?selected="false"?bounds="[0,240][1176,2328]"><node?index="0"?text="你好，世界"?resource-id=""?class="android.widget.TextView"?package="com.michalliu.myapplication"?content-desc=""?checkable="false"?checked="false"?clickable="false"?enabled="true"?focusable="false"?focused="false"?scrollable="false"?long-clickable="false"?password="false"?selected="false"?bounds="[288,1160][888,1320]"?/><node?index="1"?text="javaApp"?resource-id=""?class="android.widget.TextView"?package="com.michalliu.myapplication"?content-desc=""?checkable="false"?checked="false"?clickable="false"?enabled="true"?focusable="false"?focused="false"?scrollable="false"?long-clickable="false"?password="false"?selected="false"?bounds="[366,1320][809,1480]"?/></node></node></node><node?index="1"?text=""?resource-id="android:id/statusBarBackground"?class="android.view.View"?package="com.michalliu.myapplication"?content-desc=""?checkable="false"?checked="false"?clickable="false"?enabled="true"?focusable="false"?focused="false"?scrollable="false"?long-clickable="false"?password="false"?selected="false"?bounds="[0,0][1176,72]"?/></node> </hierarchy>

由此可以看出，鴻蒙Android版要脫離Android體系難度還比較高，畢竟核心的UI部分非自繪。

Java應(yīng)用的運行環(huán)境示意圖：

我們理解鴻蒙Android從設(shè)計上更類似QT跟Windows的關(guān)系，可以理解為在Android操作系統(tǒng)的基礎(chǔ)上搭了一套自己的應(yīng)用程序框架。

目前鴻蒙是跟Android深度綁定的，鴻蒙切換操作系統(tǒng)的可能性不是完全沒有，但成本相當高，應(yīng)該說鴻蒙Android的這個設(shè)計思路是既然擺脫不了安卓，基于這個前提，那么就充分利用它。

3.2、Js應(yīng)用

從目前已經(jīng)開源出來的部分上來看基于js開發(fā)的應(yīng)用是一種類似小程序的開發(fā)方式，html,js,css首先會編譯成jsbundle（編譯工具本身未開源），jsbundle的執(zhí)行不同的鴻蒙系統(tǒng)上有所區(qū)別。

• Js應(yīng)用在鴻蒙嵌入式系統(tǒng)上執(zhí)行分析

經(jīng)過對openharmony代碼分析，在openharmony里Js應(yīng)用是以自繪的方式渲染，支持的UI組件看起來還比較完善（從源碼里看繪制部分似乎參考了部分flutter代碼），使用三星的Jerry Js引擎，猜測是挖的三星的人？因為這個Js引擎實在太小眾，Google V8他不香嗎？

UI組件框架在 ace_engine_lite 里，從開源的代碼我們看出支持的UI組件還比較豐富，除了常規(guī)的控件，還包含列表，動畫等復(fù)雜控件的實現(xiàn)。

ace_engine_lite 負責(zé)維護UI組件的生命周期，事件通信，數(shù)據(jù)更新等，是邏輯層

UI組件的顯示層在 graphic_ui 工程中，例如下圖為UIButton繪制的實現(xiàn)：

目前這個自繪的工程只有嵌入式的的實現(xiàn)，沒有Android對應(yīng)的實現(xiàn)。

實際在Android工程上，鴻蒙走的并不是自繪的方案，而是類似ReactNative的控件轉(zhuǎn)換，ReactNative采用的是React的語法，而鴻蒙Android采用的是Vue的語法，從國內(nèi)的開發(fā)者生態(tài)上來看，這是個正確的選擇。

鴻蒙的這個用C++實現(xiàn)類VUE語法，在嵌入式上自繪，Android上控件轉(zhuǎn)換的Js跨平臺渲染框架屬于原創(chuàng)，可惜的是鴻蒙Android這塊并未開源，不能深入研究。

• Js應(yīng)用在鴻蒙Android上執(zhí)行分析

Js應(yīng)用在鴻蒙Android上會轉(zhuǎn)換成Android的UI控件，Js應(yīng)用解壓后的產(chǎn)物如下：

這些文件的作用如下：

對于Js應(yīng)用來說核心邏輯由ohos.aafwk.ace.ability.AceAbility完成jsbundle的加載和運行工作。

（注意：雖然java應(yīng)用和js應(yīng)用在解壓后目錄結(jié)構(gòu)似乎差不多，文件命名也差不多，但其工作原理完全不同。在Java應(yīng)用里class.dex已經(jīng)是鴻蒙應(yīng)用的真正可執(zhí)行代碼。在js應(yīng)用里class.dex還是一個殼，這個殼用于打造執(zhí)行Js應(yīng)用的運行環(huán)境，真正的業(yè)務(wù)邏輯在app.js里。)

js應(yīng)用布局文件及顯示效果:

dump出UI的繪制方式，可以看到Js應(yīng)用的UI繪制，在鴻蒙Android上是用Android的UI控件來承載，非自繪UI。

<?xml?version='1.0'?encoding='UTF-8'?standalone='yes'??> <hierarchy?rotation="0"><node?index="0"?text=""?resource-id=""?class="android.widget.FrameLayout"?package="com.example.myapplicationjs"?content-desc=""?checkable="false"?checked="false"?clickable="false"?enabled="true"?focusable="false"?focused="false"?scrollable="false"?long-clickable="false"?password="false"?selected="false"?bounds="[0,0][1176,2328]"><node?index="0"?text=""?resource-id="android:id/decor_content_parent"?class="android.view.ViewGroup"?package="com.example.myapplicationjs"?content-desc=""?checkable="false"?checked="false"?clickable="false"?enabled="true"?focusable="false"?focused="false"?scrollable="false"?long-clickable="false"?password="false"?selected="false"?bounds="[0,0][1176,2328]"><node?index="0"?text=""?resource-id="android:id/action_bar_container"?class="android.widget.FrameLayout"?package="com.example.myapplicationjs"?content-desc=""?checkable="false"?checked="false"?clickable="false"?enabled="true"?focusable="false"?focused="false"?scrollable="false"?long-clickable="false"?password="false"?selected="false"?bounds="[0,72][1176,240]"><node?index="0"?text=""?resource-id="android:id/action_bar"?class="android.view.ViewGroup"?package="com.example.myapplicationjs"?content-desc=""?checkable="false"?checked="false"?clickable="false"?enabled="true"?focusable="false"?focused="false"?scrollable="false"?long-clickable="false"?password="false"?selected="false"?bounds="[0,72][1176,240]"><node?index="0"?text="entry_MainAbility"?resource-id=""?class="android.widget.TextView"?package="com.example.myapplicationjs"?content-desc=""?checkable="false"?checked="false"?clickable="false"?enabled="true"?focusable="false"?focused="false"?scrollable="false"?long-clickable="false"?password="false"?selected="false"?bounds="[48,115][528,196]"?/></node></node><node?index="1"?text=""?resource-id="android:id/content"?class="android.widget.FrameLayout"?package="com.example.myapplicationjs"?content-desc=""?checkable="false"?checked="false"?clickable="false"?enabled="true"?focusable="false"?focused="false"?scrollable="false"?long-clickable="false"?password="false"?selected="false"?bounds="[0,240][1176,2328]"><node?index="0"?text=""?resource-id=""?class="android.view.ViewGroup"?package="com.example.myapplicationjs"?content-desc=""?checkable="false"?checked="false"?clickable="true"?enabled="true"?focusable="true"?focused="false"?scrollable="true"?long-clickable="true"?password="false"?selected="false"?bounds="[0,240][1176,2328]"><node?index="0"?text="您好?世界"?resource-id=""?class="android.widget.TextView"?package="com.example.myapplicationjs"?content-desc=""?checkable="false"?checked="false"?clickable="true"?enabled="true"?focusable="true"?focused="false"?scrollable="true"?long-clickable="true"?password="false"?selected="false"?bounds="[331,1173][844,1332]"?/><node?index="1"?text="Js?Application"?resource-id=""?class="android.widget.TextView"?package="com.example.myapplicationjs"?content-desc=""?checkable="false"?checked="false"?clickable="true"?enabled="true"?focusable="true"?focused="false"?scrollable="true"?long-clickable="true"?password="false"?selected="false"?bounds="[301,1347][874,1452]"?/></node></node></node></node> </hierarchy>

鴻蒙應(yīng)用層在設(shè)計上，基于自己的DSL和應(yīng)用運行框架，在嵌入式設(shè)備上以自繪的方式渲染，在鴻蒙Android上通過適配層轉(zhuǎn)換為Android原生控件渲染。這樣的設(shè)計優(yōu)勢是減輕了工作量，組件方面可以復(fù)用Android的生態(tài)，能力會更豐富，畢竟從零再打造一套完整且龐大的UI體系成本太高，體驗還不一定有Android做的好，而劣勢則是犧牲了可維護性，兩套方案要各自獨立維護，維護成本較高，另外還可能帶來兼容性的問題。從openharmony源碼上看，基于自繪方案并沒有預(yù)留給Android的擴展接口，targetos僅包含linux和liteos兩種，因為渲染層架構(gòu)不同，未來的改成一致的可能性也較低。

六、總結(jié)

鴻蒙OS并不定位于對Windows、Android進行替代，而是劍指萬物互聯(lián)時代全場景、多終端的操作系統(tǒng)，與此相對應(yīng)，鴻蒙OS（及大華為體系）所有的生態(tài)布局也將圍繞萬物互聯(lián)展開。鴻蒙OS在完成細分場景的拓展與跑馬圈地后，鴻蒙OS將完善華為AIoT生態(tài)，進一步在智慧城市、車聯(lián)網(wǎng)（深化）、工業(yè)互聯(lián)網(wǎng)三方面發(fā)力推進。

中長期來看，鴻蒙OS與華為“云+端”芯片形成強大合力，進軍產(chǎn)業(yè)物聯(lián)網(wǎng)。華為優(yōu)質(zhì)網(wǎng)絡(luò)設(shè)備是IoT的連接基礎(chǔ)，連接獲得了大量數(shù)據(jù)，但只有通過智能分析才能夠形成殺手級應(yīng)用。華為已在云側(cè)和端測擁有昇騰、鯤鵬、麒麟等芯片，具備強大算力，疊加鴻蒙OS高效、靈活的執(zhí)行力，將培育大量高價值應(yīng)用。基于近景和遠景的生態(tài)藍圖，當前鴻蒙OS的發(fā)力抓手仍是以移動端為核心的HMS產(chǎn)業(yè)鏈。

招人了：

微信支付正在熱招終端，前端，后臺等各類人才，歡迎應(yīng)聘。

微信刷臉支付Android客戶端開發(fā)（深圳）

點我：https://careers.tencent.com/jobdesc.html?postId=1364129004637921280

微信支付技術(shù)生態(tài)研發(fā)工程師（深圳）

點我：https://careers.tencent.com/jobdesc.html?postId=1381798500261437440

微信支付分行業(yè)應(yīng)用后臺開發(fā)工程師（深圳）

點我：https://careers.tencent.com/zh-cn/jobdesc.html?postId=1369832064592912384

微信支付行業(yè)C++后臺開發(fā)工程師（深圳）

點我：https://careers.tencent.com/zh-cn/jobdesc.html?postId=1381790476046180352

微信支付行業(yè)應(yīng)用開發(fā)工程師（深圳）

點我：https://careers.tencent.com/jobdesc.html?postId=1366934439149445120

微信支付行業(yè)大數(shù)據(jù)應(yīng)用運營開發(fā)（深圳）

點我：https://careers.tencent.com/zh-cn/jobdesc.html?postId=1409708599134920704

微信支付，不止支付。

最近其他文章：

這篇Redis文章，圖靈看了都說好

四種代碼潔癖類型，程序員看了直呼內(nèi)行

一文深入理解 Kubernetes

想了解騰訊技術(shù)人的故事，歡迎關(guān)注：

總結(jié)

以上是生活随笔為你收集整理的不吹不擂，一文揭秘鸿蒙操作系统的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。