标签：

参考资料

https://source.android.com/devices/tech/dalvik/dalvik-bytecode.html

https://source.android.com/devices/tech/dalvik/instruction-formats.html

http://www.milk.com/kodebase/dalvik-docs-mirror/docs/dalvik-bytecode.html

什么是Dalvik字节码？

字节码的格式？

dalvik字节码是以一个字（两字节）为单位，必须是一个字的整数倍。所以，你看到dexdump出的字节指令，其长度都必须x2才能得到其字节长度。

不同指令的字节码长度不一样，相同操作类型的指令长度是一样的，根据指令操作类型，就可以确定指令的长度。比如 mov v1, v2，指令长度是1字。

字节码在dex文件中存储时，都是小端的。因此，第一个字节必须是操作类型（操作符），是一个0～255范围内的一个数字，根据操作符，我们可以确定后续有多少个字以及表示什么意思。

每个操作符都有一个格式（format），根据格式，我们可以知道该指令的长度，参数有哪些、每个参数的长度、参数是如何存储的，这些重要的信息。不同的指令可以有相同的格式，因此，dalvik将他们分类，并给每个格式以不同的描述。每种格式被称为Format ID。

下表详细说明了dalvik字节码的格式（来自https://source.android.com/devices/tech/dalvik/instruction-formats.html）。这个表分为4列。其中前3列分别是Format, ID, Syntax。

Format列

ID列

Syntax列

常量池与常量解析表是什么？

java的很多操作，都需要类、方法、域和字符串。这些反映在字节码中，都是以字符串的形式存在的。

所有的类名、方法名、域名、域和方法的签名已经常量字符串全部存储在常量池中。常量池是一个字符串池，包含所有字符串。

同时为了访问这些常量字符串，必须通过一些解析表来进行映射。这些解析表包括type表--保存class名字的索引；field表，包括field所属类的解析表索引、field名字的索引、field签名的索引；method表，包括method所属类的索引、method名字的索引、签名的列表；string表保存的则是常量池中的索引。

用下面的图表示的更加清楚：

图中的每一项在Dex文件中都是以表的方式存在的。

这些表对程序的运行至关重要。如果指令中含有“string@XXXX”这种格式的参数时，那么就要从StringId表中取出一个StringId项，然后通过其offset，从常量池中得到对应的字符串；对于"method@XXXX"这种格式，就是从MethodId的表中得到一个MethodId项，从而读取到各项信息。

但是要注意一点，上图描绘的是dex文件中存在的关系，不是运行时的关系。当我们执行一条指令，比如 "const/string vA, string@BBBB"， 寄存器vA中保存的不是“BBBB”的值，也不是从常量池中得到的字符串地址，而是一个和该字符串对应的java.lang.String对象；同理，const/class vA, class@BBBB这样的指令，vA保存的是BBBB所描述的class的java.lang.Class对象。但是 invoke指令和iput,iget等field指令，在运行时并不取得对应的java.reflect.Method和java.reflect.Field对象，而是Dalvik内部的Method和Field对象。这些内部对象只能在dalvik内部使用，不会反映在java层的代码中，java代码也无法使用。

之所以出现这些差别，是因为string，class这种对象，是必须能够让java层代码访问的，而field和method对java代码是透明的。

Dalvik为了应对这种差别，都会做一个与这些表大小一样，索引一致的cache表，这个cache表内放置了已经解析好的对象，需要的时候直接从cache中取，不需要这样来回查找了。

当然，这些表内防止的是所有java代码能够访问到的类、field、method和字符串。比如，你要访问一个android.content.Content类及其方法，那么他们的名字就会放在表内。

和类、对象操作相关的指令有哪些？

new 语句对应的指令

instance of语句对应的指令

check cast指令

<Class>.class语句

Field访问指令

如何调用和返回函数

在参数传递上，对于非static函数，第一个参数是this对象。

switch相关指令是怎么回事？

int idx = value_of(vAA) - first_key;
if (idx >= size)
  target_pc = current_pc + PACKED_SWITCH_SIZE;
else
  target_pc = current_pc + targets[idx];

int idx = find_key(keys, value_of(vAA));
if (idx >= size)
  target_pc = current_pc + PACKED_SWITCH_SIZE;
else
  target_pc = current_pc + targets[idx];

quick类型的指令有那些，起到什么作用？

dalvik有一项优化，即将dex文件转换为odex文件。那么，odex与dex有什么区别呢？在文件结构上，odex文件会创建一个hash表，以类名为key，帮助系统快速找到class，从而快速加载；在字节码上，引入了一些quick指令，这些quick指令，能够加快执行速度。

quick指令是针对iget/iput，以及invoke-virtual的。iget/iput指令总共被分成3种：iget/iput-quick, iget/iput-object-quick, iget/iput-wide-quick。它们主要是类型与长度不同（见上一节)，实际原理都是一样的。iget/iput的原理，是将原iget/iput中记录field在解析表中的索引，直接换成了这个field在对象中的偏移。虚拟机只要用this对象+偏移就可以获取到field在object对象中的位置，从而进行读写。

另外一个invoke-virtual-quick和invoke-virtual-quick/range，同样的，它将invoke-virtual指令内包含的method在解析表内的索引，换成了对应的虚函数在对象的虚函数表中的偏移，通过 this->class->vtable + offset的方式取得method指针，然后进行调用。

除了这些外，还有一个execute-inline指令。这个指令其实是将很多非常基础的类的函数换成dalvik内部指针。比如String类的很多函数，如charAt等，换成dalvik内部用c语言编写的 java_lang_String_charAt函数，在运行时，直接调用内部函数，速度会提升很多。execute-inline会将对应的内部函数的索引放在指令里面。

字节码的程序结构如何？

用下面的表表示：

代码数据部分都是可执行的代码。与我们通常看到的代码不同，davlik字节码使用了大量的goto指令，用于实现各种分支和循环。

try-catch数据结构是什么？

try-catch数据结构，是放在代码的后面。在dalvik用CodeItem这个结构来保存code数据，其中的insns_size_in_code_units_是以2字节为单位保存从Method代码开始位置到TryItem数组的偏移。

try catch是用TryItem数组保存的，一个TryItem的结构如下

  struct TryItem {
    uint32_t start_addr_;
    uint16_t insn_count_;
    uint16_t handler_off_;

   private:
    DISALLOW_COPY_AND_ASSIGN(TryItem);
  };

insn_count_记录try块涉及的代码指令数；

handler_off_ 是catch块的数据，这个偏移是相对与代码开始位置。它的数据是经过LEB128编码的，数据可以被解析成一个CatchHandlerItem结构

CatchHandlerItem结构定义如下

    struct CatchHandlerItem {
      uint16_t type_idx_;  // type index of the caught exception type
      uint32_t address_;  // handler address
    } handler_;

address_ 是处理代码的入口。

HandleItem可能不止一个，会有多个。

TryItem是一个数组，数组的长度可以0，1，... N个。当异常发出时，得到异常发出位置的dex pc，用这个dex pc去匹配TryItem中start_addr_和insn_count_，看dex pc落在哪个TryItem的区间内。如果找到了TryItem块，就找它下面的CatchHandleItem，去匹配抛出的exception类型，与CatchHandlerItem定义的类型是否一致，如果一致就找到了对应的处理，如果不一致，则继续查找。

如果本函数内已经没有可以处理的Try-catch了，就向上找调用者函数，依次取查找。

当然，我们知道，java的异常，是 try-catch-finally结构，所以，如果有 finally的话，它是最后一个CatchHandleItem了。

一个TryItem的CatchHandlerItem信息结构，可以用下表来描述（数据都是经过LEB128加密的）

dalvik字节码问答

标签：

原文地址：http://blog.csdn.net/doon/article/details/51193196