本文主要内容为来自深开鸿的OS框架开发工程师巴延兴从深开鸿参与OpenHarmony的社区贡献概览，到个人如何通过SIG进行开源贡献。以及后面的参与共建的方向路径以及贡献流程的学习。最后介绍HDF、软总线SIG共建成果。也是给我们一个启发，OpenHarmony是每个人的OpenHarmony，只要想参与共建，都可以利用自己对应的技能做贡献。

1.1深开鸿参与社区贡献总览

深开鸿开源策略：从开源中来，到开源中去。

截至目前。深开鸿主导了 4 个 SIG，参与共建的 SIG 有 12 个，尤其是内核、软总线、HDF、ArkUI 等根技术领域都有深度参与，累计向主干贡献代码 40万行。我个人目前参与OpenHarmony最好的成绩是在战码活动带领一百余人提交Pr，自己累计向主干提交1.5W+代码。

1.2如何通过SIG进行开源贡献

参与:向SIG leader发起申请。审核同意后即可参与到共建中来:共建者通过认领SlGleader发布的任务issue来承接共建任务、再按照需求分析、功能设计、代码开发、功能测试、功能交付等步骤进行任务开发:任务开发完成后。提PR把代码、文档等提交到社区，完成最终的开源贡献。 主导:如果想申请并主导成立一个新的SIG，需要经过申请、孵化、毕业等步骤。整个过程经过PMC例会，架构SIG QA SIG等组织的审视和把控SIG后成立后，需要定期组织召开会，带领其他共建单位向社区积极贡献技术成果(代码、文档等等)。

关于SIG，也有三个阶段

SIG成立

• 选取共建技术领域并给出规划

• 向PMC例会提交议题并通过评审

• 通过架构SIG例会评估后建立新的代码仓。

SIG孵化

• 启动需求澄清、特性梳理方案设计、代码开发、单元测试、功能测试等流程，完成SIG项目开发OAT等问题自检。

SIG毕业

• 向架构SIG申请新SIG毕业

• 向QA SIG会申请新SIG准出

• 仓库owner移仓

2.1辅助工具SIG主导实践经验

2.1.1辅助工具SIG

OpenHarmony系统开发痛点

1.NAPI重复率高

NAPI框架代码的重复率很高，面对着不同的TS接口，开发者都要去实现相似度很高的框架代码，繁琐且效率低下

2.NAPI学习成本高

NAPI框架实现机制，不仅涉及JavaScript、C++语言，而且还涉及编译脚本，使得开发者学习成本较高。

3.NAPI需求量大

OpenHarmony系统功能均是通过NAPI接口体现，目前已经支持1w多个NAPI接口。

深开鸿优化点

1.降低代码重复率 工具将 C++、JavaScript接口类型转换等代码抽取公共模块，降低了代码重复率

2.降低学习成本

工具不仅可以实现JavaScript、C++数据类型转换，还可以生成编译脚本，使得开发者学习成本降低

NAPI学习成本高工具框架解析器 IntelliJ IntelliJ namespace异步函数同步函数生成器 return interface parameters

3.降低开发工作量

代码仓地址:https://gitee.com/openharmony/napi_generator

2.1.2IDL转换工具

OpenHarmony系统开发痛点

1.HDI开发难度大 HDI开发者对于C语法较熟悉，习惯在.h文件中定义HDI接口， 而对于IDL文件结构、语法并不是很熟悉，需要学习IDL相关语法，造成开发难度较大

2.HDI工作量大

HDI接口是驱动对外提供服务的必要条件，各个子系统均有涉及，故HDI工作量较大

深开鸿优化点

1.降低开发难度 工具将 开发者熟悉的.h文件转换为系统需要的.idl文件，节省了开发者的学习idl的成本，降低了HDI的开发难度

2.降低开发工作量 工具实现.h到.idl转换后，开发者的工作量大大降低，缩短交付周期

代码仓地址:https://gitee.com/openharmony/drivers_framework/tree/OpenHarmony-3.1-Release/tools/idl-gen

2.1.3开机动画工具

OpenHarmony系统开发痛点

1.资源格式要求高

OpenHarmony2.0版本开机动画只支持raw文件，不利于开发者在发行版和定制版进行直观展现

2.定制化需求大 对于不同的产品，其开机动画均不同，产品需求多样化、需求量大

深开鸿优化点

1.资源格式多样化

开机动画工具支持图片集和mp4文件，并支持开机动画的分辨率、旋转角度、翻转等设置操作，使得资源格式多样化， 更加方便开机动画的制作

2.降低演示工作量

一键生成开机动画文件，并且支持在 PC 上查看动画效果，降低了演示的工作量 代码仓地址:https://gitee.com/openharmony/graphic_standard/tree/master/frameworks/bootanimation/data/bootanimation_tool

2.2参与共建

2.2.1共建方向

共建方向我们可以从文档资料，测试用例，工具开发入手。

文档资料

• 使用指导

• 开发指导

• 集成指导

测试用例

• UI用例

• ST用例

• 测试框架

工具开发

• 工具能力

• VSCode插件

• IntelliJ插件

2.2 内核SIG参与共建经验

2.2共建路径

2.2提交Issue

1.进入社区主代码，点击新建Issue

2.输入标题和相关描述，点击创建即可。

2.3开发流程

2.3.1.配置码云账号，个人邮箱并签署DCO协议

1.注册，地址: https://gitee.com/ 注册码云账号，只要点击导航条中的“注册”，或者点击首页中那个大大的“加入码云”按钮，即可进入注册页面。

输入账号、邮箱、密码,然后点击注册按钮.

注册的时候最好取一个有意义的名字，比如姓名全拼，昵称全拼，如果被占用，可以加上有意义的数字.比如我的

注册完官方会向大家的邮箱发送一份激活邮件，请点击其中的链接激活账号，账号激活后，注册流程就算完成了。注册完毕即以新注册的账号登录，登录后即进入用户的控制面板页面。

找不到ssh-keygen命令是因为你的工作目录不在ssh-keygen.exe所在目录下，导致找不到命令，所以切换工作目录到ssh-kengen所在目录(Git/usr/bin/)即可。以我为例，我的Git安装在D盘Git下，所以进行操作 cd D:/Git/usr/bin/ ，然后执行 ssh-keygen -t rsa -C “您的邮箱地址” 即可。

2.公钥认证管理

开发者向码云版本库写入最常用到的协议是 SSH 协议，因为 SSH 协议使用公钥认证，可以实现无口令访问，而若使用 HTTPS 协议每次身份认证时都需要提供口令。使用 SSH 公钥认证，就涉及到公钥的管理。

3..如何生成ssh公钥

你可以按如下命令来生成sshkey:

这个邮箱就是你的上面的邮箱

ssh-keygen -t rsa -C "xxxxx@xxxxx.com"  
​
# Generating public/private rsa key pair...
# 三次回车即可生成 ssh key

查看你的 public key，

mac

cat ~/.ssh/id_rsa.pub
# ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC6eNtGpNGwstc....

windows

在C:\Users\用户.ssh目录下找到id_rsa.pub复制里面所有内容

4.添加public key到码云

并把他添加到码云（Gitee.com） SSH key添加地址

添加后，在终端（Terminal）中输入

ssh -T git@gitee.com

若返回

Welcome to Gitee.com, yourname!

则证明添加成功。

5.DCO签署

1.DCO签署网址

开发者原创声明Developer Certificate of Origin

开发者原创声明

注意：

DCO签署Name 必须要和git config --global user.name 设置保持一致（其实不一致也可以，但一致之后少麻烦）

DCO签署E-mail必须要和git config --global user.email设置保持一致

6.修改本地的邮箱和签署邮箱一致

git config --global user.name "你的名字" 
git config --global user.email "你的gitee绑定邮箱"
git config --global  --list

比如我的：

git config --global user.name "徐建国" 
git config --global user.email "852851198@qq.com"
git config --global  --list

2.3.2.Fork代码到私仓

2.3.3.clone代码到本地

2.3.4.本地开发和测试

2.3.5.提交Pr并通过CL门禁

5.1代码提交到自己的私有仓，刷新，点击“+ Pull Request”建PR合入代码到社区主代码仓；

5.2.进入PR提交界面，可选择代码仓库分支，和关联ISSUE ID，简单描述合入的PR修改等信息；

标题为你修改的任务摘要

比如我的：智能家居中控

关联ISSUE ID

第一步查看自己的issues ID

第二步添加到自己的Pull request的描述里

5.3PR建立成功，首先默认进行DCO检查，检查成功，需要手动在评论区输入回复”start build”方可进入代码的CI静态检查和编译等操作。

2.3.6.联系committer

联系committer、进行Committer评审

committer：https://gitee.com/openharmony/community/blob/master/zh/committer.md

2.4HDF、软总线SIG共建成果介绍

2.4.1内核SIG

进展:

1.Littlefs文件系统优化

采用读写缓存链表或者环形数组，增加读写缓存文件的数量，加速读写进程，而 Littlefs目前仅用两个内存块作为数据缓存区，限制读写并发:另外，根据Littlefs的磨损均衡策略等实现方式，进行改进.

2.第三方库移植

移植iperf等第三方库，扩展shell功能

规划:

1.内核模块优化

优化内核中断管理、内存管理、功耗管理等策略，并提供配置接口，以便用户根据使用场景自主选择

2.系统解决方案

借助于对系统的极致了解，向外提供具体场景的系统解决方案

2.4.1.1Littlefs优化需求和方案

1.社区需求

更新文件数据性能差，一些典型场景，

(1)在一个文件中的随机位置写数据

(2)向文件中按顺序多次写入一个字节的数据

2.Littlefs随机读写10性能瓶颈分析

每个Littlefs文件都占有一个Cache，既可以用作读缓存又可以用作写缓存。对于写缓存，在切换作读缓存的时候，或者访问的位置超过当前缓存的时候，都要进行文件刷新，其中要涉及到耗时的块擦除(520ms)。若是修改了Littlefs文件CTZ跳表中一个非末尾块内容时，会涉及到多个块数据的搬移。这样，在随机读写的场景中，10性能会表现的很差。

3.Littlefs优化方案

由上述对Littlefs随机读写IO性能瓶颈的分析可知，影响IO性能的主要因素是每个文件拥有有一个Cache，在由写切换到读或者写的位置超过一个Cache时，都会引起存储文件内容的块的替换，其中包含了耗时的块擦除操作。基于Littlefs的文件缓存可以做两个方面的优化。

(1)缓存在文件间共享，即建立一个缓存池，文件都从缓存池内申请缓存，或者释放缓存到该缓存池: (2)一个文件多个缓存，即缓存过少是引起文件刷新进而影响IO性能的主要因素。可以是一个文件根据需要占有一个或者多个缓存，延缓或者减少文件刷新次数。

2.4.1.2Littlefs编写和编译过程总结

(1)修改lfs.c和lfs.h文件

(2)修改gn配置文件

因为Littlefs只是liteosm支持的众多文件系统中的一种，并且需要在VFS接口和Littlefs接口做转换所以此处只使用了gni文件引用Littlefs源文件。所以只需要修改Littlefs.gni (3)编译Littlefs为内核模块

Littlefs和VFS间不能直接兼用，这里除了对Littlefs源文件Littlefs.gni的引用外，还添加了实现 Littlefs和VFS间接口的源文件。

(4)添加liteos_m对Littlefs的引用

2.4.1.3Littlefs提交PR过程总结

1.Littlefs第三方库repository路径，并fork到用户自己仓

2.git clone 到本地

3.提交修改到用户仓

git add .
git commit -s -m '修改信息'
git push

4.提交PR

5.填写PR单

6.评论中添加“start build”触发。

2.4.2Video Coder HDF 驱动SIG

RockChip 芯片支持:

• 我们基于RockChip Toybrick 3568x实现了HDF框架开发。RockChip 提供了适用于瑞芯微系列芯片的通用媒体处理软件平台MPP，对于其他型号的RK芯片，只需基于MPP编译对应的OpenMax框架，即可实现对接HDF框架

• MPP提供了MPI接口，可对接OpenMax，FFmpeg，Gstreamer或者直接对接上层应用。我们基于这套接口提供的MppBuffer，MppBufferGroup以及 packet和frame相关的组件和接口，结合Buffer队列，共享内存等机制，实现了硬件编解码流程，并完成了相关的编解码演示程序和单元测试程序

未来演进:

• 目前驱动框架依赖的OpenMax框架，主要应用于标准富设备。未来将会定义 OpenHarmony自有接口，其特性是支持所有的轻设备与富设备，具有更大的灵活性，为开发者提供更好的选择，实现一次开发多端部署。

• 同时针对输入输出Buffer的跨进程传输将增加BufferHandle和 DynamicHandle支持，编码时直接将YUV数据输出到显示内存，编码时直接从显示中获取YUV数据，减少内存的拷贝，提高效率 ToyBrick-RK3568X。

• 在芯片支持上，将支撑更多芯片厂商的对接工作

2.4.3软总线SIG

进展:

1.蓝牙协议栈首次适配第三方芯片(RK3568x)

2.支持软总线通过蓝牙传输文件

3.补齐WIFI Direct能力

4.补齐STA确实功能(扫描信息完善、静态IP地址设置等)

5.提供NFC开发板和NFC芯片(NXP PN7150)

6.移植开源NFC协议栈，适配对接NFC服务层

规划：

1.API优化

支持对蓝牙API进行权限检查

2.标准跟踪

支持BT5.0升级到BT5.2/5.3版本

3.功能增强

• 支持文件传输功能

• 支持BLE Audio

4.提供WIFI STA和AP共存

5.支持WIFI IPV6

6.支持NFC controller基本能力

7.支持NFC TAG基本读写能力

总结

本文主要讲解了一些深开鸿团队对OpenHarmony的共建成绩，以及如何贡献。在我看来，除了文中的共建方式，还可以进行开发者倡导，开发者体验，以及开发者传播。最后有些事不是看到了希望才去坚持，而是因为坚持了才会看到希望。仰望星空，不如躬身入局，欢迎大家加入 OpenHarmony生态大家庭。

本文参与华为云社区【内容共创】活动第22期。

任务14： HC大会社区活动系列直播-OpenHarmony专场：多方位了解OpenHarmony开源共建