代码改变世界

Android学习笔记(一) - 如果我们来设计Android

2012-02-25 12:12  CreateLight  阅读(1618)  评论(0编辑  收藏  举报

大家应该都背过公式,对于背公式,大体上有这么几种做法:

  1,死背。

  2,看公式的证明,并看懂。

  3,尝试自己证明公式,而后对照“标准”证明。

一般来说,对公式的记忆和使用:3 > 2 > 1。这里只是说明这样一个事实,不打算探究其原因,有兴趣者可以自行翻阅记忆和认知心理学相关书籍。

对Android最熟悉的人是谁?自然是设计并实现它们的工程师。那么,如果我们自己来设计Android,会是怎样的结果呢?

1, 我们的需求

移动计算火了,我们要做移动计算平台。

这个平台应该尽可能支持各种设备,无论是平板电脑、手机、机顶盒还是电冰箱。

这个平台应该尽可能支持各种体系结构,无论是X86、ARM还是MIPS。

出于硬件的摩尔定律(对移动开发来说,免费的午餐还没结束),这个平台应该以功能丰富为主,兼顾低资源下的运行效率。

云来了,所以要有很强的网络功能。

内容为王,所以要有很多丰富的资源。

内容都是人提供的,所以要吸引众多开发者,同时提供很棒的开发工具来提高效率。

要吸引开发者就要让他们觉得有前途和有钱途,并且学习成本低。

2,我们的设计

我们需要操作系统来管理(移动设备的)硬件。不造轮子,并且要求支持众多硬件,支持众多体系结构,功能丰富,配套工具齐全,最好免费开源,最好有强大的网络功能,那么答案几乎只有一个: Linux。

现在有了设备 + OS,还需要各种应用。第一,要有应用,所以要有SDK给开发者;第二,应用要能跑,所以要有相应的运行时环境。这两者是紧密结合的。

SDK需要这些东西:语言、工具链、库。

那么我们有这些选择:

2.1 基于原生机器码

   语言:c语言

      工具链:针对不同体系结构的特定工具链(比如arm用ads或rvct),或者统一用现成的GNU工具链,这些工具链提供从源代码到可执行文件的转换,以及debug。加上其它的一些改善开发效率的通用工具:版本控制、模拟器、log、性能剖析等。还有编辑器或IDE(vi、Emacs及其他)。

   库:标准C库 + GUI库(如GTK) + linux-system-api + 移动设备特定库(触摸、感应、摄像头、LBS等)。

  运行时环境:如同linux,即elf文件的加载及运行。

  优点:C语言能保证有限资源的充分利用,有大量的熟悉C语言的开发者。

       有大量现成工具链。有一定数量熟悉这些工具的开发者。

     库已经被证明(在PC上)能提供足够丰富的功能。

  缺点:C语言偏底层,开发效率不高,对开发者要求较高。

     依赖于体系结构的工具链和库,需要开发者针对不同平台进行构建及部署,导致一个APP有多个版本。而且无论是工具链还是库的使用,还是有一定的技术门槛的。另外特定体系结构的工具(ads\rvct)需要价值不菲的许可证。

     现有的库(基于PC)是否适用于嵌入式环境。

     elf有一定的冗余,是否适合嵌入式环境下资源(空间、网速)相对匮乏的环境。

·  总结:主要优点是:运行效率高(不确保,只是想当然,毕竟没做profiling);主要缺点是:开发效率低(相对而言,应该没什么疑问)。目前移动设备有非常大一部分是基于C语言来开发的,比如功能手机主要的平台:MTK、SPRD、MSTAR、互芯的主要版本(2012年之前),都是基于C开发的。

2.2  基于原生机器码

  语言:C++

  工具链:同C语言系列

  库:STL + QT + linux-system-api + 移动设备特定库

  运行时环境:同C语言系列

  优点:运行效率高。QT在嵌入式领域已经有了一定的应用。

  缺点:C++开发者相对小众,门槛相对较高(高于C)。开发效率相对来说也不高。

     QT使用者相对小众,而且不同版本的许可也比较纠结。

     有成功的前例(Symbian) 和 开发中(???)的系统(MeeGo + Tizen)

  总结:优点和缺点几乎和C语言一样,不同的是:开发效率可能高一些;但门槛也会高一些;现有开发者数量更少一些(虽然有Symbian转行的开发者,但应该还是比不过C系的)。

2.3 基于虚拟机

  语言:java

  工具链:Eclipse + 插件 + jdk + 通用工具

  库:jdk + 大量现成java库 + 移动设备特定库

  运行时环境:JVM

  优点:大量现成的轮子,开发效率较高,现有开发者众多,门槛相对较低,一次开发,四处运行(或者说部署)。

  缺点:性能(空间+时间)是大问题。

     和甲骨文可能有版权方面的纠结。

  总结:如果能改善性能到理想的水准,这将是非常好的选择。改善性能是java社区长盛不衰的话题,这方面的努力和成果也非常多,普遍的做法是提供高效的虚拟机实现(jit、hotspot)。另外就是提供高效的库(特别是针对并发进行优化过的库,以在多核系统上达到高效),或者提供利于并发的语言特性。特别的,对于嵌入式领域,如果在arm架构上运行,那么可以充分利用arm芯片(型号带J的)对java字节码的硬件支持(Jazelle技术),以达到提速的目的。

2.4 基于解释型语言

  语言:其它解释型语言(python、perl、 Ruby等)

  工具链:IDE + 解释器 + 通用工具

  库:相应语言的库。

  运行时环境:相应语言的运行时环境

  优点:高开发效率

  缺点:性能是大问题,是否能提供移动设备所需的丰富功能也是个问题。并且目前没有针对嵌入式做特定的优化(典型的,调试将是比较痛苦的事情)。

  总结:基本不可行。
2.5 其他选择

  还可以用D、Scala、 Go... 这些语言本身功能足够强大(应付系统及应用开发),而且相对较新(通常意味着较优美),但受限于工具、现有开发者、库等因素,并非很好的选择。C#也许语言本身很不错,但显然,这里是不可能的。

3,google - android的设计

  语言:java

  os: Linux

  工具链:Eclipse + 插件(第三方+google针对android自行开发的大量插件)+ jdk(javac) + google自行开发的大量工具。

  库:jdk(j2se的大部分,放弃了awt和swing) + google自己提供的大量类库

  运行时环境 : google自己开发了Dalvik-VM代替了标准的JVM;使用dex代替了标准的java字节码文件(.class).

  优点:选择java能带来大量开发者,能保证开发效率,有丰富的工具可用。

      android-SDK中提供的各种工具确实非常棒。

      dvm 据说效率高于jvm(我现在无法确定),dex确实比class文件紧凑。

  缺点:没有使用arm的Jazelle技术,本来这是很棒的提升相关平台运行效率的方法,原因据说两方面:

      1, dvm不使用标准java字节码,因此无法使用Jazelle。

      2,Jazelle需要arm授权,google不喜欢这个。

      似乎没有针对并发做太多优化。

  不确定:性能真的达标了吗?为什么要有NDK?

      google自己的GUI库确实比j2se中的好吗?

      开发者都喜欢统一,不喜欢分裂。android会造成Linux和java的碎片化吗?

  总结:走着瞧

4,其它:

对比之前我们的需求,google还需要做的就是用“开发android有前途和有钱途”来吸引众多开发者转向或进入android领域,就目前成果来看,无疑是成功的。至于其具体做法和成功的原因,由于个人缺乏这方面的知识和经验,就不妄加评论了。

本文简单的陈述了android的大体设计,后续将会针对android的每一个具体的特定的方面提出自己的设计、对照(并学习)google的设计,从而在学习android的过程中,能够于多个层次上都有所收获。

如果你觉得还有其他的设计方式,或者对本文观点有不同看法,欢迎交流。