Android编译速度如何才能加快

时间:2016-07-20 12:08:09    来源:信狮教育    已有人浏览
大家都关注: 深圳北大青鸟深圳信狮
分享到:
导读:写在前面的话对 于Android开发者而言,随着工程不断的壮大,Android项目的编译时间也逐渐变长,即便是有时候添加一行代码也需要等待好久才
写在前面的话
对 于Android开发者而言,随着工程不断的壮大,Android项目的编译时间也逐渐变长,即便是有时候添加一行代码也需要等待好久才能看见期待的效 果。之前加快Android编译的工具相对较少,其中最具有代表性的开源项目当属FaceBook的Buck和 mmin18的LayoutCast,除此之外还有JRebel 和 Jimulabs。不过前两天google宣布推出Instant Run加快Android 编译速度,相信对其他的工具来说都是一次冲击,这也是写这篇文章的动机。
 
相 对于Buck而言,LayoutCast显得更轻量一些,对项目的侵入性较弱。对于一些繁重的项目而言,Buck带来的好处是显而易见的,但是适配过程中 的坑也是很多的。Instant Run 对项目的侵入性其实也是比较大的,但是这些都不需要用户去操作、配置,所以看起来和LayoutCast一样属于轻量型的。
 
时间去哪儿了?
 
 
Android程序编译大致过程如图所示,详细的过程可以参考gradle 中的tasks。
 
 
那么为什么我们每次编译都需要等待那么久?事实上我们我们可以gradle中添加TaskExecutionListener来监听gradle脚本中每个task的执行时间。
 
执行脚本可以发现主要的费时在dex(包含preDex)以及install这两个步骤。BUCK和LayoutCast的主要工作也是集中于这些费时的步骤上面。
 
如何加快?
 
 
开发过程中对项目的改动一般分为Java文件的修改以及资源文件的修改,这些修改都会涉及到上述的几个费时步骤,这也就是为什么即便我们修改一行代码也需要编译很久。
 
1、Java文件修改
 
通常,修改的.java文件会先经过javac操作生成.class文件。而后与其他的.class文件经过dx生成.dex文件。经过dx的操作很费时,针对这种情况,BUCK、LayoutCast和Instant Run采用了两种方法来解决。
 
BUCK
 
BUCK建立了一套完善的依赖规则以及细化的缓存系统来缩减编译时间,并通过使用三方的dex merege工具将.dex文件合并的时间复杂度从O(N^2)降到O(NlgN)。
 
如图所示,当修改A.java文件时,只涉及到相应的dx操作以及dex merge操作(红色部分),这样就大大的缩减了dx的操作时间。BUCK在依赖规则上狠下功夫推出了ABI,更是进一步的减少了不必要的操作。
 
LayoutCast
 
LayoutCast的实现同很多插件的实现原理差不多,具体分析如下:
 
在ClassLoader查找类的时候会先去调用BaseDexClassLoader类中的findClass方法。
 
 
随后在DexPathList类中根据dexElements来查找相应的class。
 
 
其中dexElements代表着不同dex文件。
 
 
也就是说,在ClassLoader加载类的时候会去按照dexElements中dex文件的顺序依次查找,如下图所示,在1.dex中查找到了A类,那么就不会再从后面的dex文件中继续查找了。
 LayoutCast就是利用这样的原理,将修改的Java文件生成dex文件,并将此dex文件利用反射的方式插入到dexElements数组的前面。当然,从Java到dex的过程需要额外的查找各种依赖包之类的工作,这部分工作在cast.py中实现。
 
这种方式的实现在ART下是没有问题的,但是在Dalvik中就会出现IllegalAccessError的问题
 
 
Install Run
 
Install Run 同样也是生成新的增量dex,但是新增dex中的类和原来的类名有区别。比如说,在修改Hello.java类之后,会生成包含Hello$overide类的dex文件。
 
那么,这个新增的dex文件中Hello$Override类是如何被调用的?
 
我们先看看原来的Hello.java文件经过Instant Run 编译前后的区别:
 
编译前的hello.java文件
 
 
经过Instant Run之后的
 
 
可以看出,如果$change存在的话,就会调用$change中相应的函数,那么我们只需要通过反射将Hello.java中$change字段改为修改后的Hello$override的类就Ok了。
 
这也就是为什么Instant Run并不存在前面说到的IllegalAccessError的问题,并且支持不重启就能看见修改效果的原因。
 
2、Res修改
 
Resource 文件的修改会涉及到AAPT、ApkBuilder以及最后的Install操作。其中APPT的操作要求比较高,LayoutCast、Instant Run均没有在这部分进行优化,他们的主要工作在于后面的两个操作。其主要的思路在于将修改的后的资源利用aapt打包成新的.ap_文件,并通过反射的 方式将原来的资源文件改为修改后的。
 
LayoutCast
 
LayoutCast主要做了两件事。
修改LayoutInflater服务
对于下面的用法我们并不陌生:
 
 
其中LayoutInflater.from的实现是在Context的实现类ContextImp中获取LAYOUT_INFLATER_SERVICE系统服务
 
 
那么ContextImpl又是如何获取相应的服务的,查看ContextImpl类可以发现,
 
 
可 以发现调用getSystemService的过程是在SYSTEM_SERVICE_MAP的表中查找ServiceFetcher,并返回 ServiceFetcher中的mCachedInstance。那么只需要将mCachedInstance替换为自定义的BootInflater 并在BootInflater中完成Resource的Overrirde就可以了,如下图所示。
 
 
修改Resource
 
我们知道Activity中的通过调用getResources()方法来访问资源,这实际上是调用ContextWrapper类中的getResource()方法
 
 
LayoutCast中就采用替换mBase为自定义的OverrideContext,并在其中将Resource返回为修改后的Resource。
 
Instant Run
 
Instant Run 对资源文件的处理和LayoutCast基本类似,但是在细节的处理上有所不同,比如Instant Run 通过对ActivityThread类中的mPackages和mResourcePackages的修改来改变LoadedApk中mResDir的 值。
 
 
资源文件修改的处理相对于Java文件的处理较为复杂,这中间涉及到aapt、attribute唯一性 、ID值一致等问题都增加了资源文件处理的难度。
 
总结
 
总的来说
 
 
每 种方法都有自己的特色,BUCK依赖于自己强大的缓存和依赖管理系统。而LayoutCast和Instant Run相对而言采用了更灵巧的方法。相对而言,Instant Run 凭借着天然的优势(和升级后的gradle结合),可以胜LayoutCast一筹,但是LayoutCast这种想法的提出还是很赞的。目前增量的编译 集中在Java文件的修改,对于Res的修改暂时好像还不支持,这在后续应该会有提升吧。
  • 勤学苦练是良训

    姓名:邓*班级:3T133专业:ACCP学历:大专年龄:24就业岗位:Java软件开发工程师就业薪资:8500就业企业:深圳*利创投信息技术有限公司经

  • 饶*强:新的教学模式让我学到了更多

    我初中毕业,英语较差,要找一个适合自己的培训机构的确很不容易。找了很久,偶然机会认识了哥哥的朋友,信狮学校毕业的,工资很高,推荐我来学习,抱着试试看的想法来信狮了解了一下

  • 黄*冲:北大青鸟让我找到了好工作

    回想这两年的学习,苦乐参半,在信狮的学习使我们不经意间长大成人,无论做人还是做事,都有了职业人的风范,不再幼稚青涩。现在,我们知道企业的真正需求,会以理性的态度面对生活,

  • 刘于奇:不断成长和进步

      姓名:刘于奇  年龄:23  原学历:大专  现工作单位:深圳视图信息技术有限公司  现职位:JAVA软件工程师  月薪:4300  入

  • 高中毕业打工没前景,选择北大青鸟信狮教育让她重新出发

    高中毕业打工没出路!怎么办?北大青鸟信狮教育学技术,找好工作。

热点专题 更多 >
热门标签 更多 >