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构建的参数,还就是通过配置文件的方式,用单例看似很正确。但是,对于整体架构设计上,却是错误的。我是极不愿意使用单例模式的。今天闲时讨论,团队的小伙子说自己用单例的时候觉得好爽,好方便,同事于此时给出了一句评语,我觉得很合适:你觉得很方便的地方,必然意味着其他人的不方便。这也是我一直以来秉承的理念,没有那么绝好的方案,都是在折衷。如果为了项目长久的发展顺利,我宁愿不要当下工作上的一些方便。

 

 

 

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


[ 主页 ]
COMMENTS
POST A COMMENT

(optional)



(optional)