前言

在今年三月份的某一天，意外的發現，我所關注的公眾號“Qt軟件”，頭像由原本清新的綠色變為了厚重的黑色
→習慣了清新綠的我有些奇怪，正好 Qt 在我常使用的 B站 有運營著活躍的官方賬號，于是嘗試在該賬號的視頻下留言“logo由綠變黑是有什么寓意嗎？”，得到了如下回復：

再進入Qt官網查看，發現已由 Qt Company 變為了 Qt Group，驚覺自己對 Qt 的認知還停留在從前，于是在九月下旬得到Qt全球峰會中國站在上海召開的消息推送時，第一時間報名，最終審核成功，有幸參與了 Qt全球峰會2023中國站，本人并不是一位資深的軟件工程師，今天只是站在一個普通開發者的角度，記錄此次會議的概要，發表下個人愚見。

峰會議程

此次峰會，上午場為全體大會，下午場以分論壇方式舉行，分為 嵌入式開發 和 桌面/移動端開發 兩個專場

簽到 & Demo 演示

峰會地址是上海萬豪虹橋大酒店，會場還是很好找的，簽到完成，獲得吊牌，再送幾本宣傳冊

開場致辭

Qt Group亞太區副總裁致辭，全英文無翻譯…

Qt Group 產品總監演講（產品開發的趨勢-開放的軟件、工具和框架）

產品戰略

• 總體而言，Qt的產品戰略為：公開的工具、開放的框架，專注于優化產品開發流程；
• 軟件開發方面，使其他部門無縫銜接入產品的開發流程中，QA工具為產品的質量做了保證；
• 相信開放工具戰略，積極擁抱第三方（如 Qt 6 擁抱 cmake）
• QtCreator 的目標是穩定的API，開放插件生態，集成更多有趣的功能
• 開放的框架戰略，并不是要兼并所有，而是包容的思想（如在已有的軟件基礎上，使用Qt進行組合）

QtQuick or QtWidgets（c++ or qml）

這真是個老話題了，我已經不想多討論，直接粗暴的使用一個經典言論：你的軟件使用鼠標比較多就選擇widgets，觸屏操作多就選擇quick；這句話適用于大部分場景。

Qt如何定義AI

生成式的AI并不能確保質量，生成越多，測試工作就越多（由此引出了Qt 的 COCO7工具），
AI是增強性的功能，而不是主導性的功能。

個人看法

在很多開發者的認知中，Qt 只是一個開發框架，一些新的用戶甚至可以說出“Qt是一個UI庫”這樣的言論；在我看來，按照 Qt 目前的布局，它將是一個全套的解決方案。

Qt 在券商數字化轉型和信創改造中的創新實踐

由國泰君安的一位員工（title就不提了）分享Qt在金融證券行業的案例，該行業中的投資者對軟件響應速度有一定要求，以及大量用戶使用MacOS、Linux、國產操作系統（跨平臺需求）

• 國泰君安2002年推出全行業首家全自研網上交易終端（基于Delphi）
• 2015年8月：行業首發一戶通賬戶體系的融合金融終端
• 2018年3月：啟動新框架調研
• 2018年8月：完成PC端技術棧的調研，選擇Qt作為國泰君安新一代PC端主要開發框架
• 2019年12月：完成整體基于Qt框架的MAC版富易（國泰君安網上交易專用系統）
• 2021年7月：得益于選擇的Qt框架滿足信創要求，實現全行業首發上線支持國產系統版本富易
• 2022年8月：基于Qt自研框架
• 2023年12月：全面部署切換，日均在線用戶16萬，日調用量1億+

這是一個成功的案例，該公司無疑是開拓、進取且勇敢的。

Qt產品路線圖

獲悉Qt目前已有4800+萬行代碼，這個代碼量并不是只有Qt framework，包含了COCO單元測試工具、Squish UI自動化測試、Test center 平臺等；詳細的內容我建議直接去 Qt Group 看

關于Qt版本

• 當前的時間節點，Qt最近的長期支持版本是6.5
• 目前用戶量最多的版本是Qt5.15，由于用戶量龐大，原定的LTS版本支持三年的計劃也延長了兩年
• Qt6.6版本增加了很多特性
  • 用于權限管理的QML API
  • 優化對 Android 的支持
  • Style 的改進和優化
  • Qt for web 的優化
  • 正在進行 c++ 20 的初步支持（這是令人激動的）
  • 未來考慮全面支持c++ 20
  • 異步I/O
  • 等等等等…
• 下一個LTS版本將是Qt6.8，預計于2025年發布

Qt 賦能STM32 MPU 人機界面應用 - 助力用戶構建強大高效的 GUI

意法半導體和Qt深度合作，高性價比圖像解決方案

---

下午場是分論壇進行，我反復切換，只選擇了感興趣的

---

非零和博弈的 HMI 開發流程

抱歉，我沒有太多產品思維，也沒有汽車行業的經驗，純粹牛嚼牡丹

根據我拍下的照片，抄錄下一些概念：

何為產品經理

產品經理是負責監督產品或一系列產品在其生命周期中的開發和管理的專業人士；他們在定義產品策略、設定優先事項，并指導產品開發過程中起著至關重要的作用。

零和博弈（具體到汽車行業）

• 在工作流程中，總有一方會在一個周期內贏得主導權，然后突然出現某個觀點，然后下一次就輪到另一方接管
• 在設計和開發開始整合時，我們聽到了很多抱怨，整個迭代過程中充滿了摩擦
• 當他們開始考慮將其復用并擴展到其它車型時，整個代碼庫得支持變的難以為繼，甚至難如登天，最終導致了延遲，最初高利潤的計劃變成了一場白日夢

銀河麒麟 Qt 框架源碼級桌面實踐分享

銀河麒麟桌面操作系統中，Qt 起到承上啟下的作用，系統層次從上往下依次是：

• 業務應用：圖形化應用程序
• 桌面環境：任務欄、文件資源管理器等
• 應用運行時：Qt
• 基礎庫環境：Glibc、FFmpeg、openssl、bluez、DBus、alsa…
• 硬件環境

Qt 的看護難度（不是很理解該用詞）

以某版本為例，統計了 Qt 開發模塊數、API數量、目前社區未解決bug數量（兩千多個，數據似乎很驚人），同時要求了工程指標；

與 Qt 商業版本合作的原因

• 產品質量得到保證
• 促進生態
• 從 Qt Group 可獲得高質量的技術支持服務
• 通過培訓以及共同排查問題的過程，提高研發實力

任何選擇，你最好都有你的理由。

疑難問題修復

麒麟系統級開發，遇到的問題不常見，太細節了，在此就不放了，只說一個常見的：Qt 版本升級引發的兼容性問題。麒麟遇到這個問題的原因是由于Qt public API 的兼容性保證，升級前過于樂觀，升級后出現大量問題，原因是 private API 兼容性欠佳；（一些邪惡的軟件工程師喜歡用Qt private 模塊，hhhhh，狠狠的敲打）

Qt 工作構想

• 構建多平臺一致的 Qt 使用方法，提高生態適配效率
• 為 Qt 應用開發各環節賦能，提高產品質量

很好的愿景，第一條的解讀：如 windows 系統上 Qt 開發，直接下載 Qt 提供的預編譯包即可，即使安裝多個版本也無妨，而在 Linux 下情況是不同的，不熟悉 Linux 環境的開發者，會浪費一些時間在這上面（更遑論Linux發行版錯綜復雜），徒增心智負擔。

使用靜態代碼分析工具提升軟件質量（手機拍照，將就著看）

軟件開發過程中，如果沒有采取積極的措施，軟件的復雜性/功能性將越來越快地增長，稱之為“軟件侵蝕”，我們需要阻止它

重構：功能性不變，從工程角度提升技術架構和質量；持續的重構，可改善軟件侵蝕

在實踐中，這是難以實現的，預算、時間、風險都是企業無法接受的，最終很難改善問題

• 重構是個很好的辦法，只是作為集中式的任務來說有點困難
• 把它分散到更小的迭代中
• 預算、時間、風險雖然仍存在，但可以通過日常任務的方式來處理，類似敏捷開發方法
• 使用 Axivion 進行 CI（持續集成）中的靜態代碼分析（圖窮匕見）
  

Qt + OneOS 提升客戶 HMI 產品開發體驗

OneOS 自上至下抽象為：

• 應用場景
• 組件層
• 框架層
• 內核層
• BSP/Driver
• 硬件層
  OneOS 框架層選擇了 Qt for MCUs 作為開發框架，以下直接展示產品：
  

Qt Wayland 最新進展

• linux 桌面正在遷移到 Wayland
• gnome 推動 Wayland
• KDE 6.0 全面支持 Wayland（將于今年開發完畢，KDE 加油！）

齊亮大佬云淡風輕的從 X-Server 為引，圍繞 Compositor 講解 QtWayland，讓我汗流浹背（差距太大了）

如何在新的硬件平臺上運行 Qt for MCUs

以下直接摘自演講者PPT，本人對 MCU 并不太了解，侵刪

為什么要在 MCU 上使用 Qt ？

• 使用 MCU 的優勢
  • 便宜：通常比 MPU 價格更低
  • 快速：啟動時間大大縮短
  • 可靠：復雜度更低，更容易保證健壯性
  • 高效：更容易快速實現大規模生產
• 原生 API 開發的劣勢
  • 開發效率低：缺乏抽象層，很難開始開發，驗證調試復雜
  • 廠商綁定：每家都有各自的 API 和配置，純體力勞動
• 使用 Qt 解決了哪些問題
  • 簡單：Design Studio 和 QML 適用于設計師和 TA
  • 可擴展性：應用很容易在不同供應商的 MCU 和板卡之間遷移
  • 支持：完善的文檔和眾多示例以及本地化支持

官方現已適配超過35款MCU（拍的實在糟糕，但這些都是公開的資料）

• 在 MCU 上使用 Qt 非常簡單，而且不會被鎖定在某個 MCU 供應商或特定板卡上
• 你可以在一個官方支持的平臺上試用，然后根據自己選擇的 MCU 進行定制
• 移植的步驟都有詳細記錄，你可以按照步驟進行

紀念品照片

個人對 Qt 的看法

• 使用 Qt 的時間也不短了，算是一個 Qter，猶記得第一次使用 Qt show 出一個窗口時激動的心情；我很愿意相信，Qt 為 c++ 煥發了活力，c/c++ 的學習是枯燥的，很多人學習 c++ 時都是對著冰冷的終端，無情的打印字符，做不出任何東西，得不到正反饋，很難不讓人自我懷疑。
• Qt 簡化了 c++ 的使用，見到很多初學 Qt 的學生或是跨行業選手，在連 c++ 基本語法（基本語法不作具體定義，大家伙別太魔怔）都認不全的情況下，使用 Qt 做出了簡單的項目，且能夠不出巨大的紕漏，頗有 “舊時王謝堂前燕，飛入尋常百姓家” 的意味；我本人也比較感激 Qt，它讓我平滑的學習了 c++。
• 而今，Qt Group 有了更遠大的目標，一方面，Qt 公司較小的體量，維持著龐大的產品線，令人擔憂；另一方面，似乎很多優秀的作品都是由小而美的團隊完成，太多人的意見也會讓事情變壞；這很難評價。
• Qt 的多重授權、發律師函、以及嵌入式上 LGPLv3 協議的不明確解讀頗受詬病，期望未來能夠有更好的商業化策略。
• 不管怎樣，希望它越來越好。

最后，讓我們一起讀出 “Qt”（同 cute 讀音）。