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

相較于 OpenHamrony 1.0 LTS 版本只支持小型和輕量系統，OpenHamrony 3.0 LTS 版本覆蓋了小型、輕量和標準系統，從 IoT 設備到手機的系統全支持。

本文將會詳細介紹我關注的 OpenHamrony 3.0 LTS 版本一些改變。

編譯環境配置有所簡化

在 OpenHarmony 3.0 系統中，搭建環境不再需要那么復雜的操作（環境最好為 20.04），大概需要 6 步即可以編譯出你想要的結果。

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

①安裝依賴

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+±multilibg++flexdosfstoolsdefault-jredefault-jdkcurlccachebuild-essentialbisonbinutilsbcgenext2fsruby

②安裝工具：repo 和 hc-gen

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

默認使用 root 權限安裝至 /usr/local/bin，也可以裝至其他路徑。

③配置 git 相關參數，（可能也需要你把 ssh 公鑰填到 gitee 設置中）。

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

gitconfig--globaluser.name"xxx"

④創建代碼目錄并拉取代碼：

mkdirOpenHarmony

cdOpenHarmony

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

reposync-c

repoforall-c'gitlfspull'

⑤下載預編譯工具：

./build/prebuilts_download.sh

⑥運行編譯腳本（需自行調整參數）

編譯 Hi3516DV300 鏡像：

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

編譯 arm64 系統鏡像：

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

編譯 SDK 庫：

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

結果輸出：

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

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

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

新增了哪些功能

在每次發布后都會有一份詳細的文檔介紹新增的功能，例如這次的更新如下：當前版本在 OpenHarmony 2.2 Beta2 的基礎上，針對標準系統、輕量系統和小型系統更新內容。

標準系統新增特性功能：

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

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

• 支持設備管理 PIN 碼認證的基本能力。

• 支持關系型數據庫、分布式數據管理基礎能力。

• 支持方舟 JS 編譯工具鏈和運行時，支持 OpenHarmony JS UI 框架應用開發和運行。

• 支持遠程綁定 ServiceAbility、FA 跨設備遷移能力。

• 支持應用通知訂閱與應用通知消息跳轉能力。

• 支持輸入法框架及支持輸入基礎英文字母、符號和數字。

• 相機應用支持預覽、拍照和錄像基礎能力。

• 支持 CS 基礎通話、GSM 短信能力。

• 支持定時器能力，提供定時時區管理能力。

• 在標準設備間的分布式組網下，提供應用跨設備訪問對端資源或能力時的權限校驗功能。

輕量和小型系統新增特性功能：

• 新增輕量級分布式能力增強，支持從輕量級系統啟動標準系統上的 Ability。

• 軟總線能力增強支持，提供認證通道傳輸能力，用于設備綁定。

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

• 輕量系統上新增權限屬性字段及其寫入接口，上層應用可通過該字段實現相關業務。

詳細的介紹可以查看鏈接：

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

挑幾條大家比較關注的點來講講

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

如果你開發過 HaronyOS 應用，你就會覺得很熟悉，HarmonyOS 是通過 Java 來實現 ServiceAbility 和 DataAbility 的能力。

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

②用戶程序框架子系統能力得到了增強

大家可以通過調用系統 API 來安裝、卸載 HAP 以及獲取指定用戶下所有已安裝的應用信息，這為以后的應用市場奠定了基礎。

當然如果你能力夠的話，現在就可以嘗試實現一個應用市場的應用，大家都以后都從你這下載 HAP，這也是以后 OpenHarmony 的發行版著重關注的地方。

了解詳情請前往：

https://gitee.com/openharmony/appexecfwk_standard

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

ts2abc（TypeScript to Ark ByteCode）組件是方舟運行時子系統的前端工具，支持將 JavaScript 文件轉換為方舟字節碼文件。

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

方舟運行時子系統介紹：

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

④還有大家最為關注的軟總線，這次軟總線進行了多倉合一

以后無論輕量、小型和標準系統都使用同一份代碼，減少了大家的工作量，以后只要研究一份代碼即可。

而且軟總線的能力得到了增強，只要兩個設備接入同一個局域網中就會自動發現設備，可以體驗官方提供的兩個例子音樂和計算器。甚至可以自己使用 API 來寫一個簡單的應用流轉。

了解詳情請前往：

https://gitee.com/openharmony/communication_dsoftbus

⑤OpenHarmony 通過 CES（Common Event Service，公共事件服務）為應用程序提供訂閱、發布、退訂公共事件的能力

一般包括兩種公共事件，系統公共事件和自定義公共事件：

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

• 自定義公共事件：應用自定義一些公共事件用來實現跨應用的事件通信能力。每個應用都可以按需訂閱公共事件，訂閱成功且公共事件發布，系統會把其發送給應用。

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

⑥提供了輸入法的能力

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

⑦各種手機能力的補足

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

新加的JS的能力的倉

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

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

https://gitee.com/openharmony/js_worker_module

②基于 JS 的線程創建能力：process

主要是獲取進程的相關 id 以及獲取和修改進程的工作目錄，及進程的退出關閉。

通過 childprocess 對象可以用來創建一個新的進程，主進程可以獲取子進程的標準輸入輸出，以及發送信號和關閉子進程。

具體的使用方法請參考：

https://gitee.com/openharmony/js_sys_module

③字符串編碼：UTIL

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

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

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

具體使用方法可以參考：

https://gitee.com/openharmony/js_util_module

④解析，構造，規范化和編碼 URLs：URL 接口

URL 的構造函數創建新的 URL 對象。以便對 URL 的已解析組成部分或對 URL 進行更改。

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

具體使用方法可以參考：

https://gitee.com/openharmony/js_api_module

⑤新的界面編寫方式

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

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

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

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

啟動器詳情：

https://gitee.com/openharmony/applications_launcher

系統設置詳情：

https://gitee.com/openharmony/applications_settings

系統界面詳情：

https://gitee.com/openharmony/applications_systemui

OpenHarmony各個SIG興趣小組進展

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

①Kernel-SIG 小組

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

詳細的文檔地址為：

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

②新的 Dev-Board-SIG 小組

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

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

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

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

③Python-SIG 小組

Python-SIG 是由唐佐林老師發起的，基于 Python 做開發，專為輕量設備打造。現可以跑在 Hi3861 和 W800 兩種芯片上面，后續會增加更多的芯片。

大家如果不想學習 C 語言嵌入式開發，則可以直接使用唐老師的 Python 固件來開發，現已支持多種驅動。唐老師可是 C/C++ 的大神，10 多年的嵌入式開發經驗，可以和唐老師學習到很多。 了解詳情請前往：

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

④RISCV-SIG 小組

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

RISC-V 開源指令集架構我就不多說了，懂得都懂，也希望更多人加入進來為 OpenHarmony 的生態做出貢獻。

了解詳情請前往：

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

⑤OpenBlock-SIG 小組

OpenBlock-SIG 為了擴展 OpenHarmony OS 在青少年編程和 STEM 教育中的應用范圍。

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

了解詳情請前往：

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

⑥EduDataSpecification-SIG 小組

EduDataSpecification-SIG 旨在構建圍繞 OpenHarmony 軟硬件生態，與教育領域軟硬件伙伴共同解決教育數據采集場景中的高頻痛點，共同制定教育專屬操作系統與數據采集標準，助力教育行業自主創新，促進 OpenHarmony 教育信息化領域內的南北向應用生態快速發展。

主要以捐獻數據采集相關能力組件的方式形成教育信息數據采集事實標準。感興趣的可以查看他們的會議紀要和技術文檔，寫的非常詳細。

⑦Industrial_Internet-SIG 小組

Industrial_Internet-SIG 旨在圍繞 OpenHarmony 構建工業專屬操作系統和軟硬件生態，助力制造業自主創新。

通過開源捐獻，促進 OpenHarmony 上的工業互聯網南北向應用生態快速發展。感興趣的可以加入他們。

一個開發者面臨的困境和思考

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

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

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

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

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

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

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

我認為明年是關鍵的一年，明年的關鍵點在于生態，而不是 OpenHarmony 系統的研發。

當基礎功能具備的時候，如果沒有大量的應用開發者加入，沒有大量的應用供用戶選擇和使用，那么生態起不來，生態起不來，在生態中的企業和個人都不能實現自身價值。雖說是開源項目，但是用愛發電是不長久的、不可持續的。

展望

未來 OpenHarmony 的發展方向主要是基于軟總線的創新。

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

它就是分布式對象，這是個用于數據同步的方法，而不是遠程調用的方法，多側設備創建相同的對象，只要一方同步數據，其余設備都可以自動更新數據。

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

詳細的文檔地址為：

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

當然，以上提到的只是一些創新點，更多的創新點需要大家來想象，以前的技術不能做的事，未必現在不能做。

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