每日一问 | Java 中的 lambda 与 Android 中的 lambda 有什么不同？

像上次那样，在打印日志后，抛个异常看下堆栈信息：

public class Application extends android.app.Application {

    @Override
    public void onCreate() {
        super.onCreate();
        Runnable r = () -> {
            Log.d("Application", "hello, lambda");
            throw new RuntimeException();
        };
        r.run();
    }
}

log：

2021-01-08 12:33:11.135 18587-18587/com.wuyr.wanandroidqa D/Application: hello, lambda
2021-01-08 12:33:11.136 18587-18587/com.wuyr.wanandroidqa D/AndroidRuntime: Shutting down VM
2021-01-08 12:33:11.137 18587-18587/com.wuyr.wanandroidqa E/AndroidRuntime: FATAL EXCEPTION: main

     ......

     Caused by: java.lang.RuntimeException
        at com.wuyr.wanandroidqa.Application.lambda$onCreate$0(Application.java:17)
        at com.wuyr.wanandroidqa.-$$Lambda$Application$oUeNkShH0O2BQaqerA0o62-qsRg.run(Unknown Source:0)
        at com.wuyr.wanandroidqa.Application.onCreate(Application.java:19)
        at android.app.Instrumentation.callApplicationOnCreate(Instrumentation.java:1192)
        at android.app.ActivityThread.handleBindApplication(ActivityThread.java:6712)
        at android.app.ActivityThread.access$1300(ActivityThread.java:237) 
        at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1913) 
        at android.os.Handler.dispatchMessage(Handler.java:106) 
        at android.os.Looper.loop(Looper.java:223) 
        at android.app.ActivityThread.main(ActivityThread.java:7656) 
        at java.lang.reflect.Method.invoke(Native Method) 
        at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:592) 
        at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:947)

这次居然能直接在堆栈中看到那个自动生成的实现类！

打开编译之后的apk看下dex：

这个类直接存在dex里面了！

还可以看到Application也多了一个lambda$onCreate$0方法，看下它的smali代码：

.method static synthetic lambda$onCreate$0()V
    .registers 2

    .line 16
    const-string v0, "Application"

    const-string v1, "hello, lambda"

    invoke-static {v0, v1}, Landroid/util/Log;->d(Ljava/lang/String;Ljava/lang/String;)I

    .line 17
    new-instance v0, Ljava/lang/RuntimeException;

    invoke-direct {v0}, Ljava/lang/RuntimeException;-><init>()V

    throw v0
.end method

大致解释一下：

1. 先注册了2个寄存器；

2. 把字符串常量 "Application" 赋值给寄存器v0；

3. 把字符串常量 "hello, lambda" 赋值给寄存器v1；

4. 调用android.util.Log的静态方法d，把寄存器v0和v1的值传了进去（Log.d("Application", "hello, lambda");）；

5. 创建java.lang.RuntimeException对象实例，并赋值到寄存器v0上；

6. 调用java.lang.RuntimeException的<init>()方法（即无参构造函数），目标对象是寄存器v0储存的值；

7. 抛出异常，目标对象是寄存器v0储存的值（throw new RuntimeException();）；

有没有发现，这里跟java的做法是一样的（把lambda主体移到了一个额外生成的方法里）！

再看看onCreate方法：

# virtual methods
.method public onCreate()V
    .registers 2

    .line 14
    invoke-super {p0}, Landroid/app/Application;->onCreate()V

    .line 15
    sget-object v0, Lcom/wuyr/wanandroidqa/-$$Lambda$Application$oUeNkShH0O2BQaqerA0o62-qsRg;->INSTANCE:Lcom/wuyr/wanandroidqa/-$$Lambda$Application$oUeNkShH0O2BQaqerA0o62-qsRg;

    .line 19
    .local v0, "r":Ljava/lang/Runnable;
    invoke-interface {v0}, Ljava/lang/Runnable;->run()V

    .line 20
    return-void
.end method

第15行，获取那个自动生成的实现类的静态变量INSTANCE（类型是这个类本身，也就是说，INSTANCE是【自动生成的实现类】的实例），并赋值到寄存器v0上；

19行，声明局部变量 "r"，类型是java.lang.Runnable，初始值是寄存器v0的值；然后调用java.lang.Runnable接口方法run，目标对象是寄存器v0储存的值。

它这里把原来的【创建对象实例】改成了【获取静态字段】。其实这只是一个优化，因为lambda函数体没有依赖CallerClass的变量或方法，完全可以作为一个静态变量存在，这样能避免反复创建对象，但如果有使用到依赖CallerClass里的东西，还是会变成new-instance指令的。

好，来看下那个实现类的smali：

# direct methods
.method static synthetic constructor <clinit>()V
    .registers 1

    new-instance v0, Lcom/wuyr/wanandroidqa/-$$Lambda$Application$oUeNkShH0O2BQaqerA0o62-qsRg;

    invoke-direct {v0}, Lcom/wuyr/wanandroidqa/-$$Lambda$Application$oUeNkShH0O2BQaqerA0o62-qsRg;-><init>()V

    sput-object v0, Lcom/wuyr/wanandroidqa/-$$Lambda$Application$oUeNkShH0O2BQaqerA0o62-qsRg;->INSTANCE:Lcom/wuyr/wanandroidqa/-$$Lambda$Application$oUeNkShH0O2BQaqerA0o62-qsRg;

    return-void
.end method

......

# virtual methods
.method public final run()V
    .registers 1

    invoke-static {}, Lcom/wuyr/wanandroidqa/Application;->lambda$onCreate$0()V

    return-void
.end method

在类被加载的时候，就创建了它自己的对象实例，并赋值给静态字段INSTANCE；

实现的run方法，里面也是直接调用Application的静态方法lambda$onCreate$0（跟java的做法一样）。

嗯，那就是说：

Java的lambda，在编译成dex时会直接生成对应的实现类，相比于Java本身的做法，不同的只是【生成实现类】的时机。但这已经跟直接使用【匿名内部类】的效果无区别了（忽略那个静态实例的优化）。

至于第三问，transformClassesWithDesugarForDebug这个任务是做什么的？

刚开始的时候，我翻遍了gradle的源码也没找到这个Task。。。后来才发现，是版本原因，grep了一下项目目录，发现只有几个gradle版本比较旧的项目里才有这样的字眼：

逐个查看了下版本，发现这几个都是3.1.4：

而我当前的版本是4.0.1，在4.0.1上，已经没有了transformClassesWithDesugarForDebug这个Task了，取而代之的是desugarDebug(Release)FileDependencies和dexBuilderDebug(Release)，前者是把项目依赖的所有jar包脱糖，后者是将项目自己的class脱糖。这两个Task都会调用到D8DexArchiveBuilder的convert方法，在这里会借助com.android.tools.r8.D8（暂时看不到源码）这个类去完成！

注意！其实lambda在编译成class时，还是会按Java原本的方式（即invokedynamic）处理的。

打开app/build/intermediates/javac/debug/classes/ 目录：

可以看到这时候还没有生成内部类，javap看一下：

没错吧，还是跟上一问的字节码一样。

我去看戏了！！！想知道我是怎么知道D8DexArchiveBuilder这些的同学，留言，我周末补充下，关机！！

我是怎么发现D8DexArchiveBuilder这些类的呢？

其实找到这些类并不是最终目的，我们这一次主要是想弄清楚在build过程中那些class何时desugar，何时转成dex。

新建一个项目，看下你的gradle版本是多少：

接着打开你的gradle目录/caches/modules-2/files-2.1/com.android.tools.build/gradle/对应的gradle版本号/ 这个目录，把带有sources字眼的那个jar解压出来。

然后搜一下关键字 "desugar" ：

grep -rni desugar：

会看到有几个出现频率比较高的文件：

先看第一个吧，在刚刚新建的项目中创建一个library（为了等下不会因编译错误而中断debug），然后library中添加你项目对应gradle版本的依赖，比如我的：

implementation "com.android.tools.build:gradle:4.1.2"

sync之后就能通过全局搜(CTRL + SHIFT + F)定位到DexArchiveBuilderTask这个类了：

可以看到它是一个NewIncrementalTask，在它的doTaskAction方法里打个断点，我们试试等下会不会执行到这里。

debug之前，先在app module那边加上lambda代码：

好，在gradle窗口那边，开启debug（注意运行的Task是app下的build，不是project的build，因为后者会把刚刚添加了gradle依赖的library也一起编译，导致编译失败的）：

（Android Studio4.0以上能直接这样debug了，不再需要创建Remote Configuration）

果然执行到了！这个Task的名字就叫dexBuilderDebug ！

那个inputChanges参数，里面有个Map，记录的都是些class和jar的路径：

它下一步是创建了DexArchiveBuilderTaskDelegate对象，并调用它的doProcess方法：

abstract class DexArchiveBuilderTask : NewIncrementalTask() {
    override fun doTaskAction(inputChanges: InputChanges) {
        ......

        DexArchiveBuilderTaskDelegate(...).doProcess()

        ......
    }
}

到了DexArchiveBuilderTaskDelegate这边，会看到一个叫projectClasses的Set：

里面有三个路径，分别是R.jar、编译后的java文件路径、编译后的kt文件路径。

打开编译后的java文件路径，发现MainActivity和自动生成的BuildConfig已经在里面了（现在没有kotlin类，所以kotlin-classes那边是空的）。

如果现在用javap去查看MainActivity的字节码，会看到lambda还没有脱糖的，里面还是使用的invokedynamic指令，就像先前的回答里说的那样。

好，接着往下看：

class DexArchiveBuilderTaskDelegate(...){

    fun doProcess() {
        try {
            Closer.create().use { closer ->

                ......

                val processInputType = { ... ->

                    processClassFromInput(...)

                }

                processInputType(...) //currentProject

                processInputType(...) //otherProjects

                processInputType(...) //mixedScopes

                processInputType(...) //externalLibs

                ......
            }
        } catch (e: Exception) {
            ......
        }
    }

    private fun processClassFromInput(...){
        ......
    }
}

它创建了一个lambda，分4次调用，lambda里面又调用了processClassFromInput方法，跟进去：

在这里把刚刚那三个路径分了类：class文件路径和jar包路径。

如果class文件路径不为空的话（现在肯定不为空了），就会进入到convertToDexArchive方法：

主要看最后的if，那个workerExecutor应该是一个线程池的包装类（虽然看不到源码），在调用它的submit方法时，把一个叫DexWorkAction的类传了进去：

这个DexWorkAction刚好实现了Runnable，run方法里面只调用了launchProcessing方法，在这里打个断点，看看等下会不会执行到这里。

真的执行到了！

那就接着往下看launchProcessing：

注意这里有调用一个叫getDexArchiveBuilder的方法：

private fun getDexArchiveBuilder(...): DexArchiveBuilder {

    val dexArchiveBuilder: DexArchiveBuilder

    with(dexWorkActionParams) {
        when (dexer) {
            DexerTool.DX -> dexArchiveBuilder = DexArchiveBuilder.createDxDexBuilder(config)

            DexerTool.D8 -> dexArchiveBuilder = DexArchiveBuilder.createD8DexBuilder(...)

            else -> throw AssertionError("Unknown dexer type: " + dexer.name)
        }
    }
    return dexArchiveBuilder
}

咦？！在getDexArchiveBuilder方法里，会根据dexer来判断返回是返回 DxDexBuilder还是 D8DexBuilder ！

点开DexArchiveBuilder，会看到它有2个实现类：

这就刚好对应得上getDexArchiveBuilder的两个类型。

好，回到刚刚的launchProcessing方法，继续F8下去，发现它走了else那边，也就是调用了processNonIncrementally方法：

private fun processNonIncrementally(...) {
    ......

        process(...)

    ......
}

主要看process方法：

DexArchiveBuilder的convert方法会在这里面调用，看下面Variables窗口，现在DexArchiveBuilder的实例是D8DexArchiveBuilder。

F7跟进去：

final class D8DexArchiveBuilder extends DexArchiveBuilder {
    @Override
    public void convert(...)
            throws DexArchiveBuilderException {
        D8DiagnosticsHandler d8DiagnosticsHandler = new InterceptingDiagnosticsHandler();
        try {

            D8Command.Builder builder = D8Command.builder(d8DiagnosticsHandler);
            ......
            D8.run(builder.build(), MoreExecutors.newDirectExecutorService());

        } catch (Throwable e) {
            throw getExceptionToRethrow(e, d8DiagnosticsHandler);
        }
    }
}

emmmm，在这里初始化了D8的命令参数之后，就直接调用了D8类的静态方法run，但是想直接看run方法里面的源码是看不到的：

不过现在也能断定它是运行SDK/build-tools目录下的d8工具了，class文件的脱糖，都会由d8去处理。

而调用d8工具的Task，就是开头所看到的dexBuilder(Debug/Release)。

还没完，继续：

可以看到entryCount的值为2，估计就是刚刚在app/build/intermediates/javac/debug/classes目录下的2个class文件（BuildConfig和MainActivity）；

再看它的output目录为app/build/intermediates/project_dex_archive/debug/out，打开它：

嗯，现在是空的，回到AS中，F9，刷新一下：

有了！看下它里面的文件：

！！！BuildConfig和MainActivity已经从.class变成了.dex！

慢着！把MainActivity.dex拖进AS里面看看：

看到了没？！现在lambda已经变成了内部类了！

冲凉睡觉

1. 首先从class层面分析 两者是一样的
2. Android 的更像是语法糖，因为语法糖的定义正常是需要有脱糖器的，但是java1.8后的lambda已经不是糖了，而是一种相对标准动态调用

3. 脱糖器 d8 流程的一部分

   我刚刚完成的 lambda 的插装https://github.com/Leifzhang/AndroidAutoTrack

   我的博客也对这部分做了一个详细的解释了

   https://juejin.cn/post/6918733287015841800/

先简单回答下，java会用invokeDynmic来处理lambda，而在Android上仅仅是个存语法糖了，transformClassesWithDesugarForDebug会将lambda翻译成匿名内部类