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