編者按：在 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 一定能夠向著積極的方向發展。
