Lvgl VS GuiX选取参考
文档更新记录：
Date：2020/10/xx: 添加支持的功能描述 by Hpbbs(toweros@sina.com)
Date：2020/12/18: 添加对比的性能和重用方面的内容 by Hpbbs(toweros@sina.com)
Data：2020/12/20: 修改目录结构，以技术选型原则重新安排内容 by Hpbbs(toweros@sina.com)
一、重用价值角度列举（共识）：
重用的三个问题：
- 质量
- 文档
- 许可证条款：重新发布权，使用权，个人使用修改权，修改版本的重新发布权
- 发展：软件项目的生存期和项目自我定位（假设软件项目的生存期很短，就很容易犯错；程序没有办法解决程序员没有假设过的问题）
找到可重用代码的价值
- 维护成本，发展成本
- 决策成本，行政成本
- 开发者的交流学习成本
- 时间投资：了解找到什么优秀的复合场景的可重用代码
二、嵌入式场景特点（共识）
1. 嵌入式GUI的下层：硬件多元多样
- GUI公共部分（GUI库）基本没有能力去做硬件级别优化（必须在移植时根据硬件特定编写，但这已不在公共的GUI范畴）
- GUI Lib的host os依赖部分必须接口化（而这个接口对依赖的支持预留越多，说明gui lib的可支持的底层优化空间，基本上来说：底层接口的表达的能力 == GUI库本身的能力），接口是GUI lib的硬件瓶颈，是基因（当然不排除设计层面上的渲染绘制机制的设计优良）
2. 嵌入式 可视化 UI特点：交互控制设计简洁 & 提前算力
- 不像手机，电脑 等大屏幕设备：决定了UI交互控制必须简洁，页面内容设计必须简洁，不简洁反而会导致难看难用
- 不像网页，大型游戏，没有directX那样统一的优化接口，性能CPU GPU都不在一个量级：决定了复杂的UI效果没法在本地计算呈现（如三维动画，矢量计算），必须要尽量将计算放在其他端（比如图片资源提前解压缩为binary，过于复杂的UI效果都使用图片为载体），最终成为：空间换时间，内存换算力的交易
3. 嵌入式UI库商业运作方式：硬件绑定销售与桌面级库 服务器级代码库的商业逻辑好像不太一样（结论不确定）
- GUIX：2014年发布首版，支持Pre-Lisence的硬件板子免费使用 （主要ST和NXP）和 主动申请授权后使用 两种方式，绑定销售
- Touchgfx前期独立发展，被意法半导体收购后，与st系列板子绑定
- Qt for mcu：提供商业版本，开源（GPL3.0）
- lvgl暂时免费开源，后期发展？
三、总结先行：
从需求匹配而言，LVGL与GUIX基本都可以满足
设计角度：
Guix ：整体设计完整成熟，配套UI Designer，和代码及资源生成，应用与布局细节代码分离，细节考虑更多
LVGL：基本能完成项目需求，UI designer在计划中，无代码生成，有资源手动生成
（见软件质量对比表 1.1)
性能角度：
UI库性能主要在 刷新和绘制，lvgl主要针对简单图元，guix的API图元丰度更多，或许他做了特异性的优化；其次lvgl的优良移植性可能会导致一定性能消耗；刷新暂没看guix代码；性能无法下定语孰优孰劣
（有功能 与 用到动能 与 功能有较好效果 与 功能在对应项目中有较好效果 都是不同的问题，是没有强关联的：需要进一步场景化的测试和需求匹配）
其他：许可证和后期发展角度：
从文档上看，GUIX更加成熟，微软GUIX的团队似乎对嵌入式+GUI理解更深一点，如：针对嵌入式UI简洁的特性，将UI相关的代码以及一部分控制相关的交互接口 完全交给Desingner，同时降低 不熟悉UI模式开发思维的嵌入式开发者的程序入手的门槛；同时整体更加成熟，lvgl和guix大部分设计相同，同时GUIX有额外的支持：如国际化，资源管理，富文本支持；
（更新：LVGL目前也有了UI所见即所得的设计工具，上一条论据并不那么明显）
而从发展角度看：guix很成熟，可能会基本固化，lvgl也是整体比较完善，同时是在发展的过程，或许需要从发展的眼光和法律许可，行政成本角度去看
四、人员资源成本/法律/开发合作/自我发展定位：
法律和许可：gui授权，vela发展过程中的授权，是否需要以及是否可以自己开发分支的问题
收益成本：
- guix设计成熟，在开发人员的成本低；
- lvgl处于发展期（无论是代码库功能本身还公司发展）；
- 短期收益：员工开发效率更高，guix设计成熟全面，或许可以快速出成品；
- 长期收益：开发人员投入成本，推广成本，授权使用费用成本，代码，后期发展后，公司对技术控制权的问题
自我发展定位和需求定位的问题
目前主要的问题：是需要快速出成品，还是需要一个长远的技术自主权和稳定的技术栈；目前在嵌入式UI投入的目标：产品或长远技术积累或两者都要
五、详细对比内容
1.软件质量对比
主要从如下角度对比
- 用户空间
- 系统支持空间
- 架构设计
- 基本量化性能指标
- 软件热度/商业化
| 对比 | GUIX | LVGL | 结果 |
|---|---|---|---|
| 用户空间 | |||
| API能力及透明性 | Noun-verb naming convention | 同 ，api接口描述透明化，易理解 | 无差异 |
| widgets丰富度 | 丰富度低，支持 富文本编辑和带样式复制 | 偏扁平化设计，丰富度比GUIX高，且已经拓展了相应的控件 | 拟物效果一般更加要求性能 |
| UI designer以及模拟器 | GUIX Studio（Base on windows platform）：compile to ANSI C code（应该会有中间描述文件） generating resource file；有模拟器；Desiner无法导入自己编写的控件，只能进行比较底层简单控件元素的拖拽设计 | UI designer计划中；模拟器：因为移植性可移植到一般的通用模拟器 | GUIX抽离了layout和c代码，增大灵活性；但是Designer无法拓展自己的控件，灵活性又被自己吃掉了 |
| 系统支持空间 | |||
| 平台依赖 | requires：thread or tasking, mutex, event queue timing service providing by underlying RTOS；支持移植 | 在基础依赖方面对os依赖比起guix少 | LVGL耦合度更低 |
| 内存 | Flash: >13.2; RAM:>4kb; displaybuffer; no canvas required with internal GRAM and self technology | clock > 16mhz; Flash/rom: >64kb; RAM:static(2) Stack(2-8kb); Displaybuffer,framebuffer | 基本相同，仅从数据看：GUIX下限更低 |
| 底层绘制能力 | 接口比较多，绘制接口号称全canvas支持，绘制接口可自定制优化 | 图元绘制相对guix少，但是最小操作集，提供有GPU接口 | |
| 刷新机制 | 脏列表，有区域切割的刷新 | 分层，分可视有效区域刷新， | 说法不同，逻辑相同 |
| 架构设计 | |||
| 驱动模型 | 事件驱动，有事件队列管理，状态码和widget函数指针实现 | 事件驱动，状态码和函数指针实现，没有事件队列的设计 | 都是使用类似于状态码通知的架构设计， 没有本质区别；guix有额外事件队列管理 |
| 窗口管理 | 阉割实现，可以实现：UI部分的管理和页面栈；但管理较多的应用页面上下文资源和线程任务（有窗口，但是没有上下文） | 有screen的load的简单设计，无页面栈（主要缺陷），已补全 | |
| UI 分离设计 | 有Theme但耦合性一般（按api），layout与代码分离，基于designer，实现了 布局显示 的分离，样式的分离 | style/theme 参照css设计，设计较好，实现了样式的分离和统一 | |
| 性能其他 | |||
| 资源管理 | 依附于designer而做出了资源管理，也带来一定灵活性限制；但是资源管理没能独立出来 | 没有 | |
| 安全考虑 | |||
| 数据类型重定义 | 除了字符串重新处理了，其他也就是typedef，没有特别的 | ||
| 主动idel | 没有事件输入时就会主动idel（按文档） | lvgl没见到类似设计 | |
| 国际化 | 用不一套资源的方式提供，但是提供的很奇怪（没看相关源码） | 支持utf8编码，组件支持bidi，但似乎没有别的了 | |
| 软件价值和软件热度 | |||
| 支持的平台（支持越多说明需求越多，代表质量越好） | 微软 | LVGL团队 | |
| 其他公司的使用（被使用越多，说明越被看好，大厂背书） | |||
| 商业化程度 | 成熟完善 | 尚未确定 |
表1.1 软件质量对比
注：有功能 与 用到动能 与 功能有较好效果 与 功能在对应项目中有较好效果 都是不同的问题，是没有强关联的：需要进一步场景化的测试和需求匹配
2. 法律许可 成本
| 对比 | GUIX | LVGL | 结果 |
|---|---|---|---|
| 授权 法律 成本 | |||
| LISENCE | Pre-Lisence（绑定板子）或者单独授权（2.5刀 每xx设备） | 商业合作暂不明了 | |
| 开发者成本 | 嵌入式驱动开发的开发者适应GUI的开发模式需要成本，Designer或许会降低 | Desinger在规划中，效果未知 | |
| 文档 | 设计纵览+源码+example | 设计纵览+源码+example+较详细api说明和移植说明 | |
| 能否修改后发布(是否需要) | 未知 | 未知 | |
| 运维管理行政成本 | guix是微软出品，可能更多的是合作 | 对于lvgl在寻求商业化的当前阶段而言，或许能有更多的主动权 |
表1.2 法律许可
3. 发展：自身发展/合作发展/
| 对比 | Situation one | situation two | … |
|---|---|---|---|
| 工具库自身发展 | GUIX本身发展较为稳固，lvgl是在发展过程 | ||
| 合作模式 | 只是本设备使用这个工具 | 将这个工具开发本公司的分支作为技术栈 | |
| vela后期法律风险评估 |
表1.3 发展角度对比
目前项目需求：
UI designer工具非刚性需求，多数人写UI更加愿意使用代码编写而不是用工具拖拽，designer更多的是方便开发人员与设计师交流想法 和验证的工具
（更新）：UI Designer对于有简洁内容和交互属性的嵌入式UI，且开发者多是嵌入式领域的人员而言，designer是有优势的
根据布局描述文件 来动态差异性绘制页面 或许当下表盘主要需求； 表盘 从设计师 到 设备端的主要隔阂是打通设计语言到c 绘制代码语言
（更新）：原结论说的过于模糊，目前的项目需求是前半句而已，后半句是 UI描述语言的公共问题（无论是xml还是其他半结构性标记语言）
从UI库的层面来说，性能，架构设计根据其自我定位可能各有千秋，而在应用层面：应用代码分离标准，打包标准，应用构建标准，资源文件如何组织的标准，这些标准规则LVGL没有定，GUIX似乎也没有（不确定）；没有项目构建标准 多个项目难以组织，多人难以合作
后期发展的角度：
- 收益成本估量
- 是否有掌握UI库主动权的想法，选择中的UI库是否支持 修改后发布的许可合作方式
参考
- Unix编程思想：关于复用的价值
- LVGL官网：lvgl
- GUIX官网：Guix