首先，简单说一下，这个例子的情形：
这个例子，是对应v0.1这个demo的，也就是适用于一般单色的 而且像素不多的屏，如12864这类屏。
因为它单色，也因为它的像素少，所以在其上显示太多图像，或者试图花哨，都会对整体效果起到反作用。
还不如简简单单地就文字好了。
一个缺点就是，效果比较丑，而且还会造成外观上，button label text等根本没有区别。
但是这种情况下，也有一种设计思路，那就是，根本不用区分什么 button label text
比如说，button和text合二为一，或者一个界面，基本上只有button。
例如上一代智能手机中最常见的电话本的列表。
不管如何，受限于具体的显示器件的表达能力，我们不能也不宜强行搬用老套的显示界面，而要变通，否则就会很难看。
比如，我就一直很不看好在 7寸以下的屏上，像PC上使用 窗口 的 界面。
另一个很重要的问题：
在FreeUI的几个帖子的回复里，还有我在其他地方看到的关于 人机界面 设计编程 的讨论中，听得最多，而且我个人也觉得最奇怪最难以理解的设计之一就是：
似乎，在很多的设计里，人们很担心“同一个按钮”在“不同的页面”有不同的含义或者跳转的页面。
我之所以困惑，是因为我的设计思路完全不存在这种困难
——因为在我的思路里，每个页面每个控件（比如 按钮） 都是唯一的，它们都通过唯一id号编号，寻址。
不过稍微想想，我大概能知道那些设计的大致思路。
因为他们没有把每个屏每个控件表格化，没有把他们抽象，而是把 控件本身 和 具体的界面运作以及背后的触发函数等 混为一体。
在这种情况下，如我所说的那样，一旦界面复杂起来，这个程序将会变得越来越难写。
为什么呢？
我有一种以下的理解方式：
我在做HMI的过程里，慢慢地产生一种感觉，类似FreeUI这种处理思路下的人机界面，每个界面都特别像多任务机制里的一个个独立的任务。
既然是多任务，那每一个任务——在这里是每一个页面，都应该是独立的，拥有独立的运行时间和独立的堆栈。这样，每一个任务的编写才会变得纯粹和简单。
对于界面也一样，只有这种情况下，界面与界面之间的耦合才会被解耦，否则，一套界面跑下来，必然顾此失彼，最后谁都会疯掉的。
说到这里，我想很多人又会担心存储空间消耗太厉害了，怕8位机什么的承受不起了——在我的记忆里，每一次我打算用类似的思路去重新组织一些实现的时候，基本上都会有人跳出来，说这样资源消耗太厉害，低端系统消受不起。
然而，尽管这次，对FreeUI的资源消耗情况我没有做一个仔细清算，但是，从我以往的经验和我现在实际实现的方案里，其实，我从来没有滥用大数组，很多地方都是用指针来避免不必要的空间浪费。
所以，我觉得，实际上还是该用多少我这里就用多少，只是相对来说会多出很小一个比例的“管理开销”。
所以，这种担心大可不必——许多时候，我一直把这种质疑视为 裹脚布或者偷懒的借口。
非常喜欢楼主的freeui，一直都被单片机的人机界面所困扰，虽然写过很多，但方式思路都不统一，显得杂乱。看了楼主的思路觉得还是不错的，可以借鉴一下msos 的hmii，思路是基于c#上位机的方式，还是很好理解的，我感觉你的这个和他有异曲同工之处。
eeworld的第一个回帖献给你了，你说中了我的痛点
非常感谢。
然而楼主最近再一次沉下去了。
就不说啥啥加班快疯了神码的。
但是楼主这次打死都不会放弃的。
这几天加班少了，是在寂寞空虚冷在想的是怎么把文档写好.......
那什么，我弄了一下好像还是看得不是很清，所以，看不清楚请点击图片看大图.......
那什么，先将就看着吧，又得回去搬砖了，真的，不然明天我就会被很多人掐死的，这么说，你们能不能原谅我已经超过一周没有更新FreeUI的 git了？我估计最多春节放假的时候，我还是够时间好好写的，为了不让你们口吐白沫，我是多么的操劳过度啊卧槽~~
本帖最后由 辛昕 于 2016-2-6 21:09 编辑
京公网安备 11010802033920号
