共计 4781 个字符，预计需要花费 12 分钟才能阅读完成。
编者按：在 OpenHarmony 生态倒退过程中，涌现了少量优良的代码贡献者，本专题旨在表彰奉献、分享教训，文中内容来自嘉宾访谈，不代表 OpenHarmony 工作委员会观点。
OpenAtom OpenHarmony（以下简称“OpenHarmony”）正在蓬勃发展，但开源社区在国内还是一个年老的新生事物，如何参加社区开源奉献曾经成为开发者们越来越关怀的话题。中国科学院软件研究所的黄吉老师将以一个开发者的视角给大家论述深度参加到 OpenHarmony 社区的一些心得体会。
Q1 请简要介绍下本人，以及所在开发团队
大家好，我叫黄吉，目前就任于中国科学院软件研究所（以下简称“中科院软件所”），在中科院软件所负责 OpenHarmony 移植开发相干工作。中科院软件所团队在 OpenHarmony 项目组中次要负责 OpenHarmony 的技术研发、技术支持、社区反对、SIG 仓 CI 门禁反对及保护、流动营销撑持、及其他社区治理相干的工作。
Q2 作为开发畛域出名的技术大牛，您最后为什么会抉择退出 OpenHarmony 生态、参加开源共建呢？您认为，OpenHarmony 我的项目最吸引人的点在哪里？
大牛谈不上，我的技术能力、业余意识等各方面须要学习的中央还有很多。我认为这个抉择是双向的，一方面我被 OpenHarmony 我的项目踊跃的开源精力深深吸引，感觉为开源社区奉献代码真的是一件很酷的事件，心田有参加 OpenHarmony 生态的主观能源；另一方面是 OpenHarmony 社区秉持凋谢容纳的主旨，接收了很多一般开发者，我才会有机会去理解 OpenHarmony 我的项目并尝试为其奉献代码。开源共建也是 OpenHarmony 我的项目最吸引人的重要特点。现如今 OpenHarmony 我的项目为国内开源之路迈出了松软的一步，这条路可能走得没那么快，但它的确怯懦地踏出了脚步，这就足够了。
Q3 您在什么时候退出了 OpenHarmony 开源我的项目团队？通过多久研发了 RK3568 的 ADM 驱动，合入主干上千行代码，当初被评为代码月度奉献之星，真的太了不起了！您不便给咱们介绍一下这个产品吗，或者这段经验吗？这么短时间达成了这样好的成果，请问您的“秘诀”都有哪些呢？
我是在 2021 年 2 月份的时候退出 OpenHarmony 开源我的项目团队的。过后的 OpenHarmony 还只有轻量及小型零碎，现在标准型零碎的能力曾经趋于欠缺了，并且有了本人的 hap 利用开发工具。能够看到 OpenHarmony 的能力是在一直疾速迭代、演进及欠缺。
回首 Dayu200 开发板的 ADM(Audio Device Model，音频设备模型) 开发过程，是充斥喜悦、充斥播种的。ADM 是 HDF(OpenHarmony Driver Foundation) 上面的一个音频子模块，ADM 曾经反对了 Hi3516DV300 等开发板，而咱们做的这块就是对 Dayu200 开发板的适配。在咱们做适配之前，音频驱动齐全依赖于 TinyALSA 库，当初将其齐全 HDF 化，不仅解决了依赖问题，还具备里程碑意义，为其余第三方开发板的移植提供了参考。适配过程中，咱们发现从零开始实现接口是不事实的，造轮子不仅须要思考稳定性、音频编解码、格局匹配、DMA 传输等多方面的货色，而且工作量微小，也不利于后续的保护，因而咱们另辟蹊径。采纳 Linux 原生函数来进行适配，其中 Codec 层通过注册 RK809 原生对象来获取操作 I2C 总线的对象，而后传入对应的 regmap 函数来进行寄存器读写操作；DAI 层通过注册 RK3568 原生对象来获取操作 I2S 总线的对象，而后传入对应的 regmap 函数来进行 I2S 寄存器读写操作；而 DMA 局部则是通过 Linux 原生的 dma_engine 相干函数，依照标准的流程来实现申请 DMA 通道，配置 DMA 通道，预处理 DMA 通道，DMA 数据提交，DMA 数据处理等一系列的操作。因为厂商个别都会对内核局部进行保护，并且其硬件外设都由内核驱动进行治理，应用 Linux 原生接口就相当于搭了一座桥，把下层框架与内核驱动分割了起来，保护起来更容易了。同时，这种适配思路和办法是独创性的，是非常具备借鉴意义的。
如果说有什么秘诀的话，那就是裹足不前的勇气、卑躬屈膝的毅力以及永无止境的求知欲。遇到问题是再寻常不过的事件了，“长风破浪会有时，直挂云帆济桑田”，唯有迎难而上方可解决难题。有时候很可能多条路都走不通，有时候会有挫败感，但保持的毅力会带咱们走进来，缓缓找到新的方向。当然，还有很多货色是没接触过或者不甚了解的，但求知欲会推着咱们后退，推着咱们被动去学习，去理解未知，去向身边的人求教，最终帮忙咱们的成长。
Q4 能开发出这么一个优良的产品，将外围代码合入主干，您和您的团队肯定付出了很多。能够给咱们分享一下，开发这个产品的整个过程，包含后期、中期、前期，您们具体都做了哪些工作，投入了多少人力和资源？
Dayu200 开发板基于 OpenHarmony 的移植工作是由润和软件主导，社区的多家成员单位的共事深度参加其中，有华为、润和软件、深开鸿、中科院软件所等。中科院软件所团队承接了移植 ADM 模块的工作。接下工作后，咱们分割到了华为和润和软件的技术人员，获取到了指标开发板的芯片、原理图等研发必要的材料，随后相熟硬件的参数设计、芯片寄存器配置等信息，并且逐步搭建代码框架。相熟过程其实破费的工夫和精力十分多，对于齐全不分明的构造，须要一点一点浏览文档，遇到不分明的细节问题，还要分割开发人员一点一点对齐，这是一个考验急躁的过程。中科院软件所团队在整个开发过程中始终与其余各单位共事放弃着严密的沟通，简直每天都会组织会议一起探讨研发计划，针对应用 HDI 的读写接口无奈作用于指标芯片的问题，抉择采纳 Linux 原生函数来进行适配解决，无效晋升了进度。在实现了代码的初步性能并验证后，咱们把本地适配好的代码上传提交到 OpenHarmony 代码仓，期间还通过了 CI 门禁的代码编译、代码测试、代码标准审查，有问题的局部会被批改直到通过审核。其中这个过程也相当考量细节，有可能代码标准审查一下子就报几百个标准问题或者正告，包含空格标准问题、换行标准问题、正文标准问题、宏定义标准问题等问题，须要认真地核查批改。最初通过对代码的一直修改和验证并将代码整顿到合乎社区标准的状态后，这些代码胜利合入到了骨干。总的来说，这是各方一起通力合作的后果，实现了从进度跟踪到任务分配再到技术问题攻坚的一系列问题的闭环。
Q5 在整个开发过程中，您和您的团队遇到过哪些技术上或其余方面的难题？这些难题又是如何被逐个解决？在这些难题被解决的过程中，您总结了哪些贵重的教训 or 教训？
整个开发过程中次要有以下几个艰难点。第一，Dayu200 开发板的音频芯片比拟非凡，它蕴含 Codec、RTC、PMIC 等多种性能，不能简略的采纳 ADM 接口去操作它。为了防止影响到其余性能的失常运作，咱们应用了原生 Linux 设施驱动接口来操作 I2C、I2S、DMA 的通信以及数据传递，防止了异样操作的危险。第二，播放一段时间后，进行播放，继续有尖利的很小的声音。针对此问题，咱们注册了 Trigger 函数，依据接管到状态信息，如果为进行状态，则对 Codec 相干器件进行下电。第三，RK 的音量调节性能必须要给左右声道寄存器写入雷同数值才可失效，但过后框架还不反对对左右寄存器的赋值。起初，咱们与框架开发人员协商，使得框架新增了该项性能，最终适配上了音量调节能力。
教训的话，就是肯定要多去和不同的技术开发人员沟通交流，有时候可能会陷入思维定势，经常不能发现自己代码上的问题，而他人一眼就看到关键所在，间接指出来，那么问题就迎刃而解了。
Q6 退出 OpenHarmony 生态以来，您最大的惊喜是什么？或者有哪些具体的播种？
退出 OpenHarmony 生态以来，我最大的惊喜是理解了开源社区的玩法，在 OpenHarmony 社区，能够从他人的代码中学到更多常识，同时本人的代码能够被更多人看到，好的中央不好的中央，都会有人提出来，在这种疾速的反馈中，更可能理解本人存在的有余。
我认为，这段时间充斥了播种，首先是意识了很多气味相投的小伙伴，大家都积极参与开源我的项目，奉献本人的代码，开源之路本就荆棘丛生，有这么多开源社区的搭档一起前行，路也好走了许多。其次是取得了磨难与成长，在优良的人背后，你能看到差距，从而去学习他人的长处；在优良的代码背后，你能看到框架构思的差距，从而去学习他人的编码思路，这的确让人受益匪浅。
Q7 期待将来 OpenHarmony 哪些方面可能失去改善、提供更多反对？
主观的说，OpenHarmony 还存在有一些有余的中央，比方社区反映的入门材料较少、框架解析材料不够清晰、issue 申请响应不太及时等问题。次要起因在这么几个方面，一是 OpenHarmony 倒退初期，它是国内最前沿的大规模的开源零碎，它的倒退是摸着石头过河的过程，必然会存在这样或者那样的没有遇到过的问题，这是相当失常的；二是开发者技术水平和技术关注点存在差别，有的开发者可能须要更详尽的入门材料来进入门槛，有的开发者可能关注底层驱动 lib 库的编译生成形式，有的开发者可能关注 OpenHarmony SDK 如何生成 hap 利用，不晓得如何找到本人想要的开发材料；三是 OpenHarmony 每个代码仓的治理绝对独立，由每个仓库本人的 committer 进行治理，一方面很多开发者可能找不到正确的代码仓来提 issue，另外一方面某些 committer 可能因为事务忙碌，没有及时地回复 issue。我期待将来 OpenHarmony 可能切实的疏导开发者，依据他们的需要，提供对应的开发材料开发资源，并且可能进一步增强与开发者的分割，更多聆听开发者的声音，给予良性的无效的反馈。
Q8 OpenHarmony 目前仍处在开发摸索阶段，很多共建单位和生态搭档还不分明开源我的项目的玩法，或不知该如何着手进行开发。能够请您给大家分享一条，您认为最重要或最值得分享的心得吗？
我认为 OpenHarmony 是一个十分自在凋谢的我的项目，各家共建单位或生态搭档能够依据本人的需要想法来进行抉择。如果想进行利用 hap 开发，能够参考 OpenHarmony 的 docs 仓上面的 JS 开发材料。如果是想进行开发板移植，能够参考 OpenHarmony 的 docs 仓上面的芯片移植材料，在此基础上，如果想奉献代码，则能够分割 OpenHarmony SIG 相干组织走代码上仓的流程。至于开发上的问题，倡议在 OpenHarmony 社区的 Zulip 上发问（https://zulip.openharmony.cn，未注册用户须要邮箱注册），或者在研发探讨群外面发问，或者是在相干代码仓提 issue，总之，渠道是非常宽泛的。
JS 开发材料：https://gitee.com/openharmony…
芯片移植材料：https://gitee.com/openharmony…
Q9 开放性问题，能够畅所欲言，请问您还有什么想通知大家？
OpenHarmony 的倒退是一个任重而道远的过程，当初的 OpenHarmony 就像一个刚刚学会走路的小孩，但它的成长还须要相当长的一段时间，它的成长须要有人去疏导。OpenHarmony 开源社区的倒退离不开宽广开发者的反对，离不开宽广媒体的反对，离不开国内外各大共建单位以及生态搭档的退出。我十分心愿大家可能更多关注 OpenHarmony，多给社区提提意见，大家的声音才是 OpenHarmony 衰弱倒退的能源，同时心愿大家多给 OpenHarmony 提交代码，即使一砖一瓦一沙一石，汇聚起来都能够是平凡的力量，置信只有大家的致力会集起来，OpenHarmony 肯定可能向着踊跃的方向倒退。