主题：【原创】手机应用开发商之烦恼 [4] 跨平台 -- 邓侃

[1] 苦恼

[2] 卖点

[3] 意境

[4] 跨平台

手机的型号款式众多。每开发一个应用软件，开发者面临的头痛事情，就是要移植到各种不同的OS平台，以及每个平台上不同型号和版本的手机。不仅如此，每当手机制造商推出一款新的手机，应用开发商不得不被动地跟进，这样更进一步增加了移植的负担。

如何让移植的工作变得轻松？这就是所谓跨平台的问题。实现跨平台的思路有三个。

1. 跨平台的编译。

说到不同的平台，大家首先想到的是不同平台的APIs不同。不同APIs固然很麻烦，但是这不是麻烦的全部分。源代码的编译，往往依赖一些libs，还要调用平台的环境变量。不同的平台，放置libs的位置不同，系统环境变量也各不相同。所以就有Automake和Autoconf这些工具，试图实现跨平台的编译。

但是Automake和Autoconf的入门壁垒很高，不容易掌握。如果有谁不信，不妨下载Apache HTTP server的源代码，和附带的makefile和config.in。打开这些makefile和config.in，看看是不是好懂。然后改写一部份源代码，让Apache做一些很酷很搞怪的动作。有些人抱怨，说makefile和config.in很邪恶。当你做完上述事情以后，或许你会理解和同情这些人的情绪。

为什么抱怨makefile和config.in很邪恶？其中很重要的原因是如何处理各个模块之间的相互依赖关系，libs的路径，以及环境变量。这些操作基本上是字符串的处理，makefile和config.in采用的是regular expression这个字符串处理工具。Regular expression中文翻译是正则表达式。凭心而论，正则表达式的发明和设计非常聪明。但是过于聪明了，就变成阳春白雪，不便于读解。拿一段稍微复杂一点的正则表达式过来，一眼读过去，往往一头雾水不解其意。一个字符一个字符死盯着读，也无济于事。无可奈何之余，只好分拆开来，一段一段在电脑里运行，看看究竟是做什么的。

如果满篇充斥着这样折磨人的正则表达式，用户自然会有怨气。不幸的是，类似Apache server这样稍微有点规模的系统，它们的makefile和config.in都是这样的天书。

光抱怨没有用，于是英雄挺身而出，解开发者于倒悬。SCons的办法是用Python来处理各个模块之间的依赖关系，libs的路径，以及环境变量。SCons的想法很简单，用程序来解决字符串处理，回避折磨人的正则表达式。你别说，SCons真的好使，应验了一句老话，简单就是美。

虽然SCons让跨平台的编译变得轻松一些，但是对于开发者而言，每当移植一个新平台新型号，都必须扩充原有的Scons script。所以，SCons的贡献局限于减轻负担，但是负担依然存在。

2. 跨平台的语言。

Java喊的口号是write once run anywhere。 开发者写Java代码很爽，因为跨平台的工作推卸给了Java Virtual Machine（JVM）。换而言之，如果真的实现write once run anywhere这个理想，那么每个平台，每个型号，都得提供对应的JVM。

J2ME的推广并不顺利，原因不仅仅是J2ME在技术上存在缺陷，而且更重要的是厂商之间的协作。Sun Microsystem是IT业强人，Nokia与其它手机制造商也是强人。强强联手固然会有巨大的商业前途，但是困难是彼此都是老大，谁也不服小。更不要说很难达成彼此都觉得公平的利益分配方案。

C#的设计思路与Java很像，但是除了Windows，有没有听说其它平台支持C#？

不久前，Google也来趟浑水，另起炉灶搞了Android。Android里面那个Delvik virtual machine，运行效率的确比J2ME virtual machine要高。究其原因，Delvik其实不是一个彻头彻尾的虚拟机，这是另外一个故事，按下不表。Google号召手机制造商们组织起一个联盟，都来使用Android。这对于应用开发商而言，当然是福音，但是手机制造商们是不是衷心拥护，有待观察。

J2ME，C#和Android，描绘的前景都很诱人，但是严酷的现实是，对于手机应用开发者而言，不仅要移植Symbian，Brew，而且还要移植J2ME，C#和Android，负担不是降低了，反而更重了。

另外，Virtual machine与Native OS相比，运行效率多少会差一点。对于简单的手机应用来讲，这个缺陷不矛盾。但是如果手机应用涉及到大量数据，导致高额的IO和CPU消耗，virtual machine的缺陷就变得明显。

3. 拆分应用程序，提炼跨平台的模块。

很多手机应用程序，都涉及到用户界面的渲染，譬如绘制button之类控件，还有影像的显示。都涉及到与网络服务器的交互，譬如类似于HTML里面form那样的功能。都涉及到与用户的交互，譬如用户触摸屏幕的不同部位，应用程序有不同响应。

界面渲染，与网络服务器交互，与用户交互，这些功能，浏览器里都有。设想一下，把应用程序中有关界面渲染，与网络服务器和用户的交互分离出来，交给浏览器去完成，那么手机应用的开发强度就会大大降低。开发商们要做的工作主要是设计HTML页面，调试JavaScript。

但是单纯依赖HTML + JavaScript 还不够。手机应用程序不仅要与网络服务器交互，与用户交互，还需要与手机本地的功能块交互，譬如地址本，譬如GPS驱动模块，等等。所以，除了HTML + JavaScript，还要有Plug-in。手机应用开发商的开发负担，将来主要集中在开发这些plug-ins上。

WebKit和V8很值得研究，WebKit作为一个渲染机（Rendering engine），主要负责HTML的解析和界面的渲染。V8是新一代JavaScript engine。之所以值得研究，有两个原因。a. 它们都是开源项目，b. WebKit已经包含在多个平台上，譬如Symbian，iPhone和Android。

前面说了三个实现跨平台的思路，对于手机开发者而言，应该做什么样的选择？个人的建议是，

1. 基点放在1。

2. 着力发展3，plug-in部份结合1。

3. 密切跟踪2的进展。

• 【原创】手机应用开发商之烦恼 [5] 纵深