Android 系统开发问题杂谈



Android 系统自从发布以来, 特别是 HTC G1 以及最近的 Magic 上市, 不但造成了手机业界的轰动, 也吸引了众多开发人员的目光. 从其上的应用程序的开发方式来看, 基于 Java 的开发比起同样是大热门的 iPhone 来无疑门槛相对要低一些. 这也是吸引开发人员的一个因素; 另一方面, 由于 Android 是一个基于 Apache License 发布的开放源码的系统, 自然引起了手机厂商以及运营商对其进行定制以将其变成自己的系统的兴趣. 但是, 这种开放性以及系统修改的随意性在带来其好处的同时, 也会对系统以及应用程序的开发造成一定程度的困扰.

Android 版本的问题


在 Android 以 Apache License 开放出来之后, 这个时候的 Android 系统的版本 和 SDK 的版本都是 1.0. 作为工作在移动开发领域的开发者, 我就常常有这么一个困惑. Android 的版本将会如何演进? 根据不同版本开发的应用程序之间的兼容性如何保证? 看一下 Apple 在 iPhone 系统上的策略. Apple 的策略很简单, 应用程序必须兼容我的最新版本. 因为 Apple 控制了从手机, 系统到应用程序分发的所有渠道, 它完全可以这么做. 但是 Android 不一样了, 由于 Android 系统的开放性, 类似于 iPhone 的强制手段是无法执行的. 这必然造成应用程序的兼容性问题. 而且, 作为 Android 应用的官方分发渠道, Android Market 又如何控制不同版本的系统需要的适应不同版本的应用呢?

随着今年 5 月份 Android SDK 1.5 以及 Android 系统 1.5 的正式发布, Google 给出了一个答案. 在 Android 应用程序的 manifest 中, 必须标明兼容的最小版本号. 这是在开发人员将应用程序发布到 Market 时 market 系统会进行的一项强制性检查. 对于开发中用到的 API, Android SDK 引入了一个 api level 的概念. 应用程序可以通过检查 api level 来获知运行的系统的版本. 这样, 基本上可以解决不同版本间的应用程序兼容性问题了. 比如说, 输入法是在 SDK 1.5 之后才支持的, 那么, 作为一个发布到 Android Market 上的输入法, 必须指明最小的兼容版本号为 1.5, 这样就不会引起诸如把输入法安装到 1.0/1.1 的系统上然后抱怨无法使用的问题了.

问题是, 虽然 android 定义了这样的解决方法, 对于应用程序的开发者来说, 由于没有类似 iPhone AppStore 的强制性条款, 是否及时能作出响应还是一个问题, 更不用说一旦涉及到厂商定制系统的时候, 问题会变得更加严重.

在厂商定制系统上运行的应用的兼容性问题


作为一个开放的系统, 如何使得根据 Google 的 Android SDK 开发出来的应用程序能够在各个厂商或多或少的定制中都能工作? 这是一个比前面的适应 Android 系统的不同版本更严重的问题. 厂商或者运营商定制的系统往往会加入很多自己的应用甚至自己的修改, 在 Android 系统上这个技术上很容易而且知识产权上也无问题, 只是厂商或者运营商定制的系统是否同样能够运行来自于 Android market 的, 基于 Google 提供的 Android SDK 开发的应用呢? 这个是很不确定的.

这里就要提到移动的 OMS 了. 移动的 OMS 的研发是基于 Android 1.0 的 (其实应该是比正式的 1.0 更早的版本). 为了适应移动的需要, 在 Android 上做的改动着实不少. 从最近透露出来的情况是已经能兼容大多数 Google 本身的应用了, 只是 maps 据说还没法跑起来. 问题是 OMS 还不见上市, android 系统已经升级到 1.5 了, 而且 2.0 分支上的开发也已经进行得紧锣密鼓了. 不知道采用 OMS 的中移动定制机上市的时候, 有多少 Android Market 上的应用能够顺利运行呢? 当然, 移动或许并不在乎这个, 好歹 OMS 也算是号称移动自己的系统了. 而且移动也积极地在建立自己的应用软件商店 M-Market, 不过从上个月看到的测试界面来看, 好象只有 Windows Mobile 和 Symbian 的应用.

这个问题不仅仅是移动有, 所有有志于定制机的厂商或者运行商都有. 而且, 一旦有许多的定制系统出现, 将来的发展就会如同 Unix 一样发展出无数的方言来. 虽然大家都是基于 android 的系统, 应用程序之间却不能互换使用, 这也是一个有趣的现象. 但愿不会称为现实吧.


不同的移动设备的问题


已经有不少厂商在动把 Android 系统弄到别的设备诸如 MID 或者上网本上去了. 最新的消息是 Acer 在 Computex 2009 上展出了使用 android 的上网本系统. 只是 Computex 2009 在台湾, 无缘得见其上到底运行了些什么应用程序. 只是, 从笔者多年在不同规模和结构的平台上开发的经验来看, 让应用程序在这些不同的平台上运行起来的代价是非常高昂的.

从简单地说, 屏幕的尺寸和分辨率的不同, 就会造成应用程序的很大问题. 针对 480x320 的 G1 屏幕开发的程序, 大多数都不会在 800x600 的桌面显示器上有良好的效果. 而且显示范围的大小, 直接决定了用户界面的设计策擽. 而且, 有无物理键盘, 是否触摸屏对于应用程序行为和可操作性的影响也是巨大的. 莫非以后会出现专为这个厂商的上网本开发的 android 程序, 专为那个厂商的 MID 开发的 android 应用? 当然也不是说不可能, 只是成功的机会很小吧.

从系统本身来说, android 的 Dalvik VM 是专门为 ARM, 或者说为有大量寄存器的 RISC 系统优化的. 要把 Dalvik 移植到不同的 CPU 结构上 - 不是说不可以 - 至少性能上会有很大的问题存在.


山寨, 著名的山寨


Android 系统一发布, 大家都欢欣鼓舞, 真是山寨的理想系统啊. 没有知识产权问题, 随便怎么使都不是盗版. 仿佛山寨的春天就要来了. 然而, 事情哪有想象得那么美好, 对 Android 系统的移植与定制不是山寨厂商的软件力量能够顺利完成的. 如果按照山寨的惯例, 直接用线程的整体方案复制, 那么, 采用 Android 有什么意义吗? 不如沿用 MTK 的好, 至少那个成熟有效几乎不需要任何研发成本. 况且联发科已经准备提供面向 Windows Mobile 的整体方案了, 山寨厂商们不如简单盗版 WM 来得简单快捷. 所以, 寄希望于山寨能将 android 发扬光大乃至繁荣昌盛是不切实际的, 至少我个人这么认为.

象 android 这样的一个系统, 面向的就是智能移动设备. 其成功与否, 完全取决于应用的丰富程度. 而山寨是卖手机的, 应用跟他们无关. 就算为了卖手机必须有应用, 也就仅仅局限在这些应用上. 山寨系统是不会去看应用的兼容性和开发的可能性的. 从这个意义上来说, 即使有山寨的 android 系统出现, 那也跟 MTK 没什么区别.