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