如果你有一定的编程基础，且知道什么是xml，什么是axml，你可以点击干货直接进入干货环节，但是我还是建议你听我絮叨一番，毕竟我还是想对你说…

APK是什么

apk是安卓的可执行程序，它的本质就是一个zip格式的压缩包文件，只是它可以被安卓系统识别、解释和运行。下图是apk内部的目录结构

看起来文件有点多，不过别担心，今天的主角只有xml文件，例如：图中看到的二进制化的AndroidManifest.xml，以及res目录下的所有二进制的xml文件.
安卓中二进制化的xml简称axml。

XML是什么

可扩展标记语言，标准通用标记语言的子集，简称XML。是一种用于标记电子文件使其具有结构性的标记语言

以上是百度百科的解释

xml文件内容如下图所示

AXML是什么

(Android Binary XML)是安卓项目中、清单文件、布局文件以及其它所有xml资源，经过编译后产生的：二进制化的xml文件

上图的xml文件编译后产生的axml文件内容如下图所示

你是否会觉得：xml看着挺友好的，简单易懂，为什么要大费周折的搞成二进制呢？这太反人类了。

我简单讲两句二进制化的好处

1. 文件尺寸缩减，例如：文件中大量使用到android:属性=“内容”，经过二进制化以后，xml中所有的android字符就只需要一个索引值指向android的命名空间即可，原本需要7个字符才能表示的信息，现在只需要一个索引 ID，直接省掉6个字符的空间 何况是全文共用这一个ID 这节省量是相当可观的。当然，其中的属性和内容也是同理。所以这种减过肥的xml看起来会更加性感。

2. 执行效率更高，xml文件对人类而言，结构清晰，逻辑明确。但是对安卓系统来说并非如此。如果安卓直接使用xml，它就需要先解析xml，然后将文字信息一一对应到它所能识别的逻辑上（这种 将你懂的事情变成它能懂的事情，是一件耗时费力的过程。所以说：对人说人话，对机器就要说01话。）二进制化所产生的那一系列ID是直接指向安卓所能识别的逻辑上的，所以AXML对程序的执行来说，效率是非常哇塞的。

通过以上讲解，你应该大致明白了什么是xml，什么是axml，以及为什么安卓要把xml编译成axml。

那么至此，新的问题就产生了。

如果我只能拿到一个安卓的apk安装包，我没有源代码。那里面这种只给系统看不给我看的，二进制化的产物，到底会跟我的手机联合起来干些什么勾当？我是不是就无从得知了？万一它要对我做什么羞羞的事？我该怎么办？

您不用担心，本作文，就是为了解决这种问题，而准备的。

万事万物皆有规律可循，xml编译成axml也同样如此。它并非编译器，对xml风流过后，不负责任的产物。它是有道理可讲，有规律可循的正经事。所以我们就是要顺着它的规律，由着它的道理，一步一步抽丝剥茧，理清axml的来龙去脉，揪出创造它的元凶xml本身，让xml自己出来接受盘查。

---

那么，xml到axml之间到底有什么道理，又有什么规律，我们该从何查起呢？

所以这里就有了第一个自问自答环节：
到底谁能看懂这axml？
既然这axml最终是给安卓系统使用的，那当然就是安卓系统明白其中的道理啦，所以这线索就在安卓底层找。

安卓底层代码我给您放这里了。您想看的话就点进去吧。里面有安卓的各个版本的各种代码。喜欢侦探游戏的都可以进去探索一番，相信一定会有不小的收获的。

现在有了系统源码，接下来的问题就是该看哪个代码？安卓4.4版本有10个G的源代码。茫茫代码海，该游向何方？

所以这里就有了第二个自问自答环节：
axml对安卓来讲到底算个什么东西？
既然它不是程序逻辑，那它就是程序资源。所以去寻找资源相关的东西。

以上只是给出寻找思路，答案我就直接放在这里，感兴趣的话，可以自己去源码里一探究竟。

axml用到的格式在ResourceTypes.h已有定义。

接下来就是干货时间

---

上干货

首先我直接给出我的分析结果，我已经把我所理解的AXML的组成原理，整理为一张结构图，就是下面这张图了。如果想看我的源码的话,它已经托管至全球最大的同性交友网站，直接点击那两个高亮部分，进去把玩一番吧。接下来我会以此图为主，把一些重要的注意事项讲给你听，希望你会喜欢这篇作文，并从此爱上我。

ResourceTypes.h里提出了一个概念，叫做chunk块
整个axml文档是由 一块(chunk) 又 一块(chunk) 的结构堆叠起来的，为了便于理解，可以把chunk理解为一个盒子。
整个axml是最大的一个盒子(chunk) 盒子里面依次是

1. 字符串盒子(String Chunk)
   这个盒子里，存放的是整个文档用到的字符串信息，文档用到字符串的地方，都会拿着索引来这里领取字符串。
2. 然后是资源盒子(System Resource Chunk)
   这个盒子里，存放的是该文档用到的安卓的系统属性对应的索引(你可以在安卓源码的android.R$attr.**中找到这些索引的身影)。
3. 最后是一个大盒子：命名空间盒子([Start and End] Name Space Chunk)
   它是整个xml文档的开始
   整个文档以Start命名空间为开始，又以End命名空间为结束，所有的文档标签都在它所属的命名空间内展开。
   一个文档内可以有多个命名空间并存：例如系统的android空间，与自定义控件用到的app空间可以并存。
   命名空间内部存放的就是整个文档的具体结构信息了。

命名空间内所存放的 结构盒子(chunk) 依次是

1. 开始标签(Start Tag Chunk)
   开始标签是具体标签的开始
   例如：<manifest… 的开始以及<application… 的开始。
   同时里面存放了该标签所需要的所有具体的属性信息(Attribute)
   例如：application中的android:theme=“@style/Theme.TestApk”
   以及android:icon=“@mipmap/ic_launcher”
   等等所有的属性都在属性信息(Attribute) 里存储。
   (TIPS:这里的icon是属性名，android是该属性所在的命名空间，@mipmap/ic_launcher 是该属性的值。不过要注意，这里存的不是 @mipmap/ic_launcher 这个字符串，而是它对应到resources.arsc 文件中，记录的索引值，由于arsc文件不是本作文的主角，所以它没有资格在这篇作文里占太多的篇幅)
2. 最后是结束标签(End Tag Chunk)
   所有的 开始标签(Start Tag Chunk) 都有一个与之对应的 结束标签(End Tag Chunk) 。
   开始标签(Start Tag Chunk) 与 结束标签(End Tag Chunk) 之间可以嵌套另外的标签。
   例如：
   1. <manifest>标签的开始与结束之间嵌套了<application>标签；
   2. <application>标签又嵌套了<activity>标签；
   3. <activity>标签又嵌套了<intent-filter>标签；
   以此类推，循环往复，就组成了整个xml文档的结构。

---

到此为止希望你已经大致清楚了 AXML 这个 大盒子(chunk) 的结构怎么堆叠起来的了。

接下来将是热血沸腾的高潮时刻，希望你还能hold住。高能提示：提前备好纸巾，全程无尿点，接下来会结合ResourceTypes.h中定义的结构体，深入axml的体内来一探究竟。

因为涉及到代码的分析和整理，这里希望你具备一定的编程基础，最好是理解C++数据结构的定义，同时懂一点安卓的正向开发，知道安卓的项目结构。 当然你不清楚C++也没关系，我会将C++的结构体转写为java的Object。

代码分析

在开始代码分析之前有一件非常重要，但是 ResourceTypes.h 没有提到事情，你一定不要忽视，由于安卓系统主流的CPU是arm的架构，所以axml的二进制整篇是以小端编码的方式存储的。

大小端编码也不是本文的主体，更专业的解释需要你另外补充营养。
这里只粗略的解释一下

---

例如下面这两个字节
00 0F
大端编码 它的结果就是 00 0F 值等于 15
小端编码 需要字节倒序 就是 0F 00 值等于 3840

结构图第一行也已经注明 little endian byte order 请不要忽视它的存在

上面axml截图中开始的两个字节是03 00但是结构图备注的FileType却是0x0003正是这个原因

---

接下来正文开始

ResourceTypes.h开篇的第一个结构体是Res_png_9patch，安卓的.9图不是本文所care的东西，直接跳过，之后的无关成员也会一并跳过。

header定义

通过上面的结构图，你或许注意到，每个 盒子(chunk) 的开始都会有一些共同的属性 [Chunk Type、Header Size、Chunk Size] 这几个共同的属性是就是该 盒子(chunk)的基础头信息(header) ，头信息解释了这个盒子姓甚名谁。

不同的盒子，头信息的数据量是不同的，Header Size 表明了当前 盒子(chunk) 头信息的大小,图中头信息的内容已用粗体区别出来。

tips:文件最开始的 FileType 和 FileSize 与子盒子的 ChunkType 和 ChunkSize 其实是同样的东西，只是根盒子的size也等同于该文件的size，根盒子的type也同等于该文件的type，索性直接将其命名为了 FileType 和 FileSize ，请悉知，并奔走相告。

那么接下来看一下ResourceTypes.h中对基础头信息的定义[代码160行]

/**
 * Header that appears at the front of every data chunk in a resource.
 */
struct ResChunk_header
{
    // Type identifier for this chunk.  The meaning of this value depends
    // on the containing chunk.
    uint16_t type;

    // Size of the chunk header (in bytes).  Adding this value to
    // the address of the chunk allows you to find its associated data
    // (if any).
    uint16_t headerSize;

    // Total size of this chunk (in bytes).  This is the chunkSize plus
    // the size of any data associated with the chunk.  Adding this value
    // to the chunk allows you to completely skip its contents (including
    // any child chunks).  If this value is the same as chunkSize, there is
    // no data associated with the chunk.
    uint32_t size;
};

[tips:1 byte = 8bit]
chunkType 占16bit，即2byte 对应java的short
headerSize 占16bit，即2byte 对应java的short
chunkSize 占32bit，即4byte 对应java的int

所以上面的结构体转java代码如下

class BaseChunk {
    
	short chunkType;
	short headerSize;
	int chunkSize;
}

chunkType的取值为[代码179行]

enum {
    RES_NULL_TYPE               = 0x0000,
    RES_STRING_POOL_TYPE        = 0x0001,
    RES_TABLE_TYPE              = 0x0002,
    RES_XML_TYPE                = 0x0003,

    // Chunk types in RES_XML_TYPE
    RES_XML_FIRST_CHUNK_TYPE    = 0x0100,
    RES_XML_START_NAMESPACE_TYPE= 0x0100,
    RES_XML_END_NAMESPACE_TYPE  = 0x0101,
    RES_XML_START_ELEMENT_TYPE  = 0x0102,
    RES_XML_END_ELEMENT_TYPE    = 0x0103,
    RES_XML_CDATA_TYPE          = 0x0104,
    RES_XML_LAST_CHUNK_TYPE     = 0x017f,
    // This contains a uint32_t array mapping strings in the string
    // pool back to resource identifiers.  It is optional.
    RES_XML_RESOURCE_MAP_TYPE   = 0x0180,

    // Chunk types in RES_TABLE_TYPE
    RES_TABLE_PACKAGE_TYPE      = 0x0200,
    RES_TABLE_TYPE_TYPE         = 0x0201,
    RES_TABLE_TYPE_SPEC_TYPE    = 0x0202
};

转java代码如下

public enum ChunkType {
    
    CHUNK_STRING            /*chunk type*/(0x0001),
    CHUNK_RESOURCE          /*chunk type*/(0x0180),
    CHUNK_START_NAMESPACE   /*chunk type*/(0x0100),
    CHUNK_END_NAMESPACE     /*chunk type*/(0x0101),
    CHUNK_START_TAG         /*chunk type*/(0x0102),
    CHUNK_END_TAG           /*chunk type*/(0x0103),
    ;
    public final int TYPE;

    ChunkType(int TYPE) {
    
        this.TYPE = TYPE;
    }
}

java代码里我只列出了axml用到的部分，未使用的部分被我赏了白眼。

以上代码对基础的头信息也就解释清楚了。

---

接下来直接开始看图识字环节。

String Chunk

StringChunk是整个文件的头信息结束后，第一个冲出来的盒子(chunk)。所以它从文件的(headerSize)第八个字节开始。

StringChunk的结构定义如下[代码382行]

/**
 * Definition for a pool of strings.  The data of this chunk is an
 * array of uint32_t providing indices into the pool, relative to
 * stringsStart.  At stringsStart are all of the UTF-16 strings
 * concatenated together; each starts with a uint16_t of the string's
 * length and each ends with a 0x0000 terminator.  If a string is >
 * 32767 characters, the high bit of the length is set meaning to take
 * those 15 bits as a high word and it will be followed by another
 * uint16_t containing the low word.
 *
 * If styleCount is not zero, then immediately following the array of
 * uint32_t indices into the string table is another array of indices
 * into a style table starting at stylesStart.  Each entry in the
 * style table is an array of ResStringPool_span structures.
 */
struct ResStringPool_header
{
    struct ResChunk_header header;

    // Number of strings in this pool (number of uint32_t indices that follow
    // in the data).
    uint32_t stringCount;

    // Number of style span arrays in the pool (number of uint32_t indices
    // follow the string indices).
    uint32_t styleCount;

    // Flags.
    enum {
        // If set, the string index is sorted by the string values (based
        // on strcmp16()).
        SORTED_FLAG = 1<<0,

        // String pool is encoded in UTF-8
        UTF8_FLAG = 1<<8
    };
    uint32_t flags;

    // Index from header of the string data.
    uint32_t stringsStart;

    // Index from header of the style data.
    uint32_t stylesStart;
};

接下来结合结构图逐一分析StringChunk里的信息

1. chunkType 为0x0001 与上述enum的结果对应。
2. headerSize 为0x001C = 28 个字节 表明从chunkType开始包含chunType的前28个字节信息 都是stringChunk的头信息，28字节后的信息是该chunk的内容信息。
3. chunkSize 的大小，记录了从chunkType开始到StylePool结束，即整个StringChunk所占的字节大小。
4. StringCount 字符串的数量
5. StyleCount 这里测试StyleCount总是为零，个人理解它可能是类似html代码中标签的style属性分段后存储下来的信息，但是安卓的标签不会用到类似style这种单属性里面拥有多个结果的属性配置。
6. isUTF8 注意结构体里 flag 是由两部分组成的，其中utf8的属性需要左移8位，证明utf8是在sorted之前出现的。java中我将flag拆解成了 isUTF8 和 isSorted 两部分，因为这很重要，接下来会着重解释它的重要性。
7. isSorted 这里指明C++是否对字符串池进行了排序(如果排序会采用strcmp16进行两个字符串的比对)，实际观测到的结果是没有排序，并且值总是为0。
8. StringStart 首个字符串开始的位置，注意它不是从整个文件开始计算，而是从该 盒子(chunk) 的0点坐标开始计算的。
9. StringOffsets 这是一段连续的Index数组，每个index占4字节(对应java的Integer)，各个数字表示对应的各个字符串，从StringStart开始的偏移量。
10. StyleOffsets 上文说过，因为StyleCount总是为0，所以这里也就总是为空，占0字节，不占位置，只占心情。
11. StringPool 从这里开始，才是StringChunk的重点，也是我刚才需要解释isUTF8的重要性的地方。header的注释信息己经提到，字符默认是UTF16的编码，除非isUTF8不为0，才说明这里的字符串需要UTF8编码。这里有好几个坑需要刨一下，接下来展开讲StringPool。
    

StringPool

首先上文已经讲过，axml全文小端编码，所以这里默认的字符编码是UTF_16LE(little endian)，只有isUtf8不为0的时候才是UTF8编码，所以这里有个坑需要注意，我之所以说isUtf8不为零即为真， 是因为isUTF8这个值其实是以大端编码记录的，所以二进制文件可以看到是00 01 也就是数字1，但是经过小端编码后 得到的值是01 00就成了数字 256，在我的代码中你会看到这行代码

        //utf8(0x0100) or default utf16le(0x0000)
        this.isUTF8 = byteBuffer.getShort() != 0;

因为我猜测它的取值只有0或1，所以我直接用了不为零即为真的判断方式，所以你知道我为什么这么干就好，但是重新存储该信息的时候，我是切回大端编码写回，再切回小端编码写后续内容的。

    @Override
    protected void toBytes(ByteArrayOutputStream stream) throws IOException {
    
        stringCount = stringList.size();
        ByteBuffer byteBuffer = ByteBuffer.allocate(5 * 4 + stringOffsets.length * 4 + styleOffsets.length * 4);
        byteBuffer.order(ByteOrder.LITTLE_ENDIAN);
        byteBuffer.putInt(stringCount);
        byteBuffer.putInt(styleCount);
        byteBuffer.order(ByteOrder.BIG_ENDIAN);
        byteBuffer.putShort((short) (isUTF8 ? 1 : 0));
        byteBuffer.putShort((short) (isSorted ? 1 : 0));
        byteBuffer.order(ByteOrder.LITTLE_ENDIAN);
        byteBuffer.putInt(stringStart);
        byteBuffer.putInt(styleStart);
        }

接下来继续讲StringPool里面的内容
StringPool里面是每一条的字符串信息
结构图中Each One (String)已经简单阐明了它包含几层结构
不过这里的每一条信息都是一个坑

开始的CharLength和ByteLength是第一个坑，这两个属性在ResourceTypes.h中没有提及，是我一次又一次遭受程序的毒打后，总结经验并验证出来的。

在UTF_16LE的编码下CharLength和ByteLength整体是一个CharLength，即CharLength直接占两个字节，没有ByteLength属性。个人揣测，这可能是因为UTF_16LE本身已经足够容纳所需的文字信息，不需要额外的ByteLength属性。因为UTF_16LE的每个字符直接占用了2个字节，而UTF8每个字符占1个字节,当然了UTF8是可变长的，所以就有了下一个坑。

在UTF8的编码下CharLength和ByteLength都有各自的意义。CharLength是字符数量，即java的String.length()，ByteLength是该字符所占的字节大小，即String.getBytes(StandardCharsets.UTF_8).length。往往CharLength和ByteLength的值是相同的，所以我一开始是直接使用CharLength没有考虑ByteLength 导致遇到中文的时候，系统直接崩溃了，因为英文字符只占一个字节所以CharLength与ByteLength 是相等的，但是中文的字符占三个字节ByteLength 是大于CharLength的。这个坑在ResourceTypes.h也未提及。

至此StringChunk的分析也就结束了，现在来展现几个截图，给你巩固一下。

首先这是Manifest的源文件

这是Manifest的axml文件，我已经在二进制下面，备注了它对应的意义
你可以注意到isUTF8 = 0所以是UTF16LE编码，每个字符占两个字节，比如第一个字符[7400]


然后这是layout的源文件

这是Layout的axml文件，我也在二进制下面，备注上了它对应的意义
你可以注意到isUTF8 = 1所以这里的字符串是UTF8编码，每个字符占1个字节，比如第一个字符[74]

其实这里还有一个技巧，可以让你更直观的看到文字信息。
现在已经知道Manifest中的字符是UTF16LE编码 那我们直接以UTF16LE编码的方式打开它就可以看到文字了
同理Layout中的字符是UTF8编码 那我们直接以UTF8编码的方式打开它，就可以看到文字了

就像这样

现在用UTF16LE打开AndroidManifest

用UTF8打开Layout

相信你已经注意到了，我在manifest和layout中都写入了“测试APK123”，但是在不同的编码下，呈现出了不同的结果

<0x0800> 测试APK123 <0x0000>
<长度8> 测试APK123 <结束符>

你应该注意到 截图中是 <0x08> 但是我这里写的是 <0x0800> 因为UTF16LE每个字符占两个字节，我只是将它真实的样子展现给你。

<0x08><0x0c> 测试APK123 <0x00>
<长度8><字节12> 测试APK123 <结束符>

因为UTF8中，中文占三个字节所以是3+3+6=12

最后再说一遍TIPS:

UTF16双字节，UTF8单字节
UTF16双字节，才会区分LE和BE
UTF8 单字节，没有多余的字节去倒序，所以不区分LE或BE

到此为止，整个StringChunk就解释完了，不知道你学废了没有，想了解更多细节的话，可以去浏览一下我的代码，看看与你所想是否一样。

---

System ResourceID Chunk

StringChunk之后，紧接着就是SystemResourceIDChunk 它的Type是0x0180
除了基础的Header信息之外，它的主体只有一个ResourceIDs。
ResourceIDs是一段连续的32位Integer数组，里面记录了整个文档中，使用到的系统属性所对应的索引ID，你可以在安卓源码的android.R$attr.**中找到这些索引的身影。

就像下面这样

如果你也想跑一下ResourceChunk.java的代码，你只需要插入相应的打印语句即可。

---

Start NameSpace Chunk & End NameSpace Chunk

命名空间是由开始和结束两组标签成对出现的
它除了基本的header信息之外
还有4个信息

1. LineNumber 该命名空间出现在文档中的第几行，但是我的代码中并没有严格按照它的行数去呈现，我把所有的命名空间都提权，放在了首个标签的属性中，它就像这样xmlns:android=“http://schemas.android.com/apk/res/android” 当然你不必担心，命名空间提权后，不会对程序本身造成影响。
2. Comment 该命名空间的备注信息，类似html的<!-- -->里面的注释信息，所以不用在意它，因为安卓软件编译后，会直接丢弃备注信息。
3. Prefix 该命名空间中的前缀，即"android"
4. Uri 该命名空间的地址，即"http://schemas.android.com/apk/res/android"

从这里开始 需要注意 不管是 Prefix 还是 Uri 甚至之后所有的TagChunk中出现的所有文字信息，存储的都不是具体文本，而是指向 StringChunk 中 StringPool 的index索引。

假设:现在这个 Prefix 拿到了int值等于5，那么你在 StringChunk 中 StringPool 的第6串(即索引为5)的字符串里，会得到内容为"android"的字符串。

---

Start Tag Chunk & End Tag Chunk

</EndTag> 是对 <StartTag> 标签的关闭，这里只讲述一下StartTag，理解了StartTag，EndTag就很easy了。

先来看一下ResourceTypes.h中对TagChunk的结构定义[代码564行]

/**
 * Extended XML tree node for start tags -- includes attribute
 * information.
 * Appears header.headerSize bytes after a ResXMLTree_node.
 */
struct ResXMLTree_attrExt
{
    // String of the full namespace of this element.
    struct ResStringPool_ref ns;

    // String name of this node if it is an ELEMENT; the raw
    // character data if this is a CDATA node.
    struct ResStringPool_ref name;

    // Byte offset from the start of this structure where the attributes start.
    uint16_t attributeStart;

    // Size of the ResXMLTree_attribute structures that follow.
    uint16_t attributeSize;

    // Number of attributes associated with an ELEMENT.  These are
    // available as an array of ResXMLTree_attribute structures
    // immediately following this node.
    uint16_t attributeCount;

    // Index (1-based) of the "id" attribute. 0 if none.
    uint16_t idIndex;

    // Index (1-based) of the "class" attribute. 0 if none.
    uint16_t classIndex;

    // Index (1-based) of the "style" attribute. 0 if none.
    uint16_t styleIndex;
};

struct ResXMLTree_attribute
{
    // Namespace of this attribute.
    struct ResStringPool_ref ns;

    // Name of this attribute.
    struct ResStringPool_ref name;

    // The original raw string value of this attribute.
    struct ResStringPool_ref rawValue;

    // Processesd typed value of this attribute.
    struct Res_value typedValue;
};

对应的java代码如下

public class StartTagChunk extends BaseContentChunk {
    
    public final int namespaceUri;
    public final int name;

    public short attributeStart;
    public short attributeSize;
    public short attributeCount;
    public short idIndex;
    public short classIndex;
    public short styleIndex;

    public List<Attribute> attributes;
    
    public static class Attribute {
    
        public final int namespaceUri;
        public final int name;
        public final int value;
        public final short structureSize;
        public final byte Res0;
        public final byte type;
        public final int data;
    }
}

这里只讲一下，上文没有讲过，但是StartTag里独有的属性

1. namespaceUri 当前标签所属的命名空间的字符串索引
2. name 当前标签名的字符串索引
3. attributeStart 从当前chunk的header之后的偏移量，即Comment之后的多少字节，是属性的开始，固定为20，即从namespaceUri到styleIndex之后刚好是20byte，然后开始属性信息。
4. attributeSize 每个属性的大小，即Each One (attribute) 的所有属性之和的大小=固定值20byte。
5. attributeCount 该TGA标签用到的，属性的数量。
6. idIndex 如果使用了的id属性(例如layout文件中android:id=“@+id/text_dashboard”)，就会拿到大于0的index，它对应System ResourceID Chunk的第index个(注意是从1计算不是从0)，例如在这个layout中就会拿到index为2，在System ResourceID Chunk的第二个int值得到ID1>16842960而android.R$attr中存在成员public static final int id = 16842960;
7. classIndex 安卓的xml没有使用class属性所以这里总为0。假设不为0的话，我猜测它会指向dex文件的某个索引
8. styleIndex 安卓的xml没有使用style属性所以这里总为0。假设不为0的话，我猜测它会指向arsc文件的某个索引
9. attributes 这里配置的就是具体的属性信息了，这里东西有点多，展开讲一下

attribute

什么是attribute(属性)

例如：layout中有这样一行文字

android:text=“测试APK123”

这就是TextView标签的一条属性信息

“android” 是该属性所属的命名空间
“text” 是该属性的属性名
“测试APK123” 是该属性的属性值


具体内容如下所示

1. namespaceUri 命名空间的uri，指向StringPool的下标
2. name 属性名，指向StringPool的下标
3. value 属性值，指向StringPool的下标
4. structureSize ResValue的大小：(structureSize+Res0+type+data)的大小
5. Res0 这里总为0，但是占用1个字节，赏它一个大白眼。
6. type 属性值的数据类型，类型的定义在ResourceTypes.h代码233行
7. data 由type推算的数据结果，例如索引类型 [@string/、@drawable/、@dimen、etc…] 如果这里不是索引类型。而是直接的字符串，那就使用value属性值去StringPool里取字符串。

最后还是说一下，EndTag是对StartTag的结束，Tag可以相互嵌套，下面是一个简略图。希望你能理解

<根标签 xmlns:命名空间="命名空间地址">
	<标签 命名空间:属性名="属性值">
		<子标签 命名空间:属性名="属性值"><...></子标签>
		<...>
	</标签>
	<...>
</根标签>

---

如果还有什么不理解的，可以在评论区提问，虽然我不一定会现身(我很懒的)。但是我还是期待着与你的再次相遇。

如果还想知道更多的技术细节
或者想看更多的代码
请直奔全球最大的同性交友网站，我将在那里，用最妖娆的代码再次与你缠绵，拜拜～

---

如果你看到此处，还不愿意走开，那咱们就是好朋友了，既如此，点个关注，咱们就开始愉快的乞讨环节吧

乞讨环节

每每路过咖啡店，看到那里的小青年，手拿咖啡，侃侃而谈。我就会低下头默默的扣我的衣角，已经记不清上一次喝咖啡是哪一年，花了几块钱！

重温干货

---

ResourceTypes.h
项目地址