全面解析OpenHarmony 3.0 LTS

在 2021 年 9 月 30 號，OpenHarmony 迎來了重大更新，發(fā)布了 3.0長期支持版，這是今年發(fā)布的第二個長期支持版，也是首個真正意義上全量長期支持版本。

相較于 OpenHamrony 1.0 LTS 版本只支持小型和輕量系統(tǒng)，OpenHamrony 3.0 LTS 版本覆蓋了小型、輕量和標(biāo)準(zhǔn)系統(tǒng)，從 IoT 設(shè)備到手機(jī)的系統(tǒng)全支持。

本文將會詳細(xì)介紹我關(guān)注的 OpenHamrony 3.0 LTS 版本一些改變。

編譯環(huán)境配置有所簡化

在 OpenHarmony 3.0 系統(tǒng)中，搭建環(huán)境不再需要那么復(fù)雜的操作（環(huán)境最好為 20.04），大概需要 6 步即可以編譯出你想要的結(jié)果。

這里列出具體的步驟，方便熟悉舊版本的讀者做對比：

①安裝依賴

sudoapt-getupdate&&sudoapt-getinstallgnutls-bingcc-arm-linux-gnueabibuild-essentialfakerootdpkg-devgit-lfsbuild-essentialgccg++makezlib*zipxsltprocx11proto-core-devwgetvimunzipu-boot-toolstzdatatexinfosshsconspython3-minimalpython3-setuptoolspython3-pippython3-distutilspython3-aptpython3.8-distutilsnpmnfs-kernel-servermtoolsmtd-utilsm4localeslibxml2-utilslibx11-devlibreadline-devlibgl1-mesa-devlibffi*libc6-dev-x32libc6-dev-i386lib32z-devlib32ncurses5-devgperfgnupggit-lfsgit-coreg+±m(xù)ultilibg++flexdosfstoolsdefault-jredefault-jdkcurlccachebuild-essentialbisonbinutilsbcgenext2fsruby

②安裝工具：repo 和 hc-gen

sudocurl-shttps://gitee.com/oschina/repo/raw/fork_flow/repo-py3>/usr/local/bin/repo

默認(rèn)使用 root 權(quán)限安裝至 /usr/local/bin，也可以裝至其他路徑。

③配置 git 相關(guān)參數(shù)，（可能也需要你把 ssh 公鑰填到 gitee 設(shè)置中）。

gitconfig--globaluser.email"xxx@mail.com"

gitconfig--globaluser.name"xxx"

④創(chuàng)建代碼目錄并拉取代碼：

mkdirOpenHarmony

cdOpenHarmony

repoinit-uhttps://gitee.com/openharmony/manifest.git-bOpenHarmony-3.0-LTS--no-repo-verify

reposync-c

repoforall-c'gitlfspull'

⑤下載預(yù)編譯工具：

./build/prebuilts_download.sh

⑥運行編譯腳本（需自行調(diào)整參數(shù)）

編譯 Hi3516DV300 鏡像：

./build.sh--product-nameHi3516DV300–ccache

編譯 arm64 系統(tǒng)鏡像：

./build.sh–product-nameohos-arm64--ccache

編譯 SDK 庫：

./build.sh--product-nameohos-sdk–ccache

結(jié)果輸出：

out/ohos-arm64-release/ohos-sdk/windows

該目錄即是 DevEco Studio 中的 OpenHarmony SDK，其中也包含 hdc_std.exe，當(dāng)前環(huán)境不再提供 hdc 的預(yù)編譯文件了，需要自己編譯出對應(yīng)的版本，否則不能使用 HDC 安裝 HAP 和發(fā)送文件。

下載主線的版本有時會對應(yīng)不上，輸入命令無反應(yīng)，所以需要我們自己手動編譯。

新增了哪些功能

在每次發(fā)布后都會有一份詳細(xì)的文檔介紹新增的功能，例如這次的更新如下：當(dāng)前版本在 OpenHarmony 2.2 Beta2 的基礎(chǔ)上，針對標(biāo)準(zhǔn)系統(tǒng)、輕量系統(tǒng)和小型系統(tǒng)更新內(nèi)容。

標(biāo)準(zhǔn)系統(tǒng)新增特性功能：

• 用戶程序框架支持服務(wù)能力（ServiceAbility，DataAbility）和線程模型。

• 支持文件安全訪問，即文件轉(zhuǎn)成 URI 和解析 URI 打開文件的能力。

• 支持設(shè)備管理 PIN 碼認(rèn)證的基本能力。

• 支持關(guān)系型數(shù)據(jù)庫、分布式數(shù)據(jù)管理基礎(chǔ)能力。

• 支持方舟 JS 編譯工具鏈和運行時，支持 OpenHarmony JS UI 框架應(yīng)用開發(fā)和運行。

• 支持遠(yuǎn)程綁定 ServiceAbility、FA 跨設(shè)備遷移能力。

• 支持應(yīng)用通知訂閱與應(yīng)用通知消息跳轉(zhuǎn)能力。

• 支持輸入法框架及支持輸入基礎(chǔ)英文字母、符號和數(shù)字。

• 相機(jī)應(yīng)用支持預(yù)覽、拍照和錄像基礎(chǔ)能力。

• 支持 CS 基礎(chǔ)通話、GSM 短信能力。

• 支持定時器能力，提供定時時區(qū)管理能力。

• 在標(biāo)準(zhǔn)設(shè)備間的分布式組網(wǎng)下，提供應(yīng)用跨設(shè)備訪問對端資源或能力時的權(quán)限校驗功能。

輕量和小型系統(tǒng)新增特性功能：

• 新增輕量級分布式能力增強(qiáng)，支持從輕量級系統(tǒng)啟動標(biāo)準(zhǔn)系統(tǒng)上的 Ability。

• 軟總線能力增強(qiáng)支持，提供認(rèn)證通道傳輸能力，用于設(shè)備綁定。

• 輕量級全球化能力增強(qiáng)支持，新增 31 種語言支持。

• 輕量系統(tǒng)上新增權(quán)限屬性字段及其寫入接口，上層應(yīng)用可通過該字段實現(xiàn)相關(guān)業(yè)務(wù)。

詳細(xì)的介紹可以查看鏈接：

https://gitee.com/openharmony/docs/blob/master/zh-cn/release-notes/OpenHarmony-v3.0-LTS.md

挑幾條大家比較關(guān)注的點來講講

①用戶程序框架支持服務(wù)能力（ServiceAbility，DataAbility）和線程模型

如果你開發(fā)過 HaronyOS 應(yīng)用，你就會覺得很熟悉，HarmonyOS 是通過 Java 來實現(xiàn) ServiceAbility 和 DataAbility 的能力。

但是在 OpenHarmony 中，這部分的工作由 JS 語言來實現(xiàn)，JS 可以直接寫 ServiceAbility 和 DataAbility。

②用戶程序框架子系統(tǒng)能力得到了增強(qiáng)

大家可以通過調(diào)用系統(tǒng) API 來安裝、卸載 HAP 以及獲取指定用戶下所有已安裝的應(yīng)用信息，這為以后的應(yīng)用市場奠定了基礎(chǔ)。

當(dāng)然如果你能力夠的話，現(xiàn)在就可以嘗試實現(xiàn)一個應(yīng)用市場的應(yīng)用，大家都以后都從你這下載 HAP，這也是以后 OpenHarmony 的發(fā)行版著重關(guān)注的地方。

了解詳情請前往：

https://gitee.com/openharmony/appexecfwk_standard

③本次更新提供了方舟運行時以及 ts2abc

ts2abc（TypeScript to Ark ByteCode）組件是方舟運行時子系統(tǒng)的前端工具，支持將 JavaScript 文件轉(zhuǎn)換為方舟字節(jié)碼文件。

因為我不是這方面的專家，就不展開講了，Gitee 上提供了詳細(xì)的編譯步驟以及使用方法。

方舟運行時子系統(tǒng)介紹：

https://gitee.com/openharmony/docs/blob/master/zh-cn/readme/ARK-Runtime-Subsystem-zh.md

方舟運行時使用指南：

https://gitee.com/openharmony/ark_js_runtime/blob/master/docs/ARK-Runtime-Usage-Guide-zh.md

④還有大家最為關(guān)注的軟總線，這次軟總線進(jìn)行了多倉合一

以后無論輕量、小型和標(biāo)準(zhǔn)系統(tǒng)都使用同一份代碼，減少了大家的工作量，以后只要研究一份代碼即可。

而且軟總線的能力得到了增強(qiáng)，只要兩個設(shè)備接入同一個局域網(wǎng)中就會自動發(fā)現(xiàn)設(shè)備，可以體驗官方提供的兩個例子音樂和計算器。甚至可以自己使用 API 來寫一個簡單的應(yīng)用流轉(zhuǎn)。

了解詳情請前往：

https://gitee.com/openharmony/communication_dsoftbus

⑤OpenHarmony 通過 CES（Common Event Service，公共事件服務(wù)）為應(yīng)用程序提供訂閱、發(fā)布、退訂公共事件的能力

一般包括兩種公共事件，系統(tǒng)公共事件和自定義公共事件：

• 系統(tǒng)公共事件：系統(tǒng)將收集到的事件信息，根據(jù)系統(tǒng)策略發(fā)送給訂閱該事件的用戶程序。例如：系統(tǒng)關(guān)鍵服務(wù)發(fā)布的系統(tǒng)事件（例如：hap安裝，更新，卸載等）。

• 自定義公共事件：應(yīng)用自定義一些公共事件用來實現(xiàn)跨應(yīng)用的事件通信能力。每個應(yīng)用都可以按需訂閱公共事件，訂閱成功且公共事件發(fā)布，系統(tǒng)會把其發(fā)送給應(yīng)用。

這些公共事件可能來自系統(tǒng)、其他應(yīng)用和應(yīng)用自身。這個能力很重要，如果和云對接，可以接收到云端的推送，如天氣更新以及廣告推送等等。

⑥提供了輸入法的能力

現(xiàn)在的輸入法使用體驗需要優(yōu)化，輸入法的彈出以及輸入都需要屏幕閃爍一下才可以輸入進(jìn)去，尤其是在輸入 WiFi 密碼的時候，可能需要三分鐘才能輸完，假如輸錯了，那么還再需要三分鐘，還需努力。

⑦各種手機(jī)能力的補(bǔ)足

例如電話通信、短信、NFC、藍(lán)牙等，但是這些都在 Hi3516 上體驗不到，需要一款完備的旗艦開發(fā)板來體驗。

新加的JS的能力的倉

①基于 JS 的多線程能力：worker

通過 postMessage 完成 worker 線程與宿主線程的通信。具體的使用方法請參考：

https://gitee.com/openharmony/js_worker_module

②基于 JS 的線程創(chuàng)建能力：process

主要是獲取進(jìn)程的相關(guān) id 以及獲取和修改進(jìn)程的工作目錄，及進(jìn)程的退出關(guān)閉。

通過 childprocess 對象可以用來創(chuàng)建一個新的進(jìn)程，主進(jìn)程可以獲取子進(jìn)程的標(biāo)準(zhǔn)輸入輸出，以及發(fā)送信號和關(guān)閉子進(jìn)程。

具體的使用方法請參考：

https://gitee.com/openharmony/js_sys_module

③字符串編碼：UTIL

UTIL 接口用于字符編碼 TextEncoder、解碼 TextDecoder 和幫助函數(shù) HelpFunction。 TextEncoder 表示一個文本編碼器，接受字符串作為輸入，以 UTF-8 格式進(jìn)行編碼，輸出 UTF-8 字節(jié)流。

TextDecoder 接口表示一個文本解碼器，解碼器將字節(jié)流作為輸入，輸出 stirng 字符串。

HelpFunction 主要是對函數(shù)做 callback 化、promise 化以及對錯誤碼進(jìn)行編寫輸出，及類字符串的格式化輸出。

具體使用方法可以參考：

https://gitee.com/openharmony/js_util_module

④解析，構(gòu)造，規(guī)范化和編碼 URLs：URL 接口

URL 的構(gòu)造函數(shù)創(chuàng)建新的 URL 對象。以便對 URL 的已解析組成部分或?qū)?URL 進(jìn)行更改。

URLSearchParams 接口定義了一些實用的方法來處理 URL 的查詢字符串。URI 表示統(tǒng)一資源標(biāo)識符引用。xml 表示指可擴(kuò)展標(biāo)記語言。

具體使用方法可以參考：

https://gitee.com/openharmony/js_api_module

⑤新的界面編寫方式

在 DevEco Studio 3.0 beta 版中可以直接下載到 OpenHarmony 的 SDK，無需手動下載，創(chuàng)建項目的最后一個模板即是 OpenHarmony HAP 的模板。

新的范式和 API 暫時還沒有文檔介紹，估計是在 HDC 大會上亮相，但是官方已經(jīng)在 Gitee 上上傳了三個經(jīng)典的例子。

Launcher、SystemUI、Settings 這三個 APP 必定會被替換成發(fā)行版的樣式，和發(fā)行版息息相關(guān)。基于 OpenHarmony 的 EMUI、MIUI 也不會太遠(yuǎn)了。

基于某種原因不能給大家多做介紹，只把這三個鏈接發(fā)給大家，自行研究。而且每個倉庫都有詳細(xì)文檔和使用方法以及如何替換系統(tǒng)應(yīng)用。

啟動器詳情：

https://gitee.com/openharmony/applications_launcher

系統(tǒng)設(shè)置詳情：

https://gitee.com/openharmony/applications_settings

系統(tǒng)界面詳情：

https://gitee.com/openharmony/applications_systemui

OpenHarmony各個SIG興趣小組進(jìn)展

我并不敢說我完全了解所有的 SIG 小組，為避免片面，這里只說一下概況，如果有對相應(yīng)領(lǐng)域感興趣的小伙伴，可以直接去 Gitee 上各個項目組去看詳細(xì)信息。

①Kernel-SIG 小組

Kernel-SIG 小組的產(chǎn)出成果最好，可能大家關(guān)注度不高，并不清楚他們做了什么，但是做 OpenHarmony 移植工作的開發(fā)者們應(yīng)該已經(jīng)關(guān)注了該 SIG 的會議和進(jìn)展。為了減輕開發(fā)者的移植工作量，他們做了大量的工作，實現(xiàn)了只要使用廠家提供的 Linux 內(nèi)核加上對應(yīng)的內(nèi)核 patch 和 HDF patch，就可以跑起 OpenHarmony，這讓 Linux 內(nèi)核移植工作大幅下降。該 SIG 還提供了 HDF 測試樣例，用來檢測移植是否成功，這些 HDF 測試樣例已經(jīng)在樹莓派 3 的移植上經(jīng)過驗證，大家可以放心食用，當(dāng)然這只適合 OpenHarmony Linux 內(nèi)核的移植。

詳細(xì)的文檔地址為：

https://gitee.com/openharmony/docs/blob/master/zh-cn/device-dev/porting/porting-linux-kernel.md

②新的 Dev-Board-SIG 小組

新的 Dev-Board-SIG 小組合并了 Driver-SIG 小組，組織了大量的個人開發(fā)者、三方方案商、芯片原廠和 OpenHarmony 研發(fā)做 OpenHarmony 的移植工作。

Dev-Board-SIG 小組組織各開發(fā)板廠商撰寫開發(fā)板的開發(fā)計劃說明，梳理開發(fā)板的硬件接口說明、軟件建倉的梳理以及開發(fā)板項目管理策略。 在這些工作的基礎(chǔ)上，小組發(fā)布了富設(shè)備開發(fā)板的接口規(guī)范，并對各個開發(fā)板資料進(jìn)行了整理歸檔，規(guī)范展示窗口，解決了開發(fā)者基于自己的項目選擇合適開發(fā)板的問題。

Driver-SIG 小組還做了 HDF 的解耦工作，并且研發(fā)人員寫了多篇關(guān)于 HDF 驅(qū)動的移植和開發(fā)文章，目前已經(jīng)發(fā)表，大家可以關(guān)注。 了解詳情請前往：

https://gitee.com/openharmony-sig/devboard

③Python-SIG 小組

Python-SIG 是由唐佐林老師發(fā)起的，基于 Python 做開發(fā)，專為輕量設(shè)備打造?，F(xiàn)可以跑在 Hi3861 和 W800 兩種芯片上面，后續(xù)會增加更多的芯片。

大家如果不想學(xué)習(xí) C 語言嵌入式開發(fā)，則可以直接使用唐老師的 Python 固件來開發(fā)，現(xiàn)已支持多種驅(qū)動。唐老師可是 C/C++ 的大神，10 多年的嵌入式開發(fā)經(jīng)驗，可以和唐老師學(xué)習(xí)到很多。 了解詳情請前往：

https://gitee.com/openharmony-sig/python

④RISCV-SIG 小組

RISCV-SIG 小組主攻 OpenHarmony 適配 RISC-V 芯片，而且為此還做了 llvm 工具鏈的適配，現(xiàn)在支持的兩款芯片分別為全志 D1 和賽昉 7000，更多芯片支持正在規(guī)劃中。

RISC-V 開源指令集架構(gòu)我就不多說了，懂得都懂，也希望更多人加入進(jìn)來為 OpenHarmony 的生態(tài)做出貢獻(xiàn)。

了解詳情請前往：

https://gitee.com/openharmony-sig/riscv

⑤OpenBlock-SIG 小組

OpenBlock-SIG 為了擴(kuò)展 OpenHarmony OS 在青少年編程和 STEM 教育中的應(yīng)用范圍。

OpenBlock SIG 將移植基于 Blockly 的圖形化編程語言的運行時到 OpenHarmonyOS 上，并支持軟總線、分布式等 OpenHarmonyOS 能力。技術(shù)能力有限，但是想嘗鮮的讀者可以去嘗試一下 Blockly 的圖形化編程。

了解詳情請前往：

https://gitee.com/openharmony-sig/openblock

⑥EduDataSpecification-SIG 小組

EduDataSpecification-SIG 旨在構(gòu)建圍繞 OpenHarmony 軟硬件生態(tài)，與教育領(lǐng)域軟硬件伙伴共同解決教育數(shù)據(jù)采集場景中的高頻痛點，共同制定教育專屬操作系統(tǒng)與數(shù)據(jù)采集標(biāo)準(zhǔn)，助力教育行業(yè)自主創(chuàng)新，促進(jìn) OpenHarmony 教育信息化領(lǐng)域內(nèi)的南北向應(yīng)用生態(tài)快速發(fā)展。

主要以捐獻(xiàn)數(shù)據(jù)采集相關(guān)能力組件的方式形成教育信息數(shù)據(jù)采集事實標(biāo)準(zhǔn)。感興趣的可以查看他們的會議紀(jì)要和技術(shù)文檔，寫的非常詳細(xì)。

⑦Industrial_Internet-SIG 小組

Industrial_Internet-SIG 旨在圍繞 OpenHarmony 構(gòu)建工業(yè)專屬操作系統(tǒng)和軟硬件生態(tài)，助力制造業(yè)自主創(chuàng)新。

通過開源捐獻(xiàn)，促進(jìn) OpenHarmony 上的工業(yè)互聯(lián)網(wǎng)南北向應(yīng)用生態(tài)快速發(fā)展。感興趣的可以加入他們。

一個開發(fā)者面臨的困境和思考

OpenHarmony 這半年來的發(fā)展比較迅速，一線開發(fā)者的組織架構(gòu)、管理和機(jī)制逐漸完善，也有越來越多的共建企業(yè)和野生開發(fā)者加入。但作為一個開發(fā)者，我還是有些想吐槽的。

OpenHarmony 的快速發(fā)展，也帶來一部分問題，例如 Hi3516 的芯片越來越不能滿足應(yīng)用開發(fā)者的需求，因為該芯片只是用來做 IPCamera 的芯片，不適合做手機(jī)、平板和大屏設(shè)備。

想要做進(jìn)一步的開發(fā)適配就需要更高性能的芯片加入，但是目前還沒有一款開發(fā)板能夠提供完整流暢的開發(fā)體驗。

OpenHarmony 3.0 LTS 版本發(fā)布的這個時間節(jié)點，需要有幾款性能強(qiáng)悍的旗艦開發(fā)板，擁有 3.0 LTS 版本的全功能體驗，手機(jī)電話、NFC、藍(lán)牙和 GPU 等能力，這樣大量的應(yīng)用開發(fā)者才會開發(fā)出 OpenHamrony 的應(yīng)用。

目前，應(yīng)用開發(fā)者開發(fā)的應(yīng)用在 Hi3516 這種對 3.0 LTS 版本功能支持不全的開發(fā)板上運行，手指戳爛了屏幕都沒有響應(yīng)，體驗很差，這會造成很多應(yīng)用開發(fā)者流失。

同樣的代碼在手機(jī)流暢的運行，在 Hi3516 開發(fā)板上就卡成 PPT，隱形之中 OpenHarmony 就失去了大量的應(yīng)用，也會打擊開發(fā)者們的熱情，形成口碑效應(yīng)后，自然就沒有新的應(yīng)用開發(fā)者加入，那么 OpenHarmony 的生態(tài)如何發(fā)展？

這是個擺在了 OpenHarmony 面前急需解決的問題。

我認(rèn)為明年是關(guān)鍵的一年，明年的關(guān)鍵點在于生態(tài)，而不是 OpenHarmony 系統(tǒng)的研發(fā)。

當(dāng)基礎(chǔ)功能具備的時候，如果沒有大量的應(yīng)用開發(fā)者加入，沒有大量的應(yīng)用供用戶選擇和使用，那么生態(tài)起不來，生態(tài)起不來，在生態(tài)中的企業(yè)和個人都不能實現(xiàn)自身價值。雖說是開源項目，但是用愛發(fā)電是不長久的、不可持續(xù)的。

展望

未來 OpenHarmony 的發(fā)展方向主要是基于軟總線的創(chuàng)新。

雖然大家現(xiàn)在感受不深，但是如果你一直關(guān)注代碼的更新，你就會發(fā)現(xiàn)一個非常有趣的代碼倉庫，雖然它的功能還不完善，只有部分功能。

它就是分布式對象，這是個用于數(shù)據(jù)同步的方法，而不是遠(yuǎn)程調(diào)用的方法，多側(cè)設(shè)備創(chuàng)建相同的對象，只要一方同步數(shù)據(jù)，其余設(shè)備都可以自動更新數(shù)據(jù)。

基于這種技術(shù)可以有無限的想像，例如我家有一個 OpenHarmony 的溫濕度計（沒有屏幕），我只需要做一個 OpenHarmony 電子墨水屏（不帶有溫濕度計）來顯示溫濕度。 這就是所謂的設(shè)備虛擬化，多種設(shè)備聯(lián)動，手機(jī)就可以調(diào)用家用攝像頭的能力來視頻通話。我猜想超級終端的實現(xiàn)，也是基于該能力做的，否則體驗不會做到這么好。

詳細(xì)的文檔地址為：

https://gitee.com/openharmony/communication_softbus_lite/blob/master/README_zh.md

當(dāng)然，以上提到的只是一些創(chuàng)新點，更多的創(chuàng)新點需要大家來想象，以前的技術(shù)不能做的事，未必現(xiàn)在不能做。

就如同當(dāng)初我們身處 3G 技術(shù)的包圍之下，很難想象出 4G 能夠多大程度影響我們的生活，能給應(yīng)用帶來多少場景創(chuàng)新。