簡(jiǎn)介這是一份基于Arm與Qt的C智能車(chē)載系統(tǒng)完整源碼適合嵌入式開(kāi)發(fā)者、Qt界面程序?qū)W習(xí)者以及需要畢業(yè)設(shè)計(jì)參考的本科生。系統(tǒng)實(shí)現(xiàn)了天氣預(yù)報(bào)、音樂(lè)播放器、視頻播放器、倒車(chē)?yán)走_(dá)、行車(chē)記錄儀、多語(yǔ)言切換等功能核心模塊均利用Qt C完成綜合展示UI設(shè)計(jì)、多線程/定時(shí)刷新與底層驅(qū)動(dòng)交互。壓縮包共116個(gè)文件大小11.23MB主要包含cpp/h源文件、ui界面描述、png資源圖、m4a音頻、makefile構(gòu)建腳本以及qm/ts多語(yǔ)言翻譯文件和so動(dòng)態(tài)庫(kù)并附有ARM平臺(tái)驅(qū)動(dòng)代碼便于理解上層功能與硬件驅(qū)動(dòng)的銜接。目前已有1510人學(xué)習(xí)下載。借助這套源碼可掌握Qt項(xiàng)目工程結(jié)構(gòu)、各功能模塊的拆分方法與ARM環(huán)境下的交叉編譯思路直接參考或在此基礎(chǔ)上擴(kuò)展能顯著縮短車(chē)載系統(tǒng)類(lèi)畢業(yè)設(shè)計(jì)的開(kāi)發(fā)周期。1. 把“智能車(chē)載系統(tǒng)”從畢業(yè)設(shè)計(jì)做成可上車(chē)的工程C、Arm和Qt怎么分工“智能車(chē)載系統(tǒng)”這個(gè)詞落在 C 本科畢業(yè)設(shè)計(jì)里最常踩的坑是功能做出來(lái)了換一塊 Arm 板子就起不來(lái)或者 UI 和業(yè)務(wù)邏輯全塞在一個(gè)線程一接 CAN 數(shù)據(jù)界面就掉幀。用 C、Qt 加 Arm 做車(chē)載方案不是因?yàn)檫@套組合聽(tīng)起來(lái)夠“嵌入式”而是它能覆蓋從開(kāi)發(fā)機(jī)到目標(biāo)板的完整鏈路Q(chēng)t 負(fù)責(zé)跨平臺(tái) UIC 負(fù)責(zé)在幾十毫秒內(nèi)把總線數(shù)據(jù)、傳感器信息轉(zhuǎn)成界面能直接綁定的屬性Arm 則是這套系統(tǒng)最終跑在上面的低功耗硬件底座。這篇文章面向兩類(lèi)人拿它當(dāng) C 畢業(yè)設(shè)計(jì)、想把“能跑”變成“能演示”的學(xué)生以及剛接手車(chē)載域控制器、需要把代碼從 x86 遷到 Arm 的工程師。后面所有內(nèi)容都圍繞一條主線先把架構(gòu)拆對(duì)再談怎么交叉編譯、怎么調(diào)參最后解決上車(chē)前的驗(yàn)證問(wèn)題。2. 先立框架為什么車(chē)載系統(tǒng)需要“Qt 做臉、C 做腦、Arm 做底”2.1 QML 與 C 的分層邊界誰(shuí)的數(shù)據(jù)不能跑在 UI 線程車(chē)載系統(tǒng)的典型界面包括儀表盤(pán)、中控導(dǎo)航、空調(diào)面板、倒車(chē)影像其中儀表盤(pán)對(duì)刷新率要求最高速度表指針的更新要求通常在 30fps 以上。Qt 里做這類(lèi)界面有兩種路線傳統(tǒng) Widgets 和 QML。Widgets 適合表單密集型界面控件樹(shù)復(fù)雜但自定義繪制時(shí)性能和代碼量都不占優(yōu)QML 用聲明式語(yǔ)法描述界面動(dòng)畫(huà)、漸變、圓角這些效果交給 Scene Graph 渲染CPU 占用遠(yuǎn)低于 Widgets 的 QPainter 重繪。智能車(chē)載系統(tǒng)里大量存在“數(shù)值變化帶動(dòng)視覺(jué)反饋”的場(chǎng)景QML 的屬性綁定天然適配所以主界面我一般建議用 QML 做C 只做數(shù)據(jù)層。分層要守住一條紅線UI 線程里不能出現(xiàn)阻塞調(diào)用。CAN 總線上一條報(bào)文周期可能是 10ms如果直接在界面線程里解析、查表、寫(xiě)日志任一環(huán)節(jié)耗時(shí)超過(guò)一幀界面就開(kāi)始卡。常見(jiàn)做法是開(kāi)一個(gè)獨(dú)立的采集線程負(fù)責(zé)從 CAN/串口讀取原始字節(jié)解析成結(jié)構(gòu)體再通過(guò)信號(hào)槽機(jī)制把結(jié)果拋給 QML 層QML 端只負(fù)責(zé)把屬性變化渲染出來(lái)。這樣即使總線出現(xiàn)大量錯(cuò)誤幀也只會(huì)積壓在隊(duì)列里界面不受影響。Qt 里實(shí)現(xiàn)這種隔離依賴(lài)一個(gè)核心機(jī)制信號(hào)槽。QObject::connect 連接信號(hào)和槽時(shí)如果不指定連接類(lèi)型Qt 會(huì)根據(jù)信號(hào)發(fā)送線程和接收者所在線程自動(dòng)選擇直連還是隊(duì)列連接?？缇€程時(shí)使用隊(duì)列連接信號(hào)參數(shù)會(huì)被復(fù)制一份投遞到接收者的事件循環(huán)中執(zhí)行。這意味著傳給信號(hào)的自定義數(shù)據(jù)結(jié)構(gòu)必須是可復(fù)制的并且要通過(guò) qRegisterMetaType 注冊(cè)否則編譯能過(guò)、運(yùn)行時(shí)報(bào)錯(cuò)。struct CanFrameData { uint32_t canId; uint8_t data[8]; uint8_t dlc; uint64_t timestampMs; }; Q_DECLARE_METATYPE(CanFrameData) // 在 main.cpp 中注冊(cè)一次 qRegisterMetaTypeCanFrameData(CanFrameData);不注冊(cè)的話connect 執(zhí)行到運(yùn)行時(shí)會(huì)出現(xiàn)“QObject::connect: Cannot queue arguments of type CanFrameData”的警告信號(hào)直接丟棄。開(kāi)發(fā)車(chē)載系統(tǒng)的數(shù)據(jù)層時(shí)務(wù)必把自定義報(bào)文結(jié)構(gòu)統(tǒng)一集中到一個(gè)頭文件里所有線程間傳遞的數(shù)據(jù)都從這份定義走避免每個(gè)模塊各自定義一份“長(zhǎng)得一樣但類(lèi)型不同”的結(jié)構(gòu)體。2.2 信號(hào)槽在跨線程連接下回調(diào)時(shí)機(jī)的實(shí)際行為很多用 Qt 做嵌入式開(kāi)發(fā)的初學(xué)者對(duì)跨線程信號(hào)槽的理解停留在“信號(hào)發(fā)出槽函數(shù)會(huì)自動(dòng)執(zhí)行”這一層但實(shí)際上槽函數(shù)的執(zhí)行線程、執(zhí)行時(shí)機(jī)和返回值行為都有嚴(yán)格規(guī)則。下表把四種連接類(lèi)型的差異列出來(lái)這對(duì)排查界面卡死和數(shù)據(jù)丟失非常關(guān)鍵。連接類(lèi)型槽在哪個(gè)線程執(zhí)行是否阻塞發(fā)送線程能否拿到槽返回值DirectConnection發(fā)送線程當(dāng)前線程阻塞可以QueuedConnection接收者線程不阻塞拿不到靜態(tài)分派丟棄AutoConnection默認(rèn)根據(jù)收發(fā)線程是否相同自動(dòng)判斷跨線程時(shí)不阻塞跨線程時(shí)拿不到BlockingQueuedConnection接收者線程阻塞發(fā)送線程直至槽完成可以AutoConnection 是最常用的默認(rèn)值但它有一個(gè)隱蔽的坑槽函數(shù)如果不允許參數(shù)以非 const 引用傳遞隊(duì)列連接會(huì)復(fù)制參數(shù)如果槽想通過(guò)非 const 引用改參數(shù)值第二次連接就會(huì)報(bào) static assertion。在工作中我見(jiàn)過(guò)不止一次有人想用跨線程信號(hào)槽索取結(jié)果直接寫(xiě)成普通 connect 引用參數(shù)結(jié)果編譯失敗或數(shù)據(jù)不變。如果確實(shí)需要同步調(diào)用跨線程對(duì)象的方法拿返回值正確姿勢(shì)是用 QMetaObject::invokeMethod并顯式指定 BlockingQueuedConnectionQString currentGear; QMetaObject::invokeMethod(gearController, currentGear, Qt::BlockingQueuedConnection, Q_RETURN_ARG(QString, currentGear));這段代碼會(huì)等待 gearController 所在線程處理完 currentGear() 槽函數(shù)并把返回值寫(xiě)進(jìn) currentGear 才繼續(xù)執(zhí)行。注意發(fā)送者線程絕對(duì)不能和接收者線程是同一個(gè)線程池里的同一個(gè)線程否則會(huì)死鎖。車(chē)載系統(tǒng)里這種調(diào)用通常只在“用戶(hù)切擋需要立刻刷新?tīng)顟B(tài)”時(shí)用頻繁調(diào)用會(huì)阻塞采集線程設(shè)計(jì)時(shí)應(yīng)盡量避免。2.3 用結(jié)構(gòu)體 QByteArray 構(gòu)建 CAN 幀解析層CAN 報(bào)文的裸數(shù)據(jù)是字節(jié)流直接 memcpy 成結(jié)構(gòu)體在 x86 和 Arm 上都有字節(jié)序風(fēng)險(xiǎn)。業(yè)界常見(jiàn)做法是定義一套帶字節(jié)序轉(zhuǎn)換的解析宏或工具函數(shù)先用移位拼接出標(biāo)準(zhǔn)字節(jié)序再填充結(jié)構(gòu)體。下面是一個(gè)從 QByteArray 解析 Intel 格式 CAN 幀的例子這種格式在車(chē)載總線里最常見(jiàn)即低字節(jié)在前。static uint16_t parse_le16(const QByteArray buf, int offset) { return static_castuint16_t(buf[offset]) | (static_castuint16_t(buf[offset 1]) 8); } CanData parseCanFrame(const QByteArray raw) { CanData out; out.canId static_castuint32_t(raw[0]) | (static_castuint32_t(raw[1]) 8) | (static_castuint32_t(raw[2]) 16) | (static_castuint32_t(raw[3]) 24); out.dlc raw[4]; out.speed parse_le16(raw, 5); // 車(chē)速單位 0.01 km/h out.rpm parse_le16(raw, 7); // 轉(zhuǎn)速單位 1 rpm return out; }這里手動(dòng)用小端解析而不是直接 reinterpret_cast是因?yàn)?CAN 幀可能存在跨字節(jié)的位域比如某個(gè)信號(hào)占用 12 bit會(huì)跨越兩個(gè)字節(jié)的邊界。位域結(jié)構(gòu)體在 C 標(biāo)準(zhǔn)里對(duì)內(nèi)存布局規(guī)定得很模糊編譯器可能插入填充同一個(gè)結(jié)構(gòu)體在 GCC 和 Clang 下布局也可能不一致。抓數(shù)據(jù)協(xié)議時(shí)把信號(hào)定義整理成“起始字節(jié)、起始位、長(zhǎng)度、縮放系數(shù)、偏移量”一張表比寫(xiě)死結(jié)構(gòu)體更保險(xiǎn)。3. 核心模塊落地儀表繪制、車(chē)輛狀態(tài)路由、配置持久化3.1 速度表和轉(zhuǎn)速表的 QML 繪制如何做到 60fps儀表盤(pán)是車(chē)載系統(tǒng)里辨識(shí)度最高的部分答辯時(shí)也是視覺(jué)亮點(diǎn)。QML 繪制儀表有兩種方式用 Canvas 元素手動(dòng)畫(huà)弧線或用 Shape 元素聲明矢量路徑。Canvas 每次重繪都會(huì)走一次 JavaScript 回調(diào)如果表盤(pán)刻度多、漸變復(fù)雜幀率容易掉到 30fps 以下Shape 是基于幾何體的聲明式繪制復(fù)雜度和 Canvas 相當(dāng)?shù)讓佑射秩揪€程管理更適合頻繁更新。我一般用 Shape 畫(huà)背景刻度和漸變色環(huán)用 Image 或 Text 顯示數(shù)字讀數(shù)速度值變化只改變一個(gè) property讓 Scene Graph 只重繪變化區(qū)域。Shape { id: speedRing anchors.fill: parent ShapePath { strokeColor: #00BFFF strokeWidth: 8 fillColor: transparent capStyle: ShapePath.RoundCap startX: centerX radius * Math.cos(startAngle * Math.PI / 180) startY: centerY radius * Math.sin(startAngle * Math.PI / 180) PathArc { id: arcPath x: centerX radius * Math.cos(endAngle * Math.PI / 180) y: centerY radius * Math.sin(endAngle * Math.PI / 180) radiusX: speedRingRadius radiusY: speedRingRadius } } property real centerX: width / 2 property real centerY: height / 2 property real speedRingRadius: Math.min(width, height) / 3 property real speedValue: 0 property real startAngle: -120 property real endAngle: startAngle speedValue / 260 * 300 }這段代碼里speedValue 是 C 層從 CAN 數(shù)據(jù)解析后通過(guò)信號(hào)槽更新上來(lái)的屬性QML 層只做從 0 到 260km/h 的角度映射。運(yùn)行時(shí)可以看到一個(gè)關(guān)鍵行為speedValue 變化時(shí)只有 PathArc 的終點(diǎn)坐標(biāo)變化Shape 內(nèi)部會(huì)做局部更新不會(huì)把整個(gè)表盤(pán)重畫(huà)一遍。如果你的開(kāi)發(fā)電腦上能跑 100fps 以上在 Arm 板上卻掉到 30fps優(yōu)先檢查是不是把整個(gè)儀表組件放進(jìn)了 Canvas 的 onPaint 里那會(huì)觸發(fā)全量重繪。3.2 采集線程如何安全地把數(shù)據(jù)同步給 QML 屬性C 端接收總線數(shù)據(jù)后不能直接改 QML 屬性。正確鏈路是采集線程解析完數(shù)據(jù)發(fā)信號(hào)給一個(gè)繼承自 QObject 的 VehicleModel 對(duì)象該對(duì)象把轉(zhuǎn)速、車(chē)速、檔位等字段更新到 Q_PROPERTY 對(duì)應(yīng)的成員變量里再發(fā)一個(gè)通知信號(hào)QML 端綁定該屬性的表達(dá)式自動(dòng)重新求值。VehicleModel 自身必須住在主線程這樣屬性變化通知才能安全觸達(dá) QML。class VehicleModel : public QObject { Q_OBJECT Q_PROPERTY(int speed READ speed NOTIFY speedChanged) Q_PROPERTY(int rpm READ rpm NOTIFY rpmChanged) public: explicit VehicleModel(QObject* parent nullptr); int speed() const { return m_speed; } int rpm() const { return m_rpm; } public slots: void onCanFrameReceived(const CanData frame); signals: void speedChanged(); void rpmChanged(); private: int m_speed 0; int m_rpm 0; QMutex m_mutex; }; void VehicleModel::onCanFrameReceived(const CanData frame) { m_mutex.lock(); if (m_speed ! frame.speed) { m_speed frame.speed; m_mutex.unlock(); emit speedChanged(); } else { m_mutex.unlock(); } }注意這里先比較再賦值只有數(shù)值確實(shí)變化才發(fā)通知。如果每幀都發(fā) speedChanged即使車(chē)速?zèng)]變QML 也會(huì)觸發(fā)表達(dá)式求值造成無(wú)謂的渲染開(kāi)銷(xiāo)。采集線程發(fā)信號(hào)時(shí)用 QueuedConnection 連接到這個(gè)槽保證槽函數(shù)在主線程執(zhí)行數(shù)據(jù)量大的模塊化結(jié)構(gòu)也可以在 onCanFrameReceived 里再包一層批量更新用一次信號(hào)攜帶整包數(shù)據(jù)降低跨線程消息數(shù)量。3.3 QSettings 與輕量數(shù)據(jù)庫(kù)如何分工車(chē)載系統(tǒng)里有兩類(lèi)持久化需求一類(lèi)是亮度、音量、語(yǔ)言、主題色這類(lèi)用戶(hù)偏好另一類(lèi)是行駛?cè)罩?、故障碼、充電記錄這類(lèi)會(huì)持續(xù)增長(zhǎng)的時(shí)序數(shù)據(jù)。前者用 QSettings 就足夠優(yōu)點(diǎn)是按 key-value 讀寫(xiě)ini 文件格式可直接用文本編輯器檢查適合調(diào)試時(shí)快速改值。后者的選擇要看數(shù)據(jù)規(guī)模故障碼和 stats 日志幾千條以?xún)?nèi)可以用 SQLiteQt 提供 QSqlDatabase 封裝超過(guò) G 級(jí)數(shù)據(jù)流就應(yīng)該考慮更底層的文件歸檔把每天的數(shù)據(jù)寫(xiě)成獨(dú)立二進(jìn)制文件再做索引。QSettings settings(QSettings::IniFormat, QSettings::UserScope, MyAuto, VehicleSystem); settings.setValue(ui/brightness, 72); settings.setValue(ui/theme, dark); int brightness settings.value(ui/brightness, 80).toInt();注意在車(chē)載板子上如果使用只讀根文件系統(tǒng)QSettings 的默認(rèn)寫(xiě)路徑可能是 /root/.config改成顯式傳配置文件路徑更穩(wěn)妥。SQLite 在 Arm 板上的典型坑是 WAL 模式和網(wǎng)絡(luò)文件系統(tǒng)不兼容車(chē)載的場(chǎng)景通常是一塊 eMMC 或 SD 卡WAL 模式反而略有性能提升關(guān)鍵在于別把數(shù)據(jù)庫(kù)文件放在被頻繁掉電的掛載點(diǎn)上。掉電丟失是嵌入式系統(tǒng)的常態(tài)數(shù)據(jù)庫(kù)寫(xiě)操作建議用事務(wù)批量提交并每 30 秒強(qiáng)制一次 fsync。4. Arm 交叉編譯工具鏈、CMake 和 Qt 庫(kù)的 sysroot 排坑4.1 先選對(duì)目標(biāo)架構(gòu)aarch64 還是 32 位 armhfArm 板的 SoC 現(xiàn)在主流的 64 位用戶(hù)空間是 aarch64老一些的板子可能是 32 位 armv7。交叉編譯前第一步是確認(rèn)目標(biāo)板的內(nèi)核和文件系統(tǒng)對(duì)應(yīng)的用戶(hù)空間架構(gòu)常見(jiàn)做法是在板子上執(zhí)行uname -m輸出 aarch64 用 aarch64-linux-gnu- 工具鏈輸出 armv7l 則用 arm-linux-gnueabihf-。armhf 表示帶硬件浮點(diǎn)armel 是軟浮點(diǎn)現(xiàn)在的根文件系統(tǒng)基本都是 armhf混用會(huì)出現(xiàn)“cannot execute binary file”的錯(cuò)誤非常容易誤導(dǎo)人。目標(biāo)環(huán)境工具鏈前綴常見(jiàn) OS/系統(tǒng)注意事項(xiàng)64 位 Arm 服務(wù)器/開(kāi)發(fā)板aarch64-linux-gnu-Ubuntu ARM64、麒麟 ARM64編譯參數(shù)加 -marcharmv8-a32 位 Arm 嵌入式板arm-linux-gnueabihf-Debian armhf、buildroot 默認(rèn)浮點(diǎn)參數(shù)必須含 -mfloat-abihard僅裸機(jī)/RTOSarm-none-eabi-無(wú) OS 用戶(hù)空間不加 glibc 依賴(lài)Qt 需要定制平臺(tái)插件有些老式 SD 卡燒錄鏡像里是 armel 用戶(hù)空間但板子手冊(cè)卻寫(xiě)著“Compiled for ARM”這種情況下用 arm-linux-gnueabihf 編譯的程序一跑就崩。拿著ldd /bin/ls在目標(biāo)板上輸出里看 libc.so.6 的路徑比看任何手冊(cè)都準(zhǔn)。4.2 用 Qt 源碼包構(gòu)建一套匹配目標(biāo)板的 Qt 庫(kù)交叉編譯 Qt 程序最常用的方式不是直接在自己電腦的 Qt 安裝目錄里找?guī)於菫榘遄訙?zhǔn)備一套 sysroot。sysroot 里放目標(biāo)板的 lib 頭文件和 ld 配置。推薦的做法是用 buildroot 或 Yeocto 生成目標(biāo)系統(tǒng)鏡像時(shí)把 qtbase 等包加進(jìn)構(gòu)建列表然后從鏡像里提取 sysroot。如果板子廠商提供了帶 Qt 的根文件系統(tǒng)直接解壓出來(lái)并掛載到一個(gè)目錄然后給編譯器傳--sysroot指向它。沒(méi)有現(xiàn)成 sysroot 時(shí)另一種常見(jiàn)做法是自行用 Qt 源碼交叉編譯。下載 qtbase 源碼后關(guān)鍵命令是 qmake 配置時(shí)指定 -xplatform例如./configure -prefix /opt/arm-qt5.15 \ -xplatform linux-aarch64-gnu-g \ -sysroot /opt/sysroot-arach64 \ -opensource -confirm-license \ -no-opengl \ -no-gtk \ -skip qtwebengine make -j8 make install注意幾個(gè)參數(shù)-xplatform 指定的是 Qt 源碼里 mkspecs 目錄下的一個(gè)子目錄名也就是 qtbase/mkspecs/linux-aarch64-gnu-g。如果沒(méi)有這個(gè) mkspec可以拿平臺(tái)上自帶的linux-arm-gnueabi-g目錄復(fù)制一份修改 qmake.conf 里的編譯器路徑和 -march 參數(shù)。這樣 Qt 庫(kù)、mkspec 和打包的插件全部對(duì)齊后續(xù) CMake 在開(kāi)發(fā)機(jī)上指到這套構(gòu)建產(chǎn)物即可。4.3 CMake 工具鏈文件里的交叉編譯參數(shù)與常見(jiàn)缺失Qt 6 時(shí)代官方推薦用 CMake 而非 qmake。交叉編譯時(shí)CMake 需要一份工具鏈文件告訴編譯器、sysroot 和 Qt 的搜索路徑。建一個(gè)arm-toolchain.cmakeset(CMAKE_SYSTEM_NAME Linux) set(CMAKE_SYSTEM_PROCESSOR aarch64) set(CROSS_COMPILE /opt/gcc-arm-10.3-aarch64/bin/aarch64-linux-gnu-) set(CMAKE_C_COMPILER ${CROSS_COMPILE}gcc) set(CMAKE_CXX_COMPILER ${CROSS_COMPILE}g) set(SYSROOT /opt/sysroot-arach64) set(CMAKE_SYSROOT ${SYSROOT}) set(CMAKE_FIND_ROOT_PATH ${SYSROOT} /opt/arm-qt5.15) set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER) set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY) set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY) add_compile_options(-marcharmv8-a) add_link_options(-marcharmv8-a)這份文件里最容易被忽略的是CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER。如果不寫(xiě)CMake 會(huì)在 sysroot 里找開(kāi)發(fā)機(jī)使用的工具比如 find_package 時(shí)找到它自己的 clang然后交叉編譯鏈斷裂。之后用 CMake 生成構(gòu)建目錄cmake -B build-arm \ -DCMAKE_TOOLCHAIN_FILEarm-toolchain.cmake \ -DCMAKE_PREFIX_PATH/opt/arm-qt5.15/lib/cmake \ -DCMAKE_BUILD_TYPERelease make -j8編譯出來(lái)的可執(zhí)行文件在 x86 機(jī)器上無(wú)法直接運(yùn)行檢查它是不是真的交叉產(chǎn)物用file build-arm/bin/vehicle_system輸出里應(yīng)包含ELF 64-bit LSB pie executable, ARM aarch64。5. 上車(chē)前三件小事離屏測(cè)試、性能定位與發(fā)布清單5.1 把無(wú)屏板子當(dāng) CI 跑QT_QPA_PLATFORMoffscreen板子到手之前交叉編譯出來(lái)的程序沒(méi)法連顯示器但 Qt 的 platform plugin 提供一個(gè) offscreen 插件可以把所有渲染丟到內(nèi)存里跑不做真實(shí)窗口和繪制。這個(gè)特性用來(lái)做單元測(cè)試和冒煙測(cè)試非常合適。在開(kāi)發(fā)機(jī)上跑 ARM 版程序需要把交叉編譯產(chǎn)物的 Qt 庫(kù)路徑放到目標(biāo)板的 lib 底下但如果你先用 x86 版做邏輯測(cè)試直接在開(kāi)發(fā)機(jī)上這樣執(zhí)行QT_QPA_PLATFORMoffscreen ./vehicle_system --smoke-test這個(gè)命令會(huì)讓程序不依賴(lài)任何顯示設(shè)備啟動(dòng)遍歷一遍主界面創(chuàng)建流程和信號(hào)槽連接然后自動(dòng)退出。把命令放到 Jenkins 或 GitLab CI 里每次提交代碼后跑一次界面相關(guān)的低級(jí)錯(cuò)誤能提前兜住。要注意 offscreen 平臺(tái)下 QML 的 Canvas 不會(huì)真正渲染因此視覺(jué)問(wèn)題檢測(cè)不出來(lái)只能驗(yàn)證加載和綁定邏輯。5.2 用 Qt Quick Profiler 定位繪制瓶頸在哪一層真正在板子上跑起來(lái)后性能問(wèn)題通常出在 QML 場(chǎng)景圖構(gòu)建或數(shù)據(jù)從 C 到 QML 的傳遞頻率。Qt 自帶 qmlprofiler能捕獲 UI 線程的時(shí)間分配但要求程序以 QML debugging 模式啟動(dòng)。命令行示例如下./vehicle_system -qmljsdebuggerport:3768,block啟動(dòng)后在開(kāi)發(fā)機(jī) Qt Creator 里點(diǎn)擊“Analyzer QML Profiler”連接目標(biāo)板的 3768 端口就能看到每一幀里 JavaScript 執(zhí)行、場(chǎng)景圖渲染、內(nèi)存占用的占比。最常見(jiàn)的結(jié)論是某個(gè) QML 組件里寫(xiě)了復(fù)雜的循環(huán)或 JSON 解析阻塞了 render thread。把這類(lèi)計(jì)算搬到 C 端QML 端只存最終渲染用的數(shù)值。5.3 打包時(shí)用 ldd 清單和 QPA 插件核對(duì)交叉編譯出的程序拷貝到板子上一閃而過(guò)十有八九是動(dòng)態(tài)庫(kù)缺失。用arm-linux-gnueabihf-readelf -d vehicle_system | grep NEEDED查依賴(lài)再把每一條庫(kù)和目標(biāo)板/lib/usr/lib下實(shí)際存在的文件對(duì)比生成 lib 匹配清單。Qt 相關(guān)的庫(kù)建議把libQt5Core.so.5、libQt5Gui.so.5、libQt5Qml.so.5和libQt5Quick.so.5一起拷入板子放在與開(kāi)發(fā)機(jī)相同的相對(duì)目錄。最后核對(duì) QPA 插件。Qt 運(yùn)行時(shí)會(huì)通過(guò)QT_QPA_PLATFORM_PLUGIN_PATH尋找libqlinuxfb.so或libqeglfs.so等平臺(tái)插件路徑配錯(cuò)程序啟動(dòng)即報(bào) “could not find a Qt platform plugin”。發(fā)布時(shí)把這幾個(gè)插件打進(jìn)文件系統(tǒng)并在啟動(dòng)腳本里顯式寫(xiě)入export QT_QPA_PLATFORMlinuxfb export QT_QPA_PLATFORM_PLUGIN_PATH/opt/vehicle/plugins/platforms export LD_LIBRARY_PATH/opt/vehicle/lib /opt/vehicle/bin/vehicle_systemlinuxfb 是最樸素的幀緩沖平臺(tái)插件不帶 GPU 加速時(shí)性能一般但兼容性最好適合做畢業(yè)設(shè)計(jì)演示板子帶 GPU 且 Qt 編譯時(shí)啟用了 eglfs優(yōu)先換 QT_QPA_PLATFORMeglfs界面流暢度會(huì)明顯提高。本文還有配套的精品資源點(diǎn)擊獲取