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

　　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的过程中，能够于多个层次上都有所收获。

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