本文共 1584 字，大约阅读时间需要 5 分钟。

了解下Dalvik的可能设计初衷： dalvik的设计的初衷就是运行在像Android这样的小RAM，低速度flashmemory，运行标准Linux系统的设备。针对这样的平台特性，要想做到更好，我们需要考虑以下几点： 1)为了减少系统的内存使用，字节码可以多进程共享。但出于安全性考虑，这样的字节码不可以编辑。 2)为了保证响应速度，加载一个新的APP所需时间尽量少。 3)标准Java中把多个类文件分别存放导致了大量的冗余，为了节省APP的占用空间，这个问题要解决。 4)加载类的时候解析类的字段成员会导致额外的消耗，如果改成像C一样直接访问会比较好。 5)字节码verification很有必要，但很慢，我们需要把验证与APP执行分开。 6)字节码optimization(比如指令优化、方法pruning)可以在很大程度上影响执行速度和电池消耗。 标准VM都是程序启动时把每单个的类文件解压放入heap，每个进程都有一份copy。这样的做法在内存占用和时间上面都有损失，但方便了对指令的优化。 而相应的为了这些关键点dalvik做了哪些改变： 1)多个类被集成进单一的DEX文件。 2)DEX文件在进程间以只读方式共享。 3)byte ordering和word alignment根据local system来做调整。 4)字节码verification尽可能提前。 5)需要修改字节码的optimization必须提前进行 dex文件 Dex全称是Dalvik VM executes，即Android Dalvik虚拟机的可执行文件，它不是JavaME的字节码而是Dalvik字节码。 dex文件来源： 在编译Java 代码之后，通过Android 平台上的工具可以将Java 字节码转换成Dex 字节码。虽然Google称Dalvik是为了移动设备定做的，但是业界很多人认为这是为了规避向sun 申请Javalicense。这个DalvikVM针对手机程序程式/CPU 做过最佳化，可以同时执行许多VM而不会占用太多Resource。 dex文件执行前优化： 虽然DEX文件的结构是紧凑的，但是我们还是要想方设法的进行提高程序的运行速度，我们就仍然需要对DEX文件进行进一步优化 当Android系统启动一个应用的时候，有一步是对Dex进行优化，这个过程有一个专门的 工具来处理，叫DexOpt。DexOpt是在第一次加载Dex文件的时候执行的。它主要是调整所有字段的字节序（LITTLE_ENDIAN）和对齐结构中的没一个域验证DEX文件中的所有类 对一些特定的类进行优化，对方法里的操作码进行优化 。优化后的文件大小会有所增加，应该是原AndroidDEX文件的1-4倍。 优化发生的时机有两个：对于预置应用，可以在系统编译后，生成优化文件，以ODEX结尾，即OptimisedDex。执行ODex的效率会比直接执行Dex文 件的效率要高很多。 Dexopt的一些缺陷： （1）Android2.3及以前版本用来执行dexopt(用于优化dex文件)的内存只分配了5M （2） DexOpt会把每一个类的方法id检索起来，存在一个链表结构 里面。但是这个链表的长度是用一个short类型来保存的，导致了方法id的数目不能够超过 65536个。当一个项目足够大的时候，显然这个方法数的上限是不够的，就会导致dex爆掉的问题。尽管在新版本的 Android系统中，DexOpt修复了这个问题，但是我们仍然需要对老系统做兼容（Android2.3及以前版本）。 为了保证版本兼容，我们可以做的优化： 简单而言需要进行dex分包，具体可参考博客http://blog.csdn.net/huli870715/article/details/26586501

转载地址：https://blog.csdn.net/Danlinan/article/details/38896363 如侵犯您的版权，请留言回复原文章的地址，我们会给您删除此文章，给您带来不便请您谅解！