Android高级之Dalvik初识

 本文来自http://blog.csdn.net/liuxian13183/ ，引用必须注明出处！

研究安卓已多年，一直在应用层做开发，Framework层只是看过，也就是大家常说的"底层"，而高级一点的功能如热加载、处理器类型配置，必须得了解再深入些才好，Library、Runtime、Kernel层等；当然了解底层的原因，不是在于去做底层开发，而是更好的做应用层，使其功能更强大和完善。这里的底层是除应用层以外其他层。而Dalvik是什么，就是把各层串起来，处理安卓系统和服务的一个计算机。

Dalvik这个名字，是创始人的祖先生存过一个小村庄的名字，大概为纪念先人的原因，这个村庄位于冰岛。前面也有讲这个虚拟机是专门为移动设备，即内存小、计算能力低、运行标准要求高提供的嵌入式设备，正因为克服如此多的问题，以其优良的性能出现在世人面前，才受到众多厂商的追捧，前有HTC、摩托罗拉，后来阿里云、小米；越来越追求代码层的优化，更好的解决方案，更快的解释、加载速度，更好的体验和兼容性，来抵消硬件设备带来的价格冲击-这也是国内厂商，应对众多街机的一种战略手段，以数十万上百万的出厂设备*单利-有限的研发力量价格=最终厂家利润，假设每件研发投入100万，价格降低5块，则收益至少达到平衡或500万以上；个人不太认同这种恶性竞争，逼死开发的策略，商品应该优质高价，让消费者使用安全放心，带给的是心理的安全感、舒适感、品牌感知度，以及强大的功能，像IPhone一样，让生活归生活，功能归功能；总之从厂商竞争情况来说，个人觉得华为做的最好。但万变不离其宗，产品总是不完善的，需要维护和升级，以维持其对于公众的领先地位，因此理解虚拟机，有助于从全局出发，提出更好的优化或解决方案，为消费者提供更好的产品。

闲话这么多，进入正题。Dalvik来自于JVM，大多数的java程序都可以执行（为什么说大多数，因为它退出JSF标准，按说1.6以后是否全面的支持Java，这事能肯定）。前面对JVM有过讲解，它基于堆栈，处理代码指令，需要不断的从主内存复制到临时内存，然后操作完再存回去，有寄存器但仅限于虚拟机自己使用；而Dalvik基于寄存器，代码的执行本身就依赖于寄存器，且避免过多的存取，字节码指令减少47%，访问次数减少37%，因此执行速度更快。但寄存器有一个缺陷，只有65536个，每个32位，即总共256k，因此它还需要另一种文件Odex的支持。说到它，就得先讲dex文件，我们都知道java文件被编译后形成.class文件，这种文件符合JVM的执行规则；而Dalvik则把.class文件使用dx工具压缩形成dex文件，它符合寄存器的执行规则，同时又是对原数据进行过优化，共享共同数据，降低冗余，使用代码结构紧凑，因而包大小大约为同类型jar文件的50%。

Dex文件的格式与前面讲的类文件格式类似，可以对比着看：有基本数据类，如byte占8位，表示1byte的有符号数，ubyte同样，但表示无符号数；也有文件结构，也有字符串索引，字段索引，方法索引，类型索引，类定义，多的是原型数据索引，连接数据区等；同时header信息里也存着魔数，文件总长度，以上各种索引及类型的个数、地址等，索引除公用的是绝对位置，其他均为相对位置。数据的存放。Dalvik字节码总共有226条，使用时会用一个hash指令表来存储，格式如 B|A|op 12x 第一个是指令，第二个是缩写，用来说明它的操作逻辑。

Odex文件是为了提高程序执行速度而做的本地缓存，一般存在data/dalvik-cache/xxx.odex，这个文件已经由寄存器加载时帮忙做过字节码校验、空方法消除、替换优化等工作，执行时优化解释odex，没有再执行dex，把加载过的字节码缓存入odex，这就是它的工作原理。它在Dex文件前添加了头部信息，尾部拼接了依赖库、寄存器映射关系、类hash索引等辅助信息，索引再介绍一下，它包括文件的偏移地址和类的偏移地址，通过hash定位可以尽快查找到资源并加载。讲到这里，dex加载的原理已经明了，由Dalvik加载，处理器解释执行，缓存放入odex。而Odex不断增大，也是安卓手机内存变小的原因，因而对于卸载的App的odex文件可以删除，不常用的选择删除，常用的保留，不然每次加载解释后仍然会增大，而手机速度更慢。降低Android手机内存最好的方法就是找到data/dalvik-cache里不使用的odex删除。

dex是重点，而apk的组成还有主配置文件，资源文件，通过aapt工具打包而成，用jarsigner签名。而dex的加载跟class文件加载非常类似，把Dex(class)与一个DexFile(ClassFile)文件关联，建立起数据结构，再把各个类依次加载生成对象，把指针交给解释器引用执行，而4.0.4解释器又有两种，C语言和汇编，移动和快速型；但虚拟机除了支持java语言以外，还支持c语言编写的程序，按照java接口进行调用，执行效率更高；当然使用JIT补丁的方法，会更便捷，加载更快，移植性较强，后面我们将介绍热加载的原理和常用的几种框架。

Apk内部的文件包含以下几种：

resources.arsc：二进制文件，资源id和路径映射组成

res：二进制，项目中的res目录

class.dex：class编译成的可执行文件，反编译后可以看到源码结构

AndroidManifest.xml：二进制文件，反编译后可看到部分内容

讲完dex文件，接下来可以讲讲安卓系统的启动过程，之前有过介绍，但本次希望以更通俗的语法来说明。系统按键触动驱动，触发init.rc的init进程启动，这是系统启动后的首个进程，再创建各种守护进程，然后启动Zygote进程，也就是用户进程，其他应用都是由它创建-fork子进程共享内存和资源，启动系统服务的SystemServer进程（相当于服务端）监听socket指令操作。x86初始化，执行dalvik/dalvikvm/Main.c中的main方法，执行JNI_CreateJavaVM函数创建虚拟机；而Arm平台初始化是从Zygote进程开始的，执行/jni/AndroidRuntime.cpp的startVm方法，通过JNI_CreateJavaVM函数创建虚拟机。然后调用startReg注册JNI函数，用来调用java类；调用ZygoteInit类的main方法：1、创建socket接口（相当于客户端），接收应用请求 2、调用预加载类和资源 3、启动SystemServer并分裂出sytem_server，启动各项系统服务，最终将线程加入Bind通信系统，此进程退出则Zygote退出重启4、调用runSelectLoopMode监听程序请求 注：子进程同样可以再fork出一个Zygote进程，所以在实际操作时，要区分一下。在子进程中fork函数返回0，在父进程返回负值 或此进程的pid，可以用来区别运行的是否是子进程或者创建成功与否。

虚拟机的功能可以分为以下几部分：

1、进程管理：每个虚拟机都有一个进程，依赖于Zygote机制实现

2、Zygote进程管理：会fork出来一个子Zygote进程，一个SystemServer进程，一个非Zygote进程的Speciallize进程

3、类加载：先加载所有类库，然后加载字节码，放入类数据结构，供类解释器执行，如果有关联的超类、接口等也一并加载

4、内存管理：使用新老生代结合的方式，使用复制+标记-清除的算法

4、本地接口：JNI

5、反射机制：通过类结构的加载，查看、调用、修改类中的方法和属性

6、解释器：负责执行Dex字节码

7、即时编译：JIT

Dalvik编译的原理在于：开发者编译项目成dex，在安装时转成odex，减少了JIT时再进行字节码校验等工作；

而ART在Android4.4版本出现，相比较Dalvik的优势在于，直接将dex编译成可执行的机器码(而不再JIT将字节码转换为机器码)，这样加速App的运行，减少电量的消耗，用户体验更加流畅；当然劣势也是有的，App安装时比较慢，缓存文件变大；较之IOS一次开发者编译，即在用户手机运行有先天的弊端，优势在于Android热修复和动态加载方便，而IOS相对则比较古板。

Dex较之class文件，添加新操作码支持，进行文件优化和压缩，加快解析速度


签名好处：1、顺利升级2、热修复 3、进程级数据共享
Meta-Inf里的文件Manifest.MF是对Apk包中非Meta-Inf的所有文件进行数据校验，而Cert.Sf对Manifest.MF和其他文件进行校验，Cert.Rsa中存储签名信息

Dalvik运行在Arm的CPU上，那么有必要了解一下Arm

Arm：一家1990年成立的英国公司，主要进行Cpu授权，是一种知识产权公司，占据移动95%的市场，主要靠设备抽成盈利。

产权领域：指令集架构、微处理器、GPU、互连架构等

特点：低功耗、低成本，使用RISC(Reduced Instruction Set Computer，通常仅执行1或2个指令即可完成意图)，

和big.LITTLE架构(适配高性能-64位的内核和低性能-32位的内核切换），方便其他品牌贴标生产

授权方式：架构、内核、使用三种形式，分别针对大、中、小型公司

合作伙伴：高通、联发科等蚂蚁联盟

合作形式：实行OEM（Original Equipment Manufacture）

对手劣势：1968年成立的Intel使用CISC（Complex Instruction Set Computer，通常仅执行3或4个指令即可完成意图）架构的x86功耗高、掉电快

适配执行：从上面介绍可以看出，Arm占据绝对多数市场，因此mips和x86基础不需要考虑适配，而且它们会主动解析Arm指令成自己能使用的指令（使得自身效率更低，不得不赞叹规模效应的强大），big.LITTLE的高低性能内核切换，可以进行有效省电（计算量小用低性能、大用高性能，性能越高越耗电）。而64位寄存器的使用，减少内存存取的次数，提高CPU处理效率，用于RISC架构高性能的处理器。

Mips：1998年成立，同样依据RISC架构，中科院设计的“龙芯”与它95%类似，涉及侵权，而准备收购其估值1亿的20%股份。

在Android Studio下，则可以通过以下的构建方式指定需要类型的SO库。

productFlavors {
    flavor1 {
        ndk {
            abiFilters "armeabi-v7a"
            abiFilters "x86"
            abiFilters "armeabi"
        }
    }
    flavor2 {
        ndk {
            abiFilters "armeabi-v7a"
            abiFilters "x86"
            abiFilters "armeabi"
            abiFilters "arm64-v8a"
            abiFilters "x86_64"
        }
    }
}

更多：http://blog.csdn.net/reboot123/article/details/17918447

案例：

• 如果你使用的是 1.7.4 版 (或更高版本) Agora Native SDK:

  Agora Native SDK 目前支持 64 位的 ARM 架构，只需将 arm64-v8a 里面的文件(位于SDK包内)拷贝至项目对应的 arm64-v8a 路径下。目前不支持 x86_64 架构直接运行，不过可以以 x86 方式兼容运行。具体做法就是在64位的 x86 设备上保证 APK 里面没有 x86_64 目录。

• 如果你使用的是 1.7.4 版之前的 Agora Native SDK:

  Agora Native SDK 目前只提供 32 位 native 库（armeabi-v7a），在 64 位设备上，Android 支持以 32 位进程模式启动 APK，因此 Agora Native SDK 也可以在 64 位 Android 设备上使用，但必须保证 APK 的 arm64 目录为空。否则 Android 系统将以 64 位进程模式加载 APK，由于 Agora Native SDK 没有提供 64 位库，APK 启动会失败。 由于目前 Android 的主流还是 32 位设备，一般各厂商都会提供 32 位库，因此一般来说，在 64 位 Android 设备以 32 位进程模式启动一般不会有问题。但是如果在某些 64 位平台上出现了这样的错误: java.lang.UnsatisfiedLinkError: dlopen failed: ”libHDACEngine.so”

但是如果 64 位平台上出现以下报错:

java.lang.UnsatisfiedLinkError: dlopen failed: "libHDACEngine.so"

可能的原因:

在安装 APK 的时候，系统会按照 Build.SUPPORTED_ABIS 去查找 APK 的 lib 目录下的 native 库的目录（现有的 ABI: armeabi, armeabi-v7a,arm64-v8a, x86, x86_64, mips64, mips）。

如果在 app 中有兼容 64-bit 的目录但是又缺少库文件的话，并不会使用其他 ABI 目录下的库文件替换所缺少的库文件进行安装，这些库不混合使用，也就是说需要为每个架构提供对应的库文件。

Android 在加载 native 库的时候有回退（fallback）机制，在64位系统上如果 app 并不存在 arm64-v8a 的目录，则会尝试寻找armeabi-v7a下面的库进行加载，一般来说是向下兼容的。

解决方案:

• 方法 1: 在构建应用程序的时候，在工程 (project) 里删除所有 arm64-v8a 下面的库以及该目录；在生成 app 后，确认 apk 的包内 lib 下没有 arm64-v8a 的目录。
• 方法 2: 在 gradle 构建文件中设置 abiFilters，只打包 32 位架构的库:

 android {
  ...
  defaultConfig {
    ...
    ndk {
      abiFilters "armeabi-v7a","x86"
    }
  }
}