查看原文
其他

【开发必备】加快Android编译速度的技巧,少走弯路!

2016-05-03 达内Android培训
前言

对于Android开发者而言,随着工程不断的壮大,Android项目的编译时间也逐渐变长,即便是有时候添加一行代码也需要等待好久才能看见期待的效果。之前加快Android编译的工具相对较少,其中最具有代表性的开源项目当属FaceBook的Buck和 mmin18的LayoutCast,除此之外还有JRebel 和 Jimulabs。不过前段时间google宣布推出Instant Run加快Android 编译速度,相信对其他的工具来说都是一次冲击,这也是写这篇文章的动机。


为什么Android程序员每次编译都需要等待那么久?如何加快编译速度?加快编译速度需要注意哪些问题?我们先来看下:


时间去哪了?


Android程序编译大致过程如图所示,详细的过程可以参考gradle 中的tasks。



那么为什么我们每次编译都需要等待那么久?事实上我们我们可以gradle中添加TaskExecutionListener来监听gradle脚本中每个task的执行时间。


class TimingsListener implements TaskExecutionListener, BuildListener {
private Clock clock
private timings = []
@Override
void beforeExecute(Task task) {
clock = new org.gradle.util.Clock()
}
@Override
void afterExecute(Task task, TaskState taskState) {
def ms = clock.timeInMs
timings.add([ms, task.path])
task.project.logger.warn "${task.path} took ${ms}ms"
}
@Override
void buildFinished(BuildResult result) {
println "Task timings:"
for (timing in timings) {
if (timing[0] >= 50) {
printf "%7sms %s\n", timing
}
}
}
@Override
void buildStarted(Gradle gradle) {}

@Override
void projectsEvaluated(Gradle gradle) {}

@Override
void projectsLoaded(Gradle gradle) {}

@Override
void settingsEvaluated(Settings settings) {}
}

gradle.addListener new TimingsListener()


执行脚本可以发现主要的费时在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方法。


//----dalvik/system/BaseDexClassLoader.java

protected Class findClass(String name) throws ClassNotFoundException {

Class clazz = pathList.findClass(name);

if (clazz == null) {

throw new ClassNotFoundException(name);

}return clazz;}


随后在DexPathList类中根据dexElements来查找相应的class。

//----dalvik/system/DexPathList.java

public Class findClass(String name) {

for (Element element : dexElements) {

DexFile dex = element.dexFile;

if (dex != null) {

Class clazz = dex.loadClassBinaryName(name, definingContext);

if (clazz != null) {return clazz;

}

}

}

return null;

}


其中dexElements代表着不同dex文件。

/** list of dex/resource (class path) elements */
private final Element[] dexElements;


也就是说,在ClassLoader加载类的时候会去按照dexElements中dex文件的顺序依次查找,如下图所示,在1.dex中查找到了A类,那么就不会再从后面的dex文件中继续查找了。



LayoutCast就是利用这样的原理,将修改的Java文件生成dex文件,并将此dex文件利用反射的方式插入到dexElements数组的前面。当然,从Java到dex的过程需要额外的查找各种依赖包之类的工作,这部分工作在cast.py中实现。


这种方式的实现在ART下是没有问题的,但是在Dalvik中就会出现IllegalAccessError的问题


java.lang.IllegalAccessError: Class ref in pre-verified class resolved to unexpected implementation
dalvik.system.DexFile.defineClass(Native Method)
dalvik.system.DexFile.loadClassBinaryName(DexFile.java:211)
dalvik.system.DexPathList.findClass(DexPathList.java:315)
dalvik.system.BaseDexClassLoader.findClass(BaseDexClassLoader.j


Install Run


Install Run 同样也是生成新的增量dex,但是新增dex中的类和原来的类名有区别。比如说,在修改Hello.java类之后,会生成包含Hello$overide类的dex文件。


那么,这个新增的dex文件中Hello$Override类是如何被调用的?

我们先看看原来的Hello.java文件经过Instant Run 编译前后的区别:


编译前的hello.java文件

public String name(String str) {
return str;
}


经过Instant Run之后的

---compiled Hello.java
public String name(String str) {
IncrementalChange var2 = $change;
return var2 != null?(String)var2.access$dispatch("name.(Ljava/lang/String;)Ljava/lang/String;", new Object[]{this, str}):str;
}


可以看出,如果$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 layoutInflater = LayoutInflater.from(context);
View view = layoutInflater.inflate(resourceId, root);

其中LayoutInflater.from的实现是在Context的实现类ContextImp中获取LAYOUT_INFLATER_SERVICE系统服务

//---- android/view/LayoutInflater.java
public static LayoutInflater from(Context context) {
LayoutInflater LayoutInflater =
(LayoutInflater)context.getSystemService(Context.
LAYOUT_INFLATER_SERVICE);
if (LayoutInflater == null) {
throw new AssertionError("LayoutInflater not found.");
}
return LayoutInflater;
}

那么ContextImpl又是如何获取相应的服务的,查看ContextImpl类可以发现,


//---- android/app/ContextImpl.java
public Object getSystemService(String name) {
ServiceFetcher fetcher = SYSTEM_SERVICE_MAP.get(name);
return fetcher == null ? null : fetcher.getService(this);
}


可以发现调用getSystemService的过程是在SYSTEM_SERVICE_MAP的表中查找ServiceFetcher,并返回ServiceFetcher中的mCachedInstance。那么只需要将mCachedInstance替换为自定义的BootInflater并在BootInflater中完成Resource的Overrirde就可以了,如下图所示。



修改Resource


我们知道Activity中的通过调用getResources()方法来访问资源,这实际上是调用ContextWrapper类中的getResource()方法

public Resources getResources(){
return mBase.getResources();
}

LayoutCast中就采用替换mBase为自定义的OverrideContext,并在其中将Resource返回为修改后的Resource。


Instant Run


Instant Run 对资源文件的处理和LayoutCast基本类似,但是在细节的处理上有所不同,比如Instant Run 通过对ActivityThread类中的mPackages和mResourcePackages的修改来改变LoadedApk中mResDir的值。


for (String fieldName : new String[] { "mPackages", "mResourcePackages" })
{
Field field = activityThread.getDeclaredField(fieldName);
field.setAccessible(true);
Object value = field.get(currentActivityThread);
for (Map.Entry
> entry : ((Map)value).entrySet())
{
Object loadedApk = ((WeakReference)entry.getValue()).get();
if (loadedApk != null) {
if (mApplication.get(loadedApk) == bootstrap)
{
if (externalResourceFile != null) {
mResDir.set(loadedApk, externalResourceFile);
}
if ((realApplication != null) && (mLoadedApk != null)) {
mLoadedApk.set(realApplication, loadedApk);
}
}
}
}
}
,>


资源文件修改的处理相对于Java文件的处理较为复杂,这中间涉及到aapt、attribute唯一性 、ID值一致等问题都增加了资源文件处理的难度。


总结


总的来说,每种方法都有自己的特色,BUCK依赖于自己强大的缓存和依赖管理系统。而LayoutCast 和Instant Run相对而言采用了更灵巧的方法。相对而言,Instant Run 凭借着天然的优势(和升级后的gradle结合),可以胜LayoutCast一筹,但是LayoutCast这种想法的提出还是很赞的。目前增量的编译 集中在Java文件的修改,对于Res的修改暂时好像还不支持,这在后续应该会有提升吧。


【福利时间】学安卓开发如何拿高薪?0基础学员如何逆袭过万高薪?如何用安卓敲开BAT名企大门?移动互联网发展新趋势有哪些?从事安卓开发,前景和“钱”景如何?……微信留言达妹,你想知道的都在这!

PS:5月份Android培训免费训练营,现在可以报名抢座喽!


再PS:《报名方式》微信回复姓名+联系方式+所在地区,即可参与报名!




我们是一群热爱IT的年轻人,如果你也爱IT、爱移动端开发,欢迎加入我们,让我们共同为梦想发声。Android开发QQ:3264778080

【达妹推荐】

微信关注公众号回复字母查看文章


回复A ► 学习Android薪资及开发技巧

回复B ►  安卓程序猿圈劲爆资讯回复C ►  程序员升职记回复D ► 2016 移动互联薪资行情

回复E ► 为什么Android开发最抢手

选达内=4个月=高薪就业


长按二维码即可识别关注↓↓↓



内容来源程序师,如涉及版权问题,请与我们联系,及时删除处理!文章如需转载请注明来源!

您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存