安卓架构分析

安卓生态圈简介

.2003年Android公司成立

.2005年被谷歌收购

.2008年，HTC G1-第一部安卓手机发步。

制作一个移动版的操作系统是谷歌最原始的初衷，后来的发展也是这样子进行的。有趣的是安卓的英文的意思是机器人。这也是为什么安卓的图标是个机器人的样子。

Android碎片化问题

· 24,093 Distinct Android devices seen this year

· 18,796 Distinct Android devices seen last year

· 682,000 Devices surveyed for this report.

设备分布图

安卓版本分布图

厂商

https://opensignal.com/reports/2015/08/android-fragmentation/

Android碎片化带来的思考

.难以通用攻击

.难以完全防御

对于安卓测试工程师的会怎么样呢？

恐怕会是这个场景

 

可以想象安卓测试工程师不停的在点点点的情景。所以，在安卓上使用APP通常会出现闪退的情况，就是由于安卓碎片化所带来的兼容性测试难题。据玄武实验室透露，安卓版微信闪退的概率达到百分之一已经不错了。相比之下IOS系统便轻松的多，所以，企业推出APP，通常优先推出IOS版的。

Android跟Java有什么关系？

第一个要思考的就是只用Java便可以进行安卓开发吗？

答案当然是肯定的。作为一个应用开发者仅用java开发安卓是可以，在写这篇文章之前，我跟我们教过安卓开发的老师交流过，她就是一个地地道道的纯java开发者。

那么用java开发的好处是什么？这个问题和谷歌为什么用Linux Kernel而不自己写一个Kernel的答案是一样的。大家都想偷点懒，就像平时写代码总是不自觉的百度一下，有的话，便自己修改一下就用了。毕竟谁都不想35之前就脱发啊！使用java的好处就是可以解决安卓碎片化问题，避免了成堆的BUG，因为使用Java只需要管Java VM以下的针对硬件的API的问题，对于java VM之上的地方基本都是一样的。所以跨平台性很好。

为什么还要使用NDK开发？

● NDK

Native Development Kit（NDK）是一系列工具的集合。它提供了一系列的工具，帮助开发者快速开发C/C++的动态库，并能自动将so和java一起打包成apk。

● JNI

Java Native Interface（JNI）标准是java平台的一部分，JNI是Java语言提供的Java和C/C++相互沟通的机制，Java可以通过JNI调用C/C++代码，C/C++的代码也可以调用java代码。

● JNI与NDK的关系

NDK可以为我们生成了C/C++的动态链接库，JNI是java和C/C++沟通的接口，两者与android没有半毛钱关系，只因为安卓是java程序语言开发，然后通过JNI又能与C/C++沟通，所以我们可以使用NDK+JNI来实现“Java+C”的开发方式。

NDK开发具有以下优点： 
1. 项目需要调用底层的一些C/C++的一些东西（java无法直接访问到操作系统底层（如系统硬件等）），或者已经在C/C++环境下实现了功能代码（大部分现存的开源库都是用C/C++代码编写的。），直接使用即可。NDK开发常用于驱动开发、无线热点共享、数学运算、实时渲染的游戏、音视频处理、文件压缩、人脸识别、图片处理等。 
2. 为了效率更加高效些。将要求高性能的应用逻辑使用C/C++开发，从而提高应用程序的执行效率。但是C/C++代码虽然是高效的，在java与C/C++相互调用时却增大了开销； 
3. 基于安全性的考虑。防止代码被反编译，为了安全起见，使用C/C++语言来编写重要的部分以增大系统的安全性，最后生成so库（用过第三方库的应该都不陌生）便于给人提供方便。（任何有效的代码混淆对于会smail语法反编译你apk是分分钟的事，即使你加壳也不能幸免高手的攻击） 
4. 便于移植。用C/C++写得库可以方便在其他的嵌入式平台上再次使用。

总结的来说，使用C++开发的原因可以归结为两点，一是程序运行速度，一般热衷于ndk开发的，游戏公司居多。这就不用解释了。二是为了安全性考虑，腾讯肯定不会想王者明天成为别人的王者荣耀！

安卓架构分析

 

首先需要从整体上了解Android系统的架构。Android系统大致可以划分为五个层次，它们分别是Linux内核层、硬件抽象层、运行时库层、应用程序框架层和应用程序层。其中，硬件抽象层从实现到使用上涉及了这五个层次。

那么为什么要设置硬件抽象层HAL，其实这是谷歌的一个邪恶的计划。我们都知道Linux的原生的Kelnel是开源的，它是遵循GPL协议的，这个协议是非常严格的，如果你作为厂商对Linux源码进行了修改了的话，就必须公布出去，这显然会损害硬件厂商的利益，所以，谷歌自己加了个HAL层，在上面做一些闭源的开发。所以，严格的说，安卓系统并不是完全的开源，各大厂商都有自己的独特安卓系统，像小米，华为等等

下面是引用了《进击的程序员》中对HAL层的描述：

 

   Android系统的硬件抽象层（Hardware Abstract Layer，HAL）运行在用户空间中，它向下屏蔽硬件驱动模块的实现细节，向上提供硬件访问服务。通过硬件抽象层，Android系统分两层来支持硬件设备，其中一层实现在用户空间中，另一层实现在内核空间中。传统的Linux系统把对硬件的支持完全实现在内核空间中，即把对硬件的支持完全实现在硬件驱动模块中。

Android系统为什么要把对硬件的支持划分为两层来实现呢？我们知道，一方面，Linux内核源代码是遵循GPL协议的，即如果我们在Android系统所使用的Linux内核中添加或者修改了代码，那么就必须将它们公开。因此，如果Android系统像其他的Linux系统一样，把对硬件的支持完全实现在硬件驱动模块中，那么就必须将这些硬件驱动模块源代码公开，这样就可能会损害移动设备厂商的利益，因为这相当于暴露了硬件的实现细节和参数。另一方面，Android系统源代码是遵循Apache License协议的，它允许移动设备厂商添加或者修改Android系统源代码，而又不必公开这些代码。因此，如果把对硬件的支持完全实现在Android系统的用户空间中，那么就可以隐藏硬件的实现细节和参数。然而，这是无法做到的，因为只有内核空间才有特权操作硬件设备。一个折中的解决方案便是将对硬件的支持分别实现在内核空间和用户空间中，其中，内核空间仍然是以硬件驱动模块的形式来支持，不过它只提供简单的硬件访问通道;而用户空间以硬件抽象层模块的形式来支持，它封装了硬件的实现细节和参数。这样就可以保护移动设备厂商的利益了。

介绍Android系统的硬件抽象层的目的在于认识Android系统的体系结构，因为它的实现和使用依次涉及Android系统的硬件驱动模块、硬件抽象层、外部库和运行时库层、应用程序框架层和应用程序层等。

 

  我们还要着重分析一个层是运行时库层，因为Dalvik虚拟机在这个层，接下来我们将围绕运行时库层Dalvik虚拟机，JVM虚拟机，ART，三者的机制和区别。

2014年6月25日，Android L 正式亮相于召开的谷歌I/O大会，Android L 改动幅度较大，谷歌将直接删除Dalvik，代替它的是传闻已久的ART。

 Android 4.4发布了一个ART运行时，准备用来替换掉之前一直使用的Dalvik虚拟机，希望籍此解决饱受诟病的性能问题。这里要分析的是ART是如何无缝替换掉原来的Dalvik虚拟机的。毕竟在原来的系统中，大量的代码都是运行在Dalvik虚拟机里面的。

Dalvik虚拟机与Java虚拟机的最显著区别是它们分别具有不同的类文件格式以及指令集。Dalvik虚拟机使用的是dex（Dalvik Executable）格式的类文件，而Java虚拟机使用的是class格式的类文件。一个dex文件可以包含若干个类，而一个class文件只包括一个类。由于一个dex文件可以包含若干个类，因此它就可以将各个类中重复的字符串和其它常数只保存一次，从而节省了空间，这样就适合在内存和处理器速度有限的手机系统中使用。一般来说，包含有相同类的未压缩dex文件稍小于一个已经压缩的jar文件。

 我们知道，Dalvik虚拟机实则也算是一个Java虚拟机，只不过它执行的不是class文件，而是dex文件。因此，ART运行时最理想的方式也是实现为一个Java虚拟机的形式，这样就可以很容易地将Dalvik虚拟机替换掉。注意，我们这里说实现为Java虚拟机的形式，实际上是指提供一套完全与Java虚拟机兼容的接口。例如，Dalvik虚拟机在接口上与Java虚拟机是一致的，但是它的内部可以是完全不一样的东西。

实际上，ART运行时就是真的和Dalvik虚拟机一样，实现了一套完全兼容Java虚拟机的接口。为了方便描述，接下来我们就将ART运行时称为ART虚拟机，它和Dalvik虚拟机、Java虚拟机关系如图：

 

 

 从图可以知道，Dalvik虚拟机和ART虚拟机都实现了三个用来抽象Java虚拟机的接口：

1. JNI_GetDefaultJavaVMInitArgs -- 获取虚拟机的默认初始化参数

2.JNI_CreateJavaVM -- 在进程中创建虚拟机实例

3. JNI_GetCreatedJavaVMs -- 获取进程中创建的虚拟机实例

在Android系统中，Davik虚拟机实现在libdvm.so中，ART虚拟机实现在libart.so中。也就是说，libdvm.so和libart.so导出了JNI_GetDefaultJavaVMInitArgs、JNI_CreateJavaVM和JNI_GetCreatedJavaVMs这三个接口，供外界调用。

此外，Android系统还提供了一个系统属性persist.sys.dalvik.vm.lib，它的值要么等于libdvm.so，要么等于libart.so。当等于libdvm.so时，就表示当前用的是Dalvik虚拟机，而当等于libart.so时，就表示当前用的是ART虚拟机。

以上描述的Dalvik虚拟机和ART虚拟机的共同之处，当然它们之间最显著还是不同之处。不同的地方就在于，Dalvik虚拟机执行的是dex字节码，ART虚拟机执行的是本地机器码。这意味着Dalvik虚拟机包含有一个解释器，用来执行dex字节码。当然，Android从2.2开始，也包含有JIT（Just-In-Time），用来在运行时动态地将执行频率很高的dex字节码翻译成本地机器码，然后再执行。通过JIT，就可以有效地提高Dalvik虚拟机的执行效率。但是，将dex字节码翻译成本地机器码是发生在应用程序的运行过程中的，并且应用程序每一次重新运行的时候，都要做重做这个翻译工作的。因此，即使用采用了JIT，Dalvik虚拟机的总体性能还是不能与直接执行本地机器码的ART虚拟机相比。

  那么，ART虚拟机执行的本地机器码是从哪里来的呢？Android的运行时从Dalvik虚拟机替换成ART虚拟机，并不要求开发者要将重新将自己的应用直接编译成目标机器码。也就是说，开发者开发出的应用程序经过编译和打包之后，仍然是一个包含dex字节码的APK文件。既然应用程序包含的仍然是dex字节码，而ART虚拟机需要的是本地机器码，这就必然要有一个翻译的过程。这个翻译的过程当然不能发生应用程序运行的时候，否则的话就和Dalvik虚拟机的JIT一样了。在计算机的世界里，与JIT相对的是AOT。AOT进Ahead-Of-Time的简称，它发生在程序运行之前。我们用静态语言（例如C/C++）来开发应用程序的时候，编译器直接就把它们翻译成目标机器码。这种静态语言的编译方式也是AOT的一种。但是前面我们提到，ART虚拟机并不要求开发者将自己的应用直接编译成目标机器码。这样，将应用的dex字节码翻译成本地机器码的最恰当AOT时机就发生在应用安装的时候。

总结

Dalvik和JVM有啥关系？

主要区别：
Dalvik是基于寄存器的，而JVM是基于栈的。
Dalvik运行dex文件，而JVM运行java字节码
自Android 2.2开始，Dalvik支持JIT（just-in-time，即时编译技术）。
优化后的Dalvik较其他标准虚拟机存在一些不同特性:　
1.占用更少空间　
2.为简化翻译，常量池只使用32位索引（存放字符串常量和基本类型常量（public static final）。 常量值通常直接存放在程序代码内部，这样做是安全的，因为它们永远不会被改变。）　
3.标准Java字节码实行8位堆栈指令,Dalvik使用16位指令集直接作用于局部变量。局部变量通常来自4位的“虚拟寄存器”区。这样减少了Dalvik的指令计数，提高了翻译速度。　
　当Android启动时，Dalvik VM 监视所有的程序（APK），并且创建依存关系树，为每个程序优化代码并存储在Dalvik缓存中。Dalvik第一次加载后会生成Cache文件，以提供下次快速加载，所以第一次会很慢。
Dalvik解释器采用预先算好的Goto地址，每个指令对内存的访问都在64字节边界上对齐。这样可以节省一个指令后进行查表的时间。为了强化功能, Dalvik还提供了快速翻译器（Fast Interpreter）。

一般来说,基于堆栈的机器必须使用指令才能从堆栈上的加载和操作数据,因此,相对基于寄存器的机器，它们需要更多的指令才能实现相同的性能。但是基于寄存器机器上的指令必须经过编码,因此,它们的指令往往更大。

Dalvik虚拟机既不支持Java SE 也不支持Java ME类库(如：Java类,AWT和Swing都不支持)。 相反,它使用自己建立的类库（Apache Harmony Java的一个子集）。

什么是ART？

即Android Runtime
ART 的机制与 Dalvik 不同。在Dalvik下，应用每次运行的时候，字节码都需要通过即时编译器（just in time ，JIT）转换为机器码，这会拖慢应用的运行效率，而在ART 环境中，应用在第一次安装的时候，字节码就会预先编译成机器码，使其成为真正的本地应用。这个过程叫做预编译（AOT,Ahead-Of-Time）。这样的话，应用的启动(首次)和执行都会变得更加快速。

ART有什么优缺点呢？

 优点：

1、系统性能的显著提升。
2、应用启动更快、运行更快、体验更流畅、触感反馈更及时。
3、更长的电池续航能力。
4、支持更低的硬件。
缺点：
1.机器码占用的存储空间更大，字节码变为机器码之后，可能会增加10%-20%（不过在应用包中，可执行的代码常常只是一部分。比如最新的 Google+ APK 是 28.3 MB，但是代码只有 6.9 MB。）
2.应用的安装时间会变长。

其实我日后安卓研究最多的是Dalvik虚拟机和ART虚拟机，对于ART其实就是采用了空间换时间大法而已。当我们开机时遇见程序正在优化中很慢的那种。那么你的手机很可能正在使用的就是ART虚拟机。

tips：现在智能手机大部分都可以让用户选择使用Dalvik还是ART模式。当然默认还是使用Dalvik模式。

用法：设置-辅助功能-开发者选项（开发人员工具）-选择运行环境（不同的手机设置的步骤可能不一样），事实证明很可能就找不到。不过还是贴别人的图。

下面这个图是我导出的手机的本地配置文件，并且在ART的地方做了批注：

参考链接

参考链接2