五千年(敝帚自珍)

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

共:💬34 🌺82
分页树展主题 · 全看首页 上页
/ 3
下页 末页
  • 家园 【原创】手机应用开发商之烦恼 [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 帖 引用 (帖内工具实现)
    • 家园 跨平台

      好文!前几天看到一则新闻,说24家运营商联合欲统一开发平台。http://www.techweb.com.cn/news/2010-02-16/539797.shtml

      这现实吗?如果能实现的话,是不是就能解决跨平台难这个问题呢?

      • 家园 但也不能忽视恐龙们的怒吼

        如果这些恐龙真的能言行一致联合起来,那还真的不能小瞧,毕竟顾客群都在他们手上。当然这事说说容易,难度很大,目的可能是讨价还价。

      • 家园 过气恐龙的梦呓而已

        对“Dumb Pipe”的恐惧驱使它们利用自己掌握的用户资源做最后的垂死挣扎。无数的硬件平台,无数的软件平台,无数的配置,无数的界面;同样的程序,200MHz CPU/8M RAM 176x120 显示屏和 1GHz CPU / 256M RAM 800x400 显示屏,如何得到同样的用户体验?

        结论:做梦去吧!

    • 家园 唱点“反调”

      总结了一下读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里面的牛人是如何具体地解决跨平台的问题。

      • 家园 想到一起去了

        以前听人介绍Extreme programming,说基本意思就是两个同时在一台电脑前面工作,这样效率高。觉得不可思议。都说多线程并发效率高,没听说多线程集中在同一个任务上效率高。

        后来试了试extreme programming,发现真的效率高。什么原因?因为两个人同时同地点做同一件事,一边干活一边讨论,虽然表面上花了很多时间说话,而不是写程序,但是,1. 工作兴致高,2. 由于充分的讨论,程序的质量好。

        分析WebKit也一样,几个人同时分析,相互讨论,不仅兴致高,而且讨论有深度。

    • 家园 开发手机应用受哪个硬件因素的制约最大?

      邓兄能否谈谈?

      比如带宽、处理器计算能力、存储容量、电池等等。

      • 家园 制约的排序

        如果让我给这四个制约派个顺序,

        1. 存储容量,

        2. 带宽,

        3. 电池,

        4. 计算能力。

        各家有各家的麻烦事。我这样排序,与我们开发的产品有关,我们的产品涉及到大数据量。

        容量不够就得去网络服务器拿,带宽的需求就高。一来一回时间就拖得久,电池就吃紧。

        计算能力虽然重要,但是比起其它三个来,问题就不是那么那么的突出。查看一下系统在各个环节的消耗,发现IO最大,而不是计算复杂性。

        对于其它应用开发商而言,他们的瓶颈或许在CPU上。所以排序没有普遍认同的定论。

        • 家园 谢谢

          俺专业是移动通信,所以有此一问。主要是想不出来除了视频之外还有多少应用需要B3G超过100Mbps的下行速率。听你介绍的这个项目,看来俺们做通信技术的还有的混。

    • 家园 对makefile系统的一个解决方案

      OpenEmbedded,比如poky linux 就是利用这个。

      但是这个系统主要是用在embedeed linux方面的。

分页树展主题 · 全看首页 上页
/ 3
下页 末页


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

Copyright © cchere 西西河