[hellogcc] Android中编译工具链的改动----LLVM分量的增加
- From: Ning Shi <shiningning1984@xxxxxxxxx>
- To: hellogcc@xxxxxxxxxxxxx
- Date: Wed, 5 Mar 2014 15:01:01 +0800
大家好：
给大家分享一下Android中编译工具链的一点改动。全是我自己的理解，有不对的地方欢迎大家指正。
这个改动是Android的runtime（也可以说是VM，这两种说法在Google官方文档中也多次交互出现）改动引发的。之前Android采用的是Dalvik
VM，在Android2.2之前，连JIT都没有使用，只是解释执行，所以速度很慢，从Android2.2之后加入了JIT之后，一直用了相当长的时间。直到ART（Android
Runtime）的出现,ART的出现也是为了进一步提高运行速度。所以总的来说，不管是添加JIT支持，还是现在的ART，都是为了速度更快。
ART是在Android4.4正式出现的，就是它引起了Android中编译工具链的改动。之前Dalvik拿到.dex或者优化过的.odex文件，是使用JIT然后执行的。现在ART是直接使用LLVM去做AOT（Ahead
of
Time），这样的话，执行速度自然就上来了，带来的牺牲是应用的安装速度会降下来，因为AOT编译是在安装的时候做的，后续的启动和执行，都使用的是AOT之后的结果。所以等于是用一次时间牺牲，换来之后的多次时间节省。
ART目前是和Dalvik同时存在系统中的，用户也可以自己选择。在系统中它们分别以Dalvik runtime (libdvm.so)
和 ART
(libart.so)这两个库的形式存在，ART的源码位置也是在和Dalvik的同级位置，直接在Android目录下有个art目录。目前art目录下的设置基本上也是参照Dalvik的形式来的，几个工具也都是类似，只是把与原来的dexopt工具给换成了dex2oat，然后引入了LLVM去做编译的工作。到这个程度，LLVM等于已经参与了Android上的所有应用的编译工作，在art出现之前，LLVM只是处理Android
Renderscript中的rs文件。
ART目前还有一系列的问题，就是依然采用dex格式文件作为输入，这带来的好处是之前的应用可以直接在art上安装，不会有什么问题。但是dex格式本身就是给Dalvik所设计的可执行格式，所以我认为，这个问题在彻底丢掉Dalvik之后，可能会去解决。
这是我的一些想法。本来想着简单写几句，又罗嗦了。欢迎大家批评指正，我回头整理出个博文出来吧。
谢谢。
史宁宁
2014年3月5日
Other related posts:
