这一次，她带着所有的勇敢与温柔，历经辛苦，把我们的孩子带到人间。

思而后越，行稳致远；

越而有勇，蓄力而发。

故名思越。

一念思吴越，一念念长久。

生逢四月九，恰应九郎缘。

从此，我们仨。

致我最温柔最勇敢的老婆。

欢迎你，小九。

疫情至今已经肆虐了 3 年，互联网也变得比以往任何时候更加寒冷，即使这样，我都忍不住想问自己一句：今年有没有可能是往后 10 年最好的一年？！

第一次给爹猪过了一个充满仪式感的生日

说道这个真的非常惭愧，这么多年都没有给我的爹猪过个充满仪式感的生日，还是我的大猪儿细心周到，给我爹猪过了一次难忘的生日。

我和大猪给爹猪选的生日蛋糕：

我、大猪、我妈给爹猪庆祝：

No Game No Life

感谢 steam，真细心，还帮我总结了一下

已经不记得是啥时候跟风买的「奥日与黑暗森林」了，对奥日的印象还停留在独立游戏、画面精美、动作&场景设计一流上，然后就是玩了几个小时，就没有然后了。后来，有阵子静下心来细细再体验了一段时间，才发现这简直是一款称得上是艺术品的游戏，深陷其中不可自拔，仿佛自己就是那个飞天遁地的奥日精灵。

但，故事总有完结的时候。火，也总需要有人传下去。

4.24，全收集、100% 全支线通关了。

和猪儿相识一周年纪念日

每次看到这张图，再看看已经成为我老婆的猪儿，不得不感慨，时间真是过得好快啊。

工作

王鹏老师馈赠

也是造化弄人，当年在抖音的时候，都没咋接触过大佬。反而是，出来之后，和大佬的接触才多了起来。

线上参加 I/O Extended 杭州 Android 专场活动，认识了前同事王鹏老师，顺便白嫖了一本鹏佬的新书，嘿嘿。

在著名公众号 kotlin 出道（bushi

放弃 KotlinPoet 基于模版引擎生成 Dependency 的 Gradle Plugin。

几年前开始关注霍老师的 kotlin 微信公众号，当时，还误以为是 jetbrain 官方的公众号呢。发现公众号里的内容质量不错之后，反手又是一波关注了霍老师的 B站账号，简直就是打开了新天地，没想到霍佬是真的就六边形战士。

Booster

• https://github.com/didi/booster/issues/368
• https://github.com/didi/booster/issues/387

我和大猪结婚了

11.11，和猪儿一起去民政局登记领证。刚进门的时候保安出于抗疫政策的大义坚决不让我们的随行跟拍——我爹猪进来，哎，真是闹心。
好在领证过程非常顺利，不得不感慨一下，现在领证的效率在数字化信息时代是真的高效得离谱，差不多 100% 自助那种，旁边有个工作人员稍微辅助下就完事了。
但，如果还是想要一些结婚的仪式感，也不是不可以。工作人员会把我们领到一个小房间，过一下结婚的流程，然后顺便帮我们拍一下照+视频，
有点可惜的是，持相机的工作人员对焦一直没对好，就有点遗憾。

对我俩来说，毕竟是个大日子，今天总得发点什么吧。看了许多小红书的文案，还是觉得差那么点意思，这时候，突然想到了要不问问过去的自己吧，于是，便有了以下的朋友圈文案。

谢谢，6 年前那个孤独的、不安的，期盼爱情与另一半的我。

照相

不得不说，在大猪的严厉教导下，我对光与影的掌握逐渐开始熟练。以下请欣赏由我这名绝地学徒带来的作品——「大猪与小猪」：

写在最后

苦难与惊喜的一年！

记得那只猩猩问屏幕前的我来不来的时候，我选择了加入，于是 15 年的那个夏天，一下班就跑去网吧开机。没办法鸭，那时候穷，根本组不起一台可以畅玩守望先锋的设备，那时候公司给实习生福利的那个小出租屋真的是又破又小，刚好能容纳下一张床板和柜子。当时经常光顾的那家网咖，用的还是 iMac，性能也就刚刚好满足中画质 60 帧。后来，进入第一家公司正式工作之后，在川神和熊桑的诱惑下，我分期买了人生中第一台 itx 主机…

第一台 itx 主机

当时这台主机是某宝买的，第一眼看到这个造型就觉得是它了，但现在回过头来看里面的配置清单，就觉得，当时硬件小白的自己真傻，居然做了整机烈士，被奸商狠宰了一波鸭。而且，最重要的是，这根本没有 itx 的灵魂!

• 非模块化的电源
• 几倍正常 itx 机箱的体积
• 140 的信仰水冷，还美其名曰自主研发，醉了
• 可怜到容量只有 256G 的 SSD
• …

虽然吐槽了这么多，也正是因为第一次接触了 itx 这个垂直细分领域，我打开了新世界的大门，从此在 itx 的攒机路上一发不可收拾，哈哈！

ITX 攒机之旅

涅槃重生

因为第一台 itx 主机实在太过于庞大，不够便携（指搬家），于是，我在保留了一部分硬件（指 CPU）的前提下，又买了一些新的硬件，将整个主机翻新了一下：

总计：9887￥，重点强调一下这个机箱，碳纤维材质的，非常便携，质量只有500g左右，体积5.57L！

办公

这台主机，和上面那台的思路差不多，将之前在淘宝买的一台工作用的主机 itx 化了，保留了 CPU、内存，其他的都升级了一下：

总计：10121￥，机箱是淘宝的孙总定制款机箱，比 5.57L 的那台大了不少，不过也还行 10L 体积，关键之颜值高鸭！

写在最后

嗯，这这篇文章就是想告诉各位对 itx 攒机感兴趣的盆友，itx 的乐趣在于尽可能地利用有限的空间来发挥压榨机器最大的性能，在自己的腰包承受范围内，选择最好的硬件，然后开动自己的双手和大脑，克服一个又一个装机时的麻烦问题，攒出自己觉得最棒的 itx 主机哈哈！

兄dei，Gradle 生命周期有了解过嘛？
emmmmmm….
那么，来说说 Configuration 阶段 Gradle 干了什么吧
emmmmmm….

Gradle 生命周期

Gradle 在编译项目时有着它自己的生命周期，从编译开始编译完毕 Gradle 一共要经历 3 个阶段：

• Initialization

初始化阶段，即执行 Gradle 的初始化配置选项，即执行项目中的 settings.gradle 脚本。

• Configuration

解析每个 Project 中的 build.gradle 脚本，即解析所有 Project 中的编译选项。解析完成后，Gradle 就生成了一张有向关系图——taskgraph，这面包含了整个 Task 的依赖关系。

• Build

该阶段是最后的编译运行阶段，即按照 taskgraph 执行编译。

这三个阶段是宏观把握 Gradle 的核心所在，运行任何 Gradle 指令都会经过这样三个阶段。

默认的输出是在配置阶段，这时候 Gradle 会执行所有 Task 的配置脚本，即使你执行一个指定的 Task，也有到 Build 阶段，才能够开始执行。

Gradle 生命周期的监听

Gradle 耗时 Task 统计

统计 Task 耗时，收集耗时超过100ms 的 Task，排序之后输出到 build 目录下的xxx.txt 文件中。

实现

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76

/**
 * 分析 Task，收集耗时超过 100ms 的task，并将日志输出到 build 文件夹下
 */
fun Gradle.analyzeTask() {

    val clock = Clock()

    val execution = mutableListOf<TaskInfo>()

    addTaskExecutionLifecycle {
        _beforeExecute { task ->
            task.extensions.add("startAt", System.currentTimeMillis())
        }
        _afterExecute { task, _ ->
            // 计算 Task 的执行时间
            val duration = System.currentTimeMillis() - (task.extensions["startAt"] as Long)
            // 收集超过耗时超过 100ms 的 Task
            if (duration >= 100) {
                execution += TaskInfo(task, duration)
            }
        }
    }

    addBuildLifecycle {
        _buildFinished {

            // 没有超过 100ms 的 Task，忽略
            if (execution.isEmpty())
                return@_buildFinished

            // 按照耗时排序
            execution.sortBy { taskInfo ->
                taskInfo.duration
            }

            // 输出内容
            val outputStr = buildString {

                // 构建总耗时
                val buildTimeInSeconds = clock.timesInMs / 1000
                val minutes = buildTimeInSeconds / 60
                val seconds = buildTimeInSeconds % 60

                // 构建字符串模板
                val timeStr = when (minutes) {
                    0L ->
                        "${seconds}s"
                    else ->
                        "${minutes}m ${seconds}s (${buildTimeInSeconds}s)"
                }

                // 文本头
                append("Build finished in ${timeStr}\n")

                // 添加耗时超过 100ms 的 Task
                execution.forEach { taskInfo ->
                    append(
                        String.format(
                            "%7sms %s\n",
                            taskInfo.duration,
                            taskInfo.task.path
                        )
                    )
                }
            }

            // 创建文件，并将内容写入
            val file = File(
                gradle.rootProject.buildDir.absolutePath,
                "build_time_records_${Date().format("yyyy-MM-dd-HH-mm-ss")}.txt"
            )
            file.parentFile.mkdirs()
            file.write(outputStr)
        }
    }
}

1. 监听 TaskExecutionListener 的 beforeExecute 和 afterExecute，计算每一个 Task 的耗时，并且将耗时大于 100ms 的 Task 收集到 execution 中
2. 监听 BuildListener 的 buildFinished， build 结束之后将 execution 排序，并且计算总耗时
3. 最后，将信息写入到 build 目录下的 xxx.txt 文件

PS:这里使用 kotlin 带接收器的扩展函数特性对 addListener 做了简化，让代码看起来更 DSL 一些

参考

• Android 群英传 神兵利器
  • 4.8章，Gradle 思考
• Blankj Auc 中统计 Task 耗时的代码

从刚接触 Android 的时候有一些业务场景真的让人蛋疼，虽说不是无解，但问题是解决了，但看着这堆代码总觉得哪里怪怪的。

那么，是什么问题呢？

State Management

React 的理念里有这么一个公式：

UI = render(data)

UI 即用户看到的界面，是一个 render（函数）的执行结果，只接受 data（数据）作为参数。这个函数是一个纯函数，所谓纯函数，指的是没有任何副作用，输出完全依赖于输入的函数，两次函数调用，如果输入相同，得到的结果也绝对相同。如此一来，最终的用户界面，在 render 函数确定的情况下完全取决于输入数据。

对于开发者来说，重要的是区分开哪些属于 data，哪些属于 render，想要更新用户界面，要做的就是更新 data，用户界面自然会做出响应，所以 React 实践的也是“响应式编程”（Reactive Programming）的思想。

React 的 state

驱动组件渲染过程的除了 prop，还有 state， state 代表组件的内部状态。由于 React 组件不能修改传入的 prop，所以需要记录自身数据变化，就要使用 state。

状态分类

状态分 2 种：

• 局部状态：这种由 Component 管理，比如：
  • Progressbar 的当前进度
  • TabIndicator 的当前选中 tab

这种状态不需要使用复杂的状态管理方案，靠 Component 维护就好了。

• 全局状态：需要在2个及以上的地方共享的状态。比如：
  • 用户信息
  • 用户设置
  • 购物车
  • …

而这些状态的划分，emmm，没有一个清晰的界限，主要还是靠程序员的经验。但是，单靠 Component 的 setState() 来管理所有的状态是有极限的！

上述的状态管理方案，对前端童鞋来说已经 8 是问题了，并且还给出了许多优秀的开源框架：

• redux
• mobx
• vuex
• …

Android 的状态管理方案

严格来说，从事 Android 开发的童鞋似乎很少在官方文档或者社区上看到State Management相关的介绍，实践就更少了，首先，Android 是命令式的（imperative），通过 setText() 类似的命令式 API 来改变 UI，所以大部分 Android 看到上述 UI = render(data) 这样的公式，都会有点摸不着头脑。然后，在那个还没有 Kotlin 的年代，Android 的主流开发语言是 Java，大家最熟悉的就是 OOP 编程， 什么函数式编程，什么纯函数啊，不可变特性啊。。。天顶星人科技？最后的结果就是，大家在这方面思考的少，而现有的系统API、第三方库甚至自己稍微捣鼓捣鼓，也能解决，所以，Android 的 UI 开发体验一直都不如前端。而我本人，也在近些年的工作学习中不断质疑（接触了前端之后），为毛 Android 这些业务代码写起来就是没有前端的香呢？

虽然 Android 上没有状态管理，但是有类似的东东！

组件间通信

Android 采取的思路是基于模块化的分冶思路，即 App 只是一个壳，按照业务划分为多个子模块，业务与业务之间隔离。在组件化的工程中，由于我们的业务模块间是物理隔离（模块间无法在编译期间访问各自的代码）的，模块间想获取不属于自己的数据（状态）时就会有问题，例如：

• 模块A里的某个 Activity/Fragment 想获取到模块B购物车的信息
• 模块C里的某个 Activity 想跳转到模块A的某个 Activity
• 模块D里的某个 Activity 想调用模块E里的某个方法
• 。。。

Android 里面对的和”状态管理“类似的往往是这些问题。

路由库

下面以阿里的 ARouter 为🌰具体进行说明是如何解决组件间通信的问题：

发起路由请求

1
2
3
4
5
6

// 跳转并携带参数
ARouter.getInstance().build("/test/1")
            .withLong("key1", 666L)
            .withString("key3", "888")
            .withObject("key4", new Test("Jack", "Rose"))
            .navigation();

通过服务注册&发现

1. 通过依赖注入解耦:服务管理(一) 暴露服务

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

// 声明接口,其他组件通过接口来调用服务
public interface HelloService extends IProvider {
    String sayHello(String name);
}

// 实现接口
@Route(path = "/yourservicegroupname/hello", name = "测试服务")
public class HelloServiceImpl implements HelloService {

    @Override
    public String sayHello(String name) {
    return "hello, " + name;
    }

    @Override
    public void init(Context context) {

    }
}

2. 通过依赖注入解耦：服务管理(二) 发现服务

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

public class Test {
    @Autowired
    HelloService helloService;

    @Autowired(name = "/yourservicegroupname/hello")
    HelloService helloService2;

    HelloService helloService3;

    HelloService helloService4;

    public Test() {
    ARouter.getInstance().inject(this);
    }

    public void testService() {
    // 1. (推荐)使用依赖注入的方式发现服务,通过注解标注字段,即可使用，无需主动获取
    // Autowired注解中标注name之后，将会使用byName的方式注入对应的字段，不设置name属性，会默认使用byType的方式发现服务(当同一接口有多个实现的时候，必须使用byName的方式发现服务)
    helloService.sayHello("Vergil");
    helloService2.sayHello("Vergil");

    // 2. 使用依赖查找的方式发现服务，主动去发现服务并使用，下面两种方式分别是byName和byType
    helloService3 = ARouter.getInstance().navigation(HelloService.class);
    helloService4 = (HelloService) ARouter.getInstance().build("/yourservicegroupname/hello").navigation();
    helloService3.sayHello("Vergil");
    helloService4.sayHello("Vergil");
    }
}

事件总线

以 EventBus 为代表的事件总线库，简化了使用原生通信的复杂度：

• startActivityForResult & onActivityResult
• Broadcast
• LocalBroadcast
• …

也看似让我们的代码得到解耦？但是，使用不当的同时也为项目埋下了一颗定时💣。

Android 端 redux 实现

Android 组件间通信的方案给人的感觉更偏向通信而没有前端状态管理的那个味儿。那，能不能。。。

能！

受到 redux 这个项目的启发，我用 kotlin&rxjava 也实现了一个 redux，也可以认为和 Android 平台无关的 redux（没有用到 Android 的类），当然之后也可以像 flutter_redux 一样，包一层 Android 相关的类，实现一个 Android 平台的 redux。

原理简述

首先非常感谢 kotlin 和 rxjava，kotlin 和 dart 还是蛮相近的，看下 dart 版的 redux 大概就能想出如果用 kotlin 咋实现的，而对着 JavaScript 写有时候就会😳。而 rxjava 基本可以等价于 flutter stream api，所以，实现一个 kt 版的 redux，难度系数大大降低！

1. 定义函数

1
2
3
4
5
6

// store.kt
typealias Middleware<State> = (store: IStore<State>, action: Any, next: NextDispatcher) -> Any

typealias NextDispatcher = (action: Any) -> Any

typealias Reducer<State> = (state: State, action: Any) -> State

2. 定义 Store 接口

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

// store.kt
interface IStore<State> {

    var _state: State

    var reducer: Reducer<State>

    var middleware: List<Middleware<State>>

    var changeController: Subject<State>

    val state: State

    val onChange: Observable<State>

    fun dispatch(action: Any)
}

注意这几点：

• changeController 使用 Subject 类型
• onChange 使用 Observeable 类型，其实这里我犯了个错，最早的版本用的 aac 里的 LiveData，因为之前一直以为 LiveData≈Subject 。但后来看到了把 LiveData 用于事件传递那些坑，结合源码后，我意识到，出事了，这个场景下 LiveData 是不适用的，它会丢失事件，它就不是被设计出来干这件事的！

3. Store 实现

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66

// store.kt
class Store<State> private constructor(
    override var _state: State,
    override var reducer: Reducer<State>,
    override var middleware: List<Middleware<State>>,
    override var changeController: Subject<State>
) : IStore<State> {

    override val state: State
        get() = _state

    override val onChange: Observable<State>
        get() = changeController

    private var dispatchers: List<NextDispatcher> = createDispatchers(
        middleware, createReduceAndNotify()
    )

    override fun dispatch(action: Any) {
        dispatchers[0](action)
    }

    private fun createDispatchers(
        middleware: List<Middleware<State>>,
        reduceAndNotify: NextDispatcher
    ): List<NextDispatcher> {

        val dispatchers = mutableListOf(reduceAndNotify)

        middleware.reversed()
            .map { nextMiddleware: Middleware<State> ->
                val next = dispatchers.last()
                dispatchers += { action: Any ->
                    nextMiddleware.invoke(
                        this,
                        action,
                        next
                    )
                }
            }

        return dispatchers.reversed()
    }

    private fun createReduceAndNotify(): NextDispatcher {
        return { action: Any ->
            val state = reducer.invoke(_state, action)
            _state = state
            changeController.onNext(state)
        }
    }

    companion object {
        fun <State> create(
            initialState: State,
            reducer: Reducer<State>,
            middleware: List<Middleware<State>> = emptyList(),
            changeController: Subject<State> = PublishSubject.create()
        ): IStore<State> = Store(
            _state = initialState,
            reducer = reducer,
            middleware = middleware,
            changeController = changeController
        )
    }
}

得益于 Kotlin 的函数式特性，这段实现和原版的 dart 相比也没有啰嗦多少😀。这里将 Store 设计为一个不可继承的 class，并且将构造函数的车门也焊死了，创建这个 Store 实例的方法只有 Store#create 函数，通过命名参数，使用者能很清晰的知道传些啥值，不过还是要介绍下 reducer 这个参数。

reducer:List 合并成的一个 Reducer 对象，这里参考了 JavaScript版 redux 的 combine 函数，贴下代码：

1
2
3
4
5
6
7
8

// reducer.kt
fun <State> combineReducers(reducers: List<Reducer<State>>): Reducer<State> {
    return { state: State, action: Any ->
        reducers.fold(initial = state) { acc: State, func: Reducer<State> ->
            return@fold func(acc, action)
        }
    }
}

Demo

有空再补，算了，还是先补上一些吧。

AppStore

创建一个单例 Store（因为该 Store 里的状态是全局的），配置好对应的参数：

• reducer，之前介绍过，略
• middleware，中间件，这里只添加了一个日志中间件

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

// AppStore.kt
private fun createStore(): IStore<AppState> = Store.create(
    initialState = AppState(),
    reducer = combineReducers(listOf(countReducer)),
    middleware = listOf(loggerMiddleware)
)

class AppStore private constructor(
    store: IStore<AppState> = createStore()
) : IStore<AppState> by store {

    companion object {
        val INSTANCE: AppStore by lazy { AppStore() }
    }
}

参考

• redux
• flutter_redux
• 把 LiveData 用于事件传递那些坑
• 为了弄懂Flutter的状态管理, 我用10种方法改造了counter app
• 深入浅出 React 和 Redux

有效的括号

String#isValid

定义扩展属性 String#isValid:

1
2
3
4
5
6
7
8

@Test
fun isValid() {
    assert("()".isValid)
    assert("()[]{}".isValid)
    assert(!"(]".isValid)
    assert(!"([)]".isValid)
    assert("{[]}".isValid)
}

单元测试

1
2
3
4
5

class Solution {
    fun isValid(s: String): Boolean {
        return s.isValid
    }
}

解法

辅助栈法

这个方法大二的时候数据结构课老师上课有讲过，解这道题非常好用的。

• 初始化辅助站 helper
• 依次处理表达式的每个括号
• 如果遇到开括号，入栈
• 如果遇到的是闭括号，出栈
• 如果辅助栈不为空，则意味表达式无效

代码：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

/**
 * 字符串是否有效
 */
private val String.isValid: Boolean
    get() {

        val helper = Stack<Char>()

        forEach { letter ->
            when {
                letter == '(' ->
                    helper.push(')')
                letter == '[' ->
                    helper.push(']')
                letter == '{' ->
                    helper.push('}')
                helper.isEmpty() || letter != helper.pop() ->
                    return false
            }
        }

        return helper.isEmpty()
    }

最长公共前缀#14

Array#findLongestCommonPrefix

定义扩展方法Array<String>#findLongestCommonPrefix:

1
2
3

fun findLongestCommonPrefix(): String{
    // 具体实现
}

单元测试

1
2
3
4

@Test
fun longestCommonPrefix() {
    assert(arrayOf("flower", "flow", "flight").findLongestCommonPrefix() == "fl")
}

解法

• 当字符串数组为空时，直接返回 “”
• 令公共字符串前缀 prefix 为 first()
• 遍历从 1 到 count() 的字符串 cur，然后找出 cur 与 prefix 公共前缀，最终结果即为最长公共前缀
• 如果查找过程中 prefix 为空，则不存在公共前缀，直接返回 “”
• 时间复杂度：O(s)，s 为所有字符串长度之和

代码：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

/**
 * 找出最长公共前缀
 */
fun Array<String>.findLongestCommonPrefix(): String {

    if (isEmpty())
        return ""

    var prefix: String = first()

    for (index in 1 until count()) {

        val cur = get(index)

        while (cur.indexOf(prefix) == -1) {

            prefix = prefix.substring(0, prefix.count() - 1)

            if (prefix.isEmpty())
                return ""
        }
    }

    return prefix
}

参考

• 精选题解

罗马数字转整数#13

String#roman2Int

给 String 定义一个私有的扩展方法 roman2Int：

1
2
3

private fun String.roman2Int():Int{
    // 具体实现
}

单元测试

1
2
3
4
5
6
7
8

@Test
fun romanToInt() {
    assert("III".roman2Int() == 3)
    assert("IV".roman2Int() == 4)
    assert("IX".roman2Int() == 9)
    assert("LVIII".roman2Int() == 58)
    assert("MCMXCIV".roman2Int() == 1994)
}

解法

由题目可以得出：

• 罗马数字由 I、V、X、L、C、D、M 构成
• 当小值在大值得左边，则减小值
• 当小值在大值的右边，则加小值

由以上结论可以得出，右值永远为正，最后一位必为正

码表：

代码实现小技巧，从第1位开始遍历，比较 cur 和 pre 的大小，从而确定是做加法还是减法，然后更新 pre 的值。只有最后一位时，做加法。

代码如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

/**
 * 罗马数转换为十进制
 */
private fun String.roman2Int(): Int {

    val dictionary = hashMapOf(
        'I' to 1,
        'V' to 5,
        'X' to 10,
        'L' to 50,
        'C' to 100,
        'D' to 500,
        'M' to 1000
    )

    var sum = 0

    var prev: Int = dictionary[first()] ?: throw IllegalStateException()

    for (index in 1 until length) {

        val cur = dictionary[get(index)] ?: throw IllegalStateException()

        when {
            cur > prev ->
                sum -= prev
            else ->
                sum += prev
        }

        prev = cur
    }

    sum += prev
    return sum
}

参考

• 题解精选

回文数#2

Int#isPalindrome

给 Int 定义一个私有的扩展方法 isPalindrome:

1
2
3
4

// Solution9.kt
private fun Int.isPalindrome1(): Boolean {
    // 具体实现
}

单元测试

1
2
3
4
5
6

@Test
fun test() {
    assert(1234321.isPalindrome1())
    assert(!(-121).isPalindrome2())
    assert(!10.isPalindrome3())
}

解法

暴力解法

通过 kotlin 提供的 api，我们可以这样：

1
2
3
4
5

private fun Int.isPalindrome3(): Boolean {
       return toString().let {
           it == it.reversed()
       }
   }

解法2

通过取整和取余操作获取整数对应的数字逐一进行比较。

举🌰，1221：

• 1221 / 1000，得到首位 1
• 1221 % 10，得到末尾 1
• 首位和末尾比较
• 再将 22 取出来继续上述操作

动画：

代码：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

/**
 * 解法 1
 */
private fun Int.isPalindrome1(): Boolean {

    if (this < 0)
        return false

    var num = this
    var div = 1

    while (num / div >= 10)
        div *= 10

    while (num > 0) {

        val left = num / div
        val right = num % 10

        if (left != right)
            return false

        num = (num % div) / 10
        div /= 100
    }

    return true
}

解法2的进阶版——解法3

回文数，将数字对折后看能否一一对应。

所以这个解法的操作就是取出后半段数字进行翻转

注意，回文数的位数存在奇数和偶数的情况：

• 如果长度为偶数，对折过来应该是相等的
• 如果长度为奇数，对折过来后，长的需要去掉一位数（除以 10 并取整）

具体做法如下：

• 每次进行取余操作（%10），取出最低位：y = x % 10
• 将最低位数字加到取出数的末尾：revertNum = revertNum * 10 + y
• 每取一个最低位数字，x 都要除以 10
• 判断 x 是不是小于 revertNum，如果小于，则说明数字已经对半或者过半了
• 最后，判断奇偶情况：如果是偶数，revertNum 和 x 相等；否则，最中间的数字就在 revertNum 的最低位上，将它除以 10 后应该和 x 相等

代码

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

/**
 * 解法2
 */
private fun Int.isPalindrome2(): Boolean {

    if ((this < 0) || (this != 0 && this % 10 == 0))
        return false

    var num = this
    var revertedNum = 0

    while (num > revertedNum) {
        revertedNum = revertedNum * 10 + num % 10
        num /= 10
    }

    return num == revertedNum || num == revertedNum / 10
}

参考

• 精选题解

整数反转#7

Int#reverse

给Int定义一个私有的扩展方法reverse：

1
2
3
4

// Solution7.kt
private fun Int.reverse(): Int {
    // 具体实现
}

单元测试

1
2
3
4
5
6
7
8
9
10

// Soulution7.kt
@Test
fun reverse() {
    // "123" 反转之后为 "321"
    assert(123.reverse() == 321)
    // "-123" 反转之后为 "-321"
    assert((-123).reverse() == -321)
    // "120" 反转之后为 "21"
    assert((120).reverse() == 21)
}

解法

反转整数可以与反转字符串进行类比。

我们想重复弹出num的最后一位数字，并将它推入到result的后面。最后，result与num相反。

要在没有辅助堆栈/数组的帮助下弹出和推入数字，我们可以使用数学方法。

数学方法

1
2
3
4
5
6
7

// pop
pop = num % 10
num /= 10

// push
temp = result * 10 + pop
result = temp

但是，这种方法很危险，因为当temp = result*10 + pop时会导致溢出。

假设result是正整数：

• 如果temp = result*10 + pop导致溢出，那么result >= Int.MAX_VALUE/10
• 如果result > Int.MAX_VALUE/10，那么temp = result * 10 + pop一定会溢出
• 如果result = Int.MAX_VALUE/10，那么只要pop > 7，temp = result * 10 + pop就会溢出

当result为负整数时同理。

代码

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

/**
 * 整数反转
 */
private fun Int.reverse(): Int {
    
    // 要反转的整数
    var value = this
    
    // 结果
    var result = 0

    while (value != 0) {
        // 计算进位，注意 pop 是带符号的
        val pop = value % 10
        when {
            // 7 是 Int.MAX_VALUE 的第2位
            (result > Int.MAX_VALUE / 10) || (result == Int.MAX_VALUE / 10 && pop > 7) ->
                return 0
            // 8 是 Int.MIN_VALUE 的第2位
            (result < Int.MIN_VALUE / 10) || (result == Int.MIN_VALUE / 10 && pop < -8) ->
                return 0
        }
        result = result * 10 + pop
        value /= 10
    }

    return result
}

参考

• 题解1
• 题解2

两数相加#2

addTwoNumbers

定义方法#addTwoNumbers:

1
2
3

fun addTwoNumbers(l1: ListNode?, l2: ListNode?): ListNode? {
    // 具体实现
}

单元测试

1
2
3
4

val num1 = listOf(2, 4, 3).toLinkedList()
val num2 = listOf(5, 6, 4).toLinkedList()
val sum = addTwoNumbers(num1, num2)
assert("${sum.toList()}" == "[7, 0, 8]")

解法

• 将 2个链表看成长度相同的链表进行遍历，如果一个链表较短，则在前面补 0，比如 987 + 23 = 987 + 023 = 1010
• 每一位的计算考虑上一位的进位，当前位计算结束后更新进位
• 两个链表遍历完成后，进位为 1，则在新链表最前放添加节点 1

小技巧：对于链表问题，返回结果为头结点时，通常需要先初始化一个预指针 pre，该指针的下一个节点指向真正的头节点 head。
使用预指针的目的在于，链表初始化时无可用节点，而链表构造过程需要移动指针，进而导致头指针丢失，无法返回结果。

代码

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52

/**
 * 两数相加
 */
fun addTwoNumbers(l1: ListNode?, l2: ListNode?): ListNode? {

    // 初始化一个预指针
    val pre: ListNode? = ListNode(0)
    var cur: ListNode? = pre
    var carry = 0 // 进位

    var num1 = l1
    var num2 = l2

    while (num1 != null || num2 != null) {

        val x = when (num1 == null) {
            true -> 0
            else -> num1.`val`
        }
        val y = when (num2 == null) {
            true -> 0
            else -> num2.`val`
        }
        var sum = x + y + carry

        // 计算进位
        carry = sum / 10
        // 计算和
        sum %= 10

        // 将结果串联
        cur?.next = ListNode(sum)

        // 移动 cur 指针
        cur = cur?.next

        num1?.let {
            num1 = it.next
        }

        num2?.let {
            num2 = it.next
        }
    }

    if (carry == 1) {
        cur?.next = ListNode(carry)
    }

    // 返回 pre 的下一个节点
    return pre?.next
}

参考

• 精选题解

反转单链表#206

工程化

leetcode提交运行等待结果是一件很漫长的事情，而我们从编写代码到debug成功期间可能会失败 N次，所以本地有一个方便我们运行测试的环境还是蛮重要的。

这里我选择建立了一个工程，将题解代码放在里面。

leetcode题解调试过程中自定义的数据结构、方法有很多都是可以复用的，

所以，我们尽可能地复（tou）用（lan）。

节点类定义

1
2
3

class ListNode(var `val`: Int) {
    var next: ListNode? = null
}

吐槽，val与kotlin的关键字冲突，所以要通过` `来转义(😢)。

ListNode?#reverse

kotlin 基操，给ListNode?定义一个扩展方法reverse，将具体的实现写在这里。

1
2
3
4

// ListNode.kt
fun ListNode?.reverse(): ListNode? {
    // 这里给出具体的代码实现
}

单元测试

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

// Solution206.kt
class Solution206 {

    @Test
    fun reverse() {
        // 从顺序表生成一个单链表
        val head = listOf(1, 2, 3, 4, 5).toLinkedList()
        // 反转单链表，得到新的头结点
        val newHead = head.reverse()
        // 打印链表
        newHead.toList().forEach {
            print("$it")
        }
    }
}

这里用到了两个我自定义的扩展方法：

• List#toLinkedList，将List转换为单链表
• ListNode#toList，将单链表转换为List

PS: 目前题解还不多，日后完善了可能会开源回馈社区

解法

双指针迭代法

要反转链表，核心就是将节点的next指针指向前驱
但当前节点无法访问过去的节点（前驱）
因此需要保存前驱节点

申请两个指针：

• prev，最初指向NULL；cur，最初指向HEAD
• 不断遍历cur，每次迭代到cur，将cur.next -> prev（指针反指），然后prev和cur前进一格
• cur迭代完成（cur为NULL），prev所在的就是最后一个节点

核心代码如下：

1
2
3
4
5
6
7

while(cur != null){
    // 先保存`cur`的下一个节点，否则"prev"、"cur"前进的时找不到下个节点
    val next = cur.next
    cur.next = prev
    prev = cur
    cur = next
}

reverse 实现

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

fun ListNode?.reverse(): ListNode? {

    if (this == null || next == null)
        return this

    var prev: ListNode? = null
    var cur: ListNode? = this

    while (cur != null) {
        val next = cur.next
        cur.next = prev
        prev = cur
        cur = next
    }

    return prev
}

边界情况

kotlin 在语言层面支持空安全，结合IDE的提醒，时刻提醒我们注意边界！

1
2
3

// 如果当前链表为空或者只有一个节点，直接返回自身
if (this == null || next == null)
    return this

递归解法

TODO

参考

• 题解1

面试中经常会被问到这样一个问题或者它的类似问题。

你如何用程序的方式检测导致UI卡顿的问题，并且定位？

思考

我个人觉得这其实是一个还不错的综合体，考察点也还算多，也可以衍生出一些题目。

先来拆解一下关键词，程序的方式检测、UI卡顿、定位：

• 程序的方式检测：不是通过图形工具、不是通过交互来检测，而是通过编写工具类在应用运行时来检测
• UI卡顿：UI线程做了一些耗时的操作
• 定位：通过日志打印出耗时超过阈值的方法

技术补完

StackTrace&StackTraceElement

先来堆栈追踪部分的知识点，因为这块 api 用的多，但了解少。

StackTrace

StackTrace（堆栈跟踪），用栈的形式保存方法的调用信息。

这个其实我们一点也不陌生，在处理异常的时候，经常会这么写一句：e.printStackTrace()，即打印调用异常的堆栈信息，方便我们在异常发生的时候能定位到具体的问题。

StackTraceElement

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

/**
 * An element in a stack trace, as returned by {@link
 * Throwable#getStackTrace()}.  Each element represents a single stack frame.
 * All stack frames except for the one at the top of the stack represent
 * a method invocation.  The frame at the top of the stack represents the
 * execution point at which the stack trace was generated.  Typically,
 * this is the point at which the throwable corresponding to the stack trace
 * was created.
 *
 * @since  1.4
 * @author Josh Bloch
 */
public final class StackTraceElement implements java.io.Serializable {
    // 省略 N行
}

获取StackTraceElement的方法有2种，返回值为StackTraceElement[]。

• Thread#getStackTrace()，常见代码Thread.currentThread().getStackTrace()
• Throwable#getStackTrace()

StackTraceElement[]包含了StackTrace的内容，遍历它可以得到方法见的调用过程，即可以得到当前方法以及其调用者的方法名、调用行数等信息。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

// main 函数入口
fun main() {
    funA()
}

// 方法A
fun funA() {
    println("--->>> enter funA")
    funB()
}

// 方法B
fun funB() {
    println("--->>> enter funB")

    val elements = Thread.currentThread().stackTrace

    elements.forEachIndexed { index, e ->
        val className = e.className
        val funcName = e.methodName
        val fileName = e.fileName
        val lineNum = e.lineNumber
        println(
            "--->>> StackTraceElement index=>$index," +
                    " fileName=>$fileName, " +
                    "className=>$className, " +
                    "funcName=>$funcName, " +
                    "lineNum=>$lineNum"
        )
    }
}

输出，如图：

Looper

主线程里有个Looper，在loop方法中会不断取出Message，调用其绑定的 Handler 在主线程执行。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

loop(){
    final Looper me = myLooper();
    final MessageQueue queue = me.mQueue;

    // 省略 N行
    for (;;) {

        // might block
        Message msg = queue.next(); 

        // This must be in a local variable, in case a UI event sets the logger
        final Printer logging = me.mLogging;
        if (logging != null) {
            logging.println(">>>>> Dispatching to " + msg.target + " " +
                msg.callback + ": " + msg.what);
        }

        // 看这里
        msg.target.dispatchMessage(msg);

        if (logging != null) {
            logging.println("<<<<< Finished to " + msg.target + " " + msg.callback);
        }

        // 省略 N行
    }
}

关键点，我们只要有办法检测：msg.target.dispatchMessage(msg)的执行时间，判断执行时间是否大于我们设置的某个阈值就可以判断UI线程是否有耗时操作了。此代码执行前后，如果设置了logging，会分别打印出:>>>>> Dispatching to和 <<<<< Finished to 这样的日志。

实操

BlockCanary

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

private const val START = ">>>>> Dispatching"

private const val END = "<<<<< Finished"

class BlockCanary private constructor() {

    companion object {

        fun start() {
            Looper.getMainLooper()
                .setMessageLogging { str: String ->
                    when (str) {
                        START ->
                            LoggerMonitor.INSTANCE.start()
                        END ->
                            LoggerMonitor.INSTANCE.stop()
                    }
                }
        }
    }
}

LoggerMonitor

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39

private const val THRESHOLD = 1 * 1000L

class LoggerMonitor private constructor() {

    private val loggerThread: HandlerThread = HandlerThread("logger")

    private val ioHandler: Handler

    private val runnable = Runnable {
        val log = buildString {
            val stackTrace = Looper.getMainLooper().thread.stackTrace
            stackTrace.forEach { e: StackTraceElement ->
                append("$e\n")
            }
        }
        Log.e("TAG", log)
    }

    val isMonitor: Boolean
        get() = ioHandler.hasCallbacks(runnable)

    init {
        loggerThread.start()
        ioHandler = Handler(loggerThread.looper)
    }

    companion object {
        val INSTANCE by lazy { LoggerMonitor() }
    }

    fun start() {
        ioHandler.postDelayed(runnable, THRESHOLD)
    }

    fun stop() {
        ioHandler.removeCallbacks(runnable)
    }
}

假设我们的阈值设置为 1000ms，当str匹配到>>> Dispatching时，调用LoggerMonitor.INSTANCE.start()，在 1000ms后执行一个任务，打印出UI线程的堆栈信息（这次在子线程中执行）。正常情况，我们的msg.target.dispatchMessage(msg)执行耗时小于 1000ms，所以str匹配到<<<<< Finished，就会调用LoggerMonitor.INSTANCE.remove()移除任务。

这里还用到了 HandlerThread，也利用了 Looper，只不过这个 Looper 在子线程中。

测试环节

Application#onCreate

1
2
3
4
5
6

class DemoApplication : Application() {
    override fun onCreate() {
        super.onCreate()
        BlockCanary.start()
    }
}

耗时模拟

1
2
3
4
5
6
7

btn_test.setOnClickListener {
           try {
               Thread.sleep(2000L)
           } catch (e: Throwable) {
               e.printStackTrace()
           }
       }

点击按钮，打印出 log：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

2020-03-10 01:40:10.509 4740-4765/info.hellovass.build_example E/TAG: java.lang.Thread.sleep(Native Method)
    java.lang.Thread.sleep(Thread.java:373)
    java.lang.Thread.sleep(Thread.java:314)
    info.hellovass.build_example.MainActivity$onCreate$1.onClick(MainActivity.kt:15)
    android.view.View.performClick(View.java:6597)
    android.view.View.performClickInternal(View.java:6574)
    android.view.View.access$3100(View.java:778)
    android.view.View$PerformClick.run(View.java:25885)
    android.os.Handler.handleCallback(Handler.java:873)
    android.os.Handler.dispatchMessage(Handler.java:99)
    android.os.Looper.loop(Looper.java:193)
    android.app.ActivityThread.main(ActivityThread.java:6669)
    java.lang.reflect.Method.invoke(Native Method)
    com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:493)
    com.android.internal.os.ZygoteInit.main(ZygoteInit.java:858)

会打印出耗时相关的代码信息，然后可以通过日志定位到耗时的方法。

Choreographer???

2020-03-10 01:40:11.516 4740-4740/info.hellovass.build_example I/Choreographer: Skipped 119 frames! The application may be doing too much work on its main thread.

这个日志似乎怎么感觉那么熟悉呢？其实日常开发中，如果我们操作不当（UI线程里执行耗时的操作）就能看到。而这个Choreographer，好像和啥 Android、16ms绘制一帧等关键词有着说不清的关系。

没错，正是在下。

Android 系统每隔 16ms 发出 VSYNC 信号，触发对 UI 的渲染。Android SDK 包含了一个相关类，以及相应的回调。理论上来说，两次回调的时间周期应该在 16ms以内，超过了，我们则认为是一次造成卡顿的耗时操作，于是：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

class BlockCanary2 private constructor() {

    companion object {
        fun start() {
            Choreographer.getInstance()
                .postFrameCallback(object : Choreographer.FrameCallback {
                    override fun doFrame(frameTimeNanos: Long) {
                        if (LoggerMonitor.INSTANCE.isMonitor){
                            LoggerMonitor.INSTANCE.stop()
                        }
                        LoggerMonitor.INSTANCE.start()
                        Choreographer.getInstance()
                            .postFrameCallback(this)
                    }
                })
        }
    }
}

第一次的时候开始检测，如果超过阈值则输出相关堆栈信息；否则移除。

衍生

这就完了嘛？兄dei，想多了，如果生产环境的性能检测工具这么写，那真的就是面向离职编程了2333。

实际要考虑的问题简直不要太多！

• Handler#hasCallbacks 方法仅支持 Android Q 及以上
• 阈值为1000ms，第一个方法耗时980ms，第二个方法耗时20ms，这时候打印的堆栈是20ms的方法的堆栈
• 阈值还是为1000ms，第一个方法耗时500ms，第二个方法耗时500ms，这时候只打印了第二个方法的堆栈
• 怎么把这些堆栈信息同步到远端
• …

写在最后

突然想起好久之前看到过@markzhai发布过一个检测UI卡顿的工具，但当时年轻不懂其中的奥秘，连随手star都忘了。

这次一定!

参考

• Android UI性能优化 检测应用中的UI卡顿
• StackTrace简述以及StackTraceElement使用实例
• 卡顿监测之真正轻量级的卡顿监测工具BlockDetectUtil（仅一个类）

大厂面试比较喜欢问，看起来简单，没梳理过就会踩坑的题

问题

• onStart 和 onResume，onPause 和 onStop 从描述上来看差不多，对开发者来说有什么实质性的不同呢？
• 假设当前 Activity 为 A，如果这时用户打开一个新 Activity B，那么 B 的 onResume 和 A 的 onPause 哪个先执行呢？

问题1.

从实际使用过程来说，onStart 和 onResume、onPause 和 onStop 看起来的确差不多，甚至我们可以只保留其中一对，比如只保留 onStart 和 onStop。既然如何，那为什么系统还要提供看起来重复的接口呢？

这两个配对的接口表示的意义不同：

• onStart 和 onStop 从 Activity 是否可见
• onResume 和 onPause 从 Activity 是否位于前台

问题2.

涉及到 Activity 的启动流程，启动流程实际上非常复杂，包含 Instrumentation、ActivityThread 和 ActivityManagerService（经常说的AMS就是它了）。

简述流程：

• 启动 Activity 的请求由 Instrumentation 处理，然后它通过 Binder 向 AMS 发送请求
• AMS 内部维护了一个 ActivityStack 并负责栈内的 Activity 的状态同步，AMS 通过 ActivityThread 去同步 Activity 的状态从而完成生命周期方法的调用

在 ActivityStack 中的 resumeTopActivityInnerLocked 关键代码：

1
2
3
4
5
6
7
8
9
10
11
12
13

// If the flag RESUME_WHILE_PAUSING is set, then continue to schedule the previous activity
// to be paused, while at the same time resuming the new resume activity only if the
// previous activity can't go into Pip since we want to give Pip activities a chance to
// enter Pip before resuming the next activity.
final boolean resumeWhilePausing = (next.info.flags & FLAG_RESUME_WHILE_PAUSING) != 0
        && !lastResumedCanPip;

boolean pausing = getDisplay().pauseBackStacks(userLeaving, next, false);
if (mResumedActivity != null) {
    if (DEBUG_STATES) Slog.d(TAG_STATES,
            "resumeTopActivityLocked: Pausing " + mResumedActivity);
    pausing |= startPausingLocked(userLeaving, false, next, false);
}

从注释里可以看到，在新 Activity 启动之前，栈顶的 Activity 需要先 onPause，新 Activity 才能启动。最终，在 ActivityStackSupervisor 中的 realStartActivityLocked 方法会调用如下代码：

1
2
3
4
5
6
7
8
9
10
11
12
13
14

// Schedule transaction.
mService.getLifecycleManager().scheduleTransaction(clientTransaction);

// frameworks/base/services/core/java/com/android/server/am/ClientLifecycleManager.java 
void scheduleTransaction(ClientTransaction transaction) throws RemoteException {
    final IApplicationThread client = transaction.getClient();
    transaction.schedule();
    // 省略N行
}

// frameworks/base/core/java/android/app/servertransaction/ClientTransaction.java
public void schedule() throws RemoteException {
    mClient.scheduleTransaction(this);
}

ClientTransaction#schedule方法中的mClient是一个IApplicationThread接口，ActivityThread$ApplicationThread派生这个接口并实现了对应的方法。所以直接到ApplicationThread#scheduleTransaction方法。ActivityThread 类中没有定义 scheduleTransaction 方法，所以调用的是他父类的 ClientTransactionHandler#scheduleTransaction 方法。

1
2
3
4
5
6
7
8
9
10
11
12
13
14

// frameworks/base/core/java/android/app/ActivityThread.java
private class ApplicationThread extends IApplicationThread.Stub {
    ..
    @Override
    public void scheduleTransaction(ClientTransaction transaction) throws RemoteException {
        ActivityThread.this.scheduleTransaction(transaction);
    }
}

// frameworks/base/core/java/android/app/ClientTransactionHandler.java
void scheduleTransaction(ClientTransaction transaction) {
    transaction.preExecute(this);
    sendMessage(ActivityThread.H.EXECUTE_TRANSACTION, transaction);
}

在 ClientTransactionHandler#scheduleTransaction 中调用了 sendMessage 方法，该方法是一个抽象方法，实现在 ClientTransactionHandler 的派生类 ActivityThread 中，ActivityThread#sendMessage 方法会把消息发给内部名为H的Handler。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38

// frameworks/base/core/java/android/app/ActivityThread.java
void sendMessage(int what, Object obj) {
    sendMessage(what, obj, 0, 0, false);
}

private void sendMessage(int what, Object obj, int arg1) {
    sendMessage(what, obj, arg1, 0, false);
}

private void sendMessage(int what, Object obj, int arg1, int arg2) {
    sendMessage(what, obj, arg1, arg2, false);
}

private void sendMessage(int what, Object obj, int arg1, int arg2, boolean async) {
    if (DEBUG_MESSAGES) Slog.v(
        TAG, "SCHEDULE " + what + " " + mH.codeToString(what)
        + ": " + arg1 + " / " + obj);
    Message msg = Message.obtain();
    msg.what = what;
    msg.obj = obj;
    msg.arg1 = arg1;
    msg.arg2 = arg2;
    if (async) {
        msg.setAsynchronous(true);
    }
    mH.sendMessage(msg);
}

// ActivityThread$H
public void handleMessage(Message msg) {
    // 省略 N行
    case EXECUTE_TRANSACTION: 
        final ClientTransaction transaction = (ClientTransaction) msg.obj;
        mTransactionExecutor.execute(transaction);
        // 省略 N行
        break;
    // 省略 N行
}

H 的实例接收到 EXECUTE_TRANSACTION 消息后，调用TransactionExecutor#execute方法切换 Activity 的状态。TransactionExecutor#execute 方法里先执行 callbacks（如果不为null），然后改变 Activity 当前的生命周期状态。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

// frameworks/base/core/java/android/app/servertransaction/TransactionExecutor.java
public void execute(ClientTransaction transaction) {
    // 省略 N行
    executeCallbacks(transaction);
    executeLifecycleState(transaction);
    // 省略 N行
}

/** Transition to the final state if requested by the transaction. */
private void executeLifecycleState(ClientTransaction transaction) {
    // 省略 N行
    // Cycle to the state right before the final requested state.
    cycleToPath(r, lifecycleItem.getTargetState(), true /* excludeLastState */);

    // Execute the final transition with proper parameters.
    lifecycleItem.execute(mTransactionHandler, token, mPendingActions);
    lifecycleItem.postExecute(mTransactionHandler, token, mPendingActions);
}

在executeLifecycleState方法里:

• 先调用TransactionExecutor#cycleToPath方法执行当前生命周期状态之前的状态
• 然后执行ActivityLifecycleItem#execute方法，由于是从ON_RESUME状态到ON_PAUSE状态切换，中间没有其他状态，cycleToPath 这个情况下没有做什么实质性的事情，直接执行lifecycleItem.execute方法
• 之前在ActivityStack.startPausingLocked方法里面scheduleTransaction传递的是PauseActivityItem对象，所以executeLifecycleState方法里的lifecycleItem实际是PauseActivityItem对象

1
2
3
4
5
6
7
8
9

// frameworks/base/core/java/android/app/servertransaction/PauseActivityItem.java
@Override
   public void execute(ClientTransactionHandler client, IBinder token,
           PendingTransactionActions pendingActions) {
       Trace.traceBegin(TRACE_TAG_ACTIVITY_MANAGER, "activityPause");
       client.handlePauseActivity(token, mFinished, mUserLeaving, mConfigChanges, pendingActions,
               "PAUSE_ACTIVITY_ITEM");
       Trace.traceEnd(TRACE_TAG_ACTIVITY_MANAGER);
   }

PauseActivityItem#execute方法中传入的client实际上是ActivityThread对象，所以我们又回到了ActivityThread。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48

// frameworks/base/core/java/android/app/ActivityThread.java
@Override
public void handlePauseActivity(IBinder token, boolean finished, boolean userLeaving,
        int configChanges, PendingTransactionActions pendingActions, String reason) {
        // 省略 N行
        performPauseActivity(r, finished, reason, pendingActions);
        // 省略 N行
    }
}

final Bundle performPauseActivity(IBinder token, boolean finished, String reason,
        PendingTransactionActions pendingActions) {
    ActivityClientRecord r = mActivities.get(token);
    return r != null ? performPauseActivity(r, finished, reason, pendingActions) : null;
}

/**
 * Pause the activity.
 * @return Saved instance state for pre-Honeycomb apps if it was saved, {@code null} otherwise.
 */
private Bundle performPauseActivity(ActivityClientRecord r, boolean finished, String reason,
        PendingTransactionActions pendingActions) {
    // 省略 N行
    if (shouldSaveState) {
        callActivityOnSaveInstanceState(r);
    }

    performPauseActivityIfNeeded(r, reason);
    // 省略 N行
    return shouldSaveState ? r.state : null;
}

private void performPauseActivityIfNeeded(ActivityClientRecord r, String reason) {
    // 省略 N行
    try {
        r.activity.mCalled = false;
        mInstrumentation.callActivityOnPause(r.activity);
        // 省略 N行
    } catch (SuperNotCalledException e) {
        throw e;
    } catch (Exception e) {
        if (!mInstrumentation.onException(r.activity, e)) {
            throw new RuntimeException("Unable to pause activity "
                    + safeToComponentShortString(r.intent) + ": " + e.toString(), e);
        }
    }
    r.setState(ON_PAUSE);
}

离终点总算不远了，Instrumentation#callActivityOnPause 方法中调用了Activity#performPause，在performPause中我们终于看到了熟悉的钩子函数onPause，至此栈顶Activity的pause流程完毕。

总结

这里的源码是根据 Android 9.0 来分析的，跟 5.0 相比，真的复杂了很多，看到一位老哥的 Activity启动流程源码分析写的不错，把 pause 这块的流程分析稍加整理放到了这道题目下，有兴趣的话可以自己翻阅源码。

思考，9.0 的源码里似乎多了很多lifecycle、状态切换相关的字眼，如果是熟悉aac架构的老哥们一定不陌生了，9.0 这块改动这么大应该就是加入了 LifeCycle 的特性（确信）。

综上，新启一个Activity的时候，旧Activity的onPause会先执行，然后才会启动新的Activity。

官网对 onPause 的解释：

The foreground lifetime of an activity happens between a call to onResume() until a corresponding call to onPause(). During this time the activity is in visible, active and interacting with the user. An activity can frequently go between the resumed and paused states – for example when the device goes to sleep, when an activity result is delivered, when a new intent is delivered – so the code in these methods should be fairly lightweight.

别在 onPause 里做重量级操作，因为 onPause 执行完之后，新 Activity 才能 Resume！

参考

• （Android 9.0）Activity启动流程源码分析
• Android开发艺术探索

自从入职上家之后，一年多的时间里就基本没有碰过多渠道了（叹息）。

总之，回顾下吧。

多渠道

多渠道也叫多渠道打包。

为什么需要多渠道打包呢？一个包能解决的事情为毛这么麻烦呢？产出一个包不也能发布到各个应用市场嘛。

如果所在的公司没有以下需求：

• 统计哪个渠道用户变多
• 哪个渠道用户黏性强
• 哪个渠道需要个性化的设计
• …

确实不需要！

我们通过 Android 提供的 API 可以获取到的信息有：

• 应用的版本号
• 版本名称
• 系统版本
• 机型
• …

但是唯独渠道，即应用商店的信息是没有办法从系统中获取到的。只能人为地在 apk 中添加渠道信息。

多渠道打包，需要关注的事情：

• 将渠道信息写入 apk
• 将 apk 中的渠道信息传输到后端

打包会经过签名这个步骤，而 Android 签名有 2种不同的方式：

• Android 7.0 之前，使用 v1 签名，是 jar signature，源自 JDK
• Android 7.0 之后，引入 v2 签名，是 Android 特有的 apk signature

使用区别：

使用 v2 方式签名，7.0 以下的系统安装应用会失败
使用 v1 方式签名，7.0 和 7.0 以下的都 OK

Android Studio 的图形界面可以同时选择两种签名方式，7.0 以下使用 v1，7.0 以上选择 v2，如图：

以下是 apk 安装过程中签名验证的流程，如图：

• UNCHANGED 代表 Android 7.0以下流程
• NEW 代表 Android 7.0以上流程

1
2
3
4
5

public class DefaultSigningConfig implements SigningConfig {

    // 省略 N行
    private boolean mV1SigningEnabled = true;
    private boolean mV2SigningEnabled = true;

v1、v2 签名默认都是启用的，如果想禁用，可以在对应的地方加上：

1
2
3
4
5

signingConfigs{
    release{
        v2SigningEnabled false
    }
}

v1、v2 有啥区别呢？

本质区别就在于签名的方式，首先 apk 本身是 zip 格式文件。

v2 签名后和签名前的差异：

签名前：

• 压缩的文件内容源数据
• 压缩的目录源数据
• 目录结束标识结构

签名后：

• 压缩的文件内容源数据
• 签名区块
• 压缩的目录源数据
• 目录结束标识结构

多了一个区块，用于签名验证。如果其他3区块被修改了，都逃不过 v2 验证，直接导致验证失败，所以 v2 比 v1 更加安全。

参考

• Android 组件化架构

在 《Android持续集成实践·后篇》中阐述了为何使用 pipeline 并且展示了一个简单的通用构建脚本，但实际生产环境中，会发现 Jenkins 内置的功能还远不能满足我们所有的需求。

这时，我们就需要扩展 pipeline。

在 pipeline 中定义函数

pipeline 本质就是一个 groovy 脚本。所以，我们可以在 pipline 中定义函数，并使用 groovy 语言自带的特性。

1
2
3
4
5
6
7
8
9
10
11
12
13

pipeline {
    agent any

    stages{
        steps{
            echo "${getVersion(BUILD_NUMBER)}"
        }
    }

    def getVersion(String buildNum){
        return new Date().format('yyMMdd') + "-${buildNum}"
    }
}

上述这个例子，我们定义了一个 getVersion 函数，并使用了 Date 类。

PS：当然不是所有的 groovy 脚本都能执行，有时候，我们需要用管理员身份登入 Jenkins，找到对应的 groovy 脚本，点击 Approve 给这个 groovy 脚本权限。

存在的问题

如果在一个 JenkinsFile 中定义一个函数，倒是无所谓。但是如果在 N 个 JenkinsFile 中重复定义这个函数，那干这个活的人就有一句mmp不知当讲不当讲了！

使用共享函数库

这又是啥勒？

Jenkins Pipline 很贴心，给我们提供了 shared library 这个功能，具体路径：Manage Jenkins -> Configure System -> Global Pipeline Libraries，如图：

配置项说明

• Name：共享库唯一标识，在 Jenkinsfile 中会用到
• Default version：默认版本。可以是分支名、tag 等。
• Load implicitily：隐式加载。如果勾选此项，将自动加载全局共享库，在 Jenkinsfile 中不需要显式引用，就可以直接使用。
• Allow default version to be overidden：如果勾选此项，则表示允许“Default version”被 Jenkinsfile 中的配置覆盖。
• include @Library changes in job recent changes：如果勾选此项，那么共享库的最后变更信息会跟项目的变更信息一起被打印在构建日志中。
• Retrieval method：获取共享库代码的方法。这里我们选择Modern SCM，然后选择 Git。

创建共享库

创建一个共享库项目，目录结构如下：

将代码推送到远程仓库中，然后将 ssh 地址填入到Modern SCM中。

使用共享库

1
2
3
4
5
6
7
8
9
10
11

@Library('global-shared-library)
pipeline{
    agent any
    stages{
        stage('build'){
            steps{
                say("Hello World")
            }
        }
    }
}

在 pipeline block 的顶部，我们使用 @Library 指定共享库。

NOTE: global-shared-library 就是配置项中的共享库标识符。

引入共享库之后，我们可以直接在 pipeline 中使用 vars 目录下的 say 函数。

小结一下，如何定义和使用一个共享函数库：

1. 按照共享库约定的源码结构，实现自己的逻辑
2. 将共享库托管到代码仓库中
3. 在 Jenkins 全局配置中配置共享库，主要是配置共享库的仓库地址
4. 在 Jenkinsfile 中使用 @Library 引用共享库

@Library

使用该注解可以指定引用的共享库版本。写法如下：

@Library(‘global-shared-library@‘) _

说明：

• 分支，如 @Library(‘global-shared-library@‘) _
• tag 标签，如 @Library(‘global-shared-library@release1.0‘) _
• git commit id，如 @Library(‘global-shared-library@e6gfhsfsdf’) _

Jenkins 支持同时添加多个共享库，所以 @Library 注解还允许同时引入多个共享库，如：@Library([‘global-shared-library’, ‘other-shared-library’]) _。

NOTE：Jenkins 处理多个共享库出现同名函数的方式是先定义者生效。也就是说，如果 global-shared-library 与 other-shared-library 存在同名的函数 say，而 @Library 引入时 global-shared-library 在 other-shared-library 前面，那么只有 global-shared-library 的 say 生效。

共享函数库介绍

共享库的目录结构复习：

放在 vars 目录下的是可以供 pipeline 直接调用的全局变量（真的很想吐槽“变量”这个名称）。变量的文件名即为在 pipline 中调用的函数名，文件名为驼峰式。

使用 var 目录下的全局变量可以调用 Jenkins pipeline 的步骤。比如 say.groovy，使用了 echo 步骤。

1
2
3

def call(String value = "hello world")
    echo "$value"
}

当我们在 Jenkinsfile 中调用 say("hello world") 时，它实际调用的是 say.groovy 文件中的 call 函数。

call 函数还支持 Closure（闭包）。举🌰：

定义一个 mvm.grrovy。

1
2
3
4
5

def call(Closure<String> closure){
    configFileProvider([configFile(fileId: 'maven-global-settings', variable: 'MAVEN_GLOBAL_ENV')]){
        closure("${MAVEN_GLOBAL_ENV}")
    }
}

通过 call 函数里的内容就可以将 configFileProvider 啰嗦的写法封装到 mvm 变量。于是，我们可以这么用：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

@Library('global-shared-library@master') _
pipeline {
    agent any
    tools {
        maven 'mvn-3.5.4'
    }
    stages {
        stage('Build'){
            steps{
                mvn{ settings->
                    sh "mvn -s ${settings} clean install"
                }
            }
        }
    }
}

接着来看 src 目录：

src 目录是以一个标准的 Java 源码结构，目录中的类被称为 Library class（库类）。而 @Library(‘global-shared-library@dev’) _ 中的 _ 代表一次性静态加载 src 目录下的所有代码 classpath 中。

Utils.groovy 代码：

1
2
3
4
5
6
7

package info.hellovass

class Utils implements Serializable {
    def getVersion(String buildNum, String commitId){
        return new Date().format('yyMMdd') + "-${buildNum}" + "-${commitId}"
    }
}

NOTE：Utils 实现了 Serializable 接口，是为了确保当 pipeline 被 Jenkins 挂起后能正确恢复。

在使用 src 目录中的类时，需要使用全包名。同时，因为写的是 Groovy 代码，所以还需要使用 script 闭包抱起来。举栗子：

1
2
3
4
5
6
7
8
9
10
11
12
13
14

@Library(['global-shared-library']) _
pipeline {
    agent any
    stages('Build') {
        steps {
            script {
                def util = new info.hellovass.Utils()
                def version = util.getVersion("${BUILD_NUMBER}", "${GIT_COMMIT}")
                echo "${version}"
            }
        }
    }
}

应用

比如，我们需要在构建成功时通过钉钉机器人发送消息到群里。

方案一，集成钉钉机器人插件

这个是网上能搜到的比较常见的方案，需要 jenkins 安装 DingTalk 插件，路径：Manage Jenkins -> Manage Plugins -> 可选插件。

但是 2.0 版本似乎不支持 pipeline 特性，只能通过 UI选项配置。

PS: 网上很多文章，可以参考

方案二，共享函数库登场

钉钉机器人可以看做一个比较通用的功能，于是，我们的共享函数库派上用场了。

新建一个 DingTalk.groovy

在 src 目录下新建一个 DingTalk.groovy，根据自己的需求编写函数：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

class DingTalk implements Serializable {
    /**
     * 发送文字消息
     * @param webHook
     * @param contentType
     * @param content 消息内容
     * @return
     */
    def sendTextMessage(
            String webHook,
            String contentType,
            String content
    ) {
        def template = "{\n" +
                "    \"msgtype\": \"text\", \n" +
                "    \"text\": {\n" +
                "        \"content\": \"$content\"\n" +
                "    }, \n" +
                "    \"at\": {\n" +
                "        \"atMobiles\": [], \n" +
                "        \"isAtAll\": true\n" +
                "    }\n" +
                "}"
        try {
            def cmd = ["curl", "$webHook", "-H", "Content-Type: $contentType", "-d", "$template"]
            def process = cmd.execute()
            process.waitFor()
            return process.text
        } catch (Exception e) {
            return e.message
        }
    }
}

上述代码定义了一个 sendTextMessage 函数，参数为:

• webHook：钉钉机器人 Webhook 地址
• contentType：application/json
• content：想要发送的文本内容

具体可以参考钉钉机器人开发文档，钉钉机器人发送的消息有多种类型：

• text 类型
• link 类型
• markdown 类型
• 整体跳转 ActionCard 类型

本文给出了发送 text类型消息的函数实现，其他几种类似，可以根据具体需求来实现。

核心原理

实际上，我们只需要执行一条 curl 命令就可以向钉钉机器人发送消息了，就这么简单。关键就是这条命令怎么写，以及如何执行了。

写法一

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

/**
 * 发送文字消息
 * @param webHook
 * @param contentType
 * @param content 消息内容
 * @return
 */
def sendTextMessage(
        String webHook,
        String contentType,
        String content
) {
    def template = "{\n" +
            "    \"msgtype\": \"text\", \n" +
            "    \"text\": {\n" +
            "        \"content\": \"$content\"\n" +
            "    }, \n" +
            "    \"at\": {\n" +
            "        \"atMobiles\": [], \n" +
            "        \"isAtAll\": true\n" +
            "    }\n" +
            "}"
    try {
        // 看这里
        def cmd = ["curl", "$webHook", "-H", "Content-Type: $contentType", "-d", "$template"]
        def process = cmd.execute()
        process.waitFor()
        return process.text
    } catch (Exception e) {
        return e.message
    }
}

cmd 是一个数组，cmd.execute 最后调用了 ProcessGroovyMethods#exec(String[] cmdarray, String[] envp, File dir) 方法，相关方法如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

// 方法一
public static Process execute(final List commands) throws IOException {
    return execute(stringify(commands));
}

// 方法二
public static Process execute(final String[] commandArray) throws IOException {
    return Runtime.getRuntime().exec(commandArray);
}

// 方法三
public Process exec(String cmdarray[]) throws IOException {
    return exec(cmdarray, null, null);
}

// 方法四
public Process exec(String[] cmdarray, String[] envp, File dir) throws IOException {
    return new ProcessBuilder(cmdarray)
        .environment(envp)
        .directory(dir)
        .start();
}

写法二

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

/**
 * 发送文字消息
 * @param webHook
 * @param contentType
 * @param content 消息内容
 * @return
 */
def sendTextMessage2(
        String webHook,
        String contentType,
        String content
) {
    def template = "{\n" +
            "    \"msgtype\": \"text\", \n" +
            "    \"text\": {\n" +
            "        \"content\": \"$content\"\n" +
            "    }, \n" +
            "    \"at\": {\n" +
            "        \"atMobiles\": [], \n" +
            "        \"isAtAll\": true\n" +
            "    }\n" +
            "}"
    try {
        // 看这里
        def cmd = "curl '$webHook' -H 'Content-Type: $contentType' -d '$template'"
        def process = cmd.execute()
        process.waitFor()
        return process.text
    } catch (Exception e) {
        return e.message
    }
}

cmd 是一个字符串，cmd.execute 最后调用了 ProcessGroovyMethods#exec(String[] cmdarray, String[] envp, File dir) 方法，相关方法如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

// 方法一
public static Process execute(final String self) throws IOException {
    return Runtime.getRuntime().exec(self);
}

// 方法二
public Process exec(String command) throws IOException {
    return exec(command, null, null);
}

// 方法三
 public Process exec(String command, String[] envp, File dir) throws IOException {
    
    if (command.length() == 0)
        throw new IllegalArgumentException("Empty command");

    StringTokenizer st = new StringTokenizer(command);
    String[] cmdarray = new String[st.countTokens()];

    for (int i = 0; st.hasMoreTokens(); i++)
        cmdarray[i] = st.nextToken();

    return exec(cmdarray, envp, dir);
}

// 方法四
public Process exec(String[] cmdarray, String[] envp, File dir) throws IOException {
    return new ProcessBuilder(cmdarray)
        .environment(envp)
        .directory(dir)
        .start();
}

困惑

理论上来说，两种实现是等价的。然鹅，测试之后，方法二执行耗时一万年，最后钉钉机器人发送消息失败。而方法一和直接在命令行里执行的速度差不多，并且能成功发送消息。

黑人问号？？？

打印命令

这里我们在 exec(String[] cmdarray, String[] envp, File dir) 这个方法里打上断点，来查看一下不同的写法，cmdArray 的值有什么区别？

写法一

写法二

果然，写法一的 cmdArray 符合预期，一看就能理解；写法二的参数被错误分割了，这也就是为毛写法二执行耗时过长而且失败的原因了。那为什么参数会被错误分割呢？

原因大致是这样的，写法二是通过空格来分割参数的！

总结

去 stackoverflow 上逛了一下，发现很多老外兄dei也有类似的问题。

所以，如果遇到要通过 groovy 执行命令的时候，推荐使用写法一。

参考

• Jenkins 2.x 实践指南

Android 工程的构建打包是一个复杂的流程，涉及工程源代码、资源文件、AIDL 文件以及工程所依赖的库文件的编译转换。

官方提供的构建流程图：

编译构建的4个步骤：源代码编译->代码合成->资源打包->签名和对齐。

1. Java 编译器对工程的代码资源进行编译，代码资源包括 App 的源代码、apt 编译生成的 R 文件和 AIDL 文件生成的 Java 接口文件。通过 Java 编译器编译生成 *.class 文件。
2. 通过 dex 工具，将 *.class 文件和项目依赖的第三方库文件生成虚拟机可执行的 .dex 文件，如果使用了 MultiDex，会产生多个 dex 文件，包含编译后的所有 .class 文件，即自身的 class文件和依赖库的 .class 文件。
3. apkbuilder 工具将 .dex 文件、apt 编译后的资源文件、依赖中的第三方库内的资源文件打包生成签名对齐的 apk 文件。
4. 使用 Jarsigner 和 Zipalign 对文件进行签名和对齐，最终生成 apk 文件。

通过 Gradle工具可以看到每个运行的 Task 的情况，还可以看到 Gradle 编译的流程，详细地显示出每个任务的 Task 耗时，如图：

以下为执行 ./gradlew assembleDebug 的 Task 输出：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

:app:preBuild // 开始预编译
:app:preDebugBuild // 开始 Debug 版本预编译
:app:checkDebugManifest // 开始检查 AndroidManifest
:app:prepareDebugDependencies // 检查 Debug 版本依赖
:app:compileDebugAidl // 编译 Debug 版本的 AIDL 文件
:app:compileDebugRenderscript // 编译 Renderscript 文件
:app:generateDebugBuildConfig // 生成 BuildConfig 文件
:app:generateDebugAssets // 生成 Assets 文件到文件夹
:app:mergeDebugAssets // 合并 Assets 文件
:app:generateDebugResValues // 生成 res value 文件
:app:generateDebugResources // 生成 resource 文件
:app:mergeDebugResources // 合并 resource 文件
:app:processDebugManifest // 处理 AndroidManifest 文件
:app:processDebugResources // 处理 resource 文件
:app:generateDebugSources // 合成资源文件
:app:compileDebugJavaWithJavac // 使用 Javac 编译 Java 文件
:app:compileDebugNdk // NDK 编译
:app:compileDebugSources // 编译资源文件
:app:transformClassesWithDexForDebug // 将 .class 文件转换成 .dex 文件
:app:mergeDebugJniLibFolders // 合并 JNI 文件夹
:app:transformNative_libsWithMergeJniLibsForDebug // 转换 JNI 文件
:app:processDebugJavaRes // 处理 Java 资源
:app:transformResourcesWithMergeJavaResForDebug // 转换 Java资源文件
:app:validateDebugSigning // 验证签名
:app:packageDebug // 打包
:app:assembleDebug // 签名