【云驻共创】多方位了解OpenHarmony开源共建

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


本文主要内容为来自深开鸿的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

image-20230320040851134

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


image-20230319222932841

2.1.3开机动画工具

image-20230320042622711

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共建路径

image-20230320043035844

2.2提交Issue

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


image-20230320043520978

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

image-20230320043702636


2.3开发流程

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

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

image-20220719090715929

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

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

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

找不到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复制里面所有内容

image-20220719111429271

4.添加public key到码云

并把他添加到码云(Gitee.com) SSH key添加地址

image-20220719110915806

添加后,在终端(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设置保持一致

向OpenHarmony社区提交代码

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代码到本地

image-20230320044635221

2.3.4.本地开发和测试

2.3.5.提交Pr并通过CL门禁

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

image-20220625110150526

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

image-20220625110210970

标题为你修改的任务摘要

比如我的:智能家居中控

image-20220719131555042

关联ISSUE ID

第一步查看自己的issues ID

image-20220723140925451

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

image-20220723141445018

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

image-20220625110230911

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.系统解决方案

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

image-20230322051500185

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性能的主要因素。可以是一个文件根据需要占有一个或者多个缓存,延缓或者减少文件刷新次数。



image-20230320033031571

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

image-20230320035518634

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

image-20230320034801480

进展:

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开源共建

【版权声明】本文为华为云社区用户原创内容,转载时必须标注文章的来源(华为云社区)、文章链接、文章作者等基本信息, 否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。