OpenHarmony 3.0 LTS全解析：首个真正意义上全量长期支持版本 原创 精华

在2021年09月30号，OpenHarmony迎来了重大更新，发布了3.0长期支持版，这是今年发布的第二个长期支持版，也是首个真正意义上全量长期支持版本。相较于OpenHamrony 1.0 LTS版本只支持小型和轻量系统，OpenHamrony 3.0 LTS版本覆盖了小型、轻量和标准系统，从IoT设备到手机的系统全支持。
 

本文将会详细介绍我关注的OpenHamrony 3.0 LTS版本一些改变。

编译环境配置有所简化

在OpenHarmony3.0系统中，搭建环境不再需要那么复杂的操作（环境最好为20.04），大概需要6步即可以编译出你想要的结果。这里列出具体的步骤，方便熟悉旧版本的读者做对比：

1. 安装依赖

sudo apt-get update && sudo apt-get install gnutls-bin gcc-arm-linux-gnueabi build-essential fakeroot dpkg-dev git-lfs build-essential gcc g++ make zlib* zip xsltproc x11proto-core-dev wget vim unzip u-boot-tools tzdata texinfo ssh scons python3-minimal python3-setuptools python3-pip python3-distutils python3-apt python3.8-distutils npm nfs-kernel-server mtools mtd-utils m4 locales libxml2-utils libx11-dev libreadline-dev libgl1-mesa-dev libffi* libc6-dev-x32 libc6-dev-i386 lib32z-dev lib32ncurses5-dev gperf gnupg git-lfs git-core g+±multilib g++ flex dosfstools default-jre default-jdk curl ccache build-essential bison binutils bc genext2fs ruby

2. 安装工具：repo 和 hc-gen

sudo curl -s https://gitee.com/oschina/repo/raw/fork_flow/repo-py3 > /usr/local/bin/repo

默认使用root权限安装至/usr/local/bin,也可以装至其他路径

3. 配置git相关参数，(可能也需要你把ssh 公钥填到gitee设置中)。

git config --global user.email "xxx@mail.com"

git config --global user.name "xxx"

4. 创建代码目录并拉取代码

mkdir OpenHarmony

cd OpenHarmony

repo init -u https://gitee.com/openharmony/manifest.git -b OpenHarmony-3.0-LTS --no-repo-verify

repo sync -c

repo forall -c 'git lfs pull'

5. 下载预编译工具

./build/prebuilts_download.sh

6. 运行编译脚本（需自行调整参数）

编译Hi3516DV300镜像

./build.sh --product-name Hi3516DV300 –ccache

编译arm64系统镜像

./build.sh –product-name ohos-arm64 --ccache

编译SDK库

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

————
作者：候鹏飞
 

本文作者51CTO HarmonyOS社区主页链接：https://harmonyos.51cto.com/user/posts/13519852