五千年(敝帚自珍)

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

共:💬34 🌺82
全看分页树展 · 主题
家园 【原创】手机应用开发商之烦恼 [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的进展。

关键词(Tags): #手机应用#浏览器#平台元宝推荐:铁手,

本帖一共被 1 帖 引用 (帖内工具实现)
全看分页树展 · 主题


有趣有益,互惠互利;开阔视野,博采众长。
虚拟的网络,真实的人。天南地北客,相逢皆朋友

Copyright © cchere 西西河