UI编辑器 vs 手写UI代码

2019-09-21

   相信做客户端UI的时候，肯定会如何实现UI而争论。是使用UI编辑器，还是完全依赖于手写。而且，对于不同类型的客户端UI，我们还需要更细致的区分一下，如桌面客户端UI、移动端UI、网页端UI、H5。 还需要针对不同类型的项目进行区分讨论，持续运营的互联网项目，传统企业项目，个人项目。如；还需要目标受众进行区分：to B端、to C端。我们先讨论一下各种情况，尝试理解各种情况下会遇到的问题。
   对于网页端UI。早些年，还能05年左右吧，那时候Dreamweaver使用很广泛，可能不少人没有见过，那时候的一些网站很简陋，看起来就是Dreamweaver这类编辑器弄出来的。要想交互做的好一些，就弄上一些Flash。然而，不久之后，这类工具市场就越来越小了，更多的人开始手写Web UI，以追求更加可控的页面。我认为，原因有两方面，其一，原来Dreamweaver这类的工具，本为静态内容网站所设计，写网页的人相当于现在的前端UI。但是，后来网站都趋于动态内容。此类工具难以跟上步伐，后来，Eclipse、ZenD Studio为代表的前后端一体工具慢慢增多，后端程序员开始直接介入部分UI代码 。这也是后来再提出来的前后端分离的源头。其二，由于网页端交互越来越复杂，JS lib越来越复杂强大，JS的介入越来越多，非手写代码不能控制HTML DOM与CSS attribute。当前，我们依然可以看到，一些偏重B端的业务，仍然会使用动态内容网站，仍使用UI编辑器类似的功能。
   对于H5，本来出现的就很晚，且总体应用场景较为简单，且运行环境差异性较大。还没有看到统一的UI编辑器，且，其开发难度本就较为简单。
   移动端UI上，编辑器的使用一直是比较广泛的。就如Android，其编辑器与Java 语言的特征之间，联系的就非常紧密，很易用，且不易出错。所以，使用范围较广。同样的移动平台，iOS使用Obj-C，其语言与UI文件之间的交互能力较弱（相较于Java），故其编辑器使用率也比Android 平台开发的要少很多。更早期的Sybian OS，由于使用变种C++，估计是不可能做出好用的UI编辑器的。Win10 Mobile，使用UWP开发，以及更早的WP系统，都是出自巨硬，且巨硬一直竭力为程序员服务，能帮程序员做的活儿都做了，从这个层面上，巨硬的技术是真的牛。且，巨硬的UI技术以C#实现，其语言特性甚至比Java更高级先进一点，以编辑器的形式实现UI会更简单且可操作性更强。非基于C++ 技术的工具可比。
   对于桌面客户端，它的情况比较复杂。既有Qt Designer、VS WinForm、UWP这样的优秀工具与技术，也有 MFC、gtk等老旧的技术，也有qtquick、pyqt等混合编程的技术，还有三维可视化、游戏，桌面端的UI编程，也是各种UI编程中最为复杂的。这里所说的“复杂“，从从技术难度本身，与业务难度上两方面描述的。桌面端UI开发，选择方案也是很多的。多，并不代表着好事，我认为相反，意味着开发者需要明确知道如何选择方案。若使用C++来写客户端，实际上没有特别好用的UI编辑器。这是由C++语言的特性决定的。因为C++缺乏反射机制，所以，较难以从配置文件的字符串直接构造对象，难以直接解析method，与字符串对应上。Qt Designer是C++语言上UI编辑器做的最好的技术了，其有限的支持窗口提升，从而提升表达能力。但是，提升之后，完全无法在工具上预览效果。而且，由于C++语法复杂，Qt Designer时而不能正常工作，找不到slot。UI文件就是XML，经uic编译器产生的C++代码，可控性上差了很多。基于Java/C#的UI技术，多用于业务交互交互上，不偏重于硬件操纵、核心算法高效性。
   我们列举一下两种方式的优缺点：
纯手工编码的方式的优点：

1. 完全的可控能力

2. 复用性高

缺点：

1. 难度大，学习成本高

2. 开发效率偏低、开发成本高

UI编辑器优点有：

1. 简单，快速学习、迅速上手

2. 开发效率高，成本低

缺点：

1. 难以代码检查。

2. 若多人协作，则几乎不可能实现。版本管理工具无法实现UI描述文件（XML或者其他描述语言）。

3. 布局控制 与 样式 控制难以协同工作。如Qt的控件提升之后，常会出现css 失效的问题。

4. 难以复用（准确来说是 描述语言的结果 难以复用）

5. 相较于手写代码，使用起来较为冗杂，对于特殊需求，容易傻眼，难以在UI文件基础上定制。

   上述的说法是相对的。例如，一个本来只能使用C++/Qt开发的项目，却采用C# .Net技术方案，核心部分仍使用C/C++开发，仍说使用UI文件方案更好，就是混淆视听了。判断准则必需在更大的合理选择下采用意义。上面所说的成本，并非采用的这种技术导致的成本，本该只能手写UI代码的项目，却采用了UI文件，这成本翻倍了不一定能搞定。我尝试在这里给出一个评判标准，对于一个项目，我们改如何选择 UI 的实现方案。
   开发者必须针对不同的项目，选择合理的技术。没有深入的研究过不熟悉的东西，就应该闭口不言。首先，是编程语言与工具的选择。如果非必要，则不选择较低层次的语言。例如，如果项目完全可以使用Java/C#实现，就没有必要考虑C++了。若项目能够使用PyQt/QtQuick等技术，就没有必要用C#这样的原生技术了。若能够使用浏览器/服务器 方案实现，就完全没有必要考虑其他选项了。
   若选择使用C++技术，就需要判断项目的业务类型如何了。若是持续迭代项目，追求目标是：稳定、快速迭代。大家很容易把“快速迭代”作为首要目标，其实不是，没有“稳定”这个基础特征，是无法实现快速迭代的，开发会陷入泥潭，难以自拔。”快“与”稳定“，必需均衡。互联网项目多选择手写代码，也是因为因为需要对代码进行更深入的掌控。若长久迭代运营，则要选择手写UI代码，至少主框架部分手写，不重要部分使用编辑器与UI文件方式。对于稍微复杂的界面，手写代码与UI文件的方式，时间投入可能差不多。对于极为复杂的界面，我的经验证明，使用UI文件的方式会花费更多的时间，而且，这些复杂的页面，后期肯定伴随着更加频繁的修改，时间花费就会更多。即使初始使用UI文件，后期也会被迫改为手写的。
   对于给第三方做的项目，一般来说，连代码质量都不是首要追求目标了，可维护性要求就更低了，只要能交付就行。客户方不愿意为”可维护性“这个特征多处费用，开发者自然不会花费精力。UI实现上，尽量使用编辑器。
   对于小工具，可以使用编辑器。比较独立的小工具，我们需要搞清楚是否需要UI。没必要的，直接命令行就好了。所谓的交互友好，真的有必要吗？学习成本与开发成本之间，真的调研过吗？对于稍微有所依赖的小工具，可以使用PyQt这样的绑定。
   我们之前的CAD项目，初期也使用了UI文件，一段时间后完全不用了。以Qt为例，因为通过窗口提升，我们只能使用UI class 的原生构造接口。是难以传入自定义参数的。当然了，我说的是难以，当然可以使用单例，因为部分控制UI构建的参数，还就是通过配置文件的方式，用单例看似很正确。但是，对于整体架构设计上，却是错误的。我是极不愿意使用单例模式的。今天闲时讨论，团队的小伙子说自己用单例的时候觉得好爽，好方便，同事于此时给出了一句评语，我觉得很合适：你觉得很方便的地方，必然意味着其他人的不方便。这也是我一直以来秉承的理念，没有那么绝好的方案，都是在折衷。如果为了项目长久的发展顺利，我宁愿不要当下工作上的一些方便。

 

 

 

如果有任何意见，欢迎留言讨论。


[ 主页 ]