Qt全球峰会2023中国站 参会概要
- 前言
- 峰会议程
- 下午场是分论坛进行，我反复切换，只选择了感兴趣的
-
- [非零和博弈的 HMI 开发流程](#非零和博弈的 HMI 开发流程)
- [银河麒麟 Qt 框架源码级桌面实践分享](#银河麒麟 Qt 框架源码级桌面实践分享)
-
-
- [Qt 的看护难度（不是很理解该用词）](#Qt 的看护难度（不是很理解该用词）)
- [与 Qt 商业版本合作的原因](#与 Qt 商业版本合作的原因)
- 疑难问题修复
- [Qt 工作构想](#Qt 工作构想)
-
- 使用静态代码分析工具提升软件质量（手机拍照，将就着看）
- [Qt + OneOS 提升客户 HMI 产品开发体验](#Qt + OneOS 提升客户 HMI 产品开发体验)
- [Qt Wayland 最新进展](#Qt Wayland 最新进展)
- [如何在新的硬件平台上运行 Qt for MCUs](#如何在新的硬件平台上运行 Qt for MCUs)
-
-
- [为什么要在 MCU 上使用 Qt ？](#为什么要在 MCU 上使用 Qt ？)
- 官方现已适配超过35款MCU（拍的实在糟糕，但这些都是公开的资料）
-
- 纪念品照片
- [个人对 Qt 的看法](#个人对 Qt 的看法)
前言
在今年三月份的某一天，意外的发现，我所关注的公众号"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 读音）。