全面解析OpenHarmony 3.0 LTS

在 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"[e-mail]"

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 能够多大程度影响我们的生活，能给应用带来多少场景创新。

编辑：jq