如何进行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/docs/blob/master/zh-cn/device-dev/driver/driver-peripherals-audio-des.md。
中间阶段，进入真正的开发过程中，我先把框架做好，然后按照模块分工合作开发。当时因为是线上办公，每天的工作时间都在 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 上运行，便于移植。但目前成熟度不够，适配难度较高。对开发者来说不太友好，希望各共建单位和开源开发者一起去完善，让平台驱动适配更容易。