OpenAtom OpenHarmony（以下簡稱“OpenHarmony”）正在蓬勃發(fā)展，但開源社區(qū)在國內(nèi)還是一個年輕的新生事物，如何參與社區(qū)開源貢獻已經(jīng)成為開發(fā)者們越來越關心的話題。中國科學院軟件研究所的黃吉老師將以一個開發(fā)者的視角給大家闡述深度參與到 OpenHarmony 社區(qū)的一些心得體會。

Q1

請簡要介紹下自己，以及所在開發(fā)團隊

大家好，我叫黃吉，目前就職于中國科學院軟件研究所（以下簡稱“中科院軟件所”），在中科院軟件所負責 OpenHarmony 移植開發(fā)相關工作。中科院軟件所團隊在 OpenHarmony 項目組中主要負責 OpenHarmony 的技術研發(fā)、技術支持、社區(qū)支持、SIG 倉 CI 門禁支持及維護、活動營銷支撐、及其他社區(qū)治理相關的工作。

Q2

作為開發(fā)領域知名的技術大牛，您最初為什么會選擇加入OpenHarmony生態(tài)、參與開源共建呢？您認為，OpenHarmony項目最吸引人的點在哪里？

大牛談不上，我的技術能力、專業(yè)認識等各方面需要學習的地方還有很多。我認為這個選擇是雙向的，一方面我被 OpenHarmony 項目積極的開源精神深深吸引，感覺為開源社區(qū)貢獻代碼真的是一件很酷的事情，內(nèi)心有參與 OpenHarmony 生態(tài)的主觀動力；另一方面是 OpenHarmony 社區(qū)秉持開放包容的宗旨，接納了很多普通開發(fā)者，我才會有機會去了解 OpenHarmony 項目并嘗試為其貢獻代碼。開源共建也是 OpenHarmony 項目最吸引人的重要特點。現(xiàn)如今 OpenHarmony 項目為國內(nèi)開源之路邁出了堅實的一步，這條路可能走得沒那么快，但它確實勇敢地踏出了腳步，這就足夠了。

Q3

您在什么時候加入了OpenHarmony開源項目團隊？通過多久研發(fā)了RK3568的ADM驅動，合入主干上千行代碼，現(xiàn)在被評為代碼月度貢獻之星，真的太了不起了！您方便給我們介紹一下這個產(chǎn)品嗎，或者這段經(jīng)歷嗎？這么短時間達成了這樣好的效果，請問您的“秘訣”都有哪些呢？

我是在 2021 年 2 月份的時候加入 OpenHarmony 開源項目團隊的。當時的 OpenHarmony 還只有輕量及小型系統(tǒng)，如今標準型系統(tǒng)的能力已經(jīng)趨于完善了，并且有了自己的 hap 應用開發(fā)工具。可以看到 OpenHarmony 的能力是在不斷快速迭代、演進及完善。

回首 Dayu200 開發(fā)板的 ADM（Audio Device Model，音頻設備模型）開發(fā)過程，是充滿喜悅、充滿收獲的。ADM 是 HDF（OpenHarmony Driver Foundation）下面的一個音頻子模塊，ADM 已經(jīng)支持了 Hi3516DV300 等開發(fā)板，而我們做的這塊就是對 Dayu200 開發(fā)板的適配。在我們做適配之前，音頻驅動完全依賴于 TinyALSA 庫，現(xiàn)在將其完全 HDF 化，不僅解決了依賴問題，還具有里程碑意義，為其他第三方開發(fā)板的移植提供了參考。適配過程中，我們發(fā)現(xiàn)從零開始實現(xiàn)接口是不現(xiàn)實的，造輪子不僅需要考慮穩(wěn)定性、音頻編解碼、格式匹配、DMA 傳輸?shù)榷喾矫娴臇|西，而且工作量巨大，也不利于后續(xù)的維護，因此我們另辟蹊徑。采用 Linux 原生函數(shù)來進行適配，其中 Codec 層通過注冊 RK809 原生對象來獲取操作 I2C 總線的對象，然后傳入對應的 regmap 函數(shù)來進行寄存器讀寫操作；DAI 層通過注冊 RK3568 原生對象來獲取操作 I2S 總線的對象，然后傳入對應的 regmap 函數(shù)來進行 I2S 寄存器讀寫操作；而 DMA 部分則是通過 Linux原生的 dma_engine 相關函數(shù)，按照規(guī)范的流程來完成請求 DMA 通道，配置 DMA 通道，預處理 DMA 通道，DMA 數(shù)據(jù)提交，DMA 數(shù)據(jù)處理等一系列的操作。因為廠商一般都會對內(nèi)核部分進行維護，并且其硬件外設都由內(nèi)核驅動進行管理，使用 Linux 原生接口就相當于搭了一座橋，把上層框架與內(nèi)核驅動聯(lián)系了起來，維護起來更容易了。同時，這種適配思路和方法是獨創(chuàng)性的，是十分具有借鑒意義的。

如果說有什么秘訣的話，那就是一往無前的勇氣、不屈不撓的毅力以及永無止境的求知欲。遇到問題是再尋常不過的事情了，“長風破浪會有時，直掛云帆濟滄海”，唯有迎難而上方可解決難題。有時候很可能多條路都走不通，有時候會有挫敗感，但堅持的毅力會帶我們走出去，慢慢找到新的方向。當然，還有很多東西是沒接觸過或者不甚了解的，但求知欲會推著我們前進，推著我們主動去學習，去了解未知，去向身邊的人求教，最終幫助我們的成長。

Q4

能開發(fā)出這么一個優(yōu)秀的產(chǎn)品，將核心代碼合入主干，您和您的團隊一定付出了很多。可以給我們分享一下，開發(fā)這個產(chǎn)品的整個過程，包括前期、中期、后期，您們具體都做了哪些工作，投入了多少人力和資源？

Dayu200 開發(fā)板基于 OpenHarmony 的移植工作是由潤和軟件主導，社區(qū)的多家成員單位的同事深度參與其中，有華為、潤和軟件、深開鴻、中科院軟件所等。中科院軟件所團隊承接了移植 ADM 模塊的任務 。接下任務后，我們聯(lián)系到了華為和潤和軟件的技術人員，獲取到了目標開發(fā)板的芯片、原理圖等研發(fā)必要的資料，隨后熟悉硬件的參數(shù)設計、芯片寄存器配置等信息，并且逐漸搭建代碼框架。熟悉過程其實花費的時間和精力非常多，對于完全不清楚的結構，需要一點一點閱讀文檔，遇到不清楚的細節(jié)問題，還要聯(lián)系開發(fā)人員一點一點對齊，這是一個考驗耐心的過程。中科院軟件所團隊在整個開發(fā)過程中一直與其他各單位同事保持著緊密的溝通，幾乎每天都會組織會議一起討論研發(fā)方案，針對使用 HDI 的讀寫接口無法作用于目標芯片的問題，選擇采用 Linux 原生函數(shù)來進行適配解決，有效提升了進度。在完成了代碼的初步功能并驗證后，我們把本地適配好的代碼上傳提交到 OpenHarmony 代碼倉，期間還經(jīng)過了 CI 門禁的代碼編譯、代碼測試、代碼規(guī)范審查，有問題的部分會被修改直到通過審核。其中這個過程也相當考量細節(jié)，有可能代碼規(guī)范審查一下子就報幾百個規(guī)范問題或者警告，包括空格規(guī)范問題、換行規(guī)范問題、注釋規(guī)范問題、宏定義規(guī)范問題等問題，需要仔細地核對修改。最后經(jīng)過對代碼的不斷修正和驗證并將代碼整理到符合社區(qū)規(guī)范的狀態(tài)后，這些代碼成功合入到了主干。總的來說，這是各方一起通力合作的結果，完成了從進度跟蹤到任務分配再到技術問題攻堅的一系列問題的閉環(huán)。

Q5

在整個開發(fā)進程中，您和您的團隊遇到過哪些技術上或其他方面的難題？這些難題又是如何被逐一解決？在這些難題被解決的過程中，您總結了哪些寶貴的經(jīng)驗or教訓？

整個開發(fā)過程中主要有以下幾個困難點。第一，Dayu200 開發(fā)板的音頻芯片比較特殊，它包含 Codec、RTC、PMIC 等多種功能，不能簡單的采用 ADM 接口去操作它。為了避免影響到其他功能的正常運作，我們使用了原生 Linux 設備驅動接口來操作 I2C、I2S、DMA 的通信以及數(shù)據(jù)傳遞，避免了異常操作的風險。第二，播放一段時間后，停止播放，持續(xù)有尖銳的很小的聲音。針對此問題，我們注冊了 Trigger 函數(shù)，根據(jù)接收到狀態(tài)信息，如果為停止狀態(tài)，則對 Codec 相關器件進行下電。第三，RK 的音量調節(jié)功能必須要給左右聲道寄存器寫入相同數(shù)值才可生效，但當時框架還不支持對左右寄存器的賦值。后來，我們與框架開發(fā)人員協(xié)商，使得框架新增了該項功能，最終適配上了音量調節(jié)能力。

經(jīng)驗的話，就是一定要多去和不同的技術開發(fā)人員溝通交流，有時候可能會陷入思維定勢，常常不能發(fā)現(xiàn)自己代碼上的問題，而別人一眼就看到關鍵所在，直接指出來，那么問題就迎刃而解了。

Q6

加入OpenHarmony生態(tài)以來，您最大的驚喜是什么？或者有哪些具體的收獲？

加入 OpenHarmony 生態(tài)以來，我最大的驚喜是了解了開源社區(qū)的玩法，在 OpenHarmony 社區(qū)，可以從別人的代碼中學到更多知識，同時自己的代碼可以被更多人看到，好的地方不好的地方，都會有人提出來，在這種快速的反饋中，更能夠了解自己存在的不足。

我認為，這段時間充滿了收獲，首先是認識了很多志同道合的小伙伴，大家都積極參與開源項目，貢獻自己的代碼，開源之路本就荊棘叢生，有這么多開源社區(qū)的伙伴一起前行，路也好走了許多。其次是獲得了磨練與成長，在優(yōu)秀的人面前，你能看到差距，從而去學習別人的優(yōu)點；在優(yōu)秀的代碼面前，你能看到框架構思的差距，從而去學習別人的編碼思路，這確實讓人受益匪淺。

Q7

期待未來OpenHarmony哪些方面能夠得到改善、提供更多支持？

客觀的說，OpenHarmony 還存在有一些不足的地方，比如社區(qū)反映的入門資料較少、框架解析資料不夠清晰、issue 請求響應不太及時等問題。主要原因在這么幾個方面，一是 OpenHarmony 發(fā)展初期，它是國內(nèi)最前沿的大規(guī)模的開源系統(tǒng)，它的發(fā)展是摸著石頭過河的過程，必然會存在這樣或者那樣的沒有遇到過的問題，這是相當正常的；二是開發(fā)者技術水平和技術關注點存在差異，有的開發(fā)者可能需要更詳盡的入門資料來進入門檻，有的開發(fā)者可能關注底層驅動lib庫的編譯生成方式，有的開發(fā)者可能關注 OpenHarmony SDK 如何生成 hap 應用，不知道如何找到自己想要的開發(fā)資料；三是 OpenHarmony 每個代碼倉的管理相對獨立，由每個倉庫自己的 committer 進行管理，一方面很多開發(fā)者可能找不到正確的代碼倉來提 issue，另外一方面某些 committer 可能由于事務繁忙，沒有及時地回復 issue。我期待未來 OpenHarmony 能夠切實的引導開發(fā)者，根據(jù)他們的需求，提供對應的開發(fā)資料開發(fā)資源，并且能夠進一步加強與開發(fā)者的聯(lián)系，更多傾聽開發(fā)者的聲音，給予良性的有效的反饋。

Q8

OpenHarmony目前仍處在開發(fā)探索階段，很多共建單位和生態(tài)伙伴還不清楚開源項目的玩法，或不知該如何著手進行開發(fā)。可以請您給大家分享一條，您認為最重要或最值得分享的心得嗎？

我認為 OpenHarmony 是一個非常自由開放的項目，各家共建單位或生態(tài)伙伴可以根據(jù)自己的需求想法來進行選擇。如果想進行應用hap開發(fā)，可以參考 OpenHarmony 的 docs 倉下面的 JS 開發(fā)資料。如果是想進行開發(fā)板移植，可以參考 OpenHarmony 的 docs 倉下面的芯片移植資料，在此基礎上，如果想貢獻代碼，則可以聯(lián)系 OpenHarmony SIG 相關組織走代碼上倉的流程。至于開發(fā)上的問題，建議在 OpenHarmony 社區(qū)的 Zulip 上提問（https://zulip.openharmony.cn，未注冊用戶需要郵箱注冊），或者在研發(fā)討論群里面提問，或者是在相關代碼倉提 issue，總之，渠道是十分廣泛的。

審核編輯 ：李倩