图片来自:medium.com/mindorks/im…
本文作者:jungle
前言
关于 Android
使用,尤其是大型使用而言,构建耗时是令人头疼的一件事。动辄几分钟甚至十几分钟的时刻更是令大部分开发人员苦不堪言。而在实践开发过程中面对最多的便是本地的增量编译,尽管官方对增量编译有做处理,但在详细项目,尤其是中大型项目中,作用其实都不太抱负。
布景
现在网易云音乐及旗下 look
直播,心遇,mus
等 app
先后采取了公共模块 aar
化,使用最新 agp
版别等措施,但全体构建耗时依然很久,增量构建一般在 2-5 min
左右。因为自己当时首要是担任开发 mus
的事务,因而结合现在 mus
的实践构建状况对增量构建做了一些优化作业。
耗时排查
结合 mus
构建的详细状况来看,现在构建耗时的大头首要会集在一些 Transform
和 dexMerge
( agp 版别 4.2.1 )。
关于 Transform
而言,首要是一些例如隐私扫描,自动化埋点等东西耗时严峻,一般增量时这些 Transform
的耗时就到达数分钟。
别的 dexMeger
使命也是增量构建时的大头,mus
增量 dexMerge
耗时约为 35-40s ,云音乐 dexMerge
增量构建耗时约 90-100s 。
优化方向
关于大型项目而言,最耗时的根本便是 Transform
了,这些 Transform
一般分为以下两类:
- 功能型
Transform
,移除只会影响自己的功能部分,不影响构建产品和项目运转。例如:埋点校验,隐私扫描。 - 强依靠型
Transform
,移除影响编译或项目正常运转。这部分一般是在apt
中采集一些信息,然后在Transform
履行时生成class
,在运转时调用履行。
功能型 Transform
能够通过编译开关和 debug/release
判别,防止在开发时调用履行。关于强依靠的 Transform
能够通过字节开源的 byteX
之类的东西将 Transform
流程拍平,对增量和全量编译都有作用。但是 byteX
的侵入性较大,需求将现有的 Transform
改成字节供给的 Transform
的子类。这儿咱们选用一种修正构建输入产品的轻量级计划来完结 Transform
增量构建的优化。
一起关于 dex
相关操作耗时的点,能够结合 dexMerge
的实践流程做增量优化,保证只有最小粒度的改动点会触发 dex
的 merge
操作。
Trasnform 增量构建
尽管 mus
现在依靠的大部分 Transform
的 isIncremental
装备回来 true
,但是实践的 io
和插桩很少有做增量逻辑的。
在增量构建时,大部分 class
在第一次构建时现现已过各 Transform
的处理,被插桩修正后移动到对应的下一级 Transform
目录了,增量时这部分现已处理过的产品其实没有必要再在各 Transform
之间履行插桩和 io
了。
现在大部分 Transform
的写法都是如下写法:
input.jarInputs.each { JarInput jarInput ->
ile destFile = transformInvocation.getOutputProvider().getContentLocation(destName , jarInput.contentTypes, jarInput.scopes, Format.JAR)
FileUtils.copyFile(srcFile, destFile)
}
input.directoryInputs.each { DirectoryInput directoryInput ->
File destFile = transformInvocation.getOutputProvider().getContentLocation(directoryInput.name, directoryInput.contentTypes, directoryInput.scopes, Format.DIRECTORY)
...
FileUtils.copyDirectory(directoryInput.file, destFile)
}
这儿在增量构建时应该做的是只对产生改动的产品做插桩和 copy
的操作:
// 伪代码如下:
// jar 增量处理
if(!isIncremental) return
if (Status.ADDED ==jarInput.status || Status.CHANGED==jarInput.status){
File destFile = transformInvocation.getOutputProvider().getContentLocation(destName , jarInput.contentTypes, jarInput.scopes, Format.JAR)
FileUtils.copyFile(srcFile, destFile)
}
// class 增量处理
val dest = outputProvider!!.getContentLocation(
directoryInput.name, directoryInput.contentTypes,
directoryInput.scopes, Format.DIRECTORY
)
if(Status.ADDED ==dirInput.status || Status.CHANGED==dirInput.status){
dirInput.changedFiles.forEach{
// 插桩逻辑
...
// 只移动增量改动插桩后的class文件到对应目录下
copyFileToTarger(it,dest)
}
}
当然因为一些历史原因,有些 Transform
的代码或许都找不到,无法改造,因而为了兼容一切状况,这边简略对 Transform
的输入产品做了简略的 hook
替换操作。
一般完结一个 Transform
都是新建一个类完结 Trasnform
的 transform
方法,在 transform
方法里履行详细操作,而 Trasnform
产品的入参正是在 com.android.build.api.transform.TransformInvocation#getInputs
的方法里:
public interface TransformInvocation {
Context getContext();
/**
* Returns the inputs/outputs of the transform.
* @return the inputs/outputs of the transform.
*/
@NonNull
Collection<TransformInput> getInputs();
...
}
通过 hook
掉 TransformInvocation#getInputs
回来的 JarInput
和 DirectoryInput
,将 JarInputs
和 Directory
中未产生改动的产品移除。
通过上述优化后本来耗时几十秒到几分钟的 Transform
根本都能被压缩到1-2 s以内。
DexMerge 增量优化
事实上 agp
版别更新十分频频,关于不同版别,dex
耗时不同。关于 3.x 的版别 dex
相关 task
首要耗时会集在dexBuilder
上,而4.x的版别首要耗时则会集在dexMerger
,因为现在 mus
等事务都使用 4.2 及以上版别的 agp
,研讨发现 4.x 的版别实践上对 dexBuilder
有做了增量的处理,全体耗时不多,因而首要对4.2及以上版别 dexMerger
耗时做优化。
顾名思义,dexMerge
实践上是对现已打出的 dex
进行合并,将多个dex
或许 jar
组成一个较大的 dex
的流程。依照正常状况,dex
数量越多,使用的启动速度越慢,因而关于大型项目,dexMerge
也是必不可少的一步。
dexMerge 流程
dexMerger
是有分桶操作的,桶的数量一般不额外装备使用默认值 16,一般桶的分配逻辑是依照包名来的,也便是说同一包名下的 class
会被分配到同一个桶里。
fun getBucketNumber(relativePath: String, numberOfBuckets: Int): Int {
...
val packagePath = File(relativePath).parent
return if (packagePath.isNullOrEmpty()) {
0
} else {
when (numberOfBuckets) {
1 -> 0
else -> {
// 同一包名下class被分到同一个bucket里
val normalizedPackagePath = File(packagePath).invariantSeparatorsPath
return abs(normalizedPackagePath.hashCode()) % (numberOfBuckets - 1) + 1
}
}
}
}
public val File.invariantSeparatorsPath: String
get() = if (File.separatorChar != '/') path.replace(File.separatorChar, '/') else path
实践的构建产品如下:
增量构建时,agp
会依照以下规矩来履行 dexMerge
使命:
- 假如有
jar
文件状况产生改动或许被移除了,即对应状况CHANGED
或许REMOVE
,这种状况一切的桶都要从头走dexMerge
流程,一般默认的bucket
数量是 16 个,也便是当构建时有一个jar
文件产生改动时,一切的输入产品悉数都会参加dexMeger
流程。(尽管d8
命令行东西对增量dexMeger
自身有必定优化,增量速度对比全量会有必定加快,但关于大型项目而言全体还是很慢。)
- 假如是只有新增的
jar
或许dex
产生改动的Directory
,那么会依据对应的包名获取到对应的桶的数组,只对找到的桶的数组进行增量的打包,这也便是咱们说的dexMerge
自身的增量操作。
回来对应bucket id 数组的代码如下:
private fun getImpactedBuckets(
fileChanges: SerializableFileChanges,
numberOfBuckets: Int
): Set<Int> {
val hasModifiedRemovedJars =
(fileChanges.modifiedFiles + fileChanges.removedFiles)
.find { isJarFile(it.file) } != null
if (hasModifiedRemovedJars) {
// 1. 假如有CHANGED或许REMOVE状况的jar,则回来悉数bucket数组。
return (0 until numberOfBuckets).toSet()
}
// 2. 假如是新增jar,或许是directory中class产生改动,回来计算到的bucket数组。
val addedJars = (fileChanges.addedFiles).map { it.file }.filter { isJarFile(it) }
val relativePathsOfDexFilesInAddedJars =
addedJars.flatMap { getSortedRelativePathsInJar(it, isDexFile) }
val relativePathsOfChangedDexFilesInDirs =
fileChanges.fileChanges.map { it.normalizedPath }.filter { isDexFile(it) }
return (relativePathsOfDexFilesInAddedJars + relativePathsOfChangedDexFilesInDirs)
.map { getBucketNumber(it, numberOfBuckets) }.toSet()
}
这种增量操作适用的是大部分代码包括在壳工程中且不会频频改动底层库的事务,不知道是不是因为国外包括 google
官方自身项目开发形式便是这样。关于大部分国内的项目,只需你做了组件化,甚至没做事务组件化但是有多个子模块类型的项目,只需有涉及到子模块的改动,一切的产品都要悉数从头参加 dexMerge
。
关于 mus
,云音乐等组件化工程,一般构建时只有壳工程是以文件夹的形式作为输入产品在后续的 Transform
和 dex
相关流程里流通,而子模块一般是以 jar
的形式参加构建,而咱们实践开发中根本便是对各事务模块的改动,对应上述第一种状况,一切的桶悉数会从头走的 dexMerger
,而第二种状况只有改动壳工程代码或许新增依靠或许模块之类的才会命中,这种状况偏少能够不用考虑。
针对上述问题解决方法首要有两种:
-
将一切的
jar
拆解为文件夹,这样只有改动模块对应的分桶收效,但是这种问题在于哪怕只改动了一个模块中的两个类,因为bucket
是依照包名固定分在同一个桶里,非相同包名则依据包名随机分桶,很或许也会连带着其他的bucket
一起进行dexMerger
,尽管能够恰当扩大分桶的数量,但是同样的,也没法彻底躲避这种问题。 -
仅针对产生改动的输入产品进行从头的
dexMerger
,将新生成的merge
后的dex
打进apk
或许移到设备中保证运转时增量改动的这部分代码能够被履行。
为了保证最小化单元的 dex
参加后续的 dexMerge
流程,咱们选用第二种方式作为 dexMerge
增量构建的计划。
增量构建产品的 dexMerge
通过 hook
dexMerge
的要害流程,咱们能够获取到产生改动的 jar
文件和包括 dex
的文件夹,然后把 dexMerge
输入产品由本来的悉数产品修正为咱们 hook
之后的产品:
咱们将一切产生改动的 dex
文件汇总移动到暂时的文件目录内,然后将方针文件夹作为一个输入产品即可,关于产生改动的 jar
,咱们也将其加到输入的产品里,然后持续走本来的 dexMerge
流程。
打出来的增量 dex
产品如下:
一起咱们需求改动增量 dexMerge
的输出目录,因为 dexMerger
正常运转时,在有代码修正的状况,一切的 bucket
都会被新的产品覆盖,哪怕新的产品是空文件夹。假如不更改文件目录就会覆盖掉之前全量打出的一切的 dex
,导致终究的 apk
包仅包括这次增量的 dex
从而无法正常运转。
一起因为每次增量构建改动的产品都不同,因而对每次构建产品的输出目录做了递加,同样是保证前次增量的产品不要被本次覆盖掉,这儿每次的产品都对后续构建流程有作用,详细会在后续内容中阐明。
当然,新的目录详细放在哪里,也跟咱们挑选的计划有联系。
热更新计划
因为有了增量的 dex
,咱们很容易联想到热更新的计划,行将增量构建出的 dex
推送到手机 sd
卡上,然后在运转时去动态加载。这种状况下增量 merge
的 dex
产品放在哪个目录下都能够,因为对后续构建流程现已没有什么太大影响了,影响的首要是运转时 dex
的加载逻辑。
1. 增量 dex 暂时产品
上述尽管有了增量的构建产品,但是为了运转时方便排序仍然会每次把当次编译新增的 dex
移动到暂时目录 pulledMergeDex
文件夹中。
然后通过 adb
每次批量整理设备中暂时的 dex
,再将悉数 pulledMergeDex
目录下的 dex
推送到设备中,这样做的意图是为了保证设备中 dex
的准确性,防止因为某次构建残留的 dex
产品运转影响现有的代码逻辑。
2. 运转时动态加载 dex
因为 dex
的加载是依照 PathList
加载 dexElements
数组的顺序早年往后加载的,因而只需依照 dex
的热更计划,在运转时反射替换 PathClassLoader
中的 dexElements
数组,将之前推送到手机目录中的数组,依照倒序先摆放好,然后再插入在 dexElements
数组最前面即可,这儿热更新的详细原理不再阐述。
接入项目中实测发现有些代码改动会不收效(首要是 Application
和 Application
直接引用到的 class
),详细原因应该是 Android N 对热补丁的影响,本地在 AndroidMainfest
文件中加了 safemode=true
,但在实践设备运转还是无效,不知道是不是现在设备的版别不支撑了。别的一种可行的方式便是类似 tinker
的解决计划对 Application
进行改造,然后通过别的的 ClassLoader
加载后续的 class
了。
Dex 重排计划
除了在运转时加载 dex
,咱们也能够测验在编译时将增量的 dex
打包到 apk
中。
gradle
中对应的 task
都有对应的构建缓存,假如咱们增量的 dex
放置在一个随机目录中,后续的 task
例如 package
,assemble
等检测输入产品没有改动的状况下,是会直接走增量构建缓存的,也就不会再履行了。而咱们期望咱们增量的 dex
被打进 apk
中,后续的 package
等 task
必须要被履行。
这种状况下,构建产品的目录就比较有讲究了,咱们能够取个巧,在之前 dexMeger
全量产品输出的目录下,添加一个 incremental
文件夹,专门做增量产品的 dexMeger
,同样的每次增量的产品在该文件目录下依照 index
递加,这样保证每次增量 dexMerge
的产品没有抵触。
打包到 apk
中的 dex
同样也是会依照 dex
的摆放顺序加载履行,因而咱们需求将新增的 dex
在编译时就摆放在 apk
的最前面。 apk
中 dex
的排序是在 package
使命中去履行的,因而咱们需求测验去 hook
package
的要害途径,将咱们新增的 dex
排在 Apk
内 dex
数组最前面。
Android Package 流程 hook
Android package
担任将之前打包流程中的一切产品汇总打包到终究对外输出的 apk
产品里,dex
自然也不例外。Android package
会结合产品的改动对 apk
中产生改动的文件做更改,将 apk
中对比 CHANGED
和 REMOVED
的文件删去,然后将构建产品中 ADDED
和 CHANGED
的产品从头添加到 apk
中去。
public void updateFiles() throws IOException {
// Calculate packagedFileUpdates
List<PackagedFileUpdate> packagedFileUpdates = new ArrayList<>();
// dex 文件的改动
packagedFileUpdates.addAll(mDexRenamer.update(mChangedDexFiles));
...
deleteFiles(packagedFileUpdates);
...
addFiles(packagedFileUpdates);
}
private void deleteFiles(@NonNull Collection<PackagedFileUpdate> updates) throws IOException {
// 当时 CHANGED REMOVED 状况的文件 先移除apk
Predicate<PackagedFileUpdate> deletePredicate =
mApkCreatorType == ApkCreatorType.APK_FLINGER
? (p) -> p.getStatus() == REMOVED || p.getStatus() == CHANGED
: (p) -> p.getStatus() == REMOVED;
...
for (String deletedPath : deletedPaths) {
getApkCreator().deleteFile(deletedPath);
}
}
private void addFiles(@NonNull Collection<PackagedFileUpdate> updates) throws IOException {
// NEW CHANGED 状况的文件 添加进apk
Predicate<PackagedFileUpdate> isNewOrChanged =
pfu -> pfu.getStatus() == FileStatus.NEW || pfu.getStatus() == CHANGED;
...
for (File arch : archives) {
getApkCreator().writeZip(arch, pathNameMap::get, name -> !names.contains(name));
}
}
文件联系则通过 DexIncrementalRenameManager
来保护,DexIncrementalRenameManager
每次会先去 dex-renamer-state.txt
去加载当时的 dex mapping
联系,结合改动的 dex
去对 apk
中文件做更改,一起每次排序完结后会将新的 dex mapping
更新在 dex-renamer-state.txt
文件中。
咱们这边参考本来的 mapping
文件,在每次编译时,将构建产品中的 dex
途径和该 dex
对应 apk
中的实践 dex
的 path
classesX.dex
相关起来做好 mapping
,然后存在单独记录的dex_mapping
文件里。
每次增量编译有新 merge
的 dex
时,先将增量的 dex
依照 classes.dex
,classes2.dex
… 的顺序摆放,然后将 dex-mapping
中的构建产品和 apk
中 dex
途径的联系加载到内存中,依照原有的顺序摆放在增量的 dex
后面,最后通过 hook
package
流程将改动的内容同步更新到 apk
文件中。
全体流程如下图:
在 apk
更新完结后,将最新的的 dex
和 apk
中 dex
途径的 mapping
联系从头写到 dex_mapping
文件记录最新的的 dex
和 apk path
的联系。为了防止每次 dex
悉数参加重排,能够在 classes.dex
和 classesN.dex
中预留必定数量的空位,防止每次一切 dex
重排。
实测 package
会有部分耗时添加,全体应该在 1s 以内,mus
全体 dexMerge
耗时由 35-40 s 缩减到3 s 左右。
现在该增量构建组件两种计划都支撑,能够依据开关装备,要注意的点是热更的计划或许涉及到Application
的改造。
优化作用
通过上述计划的优化,实测在 mus
中抱负状况下更改子模块中一行最简略的 kotlin
类中的一行代码 task
总耗时(不包括 configure
)最快约 10s,实践开发状况来看根本在 20-40s 之间。这部分耗时首要是实践开发改动的 class
和模块会多一些,一起包括了configure
的耗时,这部分时刻现在是无法防止的。一起也包括 class
编译和 kapt
等 task
一起的耗时,也会遭到设备的 cpu
,实时内存等影响。
以上数据基于个人电脑,2.3 GHz 四核 Intel Core i7,32 GB 3733 MHz LPDDR4X,不同设备跑出的数据会有部分差异,但全体优化作用还是很明显的。
总结
结合上述的优化计划,增量构建速度全体在一个比较低的水平,当然例如kotlin编译,kapt,增量的判别等还有进一步的优化空间,期待后续和其他 task
的进一步优化完结时持续分享。
本文发布自网易云音乐技能团队,文章未经授权禁止任何形式的转载。咱们终年招收各类技能岗位,假如你预备换作业,又恰好喜爱云音乐,那就参加咱们 grp.music-fe(at)corp.netease.com!