序言



屈指算来，在软件开发这个行业工作也有10个年头了，可惜没有积累下什么东西。因为工作关系，对Android的ART进行了深入研究。我对ART工作的机制和原理产生了兴趣，有一种想把它搞清楚的冲动。

ART可以说是一个杰作！它融合了虚拟机、编译器、GC等各方面的知识和原理，具有很高的学习价值。对于一个希望提高自己的层次的开发人员，学习ART恐怕是最好的方法了。

也是基于这个想法，我想把我对ART的理解分享给大家。

 

在构思这本书的时候，我希望能够用一种特别的方法来讲述ART。市面上有很多介绍Android源码的书，我也读了几本。这些书写的都很有见地，但是叙述方法却让人遗憾。这方面的书，一般都按照Android系统的模块划分，一个模块一个或者几个章节，然后在细分为若干小节。叙述过程中，按照说明+源码+配图的方式来组织。虽然这种组织方式很直观，而且便于用户查阅源代码，但是，作为一个读者，却常常被书中充斥的来自于源码的各种名词、变量和名称搞得晕头转向的。要理解作者的意图，需要常常翻阅之前看过的章节，有时还需要对照源代码。阅读的体验很差。读这样的书，比阅读源代码的体验好不了哪去。作者已经受了一番阅读源代码的罪，不要让读者再受一回了。

之所以出现这样的情况，和这些书的组织方式有关。通常情况下，我们了解一个软件或者系统，是从它的功能开始的。通过了解它的功能，在进一步的解密它的工作原理。而这些书籍在整个叙述过程中，首先假定了读者已经非常了解软件的功能，它只需要一步一步的按照软件的结构罗列出来就可以了。实际上，读这一类的书，通常要提出疑问：系统的功能是什么，这些功能是如何实现的。然后在分析系统是如何一点一点的实现这些功能。

 

因此，我在构思本书的时候，就想着，以假设-寻找-验证的方式来组织本书的结构。具体过程是这样的：选定ART的一项功能，首先猜想实现这项功能能够使用的技术方案（可能不止一种），根据猜想，在源代码中找到对应的函数或者处理代码，最后，通过设计用例或者调试来验证我的想法。

这个过程很有点侦探破案的意味：首先根据现场的蛛丝马迹，推测凶手的作案时间和手法，然后在找到关键性的证据。

 

实际上，这也是我阅读和破解ART常用的方法。在实际工作中，是没有时间让我去阅读ART这么庞大的代码（即使读了也没有用），所以只能根据自己的需要，去查找有关联的代码，然后一步一步的深入下去。

 

据此，每个大章节和小章节，都是以问题开始的。每个章节都提出一个问题，然后是这个问题的假设和推理，最后是我的验证过程和结果。当然，由于理解ART需要一些基础知识，比如汇编的知识等，我会以附录、基础知识等方式介绍给大家。

 

当这样组织本书时，你就不必从头到尾的去阅读它了，你只要找到感兴趣的章节，跟随我的思路，就可以一步一步的弄清楚相关的章节。甚至你可以从任意章节开始，获取你想要的东西。

 

阅读本书的过程，也将是一个愉快的过程。我将作为一个思维的导游，带您游览ART的世界。