30 分钟成为 Contributor｜如何多方位参与 OpenHarmony 开源贡献？

2022 年 8 月 01 日
本文字数：3653 字
阅读完需：约 12 分钟

如何优雅地参与开源贡献，向顶级开源项目提交 PR（Pull Request）。战“码”先锋直播间第八期围绕“OpenAtom OpenHarmony（以下简称“OpenHarmony”）开源贡献”话题，邀请了深圳开鸿数字产业发展有限公司（以下简称“深开鸿”）资深 OS 框架开发工程师巴延兴为大家带来《如何多方位参与 OpenHarmony 开源贡献》主题分享。

本次分享主要介绍了巴延兴带领深开鸿开源共建团队在主导/共建 16 个 SIG、贡献超过 50 万行代码的 OpenHarmony “战码”经验，在根技术、垂直领域、生态扩展等多方位参与开源贡献的实践与思考，以及辅助工具 SIG 和内核 SIG 两大板块的贡献方式、价值与用途，希望有更多开发者参与开源共建。

参与战“码”先锋，PR 征集令！感兴趣的开发者可以在 Gitee 的 OpenHarmony 代码仓提交 PR 参与活动，和全球开发者同台竞技，比拼技艺，为 OpenHarmony 生态建设贡献力量。

如何通过 SIG 进行开源贡献

什么是 SIG？

SIG 全称 Special Interest Group，即特别兴趣小组，专注一个特定的技术领域，负责该领域技术竞争力分析和关键技术识别及决策，引领技术演进的方向，也是共建单位及个人开发者进行开源贡献的基本单位。

通过 SIG 组参与开源共建的两种方式

一、参与到已有 SIG 的共建

参与者需要注册自己的官方账号，签订协议后，才能通过认领 SIG leader 发布的需求来承接共建任务。领完需求后是标准的开发过程，包括需求分析、功能设计、代码开发、功能测试、功能交付等步骤；任务开发完成后，需要提交 PR，将代码、文档等提交到社区，完成最终的开源贡献。

二、主导 SIG 组

1、成立 SIG

选取共建技术领域并给出规划 → 向 PMC 例会提交议题并通过评审 → 通过架构 SIG 例会评估后建立新的代码仓。

2、孵化 SIG

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

3、毕业 SIG

向架构 SIG 申请新 SIG 毕业 → 向 QA SIG 会申请新 SIG 准出 → 仓库 owner 移仓。

辅助工具 SIG 实践经验分享

成立辅助工具 SIG 组的宗旨是“降低重复劳动，提高工作效率，让专业的人做专业的事”。NAPI 框架代码生成工具、IDL 转换工具和开机动画工具都是围绕着这个宗旨开发而成的。

一、NAPI 框架代码生成工具

NAPI 是标准设备上的 JS API 实现方式，实现了 JS 语言到框架 C++层的调用，在 OpenHarmony 系统中，APP 调用是调用 JS 语言的接口函数，最终具体功能是用 C++语言来实现。

NAPI 存在三个开发痛点需要解决：

1、NAPI 框架代码的重复率高：面对不同的 JS 接口，开发者要实现相似度高的框架代码。

2、NAPI 框架的学习成本高：框架机制涉及 JavaScript、C++语言，以及编译脚本工具。

3、NAPI 需求量大：OpenHarmony 系统功能均是通过 NAPI 接口体现，目前已经支持 1 万多个 NAPI 接口。

针对以上三个痛点，NAPI 框架代码生成工具将 C++ 、JavaScript 接口类型转换等代码抽取公共模块，并且自动生成编译脚本。开发者使用工具自动生成 NAPI 框架代码，只需实现业务代码调用即可，避免了大量重复的工作。

二、IDL 转换工具

OpenHarmony 使用的是 HDF 驱动框架，驱动相应的硬件信息需要 IDL 文件来描述。

IDL 存在两大开发痛点需要解决：

1 、HDI 开发难度大：HDI 开发者比较熟悉 C 语言，习惯在.h 文件中定义 HDI 接口，而对于 IDL 文件结构、语法并不是很熟悉，学习曲线相对较长。

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

针对以上痛点，深开鸿设计的 IDL 转换工具将开发者熟悉的.h 文件自动转换为 idl 文件，开发者只需要在头文件中定义自己的接口即可，工具自动实现.h 头文件到 IDL 文件转换，开发者不需要关心 IDL 语法，大大降低工作量。

三、开机动画工具

开机动画工具是我们早期针对 OpenHarmony2.0 版本存在的问题做的一个辅助工具。

OpenHarmony2.0 版本在开机动画方面有两个问题：

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

2、因为产品的形态不一，对于不同的产品，其开机动画的需求也是不同。

通过开机动画辅助工具使以上两个问题得到了更好地解决：

1、开机动画工具支持图片集或者 mp4 等多种文件生成开机动画，且支持设置开机动画的分辨率等操作，更加方便开机动画的制作。

2、做到一键生成开机动画文件，并且支持在 windows 平台上查看其效果，不需要每次都去烧录到开发板上，大大降低了演示的工作量。

四、辅助工具 SIG 共建方向

目前深开鸿主导的辅助工具 SIG 组主要提供给开发者文档资料、测试用例和工具开发 3 个共建方向。

如果你擅长文档编撰，那么可以参与到社区的文档贡献，撰写文档可以不需要有很强的开发能力。

如果你是测试人员，擅长自动化测试，那么通过测试用例也可以参与到社区的建设。

另外也欢迎各位开发者参与到各种工具的建设中来。SIG 组的工具可以是独立的工具，也可以通过插件的方式集成到 IDE 开发软件中。

五、参与辅助工具 SIG 贡献的具体方式

1、提交问题单。无论是文档的 bug、测试用例的 bug、还是代码的 bug，提交了问题单就是对社区做了贡献，那么辅助工具 SIG 组如何提交问题单呢？

首先找到对应的仓库并登录，例如https://gitee.com/openharmony/napi_generator/issues。

提交过程中要注意格式要求，必须写清楚提单过程中问题出现的条件，预期的结果和错误的结果，问题的定位信息等，有了这些信息后，领取这个问题单的开发也方便定位问题。

登录找到想要认领的问题单的页面，在评论中表达出想要承接这个需求的意愿，SIG 的负责人会定期跟踪这些问题单并做出答复。

2、认领需求后进行开发流程

领到一个需求后要进行正常的开发，核心分为以下 6 步：

①通常开发者已经配置好配置码云账号、个人邮箱和签署 DCO（签署 DCO 主要是保证贡献者原创），有了这些前置工作以后，我们可以操作代码仓库进行需求的开发。

②Fork 代码到私仓。

③克隆 fork 出来的仓库到自己的主机上。

④在本地开发代码开发和功能验证。

⑤开发完毕后向官方原始仓提交 Pull Request，提交代码后会触发门禁等常规检查。

⑥如果这个 sig 组是你自己主导的，那么作为 Committer，需要评审别人提交的代码，如果只是参与共建，提交完代码通过门禁就完成任务。

内核 SIG 参与共建经验

关于深开鸿内核 SIG 共建经验，下面将以文件系统的优化为实例向大家分享具体的贡献过程。

内核共建的方向比较多，体系架构有各个硬件平台的移植，内核模块中功耗管理、时间管理、任务调度、中断管理、文件系统、三方库相关的内核 shell 命令移植，目前深开鸿主要在文件系统和第三方库方面做社区共建。深开鸿希望将来展开更多方向的优化工作，并向外提供具体场景下内核系统移植方案。

littlefs 文件系统的共建过程：

1、了解社区需求，社区目前对 littlefs 文件系统随机读写的速度不满意。

2、了解到社区文件系统对随机读写需求的前提下，对 littlefs 随机读写 IO 性能瓶颈进行分析，找到能优化的代码点，采用了“以空间换时间”的思路。

3、采用逐步优化的思路，明确方案后和社区负责人沟通，得到了社区负责人认可后，展开具体的代码工作。

由于文件系统优化是一个比较复杂的过程，下面分享了一套社区共建流程。

1、从社区认领需求后，通过微信群的方式和社区负责人沟通并澄清需求。

2、从技术上分析需求并制定优化方案，再次和社区负责人沟通，做方案讨论并得到认可。

3、具体任务开发，包括任务拆解、编码实现、测试，最后提交 PR。

针对 littlefs 文件系统优化过程中修改涉及到的相关文件，包括 littlefs 文件代码，也就是点 c 和点 h 文件；也有编译相关的文件，即.gn 文件 gni 文件，之所以修改编译相关的文件是为了测试 littlefs 的优化后的代码，我们团队增加了相关的测试用例，这些测试用例会调用内核文件系统的 API，涉及到这些编译相关的文件。