共计 2844 个字符，预计需要花费 8 分钟才能阅读完成。
编者按：在 OpenHarmony 生态倒退过程中，涌现了少量优良的代码贡献者，本专题旨在表彰奉献、分享教训，文中内容来自嘉宾访谈，不代表 OpenHarmony 工作委员会观点。
本期 OpenAtom OpenHarmony（以下简称“OpenHarmony”）开发者故事，咱们特地采访了 2 月代码最佳贡献者、一位接触 OpenHarmony 1 年左右，2022 年初便实现高难度开发我的项目的开发者——润和软件资深软件开发工程师赵海鹏。
赵海鹏是润和 OpenHarmony 南向业务媒体畛域负责人，次要承当 Audio 开发工作。在 RK3568 平台 Audio Driver Model 适配开发过程中，在突遇西安疫情的状况下，硬件和沟通问题都面临微小的挑战，面对急切性的我的项目需要，赵海鹏和他的搭档迎难而上，通过各种渠道去协调设施，把做好的固件寄送进来，协调软件所的搭档们做近程测试，包含焊接等等，简直每天在线工作及沟通 12 个小时以上，最终克服困难圆满完成工作。
咱们与赵海鹏一起聊了他退出 OpenHarmony 生态的初心、对 OpenHarmony 架构适配的了解、工作中遇到的难题和攻克的过程、以及开源过程的心得与教训等话题。现将专访内容整顿如下，心愿对你有所启发。
Q1 请简要介绍下本人，以及所在开发团队
大家好，我是润和软件资深软件开发工程师赵海鹏。我从 2020 年 10 月份开始正式接触 OpenHarmony 开源我的项目，开始理解框架和构造。目前在润和软件次要负责 OpenHarmony 南向业务媒体畛域。
Q2 作为开发畛域出名的技术大牛，您最后为什么会抉择退出 OpenHarmony 生态、参加开源共建呢？您认为，OpenHarmony 我的项目最吸引人的点在哪里？
第一个层面，从大的环境来说，OpenHarmony 是翻新的操作系统，这是吸引我的首要因素。
第二个层面，从个人成长来说，我心愿在 OpenHarmony 倒退的初期退出进来，这样会让我对整个零碎框架的演变更为分明，集体的成长机会点绝对比拟多。
Q3 您不便给咱们介绍一下这个产品吗，或者这段经验吗？这么短时间达成了这样好的成果，请问您的“秘诀”都有哪些呢？
“ 秘诀 ” 谈不上，次要学习和工作过程中，多给本人提问题，带着问题去学习与钻研；同时，针对过程遇到问题一直总结与积攒，造成知识库。
我接着说一下次要奉献的个性。咱们指标是把社区上非海思芯片第三方平台 RK3568 的 Audio 驱动适配起来。因为 Openharmony Audio 驱动框架是 ADM，原生的驱动是 ALSA，差别相对来说比拟大。为了加快进度协调软件所的一个搭档和我一起联合开发，正好赶上西安的疫情，我就始终在家里专一的搞研发，须要交换就通过线上沟通。过程中会遇到很多艰难，调试 Audio 驱动，须要一些硬件设施（示波器、逻辑分析仪等）的撑持，而处在疫情环境下，有的设施是短少的，西安的快递也很难进来，咱们通过各种渠道去协调设施，而后把做好的固件收回去，让中科院软件所的搭档做近程测试，包含焊接等等。
另外，咱们工作的工夫节点比拟缓和，只有不到一个月左右的工夫，Audio 驱动代码裁剪过后还有三万行，也就是咱们要把三万代码读懂再适配到 OpenHarmony 上，给咱们的工作也减少了难度，然而咱们都一一克服，坚挺过去，最终实现了工作。
Q4 能开发出这么一个优良的产品，将外围代码合入主干，您和您的团队肯定付出了很多。能够请您给咱们分享一下，开发这个产品的整个过程，包含后期、中期、前期，您们具体都做了哪些工作，投入了多少人力和资源吗？
在后期，内核代码中 Audio 相干的有 10w+ 的代码，须要做裁剪成最小汇合，另外，须要梳理主线上 ADM 的代码框架，参考：https://gitee.com/openharmony…。
两头阶段，进入真正的开发过程中，我先把框架做好，而后依照模块分工合作开发。过后因为是线上办公，每天的工作工夫都在 12 小时以上，单方通过线上会议交换，呈现问题及时沟通及时解决。
前期次要是调试阶段，过后信号有一些问题，中科院软件所的硬件工程师帮咱们焊接，而后采样并把信号图像回传到咱们这边，再做剖析，而后再做下一个计划的调整，遇到一些难以解决的问题，也会求助 ADM 框架负责人。为了保障较高的工作效率，这些都在线上会议进行沟通。
另外，调试过程中发现框架存在一些不敌对不欠缺的中央，在适配过程中不断完善，造成了 Linux 绝对简略适配的计划并造成文档，在社区上公布。该计划存在的问题是不兼容 LiteOS，没有齐全实现 ADM 的优化能力。
Q5 在整个开发过程中，您和您的团队遇到过哪些技术上或其余方面的难题呢？这些难题又是如何被逐个解决的？在这些难题被解决的过程中，您总结了哪些贵重的教训 or 教训呢？
技术问题：RK3568 平台的 codec 组件应用的 RK809，此芯片不是繁多的 Codec 性能还蕴含电源治理的模块，应用同一路 I2C 管制通道，拆分难度大，可能还要设计电源治理模块。
解决方案：借助 Linux 原生驱动，ADM 的驱动接口初始化节点调用对应的 probe 函数，依照此思路举一反三，其余模块也依照的这样的操作，缩小驱动代码开发对寄存器的依赖，晋升开发效率。具体的计划在 RK3568 驱动适配文档中有阐明，请关注。
Q6 退出 OpenHarmony 生态以来，您最大的惊喜是什么？或者有哪些具体的播种？
播种的第一个层面，是我以前的工作经验相对来说是单个模块或者单个个性，而当初有机会面对整个零碎。同时，OpenHarmony 正经验从 0 到 1 的过程，在咱们工作的过程中能够深刻理解整个零碎，取得比拟全面的认知，对能力的晋升空间比拟大。
第二层面针对零碎的设计，以前我只须要思考需要外部实现逻辑、流程、接口等。当初做需要设计的时候，先思考内部依赖，定义接口，而后再去设计具体的需要的框架，软件分层等等。
Q7 OpenHarmony 目前仍处在开发摸索阶段，很多共建单位和生态搭档还不分明开源我的项目的玩法，或不知该如何着手进行开发。能够请您给大家分享一条，您认为最重要或最值得分享的心得吗？
我感觉最次要的是联合本人过往的工作背景或者环境，如果没有太多教训，能够从 mini system 动手，如果有一些安卓或者 Linux 的教训，能够从 standard system 动手。总之，肯定要从本人相熟的模块动手，这样能力举一反三，通过边学边拆的形式，相熟度才会越来越高。
动手之后，须要集中在单点上深入研究，把一个点深度理解后，其余点学习的就会比拟快。同时也要看看整体的架构，如果对架构都不理解的话，是不足以撑持后续开发和我的项目工作，至多须要有概念性的认知。
Q8 开放性问题，能够畅所欲言，请问您还有话想通知大家？
从驱动零碎上来讲，目前 OpenHarmony 的驱动是基于 HDF 开发的，既能够在 Linux 上运行，也能够在 LiteOS 上运行，便于移植。但目前成熟度不够，适配难度较高。对开发者来说不太敌对，心愿各共建单位和开源开发者一起去欠缺，让平台驱动适配更容易。
