GUI 框架基础需求、设计和实现 - 3 工程框架设计 / 基础思想

以下皆为建议性内容，根据需求制定方案。

这里列出 GUI 开发中的通用性的需求、问题的解法和方案等，为了能够搭建出复杂 GUI 显示和交互逻辑，满足交互设计需求。

文章所在 Github 仓库 Staok/GUI-Framework-Study: GUI 框架基础需求、设计和实现文章会保持最新，其它地方的不会跟进。Github 上的 MarkDown 显示更完善，建议去原仓库看或者下载下来看。

涉及到本文没有的小节，请参考同专栏其它文章。

工程框架设计 / 基础思想

工程框架建议

设计前多参考其它优秀项目设计，工程目录划分、程序结构。进行吸收补充。
首要约束：

基本规则："低耦合，可重用，参数化，注释全" 。简单问题不要复杂化 。多写可复用代码，组件化，参数化（可经过简单配置进行复用），扩展方便，注释到位。

考虑程序健壮性，避免易出问题的点。可参考编程经验-易错注意。

考虑运行效率。具体编码时注意内存和 CPU 占用，内存增长大户有：缓存（不用常驻内存的不 cache，确保其会及时释放，但是缓存、对象池这种，可以减少 cpu 负担，做个平衡）、重复增殖的组件、递归等。因此数据抽象的时候数据结构简洁不占内存，内存有申请就注意释放，尽量不使用任何递归，注意增殖组件限制每次加载的数量（比如图片批量显示，限制每次只加载少量，做成可前后翻页），防止任意增殖造成内存暴增。

考虑可维护性（结构清晰，文档够，注释够，程序模块化、参数化、扩展方便）。

考虑可测试性（接口清晰，设计测试用例，设计测试工具和手段），提升程序健壮性。

设计阶段、开发阶段，发现不合理的地方、可优化的地方，尽早修缮。
这一点很重要，切实做到前后端分离，前端尽量只做界面显示而不包含业务逻辑，前端只根据后端的信息和信息变化进行显示，是一个主从（master-client）的关系，业务逻辑尽量全部放在后端，后端把要显示的信息和动态改变的信息通知发送到前端即可，不要业务逻辑即有一部分在前端也有一部在后端的混淆联动。

工程文件夹

从编辑器到文件输入输出，一律用 UTF-8 编码。
多建文件夹对文件进行归类，层次分明，命名有意义。

同一个页面下的各个子页面文件统一放到该窗口名字的文件夹下。

复制代码

screen
    config（配置文件夹）
        config.json
    src（后端文件夹）
        （每一个部分或组件的 .c/.cpp 和 .h 放到同一个文件夹）
    UI（前端文件夹）
        mainPage1 主页面1文件夹
            mainPage1 主页面文件
            subPage1 子页面文件夹
                subPage1 子页面1文件
                subPage2 子页面2文件..
        mainPage2 主页面2文件夹
            ...
        res（图片、图标素材文件夹）
        langs（多语言文件文件夹）
    tools（用于测试等的工具文件夹）

前端界面文件

事情搞简洁，不要往复杂搞。组件分明、接口分层清晰。
注释表明本页面是干什么的。其内每个组件对应界面上是什么东西也用注释标注清楚。

前端界面编写应尽量将每一个部分抽象出来，通用的组件更是，低耦合、可重用、参数化、注释全。

这样为了减小编译后固件的体积，也可以选择性编译某些文件，而不用所有界面，包括很多不用到的也包含进去。
- 前端界面编写，一个界面中每一块内容作为组件打包。若是独立的面板、子页面、组件，则可尽量独立成文件。
- 通用的小组件，每个做成独立文件。
所有的 UI 控件实体最好都加上诸如 id 或 name 属性，且最好是这个 id 或 name 在当前页面里面唯一，用有意义的名字命名，好认；并且程序中可以知道这个控件的上级是什么，以及当前所在页面，这些信息组合起来就可唯一定位这个控件。id 或 name 可的方便寻找或筛选控件，或用于埋点等，方便以后的需求。
最好都用相对位置的相关（如 Qml 的 anchors 属性，lvgl 的语句如 lv_obj_align(child,LV_ALIGN_CENTER,0,0); 等）设置界面上各个组件位置。

并且每个组件的长宽属性，文本显示、输入框的限制长度、是否可换行/省略号显示/是否滚动，限制长度等属性均设置好。

预留足够的空间，当其内部的内容变化时候（比如文本长度）

让各个组件紧凑贴在一起并且可随边界、其它组件变化而变化，并且不会乱，

这样在屏幕分配率、长宽比变化，组件增减等情况下，界面还能尽量保持规整，保持良好适配性和可扩展性。测试时候就多改变长宽比等看效果。
页面中重复性的排列的结构，比如 wifi 列表、用户列表等，每个单独的设计成组件，然后用 list 类的控件在其中添加（还有设计显示效果如：横向/竖向排列、间距、滑动条、自动对齐等）。
对于 UI 复杂交互逻辑的在前后端中的划分，请参考 基本开发模式 一节。
机器自身原因导致有时候会执行 UI 的 API 很慢（比如其它进程挤占 CPU），就会偶现一些中间状态，因此：

设计时应该尽量避免展示中间状态。

比如一个复杂组件由很多子图形构成，如果执行的慢，并且程序写的是顺序执行并挨个显示的，则呈现效果为这个复杂组件为其内部图形逐个构造显现的，可以写为要创造这个组件时候，最底层的 panel 应该先隐藏，等待内部图形都创建完毕后，再显示出来。

或者一堆列表的创建，如果机器的 CPU 比较忙，UI 就变成了一个一个往外蹦的样子，这种列表可以在数据和UI创建积累比如5个再一齐显示。

后端文件

程序文件层次清晰。编译流程清晰。依赖库清晰。
程序调用层次清晰、逻辑清晰，格式规范，注释到位。
规范，可以每一个功能单独写一个类，里面提供所有业务功能，包括一个状态机、所有相关变量和方法，前端只与这个类进行收发信息交互，前端基本不留业务代码，只是显示相关的。

应该有一个示例类，形成模板，一个功能用一个类打包，携带方便，解耦独立，添加新功能就是加新类，统一的模板去做，简化工作，而不是无尽的在原有的几个文件里面堆砌。
类的功能分离和独立，组件化，参数化（可经过简单配置进行复用），扩展方便，注释到位。

许多子功能，比如升级等，可以独立，通用性，只留出接口供其它类调用。

降低对于移植其它 GUI 框架的难度和工作量！避免全盘重构！

前后端交互

参考 基本 UI 开发模式 一节。

实用提醒

GUI 程序和后端、其它进程的通讯全部做成事件响应（事件型通知通讯，可以加快界面UI 响应速度，不必等到下一个通讯周期才更新显示）。

周期性刷新可以同时保留，即打包当前机器状态所有的信息到一个数据结构（json、protobuf 等），后端某个进程（指定为接收所有其它业务进程的信息，汇总成前面所说的一个数据结构）周期性（比如 1s）发送给 GUI 程序进程，这样可以保证 GUI 显示始终是与当前机器状态一致的，而且 GUI 进程结束再启动后也可以快速同步到当前机器状态。

但是，有的信息是高频刷新的，或者比较独立的，比如 Wi-Fi 列表这种，可以单独拿出来放在另一个主题的数据结构里面，周期性的向 GUI 进程发送，以此类推。

后端数据可能更新频繁，UI 刷新需要注意降频，一些数据变化，根据业务逻辑，经过整合、判断后才精准更新到具体的 UI 元素。
界面中所有的用户设置、配置的需要记忆的地方，比如选择框 / 开关、下拉框的状态等，都应该用一个配置文件比如 settings.json 存起来（每一项都至少有两个，默认配置和当前配置，还可以再加一个上次配置），这样，可以保存所有设置，下次开机仍然是上一次设置的状态，或者同步到别的机器等等。前端操作后，后端处理生效后再改变 json 为设置后的值，要保证 json 与当前机器状态以及控件视觉状态是一致的。