- 程序有所改变。发帖如还有问题请报告
- 【征集】西西河的经济学，及清流措施，需要主动参与者，『稷下学宫』新认证方式，24年网站打算和努力目标
主题：【原创】手机应用开发商之烦恼 [4] 跨平台 -- 邓侃
家园 【原创】手机应用开发商之烦恼 [4] 跨平台 [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的进展。
本帖一共被 1 帖 引用 (帖内工具实现)家园 跨平台 好文！前几天看到一则新闻，说24家运营商联合欲统一开发平台。http://www.techweb.com.cn/news/2010-02-16/539797.shtml
这现实吗？如果能实现的话，是不是就能解决跨平台难这个问题呢？
家园 唱点“反调” 总结了一下读Chrome的经验，有些不同的观点。
1.跨平台的编译。这个一要看公司可调动的人力资源的情况，二要看是否是Open Source。Chromium中就准备了两套方案：VC 200x中的Solution文件的和x:\chromium\src\build目录中的SCons配置文件（俺是不懂那个SCons，但起码看静态的文件是这样的，见笑见笑）。这个吗，好像前几年流传的段子 --- 如果俺有钱了,俺就弄两个手机，左手拿移动,右手持联通，想联通就联通，想移动就移动。俺是Windows上的懒人，绝对用Solution文件。因为大多数公司是“没钱的”，而且不Open Source，所以楼主的观点是“没有错误”的。
2.如果是NATIVE BINARY CODE,所谓之跨平台语言根本没有什么选择 --- 就是C/C++。所以选语言不如说选基础框架,Chrome的选择包括基础函数库 --- ICU（International Components for Unicode），插件接口 --- NPAPI，图形方面，自然是Google的私家货 --- skia。反正用VS 200x不用MFC。出于Windows上插件兼容性的考虑，ATL用了一点点。
3.第3条俺比较赞同，模块的分割与抽象很重要。这方面Chrome做的比较好，比如Renderer模块中与webkit的衔接，Plugin中和第三方的衔接。
4.该用特定平台的地方不要含糊 --- 80:20法则。Chrome在进程安全性方面，使用了Windows的DEP，Desktop, 进程Token, Job等等。LINUX上有没有类似的东西俺不知道，俺对那上面的开发是一窍不通。
5.叫什么名堂不重要，神似胜过形似 --- 好东西要大胆的借鉴，管它是来自M$还是其它。比如Factory,scoped_ptr,Release(),AddRef()。
6.如果大家的技术都趋向于同质，大家是否会沦落为目前中国的状态 ---“世界工厂”，生存链的底端？如何保持自己的核心竞争能力？
- 复 唱点“反调”
家园 这个反调唱得好 之所以要解决跨平台的问题，动机是给应用开发商减轻负担，尤其是鼓励和培育千千万万个中小型应用开发商，甚至于个人也可以鼓捣点东西，就像很多个人用户自己动手设计QQ空间皮肤，表情，又譬如很多个人用户自己动手设计Facebook游戏，小工具一样。
1. 跨平台的编译。同意你的意见。
2. 选语言不如说选lib，这话有洞见。
太守能否多说几句ICU，NPAPI, Skia？Skia和OpenGL是什么关系？请教一下。另外，VS200X和MFC的问题，ATL的问题，相信感兴趣的人不少。
坑挖不填，后果很严重，呵呵。
3. 想一起去了。
4. 平台的特定lib。不是愿意不愿意的问题，而是回避不了的问题。
打个比方，不同的硬件对应不同驱动器。所以OS的代码不可能100%跨平台。
5. 拿来主义。你所说的借鉴，是模仿M$的Factory,scoped_ptr,Release(),AddRef()，开发一套跨平台的lib？
6. 核心竞争力。是产品功能的不同。跨平台的负担越轻，开发商或者个体开发者越有精力去繁荣产品的功能，而不是疲于本命，推广单一产品去多个平台。
多谢这么有深度的反馈。
家园 好观点。 俺分析Chrome的目的之一也是想看看Google里面的牛人是如何具体地解决跨平台的问题。
家园 开发手机应用受哪个硬件因素的制约最大？ 邓兄能否谈谈？
比如带宽、处理器计算能力、存储容量、电池等等。
家园 制约的排序 如果让我给这四个制约派个顺序，
1. 存储容量，
2. 带宽，
3. 电池，
4. 计算能力。
各家有各家的麻烦事。我这样排序，与我们开发的产品有关，我们的产品涉及到大数据量。
容量不够就得去网络服务器拿，带宽的需求就高。一来一回时间就拖得久，电池就吃紧。
计算能力虽然重要，但是比起其它三个来，问题就不是那么那么的突出。查看一下系统在各个环节的消耗，发现IO最大，而不是计算复杂性。
对于其它应用开发商而言，他们的瓶颈或许在CPU上。所以排序没有普遍认同的定论。
家园 对makefile系统的一个解决方案 OpenEmbedded，比如poky linux 就是利用这个。
但是这个系统主要是用在embedeed linux方面的。
