Android 性能优化实现全量编译提速的黑科技

目录
  • 一、背景描述
  • 二、效果展示
    • 2.1、测试项目介绍
  • 三、思路问题分析与模块搭建:
    • 3.1、思路问题分析
    • 3.2、模块搭建
  • 四、问题解决与实
    • 编译流程启动,需要找到哪一个 module做了修改
    • module 依赖关系获取
    • module 依赖关系 project 替换成 aar 技术方案
    • hook 编译流程
  • 五、一天一个小惊喜( bug 较多)
    • 5.1 output 没有打包出 aar
    • 5.2 发现运行起来后存在多个 jar 包重复问题
    • 5.3 发现 aar/jar 存在多种依赖方式
    • 5.4 发现 aar 新姿势依赖
    • 5.5 发现 android module 打包出来可以是 jar
    • 5.6 arouter  bug
  • 六、下一步展望

一、背景描述

在项目体量越来越大的情况下,编译速度也随着增长,有时候一个修改需要等待长达好几分钟的编译时间。

基于这种普遍的情况,推出了 RocketX ,通过在编译流程 动态 替换 module 为 aar ,提高全量编译的速度。

二、效果展示

2.1、测试项目介绍

  • 目标项目一共 3W+ 个类与资源文件,全量编译 4min 左右(测试使用 18 年 mbp 8代i7 16g)
  • 通过 RocketX 全量增速之后的效果(每一个操作取 3 次平均值)

项目依赖关系如下图,app 依赖 bm 业务模块,bm 业务模块依赖顶层 base/comm模块

  • rx(RocketX) 编译 - 可以看到 rx(RocketX) 在无论哪一个模块的编译速度基本都是在控制在 30s 左右,因为只编译 app 和 改动的模块,其他模块是 aar 包不参与编译。
  • 原生编译 - 当 base/comm 模块改动,底部的所有模块都必须参与编译。因为 app/bmxxx 模块可能使用了 base 模块中的接口或变量等,并且不知道是否有改动到。(那么速度就非常慢)
  • 原生编译 - 当 bmDiscover 做了改动,只需要 app模块和 bmDiscover 两个模块参与编译(速度较快)

对于 rx(RocketX) 编译顶层模块速度提升 300%+

三、思路问题分析与模块搭建:

3.1、思路问题分析

  • 需要通过 gradle plugin 的形式动态修改没有改动过的 module 依赖为 相对应的 aar 依赖,如果 module 改动,退化成 project 工程依赖,这样每次只有改动的 module 和 app 两个模块编译。
  • 需要把implement/api moduleB,修改为implement/api aarB,并且需要知道插件中如何加入 aar 依赖和剔除原有依赖
  • 需要构建 local maven 存储未被修改的 module 对应的 aar(也可以通过 flatDir 代替速度更快)
  • 编译流程启动,需要找到哪一个 module 做了修改
  • 需要遍历每一个 module的依赖关系进行置换,module依赖怎么获取?一次性能获取到所有模块依赖,还是分模块各自回调?修改其中一个模块依赖关系会阻断后面模块依赖回调?
  • 每一个module换变成 aar 之后,自身依赖的 child 依赖 (网络依赖,aar),给到 parent module (如何找到所有 parent module) ? 还是直接给 app module ? 有没有 app 到 module 依赖断掉的风险?这里需要出一个技术方案。
  • 需要hook 编译流程,完成后置换 loacal maven 中被修改的 aar
  • 提供 AS 状态栏 button, 实现开启关闭功能,加速编译还是让开发者使用已经习惯性的三角形 run 按钮

3.2、模块搭建

依照上面的分析,虽然问题很多,但是大致可以把整个项目分成以下几块:

四、问题解决与实

如何手动添加 aar 依赖,分析implement 源码实现入口在 DynamicAddDependencyMethods 中的 tryInvokeMethod 方法。他是一个动态语言的methodMissing 功能

tryInvokeMethod 代码分析

 public DynamicInvokeResult tryInvokeMethod(String name, Object... arguments) {
       //省略部分代码 ...
       return DynamicInvokeResult.found(this.dependencyAdder.add(configuration, normalizedArgs.get(0), (Closure)null));
 }

dependencyAdder 实现是一个 DirectDependencyAdder

private class DirectDependencyAdder implements DependencyAdder<Dependency> {
        private DirectDependencyAdder() {
        }
        public Dependency add(Configuration configuration, Object dependencyNotation, @Nullable Closure configureAction) {
            return DefaultDependencyHandler.this.doAdd(configuration, dependencyNotation, configureAction);
        }
    }

最后是在 DefaultDependencyHandler.this.doAdd 进行添加进去,而 DefaultDependencyHandler 在 project可以获取

public interface Project extends Comparable<Project>, ExtensionAware, PluginAware {
     ...
     DependencyHandler getDependencies();
     ...
}

而 doAdd 方法三个参数通过debug 源码发现,configuration就是 "implementation","api", "compileOnly" 这三个字符串生成的对象,dependencyNotation是一个 LinkHashMap 有两个键值对,分别是 name:aarName, ext:aar,最后一个configureAction 传 null 就可以了,调用project.dependencies.add 最终会调到 doAdd 方法,也就是说直接调用 add 即可。

 public Dependency add(String configurationName, Object dependencyNotation) {
        return this.add(configurationName, dependencyNotation, (Closure)null);
    }
    public Dependency add(String configurationName, Object dependencyNotation, Closure configureClosure) {
       //这里直接调用到了 doAdd
        return this.doAdd(this.configurationContainer.getByName(configurationName), dependencyNotation, configureClosure);
    }

那么依葫芦画瓢添加 aar/jar 的实现代码:configName 是 childProject中的 configName ,也就是 "implementation", "api","compileOnly" 这三个字符串,原封不动拿过来:

   fun addAarDependencyToProject(aarName: String, configName: String, project: Project) {
        //添加 aar 依赖 以下代码等同于 api/implementation/xxx (name: 'libaccount-2.0.0', ext: 'aar'),源码使用 linkedMap
        val map = linkedMapOf<String, String>()
        map.put("name", aarName)
        map.put("ext", "aar")
        project.dependencies.add(configName, map)
    }

localMave 优先使用 flatDir实现通过指定一个缓存目录 getLocalMavenCacheDir 把生成aar/jar 包丢进去,依赖修改时候通过 上面的 4.1 添加对应的 aar 即可:

  fun flatDirs() {
        val map = mutableMapOf<String, File>()
        map.put("dirs", File(getLocalMavenCacheDir()))
        appProject.rootProject.allprojects {
            it.repositories.flatDir(map)
        }
    }

编译流程启动,需要找到哪一个 module做了修改

使用遍历整个项目的文件的 lastModifyTime 去做实现

已每一个 module 为一个粒度,递归遍历当前 module 的文件,把每个文件的 lastModifyTime 整合计算得出一个唯一标识 countTime 通过 countTime 与上一次的作对比,相同说明没改动,不同则改动. 并需要同步计算后的 countTime 到本地缓存中

整体 3W 个文件耗时 1.2s 可以接受,目前在类 ChangeModuleUtils.kt 进行实现

module 依赖关系获取

通过以下代码可以找到生成整个项目的依赖关系图时机,并在此处生成依赖图解析器。时机要在真正编译之前,确保依赖关系获取后替换能生效,而且要在全局module依赖图已经生成之后,通过以下监听可以满足:

  public interface DependencyResolutionListener {
    void beforeResolve(ResolvableDependencies var1);
    void afterResolve(ResolvableDependencies var1);
}
   project.gradle.addListener(DependencyResolutionListener listener)

如何获取每个module 的依赖,依赖就藏在Configuration.dependencies,那么通过project.configurations.maybeCreate(configName) 找到所有的 Configuration对象,就能得到每个module的 dependencies

module 依赖关系 project 替换成 aar 技术方案

每一个 module 依赖关系替换的遍历顺序是无序的,所以技术方案需要支持无序的替换

目前使用的方案是:如果当前模块 A 未改动,需要把 A 通过 localMaven 置换成 A.aar,并把 A.aar 以及 A 的 child 依赖,给到第一层的 parent module 即可。(可能会质疑如果 parent module 也是 aar 怎么办,其实这块也是没有问题的,这里就不展开说了,篇幅太长)

为什么要给到 parent 不能直接给到 app ,下图一个简单的示例如果 B.aar 不给 A 模块的话,A 使用 B 模块的接口不见了,会导致编译不过

给出整体项目替换的技术方案演示:

整体的实现在 DependenciesHelper.kt这个类中,由于讲起来篇幅太长,有兴趣可查阅开源库代码

hook 编译流程

完成后置换 loacal maven 中被修改的 aar

点击三角形 run,执行的命令是 app:assembleDebug , 需要在 assembleDebug 后面补一个 uploadLocalMavenTask, 通过 finalizedBy把我们的task运行起来去同步修改后的 aar :

val localMavenTask = childProject.tasks.maybeCreate("uploadLocalMaven"+buildType.capitalize(),LocalMavenTask::class.java)
localMavenTask.localMaven = this@AarFlatLocalMaven
bundleTask?.finalizedBy(localMavenTask)

提供 AS 状态栏 button,小火箭按钮一个喷火一个没有喷火,代表 enable/disable , 一个 扫把clean rockectx 的缓存,需要通过编写 intellij idea plugin 即可,也就是 目前拥有两个插件了,一个 gradle 插件一个 AS 插件: image.png

五、一天一个小惊喜( bug 较多)

5.1 output 没有打包出 aar

发现点击 run 按钮 执行的命令是 app:assembleDebug ,各个子 module 在 output 并没有打包出 aar

解决:通过研究 gradle 源码发现打包是由 bundle{BuildType}Aar 这个task执行出来,那么只需要将各个模块对应的 task 找到并注入到 app:assembleDebug 之后运行即可:

        android.applicationVariants.forEach {
            getAppAssembleTask(ASSEMBLE + it.flavorName.capitalize() + it.buildType.name.capitalize())?.let { task ->
                    hookBundleAarTask(task, it.buildType.name)
                }
        }

5.2 发现运行起来后存在多个 jar 包重复问题

  • 解决:implementation fileTree(dir: "libs", include: ["*.jar"])jar 依赖不能交到 parent module,jar 包会打进 aar 中的lib 可直接剔除。

通过以下代码可以判断:

// 这里的依赖是以下两种: 无需添加在 parent ,因为 jar 包直接进入 自身的 aar 中的libs 文件夹
if (childDepency is DefaultSelfResolvingDependency && (childDepency.files is DefaultConfigurableFileCollection || childDepency.files is DefaultConfigurableFileTree)) {
// 这里的依赖是以下两种: 无需添加在 parent ,因为 jar 包直接进入 自身的 aar 中的libs 文件夹
//    implementation rootProject.files("libs/tingyun-ea-agent-android-2.15.4.jar")
//    implementation fileTree(dir: "libs", include: ["*.jar"])
} else {
    parentProject.key.dependencies.add(childConfig.name, childDepency)
}

5.3 发现 aar/jar 存在多种依赖方式

 implementation (name: 'libXXX', ext: 'aar')
 implementation files("libXXX.aar")

解决:使用第一种,第二种会合并进aar,导致类重复问题

5.4 发现 aar 新姿势依赖

configurations.maybeCreate("default")
artifacts.add("default", file('lib-xx.aar'))

上面代码把 aar 做了一个单独的 module 给到其他 module 依赖,default config 其实是 module 最终输出 aar 的持有者,default config 可以持有一个 列表的aar ,所以把 aar 手动添加到 default config,也相当于当前 module 打包出来的产物。

解决: 通过 childProject.configurations.maybeCreate("default").artifacts 找到所有添加进来的 aar ,单独发布 localmaven

   fun getAarByArtifacts(childProject: Project): MutableList<String> {
        //找到当前所有通过 artifacts.add("default", file('xxx.aar')) 依赖进来的 aar
        var listArtifact = mutableListOf<DefaultPublishArtifact>()
        var aarList = mutableListOf<String>()
        childProject.configurations.maybeCreate("default").artifacts?.forEach {
            if (it is DefaultPublishArtifact && "aar".equals(it.type)) {
                listArtifact.add(it)
            }
        }
        //拷贝一份到 localMaven
        listArtifact.forEach {
            it.file.copyTo(File(FileUtil.getLocalMavenCacheDir(), it.file.name), true)
            //剔除后缀 (.aar)
            aarList.add(removeExtension(it.file.name))
        }
        return aarList
    }

5.5 发现 android module 打包出来可以是 jar

解决:通过找到名字叫做 jar 的task,并且在 jar task 后面注入 uploadLocalMaven task,代码实现在 JarFlatLocalMaven.kt

5.6 arouter  bug

发现 arouter 有 bug,transform 没有通过 outputProvider.deleteAll() 清理旧的缓存

解决:详情查看 issue,结果arouter 问题是解决了,代码也是合并了。但并没有发布新的插件版本到 mavenCentral,于是先自行帮 arouter 解决一下。然而arouter 并没有启动 增量编译,导致 DexArchiveBuilderTask运行巨慢,也就是打 dex 包很慢,项目中我重改了 arouter 插件源码支持 TransForm 增量速度提升一倍, 具体细节就下节和 dex 速度优化一起讲。

六、下一步展望

目前初步的版本已经能够在在项目 run 起来,但是还是有很多小问题不断的冒出并解决,路漫漫其修远兮,吾将上下而求索。。

下步计划:

  • dexBuild task 优化
  • 解决各种兼容性问题 目前插件趋于稳定,喜欢尝鲜的朋友可以通过github教程接入,一起关注后期进展。

以上就是Android 性能优化实现全量编译提速的黑科技的详细内容,更多关于Android 全量编译提速的资料请关注我们其它相关文章!

(0)

相关推荐

  • Android性能优化之线程监控与线程统一详解

    目录 背景 常规解决方案 线程监控 当前线程统计 线程信息具体化 线程统一 Thread创建 注意 总结 背景 在我们日常开发中,多线程管理一直是非常头疼的问题之一,尤其在历史性长,结构复杂的app中,线程数会达到好几百个甚至更多,然而过多的线程不仅仅带来了内存上的消耗同时也降低了cpu调度的效率,过多的cpu调度带来的消耗的坏处甚至超过了多线程带来的好处. 在我们日常开发中,通常会遇到以下几个问题 某个场景会创造过多的线程,最终导致oom 线程池过多问题,比如三方库有一套线程池,自己项目也有一

  • Android性能优化之plt hook与native线程监控详解

    目录 背景 native 线程创建 PLT PLT Hook xhook bhook plt hook总结 背景 我们在android超级优化-线程监控与线程统一可以知道,我们能够通过asm插桩的方式,进行了线程的监控与线程的统一,通过一系列的黑科技,我们能够将项目中的线程控制在一个非常可观的水平,但是这个只局限在java层线程的控制,如果我们项目中存在着native库,或者存在着很多其他so库,那么native层的线程我们就没办法通过ASM或者其他字节码手段去监控了,但是并不是就没有办法,还有

  • Android性能优化之JVMTI与内存分配

    目录 前言 JVMTI JVMTI 简介: native层开启jvmti 前置准备 复写Agent 开启jvmtiCapabilities 设置jvmtiEventCallbacks 开启监听 java层开启agent 验证分配数据 总结 前言 内存治理一直是每个开发者最关心的问题,我们在日常开发中会遇到各种各样的内存问题,比如OOM,内存泄露,内存抖动等等,这些问题都有以下共性: 难发现,内存问题一般很难发现,业务开发中关系系数更少 治理困难,内存问题治理困难,比如oom,往往堆栈只是压死骆驼

  • Android性能优化之捕获java crash示例解析

    目录 背景 java层crash由来 为什么java层异常会导致crash 捕获crash 总结 背景 crash一直是影响app稳定性的大头,同时在随着项目逐渐迭代,复杂性越来越提高的同时,由于主观或者客观的的原因,都会造成意想不到的crash出现.同样的,在android的历史化过程中,就算是android系统本身,在迭代中也会存在着隐含的crash.我们常说的crash包括java层(虚拟机层)crash与native层crash,本期我们着重讲一下java层的crash. java层cr

  • Android性能优化死锁监控知识点详解

    目录 前言 死锁检测 线程Block状态 获取当前线程所请求的锁 通过锁获取当前持有的线程 线程启动 nativePeer 与 native Thread tid 与java Thread tid dlsym与调用 系统限制 死锁检测所有代码 总结 前言 “死锁”,这个从接触程序开发的时候就会经常听到的词,它其实也可以被称为一种“艺术”,即互斥资源访问循环的艺术,在Android中,如果主线程产生死锁,那么通常会以ANR结束app的生命周期,如果是两个子线程的死锁,那么就会白白浪费cpu的调度资

  • Android性能优化之RecyclerView分页加载组件功能详解

    目录 引言 1 分页加载组件 1.1 功能定制 1.2 手写分页列表 1.3 生命周期管理 2 github 引言 在Android应用中,列表有着举足轻重的地位,几乎所有的应用都有列表的身影,但是对于列表的交互体验一直是一个大问题.在性能比较好的设备上,列表滑动几乎看不出任何卡顿,但是放在低端机上,卡顿会比较明显,而且列表中经常会伴随图片的加载,卡顿会更加严重,因此本章从手写分页加载组件入手,并对列表卡顿做出对应的优化 1 分页加载组件 为什么要分页加载,通常列表数据存储在服务端会超过100条

  • Android性能优化之弱网优化详解

    目录 弱网优化 1.Serializable原理 1.1 分析过程 1.2 Serializable接口 1.3 ObjectOutputStream 1.4 序列化后二进制文件的一点解读 1.5 常见的集合类的序列化问题 1.5.1 HashMap 1.5.2 ArrayList 2.Parcelable 2.1 Parcel的简介 2.2 Parcelable的三大过程介绍(序列化.反序列化.描述) 2.2.1 描述 2.2.2 序列化 2.2.3 反序列化 2.3 Parcelable的实

  • Android性能优化系列篇UI优化

    目录 前言 一.UI优化 1.1 系统做的优化 1.1.1 硬件加速 1.2 优化方案 1.2.1 java代码布局 1.2.2 View重用 1.2.3 异步创建view 1.2.4 xml布局优化 1.2.5 异步布局框架Litho 1.2.6 屏幕适配 1.2.7 Flutter 1.2.8 Jetpack Compose 1.3 工具篇 1.3.1 Choreographer 1.3.2 LayoutInspector/Android Device Monitor 1.3.3 Systr

  • Android 性能优化实现全量编译提速的黑科技

    目录 一.背景描述 二.效果展示 2.1.测试项目介绍 三.思路问题分析与模块搭建: 3.1.思路问题分析 3.2.模块搭建 四.问题解决与实 编译流程启动,需要找到哪一个 module做了修改 module 依赖关系获取 module 依赖关系 project 替换成 aar 技术方案 hook 编译流程 五.一天一个小惊喜( bug 较多) 5.1 output 没有打包出 aar 5.2 发现运行起来后存在多个 jar 包重复问题 5.3 发现 aar/jar 存在多种依赖方式 5.4 发

  • Android性能优化方法

    GPU过度绘制 •打开开发者选型,"调试GPU过度绘制",蓝.绿.粉红.红,过度绘制依次加深  •粉红色尽量优化,界面尽量保持蓝绿颜色  •红色肯定是有问题的,不能忍受 使用HierarchyView分析布局层级 •删除多个全屏背景:应用中不可见的背景,将其删除掉  •优化ImageView:对于先绘制了一个背景,然后在其上绘制了图片的,9-patch格式的背景图中间拉伸部分设置为透明的,Android 2D渲染引擎会优化9-patch图中的透明像素.这个简单的修改可以消除头像上的过度

  • 浅谈Android性能优化之内存优化

    1.Android内存管理机制 1.1 Java内存分配模型 先上一张JVM将内存划分区域的图 程序计数器:存储当前线程执行目标方法执行到第几行. 栈内存:Java栈中存放的是一个个栈帧,每个栈帧对应一个被调用的方法.栈帧包括局部标量表, 操作数栈. 本地方法栈:本地方法栈主要是为执行本地方法服务的.而Java栈是为执行Java方法服务的. 方法区:该区域被线程共享.主要存储每个类的信息(类名,方法信息,字段信息等).静态变量,常量,以及编译器编译后的代码等. 堆:Java中的堆是被线程共享的,

  • 详解Android性能优化之启动优化

    1.为什么要进行启动优化 网上流行一种说法,就是8秒定律,意思是说,如果用户在打开一个页面,在8秒的时间内还没有打开,那么用户大概的会放弃掉,意味着一个用户的流失.从这里就可以看出,启动优化的重要性了. 2.启动的分类 2.1 冷启动 先来看看冷启动的流程图 从图中可以看出,APP启动的过程是:ActivityManagerProxy 通过IPC来调用AMS(ActivityManagerService),AMS通过IPC启动一个APP进程,ApplicationThread通过反射来创建App

  • Android性能优化全局异常处理详情

    目录 前言 1 UncaughtExceptionHandler 1.1 替代Android异常机制 1.2 可选择的异常处理 2 日志上传 2.1 日志收集 2.2 日志存储 3 策略设计模式实现上传功能 前言 异常崩溃,是Android项目中一项比较棘手的问题,即便做了很多的try - catch处理,也不能保证上线不会崩,而且一旦出现崩溃,就会出现下图的弹窗,xx应用停止运行了,这种体验对用户来说是非常差的,因此已经很明显地提示,我们做的app崩溃了. 像现在企业应用,有的在发生崩溃的时候

  • Android性能优化以及数据优化方法

    Android性能优化-布局优化 今天,继续Android性能优化 一 编码细节优化. 编码细节,对于程序的运行效率也是有很多的影响的.今天这篇主题由于技术能力有限,所以也不敢在深层去和大家分享.我将这篇主题分为以下几个小节: (1)缓存 (2)数据 (3)延迟加载和优先加载 1> 缓存 在Android中缓存可以用在很多的地方:对象.IO.网络.DB等等..对象缓存能减少内存分配,IO缓存能对磁盘的读写访问,网络缓存能减少对网络的访问,DB缓存能减少对数据库的操作. 缓存针对的场景在Andro

  • 浅谈android性能优化之启动过程(冷启动和热启动)

    本文介绍了浅谈android性能优化之启动过程(冷启动和热启动) ,分享给大家,具体如下: 一.应用的启动方式 通常来说,启动方式分为两种:冷启动和热启动. 1.冷启动:当启动应用时,后台没有该应用的进程,这时系统会重新创建一个新的进程分配给该应用,这个启动方式就是冷启动. 2.热启动:当启动应用时,后台已有该应用的进程(例:按back键.home键,应用虽然会退出,但是该应用的进程是依然会保留在后台,可进入任务列表查看),所以在已有进程的情况下,这种启动会从已有的进程中来启动应用,这个方式叫热

  • Android 性能优化系列之bitmap图片优化

    背景 Android开发中,加载图片过多.过大很容易引起OutOfMemoryError异常,即我们常见的内存溢出.因为Android对单个应用施加内存限制,默认分配的内存只有几M(具体视不同系统而定).而载入的图片如果是JPG之类的压缩格式(JPG支持最高级别的压缩,不过该压缩是有损的),在内存中展开会占用大量的内存空间,也就容易形成内存溢出.那么高效的加载Bitmap是很重要的事情.Bitmap在Android中指的是一张图片,图片的格式有.jpg .jpg .webp 等常见的格式. 如何

随机推荐