編者按：在 OpenHarmony 生態發展程序中，涌現了大批優秀的代碼貢獻者，本專題旨在表彰貢獻、分享經驗，文中內容來自嘉賓訪談，不代表 OpenHarmony 作業委員會觀點，
趙海鵬
江蘇潤和軟體股份有限公司
資深軟體開發工程師
本期 OpenAtom OpenHarmony（以下簡稱“OpenHarmony”）開發者故事，我們特別采訪了 2 月代碼最佳貢獻者、一位接觸 OpenHarmony 1 年左右，2022 年初便完成高難度開發專案的開發者——潤和軟體資深軟體開發工程師趙海鵬，
趙海鵬是潤和 OpenHarmony 南向業務媒體領域負責人，主要承擔 Audio 開發作業，在 RK3568 平臺 Audio Driver Model 適配開發程序中，在突遇西安疫情的情況下，硬體和溝通問題都面臨巨大的挑戰，面對急迫性的專案需求，趙海鵬和他的伙伴迎難而上，通過各種渠道去協調設備，把做好的韌體寄送出去，協調軟體所的伙伴們做遠程測驗，包括焊接等等，幾乎每天在線作業及溝通 12 個小時以上，最終克服困難圓滿完成任務，
我們與趙海鵬一起聊了他加入 OpenHarmony 生態的初心、對 OpenHarmony 架構適配的理解、作業中遇到的難題和攻克的程序、以及開源程序的心得與教訓等話題，現將專訪內容整理如下，希望對你有所啟發，
Q=OpenHarmony A=趙海鵬
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 上運行，便于移植，但目前成熟度不夠，適配難度較高，對開發者來說不太友好，希望各共建單位和開源開發者一起去完善，讓平臺驅動適配更容易，
搜索
復制
轉載請註明出處，本文鏈接：https://www.uj5u.com/yidong/472418.html
標籤：其他
上一篇：iOS Widget