客户端UI开发浏览器编程技术浅析一

           我们在客户端编程中,经常会遇到比较复杂的UI交互,特效等。最开始最容易上手的是内嵌浏览器控件,在2000年左右的时候,主要页面和交互都用html来实现,有过mfc开发经验的vc程序员都知道,在开发向导里头拖入一个IE控件,一个网页就可以展示出来了。其他windows平台的编程语言如dephi, c#, vb等都有类似的经验体会。要show一个网页就是如此的简单,但是那时候的html还没有现在如此之强大,开发一个网页, 尤其是漂亮的网页也不是一个简单的事情。绝大多数的内嵌浏览器都是IE控件,有着一样的滚动条,右键菜单。

          后来很多UI开发框架出来了,包括当时著名的MFC,影响了很大一批人(虽然到现在MFC几乎已经被废弃了)。MFC是基于windows原生窗体式控件的封装,每个小的组件就是一个独立的窗体,据说里面有n多设计上的缺陷,要做个漂亮的界面也不容易。不过这个时候程序员们基本有个共识,以前的IE控件式没什么技术含量,本地交互也很困难,很难做到原生程序那么如臂使指,MFC 才比较有成就感。拖控件是UI开发的第一个步骤。那时候软件数量和种类都比较少,MFC是很多vc程序员的首选,用户首先关注的是软件的功能。

          随着互联网的进一步发展,同类的软件层出不穷,随便百度一个功能型软件都能找出一大堆,用户已经不再满足功能上的实现,视觉上的享受也成为一个软件是否有吸引力的重要指标。窗口式拖控件的做法越来越显出其弊端,每个控件都是一个子窗体,消耗资源比较多,控件默认都是随windows原生风格而出现,要想定制十分之困难。大家都被绑在微软的windows上,别提跨平台了。Direct UI应运而生,浑然一体的界面风格,方便的UI资源编辑,支持换肤不再是一件很麻烦的事情,一些号称跨平台的库也出现了,如Qt,wxwidgets。原先的窗体式控件被抽象成一张画布上的一个子元素,各种控件,消息响应的概念仍然借用过来,但具体实现已经脱离了windows窗体的先天限制。静态布局加脚本语言控制渐渐成为主流。

          谈了这么多UI开发发展中经历的历程,其实我很惭愧,因为我并不擅长做UI,也没有很多的UI开发经验,这纯粹是我从底层技术发展变迁总结的一点个人愚见。但由于工作关系，又与浏览器打了不少交道，所以才产生了写这篇文章的想法，仅供有同样问题的后来者参考。

         谈到浏览器,web开发人员都能意识到它本质上其实是一个运行html+js+css的工具软件。输入是不同种类的文本,输出是视觉上各种各样的效果,并且能和用户交互。在近几年的项目中,我也总是在思考客户端最好的UI开发模式是什么,大量重复的UI控件的开发工作怎么才能最简单高效的完成,Direct UI的接口如何方能简单好用。及至用过IE做界面开发,又转用过cef框架的webkit做界面开发之后,我才意识到其实浏览器本身就是一个设计得很好的Direct UI开发框架。静态布局有html文本去描述,动态交互有js文本去执行。完全符合了静态布局+动态控制的需求!没有东西是万能的,使用浏览器框架开发好处不用多说了,只要会html和js的web开发者就能做出很漂亮的界面,尤其是html标准日益规范化,强大化,html5的出现更是让前端开发者可以方便的用实现一个web版的本地应用程序。我在这里主要谈一下它的缺点,与其他UI引擎库相比,浏览器本身是个很重的开发框架,它包括了太多的东西,http网络请求,本地cache和cookie的存储,js脚本引擎解释,UI渲染。它的UI渲染引擎十分庞大丰富,全是html组件,有不少内置的特性,而且全部脚本化了。一个UI引擎最关注的的是界面渲染,能不能实现基本特效,是否能方便的扩展。但是浏览器显然不止这些,它从设计之初就更关注web页面的下载和渲染,它的渲染引擎很难扩展(也许更专业的人士觉得它简单),像是一个黑盒子,完全从html标准而来!幸而现在html标准发展很迅速,前些年的时候就只能做很粗糙的界面或者要花很大功夫。浏览器还要支持多窗口文档浏览,并发访问,所以它通常有很复杂的线程进程模型,而UI引擎本身是个库,可能根本没有线程模型,由调用者自己随心设计,这就使得浏览器要深入掌握更加困难,总会有很多东西无法掌控的感觉,不过这不影响它的使用,因为其实嵌入一个浏览器并和它做一些基本交互还是比较简单的。最后还有一个对某些应用来说或许很致命的缺点,太庞大的系统框架导致打包浏览器的运行时库非常之大,一般都超过20M,如果你的程序本身逻辑处理只有不到1M,只有一两个文件,但为了做UI渲染就不得不加上浏览器的所有运行库,看着发行包里面自己的代码只占10%都不到,开发者情何以堪?如果不带,只有微软的IE控件基本所有用户电脑上都有,但是那就意味着你的网页要做无数的浏览器兼容工作,这对IE来说无疑是个噩梦!

       总结一下,浏览器框架更倾向于一个适合web页面展示的平台级应用,如果你本来就是这样的应用,那这无疑是很好的选择;如果本地特性更多,交互逻辑更复杂,那么浏览器可能不是一个好的选择,它对前期开发原型十分方便迅速,但是越到后期越有定制需求的时候就需要更加深入的研究它了。接下来的几篇文章会依次详细的总结一下IE控件和cef框架的开发中用到的一些技术点。按照浏览器通常会提供的接口,浏览器的一个基本模型如下:

       

             IE和cef封装的浏览器框架模型其实和上图都是差不多的,只不过具体的接口,细节不同。我个人认为对浏览器的理解研究还比较浅薄,但使用这些接口已经能满足大部分应用程序的需要了。总体来说,浏览器和natvie交互的两个关键技术是 1. 自定义协议的处理 2.native对象导入到js环境中.其他都是一些细节点,但有时候研究起来也很费劲。这再一次印证了前面的观点,自定义协议处理实现了静态布局加载,natvie对象交互实现了动态控制通信.这正是一个完整的UI引擎应该提供的两个基本特性。后面的文章会逐渐阐述一些关键技术点和相关示例代码。