做開源鴻蒙開發(fā)繞不開的第一道門檻就是環(huán)境搭建。我拿小熊派nano這塊板子從頭到尾跑了一遍獲取源碼、編譯源碼的完整流程中間踩了不少坑最后整理出一套能直接照著抄的步驟。這篇文章不是貼一堆命令就完事的我會(huì)把每一步背后的原因、可能出的問題、排查方法都講清楚適合第一次接觸開源鴻蒙編譯環(huán)境的新手也適合編譯時(shí)遇到莫名其妙報(bào)錯(cuò)想快速定位的人。1. 開工之前先把環(huán)境和路線想清楚1.1 小熊派nano是塊什么板子小熊派nanoBearPi-Nano是一塊以 Hi3861V100 芯片為核心的物聯(lián)網(wǎng)開發(fā)板主打低成本和低門檻。它的定位非常明確不追求高性能而是讓開發(fā)者以很小的代價(jià)跑通一個(gè)真實(shí)的物聯(lián)網(wǎng)設(shè)備。板子上帶了 LED、按鍵、無源蜂鳴器接口、OLED 排座等常用外設(shè)配合 Type-C 供電拿來做傳感器數(shù)據(jù)采集、家居開關(guān)這種輕量級(jí)應(yīng)用非常順手。在開源鴻蒙生態(tài)里小熊派nano屬于輕量系統(tǒng)設(shè)備跑的是 LiteOS-M 內(nèi)核資源和標(biāo)準(zhǔn)系統(tǒng)完全不同。這意味著編譯方式、產(chǎn)物格式、燒錄方法都和手機(jī)/平板那種大系統(tǒng)有差異但在入門階段反而能讓你看清楚“源碼到固件”的完整鏈路?，F(xiàn)在網(wǎng)上大部分開源鴻蒙入門教程都拿它做示例說明這塊板子的適配代碼是相對(duì)成熟、可復(fù)現(xiàn)的。選擇開發(fā)板一定要清醒小熊派nano不是拿來看炫酷 UI 的它是用來理解系統(tǒng)級(jí)別的編譯、移植、驅(qū)動(dòng)、燒錄這些底層流程的。目標(biāo)如果是深入嵌入式應(yīng)用開發(fā)用它是非常合適的第一步。1.2 環(huán)境搭建的三條主流路線怎么選開源鴻蒙官方文檔大多以 Ubuntu 作為開發(fā)環(huán)境但開發(fā)者的實(shí)際宿主系統(tǒng)通常是 Windows。這里就有三條常見路線虛擬機(jī)、WSL、雙系統(tǒng)還有一條輔助路線 Docker。路線優(yōu)點(diǎn)缺點(diǎn)推薦度虛擬機(jī) Ubuntu與官方文檔一致、快照回滾方便、USB/串口透?jìng)鞒墒煺加觅Y源、磁盤性能打折扣最推薦WSL2啟動(dòng)快、和 Windows 文件互操作方便早期版本 I/O 慢、USB 串口透?jìng)髋渲脧?fù)雜可以但要折騰雙系統(tǒng) Linux性能最強(qiáng)、沒有虛擬化層干擾安裝分區(qū)有風(fēng)險(xiǎn)、切換系統(tǒng)麻煩進(jìn)階用Docker 容器純凈、可復(fù)現(xiàn)、適合 CI設(shè)備調(diào)試和燒錄不方便不推薦入門我自己的選擇是虛擬機(jī) Ubuntu 20.04。理由很實(shí)際官方文檔很多是拿這個(gè)環(huán)境做驗(yàn)證的你照著命令操作出錯(cuò)的概率最小。虛擬機(jī)快照功能特別適合環(huán)境搭建這種操作——每次做完一個(gè)關(guān)鍵節(jié)點(diǎn)就存一個(gè)快照后面搞崩了直接回滾不用重新下載幾十 GB 源碼。硬件配置上建議至少 4 核 CPU、8GB 內(nèi)存、60GB 可用磁盤。如果機(jī)器只有 4GB 內(nèi)存編譯時(shí)大概率會(huì)被 OOM 干掉后面我會(huì)講到用 swap 緩解的方案。1.3 我推薦的目錄規(guī)劃與系統(tǒng)版本系統(tǒng)方面我建議直接上 Ubuntu 20.04 LTS 64 位。雖然 22.04 也能跑但從實(shí)際踩坑經(jīng)歷看22.04 上會(huì)遇到更多“版本太新導(dǎo)致庫(kù)不兼容”的問題比如 libncurses5 裝不上、python3 版本過高引發(fā)工具鏈行為差異。20.04 是老牌穩(wěn)定環(huán)境等流程完全跑通之后再遷移到新版本也不遲。源碼目錄建議統(tǒng)一放在用戶主目錄下的~/openharmony不要放在/root不要放在中文路徑也不要放在 NTFS/FAT 這類跨文件系統(tǒng)掛載點(diǎn)。原因很簡(jiǎn)單后續(xù)編譯工具鏈會(huì)創(chuàng)建大量符號(hào)鏈接和中間文件跨文件系統(tǒng)經(jīng)常出現(xiàn) ln 失敗或權(quán)限錯(cuò)亂root 用戶生成的產(chǎn)物會(huì)讓普通用戶無法清理中文路徑則可能讓某些腳本崩潰。另外強(qiáng)烈建議完成基礎(chǔ)環(huán)境和源碼同步后立即給虛擬機(jī)做一次快照。源碼這個(gè)東西重新下載的時(shí)間成本極高快照一次等于給自己買了保險(xiǎn)。后面就算你把 hb 配置或 vendor 目錄改壞了回滾到快照也就幾分鐘的事。2. 基礎(chǔ)環(huán)境準(zhǔn)備把 Ubuntu 調(diào)教到能干活的狀態(tài)2.1 安裝基礎(chǔ)軟件包新裝的 Ubuntu 缺的東西很多先把編譯相關(guān)的依賴一次性裝齊sudo apt update sudo apt upgrade -y sudo apt install -y git curl wget unzip tar sudo apt install -y python3 python3-pip sudo apt install -y build-essential gcc g make sudo apt install -y libncurses5-dev zlib1g-dev flex bison libssl-dev sudo apt install -y gcc-multilib g-multilib這些包各司其職git是源碼同步的基礎(chǔ)curl/wget用來下載 repo 腳本和工具build-essential提供了最基礎(chǔ)的 C/C 編譯環(huán)境libncurses5-dev供內(nèi)核/系統(tǒng)層配置菜單使用flex和bison是詞法語(yǔ)法分析器很多編譯工具鏈生成代碼時(shí)會(huì)用到multilib系列提供 32 位兼容庫(kù)交叉編譯流程里調(diào)用 32 位宿主工具時(shí)離不開它。這里有個(gè)版本坑Ubuntu 22.04 之后默認(rèn)軟件源里已經(jīng)沒有l(wèi)ibncurses5-dev只提供libncurses-dev。遇到Unable to locate package libncurses5-dev時(shí)直接用libncurses-dev替代即可大部分場(chǎng)景下不影響。如果還缺個(gè)別依賴報(bào)錯(cuò)信息會(huì)明確提示用sudo apt install補(bǔ)上就行不用怕依賴問題缺哪個(gè)補(bǔ)哪個(gè)。2.2 配置 Python 和 Git開源鴻蒙的編譯腳本和 repo 工具都是 Python 寫的所以 Python 環(huán)境必須可靠。檢查當(dāng)前版本python3 --version建議 3.8 以上。20.04 自帶的是 Python 3.8符合要求。接下來升級(jí) pippython3 -m pip install --upgrade pip setuptools如果提示pip模塊不存在先執(zhí)行sudo apt install -y python3-pip。Git 配置是很多新手會(huì)漏掉的一步。repo 在操作一些 git 子命令時(shí)需要讀取用戶名和郵箱不配置的話同步源碼時(shí)會(huì)出現(xiàn)報(bào)錯(cuò)或卡住。提前做好git config --global user.name yourname git config --global user.email youexample.com用戶名郵箱隨便填只要格式合法即可不一定非得是真實(shí)信息。另外如果后續(xù)同步包含大文件倉(cāng)庫(kù)還需要安裝 git-lfssudo apt install -y git-lfs git lfs install某些固件、圖片、預(yù)編譯庫(kù)會(huì)以 LFS 方式存儲(chǔ)沒裝這個(gè)同步出來的文件會(huì)是一個(gè)幾百字節(jié)的指針文件而不是真正的二進(jìn)制內(nèi)容編譯時(shí)就會(huì)出現(xiàn)莫名其妙的“文件格式無法識(shí)別”錯(cuò)誤。2.3 安裝并驗(yàn)證 repo 工具repo 不是某個(gè)開源鴻蒙特有的工具它是業(yè)界常用的一套多倉(cāng)庫(kù)管理腳本用 manifest 文件把成百上千個(gè) Git 倉(cāng)庫(kù)組織到一起。開源鴻蒙源碼倉(cāng)庫(kù)數(shù)量非常多手動(dòng)逐個(gè) clone 不現(xiàn)實(shí)必須通過 repo 一鍵同步。安裝方式我推薦直接下載 Gitee 碼云上的 repo 腳本到用戶目錄mkdir -p ~/bin curl -s https://gitee.com/openharmony/misc/raw/master/tools/repo ~/bin/repo chmod ax ~/bin/repo echo export PATH$HOME/bin:$PATH ~/.bashrc source ~/.bashrc驗(yàn)證是否裝好repo version如果輸出類似repo version v2.32后面的信息說明可以用了。如果提示No such file or directory先檢查~/bin/repo文件是否存在再檢查第一行解釋器是python還是python3。這個(gè)問題我在下一節(jié)詳細(xì)說。另外不建議用發(fā)行版自帶的 repoapt install repo版本通常比較舊對(duì)源碼的 manifest 格式兼容性差我見過很多舊版 repo 在同步時(shí)直接報(bào)Unsupported manifest format。2.4 一個(gè)特別容易踩的坑python 和 python3 混用這個(gè)坑幾乎所有人都躲不過。你打開~/bin/repo看一眼腳本第一行很可能是#!/usr/bin/env python但 Ubuntu 20.04/22.04 默認(rèn)只安裝了python3沒有/usr/bin/python這個(gè)文件。執(zhí)行repo時(shí)系統(tǒng)解釋器找不到就會(huì)報(bào)No such file or directory或者更詭異的SyntaxError。解決辦法就是把系統(tǒng)缺的python軟鏈到python3sudo apt install -y python-is-python3裝完之后驗(yàn)證python --version能正常輸出版本號(hào)就沒問題了。這個(gè)軟鏈接不僅影響 repo源碼里很多子腳本、編譯工具也會(huì)用到python命令所以提前處理好能省掉后續(xù)一大半 Python 相關(guān)的幺蛾子。如果安裝后仍報(bào)缺什么 Python 模塊先看報(bào)錯(cuò)里的模塊名一般就是requests、setuptools之類的用 pip 裝上即可python3 -m pip install requests setuptools3. 獲取源碼repo init repo sync 的完整流程3.1 版本分支怎么選獲取源碼之前必須先決定用哪個(gè)分支。開源鴻蒙的倉(cāng)庫(kù)用分支和 tag 管理版本常見的有這么幾類master 主線代碼最新功能推進(jìn)快但變動(dòng)也快今天能編的代碼下周可能因?yàn)槟硞€(gè)倉(cāng)的改動(dòng)就編不了。OpenHarmony-3.0-LTS長(zhǎng)期支持版本資源適配較全教程資料最豐富是小熊派nano入門的首選。OpenHarmony-3.1-Release/4.0-Release 等功能更多但板級(jí)適配需要自己確認(rèn)部分流程和 3.0 有差異。我強(qiáng)烈建議新手先鎖死 3.0-LTS。小熊派nano的官方適配代碼在這個(gè)分支上是完整的網(wǎng)上絕大多數(shù)教程也基于它遇到問題能對(duì)照參考。用 master 或 4.x 也不是不行但那是已經(jīng)有經(jīng)驗(yàn)、能自己排查時(shí)才做的事。版本選擇直接決定后面的編譯命令和產(chǎn)物內(nèi)容一步選錯(cuò)就多浪費(fèi)好幾個(gè)小時(shí)。分支選擇可以參考這個(gè)表分支適合人群穩(wěn)定程度小熊派nano適配master想追新特性、做社區(qū)貢獻(xiàn)低需確認(rèn)OpenHarmony-3.0-LTS新手入門、復(fù)現(xiàn)教程高官方完整OpenHarmony-4.0-Release想體驗(yàn)新 API中需手動(dòng)確認(rèn)3.2 初始化倉(cāng)庫(kù)與同步代碼確定分支之后開始正式拉取源碼。先建目錄并進(jìn)入mkdir -p ~/openharmony cd ~/openharmony repo init -u https://gitee.com/openharmony/manifest.git -b OpenHarmony-3.0-LTS這個(gè)過程很快它不下載源碼本體只是從 manifest 倉(cāng)庫(kù)讀取一份配置文件——這份文件告訴 repo項(xiàng)目有哪些子倉(cāng)庫(kù)、每個(gè)倉(cāng)庫(kù)的路徑、遠(yuǎn)程地址、當(dāng)前該 checkout 哪個(gè) commit。執(zhí)行成功后目錄下會(huì)出現(xiàn).repo隱藏目錄里面是后續(xù)同步的元數(shù)據(jù)和 remote 配置這個(gè)目錄不能刪也不要去手工改動(dòng)它。真正的下載動(dòng)作是repo syncrepo sync -c -j4-c表示只同步當(dāng)前分支的代碼大幅減少數(shù)據(jù)量-j4表示并發(fā) 4 個(gè)倉(cāng)庫(kù)同時(shí)拉取。初次下載用時(shí)取決于網(wǎng)絡(luò)環(huán)境正常在十幾分鐘到一小時(shí)之間。如果家里網(wǎng)絡(luò)不好可以降到-j2慢一點(diǎn)但失敗率明顯下降。同步中途斷網(wǎng)也是常事不用慌再次執(zhí)行同一條命令repo 會(huì)接著上次的進(jìn)度繼續(xù)下載而不是從零開始。如果發(fā)現(xiàn)命令卡在某個(gè)倉(cāng)庫(kù)好久不動(dòng)可以 CtrlC 后重試一般不會(huì)有嚴(yán)重的殘留問題。3.3 同步完成后要做什么檢查同步完成不等于萬(wàn)事大吉先花兩分鐘檢查ls ~/openharmony repo info | head -30 du -sh ~/openharmony頂層目錄應(yīng)該能看到build、device、kernel、vendor、third_party、foundation、applications等核心目錄。如果某個(gè)目錄缺失或者明顯過小說明同步時(shí)有倉(cāng)庫(kù)沒拉完整需要再跑一次repo sync -c -j4。repo info會(huì)打印所有倉(cāng)庫(kù)的狀態(tài)可以順便看有幾行error或uninitialized有異常就先補(bǔ)拉。du -sh只是讓你對(duì)體積有個(gè)數(shù)輕量系統(tǒng)源碼加倉(cāng)庫(kù)元數(shù)據(jù)通常 20G 左右過小說明中途失敗了。如果倉(cāng)庫(kù)配置了 LFS 大文件還需要執(zhí)行repo forall -c git lfs pull確保二進(jìn)制大文件已經(jīng)真正落盤。這一步不做后面編譯到鏈接固件時(shí)經(jīng)常會(huì)報(bào)“文件太短”或者invalid ELF header非?？?。3.4 小熊派nano板級(jí)代碼的補(bǔ)充獲取這一步取決于你用的分支。在 3.0-LTS 里小熊派nano的板級(jí)適配通常已經(jīng)隨源碼帶下來了驗(yàn)證方法很簡(jiǎn)單ls ~/openharmony/vendor/bearpi/bearpi_hm_nano ls ~/openharmony/device/bearpi/bearpi_hm_nano兩個(gè)目錄下能看到config.json、build.gni、hals之類的文件說明適配代碼齊全。如果目錄為空或不存在說明當(dāng)前分支沒有內(nèi)置小熊派nano適配需要從社區(qū)倉(cāng)庫(kù)手動(dòng)補(bǔ)充。具體地址以該分支官方文檔為準(zhǔn)大體是cd ~/openharmony/vendor git clone bearpi_nano倉(cāng)庫(kù)地址 bearpi/bearpi_hm_nano cd ~/openharmony/device git clone bearpi_nano倉(cāng)庫(kù)地址 bearpi/bearpi_hm_nano注意兩個(gè)目錄放的內(nèi)容不同vendor 下是產(chǎn)品級(jí)配置、裁剪方案和編譯腳本device 下是芯片相關(guān)的驅(qū)動(dòng)和 BSP。缺了任何一個(gè)后續(xù)hb set都看不到小熊派nano這個(gè)產(chǎn)品選項(xiàng)或者編譯到一半報(bào)設(shè)備相關(guān)文件找不到。還有一種情況是倉(cāng)庫(kù)里自帶了構(gòu)建腳本會(huì)在編譯時(shí)自動(dòng)從固定地址拉取 SDK那樣你就不用手動(dòng)操作但要保證網(wǎng)絡(luò)能正常訪問那個(gè)地址。我見過多人因?yàn)橹?clone 了主倉(cāng)沒處理 SDK導(dǎo)致編譯時(shí)中斷現(xiàn)象和缺文件一模一樣。3.5 網(wǎng)絡(luò)中斷和速度慢的應(yīng)對(duì)寫到這里必須說實(shí)話源碼同步是最容易讓人心態(tài)爆炸的一步問題幾乎都是網(wǎng)絡(luò)引起的。我的經(jīng)驗(yàn)是先別急著用高并發(fā)新手從-j4開始跑通了再嘗試-j8。并發(fā)太高只會(huì)讓每個(gè)請(qǐng)求都在排隊(duì)反而容易觸發(fā)超時(shí)。如果某個(gè)倉(cāng)庫(kù)反復(fù)fatal: unable to access可以單獨(dú)進(jìn)入對(duì)應(yīng)目錄手動(dòng)git fetch看看網(wǎng)絡(luò)是否暢通但更省事的辦法是直接重試repo sync -c -j2錯(cuò)峰執(zhí)行例如放在后半夜。Gitee 碼云的服務(wù)質(zhì)量整體靠譜大部分超時(shí)是本地網(wǎng)絡(luò)波動(dòng)導(dǎo)致的短期問題多試幾次往往就過去了。另外提醒一句不要在.repo目錄里手動(dòng)刪文件來“修復(fù)”repo 的狀態(tài)記錄和 manifest 是配套的手動(dòng)刪了可能引發(fā)后續(xù)所有倉(cāng)庫(kù)重同步。真到了不可恢復(fù)的地步寧可把~/openharmony刪掉重新下載也別在那手工瞎改。4. 編譯環(huán)境搭建hb 工具鏈安裝與配置4.1 hb 工具是什么為什么要單獨(dú)裝源碼準(zhǔn)備好之后還需要一個(gè)命令行工具來驅(qū)動(dòng)編譯它就是 hbOpenHarmony build。通俗理解hb 是開源鴻蒙的“編譯管家”它讀取你選定的產(chǎn)品配置調(diào)用底層 gn/ninja 工具鏈批量編譯所有模塊最后把鏡像和固件整合出來。你不需要手動(dòng)一個(gè)個(gè)模塊去 make只要告訴 hb“編哪個(gè)產(chǎn)品”。為什么需要單獨(dú)安裝因?yàn)?hb 不在系統(tǒng)軟件源里也不是預(yù)編譯的二進(jìn)制它就藏在源碼build/lite目錄下本質(zhì)是一個(gè) Python 包。官方設(shè)計(jì)是讓你在獲取源碼后用setup.py把 hb 裝到當(dāng)前用戶環(huán)境里。這也是新手最容易困惑的地方——總以為編譯工具鏈?zhǔn)?apt 裝的其實(shí)一半是源碼自帶一半是本地安裝。舊版源碼比如 1.x用的是python build.py -p bearpi_hm_nano這種方式直接跑腳本。從 3.0 開始流程統(tǒng)一到了 hb所以網(wǎng)上教程新舊混雜很容易讓人懵。先看源碼里有沒有build/lite/setup.py有就該用 hb 流程。4.2 安裝 hb 工具的完整步驟安裝前先確認(rèn) setuptools 可用sudo apt install -y python3-setuptools然后進(jìn)入build/lite目錄執(zhí)行安裝命令cd ~/openharmony/build/lite python3 setup.py install --user這里的--user參數(shù)很關(guān)鍵只安裝到當(dāng)前用戶目錄不需要 root也不污染系統(tǒng) Python 環(huán)境。即使你只有一個(gè)開發(fā)用戶也建議用這種方式后續(xù)升級(jí)或者卸載都干凈很多。安裝完成后hb 的可執(zhí)行文件會(huì)放在$HOME/.local/bin需要手動(dòng)加入 PATHexport PATH$HOME/.local/bin:$PATH echo export PATH$HOME/.local/bin:$PATH ~/.bashrc source ~/.bashrc驗(yàn)證是否成功hb help能看到幫助信息就說明安裝完成。如果提示ModuleNotFoundError: No module named hb先檢查是否在build/lite目錄下執(zhí)行的 setup.py再確認(rèn)安裝過程沒有報(bào)錯(cuò)最后用python3 -m pip list | grep hb看看包是否真的裝上。很多時(shí)候只是 PATH 沒配置hb 其實(shí)已經(jīng)裝在系統(tǒng)里了。4.3 配置環(huán)境變量并驗(yàn)證hb 安裝好之后正式編譯前先要認(rèn)識(shí)源碼根目錄。進(jìn)入源碼根目錄執(zhí)行cd ~/openharmony hb set這是交互式命令會(huì)列出所有已發(fā)現(xiàn)的開發(fā)板產(chǎn)品。選擇列表里的bearpi_hm_nano即可。如果不想用交互菜單也可以直接指定hb set -root ~/openharmony hb set -p bearpi_hm_nano-root把當(dāng)前源碼目錄設(shè)為根目錄-p直接把產(chǎn)品設(shè)為小熊派nano。執(zhí)行完可以用hb env查看當(dāng)前編譯環(huán)境hb env輸出里應(yīng)該有 root、product、device_path、kernel 等信息。重點(diǎn)看 product 是不是bearpi_hm_nano再看 device_path 是否指向device/bearpi/bearpi_hm_nano。如果這里顯示的 device_path 是空的說明板級(jí)適配代碼沒有識(shí)別到回到 3.4 節(jié)檢查 vendor/device 目錄。此時(shí)應(yīng)該養(yǎng)成一個(gè)習(xí)慣把 PATH 和 root 相關(guān)配置寫進(jìn).bashrc不要每次開終端重敲。我見過太多人編譯前忘了source ~/.bashrc然后 hb 一直 not found其實(shí)不是環(huán)境壞了只是新終端沒加載配置。4.4 編譯依賴確認(rèn) gn、ninja 和工具鏈在不在hb 只是調(diào)度器真正干活的是 gn、ninja、編譯器。這些一般在源碼自帶的prebuilts目錄里。檢查ls ~/openharmony/prebuilts正常能看到很多工具鏈目錄。如果這個(gè)目錄不存在或者內(nèi)容是空的大概率是同步不完整或者你手動(dòng)刪過文件。工具鏈缺失的癥狀很典型編譯一開始就報(bào)ninja: command not found或gn: No such file or directory。這時(shí)不要自己去 apt 裝 gn/ninja版本對(duì)不上反而更亂正確做法是檢查源碼倉(cāng)庫(kù)完整性重新同步對(duì)應(yīng)倉(cāng)庫(kù)。編譯器方面開源鴻蒙的交叉編譯工具鏈也放在 prebuilts不依賴系統(tǒng) gcc。但編譯某些宿主工具時(shí)還會(huì)用到系統(tǒng)的 gcc/g所以第 2 章里的依賴包仍然要裝。5. 編譯源碼從 hb build 到拿到燒錄固件5.1 第一次編譯前必須檢查的項(xiàng)真正按下編譯按鈕前花 5 分鐘逐項(xiàng)檢查能避免一大半莫名其妙的失敗磁盤空間df -h /home至少預(yù)留 10GB。編譯產(chǎn)物在out目錄輕量系統(tǒng)全量編譯后也有好幾個(gè) GB。源碼屬主ls -ld ~/openharmony確保目錄所有者是當(dāng)前用戶。如果之前用 sudo 創(chuàng)建或修改過某些文件后續(xù)編譯會(huì)因權(quán)限不一致報(bào)錯(cuò)。修復(fù)命令sudo chown -R $USER:$USER ~/openharmony。Python 軟鏈接python --version必須能正常輸出如果 no such file 就去裝 python-is-python3。hb 可用性which hb能打印路徑才行。內(nèi)存余量free -h。如果內(nèi)存只有 4G 左右非常建議先加 swap。快速加 swap 的方法sudo fallocate -l 8G /swapfile sudo chmod 600 /swapfile sudo mkswap /swapfile sudo swapon /swapfile加完 swap 能顯著降低編譯中途被 OOM Kill 的概率。注意/swapfile的路徑和權(quán)限是硬要求權(quán)限不對(duì)內(nèi)核會(huì)拒絕使用。5.2 執(zhí)行編譯與日志閱讀確認(rèn)無誤后執(zhí)行全量編譯cd ~/openharmony hb build -f 21 | tee build.log-f表示強(qiáng)制全量編譯。第一次編譯必須全量因?yàn)?out 目錄里什么都沒有。編譯過程會(huì)大量刷日志這時(shí)不要干等學(xué)會(huì)看日志關(guān)注最后的輸出是否有build success字樣。出錯(cuò)時(shí)搜索error:或Error:直接定位到第一個(gè)錯(cuò)誤通常真正的錯(cuò)誤在第一個(gè)后面一連串都是連鎖反應(yīng)。日志落盤到build.log后可以用grep -i error build.log | head -30快速梳理。編譯時(shí)長(zhǎng)方面四核八線程的虛擬機(jī)第一次全量大約 15 到 30 分鐘取決于磁盤性能和 CPU。如果中途 Killed先加 swap 再重跑如果中途某個(gè)模塊報(bào)錯(cuò)把報(bào)錯(cuò)信息連同 hb 版本一起搜索基本都有答案。編譯成功后再次編譯時(shí)直接用hb build不帶 -f走增量編譯ninja 只重編改動(dòng)過的模塊通常幾秒到幾十秒就結(jié)束了。5.3 編譯產(chǎn)物在哪里怎么確認(rèn)成功編譯完成后小熊派nano的固件產(chǎn)物一般在ls -lh ~/openharmony/out/bearpi_hm_nano/BearPi-HM_Nano/這個(gè)目錄下會(huì)出現(xiàn)幾個(gè)關(guān)鍵文件Hi3861_wifiiot_app_allinone.bin可以直接燒錄的全量固件這是你最需要的東西。Hi3861_wifiiot_app.elf帶符號(hào)的調(diào)試文件調(diào)試崩潰問題時(shí)用。Hi3861_wifiiot_app.map內(nèi)存布局圖分析內(nèi)存占用時(shí)看它。判斷編譯是否成功除了看日志里的build success還要看 bin 文件的大小和時(shí)間戳。文件時(shí)間應(yīng)該是最新時(shí)刻大小正常在幾百 KB 到 1MB 級(jí)別。如果看到 0 字節(jié)或者時(shí)間戳是幾天前的說明這次編譯實(shí)際沒寫出新固件。拿到 bin 之后就可以連接串口燒錄到板子了。具體燒錄流程不是本文重點(diǎn)我只提兩個(gè)關(guān)鍵點(diǎn)一是燒錄前通常需要讓開發(fā)板進(jìn)入下載模式多數(shù)做法是按住 BOOT 鍵再上電二是串口驅(qū)動(dòng)和波特率設(shè)置要按官方文檔來不同板子的 boot 邏輯有細(xì)微差別。5.4 常見編譯錯(cuò)誤與解決速查表把我在實(shí)際過程中遇到以及幫別人排查過的典型問題整理成一張表方便對(duì)照?qǐng)?bào)錯(cuò)/現(xiàn)象大概率原因解決辦法hb: command not foundhb 未安裝或 PATH 未加載重新執(zhí)行python3 setup.py install --user并把$HOME/.local/bin寫進(jìn)~/.bashrcNo module named hbsetup.py 沒裝成功確保在build/lite下安裝先升級(jí) pip 和 setuptools 再重試No product found板級(jí)適配代碼缺失或產(chǎn)品名寫錯(cuò)檢查vendor/bearpi/bearpi_hm_nano和device/bearpi/bearpi_hm_nano確認(rèn)名字大小寫python: No such file or directory系統(tǒng)缺少python軟鏈接sudo apt install -y python-is-python3編譯中途 Killed內(nèi)存不足增加 swap、關(guān)閉 GUI、暫時(shí)降低并行任務(wù)磁盤寫滿out 目錄或源碼太大df -h找空間清理舊 out擴(kuò)展虛擬磁盤invalid ELF header/ 文件太短LFS 大文件未拉取repo forall -c git lfs pullninja/gn not foundprebuilts 不完整重新同步源碼不要用 apt 安裝替代權(quán)限錯(cuò)誤導(dǎo)致編譯失敗源碼樹被 root 所有sudo chown -R $USER:$USER ~/openharmony這張表不敢說覆蓋所有問題但覆蓋了新手 90% 的場(chǎng)景。遇到?jīng)]見過的錯(cuò)誤先看第一個(gè) error 出現(xiàn)的位置不要被后面幾十行刷屏嚇住很多時(shí)候錯(cuò)誤原因就藏在前三行。6. 編譯之后的收尾工作與經(jīng)驗(yàn)總結(jié)6.1 完整流程為什么要從頭到尾做一遍環(huán)境搭建這件事表面上是在配置工具實(shí)際上是在建立“源碼管理 構(gòu)建系統(tǒng) 板級(jí)適配”三者關(guān)系的全局觀。只復(fù)制命令不思考換個(gè)分支、換個(gè)板子就又不會(huì)了。我強(qiáng)烈建議新手至少手動(dòng)完整跑一遍不要用任何一鍵腳本把每一句命令的作用在筆記里寫下來。我第一次跑通整個(gè)流程的最大感受是問題基本都出在“環(huán)境依賴”而不是“代碼邏輯”上。源碼本身絕大多數(shù)情況是沒問題的編譯不過大多是 Python 軟鏈接缺失、vendor 目錄沒放對(duì)、磁盤空間不夠這類小事。把這些前置條件理順了后面寫業(yè)務(wù)代碼才有意義。另外建議把常用的編譯命令整理成一個(gè)可復(fù)用的腳本比如build.sh內(nèi)容大致如下#!/bin/bash source ~/.bashrc cd ~/openharmony || exit 1 hb build -f 21 | tee build.log放在源碼目錄外省得每次敲長(zhǎng)命令。腳本第一行必須先 source 環(huán)境否則 PATH 可能沒加載 hb。6.2 新手最容易忽略的3個(gè)細(xì)節(jié)第一個(gè)細(xì)節(jié)是權(quán)限。很多教程會(huì)順手寫sudo比如sudo repo sync、sudo python3 setup.py一旦源碼樹某些文件變成 root 所有后續(xù)當(dāng)前用戶編譯就會(huì)碰到各種 Permission denied。我的原則是除了apt install需要 sudo源碼目錄內(nèi)的一切操作都用普通用戶已經(jīng)出問題的用 chown 一次性修復(fù)。第二個(gè)細(xì)節(jié)是新終端的環(huán)境變量。hb 配置寫入.bashrc之后所有新開的終端都會(huì)自動(dòng)生效但如果你用了終端里的“標(biāo)簽頁(yè)復(fù)制”或某些特殊 shell可能沒有執(zhí)行完整 profile這時(shí)手動(dòng)source ~/.bashrc即可。不要一看到 not found 就急著重裝 hb先 which 一下看路徑。第三個(gè)細(xì)節(jié)是增量編譯與全量編譯的分工。日常只改了應(yīng)用或驅(qū)動(dòng)代碼用hb build增量就行如果修改了產(chǎn)品級(jí)配置、vendor 目錄結(jié)構(gòu)、內(nèi)核裁剪選項(xiàng)再用hb build -f全量重新來。盲目全量不僅浪費(fèi)時(shí)間還會(huì)掩蓋真正的問題因?yàn)槿罩咎嗔恕?.3 最后分享一個(gè)小技巧我現(xiàn)在的做法是在主目錄下維護(hù)一個(gè)env.sh集中管理所有開發(fā)環(huán)境變量export PATH$HOME/bin:$HOME/.local/bin:$PATH export OHOS_SOURCE_ROOT~/openharmony每次進(jìn)入新終端先source ~/env.sh不管切到哪個(gè)項(xiàng)目都能快速定位。配合alias hbbcd $OHOS_SOURCE_ROOT hb build -f這樣的別名操作效率會(huì)高很多。這個(gè)小習(xí)慣算不上什么高深技術(shù)但對(duì)長(zhǎng)期做嵌入式開發(fā)的人來說能省下大量重復(fù)勞動(dòng)?？赐暾琢鞒棠憔蜁?huì)發(fā)現(xiàn)小熊派nano的環(huán)境搭建并不復(fù)雜難的是那些零散的、文檔里不會(huì)細(xì)講的系統(tǒng)細(xì)節(jié)。把路徑、權(quán)限、版本差異、命令工具這幾件事先理順后面編譯源碼的過程其實(shí)是很順利的。希望你也能順利跑通在“拿到固件”的那一刻前面所有的折騰都值了。