本期 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 上運行，便于移植。但目前成熟度不夠，適配難度較高。對開發者來說不太友好，希望各共建單位和開源開發者一起去完善，讓平臺驅動適配更容易。

審核編輯 ：李倩