opoojkk

20260730

Thu, 30 Jul 2026 07:52:51 +0800

Android 17 MessageQueue 无锁化实现解析

Mon, 16 Mar 2026 08:31:03 +0800

最近 Android 有一个比较重磅的变化 —— MessageQueue 的实现从原来的有锁结构改成了无锁结构。

MessageQueue 是 Android 中非常核心的一套机制。应用中的各种事件都会通过 MessageQueue 来进行排队和分发。

旧的有锁实现，本质上是一个按时间排序的单链表优先队列。

这里的“优先”并不是传统意义上的 priority，而是：

1
2


when 越小
优先级越高

也就是说谁应该更早执行，谁就排在前面。

消息按照 when 字段排序：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


mMessages
 │
 ▼
Message (when=10)
 │
Message (when=20)
 │
Message (when=50)
 │
Message (when=100)

因此队列始终保证：

1

when 最小的消息在队头

MessageQueue.next() 每次只需要取：

1

mMessages

即可得到下一条要执行的消息。

这里有一个非常容易被误解的地方：

MessageQueue 并不是 FIFO 队列。

很多人会认为消息是按照发送顺序执行的，但实际上 MessageQueue 是按照 when 排序的。

例如：

1
2


handler.sendMessageDelayed(msgA, 5000);
handler.sendMessage(msgB);

发送顺序是：

1
2


msgA
msgB

但 when 的值是：

1
2


msgA = now + 5000
msgB = now

因此队列顺序变成：

1
2


msgB
msgA

也就是说：执行顺序由时间决定，而不是发送顺序。

所以 MessageQueue 更准确的描述其实是：按执行时间排序的优先队列。

旧实现中：

无论是

插入消息
获取下一条消息

都需要先获取锁。

基本流程如下：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


producer线程
 │
 ▼
获取锁
 │
 ▼
按 when 排序插入链表
 │
 ▼
释放锁

消费消息时同样需要获取锁。

当消息较多或者多个线程同时插入消息时，就容易出现锁竞争。

同时 UI 渲染相关任务依赖同步屏障（Sync Barrier）机制来保证优先级。

当 Choreographer 插入同步屏障后：

1
2


同步消息被阻塞
异步消息继续执行

新的版本中，将消息处理拆成了两个阶段：

1
2


1 插入消息
2 消费消息

整体结构也发生了变化。

旧实现中生产者线程直接操作有序链表。

而新的实现结构变成：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


Producer threads
 │
 ▼
 Lock-free Stack
 │
 ▼
 drainStack()
 │
 ▼
 Priority Queue

也就是说：

生产者线程
只负责把消息压入无锁栈

真正的排序操作只在 Looper 线程消费消息时才发生。

分发 #

在真正开始分发消息时，Looper 线程会先调用：

1

drainStack()

把无锁栈中的消息转移到优先队列中。

源码如下：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


private void drainStack(StackNode oldTop) {
 while (oldTop.isMessageNode()) {
 MessageNode oldTopMessageNode = (MessageNode) oldTop;
 if (oldTopMessageNode.removeFromStack()) {
 insertIntoPriorityQueue(oldTopMessageNode);
 }
 MessageNode inserted = oldTopMessageNode;
 oldTop = oldTopMessageNode.mNext;
 inserted.mNext = null;
 }
}

这里做的事情其实很简单：

1
2
3
4


stack
 │
 ▼
priority queue

完整执行流程如下：

 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


Handler.sendMessage
 │
 ▼
 构造 MessageNode
 │
 ▼
 CAS 压栈
 │
 ▼
┌──────────────────────┐
│ Lock-free Stack │
└──────────┬───────────┘
 │
 ▼
 drainStack()
 │
 ▼
┌─────────────────────────┐
│ Priority Queue │
│ Sync Queue Async Queue│
└──────────┬──────────────┘
 │
 ▼
 选择最早可执行消息
 │
 ▼
dispatchMessage()
 │
 ▼
handleMessage()

之所以要设计这一层 stack，主要是为了降低多线程插入消息时的竞争。

如果生产者线程直接操作优先队列，那么每次插入都会涉及：

1
2


heap 调整
O(log n)

同时还需要锁保护。

而 stack 的插入是：

1

O(1)

并且只需要一次 CAS。

三种状态 #

在新的 MessageQueue 中，涉及到三种状态节点：

1
2
3


STACK_NODE_ACTIVE
STACK_NODE_PARKED
STACK_NODE_TIMEDPARK

分别表示：

1
2
3
4
5
6
7
8


ACTIVE
Looper线程正在运行

PARKED
Looper线程阻塞等待消息

TIMEDPARK
Looper线程正在等待某个时间点

例如：

如果下一条消息要在 5 秒后执行，Looper 会进行类似：

1

pollOnce(timeout)

的定时等待。

这三种状态会在下一次插入消息时参与决策。

新的 MessageQueue 内部维护了两个优先队列：

1
2


同步消息队列
异步消息队列

当存在同步屏障时：

1
2


同步消息被阻塞
异步消息继续执行

如果没有同步屏障，则会从两个队列中选择when 最早的消息执行。

插入消息 #

说完消费流程之后，再来看消息是如何加入队列的。

在新的实现中，消息首先会加入一个无锁栈。

这个栈实际上是一个用链表实现的 Treiber Stack。

插入逻辑如下：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


while (true) {
 StackNode old = (StackNode) sState.getVolatile(this);

 node.mNext = old;

 if (sState.compareAndSet(this, old, node)) {
 ...
 return true;
 }
}

CAS 的含义是：

1

compareAndSet(expected, newValue)

只有当当前值等于 expected 时才会更新成功，否则更新失败。

三种状态在插入消息时的作用，就是决定是否需要唤醒 Looper 线程。

ACTIVE #

1

Looper线程正在运行

此时只需要压栈即可，不需要唤醒。

PARKED #

1

Looper线程阻塞等待消息

此时插入新消息必须唤醒：

1

nativeWake(mPtr)

TIMEDPARK #

1

Looper线程正在等待某个时间点

此时是否唤醒取决于：

1
2
3


新消息执行时间
是否早于
当前唤醒时间

如果更早，就需要提前唤醒。

如果当前栈顶不是状态节点，而是 MessageNode，说明栈中已经堆积了消息。

这时需要通过：

1

mBottomOfStack

找到栈底的状态节点。

结构类似：

1
2
3
4
5
6
7


MessageNode
 │
MessageNode
 │
MessageNode
 │
StateNode

这样 sState 既表示：

1
2


栈顶节点
同时也包含栈状态

如果状态和结构分开维护，就需要：

1
2


CAS stack
CAS state

两次原子操作。

现在只需要：

1

CAS(sState)

一次即可保证一致性。

两个队列有什么不同 #

两个优先队列分别是：

mPriorityQueue
mAsyncPriorityQueue

插入逻辑如下：

1
2
3
4
5


if (msgNode.isAsync()) {
 mAsyncPriorityQueue.add(msgNode);
} else {
 mPriorityQueue.add(msgNode);
}

同步消息进入同步队列，异步消息进入异步队列。

这样在存在同步屏障时，可以直接从异步队列取消息，而不需要扫描整个队列。

状态什么时候恢复 Active #

状态恢复为 ACTIVE 的情况主要有：

Looper线程被唤醒
Looper进入 next() 开始处理消息

线程重新开始执行消息循环时，会恢复为 ACTIVE 状态。

总结 #

Android 17 对 MessageQueue 做了一次重要的重构。

旧实现结构：

1
2
3
4
5


单链表
+
全局锁
+
多线程竞争

新实现结构：

1
2
3


Lock-free Stack
+
Priority Queue

生产者线程只需要：

1
2


CAS
压栈

消费者线程再统一整理顺序。

同时通过三种状态：

1
2
3


ACTIVE
PARKED
TIMEDPARK

精细控制线程唤醒。

整体思路可以总结为：

1
2
3
4
5


无锁收集消息
+
单线程整理顺序
+
按需唤醒 Looper

这样既降低了锁竞争，也减少了不必要的线程唤醒。

Android 启动 Activity 的多种方式

Sun, 01 Feb 2026 18:11:03 +0800

我们知道，Activity 是 Android 界面层的核心承载形式，几乎所有用户可感知的内容，最终都会落在 Activity 上。所有的内容都是基于Activity的，无论是内容、弹窗，随着官方进一步收紧安全策略，除系统应用外，普通应用更难仅仅依靠无页面的Service形式长期存在。Activity之于Android的重要性自然不言而喻。

那么，Activity是怎么启动的呢？

原生方式 #

原生方式我们通常分成两种：显示启动和隐式启动。

显示启动 #

显示启动即需要知道要启动的Activity是哪个，是最最常用的当属官方提供的方式，写起来是这样：

1
2


val intent = Intent(context, DetailActivity::class.java)
context.startActivity(intent)

当需要携带数据或是设置flag时，无非是多写两行代码，就变成了这样：

1
2
3
4
5
6
7


val intent = Intent(context, DetailActivity::class.java).apply{
 // 携带数据
 putExtra("name", "小明")
 // 设置flag
 addFlags(Intent.FLAG_ACTIVITY_NEW_TASK)
}
context.startActivity(intent)

这种方式非常灵活，每次启动添加参数、flag非常方便，编译器就能知道启动的Activity是否存在。除了出现过的这些，可以使用的还有设置luanchMode、添加动画甚至是权限，也可以使用ActivityResultLauncher接受新Activity的结果（startActivityForResult被弃用，不推荐使用）。

如果全都好，也就不会有这篇文章了对吧。它的不足是很繁琐，即使是按照相同的方式启动一个带有相同参数的Activity也要再写一遍，违反了DRY（Don’t Repeat Yourself）原则。

隐式启动 #

隐式启动和显示启动对应，也就是不知道要启动哪个具体Activity，只关心有什么特点，使用场景通常有几种：

基础功能Activity
外部Activity（三方登录）
DeepLink（Scheme）

好处是调用方不需要关心启动的是Activity名称，携带必要的参数即可。略有的不足是编译期无法校验 Intent 是否能被正确解析，只有在运行时由系统进行匹配，问题往往要到执行阶段才能暴露。

从H5中执行切携带参数时可能存在参数编码问题，需要编码，可以使用Uri.parse或是Uri.appendQueryParameter方法

封装 #

工厂方法 #

封装中用到最多的当属工厂方法。

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


class DetailActivity : AppCompatActivity() {

 companion object {
 fun start(context: Context, id: Long) {
 context.startActivity(
 Intent(context, DetailActivity::class.java).apply {
 putExtra("id", id)
 }
 )
 }
 }
}

这里是start，也可能是launch等等，将一个Activity启动的方法收敛到一个方法中，好处是很容易找到哪里启动，不足是通常不能满足所有情况，Kotlin中支持默认参数使用起来稍微些，Java中更严重，当需要不同参数情况很多时，往往要定义很多个相同名称的方法满足业务需要，看上去很乱。另外，一旦在 start 方法中掺杂业务判断，Activity 很容易从“页面”变成承载逻辑的入口，反而增加维护成本。

虽然封装了，使用时也一样是需要有所在模块的引入才能使用。

DSL / Builder #

这是我个人最喜欢的方式，利用Kotlin的扩展方法和reified关键字写出类似模板的代码。

写法像是这样：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


// 不设置flag
context.startActivity<DetailActivity> {
 long("id", 1)
}

// 设置flag
context.startActivity<DetailActivity> (options={
 flag(Intent.FLAG_ACTIVITY_NEW_TASK)
},extra = {
 long("id", 1)
})

本质上只是封装了显示启动，写法更优雅，其他方面并无差异。一样支持编译器检查，一样需要依赖Activity所在模块。

完整定义可以参考我的Gist：opoojkk/ActivityKt.kt

三方库 #

当然可以说，本质上还是封装显示启动，不过是程度不同而已，当然是这样，要是这么说，就不存在其他的方式了，毕竟Android只支持显示启动和隐式启动🤷‍♀️。

拿使用最多的框架ARouter举例，启动上的确是封装了显示启动，写法上倒是有几分像隐式启动中的DeepLink：

1
2
3
4


ARouter.getInstance()
 .build("/picture/detail")
 .withLong("id", 123)
 .navigation()

好处是写法上足够简单清晰，一目了然，带了哪些参数路径是什么，更重要的是不需要与要启动的Activity所在的模块有耦合，只关心启动，由框架完成注册。也因此支持在组件化工程中使用。不足嘛，硬要挑还是不能在编译器检查，传入的路径仍然是字符串。如果支持了，恐怕也没办法支持组件化了。

对比 #

方式	编译期校验	参数集中管理	使用成本	组件化友好	灵活性	适用场景
原生显示启动	有	无	低	无	高	小型项目、简单页面跳转
原生隐式启动	无	无	中	低	高	系统能力、三方应用、DeepLink
工厂方法	有	低	中	无	中	参数固定、跳转规则稳定的页面
DSL / Builder	有	中	中	无	高	Kotlin 项目、追求代码整洁度
ARouter 等三方库	无	高	高	高	高	组件化、多模块、大型工程

说明：

“编译期校验”指是否能在编译阶段发现 Activity 不存在或参数错误

Vue录音模块状态机重构笔记

Mon, 12 Jan 2026 22:13:42 +0800

最近被抓去写微信小程序，按照决策者的话说，逻辑都是一样的。

这句话对了一半。

作为一个成熟的 UI 框架，支持的交互能力一定是相似的：点击、长按、滑动、双击，不论是 Android、iOS 还是小程序，最终都会落到同一套用户行为模型上。但另一半恰恰是问题所在——语言和范式，会反过来塑造你组织逻辑和状态的方式。

以 Android 和小程序为例。Android 使用 Java、Kotlin 甚至 C++，这些都是强类型语言，有继承、多态、接口，重复逻辑既可以组合，也可以通过继承收敛。状态往往会被包进类里，由类型系统帮你兜底。

而在 Vue / 小程序中，语言是 JavaScript，本身动态类型语言，在不引入 TypeScript 的情况下，几乎没有编译期类型约束；虽然语法上存在 class，但在实际工程中，很少通过继承体系来承载状态语义。

这在简单页面里问题不大，但一旦交互复杂，很容易失控。

这篇文章记录的，就是我在一个录音页面里，从“多个状态变量维护”一路踩坑，最终重构成状态机的过程。

背景 #

决定重构并不是为了“写得更优雅”，而是代码已经修不动了。

页面里有两个主要流程：

AI 提问流程：视频播放到指定时间 → 系统引导 → 用户长按录音 → 识别 → 反馈
学生主动提问流程：用户点击 → 引导 → 长按录音 → 最多两轮对话 → 结束

限制条件很多：

播放音频时不能提问或录音
录音按钮和提问按钮是同一个组件
长按开始，松手结束，上滑取消
问题只会在体验版（类似 Android 的正式包）里完整暴露

真正卡住我的是一个 bug：

长按后立刻松手，重复几次后，会进入“再也无法录音”的状态。

日志看不出异常，复现不稳定，调了大半天没有头绪。越查越发现一个问题：我已经不知道系统当前到底处在什么状态了。

状态失控 #

先看状态变量。

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


const isRecordingCanceled = ref(false)
const isPressingRecordButton = ref(false)
const hasSlideToCancel = ref(false)
const recordingReady = ref(false)
const isWaitingForInput = ref(false)
const isPlayingAudio = ref(false)
const showRecordingUI = ref(false)
const recordingStartTime = ref(0)
const audioFilePath = ref('')
const recordingType = ref('')

const userActionCount = ref(0)
const currentSessionCount = ref(0)
const currentResponseCount = ref(0)
const canTriggerAction = ref(true)

// 名义上的“主状态”
const currentStatus = ref(STATUS_WELCOME)

变量本身都很合理，问题在于：它们组合在一起，才代表一个“真实状态”，但这种组合完全靠人脑维护。

判断“现在能不能开始录音”，需要这样写：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


if (
 isPressingRecordButton.value &&
 !isRecordingCanceled.value &&
 recordingReady.value &&
 !isWaitingForInput.value &&
 !isPlayingAudio.value &&
 showRecordingUI.value &&
 currentStatus.value === STATUS_WAITING_INPUT
) {
 // 可能可以录音
}

当这些变量组合在一起，可能性已经完全超过了可以用逻辑理清的范畴

异步时序 #

微信的录音 API 是异步的：

start() 不代表录音已经开始
硬件真正就绪后，才会触发 onStart

正常流程是：

1

按下 → start → onStart → 松手 → stop → onStop

但如果用户“秒按”：

1

按下 → start → 松手 → stop → onStart → onStop

旧代码里的 onStart 并不知道用户已经松手：

1
2
3


recorderManager.onStart(() => {
 updateRecordingStatus()
})

于是 UI 会被切到“录音中”，而用户此时已经放开手，状态就此错位。

这正是那个“松手了还在录音”的根源。

重构一：明确状态 #

第一步是把“隐含状态”变成“显式状态”。

1
2
3
4
5
6
7


const STATUS_SYSTEM_WAITING_INPUT = 12
const STATUS_SYSTEM_RECORDING = 13
const STATUS_SYSTEM_PROCESSING = 14

const STATUS_USER_WAITING_INPUT = 22
const STATUS_USER_RECORDING = 23
const STATUS_USER_PROCESSING = 24

现在判断“是否可以录音”只需要一行：

1

currentStatus.value === STATUS_SYSTEM_WAITING_INPUT

状态本身就是语义，不再需要拼布尔值。

重构二：用会话 ID 隔离异步回调 #

为了解决时序问题，我引入了录音会话 ID。

1
2


const currentRecordSession = ref(0)
const isHardwareRunning = ref(false)

开始录音时生成会话：

1
2
3


const session = Date.now()
currentRecordSession.value = session
recorderManager.start()

在 onStart 中校验：

1
2
3
4


if (currentRecordSession.value === 0) {
 recorderManager.stop()
 return
}

如果用户在硬件启动前松手，直接作废会话：

1

currentRecordSession.value = 0

所有异步回调都必须验证 session 是否有效，Race Condition 被彻底隔离。

重构三：状态驱动UI #

所有 UI 行为统一收敛到配置表：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


const STATUS_CONFIG_MAP = {
 [STATUS_SYSTEM_WAITING_INPUT]: {
 buttonType: 'record',
 buttonEnabled: true,
 videoControlEnabled: false
 },
 [STATUS_SYSTEM_PROCESSING]: {
 buttonEnabled: false
 }
}

状态切换统一通过：

1

toStatus(newStatus)

UI 不关心“为什么”，只关心“现在是什么状态”。

重构四：状态日志面板 #

为了验证状态流是否正确，我在页面里加了一个状态日志面板，记录每一次状态切换和关键日志。

事实证明这是非常值得的投入：很多“偶现问题”，在日志里其实一眼就能看出来，只是以前没有工具帮你看见。

重构结果 #

秒按、长按、取消不再互相污染状态
状态判断全部集中，逻辑路径清晰
错误恢复不再依赖“记得重置哪些变量”

判断当前的状态由十几个变量改为一个变量，通过判断变量状态的值就能够判断当前显示的样式。好处很明显，降低了复杂度（想不到写代码还会用到这个词），只要流程是清晰的，状态的改变一定是按照预先考虑的顺序的，即使中间有状态的转换。

当控件由多个布尔值维护时，其实已经意识到这部分代码很可能已经失控了，变量越用越多，状态就越来越复杂，总有复杂到理不清楚的状态。

反思 #

回过头再想，重构做的好吗，是还能做的更好的，这明显就是状态模式，可惜的是 JavaScript 在语言层面并不支持 sealed 这类类型系统能力，只能通过约定和运行时校验来模拟。

回过头来看这个录音模块，可以先抽象出两个高优先级维度，再衍伸出具体业务状态。

第一类：交互方式维度

点击触发（Tap）
长按触发（Long Press）

第二类：是否允许触发

可触发
不可触发（被音频播放、处理中、次数限制等条件锁住）

在这两个维度之下，才进一步派生出更具体的业务状态，比如：

等待输入
正在录音
系统处理中
等待退出
奖励展示

在 JavaScript / Vue 里，这些关系通常会被压扁成一堆布尔值；而在 Kotlin 里，这是密封类（sealed class）绝佳的使用场景。

密封类描述状态 #

如果这是 Android，我大概率会先定义一个状态模型，而不是一堆 flag。

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


sealed class RecordState {

 // 点击类交互
 sealed class Tap : RecordState() {

 object Disabled : Tap()

 object Ready : Tap()

 object Processing : Tap()
 }

 // 长按类交互
 sealed class LongPress : RecordState() {

 object Disabled : LongPress()

 object Waiting : LongPress()

 data class Recording(
 val startTime: Long
 ) : LongPress()
 }
}

这里有几个关键点：

状态是封闭集合
- 不存在“忘记处理的状态”
- 编译器会强制你在 when 里覆盖完整
交互方式本身是一级语义
- Tap 和 LongPress 是两棵完全独立的状态树
- 不需要靠 isLongPress && canRecord && !isPlaying 这种组合判断
是否可触发被状态本身表达
- Disabled 就是不允许
- 不需要额外的 canTrigger 变量

状态驱动 UI #

使用会非常简单，比如在 UI 层：

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


when (val state = recordState) {
 is RecordState.Tap.Disabled -> {
 disableButton()
 }
 is RecordState.Tap.Ready -> {
 showTapButton()
 }
 is RecordState.Tap.Processing -> {
 showLoading()
 }

 is RecordState.LongPress.Disabled -> {
 disableRecordButton()
 }
 is RecordState.LongPress.Waiting -> {
 showRecordHint()
 }
 is RecordState.LongPress.Recording -> {
 showRecordingUI(state.startTime)
 }
}

这里没有任何“隐式约定”，每一种 UI 行为，都由一个确定的状态类型驱动。

这次最难处理的，其实不是状态本身，而是录音 start / stop 的异步时序。

在 Kotlin 中，我很可能会把它直接建模进状态里：

1
2
3
4


data class Recording(
 val sessionId: Long,
 val startTime: Long
) : LongPress()

然后在回调里只做一件事：

1
2
3
4
5


if (currentState is Recording &&
 currentState.sessionId == callbackSessionId
) {
 // 合法回调
}

非法回调在类型层面就就被过滤掉了，用不到依赖其他变量或是逻辑。

对比 #

在 Vue / JavaScript 里，我只能通过：

手动维护 currentRecordSession
手动判断 isHardwareRunning
手动约定哪些状态允许哪些行为

才能达到类似的效果。

我认为这是语言的定位不同造成的，JS最最开始也是只操作dom树的语言，至于后续为什么演变成现在的状态，我没有经历过，不敢轻下妄言。

这次在小程序里用状态机，本质上是模拟 Kotlin sealed class ：

状态是有限的
转换路径是显式的
UI 行为由状态决定，而不是由事件临时判断

只是这些，在 Kotlin 里，编译器可以帮你约束；在 JavaScript 里，只能靠你自己。

2025年终总结

Mon, 29 Dec 2025 21:39:48 +0800

又是一年年尾，又到了写年终总结的时候，写年终总结无非是敦促自己想想这一年做了什么，有什么进步，又有什么想做没做成的。

细想这一年变化蛮大的，生活上、工作上都是。

生活 #

生活上，最大的变化就是从小一块长大的妹妹要结婚了。我是家里的独生子，妹妹是我大大家的，她上面还有一个亲哥。想着从小总能见到的妹妹要和另一个男生一起生活，过年不能再像之前一样打麻将，心里总归有些寂寞。

一个朋友离开北京回老家了，别人做的选择只能尊重，即使我认为回家不是最好的选择。但是我以为好的，其他人并不一定这么认为。交集只会越来越少。

年中离职前和入职现在的公司不久各养了一只猫，现在在养两只猫，一只叫岁岁，一只叫年年。要说什么寓意，岁岁平安，年年有余。开头的就是名字了，很俗，又很适合。刚好在前天两只一起做了绝育，变成了两只小公公猫。养猫的心情只有在养了之后才能体会，猫也是有自己的性格的，有的好动，有的好静，也有偶尔疯癫的，这才是一只完整的猫。

今年还买了保险，想不起来是什么契机体会到生命有多脆弱，万一我出了什么意外，我父母该依靠什么继续生活。保险可以被依靠，每年花一笔钱，抵消掉意外的概率。如果发生了保险公司赔偿一笔钱，给我父母，如果没有那更好。买保险就不要想万一没发生怎么办，钱白花了，没有那回事。谁也不知道什么时候发生，保险换来的是面对的底气和保障。

今年开始健身了，净身高173，体重才55kg，看上去瘦瘦巴巴的，随时要被风吹到。不是更早开始，是一直在纠结，是不是要找个人带着呢，又是不是做的不标准呢。到现在半年吧，上班占用的时间多，能去的次数少，也算是有些变化，还算满意。

工作 #

至于工作上嘛，年中换了工作，结果不能满意。

一直在找职业上方向，在想自己想做什么。体会过了不同的业务、不同的公司，加上平时的兴趣，还是希望做些不一样的事，单单实现业务没有乐趣。就好像是一个翻译，把产品逻辑翻译成代码。开发的职责也的确是实现产品的逻辑，又不止是这些。

现在像是到了十字路口，接下来要怎么突破，选择往哪走，都还在摸索，无论什么样，都不应该满足于当前的状态。

现在的大背景下，相信跨平台是趋势。看好跨平台，也看好响应式，即使现在不是，之后一定会是主流。

AI 还在快速变化，适应 AI 的存在是一定需要的，也就在想如果 AI 能把现在在使用的场景做到极限，未来什么样的程序员是有价值的，我想做的还需要人完成吗，我以为是需要的。

读书 #

今年和之前相比少得可怜，新的一年要重新拿起来。也带上几本给我印象深刻的书。

《亲密关系》 - 哪些因素会影响我们选择伴侣
《朱生豪书信全编》 - 朱生豪与宋清如的书信
《精英的傲慢》 - 优绩主义的影响
《老人与海》 - 精神的硬汉：圣地亚哥

新年目标 #

花更多时间看书
攒钱
学会游泳
掌握一门新的技能

大概就是这些，时间不早了，要洗洗睡了，祝大家平安快乐。

Compose Compiler 深入解析：从参数注入到重组执行的 IR 变换全流程

Sun, 28 Dec 2025 11:27:17 +0800

在 Compose 编译阶段，针对 @Composable 函数，编译器主要做两件事：

一是修改方法签名（参数注入），二是修改方法实现（函数体 Lowering）。这两个步骤是分离实现、顺序执行的，分别对应两个核心 IR Transform。

方法签名变换发生在 ComposerParamTransformer 中，负责向 Composable 函数注入 $composer、$changed、$default 等参数；方法实现变换发生在 ComposableFunctionBodyTransformer 中，负责生成 Group、处理默认参数、实现跳过与重组逻辑。

这两个 Transform 的入口方法形式上都叫 visitFunction，但它们承担的职责完全不同。

源码位置如下：

修改方法签名： https://cs.android.com/android-studio/kotlin/+/master:plugins/compose/compiler-hosted/src/main/java/androidx/compose/compiler/plugins/kotlin/lower/ComposerParamTransformer.kt

修改方法实现： https://cs.android.com/android-studio/kotlin/+/master:plugins/compose/compiler-hosted/src/main/java/androidx/compose/compiler/plugins/kotlin/lower/ComposableFunctionBodyTransformer.kt

在进入函数体变换之前，有必要先理解签名变换阶段到底做了什么。

ComposerParamTransformer 的核心目标很明确：把一个“普通的 Kotlin 函数”，改造成一个“可以被 Compose Runtime 驱动的函数”。

以一个最简单的 Composable 为例：

1
2
3
4


@Composable
fun A(x: Int) {
 f(x)
}

在签名层面，编译器会把它改写为（示意）：

1
2
3
4
5


fun A(
 x: Int,
 $composer: Composer<*>,
 $changed: Int
)

如果存在默认参数，还会注入 $default 掩码参数。

在 ComposerParamTransformer 中，真正完成这件事的是 copyWithComposerParam 这个扩展方法。它并不是“在原函数上就地修改”，而是深拷贝一个新的 IrSimpleFunction，并将新旧函数建立映射关系，防止递归调用和符号错乱。

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


private fun IrSimpleFunction.copyWithComposerParam(): IrSimpleFunction {
 assert(parameters.lastOrNull()?.name != ComposeNames.ComposerParameter)

 return deepCopyWithSymbolsAndMetadata(parent).also { fn ->
 val oldFn = this
 transformedFunctionSet.add(fn)
 transformedFunctions[oldFn] = fn
 fn.metadata = oldFn.metadata

 fn.overriddenSymbols = oldFn.overriddenSymbols.map {
 it.owner.withComposerParamIfNeeded().symbol
 }

 ...
 }
}

这里一个容易被忽略但非常关键的点是 overriddenSymbols 的处理。如果一个 Composable 函数重写了父类或接口方法（例如 setContent 中的 Content()），那么父类方法必须被同步注入 composer 参数，否则虚方法分发表会直接失效。

接下来是参数注入本身。

首先注入 $composer：

1
2
3
4
5
6


val composerParam = fn.addValueParameter {
 name = ComposeNames.ComposerParameter
 type = composerType.makeNullable()
 origin = IrDeclarationOrigin.DEFINED
 isAssignable = true
}

然后注入 $changed，用于参数变化追踪与跳过优化：

1
2
3
4
5
6


for (i in 0 until changedParamCount(realParams, fn.thisParamCount)) {
 fn.addValueParameter(
 if (i == 0) "$changed" else "$changed$i",
 context.irBuiltIns.intType
 )
}

这里的 $changed 并不是一个简单的 boolean，而是一个 bitmask。每个参数占用固定数量的 bit，用来编码该参数在调用点已知的状态（是否稳定、是否变化、是否未知）。

如果函数存在默认参数，还会额外注入 $default 掩码参数，用来指示哪些参数在调用点被省略：

1
2
3
4
5
6
7
8
9


if (fn.requiresDefaultParameter()) {
 for (i in 0 until defaultParamCount(currentParams)) {
 fn.addValueParameter(
 if (i == 0) "$default" else "$default$i",
 context.irBuiltIns.intType,
 IrDeclarationOrigin.MASK_FOR_DEFAULT_FUNCTION
 )
 }
}

需要注意的是：Compose 并不依赖 Kotlin 原生的 $default 桥接函数来处理默认参数，而是选择在 Composable 函数体内部显式展开默认值逻辑。这也是为什么默认参数的处理必须放在函数体变换阶段。

在签名变换阶段，还有一段看起来有些“边角料”的逻辑：

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


private fun IrSimpleFunction.makeStubsForDefaultValueClassIfNeeded(): List<IrSimpleFunction> {
 if (!isPublicComposableFunction()) return emptyList()

 val stubs = mutableListOf<IrSimpleFunction>()
 makeValueClassNonPrimitiveStub()?.let { stubs.add(it) }

 if (!context.platform.isJvm()) {
 makeValueClassInaccessibleConstructorDefaultStub { isPrimaryConstructorPrivate() }
 ?.let { stubs.add(it) }

 makeValueClassInaccessibleConstructorDefaultStub {
 !constructorVisibilityIsAtLeastAsAccessibleAsType()
 }?.let { stubs.add(it) }
 }

 return stubs
}

这段逻辑只在 public（或 published API）的 Composable 函数上触发，核心目的是处理 value class 作为默认参数时，在跨模块、构造器不可访问等场景下的 ABI 兼容问题。这些 stub 的生成完全发生在参数变换阶段，它们的存在只是为了保证调用侧参数 patch 的一致性，本身并不会参与 Group 生成或重组逻辑。

完成签名注入后，编译器才会进入第二阶段：函数体变换。

ComposableFunctionBodyTransformer 的入口同样是 visitFunction，但这里的重点已经不再是“函数长什么样”，而是“函数执行时如何与 Composer 交互”。

1
2
3
4
5
6
7
8
9


override fun visitFunction(declaration: IrFunction): IrStatement {
 val scope = Scope.FunctionScope(declaration, this)
 return inScope(scope) {
 visitFunctionInScope(declaration)
 }.also {
 metrics.recordFunction(scope.metrics)
 declaration.functionMetrics = scope.metrics
 }
}

FunctionScope 是整个函数体 Lowering 的上下文核心，它在构造时会扫描函数参数，识别：

是否存在 $composer
$changed 参数集合
$default 参数集合
实际业务参数数量
Slot 数量

其中一个最重要的派生属性是：

1

val isComposable = composerParameter != null

这里的“Composable”并不是指是否有 @Composable 注解，而是指：这个函数是否已经完成了 composer 参数注入，是否是一个真正可被 Runtime 驱动的 Composable 入口。

接下来进入 visitFunctionInScope。

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


private fun visitFunctionInScope(declaration: IrFunction): IrStatement {
 val scope = currentFunctionScope

 if (!scope.isComposable) {
 return super.visitFunction(declaration)
 }

 if (declaration.isDefaultParamStub) {
 return visitComposableFunctionStub(declaration)
 }

 if (declaration.origin == ADAPTER_FOR_CALLABLE_REFERENCE) {
 return visitComposableReferenceAdapter(declaration, scope)
 }

 ...
}

这里可以看到，函数体变换阶段一开始就会过滤掉几类“不是 Composable 执行体”的函数：

默认参数 stub、函数引用适配器，这些函数要么只是转发入口，要么只是桥接逻辑，本身不应该生成 Group，也不参与重组。

接下来才是 Composable 函数的核心分流逻辑。

编译器会基于函数特性，决定它属于哪一类：

Composable Lambda
可重启（Restartable）的普通 Composable
不可重启（Non-restartable）的 Composable

是否可重启，取决于多个条件的综合判断，而不仅仅是“是否 inline”。其中一个关键限制是：只有返回 Unit 的函数，才可能拥有独立的重组作用域（Restart Scope）。

不可重启并不等于“不生成 Group”。返回值的 Composable 函数依然需要 Group 来维护 Slot Table 状态，只是它们无法生成 startRestartGroup，通常会生成 startReplaceableGroup。

在可重启函数中，编译器会生成典型的结构：

1
2
3
4
5
6
7


$composer.startRestartGroup(key)

// 参数变化检测、默认参数展开、跳过逻辑

$composer.endRestartGroup()?.updateScope { composer, force ->
 A(x, composer, $changed or 1, $default)
}

这里的 updateScope Lambda，是 Runtime 在重组时重新执行该函数的入口。 $changed or 1 的目的是强制设置最低位，避免在重组回调中再次被跳过。

在函数体内部，$changed 位掩码的传播起到了核心作用。当一个 Composable 调用另一个 Composable 时，编译器会尽可能把当前已知的参数状态编码进被调用方的 $changed 参数中，这一过程被称为 Comparison Propagation。

1
2
3
4
5
6


B(
 x,
 123,
 $composer,
 (maskFromParent and dirty) or staticMask
)

通过这种方式，Runtime 可以在更深的调用层级上提前判断是否需要执行函数体，从而避免无意义的重组。

至此可以看到，Compose Compiler 的整体设计非常清晰：

第一阶段通过签名变换，把 Composable 函数改造成 Runtime 可调度的形态；第二阶段通过函数体变换，构建 Group 结构、展开默认参数、实现跳过与重组逻辑。

理解这一点之后，再回头看 remember、mutableStateOf、derivedStateOf 等 API，就会发现它们并不是“魔法”，而只是对 Slot Table 与 Group 机制的不同使用方式。

为什么设置 clipChildren = false 可以突破父 View 边界？

Sun, 21 Dec 2025 17:27:38 +0800

设置clipChildren = false #

默认情况下，clipChildren 是 true 的。也就是说，在 ViewGroup 绘制时，子 View 超出父 ViewGroup 范围的部分会被裁剪掉。当然，这个行为是可以通过设置关闭的。

如果将 clipChildren 设置为 false，允许子 View 绘制到父容器之外，Framework 内部到底做了什么？这篇就从源码角度来捋一捋这个过程。

setClipChildren 做了哪些事？ #

入口很清晰，就是 ViewGroup#setClipChildren：

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


/**
 * By default, children are clipped to their bounds before drawing. This
 * allows view groups to override this behavior for animations, etc.
 *
 * @param clipChildren true to clip children to their bounds,
 * false otherwise
 * @attr ref android.R.styleable#ViewGroup_clipChildren
 */
public void setClipChildren(boolean clipChildren) {
 boolean previousValue = (mGroupFlags & FLAG_CLIP_CHILDREN) == FLAG_CLIP_CHILDREN;
 if (clipChildren != previousValue) {
 setBooleanFlag(FLAG_CLIP_CHILDREN, clipChildren);
 for (int i = 0; i < mChildrenCount; ++i) {
 View child = getChildAt(i);
 if (child.mRenderNode != null) {
 child.mRenderNode.setClipToBounds(clipChildren);
 }
 }
 invalidate(true);
 }
}

整体逻辑并不复杂，设置后一共做了四件事：

判断之前的状态，避免重复设置；
将 clipChildren 状态保存到 ViewGroup 的 flag 中；
遍历所有子 View，同步更新其 RenderNode；
触发一次强制重绘。

其中，真正值得多看一眼的只有第 3 步。

RenderNode#setClipToBounds() #

View 中的 mRenderNode 是渲染系统的核心对象：

1
2
3
4
5
6
7
8
9


/**
 * RenderNode holding View properties, potentially holding a DisplayList of View content.
 * <p>
 * When non-null and valid, this is expected to contain an up-to-date copy
 * of the View content. Its DisplayList content is cleared on temporary detach and reset on
 * cleanup.
 */
@UnsupportedAppUsage
final RenderNode mRenderNode;

当调用：

1

child.mRenderNode.setClipToBounds(clipChildren)

本质上是在告诉渲染系统：这个 View 对应的 RenderNode 是否需要将自身绘制内容裁剪到其 bounds 之内。

继续往下看：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


/**
 * Set whether the Render node should clip itself to its bounds. This defaults to true,
 * and is useful to the renderer in enable quick-rejection of chunks of the tree as well as
 * better partial invalidation support.
 *
 * @param clipToBounds true if the display list should clip to its bounds, false otherwise.
 * @return True if the value changed, false if the new value was the same as the previous value.
 */
public boolean setClipToBounds(boolean clipToBounds) {
 return nSetClipToBounds(mNativeRenderNode, clipToBounds);
}

这里已经很明确了： clipChildren 最终并不是通过 Java 层 Canvas 裁剪实现的，而是直接下沉到了 RenderNode / HWUI 层。

nSetClipToBounds 在 Native 层 #

继续向下追，逻辑就进入了 AOSP 的 C++ 渲染管线中，这一点非常合理——毕竟最终执行绘制的是 HWUI。

简单来说，nSetClipToBounds 并不会立刻执行裁剪操作，而是：

将 clipToBounds 状态写入 RenderNode 的属性对象中；
这些属性会在后续的 RenderThread 同步阶段被读取；
真正的裁剪行为发生在 DisplayList 录制、RenderNode 遍历以及渲染阶段。

也就是说：

clipToBounds 是一个渲染属性声明，而不是一次即时裁剪操作。成员变量只是状态载体，真正的效果体现在后续渲染流程中。

如下图所示（保持原图）：

clipToBounds 如何真正影响绘制？ #

在 HWUI 的 RenderNode 树遍历过程中，clipToBounds 会参与多项关键逻辑：

Quick Reject（快速剔除）用于快速判断某个 RenderNode 是否完全在可见区域之外；
Dirty Region 计算裁剪开启时，子节点的脏区域会被限制在父节点 bounds 内；
DisplayList 裁剪指令生成决定是否需要在 DisplayList 中插入裁剪约束。

当 clipChildren = false 时：

子 View 的 RenderNode 不再受父节点 bounds 约束；
子 View 的绘制区域可以突破父容器；
相应地，脏区域的合并范围也会变大。

换句话说：

收集到的子 View 绘制区域，会在不受裁剪限制的情况下，合并进已有的 dirty region，参与后续重绘。

小结 #

从 AOSP 16 的实现来看，clipChildren 的本质并不是一个简单的「是否裁剪 Canvas」开关，而是：

一个 ViewGroup 层级的渲染策略声明
通过 RenderNode 下沉到 HWUI
深度参与裁剪、脏区计算与渲染优化逻辑

这也解释了为什么它对动画、悬浮效果以及性能都有直接影响。

Android 字符串资源加载流程解析

Sun, 07 Dec 2025 13:47:32 +0800

Android 字符串资源解析全流程解析 #

说明：本文基于 Android API 36.0 和 Android Code Search（2025.12.7 最新 android-latest-release 分支）进行源码分析。

在 Android 应用中，我们常写下这样一行代码：

1

val appName = context.getString(R.string.app_name)

看起来只是取一个字符串，但这行调用实际上穿过了从 Java 层到 Native 层的完整资源解析流程。下面以 string 为例，看系统是如何一步步把资源 ID 转成最终的字符串。

从 Context 到 AssetManager #

入口是 Context：

1
2
3
4


// frameworks/base/core/java/android/content/Context.java
public String getString(int id) {
 return getResources().getString(id);
}

ContextImpl 内部持有 ResourcesImpl，它最终把请求交给 AssetManager：

1
2
3
4
5
6
7
8


// frameworks/base/core/java/android/content/res/Resources.java
public CharSequence getText(@StringRes int id) throws NotFoundException {
 CharSequence res = mResourcesImpl.getAssets().getResourceText(id);
 if (res != null) {
 return res;
 }
 throw new NotFoundException("String resource ID #0x" + Integer.toHexString(id));
}

getResourceText() 会继续下沉到：

1
2


// frameworks/base/core/java/android/content/res/AssetManager.java
getResourceValue(resId, densityDpi, outValue, resolveRefs)

进入 JNI 前执行：

1
2


// frameworks/base/core/java/android/content/res/AssetManager.java
ensureValidLocked();

JNI 层：统一的资源访问入口 #

Android 将所有标量资源（string、color、integer、dimension 等）统一通过 NativeGetResourceValue() 访问：

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


// frameworks/base/core/jni/android_util_AssetManager.cpp
static jint NativeGetResourceValue(...){
 auto assetmanager = LockAndStartAssetManager(ptr);

 auto value = assetmanager->GetResource(resid, false /*may_be_bag*/, density);

 if (!value.has_value()) {
 return ApkAssetsCookieToJavaCookie(kInvalidCookie);
 }

 if (resolve_references) {
 auto result = assetmanager->ResolveReference(value.value());
 if (!result.has_value()) {
 return ApkAssetsCookieToJavaCookie(kInvalidCookie);
 }
 }

 return CopyValue(env, *value, typed_value);
}

GetResource：查找资源、识别类型 #

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


// frameworks/base/libs/androidfw/AssetManager2.cpp
auto result = FindEntry(resid, density_override, false, false);
if (!result.has_value()) {
 return base::unexpected(result.error());
}

// 如果 entry 是 map（style、array 等），则返回引用类型
if (auto map_entry = std::get_if<ResTable_map_entry>(&result->entry)) {
 if (!may_be_bag) return base::unexpected(std::nullopt);
 return SelectedValue(TYPE_REFERENCE, resid, result->cookie,
 result->type_flags, resid, result->config);
}

// 简单值：string、int、color
Res_value value = std::get<Res_value>(result->entry);

// 处理动态资源 ID
result->dynamic_ref_table->lookupResourceValue(&value);

return SelectedValue(value.dataType, value.data, result->cookie,
 result->type_flags, resid, result->config);

FindEntry：拆解 ID 并遍历所有设备配置 #

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


// frameworks/base/libs/androidfw/ResourceUtils.h
inline uint8_t get_package_id(uint32_t resid) {
 return static_cast<uint8_t>((resid >> 24) & 0x000000ffu);
}

inline uint8_t get_type_id(uint32_t resid) {
 return static_cast<uint8_t>((resid >> 16) & 0x000000ffu);
}

inline uint16_t get_entry_id(uint32_t resid) {
 return static_cast<uint16_t>(resid & 0x0000ffffu);
}

遍历所有配置：

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


// frameworks/base/libs/androidfw/AssetManager2.cpp
for (auto& config : configurations_) {
 const ResTable_config* desired = &config;

 if (density_override != 0 && density_override != config.density) {
 density_override_config = config;
 density_override_config.density = density_override;
 desired = &density_override_config;
 }

 auto result = FindEntryInternal(package_group, type_idx, entry_idx, *desired, ...);
 ...
}

FindEntryInternal：匹配策略 #

1
2
3
4
5
6


// frameworks/base/libs/androidfw/AssetManager2.cpp
if (entry_config.match(requested_config)) {
 if (entry_config.isBetterThan(best_config, requested_config)) {
 best = entry;
 }
}

Res_value：完整结构（string = 字符串池索引） #

 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


// frameworks/base/libs/androidfw/include/androidfw/ResourceTypes.h
struct Res_value
{
 uint16_t size;
 uint8_t res0;

 enum : uint8_t {
 TYPE_NULL = 0x00,
 TYPE_REFERENCE = 0x01,
 TYPE_ATTRIBUTE = 0x02,
 TYPE_STRING = 0x03,
 TYPE_FLOAT = 0x04,
 TYPE_DIMENSION = 0x05,
 TYPE_FRACTION = 0x06,
 TYPE_DYNAMIC_REFERENCE = 0x07,
 TYPE_DYNAMIC_ATTRIBUTE = 0x08,

 TYPE_FIRST_INT = 0x10,
 TYPE_INT_DEC = 0x10,
 TYPE_INT_HEX = 0x11,
 TYPE_INT_BOOLEAN = 0x12,

 TYPE_FIRST_COLOR_INT = 0x1c,
 TYPE_INT_COLOR_ARGB8 = 0x1c,
 TYPE_INT_COLOR_RGB8 = 0x1d,
 TYPE_INT_COLOR_ARGB4 = 0x1e,
 TYPE_INT_COLOR_RGB4 = 0x1f,
 TYPE_LAST_COLOR_INT = 0x1f,
 TYPE_LAST_INT = 0x1f
 };
 uint8_t dataType;

 enum {
 COMPLEX_UNIT_SHIFT = 0,
 COMPLEX_UNIT_MASK = 0xf,
 COMPLEX_UNIT_PX = 0,
 COMPLEX_UNIT_DIP = 1,
 COMPLEX_UNIT_SP = 2,
 COMPLEX_UNIT_PT = 3,
 COMPLEX_UNIT_IN = 4,
 COMPLEX_UNIT_MM = 5,

 COMPLEX_UNIT_FRACTION = 0,
 COMPLEX_UNIT_FRACTION_PARENT = 1,

 COMPLEX_RADIX_SHIFT = 4,
 COMPLEX_RADIX_MASK = 0x3,
 COMPLEX_RADIX_23p0 = 0,
 COMPLEX_RADIX_16p7 = 1,
 COMPLEX_RADIX_8p15 = 2,
 COMPLEX_RADIX_0p23 = 3,

 COMPLEX_MANTISSA_SHIFT = 8,
 COMPLEX_MANTISSA_MASK = 0xffffff
 };

 enum {
 DATA_NULL_UNDEFINED = 0,
 DATA_NULL_EMPTY = 1
 };

 uint32_t data;

 void copyFrom_dtoh(const Res_value& src) {
 if constexpr (kDeviceEndiannessSame) {
 *this = src;
 } else {
 copyFrom_dtoh_slow(src);
 }
 }
};

异常处理 #

1
2


// frameworks/base/core/java/android/content/res/Resources.java
throw new NotFoundException("String resource ID #0x" + Integer.toHexString(id));

加载流程图（示意） #

C++ 学习笔记：指针与引用

Sun, 30 Nov 2025 13:26:05 +0800

指针是什么 #

在 Java 和 Kotlin 这些语言里，你不能直接操作内存地址，只需要关心生命周期，避免被生命周期更长的对象引用，进而导致内存不能释放。这是一种内存管理方案。而 C++ 则允许显式地操作内存——更具体一点，是允许直接处理指针或你手动分配的内存。Rust 又走了另一条路：归属模型。一块内存只能被一个变量拥有，其他变量想要用它必须“借”，目的是规避 C/C++ 中指针带来的野指针、悬空指针之类的问题。

废话有点多，回到核心问题：指针到底是什么？

维基百科给出的定义非常标准，但也非常“教科书”。简单来说，指针就是一个变量，它的值不是普通数据，而是另一个对象的内存地址。也就是说，它保存的是“对象在哪里”，而不是“对象是什么”。

举个最正常不过的例子：

1

int a = 1;

所有语言都能理解这句话：定义一个 int 类型的变量 a，它的值是 1。只不过在底层，这意味着分配了一块用来放 int 的内存空间，这块空间里存着数字 1。而 a 其实就是“访问这块内存时的入口”。

如果我们能直接拿到这块内存的地址（假设是这块内存的起始位置），那还需要知道它是什么类型，才能知道要从这个地址往后读多少字节，才能正确还原数据的值。这就是为什么指针需要类型：int* 不仅意味着“存的是地址”，还意味着“当解引用时，把那段内存按 int 解释”。

所以，指针是什么？一句话：

指针是一个保存某个对象内存地址的变量。它的类型决定你用它解引用时如何解析那段内存。

在 C++ 中，指针由 * 声明：

1
2


int a = 1;
int* p = &a;

不要想太复杂，int* 就是“指向 int 的指针类型”，和你写 int、float 一样，是类型的一部分。它可以在定义时就指向某个变量，也可以先定义再让它指向别的地方。

既然说指针保存的是地址，那它就不能随便接受一个非地址的值，比如：

1

int* p = 1; // 不行

不是因为“指针不能赋值”，而是 1 并不是一个合法的地址，不能拿来解引用。

接下来，既然地址存进去了，怎么获得地址里存放的数据呢？还是用 *：

1

int a = *p;

你注意到没有，这次 * 在 = 右边，表示“解引用”。总之如果 * 没出现在类型声明里（int* p 这种），它就是“从地址取值”。

引用 #

前面说了，&a 的含义是“取 a 的地址”。而如果你写：

1

int b = a;

这表示的是：开辟一块新的内存，把 a 的值复制过去给 b。两个变量各占一块地方。

那有没有一种方式，不开辟第二块内存，只是给 a 再起一个名字，让另一个变量直接访问 a 的那块内存呢？有，这就是引用：

1

int& b = a;

b 和 a 是同一个对象的两个名字，修改 b 就是在修改 a。这也是为什么引用一旦绑定之后不能再改。

注意，这里的 & 和“取地址”的那个 & 完全不是一个含义。现在它出现在 = 左侧，也就是类型声明中，和 int* p 里的 * 类似，只是用来描述类型而已。

总结 #

* 和 & 都很“善变”，放在不同位置含义完全不同。

更准确地说，它们分为两种情况：一种是出现在类型声明中，比如 int*、int&；另一种是出现在表达式中，比如 *p（解引用）、&a（取地址）。

这两类含义完全不同：

符号	出现在“类型声明”中	出现在“表达式”中
`*`	声明“指针类型”	解引用（通过地址访问对象）
`&`	声明“引用类型”	取地址（得到指针）

从模拟信号到补码：计算机如何存储和计算数字

Thu, 13 Nov 2025 21:07:40 +0800

模电 #

总常听到计算机的世界中只有0和1这两个，现实也是这样。但是自然界中的数据通常不是这样不是0就是1这般非黑即白的。像是声音、电流等等，都是连续的。

为了能存储这些数据，就要转换成计算机的方式存储，那就是用二进制表示，怎么将连续的数值转换成二进制呢？先后经过模电（模拟电路）中的采样、量化、编码。

如果不想理解其中的经过，那么作用像是下图这种

想要更详细的理解，就需要付出一些时间了。

采样 #

上面是不同采样频率下得到的数据，得到的数据量是不同的，对应的，存储这些数据需要的空间也就不同。频率越高，损失的数据越少。

量化 #

刚刚看的是横坐标，现在看纵坐标。每个点对应的纵坐标都对应着在这次采样中取到的数值，想要能记录下来，要把数值以一个相对值记录对吧。纵坐标上可能是许多不同的值，但是我们保存的时候会将这些数据按照不同的阶段对应到不同的值。

拿电压举例：

假设模拟信号是一个连续电压曲线：

1

-1.0V → +1.0V

量化就是给这段范围分成若干"台阶"，比如 8 级：

电压范围	量化后值
-1.0V ~ -0.75V	0
-0.75V ~ -0.5V	1
-0.5V ~ -0.25V	2
-0.25V ~ 0.0V	3
0.0V ~ +0.25V	4
+0.25V ~ +0.5V	5
+0.5V ~ +0.75V	6
+0.75V ~ +1.0V	7

如果测得电压是 +0.63V，量化后结果是 6。

编码 #

经过量化步骤得到的是十进制的数，开始说过计算机需要用二进制的数保存，这一步要做的就是这个——将十进制转换成二进制。

数电 #

数电中通过不同的门电路和二进制完成数值的计算。补码的作用是为了简化减法计算，将减法转换成加法操作。

为什么这样呢？

加法操作比起减法需要更少的门电路，只是用一个完成加法即可。
加法的进位比起减法的借位更容易，加法只可能向高位进一，不可能进更多，也就是每一位上计算最多需要用到低位上进来的一个数；减法不一样，可能会遇到连续借位的情况，这时候会更复杂。

硬件实现:

直接减法器需要:

借位逻辑电路(比进位复杂)
大小比较电路
符号处理电路
可能的操作数交换电路
结果取反电路

加法器 + 补码只需要:

一个加法器
一个取反器(NOT门)
一个+1电路

补码 #

铺垫完了，什么是补码呢？怎么执行？为什么这么设计？

说白了补码是为了构建出和一个数比如是5，相加等于0的数，为了达成这个目的，有很多途径可以走。

为了理解补码，我们先看看其他编码方式：

原码（符号+原数字） #

1
2


+5 = 0000 0101
-5 = 1000 0101

这样其实和减法没什么差别了，先要知道两个数的正负，再比较两个数的绝对值，决定结果的符号。

反码 #

1
2


+5 = 0000 0101
-5 = 1111 1010 // 只是取反，没有 +1

这样看起来可以，但实际上有问题，会有两个0：

1
2


+0 = 0000 0000
-0 = 1111 1111

两种形式都是0。

还有另外一个问题，让我们举个例子计算5-3的结果。

1
2
3
4
5
6
7
8


5 的原码: 0101
3 的原码: 0011
3 的反码: 1100 (符号位不变,其他位取反)

5 + (-3): 0101
 + 1100
 -------
 10001 (产生进位)

为什么需要把进位加到最低位呢？

反码的数学本质 #

对于 n 位二进制数,负数 -x 的反码定义为:

1

反码(-x) = (2^n - 1) - x

这个定义直接决定了反码是模 2^n - 1 系统!

为什么是 2^n - 1? #

关键在于:反码是通过"按位取反"得到的

按位取反的数学本质 #

对于 4 位二进制:

1
2
3
4
5


3 的二进制: 0011

按位取反: 1100

这个1100代表什么数?

让我们计算:

1
2
3
4
5


原数: 0011 = 0×8 + 0×4 + 1×2 + 1×1 = 3
取反后: 1100 = 1×8 + 1×4 + 0×2 + 0×1 = 12

它们的关系:
3 + 12 = 15 = 1111

15 就是 2^4 - 1

通用规律 #

对于任意 n 位二进制数 x:

1

x 的按位取反 = (2^n - 1) - x

证明:

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


n位全1 = 111...1 (n个1) = 2^n - 1

例如:
4位: 1111 = 2^4 - 1 = 15
8位: 11111111 = 2^8 - 1 = 255

当我们对x按位取反时:
- x的某位是1 → 取反后是0
- x的某位是0 → 取反后是1

这等价于:
(2^n - 1) - x

综上，反码实际上是基于模 (2^n - 1) 的运算系统。对于 4 位二进制:

模是 2^4 - 1 = 15

这意味着在反码系统中,-3 实际上表示为:

1
2


-3 ≡ 15 - 3 = 12 (mod 15)
12 的二进制 = 1100

为什么需要循环进位 #

让我们看完整的计算过程:

5 - 3 的反码运算:

1
2
3
4


 0101 (5)
+ 1100 (-3的反码)
------
 10001

现在关键来了:

我们得到了 10001 (5位)
但在 4 位反码系统中,模是 15 (1111)
最高位的 1 代表进位,意味着我们"超出了模"

数学上的解释:

1
2
3
4
5
6
7


5 + 12 = 17 (十进制)
17 mod 15 = 2 ← 这是我们要的答案

在二进制中:
10001 = 16 + 1
16 mod 15 = 1
所以: 10001 mod 15 = 1 + 1 = 2

这个 “mod 15” 的操作在硬件上就是:把进位加回到最低位

1
2
3
4


 0001 (丢弃最高位)
+ 1 (循环进位)
------
 0010 = 2 ✓

这就是使用反码麻烦的原因。

补码的设计 #

对于 n 位二进制数,负数 -x 的补码定义为:

1

补码(-x) = 2^n - x

这个定义直接决定了补码是模 2^n 系统!

为什么不能是其他的数呢？刚刚的反码是2^{n-1，证明过不行了。那么模能不能更大一些呢？比如如果模是 2}n + 1：

1
2
3
4
5
6


定义: 补码(-x) = (2^n + 1) - x

验证: x + (-x) = x + (2^n + 1 - x)
 = 2^n + 1 = 10001

丢弃进位后:0001,还是不是0! ✗

所以只有 2^n 这个模才能让补码系统完美工作。

为什么内存中使用补码 #

说完了补码的设计原理，你可能会想：既然补码是为了简化硬件计算，那在内存里存储数据时，为什么也用补码呢？直接用原码存不是更直观吗？

统一性原则 #

想象一下，如果内存用原码存储，ALU（算术逻辑单元）用补码计算，会发生什么？

1
2
3
4
5


内存里的 -5: 1000 0101 (原码)
 ↓
 需要转换
 ↓
ALU 里的 -5: 1111 1011 (补码)

每次从内存读取数据到CPU进行计算，都要做一次转换；计算完再存回内存，又要转换回去。这不是白白增加了复杂度吗？

不如从头到尾都用同一套规则——这就是内存也使用补码的根本原因。

存储也需要比较 #

内存里的数据不只是存着不动，还要做很多操作：

比较大小：判断 a > b 吗？
查找：在数组里找最大值
排序：给一堆数排序

如果用原码，比较两个负数就很麻烦：

1
2
3
4
5
6


原码中:
-3 = 1000 0011
-5 = 1000 0101

直接按二进制比较: 1000 0101 > 1000 0011
得出结论: -5 > -3 ✗ 错了!

因为原码的符号位和数值部分是分开的，比较负数时要单独处理。

但在补码中：

1
2
3
4
5
6


补码中:
-3 = 1111 1101
-5 = 1111 1011

直接按二进制比较: 1111 1101 > 1111 1011
得出结论: -3 > -5 ✓ 对了!

补码的巧妙之处在于：所有数（包括正数和负数）都可以直接按二进制大小比较，不需要特殊逻辑。

节省硬件成本 #

如果内存用原码，CPU用补码，就需要：

数据总线上要有转换电路
缓存控制器要处理转换逻辑
DMA（直接内存访问）也要知道怎么转换

这些都是额外的硬件成本和功耗。

而统一使用补码：

数据从内存到CPU寄存器，直接传输，零开销
存储和计算用同一套规则，硬件设计简单
所有的加法器、比较器都可以共用

历史也是这么选择的 #

早期计算机确实尝试过不同的方案：

IBM 7090（1959）：用符号-数值表示（类似原码）
CDC 6600（1964）：用补码
现代所有处理器：都用补码

为什么最后都选择了补码？因为它在存储、传输、计算三个环节都是最优的选择。

C++中的自然溢出：补码的意外之喜 #

用了补码之后，还有一个意想不到的好处——溢出处理变得非常自然。

什么是溢出 #

先看一个简单的例子，8位有符号整数（int8_t）的取值范围是 -128 到 127：

1
2


int8_t a = 127; // 最大值
a = a + 1; // 发生了什么？

在数学上，127 + 1 = 128，但 128 已经超出了 int8_t 的表示范围。这就是溢出。

补码下的溢出行为 #

让我们看看在补码系统中实际发生了什么：

1
2
3
4


127 的补码: 0111 1111
 +1: 0000 0001
 ----------
结果: 1000 0000 = -128

127 + 1 = -128？这看起来很奇怪，但其实非常合理！

这正是模 2^n 运算的自然结果：

1
2
3


127 + 1 = 128
128 mod 256 = 128
但在补码中，128 被解释为 -128

为什么这是"自然"的？ #

关键在于：硬件不需要做任何额外的事情。

看看如果用原码会怎样：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


原码系统中 127 + 1:
0111 1111 (127)
+ 0000 0001 (1)
-----------
1000 0000

这是 -0 还是 -128？硬件需要：
1. 检测到溢出
2. 判断是上溢还是下溢
3. 设置溢出标志位
4. 可能触发异常

但在补码系统中：

1
2
3
4
5


硬件只管：
1. 做加法
2. 丢弃最高位的进位

就这么简单！结果自动"绕回"到正确的位置

实际例子：循环计数器 #

这个特性在实际编程中非常有用，比如实现一个循环计数器：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


uint8_t counter = 0;

// 不断递增
for (int i = 0; i < 300; i++) {
 counter++;
 // 当 counter 到达 255 后，自动变成 0
 // 不需要任何 if 判断！
}

// counter 最终值是 44
// 因为 300 mod 256 = 44

如果没有这种自然溢出，你需要这样写：

1
2
3
4
5
6
7
8


uint8_t counter = 0;

for (int i = 0; i < 300; i++) {
 counter++;
 if (counter > 255) { // 需要额外判断
 counter = 0;
 }
}

有符号数的环形世界 #

补码让整数形成了一个环形结构：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


8位有符号整数的"环":

 -128
 / \
 -127 127
 / \
 -126 126
 | |
 | ... |
 | |
 -1 → 0 → 1

不断加 1：... → 126 → 127 → -128 → -127 → ...

不断减 1：... → -127 → -128 → 127 → 126 → ...

这个环形结构让很多算法的实现变得优雅：

例子：判断两个时间戳的先后关系

1
2
3
4
5
6
7


uint32_t timestamp1 = 0xFFFFFFFE; // 接近最大值
uint32_t timestamp2 = 0x00000001; // 溢出后的值

// 即使 timestamp2 的数值小于 timestamp1
// 通过有符号减法可以正确判断
int32_t diff = (int32_t)(timestamp2 - timestamp1);
// diff = 3，说明 timestamp2 在后面

C++ 标准的规定 #

需要注意的是，C++ 标准对溢出有不同的规定：

无符号整数（unsigned）:

溢出行为是明确定义的
结果等于模 2^n
完全依赖补码的自然特性

1
2


uint8_t a = 255;
a = a + 1; // 确保结果是 0

有符号整数（signed）:

C++20 之前：溢出是未定义行为（UB）
C++20 开始：有符号整数必须用补码，溢出变成实现定义行为

1
2
3


int8_t a = 127;
a = a + 1; // C++20: 结果是 -128 (但编译器可以优化)
 // C++17: 未定义行为（危险！）

虽然实际上所有现代编译器都用补码，但在 C++17 及之前写代码时，最好避免依赖有符号数溢出的行为。

硬件层面的简洁 #

最后总结一下，补码让溢出处理变得如此简单的原因：

硬件需要做的：

执行加法
丢弃超出位数的进位

硬件不需要做的：

不需要检查溢出
不需要特殊处理边界值
不需要区分有符号和无符号（加法器是同一个）
不需要任何 if-else 逻辑

这就是为什么补码不仅简化了减法，还让整个整数运算系统变得如此优雅。

总结一下：

内存使用补码不是因为"不得不这样"，而是因为"这样最好"：

和CPU的计算逻辑统一，无需转换
比较操作可以直接用二进制大小判断
硬件实现最简单，成本最低
溢出行为自然，不需要额外处理逻辑

从内存到寄存器，从磁盘到网络传输，整个计算机系统都在用补码——这是一套经过时间检验的、最优雅的设计。

AAR 构建全解析:从解包到 APK 的完整生命周期

Mon, 10 Nov 2025 21:25:23 +0800

依赖里有一堆 AAR,最终 APK 里却不见它们的影子。

不是它们消失了,而是它们一进构建系统就被解包,残片分别流向:

dex
manifest
resources.arsc
assets
so

下面按真实的 AGP 源码线把整个事件复盘一遍。

AAR 生命周期的起点: ExtractAarTransform #

AAR 被下载后,首先交给一个类处理:

源码位置:

1
2


tools/base/build-system/gradle-core/src/main/java/
 com/android/build/gradle/internal/dependency/ExtractAarTransform.kt

源码链接: ExtractAarTransform.kt

它的使命只有一个: 把一个 AAR 解压成若干个部分,每个部分给后续的构建步骤使用。

注: 本文基于 AGP 7.x-8.x 版本分析。在 AGP 8.0+ 中,部分实现使用了新的 Artifact Transform API,但整体流程保持一致。

核心代码长这样:

 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


// ExtractAarTransform.kt (简化版)
override fun transform(
 outputs: TransformOutputs,
 input: File,
 inputLibrary: LibraryIdentity
) {
 ZipFile(input).use { zip ->
 zip.entries().asSequence().forEach { entry ->
 if (entry.isDirectory) return@forEach
 
 val path = entry.name
 val outputFile = when {
 // classes.jar: 库的主要字节码
 path == SdkConstants.FN_CLASSES_JAR -> {
 outputs.file(CLASSES_JAR)
 }
 
 // libs/*.jar: AAR 打包时包含的第三方依赖 jar
 path.startsWith(LIBS_PREFIX) && path.endsWith(SdkConstants.DOT_JAR) -> {
 outputs.file(LIBS_DIR, path.substring(LIBS_PREFIX.length))
 }
 
 // AndroidManifest.xml: 库自己的 Manifest
 path == SdkConstants.FN_ANDROID_MANIFEST_XML -> {
 outputs.file(MANIFEST)
 }
 
 // res/: 资源文件 (layout、drawable、values 等)
 path.startsWith(SdkConstants.FD_RES + '/') -> {
 outputs.file(RES_DIR, path.substring(4))
 }
 
 // assets/: 原始资源文件
 path.startsWith(SdkConstants.FD_ASSETS + '/') -> {
 outputs.file(ASSETS_DIR, path.substring(7))
 }
 
 // jni/: native 库 (so 文件)
 path.startsWith(SdkConstants.FD_JNI + '/') -> {
 outputs.file(JNI_DIR, path.substring(4))
 }
 
 // R.txt: 资源符号表
 path == SdkConstants.FN_RESOURCE_TEXT -> {
 outputs.file(R_TXT)
 }
 
 // proguard.txt: 混淆规则
 path == SdkConstants.FN_PROGUARD_TXT -> {
 outputs.file(PROGUARD_RULES)
 }
 
 // lint.jar: Lint 检查规则
 path == LINT_JAR_PATH -> {
 outputs.file(LINT_JAR)
 }
 
 else -> null
 }
 
 // 将文件从 zip 中拷贝到输出目录
 outputFile?.let { file ->
 zip.getInputStream(entry).use { input ->
 file.outputStream().use { output ->
 input.copyTo(output)
 }
 }
 }
 }
 }
}

AAR 在这里完成它的历史使命——解包成构建系统真正需要的零件。

剩下的流程,就是看这些碎片分别去哪。

1. classes.jar + libs/*.jar → 代码转换 → dex #

classes.jar 和 libs/ 目录下的 jar 文件拆出来之后,被交给代码处理链。

源码位置:

1
2
3


tools/base/build-system/gradle-core/src/main/java/
 com/android/build/gradle/internal/tasks/R8Task.kt # Release 构建
 com/android/build/gradle/internal/tasks/DexArchiveBuilderTask.kt # Debug 构建

处理流程分两种情况:

R8: 代码压缩 (ProGuard) + 优化 + 混淆 + dex 转换 (Release 模式)
D8: 单纯的 class → dex 转换 (Debug 模式或禁用 R8 时)

关键入口大致是这样:

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


// R8 模式 (Release 构建) - 伪代码
// AGP 7.x-8.0
R8.run(R8Command.builder()
 .addProgramFiles(classesJar) // 主程序 classes
 .addLibraryFiles(androidJar) // Android SDK
 .setMinApiLevel(minSdk) // 最低 API
 .addProguardConfigurationFiles(...) // 混淆规则 (包括 AAR 的 proguard.txt)
 .setOutput(outputDex, OutputMode.DexIndexed)
 .build()
);

// D8 模式 (Debug 构建) - 伪代码
D8.run(D8Command.builder()
 .addProgramFiles(classesJar)
 .setMinApiLevel(minSdk)
 .setOutput(outputDex, OutputMode.DexIndexed)
 .build()
);

在这个过程中发生了什么:

合并: 所有 AAR 的 classes.jar + libs/*.jar + 主工程的 class 文件一起处理
依赖解析: 处理 AAR 之间的传递依赖关系,确保所有需要的类都被包含
混淆规则收集: 所有 AAR 的 proguard.txt 被收集并应用到 R8/ProGuard
转换: Java 字节码 (.class) → Dalvik 字节码 (.dex)
分包: 如果方法数超过 65536,自动拆成多个 dex

最终输出:

1
2
3
4


classes.dex
classes2.dex
classes3.dex
...

此时库的字节码已经和主工程代码一起,统一转换成了 dex 格式。

2. AndroidManifest.xml → 合并 → 最终 manifest #

库里的 manifest 文件会被送进合并器。

源码路径:

1

tools/base/build-system/manifest-merger/

源码链接: manifest-merger

核心入口是:

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


// ManifestMerger2.java (简化逻辑)
MergingReport report = ManifestMerger2.newMerger(
 mainManifest, // 主模块的 manifest
 logger,
 MergeType.APPLICATION // 应用类型 (还有 LIBRARY 类型)
 )
 .addFlavorAndBuildTypeManifests(...) // variant 的 manifest
 .addLibraryManifests(libraryManifests) // AAR 的 manifest 在这里加入
 .withFeatures(...) // 合并特性配置
 .merge(); // 执行合并

// 获取合并后的 manifest
XmlDocument mergedDocument = report.getMergedDocument();

合并的核心逻辑:

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


// 简化版的节点合并策略 (伪代码)
private XmlDocument merge(
 XmlDocument lowerPriorityDocument, // 优先级低的 (库)
 XmlDocument higherPriorityDocument // 优先级高的 (主模块)
) {
 // 遍历低优先级文档的所有可合并元素
 for (XmlElement element : lowerPriorityDocument.getRootNode().getMergeableElements()) {
 
 // 在高优先级文档中查找同类型、同 key 的节点
 Optional<XmlElement> higherPriorityNode = 
 higherPriorityDocument.getNodeByTypeAndKey(element);
 
 if (higherPriorityNode.isPresent()) {
 // 存在冲突,按策略合并属性
 // 默认: 高优先级覆盖低优先级
 mergeAttributes(element, higherPriorityNode.get());
 } else {
 // 不冲突,直接添加到结果中
 addNodeToMergedDocument(element);
 }
 }
 
 return mergedDocument;
}

你看到的"主题被覆盖"“权限凭空出现"等现象都来源于这里。

合并优先级 (从高到低):

主模块 manifest
buildType manifest (如 debug/release)
flavor manifest (如 paid/free)
依赖库 manifest (AAR)

依赖冲突处理: 当 AAR1 依赖 AAR2,且都声明了相同的组件时:

按依赖解析顺序确定优先级
直接依赖优先于传递依赖
可使用 tools:replace、tools:merge、tools:remove 等标记手动控制合并策略

合并完成后,AAR 自己的 manifest 文件即完成使命。

3. res/ → 编译 → 合并 → 资源表 (resources.arsc) #

资源的处理是整个构建流程中最复杂的部分,分三个阶段。

源码位置:

1
2


tools/base/sdk-common/src/main/java/com/android/ide/common/resources/...
tools/aapt2/

第一阶段: 编译 (compile) #

每个资源文件单独编译成中间格式。

源码入口:

1

tools/aapt2/compile/

Task 类: CompileLibraryResourcesTask (AGP 7.x-8.0)

处理流程:

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


// aapt2 compile (简化逻辑)
int CompileCommand::Run(const std::vector<std::string>& args) {
 for (const std::string& filePath : inputFiles) {
 // 读取资源文件
 std::unique_ptr<ResourceFile> resource = LoadResourceFile(filePath);
 
 // 编译成 flat 格式
 // flat 是 aapt2 的中间产物格式——每个资源文件编译后生成一个 .flat 文件
 CompiledFileOutputStream out(outputPath);
 CompileResource(resource.get(), &out);
 }
 return 0;
}

例如:

1
2
3


res/layout/activity_main.xml → activity_main.xml.flat
res/drawable/icon.png → icon.png.flat
res/values/strings.xml → values_strings.arsc.flat

每个 AAR 的资源文件、主模块的资源文件,都会各自生成一堆 .flat 文件。

第二阶段: 链接 (link) #

所有 flat 文件被合并,生成最终的资源表和资源 ID。

源码入口:

1

tools/aapt2/link/

Task 类: LinkApplicationAndroidResourcesTask (AGP 7.x-8.0)

处理流程:

 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


// aapt2/link/Link.cpp (简化逻辑)
int LinkCommand::Run(const std::vector<std::string>& args) {
 
 // 1. 加载所有 compiled resources (flat 文件)
 std::vector<ResourceTable> tables;
 for (const std::string& input : inputFiles) {
 auto table = LoadCompiledFile(input);
 tables.push_back(std::move(table));
 }
 
 // 2. 加载 AAR 的 R.txt 符号表
 // R.txt 记录了库中资源的原始 ID,但这些 ID 会被重新分配
 for (const std::string& rtxtPath : libraryRTxtFiles) {
 ResourceTable table = ParseRTxt(rtxtPath);
 tables.push_back(std::move(table));
 }
 
 // 3. 合并资源表
 // 所有 AAR 的资源 + 主模块的资源都在这里合并
 ResourceTable finalTable;
 for (const ResourceTable& table : tables) {
 // 检查资源冲突,执行合并策略
 if (!finalTable.Merge(table, context)) {
 // 冲突处理: 主模块优先,AAR 资源被覆盖
 ReportConflict();
 }
 }
 
 // 4. 重新分配资源 ID
 // 每个资源分配一个唯一的 ID (0xPPTTEEEE 格式)
 // PP (0x7f) = 应用资源包 ID (系统资源是 0x01)
 // TT = 资源类型 ID (如 0x02=drawable, 0x0d=layout, 0x12=string)
 // EEEE = 该类型下的资源条目 ID (Entry ID)
 // AAR 原有的资源 ID 会被完全重新分配
 IdAssigner assigner(&finalTable);
 assigner.AssignIds();
 
 // 5. 生成 resources.arsc (资源索引表)
 TableFlattener flattener(options, &finalTable);
 std::ofstream arscFile(outputDir + "/resources.arsc", std::ios::binary);
 flattener.Flatten(&arscFile);
 
 // 6. 生成 R.java (或针对每个包生成独立的 R.java)
 // 包含所有资源的 ID 常量
 JavaClassGenerator generator(context, &finalTable);
 generator.Generate(packageName, outputDir + "/R.java");
 
 // 7. 打包非编译资源 (如 raw、图片原文件等)
 PackageResources(finalTable, outputDir);
 
 return 0;
}

第三阶段: 编译 R.java → R.jar #

aapt2 link 生成的是 R.java 源文件,还需要编译:

1
2
3
4
5


// 简化的编译流程
// AGP 7.x-8.0: 独立的编译任务
// AGP 8.0+: 整合到主编译流程中
javac -d output/ R.java
jar cf R.jar -C output/ .

最终产物:

resources.arsc: 资源索引表 (记录所有资源的 ID 和位置)
R.jar: 包含 R.java 编译后的 class
res/… : 优化后的资源文件 (layout、drawable 等)

库的资源从此融入主工程,获得重新分配的统一资源 ID。

4. assets/ → 原样打包进入 APK #

这部分处理最简单,直接复制。

源码位置:

1
2


tools/base/build-system/gradle-core/src/main/java/
 com/android/build/gradle/internal/tasks/MergeSourceSetFolders.java

核心逻辑:

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


// MergeSourceSetFolders.java (简化逻辑)
@TaskAction
public void merge() throws IOException {
 // 收集所有 assets 目录 (主模块 + 所有 AAR)
 List<File> assetsSets = getAssetsSets();
 
 // 直接复制到合并目录
 for (File assetsDir : assetsSets) {
 if (assetsDir.exists()) {
 // 简单的文件树复制
 FileUtils.copyDirectory(assetsDir, outputDir);
 }
 }
}

如果多个 AAR 或主模块有同名的 assets 文件,合并优先级:

主模块 assets
buildType assets
flavor assets
依赖库 assets (按依赖解析顺序,后解析的覆盖先解析的)

最终结果: 所有 assets 文件原样躺在 APK 的 assets/ 目录下。

5. jni/ (so) → ABI 过滤 → 打包进入 APK #

so 文件的处理在 native 库合并任务里完成。

源码路径:

1
2


tools/base/build-system/gradle-core/src/main/java/
 com/android/build/gradle/internal/tasks/MergeNativeLibsTask.kt

注: Task 类名在不同 AGP 版本可能略有差异,但逻辑一致。

核心逻辑:

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


// MergeNativeLibsTask.kt (简化逻辑)
@TaskAction
fun taskAction() {
 // 收集所有 so 文件 (主模块 + AAR)
 val nativeLibs = collectNativeLibs()
 
 // 获取 ABI 过滤配置
 val abiFilters = variantData.ndkConfig.abiFilters
 
 nativeLibs.forEach { (abi, soFiles) ->
 // 只处理配置中允许的 ABI
 if (abiFilters.isEmpty() || abiFilters.contains(abi)) {
 soFiles.forEach { soFile ->
 // 复制到对应的 ABI 目录
 val destFile = outputDir.resolve("lib/$abi/${soFile.name}")
 soFile.copyTo(destFile, overwrite = true)
 }
 }
 // 不在过滤列表中的 ABI 直接丢弃
 }
}

例如,如果你在 build.gradle 中配置:

1
2
3
4
5
6
7


android {
 defaultConfig {
 ndk {
 abiFilters 'arm64-v8a', 'armeabi-v7a'
 }
 }
}

那么 x86、x86_64 的 so 文件会被直接丢弃。

最终输出结构:

1
2
3
4
5
6
7


lib/
 ├── arm64-v8a/
 │ ├── libxxx.so
 │ └── libyyy.so
 └── armeabi-v7a/
 ├── libxxx.so
 └── libyyy.so

6. R.txt → 参与资源链接 #

AAR 中的 R.txt 记录了库内所有资源的名称、类型和在该库中的资源 ID。

格式示例:

1
2
3


int string app_name 0x7f120001
int layout activity_main 0x7f0d0025
int drawable icon 0x7f080003

资源 ID 格式说明 (0xPPTTEEEE):

资源 ID 是 32 位整数,由三部分组成:

PP (Package ID) : 应用资源包 ID
- 0x7f = 应用资源
- 0x01 = 系统资源 (android.R.*)
TT (Type ID) : 资源类型 ID
- 0x02 = drawable
- 0x0d = layout
- 0x12 = string
- 等等
EEEE (Entry ID) : 该类型下的资源条目 ID (16 位,可表示 65536 个资源)

例如 0x7f0d0025:

0x7f = 应用资源包
0x0d = layout 类型
0x0025 = 该 layout 类型下的第 37 号资源

重要: 这些 ID 只在库自己的构建中有效,当库被集成到主工程时,所有 ID 会被 aapt2 link 重新分配。

这个文件在 aapt2 link 阶段被使用:

处理位置:

1

tools/aapt2/link/

参与生成:

R.jar: 最终的 R class,包含所有资源 ID
resources.arsc: 资源索引表中的符号信息

基本流程:

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


// aapt2 link 中读取 R.txt (简化逻辑)
std::vector<ResourceTable> librarySymbols;
for (const std::string& rtxtPath : libraryRTxtFiles) {
 // 解析 R.txt,提取资源名称和类型信息
 // 原有的 ID 值会被忽略,稍后重新分配
 ResourceTable table = ParseRTxt(rtxtPath);
 librarySymbols.push_back(std::move(table));
}

// 合并所有符号,分配统一的新 ID
MergeSymbols(librarySymbols, &finalTable);
AssignNewIds(&finalTable);

7. lint.jar → Lint 检查 #

AAR 中的 lint.jar 包含自定义的 Lint 检查规则。

使用场景:

库作者可以在 AAR 中打包自己的 Lint 规则,确保使用者正确使用该库的 API。

处理位置:

1

tools/base/lint/

Task 类: AndroidLintTask

这些 lint.jar 会在代码检查阶段被加载:

1
2
3
4
5
6


// Lint 检查时加载 AAR 的自定义规则 (简化逻辑)
List<File> lintJars = collectLintJarsFromAars();
LintClient client = new LintClient();
for (File lintJar : lintJars) {
 client.addLintRules(lintJar);
}

实际案例:

例如,Jetpack Compose 的 AAR 中就包含 lint.jar,用于检查:

不正确的 Composable 函数命名 (必须以大写字母开头)
状态管理最佳实践 (remember、rememberSaveable 的使用)
性能相关的建议 (避免在 Composition 中进行耗时操作)

全链路流程图 (源码版) #

为什么 AAR 必须被解包? #

你可能会问: 为什么不直接把 AAR 塞进 APK?

因为 APK 的结构是固定的:

dex: 所有代码必须合并成统一的字节码
resources.arsc: 所有资源必须有统一的 ID 映射表
AndroidManifest.xml: 只能有一个最终的 manifest

而 AAR 是"源码级别"的打包格式,它的存在是为了:

方便分发 (不用发源码)
包含完整信息 (代码 + 资源 + manifest + so + lint 规则)
保持模块化 (每个库独立构建)

但构建 APK 时,这些信息必须"扁平化"成 APK 的标准结构。

所以 AAR 必须被解包,没有其他选择。

实际案例: RecyclerView AAR 的解包 #

以 androidx.recyclerview:recyclerview:1.3.2 为例:

AAR 大小: 约 350 KB

解包后内容:

1
2
3
4
5
6
7
8
9


classes.jar → 280 KB (包含所有 RecyclerView 相关类)
AndroidManifest.xml → 1 KB (声明最低 API 等基本信息)
R.txt → 5 KB (约 100+ 个资源符号)
res/
 ├── values/
 │ ├── attrs.xml (自定义属性定义)
 │ └── public.xml (公开的资源 ID)
 └── layout/ (无,RecyclerView 无内置 layout)
proguard.txt → 2 KB (保持规则,防止混淆关键类)

构建后流向:

classes.jar → 经过 R8 混淆优化 → 合并到 classes.dex
AndroidManifest.xml → 合并到主 manifest (贡献了 minSdkVersion 约束)
res/values/attrs.xml → 编译到 resources.arsc
R.txt → 参与资源链接,生成新的资源 ID
proguard.txt → 确保 RecyclerView.LayoutManager 等关键类不被混淆

最终 APK 中:

代码大小: 约 180 KB (混淆优化后)
资源增量: 约 3 KB (attrs 定义)

关键技术细节总结 #

资源 ID 的重新分配 #

很多人误以为 AAR 的资源 ID 会保留,实际上:

AAR 中的 R.txt 记录的 ID (如 0x7f120001) 只在该库构建时有效
集成到主工程时,aapt2 link 会完全重新分配所有 ID
最终每个资源得到一个全局唯一的新 ID
这就是为什么你不能硬编码资源 ID 的根本原因

示例:

1
2
3
4
5
6


// 错误做法 - 永远不要这样写!
int errorId = 0x7f120001; // 这个 ID 在不同构建中会变化
textView.setText(errorId);

// 正确做法
textView.setText(R.string.app_name); // 编译时会替换为实际 ID

混淆规则的收集 #

所有 AAR 的 proguard.txt 会被收集并应用:

1
2
3
4
5
6


主模块 proguard-rules.pro
+ AAR1 proguard.txt
+ AAR2 proguard.txt
+ ...
→ 合并后的完整混淆规则
→ 传递给 R8

这确保了库的 API 不会被错误混淆。

示例 (RecyclerView 的 proguard.txt):

1
2
3
4
5
6
7
8
9


# 保持 LayoutManager 及其子类不被混淆
-keep public class * extends androidx.recyclerview.widget.RecyclerView$LayoutManager {
 public <init>(...);
}

# 保持 ViewHolder 不被混淆
-keep public class * extends androidx.recyclerview.widget.RecyclerView$ViewHolder {
 public <init>(...);
}

Manifest 合并的冲突解决 #

当多个 manifest 声明冲突时:

优先级高的覆盖低的 (主模块 > buildType > flavor > 依赖)
可以使用 tools:replace、tools:merge、tools:remove 等标记控制策略
构建时会生成详细的合并报告 (位于 build/outputs/logs/manifest-merger-*.txt)

常见冲突示例:

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


<!-- 主模块 manifest -->
<application
 android:theme="@style/AppTheme"
 tools:replace="android:theme"> <!-- 强制覆盖库的 theme -->
 ...
</application>

<!-- AAR manifest -->
<application
 android:theme="@style/LibraryTheme">
 ...
</application>

<!-- 最终结果: 使用 AppTheme -->

传递依赖的处理 #

当依赖关系为 App → AAR1 → AAR2 时:

依赖解析: Gradle 首先解析整个依赖图,确定所有需要的 AAR
版本冲突: 如果 AAR1 依赖 AAR2:1.0,主模块直接依赖 AAR2:2.0,默认选择 2.0 (最近优先)
资源合并: 所有 AAR 的资源一起参与 aapt2 link,按优先级合并
代码合并: 所有 AAR 的 classes.jar 一起传递给 R8/D8

依赖冲突解决策略:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


dependencies {
 implementation 'com.example:aar1:1.0' // 内部依赖 aar2:1.0
 implementation 'com.example:aar2:2.0' // 直接依赖,优先级更高
 
 // 如果要强制使用特定版本
 implementation('com.example:aar1:1.0') {
 exclude group: 'com.example', module: 'aar2' // 排除传递依赖
 }
 implementation 'com.example:aar2:1.5' // 手动指定版本
}

总结: AAR 的命运只有一个——被解包 #

构建系统不需要"一个 AAR 文件”,它需要的只是:

里面的 class → 转成 dex
manifest → 合并到主 manifest
res → 编译后合并到 resources.arsc,资源 ID 重新分配
assets → 直接复制
so → 按 ABI 过滤后复制
R.txt → 参与资源链接,生成最终 R class
proguard.txt → 参与代码混淆
lint.jar → 提供自定义检查规则

所以 AAR 一进入系统就被解包,碎片分别走向不同的处理链,最后散落在:

classes.dex (代码)
resources.arsc (资源索引)
AndroidManifest.xml (配置)
assets/ (原始文件)
lib/ (native 库)

AAR 自己不可能出现在 APK 内部。

这,就是它的全部生命周期。

附录: AGP 版本差异说明 #

本文基于 AGP 7.x-8.x 源码分析,不同版本的主要差异:

特性	AGP 7.x	AGP 8.0+
Transform API	旧版 Transform API	新的 Artifact Transform API
R.java 编译	独立的 CompileRFilesTask	整合到主编译流程
资源处理	基于 AAPT2	同样基于 AAPT2,优化了增量编译
依赖解析	Configuration API	同样,但增加了类型安全的 API
Task 类名	MergeNativeLibs	MergeNativeLibsTask (名称统一化)

核心流程保持一致,主要是 API 和性能优化上的改进。

源码版本说明:

本文基于 Android Gradle Plugin (AGP) 7.x-8.x 源码分析,路径均来自:

1

https://android.googlesource.com/platform/tools/base/

不同 AGP 版本细节可能略有差异 (如 Task 类名、API 调用方式),但整体流程保持一致。AGP 8.0+ 引入了新的 Artifact Transform API,但 AAR 解包的本质流程未变。

命名的艺术：从驼峰到蛇形

Wed, 05 Nov 2025 21:37:44 +0800

不同编程语言往往有不同的命名约定。Java、Python、C++ 各自形成了独特的命名文化。许多重构类书籍在讲解前都会先强调命名，因为命名绝不是一件简单的事。好的命名要能准确传达含义，让人一眼就能看出变量或函数的用途。这些命名方式的共同目标，都是为了增强可读性——让名字更像语言，而不是符号。

驼峰命名法（Camel Case） #

我最熟悉的语言是 Java，而 Java 最常见的命名方式就是驼峰命名（camel case）。在这种方式中，单词连接处用大写字母标识，其他字母保持小写。例如 firstName。Java 中一般不会使用下划线 _ 来分隔单词。

“驼峰式大小写（Camel-Case）一词来自 Perl 语言中普遍使用的大小写混合格式，而 Larry Wall 等人所著的《Programming Perl》（O’Reilly 出版）的封面是一匹骆驼，因此得名。”

—— 维基百科 · 驼峰大小写

在 Java、Kotlin、Rust、Go、C++、Python 等语言中，成员变量和局部变量通常都会使用这种命名方式。

帕斯卡命名法（Pascal Case） #

帕斯卡命名法可以看作驼峰命名法的一种变体。不同之处在于：首字母也大写。例如 MyClass。在 Java 和 Kotlin 中，类名、接口名、文件名通常使用帕斯卡命名法。

蛇形命名法（Snake Case） #

蛇形命名法（snake case），也称“下划线命名法”。单词之间用下划线 _ 分隔。

有两种变体：

全大写：常用于常量，例如 MAX_VALUE、MY_NAME。这种写法在 Java、Kotlin、Rust、Python 中都很常见，C++ 的宏定义也沿用这种风格。
全小写：用于变量或函数名，尤其在 Python、Rust、C 语言中广泛使用，如 file_name、get_value。

一般来说，现代主流语言不会同时混用大小写与下划线分隔——那样既冗余又影响美观。

烤串命名法（Kebab Case） #

烤串命名法（kebab case） 使用小写字母并以短横线 - 连接，例如：css-class-name。这种命名方式在前端开发中非常常见，尤其是 CSS 的类名或 HTML 属性名中。

匈牙利命名法（Hungarian Notation） #

匈牙利命名法（Hungarian notation） 是一种历史悠久、但如今较少使用的命名方式。在 Java 时代，仍能看到有人使用，比如 mField、sInstance。其规则是在名称前添加小写前缀，用以标识变量的类型或用途。例如：

m 表示成员变量（member）
s 表示静态变量（static）

根据用途不同，它分为两种：

系统匈牙利命名法：源自早期的 BCPL 语言。当时语言层面不区分类型，于是开发者用前缀手动标注类型。
应用匈牙利命名法：后来演变为用前缀表示语义用途，而非类型，如 mField 表示“成员字段”。

虽然这种方式在现代语言中已不再主流，但在老项目、甚至部分 Android 代码中依然能见到其痕迹。

小结 #

无论是驼峰、蛇形还是烤串，这些命名方式的核心目标始终一致——让代码更易读、更易懂。命名不仅是语法规则，更是沟通的语言。它连接着人和代码，也反映着语言设计的美学。

参考资料：

函数与方法：一个容易被忽视的编程概念差异

Thu, 30 Oct 2025 21:16:42 +0800

从学习C语言接触计算机开始，我总以为函数和方法不过是两个不同的名称而已，只不过是习惯不同。直到阅读Rust语言的文档时，同时出现了"方法"和"函数"两个术语，我才意识到这其中的差异。

事实上，它们不能说是两个完全不同的概念，但确实存在区别。

什么是方法(Method) #

在面向对象编程中，方法（英语：Method；德语：Methode；法语：Méthode）指的是属于类别（所谓的类方法、静态方法或工厂方法）或者对象（所谓的实例方法）的子程序。如同过程化程序设计的程序，一个方法通常由一系列语句组成，并以此完成一个动作。它可以通过输入一组参数来指定所需的动作，且部分方法可能会有输出值（所谓的返回值）。方法的目的是提供一个机制，以访问（读取和写入）对象或类别的私有数据。

参考：Wikipedia - Method (computer programming)

函数与方法的区别 #

Wikipedia关于函数的条目中有这样一段描述：

Some programming languages, such as COBOL and BASIC, make a distinction between functions that return a value (typically called “functions”) and those that do not (typically called “subprogram”, “subroutine”, or “procedure”); some, such as C, C++, and Rust, only use the term “function” irrespective of whether they return a value or not; others, such as ALGOL 60 and PL/I, only use the word procedure. Some object-oriented languages, such as Java and C#, refer to functions inside classes as “methods”.

参考：Wikipedia - Function (computer programming)

如果你去搜索相关讨论，会发现基本能形成的共识是：定义在类内部的称为Method（方法），定义在类外部的称为Function（函数）。

各语言中的实践 #

理解了这个理论后，我们再来看各种语言的实现就清晰多了。

Java #

Java中所有的"函数"都必须定义在类中，无论是成员方法还是静态方法，因此统一称为方法。

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


public class Calculator {
 private int offset = 0;
 
 // 实例方法
 public int add(int a, int b) {
 return a + b + offset;
 }
 
 // 静态方法
 public static int multiply(int a, int b) {
 return a * b;
 }
}

// 使用
Calculator calc = new Calculator();
calc.add(1, 2); // 调用实例方法
Calculator.multiply(3, 4); // 调用静态方法

Kotlin #

Kotlin既可以像Java一样在类内部定义，这些被称为方法；也可以定义在类的外部，因此扩展函数被称为"扩展函数"，而不是"扩展方法"。

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


// 顶层函数
fun add(a: Int, b: Int): Int {
 return a + b
}

class Calculator(private var offset: Int = 0) {
 // 成员方法
 fun add(a: Int, b: Int): Int {
 return a + b + offset
 }
}

// 扩展函数（注意是"函数"不是"方法"）
fun Calculator.subtract(a: Int, b: Int): Int {
 return a - b
}

C++ #

C++同时支持函数和方法，但在术语上都统称为"function"。

函数(Function)：定义在类外部的独立函数

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


// 全局函数
int add(int a, int b) {
 return a + b;
}

// 命名空间中的函数
namespace Math {
 int multiply(int a, int b) {
 return a * b;
 }
}

方法(Method)：定义在类内部的成员函数

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


class Calculator {
public:
 // 实例方法（成员函数）
 int add(int a, int b) {
 return a + b + offset;
 }
 
 // 静态方法
 static int multiply(int a, int b) {
 return a * b;
 }
 
private:
 int offset = 0;
};

// 使用
Calculator calc;
calc.add(1, 2); // 调用实例方法
Calculator::multiply(3, 4); // 调用静态方法

Go #

Go语言明确区分函数和方法的概念。

函数(Function)：独立定义的函数

1
2
3
4
5
6
7
8


// 包级别函数
func Add(a, b int) int {
 return a + b
}

func main() {
 result := Add(1, 2)
}

方法(Method)：绑定到特定类型的函数（通过接收者receiver定义）

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


type Calculator struct {
 offset int
}

// 值接收者方法
func (c Calculator) Add(a, b int) int {
 return a + b + c.offset
}

// 指针接收者方法
func (c *Calculator) SetOffset(offset int) {
 c.offset = offset
}

// 使用
calc := Calculator{offset: 10}
calc.Add(1, 2) // 调用方法
calc.SetOffset(20) // 调用方法

Rust #

Rust也明确区分函数和方法，这也是最初让我意识到这个差异的语言。

函数(Function)：独立定义的自由函数

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


// 自由函数(free function)
fn add(a: i32, b: i32) -> i32 {
 a + b
}

// 模块中的函数
mod math {
 pub fn multiply(a: i32, b: i32) -> i32 {
 a * b
 }
}

方法(Method)：在impl块中为类型定义的函数

 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


struct Calculator {
 offset: i32,
}

impl Calculator {
 // 关联函数(Associated Function) - 类似静态方法，没有self参数
 fn new(offset: i32) -> Self {
 Calculator { offset }
 }
 
 // 实例方法 - 带有self参数
 fn add(&self, a: i32, b: i32) -> i32 {
 a + b + self.offset
 }
 
 // 可变引用方法
 fn set_offset(&mut self, offset: i32) {
 self.offset = offset;
 }
}

// 使用
let mut calc = Calculator::new(10); // 调用关联函数
calc.add(1, 2); // 调用实例方法
calc.set_offset(20); // 调用可变方法

总结 #

语言	函数(Function)	方法(Method)	特点
Java	不存在	所有都是方法	必须定义在类中
Kotlin	顶层函数、扩展函数	类成员方法	同时支持两者
C++	全局函数、命名空间函数	类成员函数	术语上都称为function
Go	包级别函数	带接收者的函数	明确区分，方法必须有receiver
Rust	自由函数、模块函数	impl块中的函数	明确区分，有self的是方法，无self的是关联函数

核心区别其实很简单：方法(Method)与类型/对象绑定，函数(Function)独立存在。

Android依赖管理解析：从ext到 Version Catalog的演进

Thu, 23 Oct 2025 20:55:28 +0800

在 Android 多模块项目中，依赖管理（Dependency Management）往往被低估。最开始你可能只是写几个 implementation "xxx:xxx:1.0.0"，但随着模块数量增长、团队协作增加、版本升级频繁，依赖的统一管理会直接影响项目的可维护性与构建效率。

目前常见的几种依赖管理方式包括：

最普通的直接写依赖；
ext 属性集中定义；
使用 buildSrc 代码模块；
使用 Gradle 7+ 的版本目录（Version Catalog）。

下面我们从示例、优势与不足的角度，依次剖析这些方案。

直接写依赖 #

最朴素的方式是把依赖写在每个模块的 build.gradle 中。

1
2
3
4
5
6


dependencies {
 implementation("androidx.core:core-ktx:1.10.1")
 implementation("com.squareup.retrofit2:retrofit:2.9.0")
 implementation("com.squareup.okhttp3:logging-interceptor:5.0.0-alpha.2")
 testImplementation("junit:junit:4.13.2")
}

优势

简单直接，几乎不需要学习成本。
适合小型或一次性项目。
所有依赖可一眼看清楚。

不足

多模块时容易重复定义。
升级版本需要全局修改，容易漏。
难以审查依赖一致性。
无法实现全局统一管理。

这种方式适合 Demo 或临时项目，一旦模块数超过三个，就会让人后悔没早点集中管理。

使用 `ext` 属性集中管理 #

在根 build.gradle 中用 ext 定义变量：

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


ext {
 versions = [
 coreKtx: "1.10.1",
 retrofit: "2.9.0",
 okhttpLogging: "5.0.0-alpha.2",
 junit: "4.13.2"
 ]

 libs = [
 coreKtx: "androidx.core:core-ktx:${versions.coreKtx}",
 retrofit: "com.squareup.retrofit2:retrofit:${versions.retrofit}",
 okhttpLogging: "com.squareup.okhttp3:logging-interceptor:${versions.okhttpLogging}",
 junit: "junit:junit:${versions.junit}"
 ]
}

在子模块中这样使用：

1
2
3
4


dependencies {
 implementation libs.coreKtx
 implementation libs.retrofit
}

优势

集中管理版本号与依赖坐标。
易于迁移、上手成本低。
小中型项目的过渡方案。

不足

仍然缺乏类型安全与自动提示。
配置多了容易混乱。
修改根配置会触发子项目重新评估，影响构建速度。
难以管理插件或 bundle。

ext 是一种“权宜之计”：比纯手写好一点，但距离真正的现代依赖管理还差几步。

使用 `buildSrc` 模块 #

在根目录下创建 buildSrc 目录，Gradle 会自动编译并加载其中代码。可以在这里定义依赖与版本常量。

buildSrc/src/main/kotlin/Dependencies.kt：

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


object Versions {
 const val coreKtx = "1.10.1"
 const val retrofit = "2.9.0"
 const val okhttpLogging = "5.0.0-alpha.2"
 const val junit = "4.13.2"
}

object Libs {
 const val coreKtx = "androidx.core:core-ktx:${Versions.coreKtx}"
 const val retrofit = "com.squareup.retrofit2:retrofit:${Versions.retrofit}"
 const val okhttpLogging = "com.squareup.okhttp3:logging-interceptor:${Versions.okhttpLogging}"
 const val junit = "junit:junit:${Versions.junit}"
}

在模块中使用：

1
2
3
4


dependencies {
 implementation(Libs.retrofit)
 implementation(Libs.okhttpLogging)
}

优势

类型安全、IDE 自动补全。
可以定义插件、扩展函数等构建逻辑。
依赖集中、可复用性强。
适合中大型项目，特别是多团队协作。

不足

修改 buildSrc 会强制重新编译整个项目。
对构建时间有一定影响。
学习与维护成本更高。
对于仅做依赖管理来说略显“重量级”。

buildSrc 是“工程师式”的方案，强大、灵活，但稍有过度设计风险。

使用版本目录（Version Catalog） #

Gradle 7.0 起推荐使用的现代方案。在 gradle/libs.versions.toml 中集中声明所有依赖。

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


[versions]
coreKtx = "1.10.1"
retrofit = "2.9.0"
okhttpLogging = "5.0.0-alpha.2"
junit = "4.13.2"

[libraries]
androidx-core-ktx = { group = "androidx.core", name = "core-ktx", version.ref = "coreKtx" }
retrofit = { group = "com.squareup.retrofit2", name = "retrofit", version.ref = "retrofit" }
okhttp-logging-interceptor = { group = "com.squareup.okhttp3", name = "logging-interceptor", version.ref = "okhttpLogging" }
junit = { group = "junit", name = "junit", version.ref = "junit" }

[bundles]
network = ["retrofit", "okhttp-logging-interceptor"]

在模块中直接使用：

1
2
3
4
5


dependencies {
 implementation(libs.androidx.core.ktx)
 implementation(libs.retrofit)
 implementation(libs.okhttp.logging.interceptor)
}

优势

版本与依赖完全集中。
IDE 自动提示强、语法简洁。
不会触发全项目重编译。
支持 bundle、plugin、version alias 等现代特性。
官方推荐、未来趋势明确。

不足

迁移成本高，需要调整依赖引用方式。
无法直接在 buildSrc 中使用。
对团队约定要求较高（别名统一、文件管理规范）。
对于简单项目可能显得过度。

Version Catalog 已成为新标准，兼顾类型安全、性能与可维护性。

对比与建议 #

方式	学习成本	版本集中度	类型安全	构建性能	适用场景
直接写依赖	最低	★	无	优	Demo、小项目
`ext`	低	★★	弱	良	中小项目
`buildSrc`	中	★★★	强	一般	中大型项目
Version Catalog	中等	★★★★★	强	最优	大型、多团队项目

建议：

新项目建议直接上 Version Catalog。
已有项目可从 ext 或 buildSrc 逐步迁移。
对于大型项目，可混合使用：Version Catalog 管理版本号，buildSrc 管理构建逻辑。
无论哪种方式，都应建立“依赖声明规范”，禁止模块私自引入未注册依赖。

结语 #

依赖管理是 Android 工程化的地基之一。当项目规模上升、团队扩大、构建频率增加，越早建立清晰、集中、可扩展的依赖管理体系，就越能避免未来的混乱。选择哪种方式取决于项目规模与团队成熟度，但如果你打算长期维护一个 Android 应用，那就别犹豫——从 Version Catalog 开始。

一次 Android APK 体积优化实录

Wed, 22 Oct 2025 21:48:06 +0800

现状及问题 #

最近工作上有些变动，新接手的项目中发现 apk 的 Debug 包有 170 多 MB，Release 包也要 140 MB。仔细看项目内容，其实并没有那么多东西。想要减小体积，首先得搞清楚从哪里下手，于是决定先分析一下应用的体积构成。

分析 #

将打包后的 apk 拖到 Android Studio 里，就能看到各部分的体积占比。

ABI #

lib 的体积挺惊人，占了 92.9MB。这个目录是放 native 库的，来源通常有两种：

自己写的 native 代码（为了性能、安全或通用性）；
第三方库自带的 native 文件。

第三方库为了支持更多设备，会同时包含多个 ABI。先从这里下手，初步猜测是没过滤 ABI。

果然，ABI 支持得很全，连不用的都打进去了。

ABI（Application Binary Interface）指的是“应用二进制接口”，也就是应用（或其原生库）与系统或其他模块在二进制层面所遵循的规则，比如指令集、函数调用约定、数据对齐、库格式、命名修饰（mangling）等。简单来说，ABI 就是 CPU 支持的指令集。

ABI 名称	架构 / 指令集	状态说明
`armeabi`	ARMv5（32 位）	早期架构，NDK r17 起已废弃。
`armeabi-v7a`	ARMv7（32 位） + Thumb-2 + NEON	早期主流架构，现已逐步淘汰。
`arm64-v8a`	ARMv8（64 位）	当前主流，Google Play 要求支持。
`x86`	Intel/AMD 32 位	市场占比极低，仅部分设备或模拟器使用。
`x86_64`	Intel/AMD 64 位	同上，主要用于模拟器。
`mips`,`mips64`	MIPS 架构	曾支持，现已移除。

当前架构情况（2025） #

ARMv8-A（64 位）
- ABI：arm64-v8a
- 市场占比超过 90%
- 特点：支持 AArch64/AArch32 双指令集，兼容性好
- 代表芯片：骁龙 8 Gen4、天玑 9400、Exynos 2400
ARMv7-A（32 位）
- ABI：armeabi-v7a
- 适用：老旧中低端设备（2015–2020）
- 现状：新机基本不再使用，仅残留于部分 IoT 设备
x86 / x86_64
- 主要用于安卓模拟器和少量平板
- 市场占比低于 3%

当前手机基本都是 64 位 ARM 架构，许多 armv8 设备都已经卡得不行，更不用说更早的 armv7。过滤 ABI 很简单，在模块级 gradle 中加上：

1

abiFilters 'arm64-v8a'

省掉了 66.86MB。

资源 #

第二大块体积来自资源。 Android 资源包含：图片、布局、字体、字符串、颜色、属性。打包时通常会开启 isShrinkResources 去掉未使用资源，但正在使用的图片仍然会占据相当大空间。

图片体积往往以 MB 计，尤其是大尺寸 PNG。常见格式有：

PNG：无损压缩，清晰但体积大；
JPG：有损压缩，体积小但容易模糊；
WebP：压缩率更高，但存在兼容性顾虑。

几种优化方式 #

算法压缩（TinyPNG、pngquant 等） 不影响质量，能显著减小体积。
降低质量 减小体积，但大图可能会糊。
改用 WebP 压缩率高，但部分旧系统仍有兼容风险。

三种方式中，第一种几乎没有副作用。综合稳定性和收益，我选择了算法压缩。

我用 TinyPNG 来处理图片。它的效果不错，但免费账号有调用限制，只能一次次通过网页上传压缩。

压缩前后效果对比：

从 32.5MB 缩减至 16.9MB，缩减 48% 。

代码 #

代码层面最常见的方式是混淆。混淆不仅能减小体积，也能提高反编译难度，可谓一举两得。

配置也很简单：

1

isMinifyEnabled true

大多数项目都会默认开启，这里不再赘述。

实操 #

当前阶段的优化主要是：

过滤 ABI，只保留 arm64-v8a；
图片压缩；
确认开启代码混淆。

这些操作后，应用从 140.3MB → 58.3MB，整体缩减 58% ，效果明显。

回顾 #

上面这些是最基础、最常规的优化，不需要额外依赖，也不会影响功能。除此之外，还可以考虑以下两种更深入的做法：

资源动态下发 除启动图、占位图、错误图外，其他资源可由服务端下发。优点是包更轻，缺点是首启依赖网络。
插件化 / 模块拆分 只保留首页等必要模块，把购买、订单、播放等拆成独立 apk 以插件形式按需下载。效果好，但工程量大。

防劣 #

ABI 配置一般不会变，但图片最容易劣化。随着业务迭代，不断有新图片被引入。为了防止包体积回涨，最好不要依赖人工检查，而是让持续集成自动化完成。

可以这样做：

构建阶段批量压缩图片；
只处理新增文件（或将压缩文件直接提交到 Git 仓库）；
定期记录包体积，若超过阈值（例如 +5MB）则触发警告。

这样既能保证体积稳定，又不会明显增加构建时间。

理解 Kotlin Flow：冷热流与背压处理

Thu, 16 Oct 2025 07:32:28 +0800

使用场景 #

1. 持续输出数据（如定时器、进度条） #

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


fun timerFlow(): Flow<Int> = flow {
 for (i in 1..5) {
 delay(1000)
 emit(i) // 每秒发出一个进度
 }
}

fun main() = runBlocking {
 timerFlow()
 .onEach { println("Progress: $it/5") }
 .onCompletion { println("Done!") }
 .collect()
}

// 输出：
// Progress: 1/5
// Progress: 2/5
// Progress: 3/5
// Progress: 4/5
// Progress: 5/5
// Done!

2. 在不同线程中执行 #

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


fun fetchData(): Flow<String> = flow {
 println("Running in thread: ${Thread.currentThread().name}")
 delay(1000)
 emit("Data from network")
}.flowOn(Dispatchers.IO) // 在 IO 线程执行

fun main() = runBlocking {
 fetchData()
 .onEach { println("Collect on thread: ${Thread.currentThread().name}") }
 .collect { println("Received: $it") }
}

// 输出：
// Running in thread: DefaultDispatcher-worker-1
// Collect on thread: main
// Received: Data from network

3. 合并多个异步请求 #

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


fun getUser(): Flow<String> = flow {
 delay(500)
 emit("User: Alice")
}

fun getMessagesCount(): Flow<Int> = flow {
 delay(800)
 emit(42)
}

fun main() = runBlocking {
 combine(getUser(), getMessagesCount()) { user, count ->
 "$user, Unread messages: $count"
 }.collect { println(it) }
}

// 输出：
// User: Alice, Unread messages: 42

这些特性让人想起了 RxJava…

冷热流 #

Flow 官方文档中区分为冷流和热流两种类型，指的是数据的发送特性。

类型	生活类比	特征
冷流 (Cold Flow)	点外卖：每次点餐，餐厅才开始做菜	每次订阅（collect）都会重新触发一次数据生产
热流 (Hot Flow)	看直播：主播持续直播，新进来的观众只能看到当前及之后的内容	数据持续发送，不会重放过去的数据

另一个比喻是将 Flow 看作一条传送带：冷流是按需求启动传送，将所有商品传送给你；热流则是始终在运行，你只能捕获你到达时之后的商品。

实现原理 #

Flow 的基础接口 #

Flow 是一个接口，只定义了一个方法用于收集数据。FlowCollector 负责发送数据：

1
2
3
4
5
6
7
8
9


// Flow.kt
public interface Flow<out T> {
 public suspend fun collect(collector: FlowCollector<T>)
}

// FlowCollector.kt
public fun interface FlowCollector<in T> {
 public suspend fun emit(value: T)
}

冷流的执行流程 #

以下面的代码为例：

1
2
3
4
5


CoroutineScope(Job()).launch {
 flowOf(1, 2, 3).collect {
 print(it)
 }
}

冷流的发送分为两个步骤：定义数据生产逻辑，然后触发数据收集。

代码实际上执行了 unsafeFlow 方法：

1
2
3
4
5
6
7
8
9


internal inline fun <T> unsafeFlow(
 @BuilderInference crossinline block: suspend FlowCollector<T>.() -> Unit
): Flow<T> {
 return object : Flow<T> {
 override suspend fun collect(collector: FlowCollector<T>) {
 collector.block()
 }
 }
}

其核心逻辑是：使用 FlowCollector 执行外部传入的 block。FlowCollector 来自哪里？正是 collect() 方法参数传入的对象。由于 FlowCollector 是函数式接口，可以直接写成 collect { ... } 的形式。

小结：冷流先定义要让某个 FlowCollector 做什么事，再通过 collect() 找到具体执行者。这就是为什么只有调用 collect() 才会收集到所有数据。

热流：SharedFlow 和 StateFlow #

热流包括 StateFlow 和 SharedFlow 两种，其中 StateFlow 是 SharedFlow 的子类。不妨先理解 SharedFlow，再看 StateFlow 会更清晰。

热流的特点是持续发送数据，不关心是否有订阅者。示例如下：

 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


runBlocking {
 // 创建一个 SharedFlow，支持多个订阅者
 val eventFlow = MutableSharedFlow<String>()

 // 启动两个收集者
 launch {
 eventFlow.collect { value ->
 println("收集者A 收到事件：$value")
 }
 }

 launch {
 eventFlow.collect { value ->
 println("收集者B 收到事件：$value")
 }
 }

 // 模拟发送事件
 delay(100)
 eventFlow.emit("用户点击按钮")
 eventFlow.emit("加载完成")

 delay(500)
}

// 输出：
// 收集者A 收到事件：用户点击按钮
// 收集者B 收到事件：用户点击按钮
// 收集者A 收到事件：加载完成
// 收集者B 收到事件：加载完成

所有订阅者都会收到消息。默认情况下不会保留历史值，除非创建 SharedFlow 时设置了 replay 参数，将上一个值和最新值先后发送。

缓冲溢出处理 #

SharedFlow 内部实现了缓冲机制，通过 replay 参数控制缓存容量。当缓冲区满时，通过 BufferOverflow 枚举决定处理策略：

SUSPEND：挂起等待直到有消费者处理缓冲区数据
DROP_OLDEST：丢弃最早的数据
DROP_LATEST：丢弃最新的数据

emit 发送流程 #

SharedFlow 的数据发送分为两个主要阶段：快速通道和常规通道。

快速通道 #

 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


private fun tryEmitLocked(value: T): Boolean {
 // 快速路径：无订阅者 -> 无需缓冲
 if (nCollectors == 0) return tryEmitNoCollectorsLocked(value)
 
 // 有订阅者，需要检查缓冲区
 if (bufferSize >= bufferCapacity && minCollectorIndex <= replayIndex) {
 when (onBufferOverflow) {
 BufferOverflow.SUSPEND -> return false // 需要挂起
 BufferOverflow.DROP_LATEST -> return true // 丢弃新值
 BufferOverflow.DROP_OLDEST -> {} // 强制加入队列并丢弃旧值
 }
 }
 
 enqueueLocked(value)
 bufferSize++ // 值已加入缓冲区
 
 // 如果缓冲区超过容量，删除最旧的值
 if (bufferSize > bufferCapacity) dropOldestLocked()
 
 // 保持 replaySize 不超过必要值
 if (replaySize > replay) {
 updateBufferLocked(replayIndex + 1, minCollectorIndex, bufferEndIndex, queueEndIndex)
 }
 
 return true
}

快速通道的条件包括：

无订阅者：只需更新缓冲区，无需发送数据
有订阅者：
- 缓冲区未满：直接加入队列
- 缓冲区已满且有未处理数据：
  - DROP_LATEST 策略：直接丢弃新值
  - DROP_OLDEST 策略：新值加入，旧值被丢弃

常规通道（挂起等待） #

当无法走快速通道（缓冲区满且策略为 SUSPEND）时，系统会：

再次检查是否满足快速通道条件
若仍不满足，将发送操作封装为 CancellableContinuation
通过协程状态机机制，待订阅者消费后唤醒该操作

collect 收集流程 #

collect() 时会将每个订阅者封装成 AbstractSharedFlowSlot。Slot 记录：

订阅者的 Continuation（协程中断点）
当前收集到的缓冲数据索引

执行流程如下：

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


collect()
│
├─ allocateSlot() // 为当前订阅者分配 slot，跟踪其读取进度
│
├─ 无限循环处理数据：
│ ├─ tryTakeValue(slot) // 尝试快速取值（非阻塞）
│ │ ├─ 缓冲区有新值 → 立即返回该值
│ │ └─ 缓冲区无新值 → awaitValue(slot) 挂起等待
│ │
│ ├─ ensureActive() // 检查协程是否被取消
│ └─ emit(value) // 将值发送给下游
│
└─ finally → freeSlot() // 收集完成或异常时释放 slot

StateFlow #

StateFlow 是 SharedFlow 的特殊版本，主要区别：

增加了 value 属性存储当前状态
禁止修改 replay 参数，只能缓存一个值
内部逻辑简化为纯粹的状态更新

每次调用 emit() 都会触发状态更新，订阅者同样被封装成 slot。状态更新通过 CAS（Compare-And-Set）原子操作实现：

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


fun makePending() {
 _state.loop { state ->
 when {
 state == null -> return // slot 已释放，跳过
 state === PENDING -> return // 已标记为待发送，无需操作
 state === NONE -> { // 标记为待发送
 if (_state.compareAndSet(state, PENDING)) return
 }
 else -> { // slot 中存储着挂起的 Continuation
 if (_state.compareAndSet(state, NONE)) {
 (state as CancellableContinuationImpl<Unit>).resume(Unit)
 return
 }
 }
 }
 }
}

StateFlow 的 collect() 比 SharedFlow 简化，因为只需处理单个值的更新，无需考虑 replay 机制。

背压（Backpressure） #

背压是什么 #

“背压”指的是上游发射数据的速度超过下游处理能力导致的积压问题。在 Flow 中，背压常见于：

热流：数据持续产生，下游来不及消费。
冷流：虽然每次重新生产，但如果中间操作符不处理，也可能积压。

Flow 的内建背压：挂起机制 #

Flow 的 emit() 是挂起函数，如果下游还没处理完，上游会自动挂起，不会像 RxJava 那样“暴走式”地发：

1
2
3
4
5
6
7
8


flow {
 repeat(1000) {
 emit(it) // 下游慢的话，这里会挂起
 }
}.collect {
 delay(100) // 模拟慢消费
 println(it)
}

这就是 Flow 的“自带背压控制”：天然限速。

SharedFlow 的背压策略：BufferOverflow #

热流场景下，SharedFlow 的背压控制靠 BufferOverflow：

1
2
3
4
5


val flow = MutableSharedFlow<Int>(
 replay = 0,
 extraBufferCapacity = 2,
 onBufferOverflow = BufferOverflow.DROP_OLDEST
)

策略	行为	适用场景
`SUSPEND`	挂起发送者等待消费完成	对数据完整性要求高
`DROP_OLDEST`	丢掉最老的值，保留最新	UI 状态、最新数据为准
`DROP_LATEST`	丢掉当前值，保留已有	已有值重要性更高

冷流的外部背压：操作符控制 #

冷流本身挂起就能控制背压，但还能通过操作符增强控制：

buffer()：增加缓冲区，让生产者不被挂起。

1
2
3
4


flow {
 repeat(1000) { emit(it) }
}.buffer(100)
.collect { delay(100) }

conflate()：丢弃中间值，只保留最新。

1
2
3
4


flow {
 repeat(1000) { emit(it) }
}.conflate()
.collect { delay(100) }

collectLatest()：取消未完成的处理，只处理最新值。

1
2
3
4
5
6


flow {
 repeat(1000) { emit(it) }
}.collectLatest { value ->
 delay(100)
 println("Processing $value")
}

这些操作符本质上是“外部背压策略”，和 SharedFlow 的内部策略互补。

总结：Flow 的设计哲学与实战建议 #

Flow 的设计哲学可以用一句话概括：“用挂起取代背压，用语义取代样板。” 它不像 RxJava 那样通过复杂的背压策略来管理数据流速，而是直接通过 suspend 的天然特性让上游“等一等”下游，简化了响应式流的心智负担。同时，Flow 的 API 更接近 Kotlin 本身的语义风格，与协程深度融合，让异步代码更直观、更易读。

在实际项目中：

数据有限、按需生产时优先用冷流，例如网络请求结果、数据库查询等场景；
数据持续产生、需要广播时使用热流，例如 UI 状态同步、事件分发；
涉及频繁事件时关注背压，灵活使用 buffer()、conflate()、collectLatest() 或 BufferOverflow 策略，避免性能问题；
复杂流组合场景下善用操作符（如 combine、flatMapLatest），可以极大简化数据流处理逻辑。

Flow 并不是 RxJava 的“轻量替代品”，而是站在协程语义之上的一套响应式思想实现。理解了它的背压机制和冷热流模型之后，才可能用它构建出既优雅又高效的数据流管道。

Kotlin 编译器插件（译）

Mon, 13 Oct 2025 21:09:56 +0800

原文：https://kt.academy/article/ak-compiler-plugin

这是《Advanced Kotlin》一书的一个章节。您可以在 LeanPub 或 Amazon 上找到它。

Kotlin 编译器是一个用于编译 Kotlin 代码的程序，同时也被 IDE 用于提供代码补全、警告等分析功能。与许多程序一样，Kotlin 编译器可以使用插件来改变其行为。我们通过扩展一个名为扩展（extension）的特殊类来定义 Kotlin 编译器插件，然后使用注册器（registrar）来注册它。每个扩展在编译器工作的特定阶段被调用，从而可能改变该阶段的结果。例如，你可以注册一个插件，当编译器为类生成父类型时被调用，从而向结果添加额外的父类型。当我们编写编译器插件时，我们受限于所支持的扩展允许我们做的事情。我们很快会讨论当前可用的扩展，但让我们先从一些关于编译器如何工作的基础知识开始。

编译器前端和后端 #

Kotlin 是一种多平台语言，这意味着相同的代码可以用于为不同平台生成底层代码。合理的是，Kotlin 编译器被分为两大部分：

前端（Frontend） ，负责解析和转换 Kotlin 代码为可以被后端解释并用于 Kotlin 代码分析的表示形式。
后端（Backend） ，负责基于从前端接收的表示形式生成实际的底层代码。

编译器前端与目标平台无关，当我们编译多平台模块时，其结果可以被重用。然而，目前正在发生一场革命，因为新的 K2 前端正在取代旧的 K1 前端。

编译器后端是特定于编译目标的，所以 JVM、JS、Native 和 WASM 都有各自独立的后端。它们有一些共享的部分，但本质上是不同的。

编译器前端负责解析和分析 Kotlin 代码，并将其转换为发送给后端的表示形式，后端基于此生成平台特定的文件。前端与目标平台无关，但有两个前端：旧的 K1 和新的 K2。后端是特定于目标平台的。

当你在像 IntelliJ 这样的 IDE 中使用 Kotlin 时，IDE 会向你显示警告、错误、组件使用情况、代码补全等，但 IntelliJ 本身并不分析 Kotlin：所有这些功能都基于与 Kotlin 编译器的通信，编译器有一个专门的 IDE API，而前端负责这种通信。

每个后端变体都共享一部分，该部分从前端提供的表示形式生成 Kotlin 中间表示（在 K2 的情况下是 FIR，即前端中间表示）。平台特定的文件是基于这个表示形式生成的。

每个后端都共享一部分，该部分将前端提供的表示形式转换为 Kotlin 中间表示，该表示用于生成特定目标的文件。

你可以在许多演示文稿和文章中找到关于编译器前端和编译器后端如何工作的详细描述，例如 Amanda Hinchman-Dominguez 或 Mikhail Glukhikh 的文章。我不会在这里详细讨论，因为我们已经涵盖了讨论编译器插件所需的一切。

编译器扩展 #

Kotlin 编译器扩展也分为前端扩展和后端扩展。所有前端扩展都以 Fir 前缀开头，以 Extension 后缀结尾。以下是当前支持的 K2 扩展的完整列表1：

FirStatusTransformerExtension - 在元素状态（可见性、修饰符等）建立时被调用，允许对其进行更改。All-open 编译器插件使用它使所有带有适当注解的类默认为 open（例如，Spring Framework 使用）。
FirDeclarationGenerationExtension - 可以指定为 Kotlin 文件生成的额外声明。其不同的方法在编译的不同阶段被调用，允许生成不同类型的元素，如类或方法。被许多插件使用，包括 Kotlin Serialization 插件，用于生成序列化方法。
FirAdditionalCheckersExtension - 允许指定额外的检查器，这些检查器将在编译器检查代码时被调用；它还可以报告可以由 IntelliJ 可视化的额外错误或警告。
FirSupertypeGenerationExtension - 在编译器为类生成父类型时被调用，允许添加额外的父类型。例如，如果类 A 继承自 B 并实现 C，扩展决定它还应该有父类型 D 和 F，那么编译器将认为 A 有父类型 B、C、D 和 F。被许多插件使用，包括 Kotlin Serialization 插件，它使用此扩展使所有带有 Serializer 注解的类具有带有适当类型参数的隐式 KSerializer 父类型。
FirTypeAttributeExtension - 允许基于注解向类型添加属性，或基于属性确定注解。被实验性的 Kotlin Assignment 插件使用，该插件允许将数字类型注解为正数或负数，然后使用此信息在违反此约定时抛出错误。适用于我们项目使用的库代码。
FirExpressionResolutionExtension - 可用于在调用函数时添加隐式扩展接收者。被实验性的 Kotlin Assignment 插件使用，当调用 injectAlgebra<T>() 时，它注入 Algebra<T> 作为隐式接收者。
FirSamConversionTransformerExtension - 在编译器将 Java SAM 接口转换为 Kotlin 函数类型时被调用，允许更改结果类型。被 SAM-with-receiver 编译器插件 使用，为带有适当注解的 SAM 接口生成带有接收者的函数类型而不是常规函数类型。
FirAssignExpressionAltererExtension - 允许将变量赋值转换为任何类型的语句。被实验性的 Kotlin Assignment 插件使用，该插件允许重载赋值运算符。
FirFunctionTypeKindExtension - 允许注册额外的函数类型。适用于我们项目使用的库代码。
FirDeclarationsForMetadataProviderExtension - 目前允许在 Kotlin 元数据中添加额外的声明。被 Kotlin Serialization 插件使用，用于生成反序列化构造函数或写入自身的方法。其行为在未来可能会改变。
FirScriptConfiguratorExtension - 目前在编译器处理脚本时被调用；它还允许更改脚本配置。其行为在未来可能会改变。
FirExtensionSessionComponent - 目前允许为会话添加额外的扩展会话组件。换句话说，它允许注册一个组件，以便可以被不同的扩展重用。被许多插件使用。例如，Kotlin Serialization 插件使用它来注册一个组件，该组件在文件或 KClass 首先从文件注解中保存序列化器的缓存。其行为在未来可能会改变。

注意！ 在本章中，我们只讨论 K2 前端扩展，因为 K1 前端已被弃用，将来会被移除。然而，K2 编译器前端目前默认不被使用。要使用它，你需要至少有 Kotlin 版本 1.9.0-Beta，并添加 -Pkotlin.experimental.tryK2=true 编译器选项。

如你所见，这些插件允许我们对编译和分析应用更改。它们可以用于显示警告或中断编译并报错。它们还可以用于更改特定元素的可见性，从而影响生成代码的行为和 IDE 中的建议。

关于后端，只有一个扩展：IrGenerationExtension。它在从 FIR（前端中间表示）生成 IR（Kotlin 中间表示）之后但在用于生成平台特定文件之前使用。IrGenerationExtension 用于修改 IR 树。这意味着 IrGenerationExtension 可以更改生成代码中的任何内容，但使用它很困难，因为我们很容易引入破坏性更改，所以必须非常小心地使用它。此外，IrGenerationExtension 无法影响代码分析，因此无法影响 IDE 建议、警告等。

后端插件扩展在从 FIR（前端中间表示）生成 IR（Kotlin 中间表示）之后但在用于生成平台特定文件之前使用。

我想明确一点，后端无法影响 IDE 分析。如果你使用 IrGenerationExtension 向类添加方法，你将无法在 IntelliJ 中直接调用它，因为它无法识别这样的方法，所以你只能使用反射来调用它。相反，使用前端 FirDeclarationGenerationExtension 添加到类的方法可以直接使用，因为 IDE 知道它的存在。

大多数流行的 Kotlin 插件需要多个扩展，包括前端和后端。例如，Kotlin Serialization 使用后端扩展来生成所有序列化和反序列化的函数；另一方面，它使用前端扩展来添加隐式父类型、检查和声明。

这是关于 Kotlin 编译器插件的基本知识。为了使其更实用一些，让我们看几个例子。

流行的编译器插件 #

许多编译器插件和使用编译器插件的库已经可用。最流行的包括：

Kotlin Serialization - 一个为 Kotlin 类生成序列化方法的插件。它是多平台的，非常高效，因为它使用编译器插件而不是反射。
Jetpack Compose - 一个流行的 UI 框架，使用编译器插件来支持其视图元素定义。所有可组合函数都被转换为特殊的表示形式，然后由框架用于生成 UI。
Arrow Meta - 一个强大的插件，引入了函数式编程语言中已知的功能支持，如光学（optics）或精炼类型（refined types）。它还支持面向切面编程（Aspect Oriented Programming）。
Parcelize - 一个为 Kotlin 类生成 Parcelable 实现的插件。它使用编译器插件向现有类添加适当的方法。
All-open - 一个使所有带有适当注解的类默认为 open 的插件。Spring Framework 使用它来使所有带有 @Component 注解的类默认为 open（以便能够为它们创建代理）。

大多数插件使用多个扩展，所以让我们考虑简单的 Parcelize 插件，它只使用以下扩展：

IrGenerationExtension 来生成在底层使用的函数和属性。
FirDeclarationGenerationExtension 来生成项目编译所需的函数。
FirAdditionalCheckersExtension 来显示错误和警告。

Kotlin 编译器插件在 build.gradle(.kts) 的 plugins 部分中定义：

1
2
3


plugins {
 id("kotlin-parcelize")
}

一些插件作为单独的 Gradle 插件的一部分分发。

使所有类为 open #

我们将从一个简单的任务开始：使所有类为 open。这个行为受到 AllOpen 插件的启发，该插件打开所有带有指定注解之一的类。然而，我们的示例会更简单，因为我们只是打开所有类。

作为依赖项，我们只需要 kotlin-compiler-embeddable，它为我们提供了可用于定义插件的类。

就像在 KSP 或注解处理中一样，我们需要在 resources/META-INF/services 中添加一个带有注册器名称的文件。这个文件的名称应该是 org.jetbrains.kotlin.compiler.plugin.CompilerPluginRegistrar，这是 CompilerPluginRegistrar 类的完全限定名。在其中，你应该放置注册器类的完全限定名。在我们的例子中，这将是 com.marcinmoskala.AllOpenComponentRegistrar。

1
2
3


// org.jetbrains.kotlin.compiler.plugin.
// CompilerPluginRegistrar
com.marcinmoskala.AllOpenComponentRegistrar

我们的 AllOpenComponentRegistrar 注册器需要注册一个扩展注册器（我们称之为 FirAllOpenExtensionRegistrar），该注册器注册我们的扩展。请注意，注册器可以访问配置，以便我们可以将参数传递给我们的插件，但我们现在不需要这个配置。我们的扩展只是一个扩展 FirStatusTransformerExtension 的类；它有两个方法：needTransformStatus 和 transformStatus。前者确定是否应该应用转换；后者应用它。在我们的例子中，我们将扩展应用于所有类，并将它们的状态更改为 open，无论之前的状态是什么。

 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


@file:OptIn(ExperimentalCompilerApi::class)

class AllOpenComponentRegistrar : CompilerPluginRegistrar() {
 override fun ExtensionStorage.registerExtensions(
 configuration: CompilerConfiguration
 ) {
 FirExtensionRegistrarAdapter
 .registerExtension(FirAllOpenExtensionRegistrar())
 }

 override val supportsK2: Boolean
 get() = true
}

class FirAllOpenExtensionRegistrar : FirExtensionRegistrar(){
 override fun ExtensionRegistrarContext.configurePlugin() {
 +::FirAllOpenStatusTransformer
 }
}

class FirAllOpenStatusTransformer(
 session: FirSession
) : FirStatusTransformerExtension(session) {
 override fun needTransformStatus(
 declaration: FirDeclaration
 ): Boolean = declaration is FirRegularClass

 override fun transformStatus(
 status: FirDeclarationStatus,
 declaration: FirDeclaration
 ): FirDeclarationStatus =
 status.transform(modality = Modality.OPEN)
}

这只是一个简化的版本，但实际的 AllOpen 插件稍微复杂一些，因为它只打开那些带有指定注解之一的类。为此，FirAllOpenExtensionRegistrar 注册一个插件，该插件由 FirAllOpenStatusTransformer 使用来确定是否应该打开特定的类。如果你对细节感兴趣，请查看 Kotlin 仓库中 plugins 文件夹中的 AllOpen 插件。

更改类型 #

我们的下一个示例将是 SAM-with-receiver 编译器插件，它将从带有适当注解的 SAM 接口生成的函数类型更改为带有接收者的函数类型。它使用 FirSamConversionTransformerExtension，这对于这个插件来说非常特定，因为它仅在 SAM 接口转换为函数类型时被调用，并且允许更改将要生成的类型。这个示例很有趣，因为它添加了一个类型，该类型将被 IDE 识别并可以直接在代码中使用。完整的实现可以在 Kotlin 仓库的 plugins/sam-with-receiver 文件夹中找到，但这里我只想展示这个扩展的简化实现：

 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


class FirScriptSamWithReceiverConventionTransformer(
 session: FirSession
) : FirSamConversionTransformerExtension(session) {
 override fun getCustomFunctionTypeForSamConversion(
 function: FirSimpleFunction
 ): ConeLookupTagBasedType? {
 val containingClassSymbol = function
 .containingClassLookupTag()
 ?.toFirRegularClassSymbol(session)
 ?: return null

 return if (shouldTransform(it)) {
 val parameterTypes = function.valueParameters
 .map { it.returnTypeRef.coneType }
 if (parameterTypes.isEmpty()) return null
 createFunctionType(
 getFunctionType(it),
 parameters = parameterTypes.drop(1),
 receiverType = parameterTypes[0],
 rawReturnType = function.returnTypeRef
 .coneType
 )
 } else null
 }

 // ...
}

如果 getCustomFunctionTypeForSamConversion 函数不返回 null，它将覆盖为 SAM 接口生成的类型。在我们的例子中，我们确定函数是否应该被转换；如果是，我们通过使用 createFunctionType 函数创建一个带有接收者的函数类型。有构建器函数可以帮助我们创建在 FIR 中表示的许多元素。示例包括 buildSimpleFunction 或 buildRegularClass，它们中的大多数都提供了简单的 DSL。这里，createFunctionType 函数创建一个类型为 ConeLookupTagBasedType 的带有接收者表示的函数类型，它将替换从 SAM 接口自动生成的类型。本质上，这就是这个插件的工作原理。

生成函数包装器 #

让我们考虑以下问题：Kotlin 挂起函数只能在 Kotlin 代码中调用。这意味着如果你想从 Java 调用挂起函数，你可以使用例如 runBlocking 将其包装在一个常规函数中，该函数在协程中调用挂起函数。

1
2
3


suspend fun suspendFunction() = ...

fun blockingFunction() = runBlocking { suspendFunction() }

我们可以使用插件来自动生成这样的挂起函数包装器，使用后端或前端插件。

后端插件需要一个 IrGenerationExtension 扩展，该扩展在 IR 中为适当的函数生成额外的包装函数。这些包装函数将存在于生成的平台特定代码中，因此可用于 Java、Groovy 和其他语言。问题是这些包装类在 Kotlin 代码中不可见。如果我们的包装函数本来就是要从其他语言使用的，这很好，但我们需要知道这个严重的限制。有一个名为 kotlin-jvm-blocking-bridge 的开源插件，它使用后端插件为挂起函数生成阻塞包装器；你可以在链接 github.com/Him188/kotlin-jvm-blocking-bridge 下找到其源代码。

前端插件需要一个 FirDeclarationGenerationExtension 类的扩展，为 FIR 中的适当挂起函数生成包装函数。然后，这些额外的函数将用于生成 IR，最后生成平台特定的代码。这些函数在 IntelliJ 中也可见，因此我们可以在 Kotlin 和 Java 中使用它们。然而，这样的插件只能与 K2 编译器一起工作，即从 Kotlin 2.0 开始。要支持以前的语言版本，我们需要定义一个支持 K1 的额外扩展。

示例插件实现 #

Kotlin 编译器插件目前没有文档，生成的元素必须遵守许多限制才能使我们的代码不会崩溃，所以定义自定义插件相当困难。如果你想定义自己的插件，我的建议是首先获取 Kotlin 编译器源代码，然后分析 plugins 文件夹中的现有插件。

这个文件夹不仅包括 K2 插件，还包括 K1 和基于 KSP 的插件。我们只对 K2 插件感兴趣，所以你可以忽略其余的。

所有支持的扩展的列表可以在 FirExtensionRegistrar 类中找到。要分析编译器如何使用扩展，你可以搜索其公开方法的使用情况。要做到这一点，按住 command/Ctrl 并点击方法名跳转到其使用位置。这应该向你显示 Kotlin 编译器在哪里使用这个扩展。但请注意，所有未记录的知识在未来更有可能改变。

总结 #

如你所见，Kotlin 编译器插件的能力由 Kotlin 编译器支持的扩展决定。在编译器的前端，这些扩展能力是有限的，所以目前只有一组特定的事情可以在前端使用 Kotlin 编译器插件完成。在编译器后端，你可以以任何方式更改生成的 IR 表示；这提供了许多可能性，但也很容易在你的代码中引起破坏性更改。

Kotlin 编译器插件技术仍然年轻、缺乏文档且在变化中。应该非常小心地使用它，因为它很容易破坏你的代码，但它也极其强大，提供了难以想象的可能性。Jetpack Compose 就是一个很好的例子。我只能与你分享 Kotlin 编译器插件如何工作以及它们能做什么的大致概念，但我希望这足以让你理解关键概念和可能性。

在下一章中，我们将讨论另一个有助于代码开发的工具：静态代码分析器。一方面，它比 KSP 或编译器插件更有限，因为它无法生成任何代码；另一方面，静态代码分析器也极其强大，因为它们可以严重影响我们的开发过程并帮助我们改进实际代码。

1: K1 扩展已被弃用，所以我将跳过它们。

作者 #

Marcin Moskała

Marcin Moskala 是一位经验丰富的开发者和 Kotlin 教师，同时也是 Kt. Academy 的创始人，该机构是 JetBrains 的官方合作伙伴，专注于 Kotlin 培训。他还是 Google Developers Expert，以其对 Kotlin 社区的重大贡献而闻名。Moskala 著有多本广受认可的书籍，包括《Effective Kotlin》、《Kotlin Coroutines》、《Functional Kotlin》、《Advanced Kotlin》、《Kotlin Essentials》和《Android Development with Kotlin》。

除了在出版领域的成就外，Moskala 还是 Medium 上最大的 Kotlin 专栏的作者。作为一名备受尊敬的演讲者，他曾受邀在众多编程大会上分享见解，包括 Droidcon 以及 Kotlin 编程语言顶级大会 Kotlin Conf 等知名活动。

Kotlin 协程：Job 与 SupervisorJob 的差异

Fri, 10 Oct 2025 21:13:33 +0800

我们都知道，在 Kotlin 协程中，可以使用 Job 或 SupervisorJob 来构建一个作用域（CoroutineScope）：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


// SupervisorJob 
val scope = CoroutineScope(SupervisorJob())
scope.launch {
 ...
}

// Job
val scope = CoroutineScope(Job())
scope.launch {
 ...
}

两者的区别似乎仅在于构造函数不同。点开源码一看，差别的确只有一个方法：

1
2
3
4
5
6
7


public fun Job(parent: Job? = null): CompletableJob = JobImpl(parent)

public fun SupervisorJob(parent: Job? = null): CompletableJob = SupervisorJobImpl(parent)

private class SupervisorJobImpl(parent: Job?) : JobImpl(parent) {
 override fun childCancelled(cause: Throwable): Boolean = false
}

SupervisorJobImpl 继承自 JobImpl，唯一做的事就是重写了 childCancelled 方法。也就是说，整个差异的核心就在这里。

JobImpl 的取消逻辑 #

来看 JobImpl 的实现：

1
2
3
4


public open fun childCancelled(cause: Throwable): Boolean {
 if (cause is CancellationException) return true
 return cancelImpl(cause) && handlesException
}

当子协程异常时，JobImpl 默认会执行 cancelImpl(cause)，也就是会触发父协程的取消逻辑。

在 cancelImpl 中：

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


internal fun cancelImpl(cause: Any?): Boolean {
 var finalState: Any? = COMPLETING_ALREADY
 if (onCancelComplete) {
 finalState = cancelMakeCompleting(cause)
 if (finalState === COMPLETING_WAITING_CHILDREN) return true
 }
 if (finalState === COMPLETING_ALREADY) {
 // 执行取消
 finalState = makeCancelling(cause)
 }
 return when {
 finalState === COMPLETING_ALREADY -> true
 finalState === COMPLETING_WAITING_CHILDREN -> true
 finalState === TOO_LATE_TO_CANCEL -> false
 else -> {
 afterCompletion(finalState)
 true
 }
 }
}

也就是说，一旦子协程抛出异常，JobImpl 就会触发父协程的 makeCancelling() 流程，继而执行 notifyCancelling()，从而传播取消信号：

1
2
3
4
5
6
7


private fun notifyCancelling(list: NodeList, cause: Throwable) {
 // 取消子任务
 onCancelling(cause)
 notifyHandlers<JobCancellingNode>(list, cause)
 // 取消父任务
 cancelParent(cause)
}

SupervisorJob 的不同 #

而 SupervisorJobImpl 的 childCancelled 方法返回 false。这意味着：当子协程异常取消时，父协程不会被取消。

这一点正是 SupervisorJob 的核心特性：

子协程的失败不会影响到其他兄弟协程，也不会导致整个作用域取消。

childCancelled 的调用链 #

继续往下看，在 ChildHandleNode 中：

1
2
3
4
5
6
7
8


private class ChildHandleNode(
 @JvmField val childJob: ChildJob
) : JobNode(), ChildHandle {
 override val parent: Job get() = job
 override val onCancelling: Boolean get() = true
 override fun invoke(cause: Throwable?) = childJob.parentCancelled(job)
 override fun childCancelled(cause: Throwable): Boolean = job.childCancelled(cause)
}

这里当子任务被取消时，会通过 childCancelled 将异常传递回父任务。而 SupervisorJobImpl 正是通过重写 childCancelled 来“截断”这个传播链。

cancelParent 的触发点 #

那么，cancelParent 是在哪里被调用的？在 JobSupport.kt 中：

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


private fun cancelParent(cause: Throwable): Boolean {
 if (isScopedCoroutine) return true

 val isCancellation = cause is CancellationException
 val parent = parentHandle

 if (parent === null || parent === NonDisposableHandle) {
 return isCancellation
 }

 // 通知父任务
 return parent.childCancelled(cause) || isCancellation
}

从注释可以看出：

对于正常的 CancellationException，不会取消父任务；只有当出现其他异常（例如崩溃）时，才可能向父任务传播。

这个方法会在 notifyCancelling() 和 finalizeFinishingState() 中被调用。而后者正是任务完成状态的最终确定逻辑。

finalizeFinishingState：异常如何进入“最终状态” #

在 finalizeFinishingState 中：

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


private fun finalizeFinishingState(state: Finishing, proposedUpdate: Any?): Any? {
 val proposedException = (proposedUpdate as? CompletedExceptionally)?.cause

 val finalException = synchronized(state) {
 val exceptions = state.sealLocked(proposedException)
 val finalCause = getFinalRootCause(state, exceptions)
 if (finalCause != null) addSuppressedExceptions(finalCause, exceptions)
 finalCause
 }

 val finalState = when {
 finalException == null -> proposedUpdate
 finalException === proposedException -> proposedUpdate
 else -> CompletedExceptionally(finalException)
 }

 if (finalException != null) {
 val handled = cancelParent(finalException) || handleJobException(finalException)
 if (handled) (finalState as CompletedExceptionally).makeHandled()
 }

 completeStateFinalization(state, finalState)
 return finalState
}

这里的关键在于：

如果 cancelParent 返回 true，说明异常已被父协程处理；
否则，handleJobException 再尝试处理；
若两者都未处理，则异常会继续冒泡到 CoroutineExceptionHandler。

handled 状态的意义 #

makeHandled() 的作用是将 CompletedExceptionally 标记为已处理（handled = true）。这个标志会影响 onCompletionInternal 的行为：

1
2
3
4
5
6


protected final override fun onCompletionInternal(state: Any?) {
 if (state is CompletedExceptionally)
 onCancelled(state.cause, state.handled)
 else
 onCompleted(state as T)
}

也就是说，当 handled 为 false 时，异常会被进一步上报。

在 SupervisorJob 中，由于 childCancelled 返回 false，子任务的异常不会让父协程进入取消状态，也不会设置 handled = true。结果就是：异常只会在当前子协程内抛出，不会影响其他子协程。

结论 #

SupervisorJob 通过重写 childCancelled，阻止了子协程异常向父协程传播，从而让协程之间相互独立。

在 Job 中，任何子协程的异常都会触发 cancelImpl → notifyCancelling → cancelParent 链条，导致整个作用域被取消。而在 SupervisorJob 中，这条链被截断，父协程不再传播取消信号，异常只在本地处理。

对比项	`Job`	`SupervisorJob`
子任务异常	会取消父任务	不会取消父任务
兄弟任务影响	相互影响（一个失败全部取消）	相互独立（失败互不影响）
childCancelled	触发父级取消逻辑	返回 false，忽略子取消
handled 状态	置为 true（异常被处理）	仍为 false（异常局部处理）

所以，当你希望在一个作用域中，某个子任务失败时不影响其他任务， SupervisorJob 就是你要用的那个。

Paging3核心解析：Kotlin Flow 如何实现内存与数据双高效

Tue, 07 Oct 2025 14:25:55 +0800

Paging 库是什么？ #

Paging 库的核心作用是帮助 Android 应用高效地加载和展示大数据集。

人话解释：它就像一个聪明的服务员，不会一次性把所有菜都端上来（避免内存爆炸），而是根据你的需求（分页）逐步、按需从本地数据库或网络获取一小部分数据。这样能显著降低内存压力，提供流畅的用户体验。

Paging 库如何使用？ #

在 Jetpack Compose 或使用 Kotlin Flow 的架构中，Paging 库的标准用法是创建一个 Flow<PagingData<T>> 来暴露给 UI 层。

核心代码示例 #

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


/
 * UI 层的不可变状态流。
 */
val items: Flow<PagingData<Article>> = Pager(
 // 配置分页行为
 config = PagingConfig(
 pageSize = ITEMS_PER_PAGE, // 每页数据量，唯一必传参数
 enablePlaceholders = false
 ),
 // 数据源工厂，每次都创建新的 PagingSource 实例
 pagingSourceFactory = { repository.articlePagingSource() } 
)
 .flow
 // 关键优化：缓存 Paging 流程，即使 UI (Activity/Fragment) 经历生命周期变化，
 // 分页状态和数据依然保留在 ViewModel 作用域内，无需从头开始加载。
 .cachedIn(viewModelScope)

原理解析：Pager 的“壳”与 Flow 的构建 #

Pager 对象：它是一个“壳子”，封装了 Flow 的创建过程。
PagingConfig：决定分页配置，pageSize 是唯一必须的参数。
pagingSourceFactory：
- 为什么是 Factory（工厂模式）？借助 Kotlin 高阶函数的灵活性，它能确保每次都需要创建新的 PagingSource 实例。
- 目的：保证每次加载时，内部的状态和参数都是最新的，避免使用旧的状态。
内部实现：真正的分页逻辑藏在更深层。它通过 StateFlow 来维护状态，并经过一系列配置和操作：
- 刷新触发：当 flow 开始收集时，会触发首次刷新加载。
- 无缝衔接：通过对加载位置的变换，新加载的数据能够从用户当前查看的位置附近开始，实现无缝的数据替换。
- 状态合并：利用 combineWithoutBatching 等 Flow 操作符，将请求状态事件和请求结果进行结合，最终发送出 PagingData 结果。

Paging 库的核心组件 #

Paging 库主要由三个核心部分组成：

如上所述，负责配置和启动分页数据流。

PagingSource #

这是您实现数据获取逻辑的地方，作用相对简单但至关重要：

加载实现：定义如何从网络或数据库加载数据的逻辑（load() 方法）。
刷新键（Refresh Key）：定义在刷新操作（例如数据失效或旋转屏幕）时，如何定位到用户正在查看的新起始加载位置。

PagingDataAdapter #

PagingDataAdapter 继承自 RecyclerView.Adapter，它将获取 Item 的工作委托给了内部的 AsyncPagingDataDiffer，并巧妙地隐藏了后续分页的关键触发逻辑。

关键原理：后续分页如何触发 #

第一次加载由 Flow 启动，但之后的加载（当用户滚动接近底部时）并不是手动调用的，它被隐藏在了 PagingDataAdapter 的内部：

核心触发点：`getItem(position)` #

当 RecyclerView 准备展示一个 Item 时，会调用 PagingDataAdapter 的 getItem(position) 方法。

PagingDataAdapter.kt

1
2
3
4
5
6
7


// PagingDataAdapter.kt

 /
 * @return The presented item at [position], `null` if it is a placeholder
 */
 @MainThread
 protected fun getItem(@IntRange(from = 0) position: Int) = differ.getItem(position)

Differ：`getItem` 的最终流向 #

getItem 调用会进入内部的 AsyncPagingDataDiffer，并最终执行到 PagingDataPresenter 的 get(index)。
在 getItem 方法内部，会更新上一次访问的索引（lastAccessedIndex = index）。

AsyncPagingDataDiffer.kt

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


 @MainThread
 fun getItem(@IntRange(from = 0) index: Int): T? {
 try {
 // ... 省略无关代码
 lastAccessedIndex = index // 记录当前访问的位置
 // ...
 return presenter[index]
 } finally {
 // ...
 }
 }

ViewportHint：将 UI 行为转化为加载事件 #

在 PagingDataPresenter 的 get(index) 方法中，核心逻辑是根据 index 创建并发送一个 ViewportHint。

调用的顺序和原理：

PagingDataPresenter.get()
->HintReceiver.accessHint()
-> PagerHintReceiver.accessHint()
-> PageFetcherSnapshot.processHint(viewportHint)

processHint 的作用：

ViewportHint 包含了用户当前在 UI 中可见的区域和滚动方向。PageFetcherSnapshot 接收到这个 Hint 后：

它会更新内部状态，确定是需要预加载下一页（APPEND）还是预加载上一页（PREPEND）。
最终，它会通过 pageEventFlow 启动两个后台协程。这些协程会不断处理收到的事件，并执行 doLoad 方法，从而悄无声息地完成了下一页数据的加载。

结论： Paging 库通过拦截 RecyclerView 的 getItem 调用，将其转换为一个 ViewportHint 事件，并利用内部的 Flow 机制，实现了加载逻辑与 UI 滚动的解耦和自动化触发。

深入 Compose：从 setContent 到 LayoutNode 绘制原理

Mon, 06 Oct 2025 22:05:44 +0800

在之前，我一直以为 Compose 是深不可测、难以理解的东西，直到我打开一个 Compose 项目的 setContent 方法，才发现它其实并没有那么复杂。

Compose 和 XML 的不同，只是写 UI 的方式不同而已。而关键差别，就在 setContent 方法上。注意，这里的 setContent 与我们平时在 Activity 中调用的、传入一个 View 或布局 id 的 setContentView 并不是同一个方法。它只是名字相同，实际上完全是另一套实现：

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


public fun ComponentActivity.setContent(
 parent: CompositionContext? = null,
 content: @Composable () -> Unit
) {
 val existingComposeView =
 window.decorView.findViewById<ViewGroup>(android.R.id.content).getChildAt(0) as? ComposeView

 if (existingComposeView != null)
 with(existingComposeView) {
 setParentCompositionContext(parent)
 setContent(content)
 }
 else
 ComposeView(this).apply {
 // Set content and parent **before** setContentView
 // to have ComposeView create the composition on attach
 setParentCompositionContext(parent)
 setContent(content)
 // Set the view tree owners before setting the content view so that the inflation
 // process and attach listeners will see them already present
 setOwners()
 setContentView(this, DefaultActivityContentLayoutParams)
 }
}

可以看到，ComposeView 继承自 AbstractComposeView，而 AbstractComposeView 又是一个 ViewGroup。当 ComposeView 被添加到 Window 上时，会创建一个 Composition 对象：

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


// ComposeView.android.kt
override fun onAttachedToWindow() {
 super.onAttachedToWindow()

 previousAttachedWindowToken = windowToken

 if (shouldCreateCompositionOnAttachedToWindow) {
 ensureCompositionCreated()
 }
}

private fun ensureCompositionCreated() {
 if (composition == null) {
 try {
 creatingComposition = true
 composition = setContent(resolveParentCompositionContext()) {
 Content()
 }
 } finally {
 creatingComposition = false
 }
 }
}

ComposeView 的 setContent 会创建一个关键的类：AndroidComposeView。可以说它是 Compose 在 Android 上的核心实现：

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


// Wrapper.android.kt
internal fun AbstractComposeView.setContent(
 parent: CompositionContext,
 content: @Composable () -> Unit
): Composition {
 GlobalSnapshotManager.ensureStarted()
 val composeView =
 if (childCount > 0) {
 getChildAt(0) as? AndroidComposeView
 } else {
 removeAllViews(); null
 } ?: AndroidComposeView(context, parent.effectCoroutineContext).also {
 addView(it.view, DefaultLayoutParams)
 }
 return doSetContent(composeView, parent, content)
}

AndroidComposeView 是 ComposeView 的唯一子 View，它把 Compose 和 Android View 系统联系起来。

在 AndroidComposeView 中，根节点就是 Compose 的 LayoutNode。Compose 中的每个组件，都会由 @Composable 标记，并在编译时由 Kotlin IR 插件自动增加两个参数：Composer $composer 和 int $changed。Composer 的唯一实现类 ComposerImpl 会为组件创建 LayoutNode，而 Applier 则负责把 LayoutNode 添加到父节点中：

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


// Wrapper.android.kt
private fun doSetContent(
 owner: AndroidComposeView,
 parent: CompositionContext,
 content: @Composable () -> Unit
): Composition {
 val original = Composition(UiApplier(owner.root), parent)
 val wrapped = owner.view.getTag(R.id.wrapped_composition_tag)
 as? WrappedComposition
 ?: WrappedComposition(owner, original).also {
 owner.view.setTag(R.id.wrapped_composition_tag, it)
 }
 wrapped.setContent(content)

 if (owner.coroutineContext != parent.effectCoroutineContext) {
 owner.coroutineContext = parent.effectCoroutineContext
 }

 return wrapped
}

这里，owner 是 AndroidComposeView，owner.root 是 Compose 的根节点，用于创建 UiApplier。

绘制流程 #

Compose 的绘制逻辑也不同于传统 View。传统 View 通常只重写 onDraw 来绘制内容，背景和前景由系统在 draw 中处理。而 Compose 的绘制单元不是 View，而是 LayoutNode，因此绘制操作在 dispatchDraw 中进行分发：

 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


override fun dispatchDraw(canvas: android.graphics.Canvas) {
 if (!isAttachedToWindow) {
 invalidateLayers(root)
 }
 measureAndLayout()
 Snapshot.sendApplyNotifications()

 isDrawingContent = true
 // 绘制根节点
 canvasHolder.drawInto(canvas) { root.draw(this) }

 if (dirtyLayers.isNotEmpty()) {
 for (i in 0 until dirtyLayers.size) {
 val layer = dirtyLayers[i]
 layer.updateDisplayList()
 }
 }

 if (ViewLayer.shouldUseDispatchDraw) {
 val saveCount = canvas.save()
 canvas.clipRect(0f, 0f, 0f, 0f)
 super.dispatchDraw(canvas)
 canvas.restoreToCount(saveCount)
 }

 dirtyLayers.clear()
 isDrawingContent = false

 if (postponedDirtyLayers != null) {
 val postponed = postponedDirtyLayers!!
 dirtyLayers.addAll(postponed)
 postponed.clear()
 }
}

在这里，root 就是 LayoutNode 的根节点。绘制时，会遍历链表中的节点，并调用节点自身的 draw 方法：

 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


// NodeCoordinator.kt
fun draw(canvas: Canvas, graphicsLayer: GraphicsLayer?) {
 val layer = layer
 if (layer != null) {
 layer.drawLayer(canvas, graphicsLayer)
 } else {
 val x = position.x.toFloat()
 val y = position.y.toFloat()
 canvas.translate(x, y)
 drawContainedDrawModifiers(canvas, graphicsLayer)
 canvas.translate(-x, -y)
 }
}

private fun drawContainedDrawModifiers(canvas: Canvas, graphicsLayer: GraphicsLayer?) {
 val head = head(Nodes.Draw)
 if (head == null) {
 performDraw(canvas, graphicsLayer)
 } else {
 val drawScope = layoutNode.mDrawScope
 drawScope.draw(canvas, size.toSize(), this, head, graphicsLayer)
 }
}

// LayoutNodeDrawScope.kt
internal fun draw(
 canvas: Canvas,
 size: Size,
 coordinator: NodeCoordinator,
 drawNode: Modifier.Node,
 layer: GraphicsLayer?
) {
 drawNode.dispatchForKind(Nodes.Draw) {
 drawDirect(canvas, size, coordinator, it, layer)
 }
}

简单总结：

ComposeView → AndroidComposeView → LayoutNode
@Composable 函数组件 → ComposerImpl → LayoutNode → UiApplier
绘制由 dispatchDraw 触发，通过 Canvas 绘制 LayoutNode 的内容
Compose 的 UI 结构和 View 层级不同，它直接操作 LayoutNode 树，而不是 View 树

Jetpack DataStore：Android应用中的现代数据存储方法

Tue, 30 Sep 2025 23:13:28 +0800

在学习 DataStore 之前，需要先了解 Kotlin 属性委托 的概念。

Kotlin 属性委托简介 #

Kotlin 支持通过 属性委托 (by) 来委托属性的获取和设置逻辑。

基本规则是：如果一个对象实现了如下方法：

1

operator fun getValue(thisRef: Any?, property: KProperty<*>): A

那么就可以用 by 实例 的方式将属性委托给该对象。

示例：

1

val Context.dataStore: DataStore<Preferences> by preferencesDataStore(name = "settings")

上面的写法将 DataStore 实例绑定到 Context 的扩展属性 dataStore，访问时会通过委托自动初始化。

创建 DataStore 实例 #

1
2
3
4
5
6


val EXAMPLE_COUNTER = intPreferencesKey("example_counter")

val exampleCounterFlow: Flow<Int> = context.dataStore.data
 .map { preferences ->
 preferences[EXAMPLE_COUNTER] ?: 0
 }

preferencesDataStore 方法利用 Kotlin 的属性委托创建 DataStore，并通过 double-check 机制 确保整个应用中访问到的都是同一个实例。

DataStore 是一个数据接口，它主要有两种实现：

Preference DataStore：对应 SharedPreferences 风格，使用键值对存储。
Proto DataStore：对应 ProtoBuf 协议，存储自定义类型，需要手动实现序列化和反序列化。

DataStore 内部关键组件 #

DataStoreImpl 是 DataStore 的核心实现类，其中关键变量有：

inMemoryCache: DataStoreInMemoryCache<T>
- 存储状态数据，Flow 中的 T 是 State<T>，可直接拿到当前状态。
readAndInit: InitDataStore()
- 负责初始化和读取文件，将 UnInitialized 状态更新为 Data 状态。
coordinator: SingleProcessCoordinator
- 单进程场景下用于版本控制和锁管理，保证数据一致性。

DataStore 状态 #

DataStore 内部状态包括：

UnInitialized：初始状态，需要解析文件。
Data：数据已初始化，可正常读取。
ReadException：读取失败。
Final：最终状态，缓存数据不再更新。

第一次访问 DataStore 时，状态为 UnInitialized，初始化完成后才会切换到 Data 状态。

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


private suspend fun readState(requireLock: Boolean): State<T> =
 withContext(scope.coroutineContext) {
 if (inMemoryCache.currentState is Final) {
 inMemoryCache.currentState
 } else {
 try {
 readAndInitOrPropagateAndThrowFailure()
 } catch (throwable: Throwable) {
 return@withContext ReadException(throwable, -1)
 }
 readDataAndUpdateCache(requireLock)
 }
 }

readAndInit 的核心逻辑是 只执行一次：

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


internal abstract class RunOnce {
 private val runMutex = Mutex()
 private val didRun = CompletableDeferred<Unit>()
 protected abstract suspend fun doRun()

 suspend fun runIfNeeded() {
 if (didRun.isCompleted) return
 runMutex.withLock {
 if (didRun.isCompleted) return
 doRun()
 didRun.complete(Unit)
 }
 }

 suspend fun awaitComplete() = didRun.await()
}

通过 didRun.isCompleted 判断是否已经初始化，保证首次初始化只执行一次。

读取数据流程 #

首次读取会调用 readAndInit.runIfNeeded() 解析文件。
初始化完成后，后续读取会直接从 inMemoryCache 获取数据。
读取操作是异步的，结合 Flow 可以实现响应式数据更新。

1
2


val exampleCounterFlow: Flow<Int> = context.dataStore.data
 .map { preferences -> preferences[EXAMPLE_COUNTER] ?: 0 }

写入数据流程 #

写入流程与 SharedPreferences 类似，但更加安全和异步：

1
2
3
4
5
6


lifecycleScope.launch {
 dataStore.edit { settings ->
 val currentCounterValue = settings[EXAMPLE_COUNTER] ?: 0
 settings[EXAMPLE_COUNTER] = currentCounterValue + 1
 }
}

DataStore 写入特点：

数据先更新到内存缓存。
再写入临时文件（.tmp）。
临时文件写入成功后，覆盖原文件。
通过版本号和锁机制保证多线程/多进程访问一致性。

示例核心实现：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


internal suspend fun writeData(newData: T, updateCache: Boolean): Int {
 var newVersion = 0
 storageConnection.writeScope {
 newVersion = coordinator.incrementAndGetVersion()
 writeData(newData)
 if (updateCache) {
 inMemoryCache.tryUpdate(Data(newData, newData.hashCode(), newVersion))
 }
 }
 return newVersion
}

DataStore 与 SharedPreferences 对比 #

特性	SharedPreferences	DataStore
存储方式	XML 文件	Proto / Preferences Map
初始化	同步解析 XML，可能导致 ANR	异步解析，基于 Flow
写入	onPause/onStop 阻塞磁盘写入	先写 tmp 文件，再覆盖，异步安全
多线程/多进程	支持有限，多线程容易出错	通过锁和版本号保证一致性
类型安全	仅基本类型	Preferences 无类型安全，Proto 可自定义类型

Proto DataStore #

Proto DataStore 使用 Protobuf 存储数据：

类型由外部定义，DataStore 不解析具体格式。
需要实现序列化和反序列化逻辑。
上层使用方式与 Preference DataStore 类似，但底层存储格式为 Proto。

多进程支持 #

DataStore 支持多进程访问，区别在于锁机制：

单进程使用 Mutex。
多进程使用 fcntl 文件锁，对整个文件加锁，保证跨进程数据一致性。

1
2
3
4
5


lockFileStream.getChannel().tryLock(
 /* position= */ 0L,
 /* size= */ Long.MAX_VALUE,
 /* shared= */ true
)

总结 #

DataStore 相比 SharedPreferences 的优势：

异步、安全，避免 ANR。
先写入临时文件，再覆盖原文件，保证数据一致性。
支持 Flow，实现响应式数据更新。
通过版本号和锁机制，支持多线程与多进程安全。
支持 Proto 格式，类型安全可扩展。

参考资料 #

Protocol Buffers编码原理

Wed, 24 Sep 2025 22:08:47 +0800

Protocol Buffers（简称 proto）是一种高效的二进制序列化协议。它的核心编码方式基于 Base-128 Varint（128 进制变长整数）。理解它的编码规则是掌握 proto 的关键。

基于 Base-128 的 Varint 编码 #

Varint 是一种可变长度整数的编码方式。一个整数可以用 1~10 个字节存储，数值越小，占用的字节越少。

每个字节有 8 位，其中：
- 最高位（MSB，Most Significant Bit）是标志位，用来表示是否还有后续字节。
  - 0 表示这是最后一个字节。
  - 1 表示后面还有字节。
- 剩下的 7 位存储实际数值。

举例：

数字 1 的 MSB 是 0，表示这是最后一个字节。

再看一个稍大的数字 150：

1
2


10010110 00000001
^ MSB ^ MSB

官方计算示例 #

1
2
3
4
5


10010110 00000001 // 原始输入
 0010110 0000001 // 去掉最高位（MSB）
 0000001 0010110 // 按大端序排列
 00000010010110 // 拼接
 128 + 16 + 4 + 2 = 150 // 解释为无符号整数

可以看到，MSB 只用于标识，不参与数值计算，最终拼接得到的二进制 00000010010110 就是 150。

消息结构 #

Protocol Buffers 的二进制消息是一系列键值对。编码时并不存储字段名称，而是使用字段编号（field number）作为键，类型则由一个叫 wire type 的值表示。

wire type #

可以理解为“底层存储格式”，不同类型的字段对应不同的 wire type。

ID	Name	说明 / 对应类型
0	VARINT	int32, int64, uint32, uint64, sint32, sint64, bool, enum
1	I64	fixed64, sfixed64, double
2	LEN	string, bytes, 嵌套 message, packed repeated
3	SGROUP	group start（已弃用）
4	EGROUP	group end（已弃用）
5	I32	fixed32, sfixed32, float

字段头（tag） 也是一个 Varint，由以下两部分组成：

高位部分：字段编号（field number）左移 3 位
低 3 位：wire type

例如：一个字节的结构可以粗略理解为：

第 1 位：标识 Varint 是否还有后续字节（若是 Varint 类型）
接下来的几位：字段编号
最后 3 位：wire type

整数编码 #

bool 和 enum #

bool 与 enum 都使用 int32 编码。
bool 的值编码为 0（false）或 1（true）。

有符号整数 #

Varint 本身只能表示无符号整数，如果直接把负数当成普通整数来编码，就会被视为一个很大的无符号数，占用的字节数也会增多。为了让负数也能紧凑地表示，Proto 在编码前会使用 ZigZag 进行转换，把有符号整数映射到无符号整数空间。

为什么需要这样的转换，可以先看计算机中**补码（Two’s Complement）**的表示方式：

1
2
3


5 (8位) = 00000101
补码(-5) = 2^8 + (-5) = 256 - 5 = 251
二进制 = 11111011

在 8 位系统中，-5 的补码是 11111011。如果把 5 和 -5 相加：

1
2
3
4


 00000101 (5)
+ 11111011 (-5)
-------------
1_00000000 // 忽略溢出 → 结果为 0

负数的补码设计，就是为了让它能与对应的正数直接相加得到 0。但对 Varint 来说，这个“补码”只是一个极大的无符号值（这里是 251），导致编码冗长。

ZigZag 的作用就是重新排列整数到无符号空间，让靠近 0 的正负数都能获得更短的编码。映射规律如下：

原始值	ZigZag 编码
0	0
-1	1
1	2
-2	3
…	…

计算公式（以 32 位为例）：

1

(n << 1) ^ (n >> 31)

其中：

n << 1：左移一位，为符号腾出空间。
n >> 31：提取符号位（正数全 0，负数全 1）。
异或运算保证正负数在无符号整数中交替分布。

经过 ZigZag 转换后，再用普通 Varint 编码，就能在保持正负数信息的同时，保证数值越接近 0，占用的字节越少。

固定长度类型 #

对于 double、fixed64 等需要固定大小的类型，直接占用对应的字节数：

double / fixed64 对应 wire type I64，占 8 字节。
fixed32 / float 对应 wire type I32，占 4 字节。

长度限定（Length-delimited） #

string、bytes、嵌套 message、packed repeated 等类型，使用 wire type LEN 编码。其结构是：

1

[字段头] [长度] [数据字节...]

其中长度也是 Varint 编码。

示例：

1
2
3


message Test2 {
 string b = 2;
}

当 b 的值是 "testing" 时，编码结果为：

1

12 07 74 65 73 74 69 6e 67

逐字节解释：

12：字段编号 2（binary 0010）和 wire type 2 组合
07：字符串长度 7
74 65 73 74 69 6e 67：ASCII 字符串 “testing”

嵌套 Message #

子消息字段同样使用 LEN 编码。例如：

1
2
3


message Test3 {
 Test1 c = 3;
}

若 Test1.a = 150，编码结果为：

1

1a 03 08 96 01

解释：

1a：字段编号 3，wire type 2
03：长度 3
08 96 01：子 message 的编码内容（字段 1 的值为 150）

List（repeated 字段） #

在 proto 中，repeated 表示一个字段可以重复多次，相当于列表（list）。数值类型的 repeated 字段在 proto3 中默认使用 packed 编码，这是一种更节省空间的方式。

packed 编码原理 #

packed 会把所有元素打包进一个字段，而不是为每个元素重复写入字段头。编码格式：

1

[字段头] [总长度] [值1][值2][值3]...

例如：

1
2
3


message TestList {
 repeated int32 nums = 1;
}

当 nums = [3, 270] 时，编码结果是：

1

0A 03 03 8E 02

逐字节解释：

0A：字段编号 1，wire type 2（Length-delimited）。
03：后续数据总长度为 3 个字节。
03：第一个数 3 的 Varint 编码。
8E 02：第二个数 270 的 Varint 编码。

这样只写一次字段头，比非 packed 模式（写多次字段头）更紧凑。

map #

map 在底层等价于嵌套 message 的 repeated 字段：

1
2
3


message Test6 {
 map<string, int32> g = 7;
}

实际等价于：

1
2
3
4
5
6
7


message Test6 {
 message g_Entry {
 string key = 1;
 int32 value = 2;
 }
 repeated g_Entry g = 7;
}

Proto 消息大小限制 #

单个序列化后的 Proto 消息最大不能超过 2 GiB。
超过此限制，大多数实现会拒绝序列化或解析。

参考 #

重新理解Android事件分发机制

Sun, 21 Sep 2025 20:23:17 +0800

在 Android 中，应用程序存在一个主线程（Main Thread），也被称为UI 线程。所有与界面相关的操作（如刷新 UI、响应点击）都必须在这个线程上完成。其实不仅是 Android，像 JavaScript 这样的前端运行环境也采取了类似的单线程设计。

为什么要用单线程处理 UI？ #

这样做的好处是显而易见的：

避免多个线程同时修改 UI 带来的竞争问题（比如出现界面错乱）。
减少使用锁（Lock）带来的性能损耗。

换句话说，UI 层面采用单线程串行化处理，既简化了模型，又提升了性能和稳定性。

Looper 与事件异步机制 #

Android 中的 Looper/MessageQueue 机制几乎是 Android 面试必问的内容。简单来说，Looper 通过一个消息循环（Message Loop），让事件变成异步执行。

其中有一个关键点是 同步屏障（Sync Barrier）：

当系统监听到 Vsync 信号 时，会在消息队列中插入一个同步屏障。
在屏障存在期间，普通消息无法被处理，只有特定的绘制消息能通过。
这样可以避免耗时任务阻塞绘制，从而减少掉帧（卡顿）。

Looper 的阻塞与唤醒 #

当 Looper 在消息队列中取不到下一个要处理的事件时，它并不会忙等浪费 CPU，而是进入阻塞状态。这里 Android 使用的是 epoll 机制，而不是更传统的 select 或 poll。

select、poll 与 epoll 的区别 #

select/poll：
- 通过一次次**遍历（轮询）**文件描述符（fd）集合，判断哪些 fd 可读写。
- 每次调用都需要把整个 fd 集合从用户态拷贝到内核态，维护的数据结构复杂度是 O(n)。
epoll：
- 将要监听的 fd 加入到内核的 监听列表（红黑树结构）。
- 内核在事件发生时，直接把 fd 放入 就绪列表（链表结构）。
- 应用层调用时，只需要读取就绪列表，而不必遍历所有 fd。

epoll 的两个核心优化点：

减少用户态与内核态之间的开销：只需传递发生变化的 fd，而不是整个集合。
避免轮询遍历：内核会主动通知哪些 fd 就绪，应用层只需处理这些就绪事件。

总结 #

Android 的 UI 线程采用单线程模型，保证了 UI 操作的安全与简洁。
Looper 机制通过消息循环，实现了事件的异步分发，并利用同步屏障确保绘制的流畅性。
在消息循环等待事件时，Android 采用了 epoll 机制，既避免了性能低下的轮询，又减少了内核与用户态之间的数据传递。

参考 #

WorkManager是怎样工作的

Sat, 20 Sep 2025 09:23:00 +0800

在 Android 开发中，WorkManager 是官方推荐的后台任务管理框架。它的特点是 任务可靠执行，即便应用退出或设备重启，也能保证任务最终执行。本文尝试从源码和运行机制角度梳理 WorkManager 的执行逻辑。

一个最简单的例子 #

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


class UploadWorker(appContext: Context, workerParams: WorkerParameters) :
 Worker(appContext, workerParams) {
 override fun doWork(): Result {
 // 任务逻辑
 return Result.success()
 }
}

val uploadWorkRequest: WorkRequest =
 OneTimeWorkRequestBuilder<UploadWorker>().build()

WorkManager.getInstance(this).enqueue(uploadWorkRequest)

UploadWorker：自定义任务。
enqueue()：将任务加入队列。
WorkManager 是单例，内部依赖 Application 实例，并通过 Provider.Configuration 提供配置（线程池、协程上下文等）。

WorkManager 的关键点 #

基于队列思想：和常见任务队列类似，支持依赖、状态跟踪。
持久化任务信息：任务存储在数据库中，确保系统杀进程后还能恢复。
多种调度器实现：底层通过 JobScheduler、GCM 或 AlarmManager 触发执行。

任务入队：数据库层面 #

数据库核心表：WorkSpec

WorkSpec：存储一个逻辑工作单元的全部信息（id、约束条件、状态等）。

入队时的逻辑：

依赖检查
- 确保所有父任务已经入库（通过 id 判断）。
- 根据任务名称和策略（APPEND、KEEP 等）处理冲突。
常见策略
- APPEND / APPEND_OR_REPLACE
  - 记录已有任务的依赖 id。
  - 如果依赖被取消或失败，删除相关任务。
- KEEP
  - 已有任务状态为 ENQUEUED 或 RUNNING 时，忽略新任务。
  - 否则删除旧任务，重新入库。
插入新记录
- 判断前置任务和执行状态，更新状态。
- 插入数据库（WorkSpec、依赖表、标签表、名称表）。
- 返回是否需要实际执行（state == ENQUEUED）。

任务执行过程 #

当任务需要执行时：

标记执行状态
- 队列中触发条件（如 ContentUri）满足。
- 状态非完成的任务被调度。
调度器决定执行方式 WorkManager 会在初始化时选择一个合适的 Scheduler：
- API 23+ → SystemJobScheduler (基于 JobScheduler)
- 旧设备 → 优先用 GcmScheduler（若有 GCM），否则用 SystemAlarmScheduler (基于 AlarmManager)
执行逻辑
- SystemJobScheduler
  1. 保存状态，将 WorkSpec 与系统 JobInfo 绑定。
  2. JobInfo 配置条件：
    - 充电 / 空闲 / 网络约束
    - API 29 前至少需要一个条件（默认延迟）
    - 前台任务标记
    - API 24+ 支持 ContentUri Trigger
    - API 26+ 支持低电量 / 低存储约束
  3. API 23 的特殊情况：只有当队列里有两个任务时才会触发 → 会补充一个任务保证执行。
- SystemAlarmScheduler
  - 直接通过 startService() 粗暴触发。

Worker 的创建与绑定 #

执行时，WorkManager 根据数据库中的 WorkSpec 动态创建 Worker 实例：

1
2
3
4
5


val worker = configuration.workerFactory.createWorkerWithDefaultFallback(
 appContext,
 workSpec.workerClassName,
 params
)

这里的关键点：

没有直接传递 Worker 实例，而是通过 类名反射 + WorkerFactory 创建。
数据库记录了任务的 workerClassName 和参数，确保任务可以在应用重启后恢复。

稳定执行的保障 #

WorkManager 的稳定性来源于以下几个方面：

持久化：所有任务与依赖存储在数据库中。
多重调度器适配：根据 API Level 和设备环境选择合适的调度方式。
状态机驱动：任务状态（ENQUEUED、RUNNING、FAILED、SUCCEEDED 等）严格受数据库驱动。
WorkerFactory：确保任务实例可恢复，避免直接依赖内存对象。

总结 #

WorkManager 的核心是 数据库 + 调度器：

数据库 → 保证任务信息和状态持久化。
调度器 → 保证任务在合适条件下触发执行。
WorkerFactory → 保证任务对象可恢复。

因此，无论应用进程是否被杀、设备是否重启，任务都能在条件满足时重新调度并最终执行。这也是 WorkManager 相比于直接使用 JobScheduler、AlarmManager 的最大优势。

参考：

ContentUri Trigger 官方文档

权力和权利

Fri, 19 Sep 2025 06:47:18 +0800

权力对应英文单词power，通过职位等方式获取到，能支配其他人，是有力量的。就比如警察差身份证。

权利对应right，法律、规定等规则授予的，在规则下能享受到的利益，像是~~选举权、被选举权、言论、出版、集会、结社、游行、示威~~、受教育（受教育总该有了吧）。

Android中的View加载是怎样执行的

Sun, 14 Sep 2025 18:05:28 +0800

在 Android 中，Activity 是四大组件之一，负责将视图（View）与 生命周期 关联。当一个 Activity 创建时，通常会通过 setContentView 设置内容，其本质是将一个 View 添加到系统预留的容器中。

在这个过程中，xml 文件会被解析成一个树状结构的 View。本文主要介绍 xml 布局是如何转化为 View 的。

LayoutInflater 的核心流程 #

加载 xml 布局文件时，会用到 LayoutInflater，解析逻辑就在其中。 inflate 的关键逻辑如下（简化保留核心部分）：

 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 View inflate(XmlPullParser parser, @Nullable ViewGroup root, boolean attachToRoot) {
 final String name = parser.getName();

 if (TAG_MERGE.equals(name)) {
 // merge 标签会合并到父布局中（内部不能再嵌套 merge）
 rInflate(parser, root, inflaterContext, attrs, false);
 } else {
 // 创建根节点 View
 final View temp = createViewFromTag(root, name, inflaterContext, attrs);

 ViewGroup.LayoutParams params = null;
 if (root != null) {
 params = root.generateLayoutParams(attrs);
 if (!attachToRoot) {
 temp.setLayoutParams(params);
 }
 }

 // 解析子节点
 rInflateChildren(parser, temp, attrs, true);

 if (root != null && attachToRoot) {
 root.addView(temp, params);
 }

 return (root == null || !attachToRoot) ? temp : root;
 }
}

这里可以看到分为两种情况：

merge 标签：直接展开合并到父布局，内部不能再嵌套 merge。
普通标签：通过 createViewFromTag 创建根节点，然后递归解析子节点。

rInflate 的解析子节点逻辑 #

rInflate 方法中，会继续递归创建子 View 并添加到父容器：

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


// LayoutInflater.java
void rInflate(XmlPullParser parser, View parent, Context context, AttributeSet attrs, boolean finishInflate) {
 final View view = createViewFromTag(parent, name, context, attrs);
 final ViewGroup viewGroup = (ViewGroup) parent;
 final ViewGroup.LayoutParams params = viewGroup.generateLayoutParams(attrs);

 // 递归解析子节点
 rInflateChildren(parser, view, attrs, true);

 // 添加到父容器
 viewGroup.addView(view, params);
}

而 rInflateChildren 只是对 rInflate 的再封装：

1
2
3


final void rInflateChildren(XmlPullParser parser, View parent, AttributeSet attrs, boolean finishInflate) {
 rInflate(parser, parent, parent.getContext(), attrs, finishInflate);
}

View 的创建方式 #

在创建 View 时，分为两类：

常见控件（TextView、ImageView、Button 等）：通过 AppCompatViewInflater 的枚举分支直接创建。
其他自定义或不在枚举中的控件：通过反射调用构造方法创建。

这也是为什么所有自定义 View 必须要有 固定签名的构造方法（如 (Context context, AttributeSet attrs)）。

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


private View createViewByPrefix(Context context, String name, String prefix) {
 Constructor<? extends View> constructor = sConstructorMap.get(name);

 if (constructor == null) {
 Class<? extends View> clazz = Class.forName(
 prefix != null ? (prefix + name) : name,
 false,
 context.getClassLoader()
 ).asSubclass(View.class);

 constructor = clazz.getConstructor(sConstructorSignature);
 sConstructorMap.put(name, constructor);
 }

 constructor.setAccessible(true);
 return constructor.newInstance(mConstructorArgs);
}

其他细节 #

如果 xml 中定义了 android:onClick，会在这里解析并绑定对应的方法（虽然现在已经很少使用这种写法）。
布局文件中所有非 merge 根节点及其子 View，最终都会通过 rInflate 的递归过程，逐一生成并挂载到父容器。

技术文章的价值思考

Tue, 09 Sep 2025 21:08:34 +0800

前几天我看到一个帖子，讨论的问题是：“在 AI 时代，技术文章还有必要吗？” 这是个有些“老派”的提法，但依然引起了不少人讨论。大多数人的观点是：没什么必要了。因为相比 AI 掌握的庞大知识，技术文章的那点内容微不足道。

我并不认同这种看法。可以从“读的人”和“写的人”两个角度来理解：

首先，从读者的角度看。 AI 的确在训练过程中使用了海量资料，再加上 RAG 技术的加持，让它仿佛拥有了超越个人的知识广度。但这些知识从何而来？它们的源头还是人类。网络上的文章、文档、讨论帖子，都是人们写下来的知识积累。如果没有最初愿意输出的那群人，就不会有今天 AI 能够回答的内容。换句话说，我们写下的东西，未来也可能成为 AI 学习的素材，从而帮助更多人。

其次，从作者的角度看。把知识系统化地写出来，本身就是一种训练和挑战。会用，不等于会讲；“以为理解”和“真正理解”之间的差距，往往要靠能否清晰地输出内容来检验。写文章正是这样一种方式。对程序员来说，很多知识如果不尝试写下来，是很难发现自己理解的深度的。同时，好的文章也能在一定程度上提升个人的竞争力。

当然，文章写得深还是浅，都会有对应的受众。只是我个人并不喜欢那种东拼西凑的内容——随便拿几张图一搜，发现好几篇文章几乎一模一样，这样的写作价值不大。但能把一件事讲得比别人更清楚，那本身就是一种能力。

Kotlin泛型和reified

Wed, 03 Sep 2025 21:48:16 +0800

Generics were introduced to the Java language to provide tighter type checks at compile time and to support generic programming. To implement generics, the Java compiler applies type erasure to:

Replace all type parameters in generic types with their bounds or Object if the type parameters are unbounded. The produced bytecode, therefore, contains only ordinary classes, interfaces, and methods.

Insert type casts if necessary to preserve type safety.

Generate bridge methods to preserve polymorphism in extended generic types.

Type erasure ensures that no new classes are created for parameterized types; consequently, generics incur no runtime overhead.

Type Erasure (The Java™ Tutorials > Learning the Java Language > Generics (Updated))

由于泛型在编译后会被擦除，如果没有定义边界，就会被替换为 Object，因此在运行时无法获取具体的类型信息。Kotlin 的泛型实现同样遵循这一规则。

当我们尝试写一个扩展函数来启动 Activity 时，就会遇到这个问题：

1
2
3
4
5


inline fun <T : Activity> Activity.startActivity(block: ((Intent) -> Unit) = {}) {
 val intent = Intent(this, T::class.java) // IDE 会报错
 block.invoke(intent)
 startActivity(intent)
}

这里会报错，是因为在运行时无法确定 T 的具体类型，也就不知道要启动哪个 Activity。

Kotlin 提供了 reified 关键字来解决这个问题，它允许在内联函数中保留泛型的实际类型，从而在运行时使用：

1
2
3
4
5


inline fun <reified T : Activity> Activity.startActivity(block: ((Intent) -> Unit) = {}) {
 val intent = Intent(this, T::class.java)
 block.invoke(intent)
 startActivity(intent)
}

调用方式如下：

1
2
3


fun Activity.startMainActivity() {
 startActivity<MainActivity>()
}

反编译成 Java 代码后，大致如下：

1
2
3
4
5


public static final void startMainActivity(@NotNull Activity $this$startMainActivity) {
 Intrinsics.checkNotNullParameter($this$startMainActivity, "<this>");
 Intent intent$iv = new Intent((Context)$this$startMainActivity, MainActivity.class);
 $this$startMainActivity.startActivity(intent$iv);
}

可以看到，reified 的作用是把泛型类型直接写进了代码中，从而在运行时可以获取具体的 Class 对象。

需要注意的是，如果我们只是使用泛型实例的方法，并不需要具体类型信息，就不会有问题：

1
2
3


fun <T : Activity> finish(t: T) {
 t.finish()
}

这里编译器能够正常处理，因为我们并不是在运行时获取类型，而是调用泛型实例的成员方法。Java 的继承机制保证了 Activity 的子类都可以访问 finish() 方法，所以实例方法不会受类型擦除的影响。

Java中的泛型在编译后是会被擦除的，如果没有定义边界，会被用Object取代，因此没有办法在运行时获取类的信息，Kotlin同理。

当定义一个扩展方法启动activity时，也就拿不到真实的类型。

1
2
3
4
5


inline fun <T : Activity> Activity.startActivity(block: ((Intent) -> Unit) = {}) {
 val intent = Intent(this, T::class.java)
 block.invoke(intent)
 startActivity(intent)
}

当这样写时，IDE会提示错误，因为不知道T具体的类型，也就不知道启动的是哪个Activity。

Kotlin中新增了关键字reified解决这种状况。

1
2
3
4
5


inline fun <reified T : Activity> Activity.startActivity(block: ((Intent) -> Unit) = {}) {
 val intent = Intent(this, T::class.java)
 block.invoke(intent)
 startActivity(intent)
}

实际上，这种写法是将传入的类，写在了代码中。来调用该方法

1
2
3


fun Activity.startMainActivity() {
 startActivity<MainActivity>()
}

借助反编译看对应的Java代码

1
2
3
4
5
6
7


 public static final void startMainActivity(@NotNull Activity $this$startMainActivity) {
 Intrinsics.checkNotNullParameter($this$startMainActivity, "<this>");
 int $i$f$startActivity = 0;
 Intent intent$iv = new Intent((Context)$this$startMainActivity, MainActivity.class);
 int var5 = 0;
 $this$startMainActivity.startActivity(intent$iv);
 }

当需要一个泛型的实例时，有些差别。

1
2
3


fun <T : Activity> finish(t: T) {
 t.finish()
}

上面的代码是可以正常编译执行的。和上面启动Activity的是不同的。上面的方法需要的是一个类型，如果不知道具体的类型就不知道要启动哪个Activity。这里执行的是泛型实例的一个方法，泛型只是把类型用边界类代替了，finish()方法Activity还是会提供的，Java继承的特性导致Activity的字类都可以访问到，也就是说实例方法是不受影响的。

flutter渲染和布局

Sun, 31 Aug 2025 11:56:40 +0800

原文：Flutter architectural overview | Flutter

本节描述了Flutter的渲染管道，即将一层层的Widgets层级转换为实际绘制在屏幕上的像素的系列步骤。

Flutter的渲染模型 #

你可能会好奇：如果Flutter是一个跨平台框架，它是如何实现和单平台框架接近的性能呢？

首先了解传统Android应用的工作方式是很有帮助的。当进行绘制时，你会先调用Android框架的Java代码。Android系统库提供了一些组件，它们负责将内容绘制到一个Canvas对象上，之后Android会调用Skia（一个用C/C++编写的图形引擎）通过CPU或GPU将内容绘制到设备上。

跨平台框架通常通过在底层的原生Android和iOS UI库之上创建一个抽象层来工作，试图平滑处理各个平台UI表示之间的不一致。应用代码通常用解释型语言（如JavaScript）编写，并且必须与Java语言的Android库或Objective-C语言的iOS系统库交互来呈现UI。所有这些会增加显著的开销，尤其是在应用的UI与逻辑有大量交互时。

相比之下，Flutter通过尽量减少这些抽象层来提升性能。在其设计中，Flutter绕过原生的系统UI部件库，直接使用自己的插件化小组件集合（Widget）。Flutter的Dart代码会被编译为原生代码，并利用名为Impeller的渲染引擎进行渲染。Impeller随应用一起提供，这使开发者即使在终端设备没有升级到最新系统版本时，也能依赖Flutter框架轻松推进应用性能的改进。这种方式同样适用于Flutter运行在其他原生平台上（如Windows或macOS）。

注意想了解Impeller支持哪些设备？请查看我可以使用Impeller吗？。更多内容请访问Impeller 渲染引擎。

从用户输入到GPU #

Flutter的渲染管道遵循的核心原则是简单即高效。Flutter为数据流向系统的过程设计了一个简洁的管道，如下图所示：

接下来我们将更详细地了解其中一些阶段。

考虑以下一个展示组件层级的代码片段：

1
2
3
4
5
6
7
8
9


Container(
 color: Colors.blue,
 child: Row(
 children: [
 Image.network('https://www.example.com/1.png'),
 const Text('A'),
 ],
 ),
);

当Flutter需要渲染这一片段时，它会调用build()方法，该方法返回一棵基于当前应用状态的UI子树。构建过程中，build()方法可以根据状态引入新的组件。例如，在上述代码片段中，Container具有color 和 child 属性。查看Container 的源码，可以发现当Color不为空时，它会插入一个代表此颜色的ColoredBox：

1
2


if (color != null)
 current = ColoredBox(color: color!, child: current);

类似地，Image和Text组件在构建过程中可能会插入子组件，例如RawImage和RichText。因此真实的组件层级可能比代码表面上看起来更深，如下所示^[2]：

这解释了为什么通过调试工具（如Flutter inspector）检查组件树时，你可能看到的结构要比你代码中写出的深得多。

在构建阶段，Flutter将代码中表达的组件翻译为对应的Element 树，每个组件都有一个对应的Element实例。每个Element代表组件树某个位置上某个组件的特定实例。Element主要有两种类型：

ComponentElement：用于承载其他元素。
RenderObjectElement：参与布局或绘制阶段的元素。

RenderObjectElement是其对应的Widget和底层RenderObject之间的中介。

任何组件的Element可以通过它的BuildContext进行引用，BuildContext是树中组件位置的句柄。例如，在调用Theme.of(context)时使用的context，就是传递给build()方法的参数。

由于Flutter的组件是不可变的（包括节点间的父/子关系），任何对组件树的更改（如将Text('A')改成Text('B')）都会返回一组新的组件对象。这并不意味着底层表示会完全重建。Element树从一个渲染帧到下一帧是持久化的，这在性能优化中起着重要作用。Flutter只会遍历发生变化的Widget，重新配置需要调整的Element树部分。

布局和渲染 #

在一个应用中，仅绘制单个组件的情况很少见。因此，任何UI框架的重要特性之一就是高效地布局整个组件树，确定每个元素在屏幕上的大小和位置。

每个渲染树节点的基础类是RenderObject，它定义了一个抽象模型用于布局和绘制。这个模型非常通用：它并不限定维度的数量，甚至不固定使用直角坐标系（例如使用极坐标系统的示例）。每个RenderObject只了解它的父节点，但对子节点知之甚少，除了知道如何“访问”它们以及它们的约束条件。这种抽象使得RenderObject能够应对多种用例。

在构建阶段，Flutter会为Element树中的每个RenderObjectElement创建或更新一个继承自RenderObject的对象。RenderObject是基础的渲染单位，例如：

RenderParagraph：用于渲染文本；
RenderImage：用于渲染图像；
RenderTransform：对子组件进行变换后绘制。

大多数Flutter组件由继承自RenderBox的对象进行渲染，RenderBox是二维笛卡尔空间中固定大小的渲染对象。RenderBox提供了一个盒约束模型，规定了每个组件在渲染时的最小和最大宽高。

在布局时，Flutter会以深度优先的顺序遍历渲染树，并从父节点向子节点向下传递大小约束。子节点在确定其大小时，必须遵守父节点提供的约束。子节点随后会通过向父节点 向上传递大小 进行响应，并且约束在子节点中得到了应用。

在单次遍历树之后，每个对象已根据父节点的约束条件定义了自己的大小，并准备通过调用paint()方法进行绘制。

盒约束模型是一种强大的组件布局机制，其效率可达O(n) ：

父组件可以通过将最大和最小尺寸设置为相同的值来完全控制一个子组件的尺寸。例如，顶层渲染对象会将其子组件的尺寸约束限定为整个屏幕大小，（子组件可以选择如何利用该空间，例如将要渲染的内容居中显示）。
父节点可以限制子节点的宽度，同时允许其对高度有一定的弹性（或相反）。一个实际的例子是流式文本，它可能需要适应水平约束但可以根据文本数量调整垂直方向。

即使在某些情况下子对象需要知道可用空间大小以决定内容的呈现方式，盒约束模型也能够正常工作。通过使用LayoutBuilder组件，子对象可以检查传递下来的约束并依据约束决定其呈现方式，例如：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


Widget build(BuildContext context) {
 return LayoutBuilder(
 builder: (context, constraints) {
 if (constraints.maxWidth < 600) {
 return const OneColumnLayout();
 } else {
 return const TwoColumnLayout();
 }
 },
 );
}

更多关于约束与布局系统的信息和示例，请参考理解约束。

所有RenderObject的根节点是RenderView，它代表整个渲染树的输出。当平台要求新帧被渲染时（例如由于垂直同步（vsync）或纹理解压缩/上传完成），会调用渲染树根节点RenderView对象的compositeFrame()方法。这会创建一个SceneBuilder以触发场景更新。当场景完成后，RenderView对象会将合成的场景传递给dart:ui中的Window.render()方法，并将控制权交给GPU以完成渲染。

关于渲染管道中合成和光栅化阶段的详细内容超出了本高层次概述的范围，更多信息可参见Flutter渲染管线的视频演讲。

Fragment的故事

Sun, 24 Aug 2025 15:04:08 +0800

Fragment 在原生 Android 开发中一直占有一席之地。像 ViewPager2、Dialog 都依赖 Fragment 来实现。虽然在实现底部导航（Bottom Navigation）时，ViewPager2 配合 Fragment 有一些小坑，但这并不影响 Fragment 在 Android 体系中的地位。

既然 Fragment 这么重要，就有必要深入了解它的奥秘。这篇文章就是一次探索。

联系 #

Fragment 的 add、replace、remove、show、hide 等操作，全部依赖 FragmentManager。要理解 Fragment，绕不开 FragmentManager。

上图展示了 Activity 与 FragmentManager 的关系。FragmentActivity 通过 FragmentController 来更新 Fragment 状态，也会依赖 FragmentHostCallback 来获取宿主信息（例如 Fragment 数量等）。

接下来看看 FragmentHostCallback。它其实是一个泛型类，泛型参数 <E> 一般代表宿主类型（通常是 Activity）。它本身并不对泛型做具体逻辑处理，而是充当桥梁——比如 Fragment 在获取 LayoutInflater 时需要一个 Context，这里传入的就是 Activity；Fragment 启动 Activity 的本质，也是通过宿主提供的方法来完成的。

再说大家最熟悉的 FragmentManager。

早期获取方式是 getFragmentManager()，对应 android.app.Fragment，现已废弃。
现在统一推荐 getSupportFragmentManager()，来自 AndroidX 的 FragmentActivity，对应 androidx.fragment.app.Fragment。

所以，不是“官方只是标记废弃”，而是 AndroidX 迁移之后，旧版被弃用，新版才是维护方向。

在日常开发中，我们最常用的就是 add、replace、remove 等方法。但实际上，FragmentManager 还负责：

管理 Fragment 的生命周期更新
保存和恢复状态
权限请求、画中画支持
Activity/Fragment 重建时的恢复

真正的核心远不止几个增删操作。

FragmentTransaction #

我们以一个常见的例子为起点：

1
2
3
4


supportFragmentManager.beginTransaction()
 .add(R.id.container, MyFragment())
 .add(R.id.container_b, MyFragment())
 .commit()

这里 beginTransaction() 会先创建一个 FragmentTransaction 实例。这个实例可以收集多个操作（Op），最后通过 commit 一次性提交。

add、replace、remove 等方法本质上都会封装成一个个 Op，记录操作类型和对应的 Fragment。真正执行是在调用 commit 系列方法时。

commit 系列方法 #

几个方法的区别如下：

commit() 把事务加入队列，稍后在主线程安全时异步执行。如果此时状态已经保存（比如在 onSaveInstanceState 之后），会抛出异常。
commitAllowingStateLoss() 与 commit() 类似，但不会因为状态已保存而报错，可能导致状态丢失。
commitNow() 立即执行事务，且会强制在所有挂起的异步事务之前完成。但它不允许再提交异步事务，否则会冲突。
commitNowAllowingStateLoss() 同上，只是允许在已保存状态后执行，可能造成状态丢失。

这样看下来，Fragment 的背后其实是一套完整的状态机，由 FragmentManager 统筹调度，FragmentHostCallback 作为宿主桥梁，FragmentTransaction 负责操作封装。我们日常写的一行 add()，实际上都在这套复杂机制中被逐步拆解和执行。

举报和被举报的

Sat, 23 Aug 2025 21:17:03 +0800

最近遇到一件有意思的事。自疫情开始，我一直在听梁文道的音频节目《八分》，今年他推出了付费版本《八分半》，犹豫了一阵子后，我订阅了。

一直以来相安无事，直到最近节目被全平台下架。有人猜测，是因为在蔡澜去世的那一期节目里，道长（梁文道）谈到了香港，提到了《苹果日报》的老板。我觉得这种说法可信度很高，因为如今的“爱国”已经到了空前的高度。

节目是付费的，承诺至少有 80 期。截至下架时（不含番外），已经播出了 72 期，还差了 8 期。于是制作团队通过小宇宙发出调查问卷，询问有多少人希望退款，不再听剩下的节目，也不会有额外内容。奇怪的是，这份调查问卷居然也被举报，链接一度无法访问。随后在周六（2025.8.23）下午，制作团队又重新发出了一份。

节目被举报已经让我很不解，更让我费解的是，连调查问卷也能被举报。我实在想不通，这样做是为了什么？是想让退款的朋友拿不到退款吗？还是说，单纯厌恶梁文道到这种程度？如果只是厌恶他，那举报调查问卷又和节目内容有什么关系呢？看到推送消息的时候，我只能无奈地笑了。

最后我只能把“举报”理解为一种无法接纳他人观点的表现。就好像在某些人的脑子里，有一张列有关键字的清单：一有清单上的话题被讨论，就触发了什么开关。不光自己不能谈，其他人谈也是不被允许的。看来这期节目恰好命中了。可惜的是我听过了整个节目，却不觉得哪里又不妥的说法。

播客我几乎只听这一档。我喜欢它的原因很简单：不是因为它告诉我对错，而是它让我反思。梁文道在很多问题上的角度和拆解方式独特又深刻，至少值得我学习。或许正是因为我在很多方面保有与他相近的看法，因此才会认同，这其中也包括一些平时并不容易被接受的观点。

现如今的环境，越来越恶劣。许多方面都受到限制。又不说什么能谈、什么不能谈，于是为了避开这些所谓敏感内容，只得采用更严格的标准。甚至是改用缩写，还有说谜语。内容来源有限，能发声的媒体越来越少，互相抄来抄去。像在屎上雕花，结果就是今天的中文互联网，充斥着重复、浅薄、泛娱乐的内容，以及让人激情澎湃的口号。

不知从什么时候开始，讨论变得格外敏感。今天讨论这个明星，明天讨论那个明星，这个综艺节目多好看等等。除此之外就是“爱国“。你可以放弃利益，会要求民族尊严，不容许伤害民族感情的事发生，和国家的方向一致。即使事一个为了生计发愁的人，也可以在国际关系上说得头头是道。

可“爱国”到底是什么呢？你知道吗？是保卫政府吗？那辛亥革命、内战又是什么？如果不是，什么才是爱国？这个国家难道不是由我们这些人一起组成的吗，我们不正是国家的一份子吗？

还有另一个现象：当糟糕的事情发生时，很多人不是去分辨是非，而是直接指责对方，好像自己永远是受害者。

当真相揭露时，还得有人去‘闹’才行。原本难以推动的事，一旦闹起来，结果往往就真会不同。在这样的氛围里，对与错本身似乎不再重要，重要的只是‘能不能闹出效果’。

AI入门指南：从零开始理解人工智能

Thu, 21 Aug 2025 21:06:58 +0800

人工智能（英语：artificial intelligence，缩写为AI^{(英语文本)}），指由人造机器所展现的智能。通常人工智能是指用普通计算机程序来呈现人类智能的技术。该词也指出研究这样的智能系统是否能够实现，以及如何实现。

这是维基百科对AI的解释，简单来说AI就是具备类似人类解决问题能力的技术。像是翻译、写代码等等等等。

在 AI 的发展过程中，Transformer 是一个极为重要的里程碑。目前的大模型，如 GPT、Claude，都是基于 Transformer 架构构建的。

Transformer 最初是 Google 为机器翻译任务提出的模型结构。翻译并不是逐字对应的，比如要翻译“知识就是力量”，单独看“知”并不能确定含义，必须结合前后词语才能得到准确的翻译。这种机制就是自注意力机制，它让模型在处理某个词时，能够“关注”到上下文中的其他词。下面是一张形象的动图：

AI 生成内容的过程，本质上就是一种“文字接龙”。在训练时，文本会被编码成向量，输入的句子会被分词成一个个词元（token），也就是常说的 token。需要注意的是，token 并不等同于词语，不同的分词方式可能会得到不同的 token。

由于生成过程是基于概率拼接的“文字接龙”，产出的内容有时可能并不存在或不真实，这种现象被称为 AI 的幻觉（hallucination） 。另外，AI 的训练数据通常截止到某一时间点，因此知识存在时效性。如果希望模型能够使用最新信息，可以通过检索增强生成（Retrieval-Augmented Generation，RAG） ，让模型在回答问题时参考外部资料，从而提高正确性和时效性。

AI 生成中的幻觉 vs RAG 解决方案 #

情况	现象（幻觉）	RAG 的作用
过时的知识	模型的训练数据截止到某个时间，回答可能已经过时。例如：问“2025年奥运会在哪举办？”，模型可能回答错误。	通过检索外部资料（数据库、搜索引擎、文档），获取最新信息，再结合模型生成，确保答案更及时。
编造事实	模型会“接龙”拼出听起来合理但实际上不存在的信息。例如：捏造一篇不存在的论文或一本虚构的书。	模型先检索相关文档，再基于真实资料生成回答，避免无中生有。
缺乏细节	模型知道大概方向，但具体数据或内容错误。例如：回答某个法律条款时给出错误的条文号。	从权威数据源中检索原始文本，再由模型组织语言，确保细节准确。
模糊回答	当训练数据不足时，模型可能给出模糊甚至前后矛盾的回答。	RAG 可以补充来自专业文档或知识库的上下文，使回答更具体、更可靠。

训练 AI 一般分为两个主要阶段：预训练（pre-training）和微调（fine-tuning） 。

预训练（pre-training） ：向模型输入海量未标注的文本（通常会经过人工或自动方式过滤掉有害和重复内容），可以理解为给 AI 灌输知识。这种基于原始文本（raw text） 、不依赖人工标注的训练方式叫做自监督学习（self-supervised learning） 。经过这一阶段得到的模型称为基础模型（base model） 。它已经掌握了大量知识，但在回答问题时往往不符合人类预期，因为它并不知道你是在“提问”。这时，**提示词（prompt）**就能发挥关键作用。
监督微调（supervised fine-tuning, SFT） ：在基础模型的基础上，使用少量带人工标注的数据进行训练，让模型学会按照人类的指令来回答问题。这个过程叫做监督学习（supervised learning） ，结果是一个能更好理解人类意图的模型。
基于人类反馈的强化学习（RLHF） ：单纯的监督微调仍然有限，因为人工标注的数据不可能覆盖所有情况。于是引入 RLHF：
1. 让多个回答由模型生成；
2. 人类对这些回答进行打分，训练一个奖励模型（reward model） ；
3. 模型在生成答案时会根据奖励模型的反馈进行优化。这样，模型不仅能理解人类指令，还能更好地对齐人类的价值观和偏好。

参考 #

LeakCanary检测到内存泄漏之后发生了什么

Sun, 17 Aug 2025 07:48:03 +0800

检测 #

LeakCanary 是 Android 开发中最常用的内存泄漏检测工具之一。由于在 dump 内存快照时需要 挂起所有线程，这会带来明显的卡顿，因此它通常只在开发和调试阶段启用。

涉及到的类型有弱引用、引用队列和一个map。像是这样：

1

 private val watchedObjects: MutableMap<String, KeyedWeakReference> = ConcurrentHashMap()

弱引用不会影响对象是否被回收，当弱引用被清理之后，弱引用会被添加进关联的弱引用队列。Leak Canary用到的弱引用类型KeyedWeakReference是WeakReference的一个子类，增加了key。弱引用的key也是watchedObjects的key，于是对象、弱引用、map几个关键信息就联系起来。

利用带有 key 的弱引用和引用队列，可以识别出哪些对象已经被回收。因为 key 是唯一的，所以一旦弱引用进入引用队列，就能从 watchedObjects 中移除对应的键值对。这样，watchedObjects 中剩下的条目就代表仍未被回收的对象，它们就是潜在的泄漏候选。

LeakCanary 借助 Lifecycle 回调，在 onDestroy() 时机清理引用队列中（已经被回收的）弱引用，并将对应条目从 watchedObjects 中移除。理论上，正常销毁的对象在这一步之后就不会再出现在 watchedObjects 中。随后 LeakCanary 会延迟一段时间（默认 5s）再次检查，如果仍然发现有 Activity 的弱引用留存，说明对象未能被 GC，存在内存泄漏，于是触发 dump 内存快照，并开始分析引用链路。

dump内存快照 #

这一步本质上是调用 Android 提供的 API 来生成 hprof 文件，相对比较“机械”，没有太多自定义逻辑。

分析内存快照 #

dump后发送消息，开始分析内存快照。

解析拿到header，包含时间戳、版本、标识(分辨字符串、对象、stack traces)信息;
找到和几种GC Root类型的关联的record，实际上是找到每种类型开始的index，存在一个数据类中一并返回;
找出泄露对象的id，默认实现先找出KeyedWeakReference类型的实例，再找出判定认为已经泄露的对象;
计算泄漏对象到 GC Roots 的最短路径，从而定位出内存泄漏的根因链路。

GC Root类型：

HprofRecordTag.ROOT_JNI_GLOBAL,
HprofRecordTag.ROOT_JAVA_FRAME,
HprofRecordTag.ROOT_JNI_LOCAL,
HprofRecordTag.ROOT_MONITOR_USED,
HprofRecordTag.ROOT_NATIVE_STACK,
HprofRecordTag.ROOT_STICKY_CLASS,
HprofRecordTag.ROOT_THREAD_BLOCK,
HprofRecordTROOT_THREAD_OBJECT,
HprofRecordTag.ROOT_JNI_MONITOR

找最短路径 #

前面步骤大多是按照 hprof 格式和 tag 规则解析数据，而“最短路径”这一环节则更关键，决定了我们如何解释泄漏对象与 GC Roots 的关系，因此单独展开。

 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


 private fun State.findPathsFromGcRoots(): PathFindingResults {
 enqueueGcRoots()

 val shortestPathsToLeakingObjects = mutableListOf<ReferencePathNode>()
 visitingQueue@ while (queuesNotEmpty) {
 val node = poll()
 if (leakingObjectIds.contains(node.objectId)) {
 shortestPathsToLeakingObjects.add(node)
 // Found all refs, stop searching (unless computing retained size)
 if (shortestPathsToLeakingObjects.size == leakingObjectIds.size()) {
 if (computeRetainedHeapSize) {
 listener.onEvent(StartedFindingDominators)
 } else {
 break@visitingQueue
 }
 }
 }

 val heapObject = try {
 graph.findObjectById(node.objectId)
 } catch (objectIdNotFound: IllegalArgumentException) {
 // This should never happen (a heap should only have references to objects that exist)
 // but when it does happen, let's at least display how we got there.
 throw RuntimeException(graph.invalidObjectIdErrorMessage(node), objectIdNotFound)
 }
 objectReferenceReader.read(heapObject).forEach { reference ->
 val newNode = ChildNode(
 objectId = reference.valueObjectId,
 parent = node,
 lazyDetailsResolver = reference.lazyDetailsResolver
 )
 enqueue(
 node = newNode,
 isLowPriority = reference.isLowPriority,
 isLeafObject = reference.isLeafObject
 )
 }
 }
 return PathFindingResults(
 shortestPathsToLeakingObjects,
 if (visitTracker is Dominated) visitTracker.dominatorTree else null
 )
 }

LeakCanary中查找是有两个队列，分高低优先级，先从高优先级中找出路径，高优先级队为空才会从低优先级队列中找。贴上关键代码：

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


private fun State.poll():ReferencePathNode {
 return if (!visitingLast &&!toVisitQueue.isEmpty()) {
 val removedNode = toVisitQueuepoll()
 toVisitSet.remove(removedNodeobjectId)
 removedNode
 } else {
 visitingLast = true
 val removedNode =toVisitLastQueue.poll()
 toVisitLastSet.remov(removedNode.objectId)
 removedNode
 }
}

toVisitQueuepoll和toVisitLastQueue即是高低优先级的队列。

队列中添加元素是怎么执行的呢？

同样贴上代码：

 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


return sortedGcRoots(graph).asSequence().mapNotNull { (heapObject, gcRoot) ->
 when (gcRoot) {
 // Note: in sortedGcRoots we already filter out any java frame that has an associated
 // thread. These are the remaining ones (shouldn't be any, this is just in case).
 is JavaFrame -> {
 GcRootReference(
 gcRoot,
 isLowPriority = true,
 matchedLibraryLeak = null
 )
 }
 is JniGlobal -> {
 val referenceMatcher = when (heapObject) {
 is HeapClass -> jniGlobalReferenceMatchers[heapObject.name]
 is HeapInstance -> jniGlobalReferenceMatchers[heapObject.instanceClassName]
 is HeapObjectArray -> jniGlobalReferenceMatchers[heapObject.arrayClassName]
 is HeapPrimitiveArray -> jniGlobalReferenceMatchers[heapObject.arrayClassName]
 }
 if (referenceMatcher !is IgnoredReferenceMatcher) {
 if (referenceMatcher is LibraryLeakReferenceMatcher) {
 GcRootReference(
 gcRoot,
 isLowPriority = true,
 matchedLibraryLeak = referenceMatcher
 )
 } else {
 GcRootReference(
 gcRoot,
 isLowPriority = false,
 matchedLibraryLeak = null
 )
 }
 } else {
 null
 }
 }
 else -> {
 GcRootReference(
 gcRoot,
 isLowPriority = false,
 matchedLibraryLeak = null
 )
 }
 }
 }

返回值是 GcRootReference，其中的 isLowPriority 字段决定了该引用进入高优先级还是低优先级队列。规则是：

“JNI Global + 匹配已知库泄漏 → 标记为低优先级（通常是外部库的已知问题，不需要第一时间关注）；”
“JNI Global + 非已知库 → 高优先级；”
“其他 GC Root → 默认高优先级。”

匹配规则参考：shark:shark.AndroidReferenceMatchers.kt

在 findPathsFromGcRoots 中可以看到 enqueue 的调用，这是因为 LeakCanary 使用 BFS（广度优先搜索） 来遍历引用链。BFS 的特性保证了：第一次找到的泄漏对象路径就是最短路径，因此无需回溯或额外计算。

Google Play 企业开发者账号注册踩坑记录

Sat, 16 Aug 2025 19:59:28 +0800

注册企业账号 #

注册企业账号的第一步仍然是注册一个 Google 账号，这个过程比较简单。随后再进入 Google Play Console 注册开发者账号时，需要在个人开发者和企业开发者之间选择。网上关于个人账号的经验文章很多，这里主要记录企业开发者的流程和坑点。

邓白氏编码（D-U-N-S） #

企业账号与个人账号最大的区别在于：企业必须提供邓白氏编码（D-U-N-S Number） 。邓白氏编码可以理解为企业在全球范围内的唯一身份识别码，由 Dun & Bradstreet 管理，被广泛用于 Google、Apple、联合国、欧盟等组织的企业认证。

目前如果直接在邓白氏官方为 “Google Play” 申请，系统会引导至某个上海的合作公司，需要支付大约 9000 元/年的费用。网络上曾经有人提到过免费的官方申请入口，但现在已经不可行了。

那有没有免费的方式？答案是有的，可以“曲线救国”：通过苹果开发者平台注册时申请 D-U-N-S 编码。一旦通过，Google Play 也能识别同一个企业的 D-U-N-S 编码。

关于付费和免费的差异，邓白氏销售的说法是：编码对每个企业都是唯一的，区别在于付费申请能提升信息可信度，更容易被一些平台认可。

支付注册费用 #

Google Play 开发者账号本身需要支付 25 美元注册费，这一步相对宽松。注意事项：

付款时需要填写卡片信息（卡号、有效期、安全码和账单地址），地址必须和卡片一致。
不要求持卡人必须是企业相关人员。
除银联外几乎所有卡组织都支持，可用外币卡，也可以用虚拟卡。
如果没有外币卡，可以通过浦发信用卡 APP「喜大普奔」申请虚拟信用卡完成支付。

填写企业信息 #

企业信息如实填写即可。

邮箱：可以使用非企业邮箱，但需要额外的验证码验证；用企业邮箱则更方便。
联系方式：推荐填写手机号，因为后续需要接收短信验证码完成验证。

此外，在创建应用之前，Google 还要求验证企业官网。最常见的方式是：在网站服务器的 header 或特定路径下增加 Google 指定的内容，操作简单，基本能顺利完成。

Kotlin的枚举、密封类和密封接口

Fri, 08 Aug 2025 20:29:13 +0800

枚举 #

下面涉及到的语言均是Kotlin，理论上Kotlin和Java在枚举中具有的功能是相同的。

说到枚举，就有先入为主的概念，认为枚举只能定义两个简单的状态，像是下面这样：

1
2
3


enum class State{
 OPEN, CLOSE;
}

其实不是这样的，这只是最最基本的用法，把枚举当做常量使用了。

变量 #

枚举中是可以定义变量的。

1
2
3
4
5


enum class State(val value:Int){
 Success(0), Fail(1);
}

printf(State.Success.value)

在Kotlin语言中，如果构造方法中出现val了，这个类就会增加一个变量。枚举也是一样的，上面就为枚举类增加了一个value的变量，而且是val的，不可以修改值的。

既然可以是val，是不是也可以是var呢，是可以的。

1
2
3
4
5


fun main() {
 println(State.Success.value)
 State.Success.value = 2
 println(State.Success.value)
}

打印的结果如下：

方法 #

枚举中不只可以有变量，同样也可以有方法。

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


enum class State(var value: Int) {
 Success(0), Failed(1);

 fun greeting() {
 println("hello, this is $value")
 }
}

fun main() {
 State.Success.greeting()
 State.Fail.greeting()
}

打印出结果：

1
2


hello, this is 0
hello, this is 1

可能已经开始混乱了，这和我用的枚举不一样啊。是不一样，枚举不只是一个常量，它也是个类。

不妨转换一下思路，枚举(State)首先是一个类，枚举中的每个常量(Success, Fail)也是一个类型，是只有一个实例的类型，而这个实例就是它本身。为了要保证每一个类型都只被创建一次，构造方法是被限制的，没有办法创建出相同类型的第二个实例，还是那上面的例子，Success就是一种类型，这个类型的实例是Success，也只有这么一个实例。

类型会有方法的重写。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


enum class State(var value: Int) {
 Success(0){
 override fun greeting() {
 println("success never greeting")
 }
 }, Fail(1);

 open fun greeting() {
 println("hello, this is $value")
 }
}

输出就变成了

1
2


success never greeting
hello, this is 1

⚠️枚举类中的常量是需要首先声明的。也就是要先声明Success和Fail，然后才可以是声明greeting方法。

枚举类适用的场景就是根据它有限个常量的特性，常用到的像是标识状态，也可以用作实现状态模式（前面提到可以重写方法）。

密封类 #

密封类开始是Kotlin的概念，Java也在JDK17中加入。

密封类和平时用到的类差别在继承上。密封类是允许继承的，只允许文件内的类继承。也因此能够保证子类个数是有限的，只有文件内的那些。密封类更像是一个抽象类，是不能在外部直接使用定义了的密封类的，一定要访问内部的子类。

之类的类型可以是abstract class, open class, class, object几种类型。密封类中的子类同样可以实现其他的接口，这和其他类型的子类没有什么差异。

对应的使用场景和枚举类似，涉及到状态的，可以考虑用它。

为什么用它不是用枚举呢，它可以比枚举更灵活，密封类的子类可以是抽象类，或者open class，这些类型的子类又可以继续继承。

1
2
3
4
5
6
7


sealed class State {
 open class Success : State()
 abstract class Error : State()7
 class NetError : Error()
 class ServerError : Error()
 object Loading : State()
}

密封接口 #

密封接口又有什么用呢？

密封和接口看起来好像是两个没有什么关联的呀，密封保证封闭，接口是开放的。

理解密封接口绕个弯可能会更容易些，密封类中像是上面的例子，State类明明没有任何变量和方法，很像是接口，这么看果然顺了很多。

密封接口为什么设计成允许外部继承的，是我不理解的。Kotlin中的类默认是final不允许继承的，使用密封接口强制不允许继承吗，我只想到这一种可能。如果不是这样，那和普通的接口又有什么差别呢，难道是给Java用的？Kotlin的协程已经不可以在Java中使用了，而且Java中密封接口的实现类是可以继续继承的。

单例模式设计对比分析

Sun, 03 Aug 2025 19:57:31 +0800

懒汉式 #

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


// java
public class Singleton {
 private static final Singleton INSTANCE = new Singleton();
 
 private Singleton() {}
 
 public static Singleton getInstance() {
 return INSTANCE;
 }
}

1
2


// kotlin
object KotlinSingleton {}

优势：

实现简单；
没有同步开销；

不足：

类加载时创建，可能造成资源浪费；

线程安全：

JVM保障（静态变量只在加载时创建一次）。

饿汉式 #

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


// java
public class Singleton {
 private static Singleton instance;
 
 private Singleton() {}
 
 public static synchronized Singleton getInstance() {
 if (instance == null) {
 instance = new Singleton();
 }
 return instance;
 }
}

1
2
3
4
5
6
7
8


// kotlin
class LazySingleton private constructor() {
 companion object {
 val instance: LazySingleton by lazy(LazyThreadSafetyMode.SYNCHRONIZED) {
 LazySingleton()
 }
 }
}

优势：

减少了不必要的资源浪费

不足：

首次访问有同步开销

线程安全：

需要依赖同步锁实现线程安全。

双重检查式 #

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


// java
public class Singleton {
 private static volatile Singleton instance;
 
 private Singleton() {}
 
 public static Singleton getInstance() {
 if (instance == null) { // 第一次检查
 synchronized (Singleton.class) {
 if (instance == null) { // 第二次检查
 instance = new Singleton();
 }
 }
 }
 return instance;
 }
}

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


// kotlin
class Singleton private constructor() {
 
 companion object {
 // 使用 @Volatile 注解确保可见性和禁止指令重排序
 @Volatile
 private var instance: Singleton? = null
 
 fun getInstance(): Singleton {
 // 第一次检查：避免不必要的同步
 return instance ?: synchronized(this) {
 // 第二次检查：防止多个线程同时通过第一次检查后重复创建
 instance ?: Singleton().also { 
 instance = it 
 }
 }
 }
 }
}

优势：

延迟加载
只有第一次访问时有同步开销

不足：

实现复杂

线程安全：

volatile防止指令重排序。

静态内部类 #

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


// java
public class Singleton {
 private Singleton() {}
 
 private static class Holder {
 static final Singleton INSTANCE = new Singleton();
 }
 
 public static Singleton getInstance() {
 return Holder.INSTANCE;
 }
}

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


// kotlin
class Singleton private constructor() {
 
 // 伴生对象作为静态成员的容器
 companion object {
 // 使用属性访问器实现延迟初始化
 val instance: Singleton by lazy { Holder.INSTANCE }
 }
 
 // 私有静态内部类（Holder模式）
 private object Holder {
 // 由 JVM 保证线程安全的初始化
 val INSTANCE = Singleton()
 }
}

优势：

实现简单
没有同步开销

不足：

无法初始化参数

线程安全：

JVM保障，同饿汉式。

枚举单例 #

1
2
3
4
5


public enum EnumSingleton {
 INSTANCE;
 
 public void doSomething() { ... }
}

优势：

方式反射、序列化破坏单例；

不足：

可嫩造成不必要的资源浪费；

线程安全：

由JVM保证（类似静态单例初始化）。

总结 #

类型	实现方式	语言	线程安全	初始化时机	优势	不足	线程安全保证机制
非懒加载	饿汉式	Java	✅	类加载时	实现简单，无同步开销	可能造成资源浪费	JVM类加载机制
	枚举单例	Java	✅	类加载时	绝对防止反射/序列化破坏	不够灵活	JVM枚举特性保证
	Object声明	Kotlin	✅	首次访问类时	语法级支持，简洁安全	非严格懒加载	编译器生成静态内部类
懒加载	同步方法	Java	✅	首次调用时	延迟加载节省资源	每次调用都同步，性能差	synchronized方法锁
	双重检查锁(DCL)	Java	✅	首次调用时	高性能（仅首次同步）	实现复杂，需volatile	volatile+同步块禁止指令重排
	静态内部类	Java	✅	首次调用时	无同步开销，优雅实现	无法传递初始化参数	JVM类加载机制
	lazy(SYNCHRONIZED)	Kotlin	✅	首次属性访问时	灵活控制初始化时机	首次访问有同步开销	委托内部使用同步锁
	lazy(PUBLICATION)	Kotlin	⚠️有条件	首次属性访问时	允许多线程并行初始化	可能多次初始化	CAS操作保证最终一致性
	lazy(NONE)	Kotlin	❌	首次属性访问时	完全无同步开销	仅限单线程环境	无保护机制

发布android库到Maven Central

Sun, 27 Jul 2025 15:08:28 +0800

平时写一些小东西时有一部分代码是很常用到的，总不能每次都写一遍，每次都复制也太麻烦了，最简单的方式就发布到maven仓库，用拉取远程仓库的方式解决。因此，废了一顿劲发布到maven central中。也刚好记录下来，帮助有需要的人。

准备 #

在发布之前，需要先考虑发不到哪里，Android工程中常用的maven仓库有四个：

Google
Maven Central
Jitpack
Jcenter

随着Jcenter宣布设为只读代码库，可以选择的只剩了三家，加上Google是官方自己用的，实际上也只有两家。

Jitpack发布相对简单，之间也尝试过，有需要可以参考： Android library模块publish到JitPack完整流程。今天的是发布到maven central的。主要原因是可以用自己的域名- -

发布的流程很清晰：构建-签名-上传

Maven Central注册 #

发布到Maven Central首先要做的当然是注册账号了，中maven central repository右上角点击Sign In，后选择注册或者用Google、Github登录即可。

注册好之后是添加namespace，这样别人才能用com.example.lib:1.0.0这样的形式拉下来你的仓库。

生成token #

进到Setup Token-Based Authentication，点击"Generate User Token"，按照提示生成一个新的token，保存下来等下需要用到。

添加namespace #

这里有两种选择，github提供的和自己的域名。如果用github提供的，你的github用户名是yourname，那namespace就是io.github.yourname。io.github这部分是固定的，你只需要修改yourname这部分，按照流程继续往下走就可以了。

如果用自己的域名，只需要在域名的DNS中添加一条Txt类型的记录，内容和maven central提示的相同即可。

构建和发布 #

代码的部分就略过了，还没有那么大能耐能教别人怎么写代码。写好之后就是构建和发布了。

在一个android项目中，一个模块有两种类型，要么是可以运行的应用，要么是提供某些逻辑功能的库。两者的差别只在使用的Gradle插件是com.android.application（应用）还是com.android.library（库）上。想要发布用到的当然是库这一类型的。

除了指明是哪种类型的模块的插件，还需要一些其他的。发布用到maven-publish，它是Gradle提供的发布插件。

在发布到maven central时，是要要求有签名的，Gradle签名的插件一般是signing，不同于应用的签名，这里的是用GPG，简单来说是一种非对称加密工具，详细的推荐阅读GPG入门教程。别担心，不会引入太多新的内容，只用到创建和输出密钥、分发到服务器中这三个操作。

或者，你也可以用com.vanniktech.maven.publish这个Gradle插件，包含了发布、签名这两个部分，你只需要导入这一个就可以了。我在使用时，最新的版本是0.34.0。

配置 #

你需要做的只是在想要发布的模块build.gradle.kts文件加上发布和签名两部分配置。因为有相关的插件依赖，所以还要加上依赖。

插件：

1
2
3
4
5
6


plugins {
 alias(libs.plugins.android.library)
 alias(libs.plugins.kotlin.android)
 // 添加这一行
 id("com.vanniktech.maven.publish") version "0.34.0"
}

发布：

 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


mavenPublishing {
 configure(
 AndroidSingleVariantLibrary(
 // the published variant
 variant = "release",
 // whether to publish a sources jar
 sourcesJar = true,
 // whether to publish a javadoc jar
 publishJavadocJar = true,
 )
 )

 coordinates("com.opoojkk", "androidkt", android.defaultConfig.versionName)

 pom {
 name.set(project.name)
 description.set("common android kotlin extensions")
 inceptionYear.set("2025")
 url.set("https://github.com/opoojkk/androidkt/")
 licenses {
 license {
 name.set("The Apache License, Version 2.0")
 url.set("http://www.apache.org/licenses/LICENSE-2.0.txt")
 distribution.set("http://www.apache.org/licenses/LICENSE-2.0.txt")
 }
 }
 developers {
 developer {
 id.set("lxx")
 name.set("lxx")
 url.set("https://github.com/opoojkk/")
 }
 }
 scm {
 url.set("https://github.com/opoojkk/androidkt/")
 connection.set("scm:git:git://github.com/opoojkk/androidkt.git")
 developerConnection.set("scm:git:ssh://git@github.com/opoojkk/androidkt.git")
 }
 }
}

上面的这些都是我的配置，需要吧涉及到的地址改成你的。尤其是coordinates中的，这会影响到你发布到的namespace。

签名：

1
2
3
4
5
6
7
8


signing {
 useInMemoryPgpKeys(
 findProperty("signingKeyId")?.toString() ?: "",
 findProperty("signingKey")?.toString() ?: "",
 findProperty("signingPassword")?.toString() ?: "" // 确保密码不为 null
 )
 sign(publishing.publications)
}

除了这些还有些，你还需要在gradle.properties中添加下配置.

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


// 发布到maven central
mavenCentralPublishing=true
// 对所有publication签名
signAllPublications=true
// 自动发布，否则要在maven central手动发布
mavenCentralAutomaticPublishing=true

// 从maven central哪来的tname
mavenCentralUsername=xxxxxx
// 从maven central哪来的token
mavenCentralPassword=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
// 用来签名的GPG keyid
signingKeyId=xxxxxxxx
// GPG私钥，注意包含包含开始和结尾"==="和空行的部分全部都是，写成一行，讲换行改成"/n"
signingKey=...
// 设置的密码
signingPassword=xxxxxx

执行 #

最后一步，执行gralde命令：

1

./gradlew publishToMavenCentral

打完收工。

GPG命令 #

涉及到的GPG命令：

创建： gpg --gen-key

创建之后需要拿到keyid才能继续执行后面的操作，获取keyid的命令：gpg --list-keys --keyid-format short。

你会得到和下面类似的：

1
2
3


pub rsa4096/34567890 2025-07-26 [SCE]
 1231231231231231231231231231231234567890
uid [ 绝对 ] lxx (androidkt) <hi@opoojkk.com>

1231231231231231231231231231231234567890就是你的keyid。一般都用短id，也就是后八位34567890。

输出密钥： gpg --armor --output public-key.txt --export {keyid}

执行后，你会得到很长的一串字符，这就是你的私钥。

发布keyid到服务器： gpg --keyserver keyserver.ubuntu.com {keyid}

有三个服务器可选，差不多…

keyserver.ubuntu.com
keys.openpgp.org
pgp.mit.edu

这些在GPG入门教程中都是有的。

总结 #

踩坑 #

签名
1. 签名用了很久才配置好，开始用导出的pgp私钥文件路径，结果不行。试过读出文字，也不行。中间还改了好多种配置，最后把全部内容放上去才好。
keyid一定要发布到server！
不用在build.gradle中自己加maven仓库，替你试过了，不好使….

步骤 #

最后总结一下步骤，以防看着迷糊。

注册maven central账号，添加namespace，生成token
生成pgp密钥，发布keyid到服务器
gradle添加插件、发布配置
执行gradle脚本发布

参考 #

Fragment重建过程详解

Sun, 20 Jul 2025 14:09:12 +0800

当Activity的配置发生变化或者低内存被回收后，会触发Activity的重建。可以通过重写onSaveInstanceState和onRestoreInstanceState实现重建时的保存和恢复逻辑。

Fragment的本质上是对View的封装，为其增加了生命周期的支持，因此能够在一个Activity中添加多个Fragment。Fragment重建也是依赖宿主Activity的。现在，当我们创建Activity实例时，看到的往往是继承自AppCompatActivity的，AppCompatActivity到Activity之间隔了很多代。

联系 #

和Fragment关系最密切的，是一个叫FragmentActivity的。它的里面有一个名叫mFragments的，实际上是FragmentController类型的一个实例。

FragmentController中，有两个关键类完成Fragment的逻辑，一个是FragmentManager实现Fragment的add、replace、remove。另一个是FragmentStateManager，它实现的是更新Fragment的状态，让Fragment执行对应的生命周期方法，还有一个对当前主题很重要的，执行保存状态也是由它发起，通知Fragment执行实现的。

保存 #

Activity的重建和Fragment时怎么联系起来的呢？

在Activity中的重建方法我们知道是onSaveInstanceState和onResotreInstanceState，但是如果在FragmentActivity中找，是找不到这个两个方法的，一直到父类ComponentActivity中才能看到。

1
2
3
4
5
6
7
8


@CallSuper
override fun onSaveInstanceState(outState: Bundle) {
 if (lifecycle is LifecycleRegistry) {
 (lifecycle as LifecycleRegistry).currentState = Lifecycle.State.CREATED
 }
 super.onSaveInstanceState(outState)
 savedStateRegistryController.performSave(outState)
}

和Fragment的秘密只有可能在父类或者savedStateRegistryController中，父类帮大家看过了，只有一些更新状态的逻辑，再有就到Activity类了。只可能是savedStateRegistryController完成的了。

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


 /**
 * An interface for an owner of this [SavedStateRegistry] to perform state saving, it will call
 * all registered providers and merge with unconsumed state.
 *
 * @param outBundle SavedState in which to place a saved state
 */
 @MainThread
 internal fun performSave(outBundle: SavedState) {
 val inState = savedState {
 restoredState?.let { putAll(it) }
 synchronized(lock) {
 for ((key, provider) in keyToProviders) {
 putSavedState(key, provider.saveState())
 }
 }
 }

 if (inState.read { !isEmpty() }) {
 outBundle.write { putSavedState(SAVED_COMPONENTS_KEY, inState) }
 }
 }

看着注释，十有八九就是我们要找的了，这个putSavedState是最后保存下来的，遍历的是keyToProviders，只要找到Fragment和keyToProviders的关系就能联系起来了。

再看FragmentActivity，初始化时有这么一段代码：

1
2
3
4
5


getSavedStateRegistry().registerSavedStateProvider(LIFECYCLE_TAG, () -> {
 markFragmentsCreated();
 mFragmentLifecycleRegistry.handleLifecycleEvent(Lifecycle.Event.ON_STOP);
 return new Bundle();
});

当真的以为找到了的时候，发现事情不对。刚刚还说Fragment相关的内容都在FragmentController里，这里面也没有用到FragmentController啊。

对啊…这样找不到，那就换个方式，正着不行，反着来，从Fragment开始找。

当Fragment保存状态时，也会执行onSaveInstanceState方法，得到一些列保存的状态和对应的值。

因此能顺利的找到FragmentManager中保存的方法saveAllStateInternal。只要不断找调用的方法，就能找到了。巧的是，在FragmentManager绑定FragmentController时，向keyToProviders中添加了一个键值对。

1
2
3
4
5
6


SavedStateRegistry registry =
 ((SavedStateRegistryOwner) mHost).getSavedStateRegistry();
registry.registerSavedStateProvider(SAVED_STATE_KEY, () -> {
 return saveAllStateInternal();
 }
);

好家伙，这不就是刚才没对上的，Activity和Fragment总算对接上了。

问题又来了，怎么保存呢所有Fragment呢？继续看saveAllStateInternal方法吧，都在里面呢。在开始没有讲，一个Fragment对应一个FragmentStateManager，因此FragmentStateManager执行保存实际上就是用了Fragment的保存方法。

比如活跃的Fragment：

 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


# FragmentStateManager.java
 @NonNull
 Bundle saveState() {
 Bundle stateBundle = new Bundle();
 if (mFragment.mState == Fragment.INITIALIZING) {
 // We never even got to ATTACHED, but we could still have some state
 // set by setInitialSavedState so we'll add that to our initial Bundle
 if (mFragment.mSavedFragmentState != null) {
 stateBundle.putAll(mFragment.mSavedFragmentState);
 }
 }

 // Save the library state associated with the Fragment
 FragmentState fs = new FragmentState(mFragment);
 stateBundle.putParcelable(FRAGMENT_STATE_KEY, fs);

 // Save the user state associated with the Fragment
 if (mFragment.mState > Fragment.INITIALIZING) {
 Bundle savedInstanceState = new Bundle();
 mFragment.performSaveInstanceState(savedInstanceState);
 if (!savedInstanceState.isEmpty()) {
 stateBundle.putBundle(SAVED_INSTANCE_STATE_KEY, savedInstanceState);
 }
 mDispatcher.dispatchOnFragmentSaveInstanceState(mFragment, savedInstanceState, false);

 Bundle savedStateRegistryState = new Bundle();
 mFragment.mSavedStateRegistryController.performSave(savedStateRegistryState);
 if (!savedStateRegistryState.isEmpty()) {
 stateBundle.putBundle(REGISTRY_STATE_KEY, savedStateRegistryState);
 }

 Bundle childFragmentManagerState =
 mFragment.mChildFragmentManager.saveAllStateInternal();
 if (!childFragmentManagerState.isEmpty()) {
 stateBundle.putBundle(CHILD_FRAGMENT_MANAGER_KEY, childFragmentManagerState);
 }

 if (mFragment.mView != null) {
 saveViewState();
 }
 if (mFragment.mSavedViewState != null) {
 stateBundle.putSparseParcelableArray(VIEW_STATE_KEY, mFragment.mSavedViewState);
 }
 if (mFragment.mSavedViewRegistryState != null) {
 stateBundle.putBundle(VIEW_REGISTRY_STATE_KEY, mFragment.mSavedViewRegistryState);
 }
 }

 if (mFragment.mArguments != null) {
 stateBundle.putBundle(ARGUMENTS_KEY, mFragment.mArguments);
 }
 return stateBundle;
 }

恢复 #

恢复时同样从Activity开始，先是Activity的生命周期方法：onCreate、onStart然后是onRestoreInstanceState。恢复Fragment流程和保存大致是相似的，不过顺序是相反的，就不再重复。

倒是有个问题不知道你有没有印象，创建Activity时抛出的不能初始化Fragment是怎么回事呢？

 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
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97


// FragmentStateManager.java
 /**
 * Recreate a FragmentStateManager from a FragmentState instance, instantiating
 * a new Fragment from the {@link FragmentFactory}.
 *
 * @param dispatcher Dispatcher for any lifecycle callbacks triggered by this class
 * @param fragmentStore FragmentStore handling all Fragments
 * @param classLoader ClassLoader used to instantiate the Fragment
 * @param fragmentFactory FragmentFactory used to instantiate the Fragment
 * @param state Bundle used to restore the state correctly
 */
 @SuppressWarnings("deprecation")
 FragmentStateManager(@NonNull FragmentLifecycleCallbacksDispatcher dispatcher,
 @NonNull FragmentStore fragmentStore,
 @NonNull ClassLoader classLoader,
 @NonNull FragmentFactory fragmentFactory,
 @NonNull Bundle state) {
 mDispatcher = dispatcher;
 mFragmentStore = fragmentStore;

 // Instantiate the fragment's library states in FragmentState
 FragmentState fs = state.getParcelable(FRAGMENT_STATE_KEY);
 mFragment = fs.instantiate(fragmentFactory, classLoader);
 mFragment.mSavedFragmentState = state;

 // Instantiate the fragment's arguments
 Bundle arguments = state.getBundle(ARGUMENTS_KEY);
 if (arguments != null) {
 arguments.setClassLoader(classLoader);
 }
 mFragment.setArguments(arguments);

 if (FragmentManager.isLoggingEnabled(Log.VERBOSE)) {
 Log.v(TAG, "Instantiated fragment " + mFragment);
 }
 }

// FragmentState.java
 /**
 * Instantiates the Fragment from this state.
 */
 @NonNull
 @SuppressWarnings("deprecation")
 Fragment instantiate(@NonNull FragmentFactory fragmentFactory,
 @NonNull ClassLoader classLoader) {
 Fragment fragment = fragmentFactory.instantiate(classLoader, mClassName);
 fragment.mWho = mWho;
 fragment.mFromLayout = mFromLayout;
 fragment.mRestored = true;
 fragment.mFragmentId = mFragmentId;
 fragment.mContainerId = mContainerId;
 fragment.mTag = mTag;
 fragment.mRetainInstance = mRetainInstance;
 fragment.mRemoving = mRemoving;
 fragment.mDetached = mDetached;
 fragment.mHidden = mHidden;
 fragment.mMaxState = Lifecycle.State.values()[mMaxLifecycleState];
 fragment.mTargetWho = mTargetWho;
 fragment.mTargetRequestCode = mTargetRequestCode;
 fragment.mUserVisibleHint = mUserVisibleHint;
 return fragment;
 }

 // FragmentFactory.java
 /**
 * Create a new instance of a Fragment with the given class name. This uses
 * {@link #loadFragmentClass(ClassLoader, String)} and the empty
 * constructor of the resulting Class by default.
 *
 * @param classLoader The default classloader to use for instantiation
 * @param className The class name of the fragment to instantiate.
 * @return Returns a new fragment instance.
 * @throws Fragment.InstantiationException If there is a failure in instantiating
 * the given fragment class. This is a runtime exception; it is not
 * normally expected to happen.
 */
 @NonNull
 public Fragment instantiate(@NonNull ClassLoader classLoader, @NonNull String className) {
 try {
 Class<? extends Fragment> cls = loadFragmentClass(classLoader, className);
 return cls.getConstructor().newInstance();
 } catch (java.lang.InstantiationException e) {
 throw new Fragment.InstantiationException("Unable to instantiate fragment " + className
 + ": make sure class name exists, is public, and has an"
 + " empty constructor that is public", e);
 } catch (IllegalAccessException e) {
 throw new Fragment.InstantiationException("Unable to instantiate fragment " + className
 + ": make sure class name exists, is public, and has an"
 + " empty constructor that is public", e);
 } catch (NoSuchMethodException e) {
 throw new Fragment.InstantiationException("Unable to instantiate fragment " + className
 + ": could not find Fragment constructor", e);
 } catch (InvocationTargetException e) {
 throw new Fragment.InstantiationException("Unable to instantiate fragment " + className
 + ": calling Fragment constructor caused an exception", e);
 }
 }

所以创建Fragment(DialogFragment)最好只定义无参的构造方法，需要的参数通过Bundle传过去，这样重建的时候能创建出来，传过去的参数也能保存下来，重建后状态都是正常的。

Kotlin的fun interface

Sun, 13 Jul 2025 19:14:19 +0800

当我们写Java时有这么一种情况，需要用到回调，但是回调中只有一个方法，这时候的写法可以更简便，举个例子：

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


public class SAMJava {
 public static void main(String[] args) {
 // 写法1
 execute(new BlockJava() {
 @Override
 public void invoke() {
 // do something
 }
 });
 }

 static void execute(BlockJava blockJava) {
 blockJava.invoke();
 }
}

interface BlockJava {
 void invoke();
}

上面是Java中传递匿名对象最最普通的写法，换用lambda的形式可以写成：

1
2
3
4


// 写法2
execute(() -> {
 // do something
});

看起来干净了很多，这就是SAM（Single Abstract Method）。要说有什么作用，就是让代码看起来很干净。这也是有限制的，只能是接口类中有一个方法需要实现的时候，当接口的中有两个方法就不行了，只能老老实实用的用方法1.

这都是在Java中，Kotlin中有些不同。

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


object SAMKt {
 @JvmStatic
 fun main(args: Array<String>) {
 // 写法1
 execute(object : BlockKotlin {
 override fun invoke() {
 // do something
 }
 })
 }

 fun execute(blockJava: BlockKotlin) {
 blockJava.invoke()
 }
}

interface BlockKotlin {
 fun invoke() // void fiinish();
}

匿名对象的形式当然是可以的，如果想换成Kotlin中lamdbas的写法，代码检查就是提示错误。

1
2
3
4


// 写法2，报错
execute {
 // do something
}

Kotlin中能不能呢，能。但有点不同，你需要声明接口是fun interface:

1
2
3


fun interface BlockKotlin {
 fun invoke() // void fiinish();
}

这时候还会提示你可以写成了写法2。
除此之外，还有一种写法。我们知道Kotlin是有高阶函数的，高阶函数可以做这事。

1
2
3
4
5
6


fun execute2(block: () -> Unit) {
 block()
}


execute2 { }

这样也是没问题的。

参考 #

What is a ‘SAM type’ in Java?

协变与逆变解析

Sun, 29 Jun 2025 11:38:04 +0800

泛型 #

泛型的作用是能对不同的类型抽离相同的逻辑，写成模板类和方法，以此减少重复代码。

但是，我们知道在Java和Kotlin中的泛型只在编译期间生效，运行时都是Object。

在一般的使用场景中是没有问题的，像是这样：

1
2
3
4
5
6
7
8
9


class Animal{}

class Dog extends Animal{}

class Cat extends Animal{}

List<Animal> animals = new ArrayList();
animals.add(new Dog());
animals.add(new Cat());

因为类型是相同的，一切都没有问题。

Java是面向对象的语言，因此ArrayList是可以赋值给List的，那List能不能接收List和List的实例呢？

答案是不能，还是以为泛型擦除。试想一下，加入可以赋值，等到取元素的时候怎么知道是什么类型的呢？类型是Dog？有没有Cat类型的呢？这就很麻烦。

Java和Kotlin又是怎么解决的呢？就是协变和逆变。

协变 #

当像下面这样声明时就可以赋值了。

1
2
3
4


List<Dog> dogs = new ArrayList();
dogs.add(new Dog());

List<? extends Animal> animals = dogs

Dog换成Cat也是一样的，这时候是允许将Animal的子类放进去的，因为能保证放进去一定是Animal类型的。

这就是协变。

逆变 #

如果我想向动物的合集中添加Cat。

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


class Pekingese extends Dog{}

void addDog(List<? super Dog> dogs){
 dogs.add(new Dog());
}

List<Dog> dogs = new ArrayList();
addDog(dogs);
List<Animal> animals = new ArrayList();
addDog(animals);
List<Cat> cats = new ArrayList();
// addDog(cats);编译不过
List<Pekingese> pekingeses = new ArrayList();
// addDog(cats);编译不过

只允许某一个类的超类添加进去，这就是逆变了。

LiveData与StateFlow对比分析

Sun, 29 Jun 2025 10:41:03 +0800

之前写过LiveData的内部实现LiveData，Jetpack中还有另一个组件StateFlow，两者作用非常类似，有什么差别呢？

StateFlow、Flow 和 LiveData StateFlow 和 LiveData 具有相似之处。两者都是可观察的数据容器类，并且在应用架构中使用时，两者都遵循相似模式。

但请注意，StateFlow 和 LiveData 的行为确实有所不同：

StateFlow 需要将初始状态传递给构造函数，而 LiveData 不需要。当 View 进入 STOPPED 状态时，LiveData.observe() 会自动取消注册使用方，而从 StateFlow 或任何其他数据流收集数据的操作并不会自动停止。如需实现相同的行为，您需要从 Lifecycle.repeatOnLifecycle 块收集数据流。

这是Android Developer-StateFlow 和 SharedFlow中写到的。

的确LiveData构造方法中可以不传递值，为什么这么设计呢？我认为两者设计的用途是不同的。

LiveData的不管是从名字还是实现上，真的很像是一个Data，内部有value，有版本，会让新增加的观察者保持最新的状态，也就是粘性事件（非要叫什么"数据倒灌"好显得高级- -）。一般会用需要传入LifeCycleOwn的方法注册观察者，因此生命周期是和LifeCycle绑定的，所以是live的。

LiveData更新值时是需要在主线程执行的，上面的考虑在一起，它就是用来保持UI和一个数据的状态（粘性事件，最好不要执行逻辑）是同步的，因此是实现MVVM架构的一个关键部分。

一个Data没有初始值，也很合理。

那StateFlow呢？StateFlow首先是一个flow，在Kotlin中Flow最基本的作用是发送数据，StateFlow还是一个热流（观察者中只能收集到订阅之后的数据变化），不像冷流能接收到从最开始发送的数据。且是和生命周期没有关联的，有了协程的加持，使用的范围可以更大些，可以从其他子线程收集到之后发给任意线程，而不是仅限于主线程。

State能没有初始值吗，听起来不太合适。

StateFlow能替换LiveData吗？我认为的是可以的。

LiveData两大特点分别是和生命周期绑定、粘性事件。生命周期StateFlow借助扩展函数repeatOnLifecycle可以做到，粘性事件也是本身就支持的。

但是，LiveData不需要借助协程，开箱即用，有更具体的使用场景。

协程与Kotlin协程对比

Sun, 22 Jun 2025 17:31:18 +0800

协程到底是什么呢？

这是我看到Kotlin协程之后的第一个问题。在回答是不是什么之前，先弄清楚什么是怎么定义的，协程也是一样。

在搜索引擎得到的答案都是"轻量化线程"、“非阻塞”、“协作式"之类的关键字关键字，真的是这样吗？

协程（英语：coroutine）是计算机程序的一类组件，推广了协作式多任务的子例程，允许执行被挂起与被恢复。相对子例程而言，协程更为一般和灵活，但在实践中使用没有子例程那样广泛。协程更适合于用来实现彼此熟悉的程序组件，如协作式多任务、异常处理、事件循环、迭代器、无限列表和管道。

摘自wikipedia

维基百科的解释是这样的，看上去好像也不能理解是什么。

维基百科的优点是会给出来源，协程最初被提出是在1963年。按照网络上的说法，线城市60年代后期出现了，按照这个说法，线程出现比协程要晚。因此，“轻量化线程"看起来不能成立。

在原始的论文中，作者表述的是一种没有主程序控制，由多段不同的协程控制的程序，子程序之间没有父子关系都是并列的。

但是被认为是协程里程碑的则是另一篇《Coroutines: A Programming Methodology, a Language Design and an Implementation》。

其中表述的概念是说协程是非抢占式的。抢占式指操作系统强制终端当前的任务，将CPU分配给其他任务，而协程不一样，是通过主动让出CPU，这时候才会切换至其他任务。最常见的场景恐怕是IO操作上，当需要切换线程时，不是由操作系统完成，而是有程序员主动执行，让正在执行IO操作的线程让出CPU。

协程是一个概念。无论是操作系统实现，还是语言实现，亦或是一个封装好的三方库，只要符合概念，通通都可以认为是协程。因此朱凯的理论"因为JVM没实现，所以不是真的协程"并不能让人信服。

再到Kotlin的协程，Kotlin的协程实现了上面的概念了吗，我想是没有的，Kotlin的协程在使用的时候看起来是切换了线程，实际上是在主线程、IO线程池和耗时运算线程池之间切换，没有释放出正在IO等待的线程的CPU。

从这个角度看，的确不是协程，但不妨碍它的名字叫Kotlin协程。

参考 #

WebView JavaScript接口实现原理

Mon, 26 May 2025 09:13:11 +0800

在工作中有和前端混合开发的项目（前端的代码运行在Webview中），混合开发涉及到前端和客户端之间方法的调用，花了点时间弄明白是实现调用的。

实现 #

我们都知道是通过WebView的addJavaScript方法将Android的方法添加进Webview，之后前端才可以调用到的，因此入口从它开始。

Java层 #

点进WebView的addJavascriptInterface方法里，添加和移除的方法实现都是通过WebViewProvider。WebViewProvider才是WebView中功能实现的类。又是怎么创建的呢？

WebViewProvider的创建通过反射方式。在不同Android SDK中指向的不同的FactoryProvider类。详细过程可以参考【迁移博客】WebView深究之Android是如何实现webview初始化的。

在我的环境下，WebViewProvider实现类是WebViewChromium。

我们要找的addJavascriptInterface又被给到了AwContents了，AwContents又给JavascriptInjector…

终于，对应到了content/public/android/java/src/org/chromium/content/browser/JavascriptInjectorImpl.java的addPossiblyUnsafeInterface。

addPossiblyUnsafeInterface方法接收到的四个参数分别是：

实现JS方法的对象
addJavaScript时传入的name
JavascriptInterface.class
List.of("*")

观察到addPossiblyUnsafeInterface的实现是一个需要传入指针的，下面的Natices接口标注了NativeMethods，而且搜到的几个JavascriptInjectorImplJni#get方法路径都在out/…路径下，猜测编译时生成的C++代码。

或者，你也可以向我一样，用ChatGPT搜对应的实现是什么，再编一顿和上面类似的理由😄。

根据规则，对应的C++实现类content/browser/android/javascript_injector_android.cc。

native层 #

从这里开始，就到了C++的部分。

C++我不熟悉，也就是大致能看懂的水平，有看不懂的交给AI解释了的。

下面是添加方法的实现，将Android传递过来的方法封装成一个C++对象，用一个map存放着。

 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


void GinJavaBridgeDispatcherHost::AddNamedObject(
 const std::string& name,
 const base::android::JavaRef<jobject>& object,
 const base::android::JavaRef<jclass>& safe_annotation_clazz,
 net::SchemeHostPortMatcher matcher) {
 DCHECK_CURRENTLY_ON(BrowserThread::UI);
 GinJavaBoundObject::ObjectID object_id;
 NamedObjectMap::iterator iter = named_objects_.find(name);
 bool existing_object = FindObjectId(object, &object_id);
 if (existing_object && iter != named_objects_.end() &&
 iter->second.object_id == object_id) {
 // Nothing to do.
 return;
 }

 if (iter != named_objects_.end()) {
 RemoveNamedObject(iter->first);
 }
 if (existing_object) {
 base::AutoLock locker(objects_lock_);
 objects_[object_id]->AddName();
 } else {
 object_id = AddObject(object, safe_annotation_clazz, std::nullopt);
 }

 // We use the serialized string of the matcher and reconstruct it
 // in the render process. We pass this around like this because we can
 // then trust that all the rules being fed to the render process are well
 // formed rules.
 // TODO(crbug.com/407420300): Rely on OriginMatcher instead of a string here.
 named_objects_[name] = {object_id, matcher.ToString()};

 web_contents()
 ->GetPrimaryMainFrame()
 ->ForEachRenderFrameHostImplIncludingSpeculative(
 [&name, object_id, &matcher,
 this](RenderFrameHostImpl* render_frame_host) {
 if (!render_frame_host->IsRenderFrameLive()) {
 return;
 }

 GetJavaBridge(render_frame_host, /*should_create=*/true)
 ->AddNamedObject(name, object_id, matcher.ToString());
 });
}

既然存放在一个map里，调用时也一定是通过这个map取到的，顺着找到了content/browser/android/java/gin_java_bridge_dispatcher_host.cc#onInvokeMethod，看到参数中使用方法名、参数和结果的，结合之前和前端打交道的经验，十有八九就是它了。

 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


void GinJavaBridgeDispatcherHost::OnInvokeMethod(
 const GlobalRenderFrameHostId& routing_id,
 GinJavaBoundObject::ObjectID object_id,
 const std::string& method_name,
 const base::Value::List& arguments,
 base::Value::List* wrapped_result,
 content::mojom::GinJavaBridgeError* error_code) {
 DCHECK(JavaBridgeThread::CurrentlyOn());
 DCHECK(routing_id);
 scoped_refptr<GinJavaBoundObject> object = FindObject(object_id);
 if (!object.get()) {
 wrapped_result->Append(base::Value());
 *error_code = mojom::GinJavaBridgeError::kGinJavaBridgeUnknownObjectId;
 return;
 }

 auto result = base::MakeRefCounted<GinJavaMethodInvocationHelper>(
 std::make_unique<GinJavaBoundObjectDelegate>(object), method_name,
 arguments);
 result->Init(this);
 result->Invoke();
 *error_code = result->GetInvocationError();
 if (result->HoldsPrimitiveResult()) {
 *wrapped_result = result->GetPrimitiveResult().Clone();
 } else if (!result->GetObjectResult().is_null()) {
 GinJavaBoundObject::ObjectID returned_object_id;
 if (FindObjectId(result->GetObjectResult(), &returned_object_id)) {
 base::AutoLock locker(objects_lock_);
 objects_[returned_object_id]->AddHolder(routing_id);
 } else {
 returned_object_id =
 AddObject(result->GetObjectResult(), result->GetSafeAnnotationClass(),
 routing_id);
 }
 wrapped_result->Append(base::Value::FromUniquePtrValue(
 GinJavaBridgeValue::CreateObjectIDValue(returned_object_id)));
 } else {
 wrapped_result->Append(base::Value());
 }
}

接着是调用Java方法

 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


void GinJavaMethodInvocationHelper::Invoke() {
 JNIEnv* env = AttachCurrentThread();
 const JavaMethod* method =
 object_->FindMethod(method_name_, arguments_.size());
 if (!method) {
 SetInvocationError(mojom::GinJavaBridgeError::kGinJavaBridgeMethodNotFound);
 return;
 }

 if (object_->IsObjectGetClassMethod(method)) {
 base::android::EventLogWriteInt(kObjectGetClassInvocationAttemptLogTag,
 getuid());
 SetInvocationError(mojom::GinJavaBridgeError::
 kGinJavaBridgeAccessToObjectGetClassIsBlocked);
 return;
 }

 ScopedJavaLocalRef<jobject> obj;
 ScopedJavaLocalRef<jclass> cls;
 if (method->is_static()) {
 cls = object_->GetLocalClassRef(env);
 } else {
 obj = object_->GetLocalRef(env);
 }
 if (obj.is_null() && cls.is_null()) {
 SetInvocationError(mojom::GinJavaBridgeError::kGinJavaBridgeObjectIsGone);
 return;
 }

 mojom::GinJavaBridgeError coercion_error =
 mojom::GinJavaBridgeError::kGinJavaBridgeNoError;
 std::vector<jvalue> parameters(method->num_parameters());
 for (size_t i = 0; i < method->num_parameters(); ++i) {
 const base::Value& argument = arguments_[i];
 parameters[i] = CoerceJavaScriptValueToJavaValue(
 env, argument, method->parameter_type(i), true, object_refs_,
 &coercion_error);
 }

 if (coercion_error == mojom::GinJavaBridgeError::kGinJavaBridgeNoError) {
 if (method->is_static()) {
 InvokeMethod(nullptr, cls.obj(), method->return_type(), method->id(),
 parameters.data());
 } else {
 InvokeMethod(obj.obj(), nullptr, method->return_type(), method->id(),
 parameters.data());
 }
 } else {
 SetInvocationError(coercion_error);
 }

 // Now that we're done with the jvalue, release any local references created
 // by CoerceJavaScriptValueToJavaValue().
 for (size_t i = 0; i < method->num_parameters(); ++i) {
 ReleaseJavaValueIfRequired(env, &parameters[i], method->parameter_type(i));
 }
}

总结 #

现在重新梳理一下完成的流程，Android中为一个WebView添加JS方法时，会通过反射创建不同的WebViewProvider实现，用的最多的是WebViewChromium。添加的JS方法会以一个对象的形式，存储在CPP的一个map中，调用时通过name和方法名称找到添加的方法。

Android和JS通信要借助Native层完成。

工具 #

Chromium代码搜索：Chromium Code Search

参考 #

【迁移博客】WebView深究之Android是如何实现webview初始化的

理解Android插件化

Sun, 11 May 2025 14:23:04 +0800

12年我还在上初中，AndroidDynamicLoader已经只吃了Fragment的插件化实现。之后不断演变，从dynamic-load-apk，到DroidPlugin，再到Atlas。

说来惭愧，时至今日才有机会接触到，不禁想一探究竟。

起源 #

在想一项技术被怎么实现、怎么应用前，总是有这样的疑问：为什么要有这项技术呢？插件化也是一样的，为什么一定要用插件化呢？

因为是25年才搜索，并没有真正的经历过插件化的演变，查资料得知：

解决Dex中方法数上限65536的问题；
大项目需求迭代，提高多个模块并行开发效率，减小应用体积，同时还能动态化修改功能（主模块之外）。

对第一个问题，Enable multidex for apps with over 64K methodsAndroid开发官方的文档中说明，从Android5.0开始，已经支持了MultiDex，用以解决65536上限的问题。

但是，考虑到应用适配的速度，尤其是一几年，没有升级到SDK版本还停留在Android 5.0之前是很正常的。虽然升级的成本要比插件化低很多😅。

插一句：Android官方提供用在Android5.0之前解决多DEX方法数上限的库中实际上也是把APK解压，通过classloader加载dex文件。

Android 5.0（API 级别 21）及更高版本使用名为 ART 的运行时，它本身支持从 APK 文件加载多个 DEX 文件。 ——为方法数超过 64K 的应用启用 MultiDex

第二个问题使用其他方式可以解决吗？至少可以解决一部分，开发效率可以考虑组件化的方式。减小应用体积动态下载这部分是不可以的。

因此，动态化是有必要的。

需要解决的问题 #

插件化即是动态下载好要执行的代码，在Android应用中涉及到三方面：

逻辑代码
四大组件
资源文件

实现方式 #

逻辑代码 #

逻辑代码只要能被类加载器加载过，找到对应的路径就是可以执行的。

在Android中有两个classloader被用来加载dex文件：PathClassLoader和DexClassLoader。两者在Android8.0之后实际上也没有差异了。

四大组件 #

四大组件也是类，为什么不和其他逻辑代码放到一起呢？

因为在Android中启动一个四个组件的类是会鉴别是否在清单文件中的，如果不在其中，会被拒绝启动。

解决的思路有两种：

清单文件中预埋容器Activity，容器中声明周期方法被调用时，手动调用实际Activity的；
利用hook，将插件 Activity 替换成实际Activity，等到检测完了后再换回来。

资源文件 #

当我们访问资源文件时，比如string。实际上是从ResourceImpl中的AssetsManager中返回的。

向ResourceImpl中添加的方法是assets.addAssetPath，所以我们想将插件的apk文件添加到宿主中，就可以通过反射修改这个地方。

实现步骤：

创建一个AssetManager对象，并调用 addAssetPath 方法，将插件 apk 的路径作为参数传入。
将第一步创建的AssetManager对象作为参数，创建一个新的Resources对象，并返回给插件使用。

参考 #

Android序列化方案对比

Sun, 23 Mar 2025 16:23:42 +0800

从开始学习Android，到现在看过很多次有人争论Android为什么用Parcelable，而不是Java提供的Serializable接口。

除了使用两者的方式不同外，国内（大陆）目前最普遍的观点是认为Serializable用了大量的反射，导致速度要比Parcelable慢。

但，真的是这样吗？

有许多人提出，是因为用到Serializable时，开发者并没有定义应该怎么序列化和反序列化，因此Java为你用反射完成的。实际上是可以实现Custom Serialization的。并没有提供给方法重写，如果想要这么做，你需要实现private的writeObject和readObject方法。你可以参考Discover the secrets of the Java Serialization API实现。

用这样的Serializable和Parcelable比较未免太不公平了。实际上，如果实现了Custom Serialization，它是要比Parcelable的写快大概3.6倍，比Parcelable的读取要快上1.6倍的。（速度未验证）。按照这个逻辑，Android中用Parcelable是有其他的原因。

StackOverFlow上的一个大牛解释，Parcelable除了可以实现进程间通信之外，还可以实现native和Java层的通信（Java层序列化后从native层读取出来）。

参考:

Mac终端中使用VS Code打开文件

Sat, 08 Mar 2025 09:35:43 +0800

最近排查ANR日志，用grep找到包含特定内容的日志后，还要找文件在哪再打开，觉得很繁琐，简单搜了下，还有平时常用的命令，一并记录下来以便后续用到查找。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


# 用特定软件打开某个文件
open -a "软件名称" path/file

# finder中打开当前文件夹
open .

# grep递归匹配特定内容
grep -r "特定内容"

# grep递归匹配特定内容，只显示文件名
grep -rl "特定内容"

DialogFragment取消机制解析

Sun, 19 Jan 2025 11:18:47 +0800

某天（周六）测试反馈一个本该不能用返回取消的弹窗，是可以用返回手势取消的。心中满是疑惑，代码中已经写了dialog?.setCanceledOnTouchOutside(false)怎么不生效呢？

带着关键字查Google，都说用setCancelable(false)就可以了，大为震惊。日思夜想睡不着，今天一定要查个明白。

Dialog #

Dialog的方法做了是什么?

 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


 // Dialog.java

 /**
 * Sets whether this dialog is canceled when touched outside the window's
 * bounds. If setting to true, the dialog is set to be cancelable if not
 * already set.
 * 
 * @param cancel Whether the dialog should be canceled when touched outside
 * the window.
 */
 public void setCanceledOnTouchOutside(boolean cancel) {
 if (cancel && !mCancelable) {
 mCancelable = true;
 }
 
 mWindow.setCloseOnTouchOutside(cancel);
 }

 // Window.java

 /** @hide */
 @UnsupportedAppUsage
 public void setCloseOnTouchOutside(boolean close) {
 mCloseOnTouchOutside = close;
 mSetCloseOnTouchOutside = true;
 }

两件事：

如果cancel的值为true，保证mCancelable为true。
改变Window的值。

DialogFragment #

为什么是DialogFragment而不是Dialog，是DialogFragment是可以用Fragment的生命周期的，Dialog作为Fragment中的一个成员变量。

Dialog是在DialogFragment创建View的时候，更确切的说是在获取LayoutInflater的时候创建了Dialog实例。DialogFragment的构造方法中穿进去的layoutId也是用作创建dialog，并没有真的把这个layout加载出来显示在Fragment中。

因此更改dialog的属性至少应该在onCreateView之后，

setCancelable做了什么？

 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


 /**
 * Called when the dialog has detected the user's press of the back
 * key. The default implementation simply cancels the dialog (only if
 * it is cancelable), but you can override this to do whatever you want.
 *
 * <p>
 * If you target version {@link android.os.Build.VERSION_CODES#TIRAMISU} or later, you
 * should not use this method but register an {@link OnBackInvokedCallback} on an
 * {@link OnBackInvokedDispatcher} that you can retrieve using
 * {@link #getOnBackInvokedDispatcher()}. You should also set
 * {@code android:enableOnBackInvokedCallback="true"} in the application manifest.
 *
 * <p>Alternatively, you
 * can use {@code androidx.activity.ComponentDialog#getOnBackPressedDispatcher()}
 * for backward compatibility.
 *
 * @deprecated Use {@link OnBackInvokedCallback} or
 * {@code androidx.activity.OnBackPressedCallback} to handle back navigation instead.
 * <p>
 * Starting from Android 13 (API level 33), back event handling is
 * moving to an ahead-of-time model and {@link #onBackPressed()} and
 * {@link KeyEvent#KEYCODE_BACK} should not be used to handle back events (back gesture or
 * back button click). Instead, an {@link OnBackInvokedCallback} should be registered using
 * {@link Dialog#getOnBackInvokedDispatcher()}
 * {@link OnBackInvokedDispatcher#registerOnBackInvokedCallback(int, OnBackInvokedCallback)
 * .registerOnBackInvokedCallback(priority, callback)}.
 */
 @Deprecated
 public void onBackPressed() {
 if (mCancelable) {
 cancel();
 }
 }

取消的问题 #

我们知道事件（MotionEvent）先发送至ViewRootImpl，然后给对应的Window。在Dialog中的Window同样对应PhoneWIndow实例。随后Window先把事件传给Window.Callback，Activity和Dialog都实现了Window.Callback接口，所以它们才能收到事件。

Window.Callback先把事件分发给自己的View，从DecorView开始，一直到根节点的View。如果所有View都不消费事件，事件最后还是回到Window.Callback，在这里是Dialog。交给onTouchEvent。可以看到是判断能不能被取消且有没有点击在Window上，如果都满足，Dialog就被cancel了。

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


 /**
 * Called when a touch screen event was not handled by any of the views
 * under it. This is most useful to process touch events that happen outside
 * of your window bounds, where there is no view to receive it.
 * 
 * @param event The touch screen event being processed.
 * @return Return true if you have consumed the event, false if you haven't.
 * The default implementation will cancel the dialog when a touch
 * happens outside of the window bounds.
 */
 public boolean onTouchEvent(@NonNull MotionEvent event) {
 if (mCancelable && mShowing && mWindow.shouldCloseOnTouch(mContext, event)) {
 cancel();
 return true;
 }
 
 return false;
 }

mWindow.shouldCloseOnTouch中判断点击在Window外部需要不需要取消的依据就是mCloseOnTouchOutside。

到这里setCanceledOnTouchOutside这一部分清晰了。

在Android中除了MotionEvent还有另一套事件——KeyEvent，用作分发按键。

KeyEvent事件会先交给DecorView，DecorView又把事件给了Window.Callback….是不是很熟悉，没错，又到了DIalog。只不过这次是dispatchKeyEvent。如果没有消费，最后依旧回到Dialog。如果事件手指离开按键，那么会触发onBackPressed()。

1
2
3
4
5


 public void onBackPressed() {
 if (mCancelable) {
 cancel();
 }
 }

2024：我的成长与思考

Sun, 12 Jan 2025 13:32:33 +0800

我没有忘写年终总结，但是忘了去年写在哪，今天才找到。按照惯例总结下去年在各方面，写下新一年的目标。

工作 #

23年11月份入职，到元旦一年出头，时间算不上长。与之前相比，感受最明显的还是流程，在上一家需求评审完了就可以开始干活了，在这里才刚开始。到真的开始写需求，需要经过预沟通（和领导们，没我什么事）、需求评审、技术预审、技术内审、技术外审后才是真的开始写代码。这背后的是对风险的把控，时间都是算好的，每一个齿轮都要按照争取的节奏转动。

收获更多的是作为一个owner（不喜欢这个词），背上责任，压力倍增，附带效果是人稍自信了些，代价是交出了自己的时间。

生活 #

这一年去了成都，从成都去了重庆，中间去了大同，十月份又去了香港，和上一次的香港有很大不同。在年前去了南京，又从南京跑到杭州，赶在远到前回到北京。

更喜欢旅行，喜欢看形形色色的人，不同城市的人是怎么生活的，有什么不同的文化，很有趣。相机又买了索尼，买东西像是做选择题，没有办法做到尽善尽美。看中优势，排除劣势或者接受没有缺点。

突然意识到26周岁了。

朋友还是几个，工作中认识了更多几个，认识人很容易，相处得来不是件容易事。

读书 #

这一年看了120个小时，每天大概19分钟，甚至比上一年更少，总有各种各样的新奇事想尝试，读书上花费的时间少的可怜。

今年印象最深刻的几本书：

《看见》 - 看见人。
《李光耀观天下（精装版）》 - 李光耀视角下的东南亚国家和美国。
《丰乳肥臀》 - 社会的变迁和伟大的母亲。
《哲学家们都干了些什么（修订版）》 - 哲学史也是找寻人生意义的历程。
《无人生还》 - 阿加莎精彩的悬疑小说。
《王能好》 - 乡村人王能好。
《新摄影笔记》 - 补足摄影技巧。

如果只能推荐一本，我会选《哲学家们都干了些什么（修订版）》。如果你对哲学感兴趣，又恰好想知道人生的意义到底是什么，很是推荐。

2025新年目标 #

去年的目标几乎都完成了，结果还不错。写下目标的意义是提醒自己有几个方向需要努力。

㊙️
读书时间150小时，日均阅读时长20+分钟。（和去年一样）。
养猫咪
攒钱。
能熟练用CPP。
考一次雅思。
再掌握一门新的技能。

Context是什么

Sun, 05 Jan 2025 14:41:24 +0800

Context是什么？这是从我开始学习Android就有的疑问，刚入行时找了无数的文章，也没有谁能解答我的疑问，有的是不断的告诉我Context是上下文，这不废话吗，我查不到Context的意思是上下文吗？我的意思是什么的上下文。

一转眼工作好几年了，实在惭愧。这两天突然想到Context（思维涣散，容易乱想），想到了Context。我想，现在我可以回答Context是什么了。

还是拿出那张Context的族谱。

当你用到一个方法的时候，传的都是Context，很少是Activity或者是Application，我知道也有，但是少。

Context还真就是上下文（也是废话），当你需要拿到资源的时候，真正给你资源的是ContextImpl对象，但是每个Context最后都会和ContextImpl联系起来。

举个例子，当你用Context.getResources想通过这个拿到一个字符串或者一个图片的时候，context不管是哪种都会给你，但是只有ContextImpl有这个能力。这是因为当你用ContextWrapper中的一种时，ContextWrapper中持有ContextImpl的成员变量，会把从ContextImpl那拿到的给你（多像领导🤣），让你以为是ContextWrapper给你的。当你用的是ContextImpl时，给资源的就是它，当然也是可以的（一一般不会这么用）。

只要你有Context，你就能拿到你想要的资源，这像不像是只要你站在某个区域，你就可以做到，这个是我理解的的上下文（Context）。

其他的像是PackageInfo、ContentResolver、Theme…都是类似的，外观模式。

Android代码混淆

Sun, 05 Jan 2025 10:41:55 +0800

在Android应用开发完成，上架前，一般是要经过加固和混淆两个步骤的，加固的原理我不懂，整理了混淆相关的知识和文档。供自己和有需要的朋友查阅。

目的 #

一定是有什么作用，否则是不会加入的。混淆的作用是什么呢？

移除运行时不是用的方法和资源，减少应用体积（缩减代码-官方介绍）
用更短的无意义的名称替换类名、属性名，替换后的代码更不宜读，增加反编译难度
检查并重写代码，进一步减少应用dex大小，提高运行速度（代码优化-官方介绍）

配置 #

我们知道Gradle是一套构建的工具，提供标准的流程，你可以用Gradle构建Java后端项目，可以构建Android项目。一般来说包括，Gradle需要经过初始化、配置、执行三个步骤。task是Gradle执行的最小单位，混淆task并不是流程中的一环，想要用Gradle混淆，是需要手动添加混淆task的。

Android项目之所以不需要你手动添加混淆的插件，简单的几行代码是开启混淆，是在Android项目的Gradle插件android中已经帮你做了这部分工作。你只需要修改几个配置即可。Android是用的是Google推出的R8，使用ProGuard 规则文件来修改其默认行为。

开启混淆 #

你需要在开启混淆的Android模块的build.gradle文件中，设置minifyEnabled的值为true，比如最常用的在构建release时：

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


android {
 buildTypes {
 release {
 // debuggable置为false是开启混淆的前提
 debuggable false

 minifyEnabled true

 // 缩减没有用到的资源
 shrinkResources true

 // 混淆规则配置
 proguardFiles getDefaultProguardFile(
 'proguard-android-optimize.txt'),
 'proguard-rules.pro'
 }
 }
 ...
}

当你新建一个Android项目时，模板会帮你添加上proguardfiles这行代码，即使你不开启混淆。

虽然写在一行，其实是两个文件，你可以把多个配置列在这里，中间用英文逗号隔开。再说模板加上的两个文件含义，proguard-android-optimize.txt从Android Gradle插件生成的，其中包含了对大多数Android项目都能用的规则，当你用Android Studio创建新模块，会帮你创建proguard-rules.pro文件，默认是空的，需要你添加规则。此外还包含其他配置文件。

来源	位置	说明
Android Studio	`<module-dir>/<wbr/>proguard-rules.<wbr/>pro`	当您使用 Android Studio 创建新模块时，Android Studio 会在该模块的根目录中创建 `proguard-rules.<wbr/>pro` 文件。默认情况下，此文件不会应用任何规则。因此，请在此处添加您自己的 ProGuard 规则，比如自定义保留规则。
Android Gradle 插件	由 Android Gradle 插件在编译时生成。	Android Gradle 插件会生成 `proguard-android-optimize.<wbr/>txt`（其中包含了对大多数 Android 项目都有用的规则），并启用 `@Keep\*` 注解。默认情况下，使用 Android Studio 创建新模块时，模块级 build 脚本会将此规则文件纳入到您的发布 build 中。注意：虽然 Android Gradle 插件包含额外的预定义 ProGuard 规则文件，但建议您使用 `proguard-android-optimize.txt`。
库依赖项	在 AAR 库中： `proguard.txt` 在 JAR 库中： `META-INF/proguard/<ProGuard-rules-file>` 除了这些位置之外，Android Gradle 插件 3.6 或更高版本还支持有针对性缩减规则。	如果某个 AAR 或 JAR 库是使用它自己的规则文件发布的，并且您将该库作为编译时依赖项纳入到项目中，那么 R8 在编译项目时会自动应用这些规则。除了传统的 ProGuard 规则之外，Android Gradle 插件 3.6 或更高版本还支持有针对性缩减规则。这些规则针对特定缩减器（R8 或 ProGuard）以及特定缩减器版本。如果库需要某些规则才能正常运行，那么使用该库随附的规则文件将非常有用。也就是说，库开发者已经为您执行了问题排查步骤。不过，您应该知道，因为这些规则是累加的，所以库依赖项包含的某些规则无法移除，并且可能会影响应用其他部分的编译。例如，如果某个库包含停用代码优化的规则，该规则将针对整个项目停用优化。
Android 资源打包工具 2 (AAPT2)	使用 `minifyEnabled true` 构建项目后：`<module-dir>/<wbr/>build/<wbr/>intermediates/<wbr/>aapt_<wbr/>proguard_<wbr/>file/<wbr/>.<wbr/>.<wbr/>.<wbr/>/<wbr/>aapt_<wbr/>rules.<wbr/>txt`	AAPT2 会根据对应用清单中的类、布局及其他应用资源的引用，生成保留规则。例如，AAPT2 会为您在应用清单中注册为入口点的每个 activity 添加一个保留规则。
自定义配置文件	默认情况下，当您使用 Android Studio 创建新模块时，IDE 会创建 `<module-dir>/<wbr/>proguard-rules.<wbr/>pro`，以便您添加自己的规则。	您可以添加其他配置，R8 会在编译时应用这些配置。

你可以在模块的pooguard-rules.pro文件中添加-printconfiguration ~/tmp/full-r8-config.txt以打印出所有规则。当然你可以修改路径。

规则 #

混淆规则不指定时，认为所有的类、成员变量、方法都可以缩减成a.b.c的形式，代码还在，知识名称变了。你需要指定保留哪些让你的应用能够用正常运行，（保留的越少越好，我们的目就是要把代码变成看不懂的形式）。

规则实在是多，详细的参见Configuration - Usage

还原 #

Android SDK中提供了恢复还原的工具：retrace 。路径位于SDK包的：cmdline-tools/version/bin/中。当你的应用出现崩溃时，你可以用它找到混淆混淆前的路径。

用法：

1

retrace path-to-mapping-file [path-to-stack-trace-file] [options]

之后终端会等你收入异常的堆栈，粘贴进去。终止：

Linux、macOS：Control+D
Windows：Ctrl+Z+Enter

即可看到原始堆栈信息。

参考 #

理解View焦点机制

Sat, 04 Jan 2025 13:35:24 +0800

本篇内容探讨View的焦点。怎么算有焦点，同一时间有几个View有焦点，焦点的分发又是怎么回事。

焦点 #

View有个方法叫hasFocus，返回值是boolean类型的，用来判断View是否有焦点。hasFocus只做了简单的一件事，判断flag中是否包含PFLAG_FOCUSED。

1

 return (mPrivateFlags & PFLAG_FOCUSED) != 0;

因此只要有PFLAG_FOCUSED这个flag就是有焦点了。

焦点分发 #

以PFLAG_FOCUSED作为突破点，很容易找到开端。最最开始是从ViewRootImpl开始的。事件的分发相信你是熟悉的，上层事件分发的起点也是焦点分发的起点，原因是在事件的ACTION_DOWN事件中，把焦点交给符合条件的View。

 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


private boolean performFocusNavigation(KeyEvent event) {
 ...
 View focused = mView.findFocus();
 if (focused != null) {
 View v = focused.focusSearch(direction);
 if (v != null && v != focused) {
 // Do the math to get the interesting rect
 // of previous focused into the coord system of
 // newly focused view
 focused.getFocusedRect(mTempRect);
 if (mView instanceof ViewGroup) {
 ((ViewGroup) mView).offsetDescendantRectToMyCoords(focused, mTempRect);
 ((ViewGroup) mView).offsetRectIntoDescendantCoords(v, mTempRect);
 }
 if (v.requestFocus(direction, mTempRect)) {
 boolean isFastScrolling = event.getRepeatCount() > 0;
 playSoundEffect(SoundEffectConstants.getConstantForFocusDirection(direction, isFastScrolling));
 return true;
 }
 }

 // Give the focused view a last chance to handle the dpad key.
 if (mView.dispatchUnhandledMove(focused, direction)) {
 return true;
 }
 } else {
 if (mView.restoreDefaultFocus()) {
 return true;
 }
 }
 ...
}

ViewRootImpl中唯一的一个View是DecorView，开始时找不到焦点，会把焦点给DecorView。DecorView会在requestFocus中分发下去，最终焦点会给第一个满足条件的View。

在这里ViewGroup需要策略和顺序。策略分别有：

FOCUS_BLOCK_DESCENDANTS: 不给子View焦点，即使该View没有获取到焦点
FOCUS_BEFORE_DESCENDANTS: 先于子View获取焦点，失败后才尝试给子View
FOCUS_AFTER_DESCENDANTS: 所有子View获取焦点失败后，才尝试获取焦点

分发的方向是根据ViewRootImpl分发的事件的KeyEvent。

这就是第一次点击时焦点分发的过程。

第二次点击时，拿到上次得到焦点的View。也会按照这次的分发的方向找到一个应该获取焦点的View。

焦点的条件 #

View需要满足以下几个条件时才有可能获取到焦点。

可见
focusable
enable
size > 0

转换 #

两个View不同时用到了两个方法：

方法名	转换方向	常用场景
`offsetDescendantRectToMyCoords`	从子视图坐标系到当前视图坐标系	计算子视图在当前视图中的具体位置
`offsetRectIntoDescendantCoords`	从当前视图坐标系到子视图坐标系	计算当前视图的某区域相对于子视图的位置

结合起来也就是把两个View的坐标转换成一致的，把这个矩形给下去，以便在View的onFocusChanged可以用到，比如ListView需要显示有焦点的View，需要移动。

ADB protocol

Sat, 04 Jan 2025 09:10:44 +0800

说明 #

网上太多文章写ADB，不尽详细，大多一知半解，干脆找来官方文件。

你最好按照下面的顺序阅读：

三篇都是复制自AOSP13源码，无修改，请放心阅读。

原文 #

 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
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297


--- a replacement for aproto -------------------------------------------

When it comes down to it, aproto's primary purpose is to forward
various streams between the host computer and client device (in either
direction).

This replacement further simplifies the concept, reducing the protocol
to an extremely straightforward model optimized to accomplish the
forwarding of these streams and removing additional state or
complexity.

The host side becomes a simple comms bridge with no "UI", which will 
be used by either commandline or interactive tools to communicate with 
a device or emulator that is connected to the bridge.

The protocol is designed to be straightforward and well-defined enough 
that if it needs to be reimplemented in another environment (Java 
perhaps), there should not problems ensuring perfect interoperability.

The protocol discards the layering aproto has and should allow the 
implementation to be much more robust.


--- protocol overview and basics ---------------------------------------

The transport layer deals in "messages", which consist of a 24 byte
header followed (optionally) by a payload. The header consists of 6
32 bit words which are sent across the wire in little endian format.

struct message {
 unsigned command; /* command identifier constant (A_CNXN, ...) */
 unsigned arg0; /* first argument */
 unsigned arg1; /* second argument */
 unsigned data_length; /* length of payload (0 is allowed) */
 unsigned data_crc32; /* crc32 of data payload */
 unsigned magic; /* command ^ 0xffffffff */
};

Receipt of an invalid message header, corrupt message payload, or an
unrecognized command MUST result in the closing of the remote
connection. The protocol depends on shared state and any break in the
message stream will result in state getting out of sync.

The following sections describe the six defined message types in
detail. Their format is COMMAND(arg0, arg1, payload) where the payload
is represented by a quoted string or an empty string if none should be
sent.

The identifiers "local-id" and "remote-id" are always relative to the
*sender* of the message, so for a receiver, the meanings are effectively
reversed.



--- CONNECT(version, maxdata, "system-identity-string") ----------------

Command constant: A_CNXN

The CONNECT message establishes the presence of a remote system.
The version is used to ensure protocol compatibility and maxdata
declares the maximum message body size that the remote system
is willing to accept.

Currently, version=0x01000000 and maxdata=256*1024. Older versions of adb
hard-coded maxdata=4096, so CONNECT and AUTH packets sent to a device must not
be larger than that because they're sent before the CONNECT from the device
that tells the adb server what maxdata the device can support.

Both sides send a CONNECT message when the connection between them is
established. Until a CONNECT message is received no other messages may
be sent. Any messages received before a CONNECT message MUST be ignored.

If a CONNECT message is received with an unknown version or insufficiently
large maxdata value, the connection with the other side must be closed.

The system identity string should be "<systemtype>:<serialno>:<banner>"
where systemtype is "bootloader", "device", or "host", serialno is some
kind of unique ID (or empty), and banner is a human-readable version
or identifier string. The banner is used to transmit useful properties.

--- STLS(type, version, "") --------------------------------------------

Command constant: A_STLS

The TLS message informs the recipient that the connection will be encrypted
and will need to perform a TLS handshake. version is the current version of
the protocol.


--- AUTH(type, 0, "data") ----------------------------------------------

Command constant: A_AUTH

The AUTH message informs the recipient that authentication is required to
connect to the sender. If type is TOKEN(1), data is a random token that
the recipient can sign with a private key. The recipient replies with an
AUTH packet where type is SIGNATURE(2) and data is the signature. If the
signature verification succeeds, the sender replies with a CONNECT packet.

If the signature verification fails, the sender replies with a new AUTH
packet and a new random token, so that the recipient can retry signing
with a different private key.

Once the recipient has tried all its private keys, it can reply with an
AUTH packet where type is RSAPUBLICKEY(3) and data is the public key. If
possible, an on-screen confirmation may be displayed for the user to
confirm they want to install the public key on the device.


--- OPEN(local-id, 0, "destination") -----------------------------------

Command constant: A_OPEN

The OPEN message informs the recipient that the sender has a stream
identified by local-id that it wishes to connect to the named
destination in the message payload. The local-id may not be zero.

The OPEN message MUST result in either a READY message indicating that
the connection has been established (and identifying the other end) or
a CLOSE message, indicating failure. An OPEN message also implies
a READY message sent at the same time.

Common destination naming conventions include:

* "tcp:<host>:<port>" - host may be omitted to indicate localhost
* "udp:<host>:<port>" - host may be omitted to indicate localhost
* "vsock:<CID>:<port>"
* "local-dgram:<identifier>"
* "local-stream:<identifier>"
* "shell" - local shell service
* "upload" - service for pushing files across (like aproto's /sync)
* "fs-bridge" - FUSE protocol filesystem bridge


--- READY(local-id, remote-id, "") -------------------------------------

Command constant: A_OKAY

The READY message informs the recipient that the sender's stream
identified by local-id is ready for write messages and that it is
connected to the recipient's stream identified by remote-id.

Neither the local-id nor the remote-id may be zero.

A READY message containing a remote-id which does not map to an open
stream on the recipient's side is ignored. The stream may have been
closed while this message was in-flight.

The local-id is ignored on all but the first READY message (where it
is used to establish the connection). Nonetheless, the local-id MUST
not change on later READY messages sent to the same stream.


--- WRITE(local-id, remote-id, "data") ---------------------------------

Command constant: A_WRTE

The WRITE message sends data to the recipient's stream identified by
remote-id. The payload MUST be <= maxdata in length.

A WRITE message containing a remote-id which does not map to an open
stream on the recipient's side is ignored. The stream may have been
closed while this message was in-flight.

A WRITE message may not be sent until a READY message is received.
Once a WRITE message is sent, an additional WRITE message may not be
sent until another READY message has been received. Recipients of
a WRITE message that is in violation of this requirement will CLOSE
the connection.


--- CLOSE(local-id, remote-id, "") -------------------------------------

Command constant: A_CLSE

The CLOSE message informs recipient that the connection between the
sender's stream (local-id) and the recipient's stream (remote-id) is
broken. The remote-id MUST not be zero, but the local-id MAY be zero
if this CLOSE indicates a failed OPEN.

A CLOSE message containing a remote-id which does not map to an open
stream on the recipient's side is ignored. The stream may have
already been closed by the recipient while this message was in-flight.

The recipient should not respond to a CLOSE message in any way. The
recipient should cancel pending WRITEs or CLOSEs, but this is not a
requirement, since they will be ignored.


--- SYNC(online, sequence, "") -----------------------------------------

Command constant: A_SYNC

*** obsolete, no longer used ***

The SYNC message was used by the io pump to make sure that stale
outbound messages are discarded when the connection to the remote side
is broken. It was only used internally to the bridge and never valid
to send across the wire.

* when the connection to the remote side goes offline, the io pump
 sends a SYNC(0, 0) and starts discarding all messages
* when the connection to the remote side is established, the io pump
 sends a SYNC(1, token) and continues to discard messages
* when the io pump receives a matching SYNC(1, token), it once again
 starts accepting messages to forward to the remote side


--- message command constants ------------------------------------------

#define A_SYNC 0x434e5953
#define A_CNXN 0x4e584e43
#define A_AUTH 0x48545541
#define A_OPEN 0x4e45504f
#define A_OKAY 0x59414b4f
#define A_CLSE 0x45534c43
#define A_WRTE 0x45545257
#define A_STLS 0x534C5453



--- implementation details ---------------------------------------------

The core of the bridge program will use three threads. One thread
will be a select/epoll loop to handle io between various inbound and
outbound connections and the connection to the remote side.

The remote side connection will be implemented as two threads (one for
reading, one for writing) and a datagram socketpair to provide the
channel between the main select/epoll thread and the remote connection
threadpair. The reason for this is that for usb connections, the
kernel interface on linux and osx does not allow you to do meaningful
nonblocking IO.

The endian swapping for the message headers will happen (as needed) in
the remote connection threadpair and that the rest of the program will
always treat message header values as native-endian.

The bridge program will be able to have a number of mini-servers
compiled in. They will be published under known names (examples
"shell", "fs-bridge", etc) and upon receiving an OPEN() to such a
service, the bridge program will create a stream socketpair and spawn
a thread or subprocess to handle the io.


--- simplified / embedded implementation -------------------------------

For limited environments, like the bootloader, it is allowable to
support a smaller, fixed number of channels using pre-assigned channel
ID numbers such that only one stream may be connected to a bootloader
endpoint at any given time. The protocol remains unchanged, but the
"embedded" version of it is less dynamic.

The bootloader will support two streams. A "bootloader:debug" stream,
which may be opened to get debug messages from the bootloader and a 
"bootloader:control", stream which will support the set of basic 
bootloader commands.

Example command stream dialogues: 
 "flash_kernel,2515049,........\n" "okay\n" 
 "flash_ramdisk,5038,........\n" "fail,flash write error\n" 
 "bogus_command......" <CLOSE>


--- future expansion ---------------------------------------------------

I plan on providing either a message or a special control stream so that
the client device could ask the host computer to setup inbound socket
translations on the fly on behalf of the client device.


The initial design does handshaking to provide flow control, with a
message flow that looks like:

 >OPEN <READY >WRITE <READY >WRITE <READY >WRITE <CLOSE

The far side may choose to issue the READY message as soon as it receives
a WRITE or it may defer the READY until the write to the local stream
succeeds. A future version may want to do some level of windowing where
multiple WRITEs may be sent without requiring individual READY acks.

------------------------------------------------------------------------

--- smartsockets -------------------------------------------------------

Port 5037 is used for smart sockets which allow a client on the host
side to request access to a service in the host adb daemon or in the
remote (device) daemon. The service is requested by ascii name,
preceeded by a 4 digit hex length. Upon successful connection an
"OKAY" response is sent, otherwise a "FAIL" message is returned. Once
connected the client is talking to that (remote or local) service.

client: <hex4> <service-name>
server: "OKAY"

client: <hex4> <service-name>
server: "FAIL" <hex4> <reason>

ADB SERVICES

Sat, 04 Jan 2025 09:06:42 +0800

说明 #

网上太多文章写ADB，不尽详细，大多一知半解，干脆找来官方文件。

你最好按照下面的顺序阅读：

三篇都是复制自AOSP13源码，无修改，请放心阅读。

原文 #

 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
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250


This file tries to document all requests a client can make
to the ADB server of an adbd daemon. See the OVERVIEW.TXT document
to understand what's going on here.

HOST SERVICES:

host:version
 Ask the ADB server for its internal version number.

host:kill
 Ask the ADB server to quit immediately. This is used when the
 ADB client detects that an obsolete server is running after an
 upgrade.

host:devices
host:devices-l
 Ask to return the list of available Android devices and their
 state. devices-l includes the device paths in the state.
 After the OKAY, this is followed by a 4-byte hex len,
 and a string that will be dumped as-is by the client, then
 the connection is closed

host:track-devices
 This is a variant of host:devices which doesn't close the
 connection. Instead, a new device list description is sent
 each time a device is added/removed or the state of a given
 device changes (hex4 + content). This allows tools like DDMS
 to track the state of connected devices in real-time without
 polling the server repeatedly.

host:emulator:<port>
 This is a special query that is sent to the ADB server when a
 new emulator starts up. <port> is a decimal number corresponding
 to the emulator's ADB control port, i.e. the TCP port that the
 emulator will forward automatically to the adbd daemon running
 in the emulator system.

 This mechanism allows the ADB server to know when new emulator
 instances start.

host:transport:<serial-number>
 Ask to switch the connection to the device/emulator identified by
 <serial-number>. After the OKAY response, every client request will
 be sent directly to the adbd daemon running on the device.
 (Used to implement the -s option)

host:transport-usb
 Ask to switch the connection to one device connected through USB
 to the host machine. This will fail if there are more than one such
 devices. (Used to implement the -d convenience option)

host:transport-local
 Ask to switch the connection to one emulator connected through TCP.
 This will fail if there is more than one such emulator instance
 running. (Used to implement the -e convenience option)

host:transport-any
 Another host:transport variant. Ask to switch the connection to
 either the device or emulator connect to/running on the host.
 Will fail if there is more than one such device/emulator available.
 (Used when neither -s, -d or -e are provided)

host-serial:<serial-number>:<request>
 This is a special form of query, where the 'host-serial:<serial-number>:'
 prefix can be used to indicate that the client is asking the ADB server
 for information related to a specific device. <request> can be in one
 of the format described below.

host-usb:<request>
 A variant of host-serial used to target the single USB device connected
 to the host. This will fail if there is none or more than one.

host-local:<request>
 A variant of host-serial used to target the single emulator instance
 running on the host. This will fail if there is none or more than one.

host:<request>
 When asking for information related to a device, 'host:' can also be
 interpreted as 'any single device or emulator connected to/running on
 the host'.

<host-prefix>:get-product
 XXX

<host-prefix>:get-serialno
 Returns the serial number of the corresponding device/emulator.
 Note that emulator serial numbers are of the form "emulator-5554"

<host-prefix>:get-devpath
 Returns the device path of the corresponding device/emulator.

<host-prefix>:get-state
 Returns the state of a given device as a string.

<host-prefix>:forward:<local>;<remote>
 Asks the ADB server to forward local connections from <local>
 to the <remote> address on a given device.

 There, <host-prefix> can be one of the
 host-serial/host-usb/host-local/host prefixes as described previously
 and indicates which device/emulator to target.

 the format of <local> is one of:

 tcp:<port> -> TCP connection on localhost:<port>
 local:<path> -> Unix local domain socket on <path>

 the format of <remote> is one of:

 tcp:<port> -> TCP localhost:<port> on device
 local:<path> -> Unix local domain socket on device
 jdwp:<pid> -> JDWP thread on VM process <pid>
 vsock:<CID>:<port> -> vsock on the given CID and port

 or even any one of the local services described below.

<host-prefix>:forward:norebind:<local>;<remote>
 Same as <host-prefix>:forward:<local>;<remote> except that it will
 fail it there is already a forward connection from <local>.

 Used to implement 'adb forward --no-rebind <local> <remote>'

<host-prefix>:killforward:<local>
 Remove any existing forward local connection from <local>.
 This is used to implement 'adb forward --remove <local>'

<host-prefix>:killforward-all
 Remove all forward network connections.
 This is used to implement 'adb forward --remove-all'.

<host-prefix>:list-forward
 List all existing forward connections from this server.
 This returns something that looks like the following:

 <hex4>: The length of the payload, as 4 hexadecimal chars.
 <payload>: A series of lines of the following format:

 <serial> " " <local> " " <remote> "\n"

 Where <serial> is a device serial number.
 <local> is the host-specific endpoint (e.g. tcp:9000).
 <remote> is the device-specific endpoint.

 Used to implement 'adb forward --list'.

LOCAL SERVICES:

All the queries below assumed that you already switched the transport
to a real device, or that you have used a query prefix as described
above.

shell:command arg1 arg2 ...
 Run 'command arg1 arg2 ...' in a shell on the device, and return
 its output and error streams. Note that arguments must be separated
 by spaces. If an argument contains a space, it must be quoted with
 double-quotes. Arguments cannot contain double quotes or things
 will go very wrong.

 Note that this is the non-interactive version of "adb shell"

shell:
 Start an interactive shell session on the device. Redirect
 stdin/stdout/stderr as appropriate. Note that the ADB server uses
 this to implement "adb shell", but will also cook the input before
 sending it to the device (see interactive_shell() in commandline.c)

remount:
 Ask adbd to remount the device's filesystem in read-write mode,
 instead of read-only. This is usually necessary before performing
 an "adb sync" or "adb push" request.

 This request may not succeed on certain builds which do not allow
 that.

tcp:<port>
 Tries to connect to tcp port <port> on localhost.

tcp:<port>:<server-name>
 Tries to connect to tcp port <port> on machine <server-name> from
 the device. This can be useful to debug some networking/proxy
 issues that can only be revealed on the device itself.

local:<path>
 Tries to connect to a Unix domain socket <path> on the device

localreserved:<path>
localabstract:<path>
localfilesystem:<path>
 Variants of local:<path> that are used to access other Android
 socket namespaces.

framebuffer:
 This service is used to send snapshots of the framebuffer to a client.
 It requires sufficient privileges but works as follow:

 After the OKAY, the service sends 16-byte binary structure
 containing the following fields (little-endian format):

 depth: uint32_t: framebuffer depth
 size: uint32_t: framebuffer size in bytes
 width: uint32_t: framebuffer width in pixels
 height: uint32_t: framebuffer height in pixels

 With the current implementation, depth is always 16, and
 size is always width*height*2

 Then, each time the client wants a snapshot, it should send
 one byte through the channel, which will trigger the service
 to send it 'size' bytes of framebuffer data.

 If the adbd daemon doesn't have sufficient privileges to open
 the framebuffer device, the connection is simply closed immediately.

jdwp:<pid>
 Connects to the JDWP thread running in the VM of process <pid>.

track-jdwp
 This is used to send the list of JDWP pids periodically to the client.
 The format of the returned data is the following:

 <hex4>: the length of all content as a 4-char hexadecimal string
 <content>: a series of ASCII lines of the following format:
 <pid> "\n"

 This service is used by DDMS to know which debuggable processes are running
 on the device/emulator.

 Note that there is no single-shot service to retrieve the list only once.

sync:
 This starts the file synchronization service, used to implement "adb push"
 and "adb pull". Since this service is pretty complex, it will be detailed
 in a companion document named SYNC.TXT

reverse:<forward-command>
 This implements the 'adb reverse' feature, i.e. the ability to reverse
 socket connections from a device to the host. <forward-command> is one
 of the forwarding commands that are described above, as in:

 list-forward
 forward:<local>;<remote>
 forward:norebind:<local>;<remote>
 killforward-all
 killforward:<local>

 Note that in this case, <local> corresponds to the socket on the device
 and <remote> corresponds to the socket on the host.

 The output of reverse:list-forward is the same as host:list-forward
 except that <serial> will be just 'host'.

ADB README

Sat, 04 Jan 2025 08:56:06 +0800

说明 #

网上太多文章写ADB，不尽详细，大多一知半解，干脆找来官方文件。

你最好按照下面的顺序阅读：

三篇都是复制自AOSP13源码，无修改，请放心阅读。

原文 #

ADB Internals #

If you are new to adb source code, you should start by reading OVERVIEW.TXT which describes the three components of adb pipeline.

This document is here to boost what can be achieved within a “window of naive interest”. You will not find function or class documentation here but rather the “big picture” which should allow you to build a mental map to help navigate the code.

Three components of adb pipeline #

As outlined in the overview, this codebase generates three components (Client, Server (a.k.a Host), and Daemon (a.k.a adbd)). The central part is the Server which runs on the Host computer. On one side the Server exposes a “Smart Socket” to Clients such as adb or DDMLIB. On the other side, the Server continuously monitors for connecting Daemons (as USB devices or TCP emulator). Communication with a device is done with a Transport.

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


+----------+ +------------------------+
| ADB +----------+ | ADB SERVER | +----------+
| CLIENT | | | | (USB)| ADBD |
+----------+ | | Transport+-------------+ (DEVICE) |
 | | | +----------+
+----------- | | |
| ADB | v + | +----------+
| CLIENT +--------->SmartSocket | (USB)| ADBD |
+----------+ ^ | (TCP/IP) Transport+-------------+ (DEVICE) |
 | | | +----------+
+----------+ | | |
| DDMLIB | | | Transport+--+ +----------+
| CLIENT +----------+ | | | (TCP/IP)| ADBD |
+----------+ +------------------------+ +----------|(EMULATOR)|
 +----------+

The Client and the Server are contained in the same executable and both run on the Host machine. Code sections specific to the Host is enclosed within ADB_HOST guard. adbd runs on the Android Device. Daemon specific code is enclosed in !ADB_HOST but also sometimes with-in __ANDROID__ guard.

“SMART SOCKET” and TRANSPORT #

A smart socket is a simple TCP socket with a smart protocol built on top of it. This is what Clients connect onto from the Host side. The Client must always initiate communication via a human readable request but the response format varies. The smart protocol is documented in SERVICES.TXT.

On the other side, the Server communicates with a device via a Transport. adb initially targeted devices connecting over USB, which is restricted to a fixed number of data streams. Therefore, adb multiplexes multiple byte streams over a single pipe via Transport. When devices connecting over other mechanisms (e.g. emulators over TCP) were introduced, the existing transport protocol was maintained.

THREADING MODEL and FDEVENT system #

At the heart of both the Server and Daemon is a main thread running an fdevent loop, which is a platform-independent abstraction over poll/epoll/WSAPoll monitoring file descriptors events. Requests and services are usually served from the main thread but some service requests result in new threads being spawned.

To allow for operations to run on the Main thread, fdevent features a RunQueue combined with an interrupt fd to force polling to return.

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


+------------+ +-------------------------^
| RUNQUEUE | | |
+------------+ | POLLING (Main thread) |
| Function<> | | |
+------------+ | |
| Function<> | ^-^-------^-------^------^^
+------------+ | | | |
| ... | | | | |
+------------+ | | | |
| | | | | |
|============| | | | |
|Interrupt fd+------+ +----+ +----+ +----+
+------------+ fd Socket Pipe

ASOCKET, APACKET, and AMESSAGE #

The asocket, apacket, and amessage constructs exist only to wrap data while it transits on a Transport. An asocket handles a stream of apackets. An apacket consists in a amessage header featuring a command (A_SYNC, A_OPEN, A_CLSE, A_WRTE, A_OKAY, …) followed by a payload (find more documentation in protocol.txt. There is no A_READ command because an asocket is unidirectional. To model a bi-directional stream, asocket have a peer which go in the opposite direction.

An asocket features a buffer where the elemental unit is an apacket. If traffic is inbound, the buffer stores the apacket until it is consumed. If the traffic is oubound, the buffer stores apackets until they are sent down the wire (with A_WRTE commands).

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


+---------------------ASocket------------------------+
 | |
 | +----------------APacket Queue------------------+ |
 | | | |
 | | APacket APacket APacket | |
 | | +--------+ +--------+ +--------+ | |
 | | |AMessage| |AMessage| |AMessage| | |
 | | +--------+ +--------+ +--------+ | |
 | | | | | | | | | |
 | | ..... | | | | | | | |
 | | | Data | | Data | | Data | | |
 | | | | | | | | | |
 | | | | | | | | | |
 | | +--------+ +--------+ +--------+ | |
 | | | |
 | +-----------------------------------------------+ |
 +---------------------------------------------------+

This system allows to multiplex data streams on an unique byte stream. Without entering too much into details, the amessage fields arg1 and arg2 are used alike in the TCP protocol where local and remote ports identify an unique stream. Note that unlike TCP which feature an “unacknowledged-send window”, an apacket is sent only after the previous one has been confirmed to be received.

The two types of asocket (Remote and Local) differentiate between outbound and inbound traffic.

adbd <-> APPPLICATION communication #

This pipeline is detailed in daemon/jdwp_service.cpp with ASCII drawings! The JDWP extension implemented by Dalvik/ART are documented in:

platform/dalvik/+/master/docs/debugmon.html
platform/dalvik/+/master/docs/debugger.html

ADB OVERVIEW

Sat, 04 Jan 2025 08:55:46 +0800

说明 #

网上太多文章写ADB，不尽详细，大多一知半解，干脆找来官方文件。

你最好按照下面的顺序阅读：

三篇都是复制自AOSP13源码，无修改，请放心阅读。

原文 #

 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
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131


Implementation notes regarding ADB.

I. General Overview:

The Android Debug Bridge (ADB) is used to:

* keep track of all Android devices and emulators instances
 connected to or running on a given host developer machine
* implement various control commands (e.g. "adb shell", "adb pull", etc.)
 for the benefit of clients (command-line users, or helper programs like
 DDMS). These commands are called 'services' in ADB.

As a whole, everything works through the following components:

1. The ADB server

 This is a background process that runs on the host machine. Its purpose
 is to sense the USB ports to know when devices are attached/removed,
 as well as when emulator instances start/stop.

 It thus maintains a list of "connected devices" and assigns a 'state'
 to each one of them: OFFLINE, BOOTLOADER, RECOVERY or ONLINE (more on
 this below).

 The ADB server is really one giant multiplexing loop whose purpose is
 to orchestrate the exchange of data (packets, really) between clients,
 services and devices.

2. The ADB daemon (adbd)

 The 'adbd' program runs as a background process within an Android device
 or emulated system. Its purpose is to connect to the ADB server
 (through USB for devices, through TCP for emulators) and provide a
 few services for clients that run on the host.

 The ADB server considers that a device is ONLINE when it has successfully
 connected to the adbd program within it. Otherwise, the device is OFFLINE,
 meaning that the ADB server detected a new device/emulator, but could not
 connect to the adbd daemon.

 The BOOTLOADER and RECOVERY states correspond to alternate states of
 devices when they are in the bootloader or recovery mode.

3. The ADB command-line client

 The 'adb' command-line program is used to run adb commands from a shell
 or a script. It first tries to locate the ADB server on the host machine,
 and will start one automatically if none is found.

 Then, the client sends its service requests to the ADB server.

 Currently, a single 'adb' binary is used for both the server and client.
 this makes distribution and starting the server easier.

4. Services

 There are essentially two kinds of services that a client can talk to.

 Host Services:
 These services run within the ADB Server and thus do not need to
 communicate with a device at all. A typical example is "adb devices"
 that is used to return the list of currently known devices and their
 states. There are a few other services, though.

 Local Services:
 These services either run within the adbd daemon, or are started by
 it on the device. The ADB server is used to multiplex streams
 between the client and the service running in adbd. In this case
 its role is to initiate the connection, then of being a pass-through
 for the data.

II. Protocol details:

1. Client <-> Server protocol:

 This section details the protocol used between ADB clients and the ADB
 server itself. The ADB server listens on TCP:localhost:5037.

 A client sends a request using the following format:

 1. A 4-byte hexadecimal string giving the length of the payload
 2. Followed by the payload itself.

 For example, to query the ADB server for its internal version number,
 the client will do the following:

 1. Connect to tcp:localhost:5037
 2. Send the string "000Chost:version" to the corresponding socket

 The 'host:' prefix is used to indicate that the request is addressed
 to the server itself (we will talk about other kinds of requests later).
 The content length is encoded in ASCII for easier debugging.

 The server should answer a request with one of the following:

 1. For success, the 4-byte "OKAY" string

 2. For failure, the 4-byte "FAIL" string, followed by a
 4-byte hex length, followed by a string giving the reason
 for failure.

 Note that the connection is still alive after an OKAY, which allows the
 client to make other requests. But in certain cases, an OKAY will even
 change the state of the connection.

 For example, the case of the 'host:transport:<serialnumber>' request,
 where '<serialnumber>' is used to identify a given device/emulator; after
 the "OKAY" answer, all further requests made by the client will go
 directly to the corresponding adbd daemon.

 The file SERVICES.TXT lists all services currently implemented by ADB.

2. Transports:

 An ADB transport models a connection between the ADB server and one device
 or emulator. There are currently two kinds of transports:

 - USB transports, for physical devices through USB

 - Local transports, for emulators running on the host, connected to
 the server through TCP

 In theory, it should be possible to write a local transport that proxies
 a connection between an ADB server and a device/emulator connected to/
 running on another machine. This hasn't been done yet though.

 Each transport can carry one or more multiplexed streams between clients
 and the device/emulator they point to. The ADB server must handle
 unexpected transport disconnections (e.g. when a device is physically
 unplugged) properly.
 

解决系统界面高度变化——WindowInsets

Wed, 01 Jan 2025 09:03:25 +0800

Android开发中，输入框作为最最基础的View之一，使用的频率是非常非常高的。

有输入框的地方就有软键盘，我知道有softinputmode可以设置软键盘弹起的行为，这只能响应软键盘弹起后整个Activity的应对行为。如果我想要拿到软键盘高度呢，这是softinputmode做不到的。你可能已经想到了监听View的变化，得到一个高度值，超过了某个阈值就认为软键盘已经弹起了。没错，这是之前常用的方式，要是我想软键盘高度会改变，怎么办？

WindowInsets #

WindowInsets是什么？window是窗口，对Android开发来说很熟悉，inset在Cambridge dictionary上解释为内衬，两个放在一起就是窗口的内衬。窗口的内衬也就是有东西占用了一部分窗口的内容，放上图片更容易理解。

WindowInsets的Window其实和Window不太一样，Android的内容显示是依赖Window的，应用中状态栏、导航栏虽然视觉效果是在应用中，其实都是在SystemUI中显示的，是在另一个Window中。所以WindowInsets中的可以理解成手机屏幕这样一个视觉窗口。

WindowInsets被设计出来就是要解决上面的这种场景的。你需要为接受软键盘高度变化的View设置一个listener，当软键盘变化时，就能从listener中拿到软键盘新的高度并做出对应处理。

1
2
3
4
5


findViewById<View>(R.id.main).setOnApplyWindowInsetsListener { v, insets ->
 val ime = insets.getInsets(WindowInsetsCompat.Type.ime())
 v.setPadding(ime.left, ime.top, ime.right, ime.bottom)
 insets
 }

细心的你也许发现了WindowInsetsCompat.Type.ime()，Type中也是有其他的类型的。像是systemBars、systemGestures等等，详细的列表你可以在在应用中全屏显示内容，并在 Compose 中处理窗口边衬区中找到。

参考 #

在应用中全屏显示内容，并在 Compose 中处理窗口边衬区

WindowInsets

软路由安装OpenWrt

Sun, 22 Dec 2024 07:51:53 +0800

软路由机器是一台J4125的小主机，只作为路由器运行。常年运行esir的固件，也是用OpenClash科学上网。大概是DNS设置的有问题，只有在fake ip模式下打开TUN时才能访问网络，挨个查原因估计要更麻烦，索性直接重装。用人编译好的固件总是不能满足需求，要么是有多余的插件，安装之后从来不打开，要么是安装一个使用频率很高的插件，却只能跟固件一起更新，综合考虑决定安装immortalWrt。好处是内核用原版OpenWrt的，只有核心的插件，其他的根据需要安装。

我开始把系统装在了U盘上，还要再把系统从U盘上复制到硬盘，嫌麻烦。直接制作U盘启动器，装到主机的硬盘上。

准备 #

一台软路由
一块U盘
一台显示器和对应的线（HDMI或是VGA）
鼠标
键盘
[winpe]工具(https://www.wepe.com.cn/)
[physdiskwrite]工具(https://m0n0.ch/wall/downloads/physdiskwrite-0.5.3.zip)

制作启动盘 #

下载winpe后选择插入的U盘制作启动盘，等待完成即可。下载physdiskwrite，解压把exe文件放到U盘跟目录

下载固件 #

访问ImmortalWrt Downloads或是ImmortalWrt Fireware Selector，如果你用和我相同的CPU，那么你需要下载x86/generic/下的。

拿J4125举例，链接就是https://downloads.immortalwrt.org/releases/23.05.4/targets/x86/generic/。列表中都是gz结尾的文件，和zip、txt的作用是一样的。gz表明文件gzip格式的。下载完成后解压得到img文件，复制到U盘的根目录。

制作启动盘用到的是img的镜像文件，你可以选择的只有img.gz结尾的文件。这些文件中差异有两个：

efi
ext4和squashfs

efi #

对应引导方式，新的主板都是支持UEFI启动的，选择两种都可以，不动。

squashfs #

ext4是可修改的，另一个是只读的，比如，路由器的恢复出厂设置功能就依赖这个只读功能

制作启动盘 #

用img.gz尝试了很多次都失败了，用img立马通过。

删除磁盘分区 #

打开桌面上的diskgenius，删除主机磁盘上的所有分区，删除后不要忘了点击左上角的保存。

将U盘中的固件复制到硬盘 #

在开始菜单中打开powershel，输入

1

physkiskwrite.exe -u $镜像文件路径

$镜像文件路径替换成你要刷的镜像文件路径。也可以直接拖拽文件到终端得到

显示finished即完成

安装 #

重启主机后狂按DEL键（一般是DEL或者F11，如果都不是搜下自己主机主板对应的按键是什么）。讲启动方式改为从U盘启动。开机等待终端能输入时也就完成了。这时候U盘就可以拔掉了。

扩容 #

安装后可用空间只有100+M留给你安装插件，但凡装个什么就爆了。直接看eSir的教程解释了原理，即使你不在意原理跟着操作也能完成。

参考 #

路由系列：软路由物理机安装openwrt 小白教程（esir高大全）

Linux装机之EFI分区理解

ext4-img.gz，squashfs.img.gz，rootfs.tar.gz等几个文件区别？

View中避免使用Context参数

Sun, 15 Dec 2024 09:22:50 +0800

工作的这几年，看见过很多次这种写法，很不爽，想吐槽。

明明View里就有个Context的变量，还要画蛇添足，再加个参数保存Context，这个Context很大概率是Activity。

恐怕是忘了传入View里的这个Context就是Activity本人吧。

来看下Activity设置内容View：

 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
77
78
79
80
81
82


// AppCompatDelegateImpl.java
// Activity解析xml布局文件的代码
@Override
public void setContentView(int resId) {
 ensureSubDecor();
 ViewGroup contentParent = mSubDecor.findViewById(android.R.id.content);
 contentParent.removeAllViews();
 LayoutInflater.from(mContext).inflate(resId, contentParent);
 mAppCompatWindowCallback.bypassOnContentChanged(mWindow.getCallback());
}

// LayoutInflater.java

// getContext
// mContext就是从Activity里传进来的兄弟
public Context getContext() {
 return mContext;
}

// 中调用到的inflate方法
public View inflate(@LayoutRes int resource, @Nullable ViewGroup root, boolean attachToRoot) {
 final Resources res = getContext().getResources();
 if (DEBUG) {
 Log.d(TAG, "INFLATING from resource: \"" + res.getResourceName(resource) + "\" ("
 + Integer.toHexString(resource) + ")");
 }

 View view = tryInflatePrecompiled(resource, res, root, attachToRoot);
 if (view != null) {
 return view;
 }
 XmlResourceParser parser = res.getLayout(resource);
 try {
 return inflate(parser, root, attachToRoot);
 } finally {
 parser.close();
 }
}

// 再往下走
private @Nullable View tryInflatePrecompiled(@LayoutRes int resource, Resources res, @Nullable ViewGroup root,
 boolean attachToRoot) {
 ...

 // Try to inflate using a precompiled layout.
 String pkg = res.getResourcePackageName(resource);
 String layout = res.getResourceEntryName(resource);

 try {
 Class clazz = Class.forName("" + pkg + ".CompiledView", false, mPrecompiledClassLoader);
 Method inflater = clazz.getMethod(layout, Context.class, int.class);
 View view = (View) inflater.invoke(null, mContext, resource);

 if (view != null && root != null) {
 // We were able to use the precompiled inflater, but now we need to do some work to
 // attach the view to the root correctly.
 XmlResourceParser parser = res.getLayout(resource);
 try {
 AttributeSet attrs = Xml.asAttributeSet(parser);
 advanceToRootNode(parser);
 ViewGroup.LayoutParams params = root.generateLayoutParams(attrs);

 if (attachToRoot) {
 root.addView(view, params);
 } else {
 view.setLayoutParams(params);
 }
 } finally {
 parser.close();
 }
 }

 return view;
 } catch (Throwable e) {
 if (DEBUG) {
 Log.e(TAG, "Failed to use precompiled view", e);
 }
 } finally {
 Trace.traceEnd(Trace.TRACE_TAG_VIEW);
 }
 return null;
}

都写明白了View view = (View) inflater.invoke(null, mContext, resource);传入的还是他。

不明白🏳️。

Ubuntu环境AOSP编译指南

Sun, 15 Dec 2024 08:08:23 +0800

起因 #

网上有这么多相似的文章，还要再写这个的原因有两个：

纸上得来终觉浅。从去年就尝试按着网上的文章编译，总也不能通过，各种各样的问题；
记录一下过程，避免踩相同的坑，也好给其他的朋友一点参考。

准备 #

环境 #

先后尝试过用Windows、Mac编译，推荐直接用Linux，不管是不是Ubuntu。

Windows的好处是方便拓展，硬盘相对便宜，日常使用我相信不是Mac就是Windows了，Windows的装机量绝对是最多的。因此开始打算在Windows上编译。为了能在Windows上用shell命令，装了一堆东西，各种方案都试过，最后还是无果费了一顿劲。

Mac的是类Unix，有现成的shell可以用，电脑配置Macbook Pro 14’ 16G内存+512G硬盘。结论是硬盘不够😅。

用Windows还是Mac都是为了偷点懒，为了省这一小点的时间，反而浪费了更多时间，得不偿失。

因此，我建议直接Linux开干。

如果你有Windows，我建议装个虚拟机，Vmware Workstation Pro对个人都免费了，Linux镜像也是一搜一大把。（直接Google搜索，害怕百度粘上脏东西）。

装备 #

硬件：PC电脑系统：Window 10 内存：32G 硬盘：2T 虚拟机软件：VMware Workstation Pro Linux：Ubuntu 22-04.5

我会把用到的软件和镜像上传到Google Drive，省去大家自己找的功夫，不放心也可以去官方找，都是免费的。只有VMware下载稍麻烦些。

Linux用你习惯即可。

我编译的是AOSP 13 r44的版本，建议为虚拟机分配硬盘时分配400G硬盘空间，开始分配300G同步代码完成后磁盘满了，很尴尬。

编译环境 #

创建虚拟机相信聪明的你可以搞定。创建后开搞。

JDK #

1
2


# 安装jdk
sudo apt install openjdk-11-jdk

Python3 #

Ubuntu 自 16.04 版本已经默认预装 python3，repo同步时用的命令都是python

1
2


# 通过软链接将python命令默认指向python3
sudo ln -s /usr/bin/python3 /usr/bin/python

安装依赖工具和库 #

1

sudo apt-get install git-core gnupg flex bison build-essential zip curl zlib1g-dev libc6-dev-i386 libncurses5 lib32ncurses5-dev x11proto-core-dev libx11-dev lib32z1-dev libgl1-mesa-dev libxml2-utils xsltproc unzip fontconfig

配置git信息 #

1
2
3
4


# 配置Git的用户名
git config --global user.name "Your Name"
# 配置邮箱
git config --global user.email you@example.com

安装Repo #

Repo 是 Google 专门用来管理 Android 大型源码库的一个工具，比如 AOSP 项目。简单说就是一个封装了 Git 命令的 python 脚本，用以简化跨多个 Git 仓库的代码管理和同步。通过 Repo，你可以在一个命令行中对所有仓库进行同步、检出特定的分支、以及执行其他 Git 操作。

1
2
3
4
5


# 安装repo
sudo apt install repo

# 查看repo版本(是否安装成功)
repo version

编译 #

创建AOSP文件夹 #

通过repo拉取。先创建一个文件夹。

以我的情况为例，我希望把文件夹命名清楚，以免过段时间字再想看时忘了是哪个版本了。

1
2
3
4
5


# 创建文件夹
mkdir AOSP_13_r44

# 进入AOSP_13_r44
cd AOSP_13_r44

初始化repo #

1
2
3
4
5


# 从Google下载Android13源码
repo init -u https://android.googlesource.com/platform/manifest -b android-13.0.0_r44

# 从镜像站下载android-13.0.0_r44源码
repo init -u https://mirrors.tuna.tsinghua.edu.cn/git/AOSP/platform/manifest -b android-13.0.0_r44

虽然VPN是程序员必备的工具，但不一定有那么多流量，有那么多流量也不一定速度快，速度快也不一定稳定，建议从镜像站下载。

我用的清华的源（和上面相同），你也可以用中科大的，可以看下高爷的文章

这里说的是后面同步代码的，repo初始化时你需要打开VPN，让repo顺利完成初始化工作。

拉取代码 #

拉取时我劝你关掉VPN，流量直接走直连是最稳定的。开始时我设置路由器上的openclash模式为TUN，总是TLS握手失败，重试了好多次都还是不行。直连从来没有失败过。

1
2
3
4
5


# 默认命令
repo sync

# 只拉取当前分支
repo sync -c

只拉取当前分支会快一些，核心的代码改动很小，拉一个分支就足够了。

命令解释： -c current branch –no-tags 不拉取tags（默认） -j 并行job数量，默认是0，根据CPU核心线程决定

更多命令敲repo sync --h查看。

同步开始后是漫长的等待直到提示repo sync has finished successfully.就算完成了。

开始编译 #

初始化环境 #

1
2


# 执行该命令，envsetup.sh 脚本初始化环境
source build/envsetup.sh

此脚本会导入若干命令（包括本页中使用的命令），让您能够使用 Android 源代码。如果虚拟机关机了，需要重新执行一次。

选择构建目标 #

使用 lunch 命令选择要构建的目标

1
2


# 默认，从后续列表中选择构建目标，
lunch

你也可以选择你要构建的目标，直接输入。比如：

1

lunch aosp_cf_x86_64_phone-trunk_staging-userdebug

构建目标中的每个字段代表什么含义推荐参考官方文档，内容很全面。

构建代码 #

选择好构建的目标之后，开始执行。

1

m

您应看到的第一个输出是目标和构建环境的概要：

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


============================================
PLATFORM_VERSION_CODENAME=VanillaIceCream
PLATFORM_VERSION=VanillaIceCream
PRODUCT_INCLUDE_TAGS=com.android.mainline
TARGET_PRODUCT=aosp_arm
TARGET_BUILD_VARIANT=eng
TARGET_ARCH=arm
TARGET_ARCH_VARIANT=armv7-a-neon
TARGET_CPU_VARIANT=generic
HOST_OS=linux
HOST_OS_EXTRA=Linux-6.5.13-1rodete2-amd64-x86_64-Debian-GNU/Linux-rodete
HOST_CROSS_OS=windows
BUILD_ID=AOSP.MAIN
OUT_DIR=out
============================================

设置swap #

如果编译过程中没有问题，等待完成即可。我给虚拟机的内容是16G，中间失败了一次。

报错信息：

1

soong bootstrap failed with: exit status 1

搜索后是因为内容不够，swap又小。

 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


I found the following video very interesting and a straightforward approach to increase the size of swapfile. Checkout this short video tutorial: How to Increase Swap on Ubuntu Linux | Linux Handbook

(From this video) following is the way to increase the swap space (if your system is using swapfile):

First check the swap size of your linux system:

swapon --show
Sample output:

NAME TYPE SIZE USED PRIO
/swapfile file 797.2M 0B -2
This output shows the swap size is being used and the type of swap. Here the swap type is "file" type (it could be partition type as well).Ubuntu uses swapfile by default and increasing and decreasing the size of it is fairly easy.

As we are going to modify the swapfile so at first turn it OFF. You might notice the process is being killed for multiple times. This happens because before turning the swap OFF the system moves its contents to main memory which may overflow the main memory. So, if the following command is killed, run it multiple times until it is successfully completed. You may also face sudden logout and / or other processes may be killed automatically.:

sudo swapoff /swapfile
Now if you run swapon --show it won't show anything as it is turned OFF.

Now change the swap size (I am making it 4GB, for n GB make it nG):

sudo fallocate -l 4G /swapfile
Now if you check the file you will see the size is increased. To see it:

ls -lh /swapfile
Now tell the Linux system to use this file as swap system:

sudo mkswap /swapfile
This will wipe the old swap signature and use the new one.

Now to turn the swap ON (as we initially turned OFF the swap space):

sudo swapon /swapfile
Done!

Now use swapon --show or free -h to see the change.

来自How to increase swap space?

我分配的16G😂。

打开 #

不出意外等编译完成后，用Android Studio for platfom打开，打开时输入构建target和希望打开的模块，大部分代码都在framework里。

参考 #

Ubuntu 下编译 AOSP 源码

Android 系统开发系列（1）：Android 12 源代码下载、编译和刷机

How to increase swap space?

Mac制作Windows启动盘指南

Sat, 14 Dec 2024 04:51:03 +0800

周二早上想看硬件有哪些，记得Windows电脑上有个AIDE，费了一顿劲找着，点了电脑直接蓝屏了，再进发现UEFI干没了😅。刚好手头又没有pe启动盘，倒是有U盘和Mac电脑，记录下用Mac制作Windows启动盘的过程。

工具 #

你需要准备的工具： 0. 一台Windows电脑；

一个U盘，最小8G的都行；
一台Mac电脑；

下载ISO镜像文件 #

我建议去官网下载，主要有三个理由：

官方没有各种牛皮藓广告，不要求你一定要登录才能下载；
系统纯净，最干净的系统镜像，其他来源的不能保证；
下载速度快，好歹也是官方的。

链接： windows10：微软官网下载 windows11：微软官网下载

逐步选择你要下载的版本、语言、32位还是64位（近几年的电脑无脑选64就可以了）开始下载，过程中需要点击几次确认。

制作启动盘 #

格式化U盘 #

在Mac终端中输入diskutil list，显示接入的磁盘，U盘的位置在最后，根据容量大小和名称判断是哪一个。比如我的：

1
2
3
4
5


/dev/disk6 (external, physical):
 #: TYPE NAME SIZE IDENTIFIER
 0: GUID_partition_scheme *31.0 GB disk6
 1: Apple_HFS Blank 209.7 MB disk6s1
 2: Microsoft Basic Data THEONE 30.8 GB disk6s2

找到了U盘后，格式化U盘。

diskutil eraseDisk MS-DOS "$U盘名称" GPT $卷名

$U盘名称 -> 替换成你希望U盘格式化后的名称 $卷名 -> 替换成U盘对应的，我的就应该换成了/dev/disk6

挂载ISO文件 #

1

hdiutil mount $ISO文件

$ISO文件替换成你的ISO文件所在的路径包括最后的iso文件后缀。

有一个小技巧，你可以输入hdiutil mount 后把ISO文件拖拽到终端中由系统帮你输入路径。

完成后终端会输出ISO挂载的路径类似/Volumes/CCCOMA_X64FRE_ZH-CN_DV9

将ISO同步U盘 #

1

rsync -vha --exclude=sources/install.wim $ISO镜像文件挂载卷名/* /Volumes/$U盘名称

拆分文件 #

由于fat32单文件最大智能支持4G，ios超过了文件限制，使用wimlib拆分镜像

如果你安装了brew，推荐用brew安装：brew install wimlib

1
2


# 拆分install.wim文件
wimlib-imagex split $ISO挂载路径/sources/install.wim /Volumes/WIN11/sources/install.swm 4000

将$ISO挂载路径替换成你的。

❗重要 #

Window安装时只能有一个UEFI分区，上面的步骤会为U盘创建一个UEFI分区，安装时又不显示U盘的分区，一直提示错误安装不上。

解决： diskutil eraseVolume HFS+ $分区名称 $卷名

$分区名称 -> 随便输入一个英文的名称即可 $卷名 -> 可以通过diskutil list查看，替换为U盘中TYPE为UEFI格式的分区标识（最右侧一列）

这一步完成后准备工作就完成了，开始安装系统。

安装系统 #

Windows电脑按F1、F11或者DELETE键进入BIOS（启动方式参考主板说明说），启动方式将U盘设置最优先的。重启Window电脑，删除Windows电脑硬盘中的UEFI分区后，一路下一步安装系统。

参考 #

记一次mac制作win11引导盘并安装使用mac制作U盘启动盘并安装win10系统

理解Kotlin协程

Sun, 08 Dec 2024 12:38:47 +0800

记下自己的一点浅薄的理解，想要更深入学习的朋友推荐阅读霍老的破解 Kotlin 协程

使用 #

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


public fun CoroutineScope.launch(
 context: CoroutineContext = EmptyCoroutineContext,
 start: CoroutineStart = CoroutineStart.DEFAULT,
 block: suspend CoroutineScope.() -> Unit
): Job {
 val newContext = newCoroutineContext(context)
 val coroutine = if (start.isLazy)
 LazyStandaloneCoroutine(newContext, block) else
 StandaloneCoroutine(newContext, active = true)
 coroutine.start(start, coroutine, block)
 return coroutine
}

启动时包含三个参数：

协程上下文
启动模式
执行方法

协程上下文 #

CoroutineContext中定义了get、plus、minusKey方法。类似list。

CoroutineContext	List
get(Key)	get(Int)
plus(CoroutineContext)	plus(List)
minusKey(Key)	removeAt(Int)

官方的注释也表明，这是一个set的接口类。

1
2
3
4
5


/**
 * Persistent context for the coroutine. It is an indexed set of [Element] instances.
 * An indexed set is a mix between a set and a map.
 * Every element in this set has a unique [Key].
 */

不用在意礼CoroutineContext类中是否有存储链表组或是其他存储数据的结构，这就是一个set（开始是写数组，纠正一下），怎么存储蛮可以交给子类实现。

key

1

public interface Key<E : Element>

element

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


public interface Element : CoroutineContext {
 /**
 * A key of this coroutine context element.
 */
 public val key: Key<*>

 public override operator fun <E : Element> get(key: Key<E>): E? =
 @Suppress("UNCHECKED_CAST")
 if (this.key == key) this as E else null

 public override fun <R> fold(initial: R, operation: (R, Element) -> R): R =
 operation(initial, this)

 public override fun minusKey(key: Key<*>): CoroutineContext =
 if (this.key == key) EmptyCoroutineContext else this
 }

默认情况在，CoroutineContext用的是EmptyCoroutineContext。几个协程上下文想加，实际上用的就是CombinedContext了。

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


‍‍```c#
internal class CombinedContext(
 private val left: CoroutineContext,
 private val element: Element
) : CoroutineContext, Serializable {

 override fun <E : Element> get(key: Key<E>): E? {
 var cur = this
 while (true) {
 cur.element[key]?.let { return it }
 val next = cur.left
 if (next is CombinedContext) {
 cur = next
 } else {
 return next[key]
 }
 }
 }

	// 省略其他代码
}
‍‍```

可以在CombinedContext中看到，内部是类似链表的结构，一个是当前节点存储的值（Element），另一个是指向下一个节点的指针（left）。

到这里CoroutineContext的结构也就清晰了。响应的，EmptyCoroutineContext中都是空的。

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


@SinceKotlin("1.3")
public object EmptyCoroutineContext : CoroutineContext, Serializable {
 private const val serialVersionUID: Long = 0
 private fun readResolve(): Any = EmptyCoroutineContext

 public override fun <E : Element> get(key: Key<E>): E? = null
 public override fun <R> fold(initial: R, operation: (R, Element) -> R): R = initial
 public override fun plus(context: CoroutineContext): CoroutineContext = context
 public override fun minusKey(key: Key<*>): CoroutineContext = this
 public override fun hashCode(): Int = 0
 public override fun toString(): String = "EmptyCoroutineContext"
}

一个CoroutineContext+另一个CoroutineContext的写法很常见，实际上是CoroutineContext中定义了operator fun plus方法，可以用+调用。翻开源码可以注意到组合时总是要先把ContinuationInterceptor放到链表（CombinedContext）最前面的位置以保证最先执行。

因为CombinedContext的结构是类似3<-2<-1的，因此最先被拿到的是实际上是末尾的1这个元素。

CoroutineStart #

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


/**
 * Defines start options for coroutines builders.
 *
 * It is used in the `start` parameter of coroutine builder functions like
 * [launch][CoroutineScope.launch] and [async][CoroutineScope.async]
 * to describe when and how the coroutine should be dispatched initially.
 *
 * This parameter only affects how the coroutine behaves until the code of its body starts executing.
 * After that, cancellability and dispatching are defined by the behavior of the invoked suspending functions.
 *
 * The summary of coroutine start options is:
 * - [DEFAULT] immediately schedules the coroutine for execution according to its context.
 * - [LAZY] delays the moment of the initial dispatch until the result of the coroutine is needed.
 * - [ATOMIC] prevents the coroutine from being cancelled before it starts, ensuring that its code will start
 * executing in any case.
 * - [UNDISPATCHED] immediately executes the coroutine until its first suspension point _in the current thread_.
 */

决定以哪种策略执行任务。

DEFAULT：默认，立即安排执行。如果执行前被取消，将不会被执行。

LAZY：需要的时机执行。调用Job.join或是start。如果执行前被取消，将不会被执行。

ATOMIC：与默认类似，如果执行前被取消，会继续执行。

UNDISPATCHED：立即执行，直到第一个挂起点。

详细策略说明参见代码注释。路径：kotlinx.coroutines.CoroutineStart

拦截器 #

拦截器是什么东西呢？

归根到底也是CoroutineContext的一个子类，在他的基础上额外实现了ContinuationInterceptor接口中interceptContinuation方法。Kotlin中现成的拦截器可以一直顺到Dispatchers的Default、Main、Unconfined、IO上，

除了上面几个常用的，你也可以自己定义拦截器。

以Dispatchers.Main为例，最后创建的是一个HandlerContext，Android开发的朋友看这个名字就猜到了，没错，就是Handler。

1
2
3
4
5


override fun dispatch(context: CoroutineContext, block: Runnable) {
 if (!handler.post(block)) {
 cancelOnRejection(context, block)
 }
 }

再回到launch时，根据CoroutineStart的策略，创建好Continuation，开始执行拦截逻辑。

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


// kotlinx.coroutines.intrinsics.Cancelable.kt

/**
 * Use this function to start coroutine in a cancellable way, so that it can be cancelled
 * while waiting to be dispatched.
 */
@InternalCoroutinesApi
public fun <T> (suspend () -> T).startCoroutineCancellable(completion: Continuation<T>): Unit = runSafely(completion) {
 createCoroutineUnintercepted(completion).intercepted().resumeCancellableWith(Result.success(Unit))
}


// kotlin.coroutines.jvm.internal.ContinuationImpl.kt

public fun intercepted(): Continuation<Any?> =
 intercepted
 ?: (context[ContinuationInterceptor]?.interceptContinuation(this) ?: this)
 .also { intercepted = it }

这是是Dispatchers.Main的，中间绕了几弯，最终会执行到HandlerContext（基类是HandlerDispatcher）。

1
2
3
4
5


override fun dispatch(context: CoroutineContext, block: Runnable) {
 if (!handler.post(block)) {
 cancelOnRejection(context, block)
 }
}

都已经Handler了，还有啥好说的🤷‍♂️。

这是Dispatcher.Main可以切换线程的原因。

Continuation #

Continuation又是什么呢？

the fact of continuing or a thing that continues or follows from something else 繼續;持續;延續;繼續發生（或進行）之事;某事的後續結果（或影響）

Cambridge Dictionary

按照CoroutineStart为Default找了半天，其实是封装了执行的一个类。

 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


/**
 * Creates unintercepted coroutine without receiver and with result type [T].
 * This function creates a new, fresh instance of suspendable computation every time it is invoked.
 *
 * To start executing the created coroutine, invoke `resume(Unit)` on the returned [Continuation] instance.
 * The [completion] continuation is invoked when coroutine completes with result or exception.
 *
 * This function returns unintercepted continuation.
 * Invocation of `resume(Unit)` starts coroutine immediately in the invoker's call stack without going through the
 * [ContinuationInterceptor] that might be present in the completion's [CoroutineContext].
 * It is the invoker's responsibility to ensure that a proper invocation context is established.
 * Note that [completion] of this function may get invoked in an arbitrary context.
 *
 * [Continuation.intercepted] can be used to acquire the intercepted continuation.
 * Invocation of `resume(Unit)` on intercepted continuation guarantees that execution of
 * both the coroutine and [completion] happens in the invocation context established by
 * [ContinuationInterceptor].
 *
 * Repeated invocation of any resume function on the resulting continuation corrupts the
 * state machine of the coroutine and may result in arbitrary behaviour or exception.
 */
@SinceKotlin("1.3")
public actual fun <T> (suspend () -> T).createCoroutineUnintercepted(
 completion: Continuation<T>
): Continuation<Unit> {
 val probeCompletion = probeCoroutineCreated(completion)
 return if (this is BaseContinuationImpl)
 create(probeCompletion)
 else
 createCoroutineFromSuspendFunction(probeCompletion) {
 (this as Function1<Continuation<T>, Any?>).invoke(it)
 }
}

执行过程中传递的都是Continuation对象。

async执行的流程大致相似，返回值是从await返回的，而不是launch方法。

协程Scope #

CoroutineScope是一个提供了协程上下文的接口。

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


// CoroutineScope.kt

//CoroutineScope
public interface CoroutineScope {
 public val coroutineContext: CoroutineContext
}

// MainScope
public fun MainScope(): CoroutineScope = ContextScope(SupervisorJob() + Dispatchers.Main)
// ContextScope
internal class ContextScope(context: CoroutineContext) : CoroutineScope {
 override val coroutineContext: CoroutineContext = context
 // CoroutineScope is used intentionally for user-friendly representation
 override fun toString(): String = "CoroutineScope(coroutineContext=$coroutineContext)"
}

// GlobalScope
public object GlobalScope : CoroutineScope {
 /**
 * Returns [EmptyCoroutineContext].
 */
 override val coroutineContext: CoroutineContext
 get() = EmptyCoroutineContext
}

LifecycleScope也没忘，LifecycleScope实际的实现类是LifecycleCoroutineScopeImpl。再原基础上增加Lifecycle以实现监听声明周期变化。

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


internal class LifecycleCoroutineScopeImpl(
 override val lifecycle: Lifecycle,
 override val coroutineContext: CoroutineContext
) : LifecycleCoroutineScope(), LifecycleEventObserver{
 ...
 fun register() {
 launch(Dispatchers.Main.immediate) {
 if (lifecycle.currentState >= Lifecycle.State.INITIALIZED) {
 lifecycle.addObserver(this@LifecycleCoroutineScopeImpl)
 } else {
 coroutineContext.cancel()
 }
 }
 }

 override fun onStateChanged(source: LifecycleOwner, event: Lifecycle.Event) {
 if (lifecycle.currentState <= Lifecycle.State.DESTROYED) {
 lifecycle.removeObserver(this)
 coroutineContext.cancel()
 }
 }
}

参考 #

破解 Kotlin 协程（3）：协程调度篇

FreshRSS API使用指南

Thu, 05 Dec 2024 07:53:41 +0800

不喜欢新闻客户端里带有政治倾向和无关紧要的娱乐新闻，诸如某某明星跌倒之类。日常都用rss阅读，可以阅读我常看的内容，FreshRSS又是可以自己部署的非常好用的服务，理所当然的用上了。

最近组了一台主机，重新安装FreshRSS之后总是也在reeder（iOS平台RSS阅读软件）上配置不了，记录一下。

Docker一种容器化技术，每一个容器都有一个端口，要通过ip:port的形式访问，互相之间是隔离的，当然也是有通讯的方式的。

拿我的情况举例，我的ip是：192.168.1.10，端口是80，访问FreshRSS的地址就是192.168.1.10:80，更严谨的应该是加上http://192.168.1.10:80。

FreshRSS也很贴心，设置-账户-API管理下有个url，点击进去会提示你访问api的url是多少。像是这样的：

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


FreshRSS API endpoints
Google Reader compatible API
Your API address:
http://192.168.1.10/api/greader.php
Google Reader API configuration test:
⚠️ WARN: Probable invalid base URL in ./data/config.php
Fever compatible API
Your API address:
http://192.168.1.10/api/fever.php
Fever API configuration test:
⚠️ WARN: Probable invalid base URL in ./data/config.php
HowjsayDictionary.comCambridge DictionaryYouglish

但其实不是这样的。拿我的情况举例，我的ip是：192.168.1.10，端口是80，那么我的api地址就是http://192.168.1.10/api/greader.php。其实我在Docker中部署的，通过这个url是找不到的，实际的应该是http://192.168.1.10:80/api/greader.php。

需要注意的是你需要把ip和端口改成你已经部署的FreshRSS的，而不是照抄我的。

另外，登录时的账号与你登录FreshRSS是相同的，但是密码不是，密码你需要在FreshRSS的设置-账户-API管理下单独设置才可以。

Jetpack ViewModel实现原理

Sat, 23 Nov 2024 09:08:41 +0800

ViewModel和架构MVVM中的VM（ViewModel）同名，但并不是一个东西，架构中的ViewModel是和View双向绑定的，这里的ViewModel只能做到利用LiveData更新。

为什么用ViewModel呢？一是把网络请求和数据库读取的逻辑从Activity中放到了ViweModel，分担了一部分Activity的压力；另一个原因是可以在Activity或Fragment重建时保存数据，不会丢失。今天探讨的时第二个问题。

用法 #

一般的创建写法是val viewModel :MyViewModel by viewModels()这样，或者直接的写法应该是val viewModel: MyViewModel = ViewModelProvider(viewModelStore,defaultViewModelProviderFactory).get(MyViewModel::class.java)这样才对。

viewModels()需要添加了activity-ktx的依赖，顺着代码往下翻实际上也是用了第二种，不同的是被Lazy包了一下。

ViewModelProvider的构造方法需要三个参数分别是ViewModelStore，Factory和CreationExtras。

ViewModelStore中有mutableMapOf<String, ViewModel>()类型的属性，实际作用也是以kv的形式存放ViewModel。

Factory更直接，一个工厂模式，决定怎么创建ViewModel类。

CreationExtras中又是一个map：

1

internal val map: MutableMap<Key<*>, Any?> = mutableMapOf()

保存额外的参数。

原理 #

保证ViewModel不被重建的奥秘藏在get方法中：

 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


 /**
 * Returns an existing ViewModel or creates a new one in the scope (usually, a fragment or
 * an activity), associated with this `ViewModelProvider`.
 *
 *
 * The created ViewModel is associated with the given scope and will be retained
 * as long as the scope is alive (e.g. if it is an activity, until it is
 * finished or process is killed).
 *
 * @param modelClass The class of the ViewModel to create an instance of it if it is not
 * present.
 * @return A ViewModel that is an instance of the given type `T`.
 * @throws IllegalArgumentException if the given [modelClass] is local or anonymous class.
 */
 @MainThread
 public open operator fun <T : ViewModel> get(modelClass: Class<T>): T {
 val canonicalName = modelClass.canonicalName
 ?: throw IllegalArgumentException("Local and anonymous classes can not be ViewModels")
 return get("$DEFAULT_KEY:$canonicalName", modelClass)
 }

 /**
 * Returns an existing ViewModel or creates a new one in the scope (usually, a fragment or
 * an activity), associated with this `ViewModelProvider`.
 *
 * The created ViewModel is associated with the given scope and will be retained
 * as long as the scope is alive (e.g. if it is an activity, until it is
 * finished or process is killed).
 *
 * @param key The key to use to identify the ViewModel.
 * @param modelClass The class of the ViewModel to create an instance of it if it is not
 * present.
 * @return A ViewModel that is an instance of the given type `T`.
 */
 @Suppress("UNCHECKED_CAST")
 @MainThread
 public open operator fun <T : ViewModel> get(key: String, modelClass: Class<T>): T {
 val viewModel = store[key]
 if (modelClass.isInstance(viewModel)) {
 (factory as? OnRequeryFactory)?.onRequery(viewModel!!)
 return viewModel as T
 } else {
 @Suppress("ControlFlowWithEmptyBody")
 if (viewModel != null) {
 // TODO: log a warning.
 }
 }
 val extras = MutableCreationExtras(defaultCreationExtras)
 extras[VIEW_MODEL_KEY] = key
 // AGP has some desugaring issues associated with compileOnly dependencies so we need to
 // fall back to the other create method to keep from crashing.
 return try {
 factory.create(modelClass, extras)
 } catch (e: AbstractMethodError) {
 factory.create(modelClass)
 }.also { store.put(key, it) }
 }

get时先尝试从store中获取，store也就是刚刚说的ViewModelStore。拿不到时才会用Factory创建一个新的。

在ComponentActivity中取到的viewModelStore又是从一个NonConfigurationInstances类实例中拿到的，实例并不是Activity内部创建的，是在Activity#attach时传入并保存下来的（你不信我也没办法，赋值的代码只有attach有）。也就是说外部一定有对其赋值的代码。

恰好知道Activity#attach方法在ActivityThread中用到。顺藤摸瓜，又找到是在Activity销毁前保存下来的。接着往上摸，找到handleRelaunchActivity的头上，确定在需要重新launch的Activity中才会传入NonConfigurationInstances，performLaunchActivity时传入null。

知道了从哪进来的，从哪出去的就好说了。Activity重建时，会用retainNonConfigurationInstances拿到，其中一部分保存的是Activity的状态，也就是activity字段中。

保存的activity名字叫activity，类型是Object的。实际的是NonConfigurationInstances，里面包含了viewModelStore。

总结 #

获取ViewModel时如果是Activity重建的场景，会在销毁前将ViewModelStore保存下来，并将ViewModelStore传给Activity，ViewModelStore保存了ViewModel实例。这样Activity重建后仍然有之前的ViewModel。

关于旅行的意义

Sun, 17 Nov 2024 12:15:14 +0800

我总是想弄清楚各种意义，仿佛没有意义的事物就不应该存在。时常看到有人分享各地的标志性建筑、食物或是服饰等等，单独拿出来分享的还是少数，更多的还是与某些东西合影的照片。即使去旅行的时间非常短，但一定会有那么两三个带标志性的，标志性物品和某个城市、某个地区、某种文化划上了等号。

对这些，我总是感到很厌恶，在我看来，这不是旅行。不过是走马观花，没有领略当地的风土人情，没有感受过这座城市中生活的人们特有的特性，也同样没有领略那里的文化，又怎么敢豪言去过那里呢。

我出去玩时也是会拍照片的，拍了未必会上传到哪个平台上，好让人家看到我去了哪里，这种上传更多的是炫耀，一种岁月静好的错觉，而不是看到了美希望与人分享。没有觉得拍照片是什么问题，我甚至为了拍照片买了相机，有问题的是到了哪里总是先掏出手机拍个不停，摆拍出一张张照片，大有不拍出像样的照片就不走的气势，亦或是匆匆拍下两三张照片千直奔下一个景点。

这大概是我不愿意与人一起出行的原因，一起去了总也要一起逛逛，一逛就到了热门景点，大到建筑，小到移动餐车，总是急匆匆的。人也多，却也挡不住大家的热情，排在长龙的队尾也不肯放弃。如果是我自己，完全可以放缓些，随意在街上走一走，累了饿了找家店，吃顿饭，吃饱喝足了再接着去哪里。

Jetpack Lifecycle组件解析

Sun, 17 Nov 2024 12:04:10 +0800

Android中又越来越多组件依赖Lifecycle，从来不好奇Lifecycle是什么东西，又是怎么起作用的吗？我很好奇。

LifecycleOwner #

通常的用法往往是从LifecyclerOwner中拿到Lifecycle对象，之后add Oberver或者remove Observer。

LifecycleOwner是一个接口，只有一个参数（说是方法更确切）：Lifecycle。单纯的为了拿到Lifecycle对象。

FragmentActivity和Fragment都继承自LifecycleOwner。内部又都持有一个LifecycleRegistry对象。

我在想为什么需要这么一个方法呢？如果没有这个方法会怎么呢？如果没有，每个持有Lifecycle的类中都需要保存Lifecycle，这是少不了的。获取就不一样了，怎么获取呢？每个类没有统一的方法啊。这么想LifecycleOwner就是统一的方法。对外只暴露拿到Lifecycle的方法。

Lifecycle #

LifecycleRegistry是Lifecycle对应的唯一实现，内部实现了记录Observer数量、添加、移除和改变状态的实际逻辑，不一一列举。

Lifecycle是个抽象类，方法有两个：addObserver和removeObserver。参数都是一个LifecycleObserver示例。也不太需要解释，就是添加和移除Observer。

此外还有一个State类型成员变量（可以理解成返回State类型的方法），保存当前的状态。

State #

 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


/**
 * Lifecycle states. You can consider the states as the nodes in a graph and
 * [Event]s as the edges between these nodes.
 */
public enum class State {
 /**
 * Destroyed state for a LifecycleOwner. After this event, this Lifecycle will not dispatch
 * any more events. For instance, for an [android.app.Activity], this state is reached
 * **right before** Activity's [onDestroy][android.app.Activity.onDestroy] call.
 */
 DESTROYED,

 /**
 * Initialized state for a LifecycleOwner. For an [android.app.Activity], this is
 * the state when it is constructed but has not received
 * [onCreate][android.app.Activity.onCreate] yet.
 */
 INITIALIZED,

 /**
 * Created state for a LifecycleOwner. For an [android.app.Activity], this state
 * is reached in two cases:
 *
 * * after [onCreate][android.app.Activity.onCreate] call;
 * * **right before** [onStop][android.app.Activity.onStop] call.
 *
 */
 CREATED,

 /**
 * Started state for a LifecycleOwner. For an [android.app.Activity], this state
 * is reached in two cases:
 *
 * * after [onStart][android.app.Activity.onStart] call;
 * * **right before** [onPause][android.app.Activity.onPause] call.
 *
 */
 STARTED,

 /**
 * Resumed state for a LifecycleOwner. For an [android.app.Activity], this state
 * is reached after [onResume][android.app.Activity.onResume] is called.
 */
 RESUMED;

 /**
 * Compares if this State is greater or equal to the given `state`.
 *
 * @param state State to compare with
 * @return true if this State is greater or equal to the given `state`
 */
 public fun isAtLeast(state: State): Boolean {
 return compareTo(state) >= 0
 }
}

LifecycleObserver #

LifecycleObserver是一个接口（废话），单纯的是一个接口。

1
2
3
4
5
6
7
8


/**
 * Marks a class as a LifecycleObserver. Don't use this interface directly. Instead implement either
 * [DefaultLifecycleObserver] or [LifecycleEventObserver] to be notified about
 * lifecycle events.
 *
 * @see Lifecycle Lifecycle - for samples and usage patterns.
 */
public interface LifecycleObserver

代码就是这么定义的。

对应的实现接口有两个：LifecycleEventObserver和DefaultLifecycleObserver。

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


/**
 * Class that can receive any lifecycle change and dispatch it to the receiver.
 *
 * If a class implements both this interface and
 * [androidx.lifecycle.DefaultLifecycleObserver], then
 * methods of `DefaultLifecycleObserver` will be called first, and then followed by the call
 * of [LifecycleEventObserver.onStateChanged]
 *
 * If a class implements this interface and in the same time uses [OnLifecycleEvent], then
 * annotations will be ignored.
 */
public fun interface LifecycleEventObserver : LifecycleObserver {
 /**
 * Called when a state transition event happens.
 *
 * @param source The source of the event
 * @param event The event
 */
 public fun onStateChanged(source: LifecycleOwner, event: Lifecycle.Event)
}

 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


public interface DefaultLifecycleObserver : LifecycleObserver {
 /**
 * Notifies that `ON_CREATE` event occurred.
 *
 *
 * This method will be called after the [LifecycleOwner]'s `onCreate`
 * method returns.
 *
 * @param owner the component, whose state was changed
 */
 public fun onCreate(owner: LifecycleOwner) {}

 /**
 * Notifies that `ON_START` event occurred.
 *
 *
 * This method will be called after the [LifecycleOwner]'s `onStart` method returns.
 *
 * @param owner the component, whose state was changed
 */
 public fun onStart(owner: LifecycleOwner) {}

 /**
 * Notifies that `ON_RESUME` event occurred.
 *
 *
 * This method will be called after the [LifecycleOwner]'s `onResume`
 * method returns.
 *
 * @param owner the component, whose state was changed
 */
 public fun onResume(owner: LifecycleOwner) {}

 /**
 * Notifies that `ON_PAUSE` event occurred.
 *
 *
 * This method will be called before the [LifecycleOwner]'s `onPause` method
 * is called.
 *
 * @param owner the component, whose state was changed
 */
 public fun onPause(owner: LifecycleOwner) {}

 /**
 * Notifies that `ON_STOP` event occurred.
 *
 *
 * This method will be called before the [LifecycleOwner]'s `onStop` method
 * is called.
 *
 * @param owner the component, whose state was changed
 */
 public fun onStop(owner: LifecycleOwner) {}

 /**
 * Notifies that `ON_DESTROY` event occurred.
 *
 *
 * This method will be called before the [LifecycleOwner]'s `onDestroy` method
 * is called.
 *
 * @param owner the component, whose state was changed
 */
 public fun onDestroy(owner: LifecycleOwner) {}
}

两者的差别在提供的颗粒度不一样，一个是把每一个状态都提供了方法；另一个则是只提供了变化的callback，至于怎么用完全不关心。

先后顺序 #

接口LifecycleEventObserver的注释中表明如果同时实现两个接口，会先调用DefaultLifecycleObserver中的方法，然后再调用LifecycleEventObserver的方法。

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


internal class DefaultLifecycleObserverAdapter(
 private val defaultLifecycleObserver: DefaultLifecycleObserver,
 private val lifecycleEventObserver: LifecycleEventObserver?
) : LifecycleEventObserver {
 override fun onStateChanged(source: LifecycleOwner, event: Lifecycle.Event) {
 when (event) {
 Lifecycle.Event.ON_CREATE -> defaultLifecycleObserver.onCreate(source)
 Lifecycle.Event.ON_START -> defaultLifecycleObserver.onStart(source)
 Lifecycle.Event.ON_RESUME -> defaultLifecycleObserver.onResume(source)
 Lifecycle.Event.ON_PAUSE -> defaultLifecycleObserver.onPause(source)
 Lifecycle.Event.ON_STOP -> defaultLifecycleObserver.onStop(source)
 Lifecycle.Event.ON_DESTROY -> defaultLifecycleObserver.onDestroy(source)
 Lifecycle.Event.ON_ANY ->
 throw IllegalArgumentException("ON_ANY must not been send by anybody")
 }
 lifecycleEventObserver?.onStateChanged(source, event)
 }
}

规则和顺序很清晰，又是怎么从Observer到DefaultLifecycleObserverAdapter的呢？

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


// Lifecycling.kt
public fun lifecycleEventObserver(`object`: Any): LifecycleEventObserver {
 val isLifecycleEventObserver = `object` is LifecycleEventObserver
 val isDefaultLifecycleObserver = `object` is DefaultLifecycleObserver
 if (isLifecycleEventObserver && isDefaultLifecycleObserver) {
 return DefaultLifecycleObserverAdapter(
 `object` as DefaultLifecycleObserver,
 `object` as LifecycleEventObserver
 )
 }
 ...

方法lifecycleEventObserver会在LifecycleRegistry添加Observer时被调用，所有的也都串起来了。

总结 #

注：实线表示持有，虚线表示继承

Jetpack LiveData解析

Sun, 10 Nov 2024 08:54:33 +0800

Jetpack中最不陌生的大概就是LiveData了，LiveData的两个特点：和lifecycleOwner绑定且监听数据变化。用过的哪个不说好？

流程 #

常用的LiveData的形式大概是这样的：

1
2
3
4
5
6
7
8


val mutableLiveData = MutableLiveData<String>()
mutableLiveData.observe(this){
 // ...
}

// 更新值
mutableLiveData.postValue(...)
mutableLiveData.setValue(...)

今天写的是LiveData怎么上来就是MutableLiveData呢？

MutableLiveData是LiveData子类，LiveData还是抽象类，拿来就能用的就是MutableLiveData了。

监听时有两个方法，分别是public void observe(@NonNull LifecycleOwner owner, @NonNull Observer<? super T> observer)和public void observeForever(@NonNull Observer<? super T> observer)

observe传入的LifecycleOwner参数用作监听生命周期变化，LifecycleOwner被销毁前移出观察者。不会因此造成npe问题。 observeForever则不在意谁是否被销毁，只要有会通知。

虽然两个方法传入的Observer是一样的类型，但在执行添加观察者时，又封装了一层，添加了版本、活跃状态及方法。observe方法添加的是LifecycleBoundObserver类型对象，observeForever添加的则是AlwaysActiveObserver类型对象，两者的基类是ObserverWrapper。

更新值从调用setValue或是postValue方法开始，postValue用于子线程中执行，通用handler的方式使得更新值的操作在主线程中执行，实际执行的还是setValue。

直接看setValue吧。setValue之后，LiveData内部做了三步，分别是：

判断主线程
更新version
保存更新后的值
通知observer

先看通知observer，方法中可以传入一个可选的ObserverWrapper类型参数，对应上面的基类，如果传入了，只分发给这一个观察者，否则分发给所有的观察者。

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


 void dispatchingValue(@Nullable ObserverWrapper initiator) {
 if (mDispatchingValue) {
 mDispatchInvalidated = true;
 return;
 }
 mDispatchingValue = true;
 do {
 mDispatchInvalidated = false;
 if (initiator != null) {
 considerNotify(initiator);
 initiator = null;
 } else {
 for (Iterator<Map.Entry<Observer<? super T>, ObserverWrapper>> iterator =
 mObservers.iteratorWithAdditions(); iterator.hasNext(); ) {
 considerNotify(iterator.next().getValue());
 if (mDispatchInvalidated) {
 break;
 }
 }
 }
 } while (mDispatchInvalidated);
 mDispatchingValue = false;
 }

重点的是决定观察者是否执行的方法：considerNotify。

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


private void considerNotify(ObserverWrapper observer) {
 if (!observer.mActive) {
 return;
 }
 // Check latest state b4 dispatch. Maybe it changed state but we didn't get the event yet.
 //
 // we still first check observer.active to keep it as the entrance for events. So even if
 // the observer moved to an active state, if we've not received that event, we better not
 // notify for a more predictable notification order.
 if (!observer.shouldBeActive()) {
 observer.activeStateChanged(false);
 return;
 }
 if (observer.mLastVersion >= mVersion) {
 return;
 }
 observer.mLastVersion = mVersion;
 observer.mObserver.onChanged((T) mData);
 }

有几个值得关注的点：

mActive
mVersion

只有状态是active时才该ObserverWrapper对象才可以通知观察者值变化了，状态的更新和获取都是和ObserverWrapper具体的实现类有关的，是哪一种类型又取决于通过哪种方式添加的观察者。

mVersion的值也需要是最新的，都很合理。

这大概就是LiveData中最主要的方法和相关流程，不知道你是否对主线程、mActive和mVersion有疑问，我是有的，为什么需要这些呢？分别来假设一下这些值没有会怎么样。

mActive #

mActive起了什么作用？需要保证观察者处于活跃状态才能接收到值的变化。如果所有观察者总是活跃状态会有什么问题吗？我相信是没有的，LifecyclerOwner总能保证按时移出。

mVersion #

mVersion又起了什么作用呢？mVersion变化来源是从setValue开始的，每更新一次value值，version就会更新一次。当观察者满足条件执行了，观察者内部的版本就会更新到最新。这样就可以理解成观察者活跃时总要保持最新的状态。

如果没有mVersion会发生什么呢？只要值变化就更新，即使是因为时序问题传过来一个过时的值。那这个值就是不能缺少的。

主线程 #

为什么所有的更新需要在主线程呢？不在主线程行不行？我相信也是可以的。大不了赋值时加锁，需要更新ui时谁需要谁切换好了。

数据倒灌？？？ #

问题的原因是在添加观察者时，会把最新的状态一并传过去，这时候观察者就要更新到最新的状态。网上的博客中有很多解决方式，今天不谈解决。

有没有可能Google就是这么设计的呢？如果时这么设计的，意图就是为了保证最新的状态，那么主线程执行是不是也能说的通了，版本、活跃状态是不是也能说的通了？

所以它就是不是一个问题，Google设想的场景就不是通知状态变化的，而是保证所有的观察者保持最新的状态。

组成 #

MutableLiveData的代码没有额外的实现：

 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 MutableLiveData<T> extends LiveData<T> {

 /**
 * Creates a MutableLiveData initialized with the given {@code value}.
 *
 * @param value initial value
 */
 public MutableLiveData(T value) {
 super(value);
 }

 /**
 * Creates a MutableLiveData with no value assigned to it.
 */
 public MutableLiveData() {
 super();
 }

 @Override
 public void postValue(T value) {
 super.postValue(value);
 }

 @Override
 public void setValue(T value) {
 super.setValue(value);
 }
}

LiveData的实现除了MutableLiveData还有个MediatorLiveData，是MutableLiveData的子类。根据官方注释中的解释，作用是用来协调多个LiveData，

 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


/**
 * {@link LiveData} subclass which may observe other {@code LiveData} objects and react on
 * {@code OnChanged} events from them.
 * <p>
 * This class correctly propagates its active/inactive states down to source {@code LiveData}
 * objects.
 * <p>
 * Consider the following scenario: we have 2 instances of {@code LiveData}, let's name them
 * {@code liveData1} and {@code liveData2}, and we want to merge their emissions in one object:
 * {@code liveDataMerger}. Then, {@code liveData1} and {@code liveData2} will become sources for
 * the {@code MediatorLiveData liveDataMerger} and every time {@code onChanged} callback
 * is called for either of them, we set a new value in {@code liveDataMerger}.
 *
 * <pre>
 * LiveData&lt;Integer&gt; liveData1 = ...;
 * LiveData&lt;Integer&gt; liveData2 = ...;
 *
 * MediatorLiveData&lt;Integer&gt; liveDataMerger = new MediatorLiveData&lt;&gt;();
 * liveDataMerger.addSource(liveData1, value -&gt; liveDataMerger.setValue(value));
 * liveDataMerger.addSource(liveData2, value -&gt; liveDataMerger.setValue(value));
 * </pre>
 * <p>
 * Let's consider that we only want 10 values emitted by {@code liveData1}, to be
 * merged in the {@code liveDataMerger}. Then, after 10 values, we can stop listening to {@code
 * liveData1} and remove it as a source.
 * <pre>
 * liveDataMerger.addSource(liveData1, new Observer&lt;Integer&gt;() {
 * private int count = 1;
 *
 * {@literal @}Override public void onChanged(@Nullable Integer s) {
 * count++;
 * liveDataMerger.setValue(s);
 * if (count &gt; 10) {
 * liveDataMerger.removeSource(liveData1);
 * }
 * }
 * });
 * </pre>
 *
 * @param <T> The type of data hold by this instance
 */

LiveData的独生子是MutableLiveData，MutableLiveData的独生子是MediatorLiveData。两代单传！

理解Android屏幕适配和最小宽度

Wed, 06 Nov 2024 08:05:07 +0800

凡事总要问为什么。为什么需要屏幕适配？众所周知，Android是一个较开发的系统，允许各家厂商定制修改AOSP，选用不同规格的硬件，包括CPU、内存、电池、传感器等等等等。当然屏幕也在其中。也因此，大家手上的手机屏幕大不相同，体现在屏幕的尺寸、分辨率上。

屏幕尺寸 #

屏幕尺寸是指从屏幕左上角到右下角这条对角线的距离，单位是英寸（inch）。

px #

如果你对图像有了解，px（pixel）是图像的基本单位，当一张图片放大到不能再放大之后，图像中最小的一个色块就是px。一个像素只能显示一个颜色，许许多多像素放在一起，从宏观上看就是有变化的图片。

值得注意：px不具有固定的大小，只是一个显示的最小单位。

分辨率 #

前面说px是图像的最小单位，手机屏幕图像的最小单位当然也是px，屏幕上有多少个px呢？这就是分辨率。通常用横竖有多少个px表述分辨率，比如：

640x480
1920x1080（1080P）
2048x1152（2k）
4096x2160（4k）

在上面的图片中也就是纵向有1920px，横向有1080px，共1920x1080个。

分辨率多对屏幕适配有什么影响呢？试想一下：有两个设备，一个设备A屏幕的分辨率是1280x720，而另一个设备B屏幕是1920x1080。假设我想写一个View，宽度占屏幕宽度的一半（短的一个边），都用px写布局时，一个是360px，另一个是540px，我需要写两套布局。

dp #

dp（Density-Independent Pixels）中文像素无关密度，表示一英寸的屏幕上有多少个像素，把分辨率和物理屏幕大小联系起来，类似其他的密度，不过是把计算密度的方式换成屏幕的。与px的计算方式：px = dp * (dpi / 160)。

dpi和160又是什么东西呢？dpi是像素密度，计算方式为：

图片中的ppi为：

ppi和dpi是两个不同的概念，暂且理解成是一样的。

而160是基准的像素密度。

为什么是160看到说法没找到官方文档，如果你看到了烦请分享出来

就相当于，认为160的密度是标准的，比这个值大的，就表示一英寸这个单位上像素数量要多。屏幕尺寸相同的情况下，这个屏幕就有更高的分辨率，要容纳下这些像素，肯定是要要在一英寸上放下更多的像素了。

dpi / 160就表示要容纳多少倍的像素，再*dp就表示一英寸上实际有多少px。

用dp写布局就能解决在设备A和设备B上适配的一部分问题。在设备A的dpi是设备B的dpi 1.5倍时，两个设备换算出宽度的dp值是相同的，这时用dp就能用一套布局在两个不同设备上有相同的显示效果。

你可能发现了规律，设备A是设备B的屏幕尺寸、宽、高都缩放1.5的结果。如果不都是成比例的呢？

最小宽度（sw） #

最小宽度方案是使用最多的方案。

系统会根据当前设备屏幕的最小宽度来匹配 values-swdp，用最小宽度是因为最小宽度不会随着旋转屏幕变化。

以一个最小宽度作为基准，比如最小宽度基准是360dp，把屏幕分成360份。最小宽度是400dp时，把400分成360份，那么每一份是基准的1.11倍，sw400的dimen值就是sw360对应的1.11倍。在sw360中的1dp在sw400中要用1.11dp。

关于最小宽度更详细参见骚年你的屏幕适配方式该升级了!-smallestWidth 限定符适配方案

补充 #

官方匹配规则 #

官方匹配规则是将多个配置限定符按照优先级先后拼接在一起，从前往后匹配，是可以向下兼容的，但是只要遇到一个不兼容的配置限定符就会回退。

举个例子，现在项目中有两个layout文件夹，分别是layout-sw540-v31和layout-sw600-v33，设备的版本是32，分辨率是1920x1080，dpi是320，最小的宽度是1080px，计算出sw对应的dp是540。按照优先级sw比版本要高，优先匹配sw540，32和31、33都不同，但是刚刚说过是可以向下兼容的，因此可以命中layout-sw540-v31。

sw计算 #

官方文档：

应用可用屏幕区域的最短尺寸。具体而言，应用窗口的 smallestWidth 是窗口可用高度和宽度的最小尺寸。您也可将其视为窗口的“最小可能宽度”。您可使用此限定符，让应用界面的可用宽度至少为 dp。

sw的单位是dp，二分辨率的单位是px，所以需要转换为dp。还用刚刚例子中的设备，最小的宽度是1080培px，假设dpi是320，计算dp的公式是px = dp * (dpi / 160)，那么计算dp的公式就是dp=px / (dpi / 160)，1080/(320/160)，sw的结果就是540。

插件仓库 #

Github仓库按照上面最小宽度计算规则，帮我们为不同的屏幕密度生成对应的dimens文件夹，

参考 #

Material Design吸顶效果实现

Tue, 05 Nov 2024 21:05:30 +0800

前言 #

Material Design是Google在2014年的I/O大会上发布的一种设计规范，包括布局、颜色、形状、声音、动效等。面向的是Android、iOS、Web和Flutter。对自己的Android，Google还推出了一系列组件、主题帮助开发者快速、方便的实现Material Design的效果。下面是几个能用在大部分实际项目中的控件：

AppBarLayout #

最近我们的项目首页UI改版，目前的布局大致如下图。打开首页时是显示tab的,向上滑动RecyclerView时超过了一定距离(比如TabLayout高度的50%)就隐藏TabLayout，下滑时超过了这距离时再显示TabLayout。

搜索时，发现有人用CoordinatorLayout+AppBarLayout实现的把ToolBar隐藏的效果。于是把我们项目中的TabLayout用AppBarLayout给包起来。达到了与期望的效果差不多的。

下面是简化了的布局。为了写起来方便用了RecyclerView，实际项目中用的则是Viewpager，除了页面左右滑动外其余都是相同的的。

布局代码如下：

 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


<?xml version="1.0" encoding="utf-8"?>
<androidx.coordinatorlayout.widget.CoordinatorLayout xmlns:android="http://schemas.android.com/apk/res/android"
 xmlns:app="http://schemas.android.com/apk/res-auto"
 xmlns:tools="http://schemas.android.com/tools"
 android:layout_width="match_parent"
 android:layout_height="match_parent"
 tools:context=".appbar.activity.OtherActivity">

 <com.google.android.material.appbar.AppBarLayout
 android:layout_width="match_parent"
 android:layout_height="wrap_content">

 <com.google.android.material.tabs.TabLayout
 android:layout_width="match_parent"
 android:layout_height="match_parent"
 android:background="@color/teal_200"
 app:layout_scrollFlags="scroll|enterAlways|snap|snapMargins">

 <com.google.android.material.tabs.TabItem
 android:layout_width="wrap_content"
 android:layout_height="wrap_content"
 android:text="Monday"/>

 <com.google.android.material.tabs.TabItem
 android:layout_width="wrap_content"
 android:layout_height="wrap_content"
 android:text="Tuesday"/>

 <com.google.android.material.tabs.TabItem
 android:layout_width="wrap_content"
 android:layout_height="wrap_content"
 android:text="Wednesday"/>
 </com.google.android.material.tabs.TabLayout>
 </com.google.android.material.appbar.AppBarLayout>

 <androidx.recyclerview.widget.RecyclerView
 android:id="@+id/content_rv"
 android:layout_width="match_parent"
 android:layout_height="match_parent"
 app:layout_behavior="@string/appbar_scrolling_view_behavior"/>

</androidx.coordinatorlayout.widget.CoordinatorLayout>

布局文件中最外层需要使用CoordinatorLayout，其他的就是TabLayout和一个RecyclerView。其中重要的是layout_scrollFlags和layout_behavior。

layout_behavior的作用是在有layout_behavior的CoordinatorLayout子View(NestedScrollView 、RecyclerView等)滚动时可以根据layout_scrollFlags改变AppBarLayout的行为。

layout_behavior是官方定义的，用appbar_scrolling_view_behavior。layout_scrollFlags可以根据我们需要的效果选择。

layout_scrollFlags #

在官方文档中，layout_scrollFlags的取值可以有以下七种：

noScroll #

不受RecyclerView或*NestedScrollView的滑动影响。*

scroll #

AppBarLayout在RecyclerView的第一个item或*NestedScrollView上方随着其滑动。类似插入到*RecyclerView第0个位置上。

exitUntilCollapsed #

需要与scroll一起使用，且可以设置minHeight。当向上滑动时顶部会有minHeight高度的TabLayout一直在顶部；向下滑动不会有变化，直到第0个位置的item完全显示。这时再向下滑动会逐渐恢复TabLayout原来的高度。

minHeight可以设置0dp，这时与只设置scroll无异。

enterAlways #

需要与scroll一起使用。在任何位置，向下滑动会隐藏TabLayout，向上滑动会显示TabLayout。且可以停留在TabLayout任意高度。

enterAlwaysCollapsed #

需要与scroll、enterAlways一起使用，且可以设置minHeight。向下滑动时与enterAlways相同。当向下滑动时会有minHeight高度的TabLayout一直在顶部，直到第0个位置的item完全显示。这时再向下滑动会逐渐恢复TabLayout原来的高度。

snap #

需要与scroll一起使用。与只是用scroll不同的只在TabLayout的显示和隐藏上，无论显示还隐藏只有TabLayout高度的一半时，才会变化，否则会回到当前的状态。

snapMargins #

需要与scroll、snap一起使用。当使用snap时，在TabLayout中设置marginBottom，设置的marginBottom不会随着TabLayout一起，会有marginBottom高度的一块留在顶部，需要再次滑动才能收起来。这就是snapMargins的使用场景，设置了marginBottom会随着TabLayout一起收起。

上面几种的效果其实都不是我们想要的。enterAlways没有吸顶的效果，意味着TabLayout可以显示一部分，这时用户点击Tab到其他内容页时，TabLayout的显示就会异常。而使用snap时，当TabLayout已经隐藏了，如果用户滑动到一半了就需要先回到第0个item的位置，再滑动才能显示TabLayout，体验很差。

既然有snap有吸顶效果，enterAlways又可以在任何位置位置滑出/隐藏TabLayout。有没有可能实现结合的效果呢？把两个flag都写在TabLayout上，确实实现了。但是没有文档说可以这么用，很迷惑。去看了下AppBarLayout的源码，CoordinatorLayout和AppBarLayout联动原理不再赘述。

snap的效果与enterAlways实际上是分开的。设置了SCROLL_FLAG_ENTER_ALWAYS后，从任意位置都能滑出TabLayout。又因为有snap的效果，手指松开结束滑动之后又会有吸顶的效果。

Material Design滚动变色效果实现

Mon, 04 Nov 2024 07:25:50 +0800

许许多多Material风格的Android应用支持滚动后改变Action Bar和状态栏的颜色, 放一张示例图:

实现 #

外层ViewGroup改用CoordinatorLayout #

CoordinatorLayout才支持内部View滚动后调用behavior的方法, 自定义View也能实现.

滚动View添加flag #

1
2


app:layout_behavior="@string/
appbar_scrolling_view_behavior"

做出反应的View添加style #

1

android:theme="@style/ThemeOverlay.AppCompat.Dark.ActionBar"

效果图:

完成代码 #

 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



<?xml version="1.0" encoding="utf-8"?>
<androidx.coordinatorlayout.widget.CoordinatorLayout xmlns:android="http://schemas.android.com/apk/res/android"
 xmlns:app="http://schemas.android.com/apk/res-auto"
 xmlns:tools="http://schemas.android.com/tools"
 android:id="@+id/main"
 android:layout_width="match_parent"
 android:layout_height="match_parent"
 tools:context=".home.MainActivity">

 <!-- AppBarLayout，include Toolbar -->
 <com.google.android.material.appbar.AppBarLayout
 android:id="@+id/appBarLayout"

 android:layout_width="match_parent"
 android:layout_height="wrap_content"
 android:layout_gravity="top"
 android:fitsSystemWindows="true"
 android:theme="@style/ThemeOverlay.AppCompat.Dark.ActionBar"
 app:liftOnScroll="true">

 <androidx.appcompat.widget.Toolbar
 android:id="@+id/toolbar"
 style="?actionBarStyle"
 android:layout_width="match_parent"
 android:layout_height="wrap_content"
 android:background="@null"
 app:titleTextColor="@color/black" />
 </com.google.android.material.appbar.AppBarLayout>


 <androidx.recyclerview.widget.RecyclerView
 android:id="@+id/rv_installed_app"
 android:layout_width="match_parent"
 android:layout_height="match_parent"
 android:scrollbars="vertical"
 app:layout_behavior="@string/appbar_scrolling_view_behavior" />

</androidx.coordinatorlayout.widget.CoordinatorLayout>

注: 不要忘记设置SupportActionBar

验证suspend all threads

Sat, 02 Nov 2024 09:05:36 +0800

验证suspend all threads #

对应KOOM实现流程, 结合对比几种场景, 验证KOOM中fork前suspend和resume后作用.

suspend和resume #

suspendAndFork

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


pid_t HprofDump::SuspendAndFork() {
 KCHECKI(init_done_)
 if (android_api_ < __ANDROID_API_R__) {
 suspend_vm_fnc_();
 } else if (android_api_ <= __ANDROID_API_S__) {
 void *self = __get_tls()[TLS_SLOT_ART_THREAD_SELF];
 sgc_constructor_fnc_((void *)sgc_instance_.get(), self, kGcCauseHprof,
 kCollectorTypeHprof);
 ssa_constructor_fnc_((void *)ssa_instance_.get(), LOG_TAG, true);
 // avoid deadlock with child process
 exclusive_unlock_fnc_(*mutator_lock_ptr_, self);
 sgc_destructor_fnc_((void *)sgc_instance_.get());
 }
 pid_t pid = fork();
 if (pid == 0) {
 // Set timeout for child process
 alarm(60);
 prctl(PR_SET_NAME, "forked-dump-process");
 }
 return pid;
}

resumeAndWait

 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


bool HprofDump::ResumeAndWait(pid_t pid) {
 KCHECKB(init_done_)
 if (android_api_ < __ANDROID_API_R__) {
 resume_vm_fnc_();
 } else if (android_api_ <= __ANDROID_API_S__) {
 void *self = __get_tls()[TLS_SLOT_ART_THREAD_SELF];
 exclusive_lock_fnc_(*mutator_lock_ptr_, self);
 ssa_destructor_fnc_((void *)ssa_instance_.get());
 }
 int status;
 for (;;) {
 if (waitpid(pid, &status, 0) != -1) {
 if (!WIFEXITED(status)) {
 ALOGE("Child process %d exited with status %d, terminated by signal %d",
 pid, WEXITSTATUS(status), WTERMSIG(status));
 return false;
 }
 return true;
 }
 // if waitpid is interrupted by the signal,just call it again
 if (errno == EINTR){
 continue;
 }
 return false;
 }
}

suspend验证 #

运行环境：一部虚拟机Android 9，一部物理机器Android 13

除Android13标题下的, 环境均为Android9的虚拟机.

运行KOOM Demo #

 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


2024-02-27 11:17:25.346 12889-12889 OOMMonitor              com.kwai.koom.demo                   I  startLoop()
2024-02-27 11:17:30.412 12889-12940 OOMMonitor_SystemInfo   com.kwai.koom.demo                   I  ----OOM Monitor Memory----
2024-02-27 11:17:30.412 12889-12940 OOMMonitor_SystemInfo   com.kwai.koom.demo                   I  [java] max:536870912 used ratio:1%
2024-02-27 11:17:30.412 12889-12940 OOMMonitor_SystemInfo   com.kwai.koom.demo                   I  [proc] VmSize:2695044kB VmRss:135440kB Threads:715
2024-02-27 11:17:30.412 12889-12940 OOMMonitor_SystemInfo   com.kwai.koom.demo                   I  [meminfo] MemTotal:2042232kB MemFree:352144kB MemAvailable:881440kB
2024-02-27 11:17:30.412 12889-12940 OOMMonitor_SystemInfo   com.kwai.koom.demo                   I  avaliable ratio:43% CmaTotal:303104kB ION_heap:0kB
2024-02-27 11:17:30.412 12889-12940 OOMMonitor...OOMTracker com.kwai.koom.demo                   I  [meet condition] overThresholdCount:1, threadCount: 715
2024-02-27 11:17:30.413 12889-12940 OOMMonitor...OOMTracker com.kwai.koom.demo                   I  over threshold dumpThreadIfNeed
2024-02-27 11:17:30.833 12889-12940 OOMMonitor...OOMTracker com.kwai.koom.demo                   I  threadNames = [.kwai.koom.demo, Jit thread pool, Signal Catcher, ADB-JDWP Connec, HeapTaskDaemon, ReferenceQueueD, FinalizerDaemon, FinalizerWatchd, Binder:12889_1, Binder:12889_2, Binder:12889_3, Profile Saver, RenderThread, queued-work-loo, LoopThread, Thread-2, Thread-3, Thread-4, Thread-5, Thread-6, Thread-7, Thread-8, Thread-9, Thread-10, Thread-11, Thread-12, Thread-13, Thread-14, Thread-15, Thread-16, Thread-17, Thread-18, Thread-19, Thread-20, Thread-21, Thread-22, Thread-23, Thread-24, Thread-25, Thread-26, Thread-27, Thread-28, Thread-29, Thread-30, Thread-31, Thread-32, Thread-33, Thread-34, Thread-35, Thread-36, Thread-37, Thread-38, Thread-39, Thread-40, Thread-41, Thread-42, Thread-43, Thread-44, Thread-45, Thread-46, Thread-47, Thread-48, Thread-49, Thread-50, Thread-51, Thread-52, Thread-53, Thread-54, Thread-55, Thread-56, Thread-57, Thread-58, Thread-59, Thread-60, Thread-61, Thread-62, Thread-63, Thread-64, Thread-65, Thread-66, Thread-67, Thread-68, Thread-69, Thread-70, Thread-71, Thread-72, Thread-73, Thread-74, Thread-75, Thread-76, Thread-77, Thread-78, Thread-79, Thread-80, Thread-81, Thread-82, Thread-83, Thread-84, Thread-85, Thread-86, Thread-87, Thread-88, Thread-89, Thread-90, Thread-91, Thread-92, Thread-93, Thread-94, Thread-95, Thread-96, Thread-97, Thread-98, Thread-99, Thread-100, Thread-101, Thread-102, Thread-103, Thread-104, Thread-105, Thread-106, Thread-107, Thread-108, Thread-109, Thread-110, Thread-111, Thread-112, Thread-113, Thread-114, Thread-115, Thread-116, Thread-117, Thread-118, Thread-119, Thread-120, Thread-121, Thread-122, Thread-123, Thread-124, Thread-125, Thread-126, Thread-127, Thread-128, Thread-129, Thread-130, Thread-131, Thread-132, Thread-133, Thread-134, Thread-135, Thread-136, Thread-137, Thread-138, Thread-139, Thread-140, Thread-141, Thread-142, Thread-143, Thread-144, Thread-145, Thread-146, Thread-147, Thread-148, Thread-149, Thread-150, Thread-151, Thread-152, Thread-153, Thread-154, Thread-155, Thread-156, Thread-157, Thread-158, Thread-159, Thread-160, Thread-161, Thread-162, Thread-163, Thread-164, Thread-165, Thread-166, Thread-167, Thread-168, Thread-169, Thread-170, Thread-171, Thread-172, Thread-173, Thread-174, Thread-175, Thread-176, Thread-177, Thread-178, Thread-179, Thread-180, Thread-181, Thread-182, Thread-183, Thread-184, Thread-185, Thread-186, Thread-187, Thread-188, Thread-189, Thread-190, Thread-191, Thread-192, Thread-193, Thread-194, Thread-195, Thread-196, Thread-197, Thread-198, Thread-199, Thread-200, Thread-201, Thread-202, Thread-203, Thread-204, Thread-205, Thread-206, Thread-207, Thread-208, Thread-209, Thread-210, Thread-211, Thread-212, Thread-213, Thread-214, Thread-215, Thread-216, Thread-217, Thread-218, Thread-219, Thread-220, Thread-221, Thread-222, Thread-223, Thread-224, Thread-225, Thread-226, Thread-227, Thread-228, Thread-229, Thread-230, Thread-231, Thread-232, Thread-233, Thread-234, Thread-235, Thread-236, Thread-237, Thread-238, Thread-239, Thread-240, Thread-241, Thread-242, Thread-243, Thread-244, Thread-245, Thread-246, Thread-247, Thread-248, Thread-249, Thread-250, Thread-251, Thread-252, Thread-253, Thread-254, Thread-255, Thread-256, Thread-257, Thread-258, Thread-259, Thread-260, Thread-261, Thread-262, Thread-263, Thread-264, Thread-265, Thread-266, Thread-267, Thread-268, Thread-269, Thread-270, Thread-271, Thread-272, Thread-273, Thread-274, Thread-275, Thread-276, Thread-277, Thread-278, Thread-279, Thread-280, Thread-281, Thread-282, Thread-283, Thread-284, Thread-285, Thread-286, Thread-287, Thread-288, Thread-289, Thread-290, Thread-291, Thread-292, Thread-293, Thread-294, Thread-295, Thread-296, Thread-297, Thread-298, Thread-299, Thread-300, Thread-301, Thread-302, Thread-303, Thread-304, Thread-305, Thread-306, Thread-307, Thread-308, Thread-309, Thread-310, Thread-311, Thread-312, Thread-313, Thread-314, Thread-315, Thread-316, Thread-317, Thread-318, Thread-319, Thread-320, Thread-321, Thread-322, Thread-323, Thread-324, Thread-325, T
2024-02-27 11:17:30.847 12889-12940 OOMMonitor              com.kwai.koom.demo                   I  OOMPreferenceManager.getFirstAnalysisTime():1709003366019
2024-02-27 11:17:30.847 12889-12940 OOMMonitor              com.kwai.koom.demo                   I  OOMPreferenceManager.getAnalysisTimes:4
2024-02-27 11:17:30.849 12889-13644 OOMMonitor              com.kwai.koom.demo                   I  mTrackReasons:[reason_thread_oom]
2024-02-27 11:17:30.850 12889-13644 OOMMonitor              com.kwai.koom.demo                   I  dumpAndAnalysis
2024-02-27 11:17:30.852 12889-13645 OOMMonitor              com.kwai.koom.demo                   I  processHprofFile
2024-02-27 11:17:30.852 12889-13645 OOMMonitor              com.kwai.koom.demo                   I  delete other version files thread
2024-02-27 11:17:30.863 12889-13645 OOMMonitor              com.kwai.koom.demo                   I  delete old files
2024-02-27 11:17:30.871 12889-13644 OOMMonitor              com.kwai.koom.demo                   I  hprof analysis dir:/storage/emulated/0/Android/data/com.kwai.koom.demo/files/performance/oom/memory/hprof-aly
2024-02-27 11:17:30.872 12889-13644 OOMMonitor...HeapDumper com.kwai.koom.demo                   I  dump /storage/emulated/0/Android/data/com.kwai.koom.demo/files/performance/oom/memory/hprof-aly/1.0.0_2024-02-27_11-17-30_851.hprof
2024-02-27 11:17:30.894 12889-13644 OOMMonitor...HeapDumper com.kwai.koom.demo                   I  before suspend and fork.
2024-02-27 11:17:30.954 12889-13645 OOMMonitor              com.kwai.koom.demo                   I  delete other version files fd
---------------------------- PROCESS STARTED (13646) for package com.kwai.koom.demo ----------------------------
2024-02-27 11:17:32.199 13646-13646 OOMMonitor...HeapDumper com.kwai.koom.demo                   I  dump, spend:1305
2024-02-27 11:17:32.206 12889-13644 OOMMonitor...HeapDumper com.kwai.koom.demo                   I  parent process wait time: 1312
2024-02-27 11:17:32.206 12889-13644 OOMMonitor...HeapDumper com.kwai.koom.demo                   I  dump true, notify from pid 13646
2024-02-27 11:17:32.206 12889-13644 OOMMonitor              com.kwai.koom.demo                   I  end hprof dump
---------------------------- PROCESS ENDED (13646) for package com.kwai.koom.demo ----------------------------

多线程环境 #

主线程fork #

Java创建线程调用C++ pthread创建

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


// Java创建线程
static void Thread_nativeCreate(JNIEnv* env, jclass, jobject java_thread, jlong stack_size,
 jboolean daemon) {
 ...
 Thread::CreateNativeThread(env, java_thread, stack_size, daemon == JNI_TRUE);
}






void Thread::CreateNativeThread(JNIEnv* env, jobject java_peer, size_t stack_size, bool is_daemon) {
 CHECK(java_peer != NULL);
 ...
 pthread_t new_pthread;
 pthread_attr_t attr;
 CHECK_PTHREAD_CALL(pthread_attr_init, (&attr), "new thread");
 CHECK_PTHREAD_CALL(pthread_attr_setdetachstate, (&attr, PTHREAD_CREATE_DETACHED), "PTHREAD_CREATE_DETACHED");
 CHECK_PTHREAD_CALL(pthread_attr_setstacksize, (&attr, stack_size), stack_size);
 int pthread_create_result = pthread_create(&new_pthread, &attr, Thread::CreateCallback, child_thread);
 CHECK_PTHREAD_CALL(pthread_attr_destroy, (&attr), "new thread");
 ...
}

子线程fork #

 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


#include <pthread.h>
#include <stdio.h>
#include <sys/types.h>
#include <unistd.h>
#include <chrono>
#include <thread>


void *func1(void *args)
{
 while (1)
 {
 std::this_thread::sleep_for(std::chrono::milliseconds(1000));


 printf("func1 is printing.\n");
 }
}


int main()
{
 pthread_t tid;
 pthread_create(&tid, NULL, func1, NULL);
 sleep(3);
 pid_t pid = fork();
 // 子进程
 if (pid == 0)
 {
 int t = 5;
 while (t-- > 0)
 {
 sleep(1);
 printf("child process\n");
 }
 }
 return 0;
}

打印信息：

1
2
3
4
5
6
7
8
9


func1 is printing.
func1 is printing.
func1 is printing.
func1 is printing.
child process
child process
child process
child process
child process

子线程执行

 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


#include <pthread.h>
#include <stdio.h>
#include <sys/types.h>
#include <unistd.h>
#include <chrono>
#include <thread>


void *func1(void *args)
{
 // fork()出一个子进程
 pid_t pid = fork();
 if (pid < 0)
 {
 // 创建子进程失败
 printf("Failed to fork a child process\n");
 return NULL;
 }
 else if (pid == 0)
 {
 // 子进程
 printf("Child process pid = %d\n", getpid());
 while (1)
 {
 sleep(1);
 printf("func1: my pid = %d\n", getpid());
 }
 }
 else
 {
 // 父进程
 printf("Parent process pid = %d, child pid = %d\n", getpid(), pid);
 return NULL;
 }
}


int main()
{
 pthread_t tid;
 pthread_create(&tid, NULL, func1, NULL);
 // 主线程等待一段时间
 sleep(20);
 while (1)
 {
 sleep(1);
 printf("main : my pid = %d\n", getpid());
 }
 return 0;
}

打印日志

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


Child process pid = 56330
func1: my pid = 56330
func1: my pid = 56330
func1: my pid = 56330
func1: my pid = 56330
func1: my pid = 56330
func1: my pid = 56330
func1: my pid = 56330
func1: my pid = 56330
...

不执行suspend和resume #

没有子线程运行（Running） #

注释C++调用suspend和resume方法

 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


2024-02-27 11:13:42.395 10991-10991 OOMMonitor              com.kwai.koom.demo                   I  startLoop()
2024-02-27 11:13:47.452 10991-11040 OOMMonitor_SystemInfo   com.kwai.koom.demo                   I  ----OOM Monitor Memory----
2024-02-27 11:13:47.452 10991-11040 OOMMonitor_SystemInfo   com.kwai.koom.demo                   I  [java] max:536870912 used ratio:1%
2024-02-27 11:13:47.452 10991-11040 OOMMonitor_SystemInfo   com.kwai.koom.demo                   I  [proc] VmSize:2685572kB VmRss:138468kB Threads:715
2024-02-27 11:13:47.452 10991-11040 OOMMonitor_SystemInfo   com.kwai.koom.demo                   I  [meminfo] MemTotal:2042232kB MemFree:368948kB MemAvailable:893380kB
2024-02-27 11:13:47.453 10991-11040 OOMMonitor_SystemInfo   com.kwai.koom.demo                   I  avaliable ratio:43% CmaTotal:303104kB ION_heap:0kB
2024-02-27 11:13:47.453 10991-11040 OOMMonitor...OOMTracker com.kwai.koom.demo                   I  [meet condition] overThresholdCount:1, threadCount: 715
2024-02-27 11:13:47.453 10991-11040 OOMMonitor...OOMTracker com.kwai.koom.demo                   I  over threshold dumpThreadIfNeed
2024-02-27 11:13:47.731 10991-11040 OOMMonitor...OOMTracker com.kwai.koom.demo                   I  threadNames = [.kwai.koom.demo, Jit thread pool, Signal Catcher, ADB-JDWP Connec, HeapTaskDaemon, ReferenceQueueD, FinalizerDaemon, FinalizerWatchd, Binder:10991_1, Binder:10991_2, Binder:10991_3, Profile Saver, RenderThread, queued-work-loo, LoopThread, Thread-2, Thread-3, Thread-4, Thread-5, Thread-6, Thread-7, Thread-8, Thread-9, Thread-10, Thread-11, Thread-12, Thread-13, Thread-14, Thread-15, Thread-16, Thread-17, Thread-18, Thread-19, Thread-20, Thread-21, Thread-22, Thread-23, Thread-24, Thread-25, Thread-26, Thread-27, Thread-28, Thread-29, Thread-30, Thread-31, Thread-32, Thread-33, Thread-34, Thread-35, Thread-36, Thread-37, Thread-38, Thread-39, Thread-40, Thread-41, Thread-42, Thread-43, Thread-44, Thread-45, Thread-46, Thread-47, Thread-48, Thread-49, Thread-50, Thread-51, Thread-52, Thread-53, Thread-54, Thread-55, Thread-56, Thread-57, Thread-58, Thread-59, Thread-60, Thread-61, Thread-62, Thread-63, Thread-64, Thread-65, Thread-66, Thread-67, Thread-68, Thread-69, Thread-70, Thread-71, Thread-72, Thread-73, Thread-74, Thread-75, Thread-76, Thread-77, Thread-78, Thread-79, Thread-80, Thread-81, Thread-82, Thread-83, Thread-84, Thread-85, Thread-86, Thread-87, Thread-88, Thread-89, Thread-90, Thread-91, Thread-92, Thread-93, Thread-94, Thread-95, Thread-96, Thread-97, Thread-98, Thread-99, Thread-100, Thread-101, Thread-102, Thread-103, Thread-104, Thread-105, Thread-106, Thread-107, Thread-108, Thread-109, Thread-110, Thread-111, Thread-112, Thread-113, Thread-114, Thread-115, Thread-116, Thread-117, Thread-118, Thread-119, Thread-120, Thread-121, Thread-122, Thread-123, Thread-124, Thread-125, Thread-126, Thread-127, Thread-128, Thread-129, Thread-130, Thread-131, Thread-132, Thread-133, Thread-134, Thread-135, Thread-136, Thread-137, Thread-138, Thread-139, Thread-140, Thread-141, Thread-142, Thread-143, Thread-144, Thread-145, Thread-146, Thread-147, Thread-148, Thread-149, Thread-150, Thread-151, Thread-152, Thread-153, Thread-154, Thread-155, Thread-156, Thread-157, Thread-158, Thread-159, Thread-160, Thread-161, Thread-162, Thread-163, Thread-164, Thread-165, Thread-166, Thread-167, Thread-168, Thread-169, Thread-170, Thread-171, Thread-172, Thread-173, Thread-174, Thread-175, Thread-176, Thread-177, Thread-178, Thread-179, Thread-180, Thread-181, Thread-182, Thread-183, Thread-184, Thread-185, Thread-186, Thread-187, Thread-188, Thread-189, Thread-190, Thread-191, Thread-192, Thread-193, Thread-194, Thread-195, Thread-196, Thread-197, Thread-198, Thread-199, Thread-200, Thread-201, Thread-202, Thread-203, Thread-204, Thread-205, Thread-206, Thread-207, Thread-208, Thread-209, Thread-210, Thread-211, Thread-212, Thread-213, Thread-214, Thread-215, Thread-216, Thread-217, Thread-218, Thread-219, Thread-220, Thread-221, Thread-222, Thread-223, Thread-224, Thread-225, Thread-226, Thread-227, Thread-228, Thread-229, Thread-230, Thread-231, Thread-232, Thread-233, Thread-234, Thread-235, Thread-236, Thread-237, Thread-238, Thread-239, Thread-240, Thread-241, Thread-242, Thread-243, Thread-244, Thread-245, Thread-246, Thread-247, Thread-248, Thread-249, Thread-250, Thread-251, Thread-252, Thread-253, Thread-254, Thread-255, Thread-256, Thread-257, Thread-258, Thread-259, Thread-260, Thread-261, Thread-262, Thread-263, Thread-264, Thread-265, Thread-266, Thread-267, Thread-268, Thread-269, Thread-270, Thread-271, Thread-272, Thread-273, Thread-274, Thread-275, Thread-276, Thread-277, Thread-278, Thread-279, Thread-280, Thread-281, Thread-282, Thread-283, Thread-284, Thread-285, Thread-286, Thread-287, Thread-288, Thread-289, Thread-290, Thread-291, Thread-292, Thread-293, Thread-294, Thread-295, Thread-296, Thread-297, Thread-298, Thread-299, Thread-300, Thread-301, Thread-302, Thread-303, Thread-304, Thread-305, Thread-306, Thread-307, Thread-308, Thread-309, Thread-310, Thread-311, Thread-312, Thread-313, Thread-314, Thread-315, Thread-316, Thread-317, Thread-318, Thread-319, Thread-320, Thread-321, Thread-322, Thread-323, Thread-324, Thread-325, T
2024-02-27 11:13:47.738 10991-11040 OOMMonitor              com.kwai.koom.demo                   I  OOMPreferenceManager.getFirstAnalysisTime():1709003366019
2024-02-27 11:13:47.738 10991-11040 OOMMonitor              com.kwai.koom.demo                   I  OOMPreferenceManager.getAnalysisTimes:2
2024-02-27 11:13:47.741 10991-11746 OOMMonitor              com.kwai.koom.demo                   I  mTrackReasons:[reason_thread_oom]
2024-02-27 11:13:47.741 10991-11746 OOMMonitor              com.kwai.koom.demo                   I  dumpAndAnalysis
2024-02-27 11:13:47.743 10991-11747 OOMMonitor              com.kwai.koom.demo                   I  processHprofFile
2024-02-27 11:13:47.743 10991-11747 OOMMonitor              com.kwai.koom.demo                   I  delete other version files thread
2024-02-27 11:13:47.752 10991-11747 OOMMonitor              com.kwai.koom.demo                   I  delete old files
2024-02-27 11:13:47.753 10991-11746 OOMMonitor              com.kwai.koom.demo                   I  hprof analysis dir:/storage/emulated/0/Android/data/com.kwai.koom.demo/files/performance/oom/memory/hprof-aly
2024-02-27 11:13:47.754 10991-11746 OOMMonitor...HeapDumper com.kwai.koom.demo                   I  dump /storage/emulated/0/Android/data/com.kwai.koom.demo/files/performance/oom/memory/hprof-aly/1.0.0_2024-02-27_11-13-47_742.hprof
2024-02-27 11:13:47.762 10991-11747 OOMMonitor              com.kwai.koom.demo                   I  delete other version files fd
2024-02-27 11:13:47.771 10991-11746 OOMMonitor...HeapDumper com.kwai.koom.demo                   I  before suspend and fork.
---------------------------- PROCESS STARTED (11748) for package com.kwai.koom.demo ----------------------------
2024-02-27 11:13:48.920 11748-11748 OOMMonitor...HeapDumper com.kwai.koom.demo                   I  dump, spend:1149
2024-02-27 11:13:48.927 10991-11746 OOMMonitor...HeapDumper com.kwai.koom.demo                   I  parent process wait time: 1156
2024-02-27 11:13:48.927 10991-11746 OOMMonitor...HeapDumper com.kwai.koom.demo                   I  dump true, notify from pid 11748
2024-02-27 11:13:48.927 10991-11746 OOMMonitor              com.kwai.koom.demo                   I  end hprof dump
---------------------------- PROCESS ENDED (11748) for package com.kwai.koom.demo ----------------------------

父进程fork前有子线程在运行，子进程dump #

fork前启动了一个线程，死循环执行

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


2024-02-29 16:40:02.053  2594-2657  OOMMonitor              com.kwai.koom.demo                   I  OOMPreferenceManager.getFirstAnalysisTime():1709191024825
2024-02-29 16:40:02.053  2594-2657  OOMMonitor              com.kwai.koom.demo                   I  OOMPreferenceManager.getAnalysisTimes:1
2024-02-29 16:40:02.056  2594-3570  OOMMonitor              com.kwai.koom.demo                   I  mTrackReasons:[reason_thread_oom]
2024-02-29 16:40:02.056  2594-3570  OOMMonitor              com.kwai.koom.demo                   I  dumpAndAnalysis
2024-02-29 16:40:02.061  2594-3571  OOMMonitor              com.kwai.koom.demo                   I  processHprofFile
2024-02-29 16:40:02.061  2594-3571  OOMMonitor              com.kwai.koom.demo                   I  delete other version files thread
2024-02-29 16:40:02.071  2594-3571  OOMMonitor              com.kwai.koom.demo                   I  create json file and then start service
2024-02-29 16:40:02.073  2594-3571  OOMMonitor              com.kwai.koom.demo                   I  hprof file size 0
2024-02-29 16:40:02.079  2594-3570  OOMMonitor              com.kwai.koom.demo                   I  hprof analysis dir:/storage/emulated/0/Android/data/com.kwai.koom.demo/files/performance/oom/memory/hprof-aly
2024-02-29 16:40:02.080  2594-3570  OOMMonitor...HeapDumper com.kwai.koom.demo                   I  dump /storage/emulated/0/Android/data/com.kwai.koom.demo/files/performance/oom/memory/hprof-aly/1.0.0_2024-02-29_16-40-02_060.hprof
2024-02-29 16:40:02.090  2594-3570  OOMMonitor...HeapDumper com.kwai.koom.demo                   I  parent process active thread count: 712
2024-02-29 16:40:02.090  2594-3570  OOMMonitor...HeapDumper com.kwai.koom.demo                   I  before suspend and fork.
2024-02-29 16:40:02.126  3577-3577  OOMMonitor...HeapDumper pid-3577                             I  child process
---------------------------- PROCESS STARTED (3577) for package com.kwai.koom.demo ----------------------------
2024-02-29 16:41:02.162  2594-3570  OOMMonitor...HeapDumper com.kwai.koom.demo                   I  t1:RUNNABLE
2024-02-29 16:41:02.162  2594-3570  OOMMonitor...HeapDumper com.kwai.koom.demo                   I  t2:TERMINATED
2024-02-29 16:41:02.162  2594-3570  OOMMonitor...HeapDumper com.kwai.koom.demo                   I  t3:TERMINATED
2024-02-29 16:41:02.162  2594-3570  OOMMonitor...HeapDumper com.kwai.koom.demo                   I  dump false, notify from pid 3577
2024-02-29 16:41:02.163  2594-3570  OOMMonitor...HeapDumper com.kwai.koom.demo                   I  parent process wait time: 60029
2024-02-29 16:41:02.163  2594-3570  OOMMonitor              com.kwai.koom.demo                   I  end hprof dump

结果: 多了一个正在运行的线程

子进程执行dump到60s结束

父进程fork前有子线程在运行，子进程suspend #

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


2024-03-01 14:05:41.932 18915-18915 OOMMonitor               com.kwai.koom.demo                   I  startLoop()
2024-03-01 14:05:47.540 18915-19076 OOMMonitor               com.kwai.koom.demo                   I  OOMPreferenceManager.getFirstAnalysisTime():1709191024825
2024-03-01 14:05:47.541 18915-19076 OOMMonitor               com.kwai.koom.demo                   I  OOMPreferenceManager.getAnalysisTimes:4
2024-03-01 14:05:47.548 18915-19780 OOMMonitor               com.kwai.koom.demo                   I  mTrackReasons:[reason_thread_oom]
2024-03-01 14:05:47.548 18915-19780 OOMMonitor               com.kwai.koom.demo                   I  dumpAndAnalysis
2024-03-01 14:05:47.551 18915-19781 OOMMonitor               com.kwai.koom.demo                   I  processHprofFile
2024-03-01 14:05:47.552 18915-19781 OOMMonitor               com.kwai.koom.demo                   I  delete other version files thread
2024-03-01 14:05:47.575 18915-19780 OOMMonitor               com.kwai.koom.demo                   I  hprof analysis dir:/storage/emulated/0/Android/data/com.kwai.koom.demo/files/performance/oom/memory/hprof-aly
2024-03-01 14:05:47.578 18915-19780 OOMMonitor_...HeapDumper com.kwai.koom.demo                   I  dump /storage/emulated/0/Android/data/com.kwai.koom.demo/files/performance/oom/memory/hprof-aly/1.0.0_2024-03-01_14-05-47_549.hprof
2024-03-01 14:05:47.600 18915-19780 OOMMonitor_...HeapDumper com.kwai.koom.demo                   I  parent process active thread count: 711
2024-03-01 14:05:47.600 18915-19780 OOMMonitor_...HeapDumper com.kwai.koom.demo                   I  before suspend and fork.
2024-03-01 14:05:47.684 19783-19783 OOMMonitor_...HeapDumper pid-19783                            I  child process
---------------------------- PROCESS STARTED (19783) for package com.kwai.koom.demo ----------------------------
2024-03-01 14:06:47.752 18915-19780 OOMMonitor_...HeapDumper com.kwai.koom.demo                   I  dump false, notify from pid 19783
2024-03-01 14:06:47.752 18915-19780 OOMMonitor_...HeapDumper com.kwai.koom.demo                   I  parent process wait: 60070
2024-03-01 14:06:47.753 18915-19780 OOMMonitor               com.kwai.koom.demo                   I  end hprof dump
---------------------------- PROCESS ENDED (19783) for package com.kwai.koom.demo ----------------------------

父进程有正在运行线程，fork前suspend，子进程dump #

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


2024-03-01 14:22:24.453 20998-20998 OOMMonitor               com.kwai.koom.demo                   I  startLoop()
2024-03-01 14:22:29.986 20998-21049 OOMMonitor               com.kwai.koom.demo                   I  OOMPreferenceManager.getFirstAnalysisTime():1709191024825
2024-03-01 14:22:29.986 20998-21049 OOMMonitor               com.kwai.koom.demo                   I  OOMPreferenceManager.getAnalysisTimes:4
2024-03-01 14:22:29.990 20998-21757 OOMMonitor               com.kwai.koom.demo                   I  mTrackReasons:[reason_thread_oom]
2024-03-01 14:22:29.990 20998-21757 OOMMonitor               com.kwai.koom.demo                   I  dumpAndAnalysis
2024-03-01 14:22:29.999 20998-21758 OOMMonitor               com.kwai.koom.demo                   I  processHprofFile
2024-03-01 14:22:30.000 20998-21758 OOMMonitor               com.kwai.koom.demo                   I  delete other version files thread
2024-03-01 14:22:30.015 20998-21757 OOMMonitor               com.kwai.koom.demo                   I  hprof analysis dir:/storage/emulated/0/Android/data/com.kwai.koom.demo/files/performance/oom/memory/hprof-aly
2024-03-01 14:22:30.015 20998-21758 OOMMonitor               com.kwai.koom.demo                   I  create json file and then start service
2024-03-01 14:22:30.018 20998-21757 OOMMonitor_...HeapDumper com.kwai.koom.demo                   I  dump /storage/emulated/0/Android/data/com.kwai.koom.demo/files/performance/oom/memory/hprof-aly/1.0.0_2024-03-01_14-22-29_992.hprof
2024-03-01 14:22:30.018 20998-21758 OOMMonitor               com.kwai.koom.demo                   I  hprof file size 0
2024-03-01 14:22:30.036 20998-21757 OOMMonitor_...HeapDumper com.kwai.koom.demo                   I  parent process active thread count: 710
2024-03-01 14:22:30.037 20998-21757 OOMMonitor_...HeapDumper com.kwai.koom.demo                   I  before suspend and fork.
2024-03-01 14:22:30.147 21760-21760 OOMMonitor_...HeapDumper pid-21760                            I  parent process suspend time: 40
2024-03-01 14:22:30.147 21760-21760 OOMMonitor_...HeapDumper pid-21760                            I  child process
2024-03-01 14:22:30.148 21760-21760 OOMMonitor_...HeapDumper pid-21760                            I  child process active thread count: 710
2024-03-01 14:22:30.148 21760-21760 OOMMonitor_...HeapDumper pid-21760                            I  suspend all thread, spend time: 1
2024-03-01 14:22:30.152 20998-21757 OOMMonitor_...HeapDumper com.kwai.koom.demo                   I  parent process suspend time: 40
---------------------------- PROCESS STARTED (21760) for package com.kwai.koom.demo ----------------------------
2024-03-01 14:22:32.005 20998-21757 OOMMonitor_...HeapDumper com.kwai.koom.demo                   I  dump true, notify from pid 21760
2024-03-01 14:22:32.006 20998-21757 OOMMonitor_...HeapDumper com.kwai.koom.demo                   I  parent process wait: 1854
2024-03-01 14:22:32.006 20998-21757 OOMMonitor               com.kwai.koom.demo                   I  end hprof dump
---------------------------- PROCESS ENDED (21760) for package com.kwai.koom.demo ----------------------------

结论: 子进程耗时没有卡住，dump的第一个步骤是suspend，长耗时是suspend造成的

Android 13 #

alarm改成180 #

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


2024-02-29 17:26:28.568  7764-7764  OOMMonitor              com.kwai.koom.demo                   I  startLoop()
2024-02-29 17:26:34.506  7764-7822  OOMMonitor              com.kwai.koom.demo                   I  OOMPreferenceManager.getFirstAnalysisTime():1709191024825
2024-02-29 17:26:34.506  7764-7822  OOMMonitor              com.kwai.koom.demo                   I  OOMPreferenceManager.getAnalysisTimes:2
2024-02-29 17:26:34.509  7764-8534  OOMMonitor              com.kwai.koom.demo                   I  mTrackReasons:[reason_thread_oom]
2024-02-29 17:26:34.509  7764-8534  OOMMonitor              com.kwai.koom.demo                   I  dumpAndAnalysis
2024-02-29 17:26:34.512  7764-8535  OOMMonitor              com.kwai.koom.demo                   I  processHprofFile
2024-02-29 17:26:34.516  7764-8535  OOMMonitor              com.kwai.koom.demo                   I  delete other version files thread
2024-02-29 17:26:34.525  7764-8535  OOMMonitor              com.kwai.koom.demo                   I  delete old files
2024-02-29 17:26:34.540  7764-8535  OOMMonitor              com.kwai.koom.demo                   I  delete other version files fd
2024-02-29 17:26:34.777  7764-8534  OOMMonitor              com.kwai.koom.demo                   I  hprof analysis dir:/storage/emulated/0/Android/data/com.kwai.koom.demo/files/performance/oom/memory/hprof-aly
2024-02-29 17:26:34.778  7764-8534  OOMMonitor...HeapDumper com.kwai.koom.demo                   I  dump /storage/emulated/0/Android/data/com.kwai.koom.demo/files/performance/oom/memory/hprof-aly/1.0.0_2024-02-29_17-26-34_512.hprof
2024-02-29 17:26:34.800  7764-8534  OOMMonitor...HeapDumper com.kwai.koom.demo                   I  parent process active thread count: 712
2024-02-29 17:26:34.801  7764-8534  OOMMonitor...HeapDumper com.kwai.koom.demo                   I  before suspend and fork.
2024-02-29 17:26:34.838  8539-8539  OOMMonitor...HeapDumper pid-8539                             I  child process
---------------------------- PROCESS STARTED (8539) for package com.kwai.koom.demo ----------------------------
2024-02-29 17:29:39.794  7764-8534  OOMMonitor...HeapDumper com.kwai.koom.demo                   I  t1:RUNNABLE
2024-02-29 17:29:39.794  7764-8534  OOMMonitor...HeapDumper com.kwai.koom.demo                   I  t2:TERMINATED
2024-02-29 17:29:39.794  7764-8534  OOMMonitor...HeapDumper com.kwai.koom.demo                   I  t3:TERMINATED
2024-02-29 17:29:39.795  7764-8534  OOMMonitor...HeapDumper com.kwai.koom.demo                   I  dump false, notify from pid 8539
2024-02-29 17:29:39.795  7764-8534  OOMMonitor...HeapDumper com.kwai.koom.demo                   I  parent process wait time: 184958
2024-02-29 17:29:39.795  7764-8534  OOMMonitor              com.kwai.koom.demo                   I  end hprof dump

结论: Android 13不fork没有子线程运行dump（KOOM fork前suspend方法不生效）

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


2024-03-01 10:24:38.321 19711-19711 OOMMonitor               com.kwai.koom.demo                   I  startLoop()
2024-03-01 10:24:43.472 19711-19853 OOMMonitor               com.kwai.koom.demo                   I  OOMPreferenceManager.getFirstAnalysisTime():1709201524073
2024-03-01 10:24:43.472 19711-19853 OOMMonitor               com.kwai.koom.demo                   I  OOMPreferenceManager.getAnalysisTimes:3
2024-03-01 10:24:43.473 19711-20567 OOMMonitor               com.kwai.koom.demo                   I  mTrackReasons:[reason_thread_oom]
2024-03-01 10:24:43.473 19711-20567 OOMMonitor               com.kwai.koom.demo                   I  dumpAndAnalysis
2024-03-01 10:24:43.473 19711-20568 OOMMonitor               com.kwai.koom.demo                   I  processHprofFile
2024-03-01 10:24:43.473 19711-20568 OOMMonitor               com.kwai.koom.demo                   I  delete other version files thread
2024-03-01 10:24:43.475 19711-20568 OOMMonitor               com.kwai.koom.demo                   I  create json file and then start service
2024-03-01 10:24:43.478 19711-20568 OOMMonitor_...sisService com.kwai.koom.demo                   I  startAnalysisService
2024-03-01 10:24:43.482 19711-20567 OOMMonitor               com.kwai.koom.demo                   I  hprof analysis dir:/storage/emulated/0/Android/data/com.kwai.koom.demo/files/performance/oom/memory/hprof-aly
2024-03-01 10:24:43.482 19711-20567 OOMMonitor_...HeapDumper com.kwai.koom.demo                   I  dump /storage/emulated/0/Android/data/com.kwai.koom.demo/files/performance/oom/memory/hprof-aly/1.0.0_2024-03-01_10-24-43_473.hprof
2024-03-01 10:24:43.485 19711-20568 OOMMonitor_...sisService com.kwai.koom.demo                   I  startAnalysisService get Pss:85973
2024-03-01 10:24:43.485 19711-20567 OOMMonitor_...HeapDumper com.kwai.koom.demo                   I  parent process active thread count: 716
2024-03-01 10:24:43.485 19711-20567 OOMMonitor_...HeapDumper com.kwai.koom.demo                   I  before suspend and fork.
2024-03-01 10:24:45.092 19711-20567 OOMMonitor_...HeapDumper com.kwai.koom.demo                   I  parent dump wait: 1607
2024-03-01 10:24:45.093 19711-20567 OOMMonitor               com.kwai.koom.demo                   I  end hprof dump

不fork有子线程运行dump #

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


2024-03-01 15:19:17.857  4939-4939  OOMMonitor               com.kwai.koom.demo                   I  startLoop()
2024-03-01 15:19:23.091  4939-5012  OOMMonitor               com.kwai.koom.demo                   I  OOMPreferenceManager.getFirstAnalysisTime():1709277563090
2024-03-01 15:19:23.091  4939-5012  OOMMonitor               com.kwai.koom.demo                   I  OOMPreferenceManager.getAnalysisTimes:0
2024-03-01 15:19:23.092  4939-5746  OOMMonitor               com.kwai.koom.demo                   I  mTrackReasons:[reason_thread_oom]
2024-03-01 15:19:23.092  4939-5746  OOMMonitor               com.kwai.koom.demo                   I  dumpAndAnalysis
2024-03-01 15:19:23.093  4939-5747  OOMMonitor               com.kwai.koom.demo                   I  processHprofFile
2024-03-01 15:19:23.093  4939-5747  OOMMonitor               com.kwai.koom.demo                   I  delete other version files thread
2024-03-01 15:19:23.100  4939-5746  OOMMonitor               com.kwai.koom.demo                   I  hprof analysis dir:/storage/emulated/0/Android/data/com.kwai.koom.demo/files/performance/oom/memory/hprof-aly
2024-03-01 15:19:23.100  4939-5746  OOMMonitor_...HeapDumper com.kwai.koom.demo                   I  dump /storage/emulated/0/Android/data/com.kwai.koom.demo/files/performance/oom/memory/hprof-aly/1.0.0_2024-03-01_15-19-23_092.hprof
2024-03-01 15:19:23.107  4939-5746  OOMMonitor_...HeapDumper com.kwai.koom.demo                   I  parent process active thread count: 716
2024-03-01 15:19:24.924  4939-5746  OOMMonitor_...HeapDumper com.kwai.koom.demo                   I  dump spend time: 1817
2024-03-01 15:19:24.925  4939-5746  OOMMonitor               com.kwai.koom.demo                   I  end hprof dump

父进程没有其他线程运行时，子进程dump #

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


2024-03-01 10:32:23.682 23437-23437 OOMMonitor               com.kwai.koom.demo                   I  startLoop()
2024-03-01 10:32:28.974 23437-23527 OOMMonitor               com.kwai.koom.demo                   I  OOMPreferenceManager.getFirstAnalysisTime():1709201524073
2024-03-01 10:32:28.974 23437-23527 OOMMonitor               com.kwai.koom.demo                   I  OOMPreferenceManager.getAnalysisTimes:7
2024-03-01 10:32:28.976 23437-24239 OOMMonitor               com.kwai.koom.demo                   I  mTrackReasons:[reason_thread_oom]
2024-03-01 10:32:28.976 23437-24239 OOMMonitor               com.kwai.koom.demo                   I  dumpAndAnalysis
2024-03-01 10:32:28.977 23437-24240 OOMMonitor               com.kwai.koom.demo                   I  processHprofFile
2024-03-01 10:32:28.978 23437-24240 OOMMonitor               com.kwai.koom.demo                   I  delete other version files thread
2024-03-01 10:32:28.985 23437-24240 OOMMonitor               com.kwai.koom.demo                   I  delete old files
2024-03-01 10:32:28.986 23437-24239 OOMMonitor               com.kwai.koom.demo                   I  hprof analysis dir:/storage/emulated/0/Android/data/com.kwai.koom.demo/files/performance/oom/memory/hprof-aly
2024-03-01 10:32:28.986 23437-24239 OOMMonitor_...HeapDumper com.kwai.koom.demo                   I  dump /storage/emulated/0/Android/data/com.kwai.koom.demo/files/performance/oom/memory/hprof-aly/1.0.0_2024-03-01_10-32-28_977.hprof
2024-03-01 10:32:28.990 23437-24239 OOMMonitor_...HeapDumper com.kwai.koom.demo                   I  parent process active thread count: 716
2024-03-01 10:32:28.990 23437-24239 OOMMonitor_...HeapDumper com.kwai.koom.demo                   I  before suspend and fork.
2024-03-01 10:32:29.007 24241-24241 OOMMonitor_...HeapDumper pid-24241                            I  child process
2024-03-01 10:32:29.009 23437-24240 OOMMonitor               com.kwai.koom.demo                   I  delete other version files fd
---------------------------- PROCESS STARTED (24241) for package com.kwai.koom.demo ----------------------------
2024-03-01 10:32:31.214 23437-24239 OOMMonitor_...HeapDumper com.kwai.koom.demo                   I  dump false, notify from pid 24241
2024-03-01 10:32:31.214 23437-24239 OOMMonitor_...HeapDumper com.kwai.koom.demo                   I  parent process wait time: 2208
2024-03-01 10:32:31.214 23437-24239 OOMMonitor               com.kwai.koom.demo                   I  end hprof dump
---------------------------- PROCESS ENDED (24241) for package com.kwai.koom.demo ----------------------------

结论: dump正常结果

Android13父进程有线程运行时，子进程dump #

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


2024-03-01 10:34:19.954 25380-25380 OOMMonitor               com.kwai.koom.demo                   I  startLoop()
2024-03-01 10:34:25.139 25380-25433 OOMMonitor               com.kwai.koom.demo                   I  OOMPreferenceManager.getFirstAnalysisTime():1709201524073
2024-03-01 10:34:25.139 25380-25433 OOMMonitor               com.kwai.koom.demo                   I  OOMPreferenceManager.getAnalysisTimes:9
2024-03-01 10:34:25.141 25380-26166 OOMMonitor               com.kwai.koom.demo                   I  mTrackReasons:[reason_thread_oom]
2024-03-01 10:34:25.141 25380-26166 OOMMonitor               com.kwai.koom.demo                   I  dumpAndAnalysis
2024-03-01 10:34:25.142 25380-26167 OOMMonitor               com.kwai.koom.demo                   I  processHprofFile
2024-03-01 10:34:25.142 25380-26167 OOMMonitor               com.kwai.koom.demo                   I  delete other version files thread
2024-03-01 10:34:25.152 25380-26167 OOMMonitor               com.kwai.koom.demo                   I  create json file and then start service
2024-03-01 10:34:25.154 25380-26166 OOMMonitor               com.kwai.koom.demo                   I  hprof analysis dir:/storage/emulated/0/Android/data/com.kwai.koom.demo/files/performance/oom/memory/hprof-aly
2024-03-01 10:34:25.154 25380-26167 OOMMonitor               com.kwai.koom.demo                   I  hprof file size 0
2024-03-01 10:34:25.155 25380-26166 OOMMonitor_...HeapDumper com.kwai.koom.demo                   I  dump /storage/emulated/0/Android/data/com.kwai.koom.demo/files/performance/oom/memory/hprof-aly/1.0.0_2024-03-01_10-34-25_142.hprof
2024-03-01 10:34:25.156 25380-26167 OOMMonitor               com.kwai.koom.demo                   I  last analysis isn't succeed, delete file
2024-03-01 10:34:25.160 25380-26166 OOMMonitor_...HeapDumper com.kwai.koom.demo                   I  parent process active thread count: 717
2024-03-01 10:34:25.160 25380-26166 OOMMonitor_...HeapDumper com.kwai.koom.demo                   I  before suspend and fork.
2024-03-01 10:34:25.177 26169-26169 OOMMonitor_...HeapDumper pid-26169                            I  child process
---------------------------- PROCESS STARTED (26169) for package com.kwai.koom.demo ----------------------------
2024-03-01 10:35:25.191 25380-26166 OOMMonitor_...HeapDumper com.kwai.koom.demo                   I  dump false, notify from pid 26169
2024-03-01 10:35:25.191 25380-26166 OOMMonitor_...HeapDumper com.kwai.koom.demo                   I  parent process wait time: 60015
2024-03-01 10:35:25.191 25380-26166 OOMMonitor               com.kwai.koom.demo                   I  end hprof dump
---------------------------- PROCESS ENDED (26169) for package com.kwai.koom.demo ----------------------------

结论: 子进程卡在dump

COW与HProf文件格式分析

Sat, 02 Nov 2024 00:15:04 +0800

COW(copy on write) #

Linux通过fork()和exec()函数族创建新进程。

为什么通过这种方式，而不是从头开始创建新进程？ #

Of course, one big question you might have: why would we build such an odd interface to what should be the simple act of creating a new process? Well, as it turns out, the separation of fork() and exec() is essential in building a UNIX shell, because it lets the shell run code after the call to fork() but before the call to exec(); this code can alter the environment of the about-to-be-run program, and thus enables a variety of interesting features to be readily built. The shell is just a user program4 . It shows you a prompt and then waits for you to type something into it. You then type a command (i.e., the name of an executable program, plus any arguments) into it; in most cases, the shell then figures out where in the file system the executable resides, calls fork() to create a new child process to run the command, calls some variant of exec() to run the command, and then waits for the command to complete by calling wait(). When the child completes, the shell returns from wait() and prints out a prompt again, ready for your next command. The separation of fork() and exec() allows the shell to do a whole bunch of useful things rather easily. For example: prompt> wc p3.c > newfile.txt In the example above, the output of the program wc is redirected into the output file newfile.txt (the greater-than sign is how said redirection is indicated). The way the shell accomplishes this task is quite simple: when the child is created, before calling exec(), the shell (specifically, the code executed in the child process) closes standard output and opens the file newfile.txt. By doing so, any output from the soonto-be-running program wc is sent to the file instead of the screen (open file descriptors are kept open across the exec() call, thus enabling this behavior [SR05]).

–威斯康大学出的 Operating System: Three Easy Pieces 的第一章第三节

微软的研究

fork()最早出现在Genie分时操作系统，允许父进程描述新进程的内存地址和机器上下文。默认情况下子进程和父进程共享内存，可以选择给子进程提供另一块完全不同的内存执行不同的程序。

UNIX可以shell实现 prompt> wc p3.c > newfile.txt 这类功能。

为什么用Copy on Write #

在Unix诞生早期，fork简单。不需要参数，为新进程提供了继承自父进程的默认值。后面随着进程的尺寸越来越大，需要复制文件锁、定时器、异步IO操作、跟踪等。此外，许多系统调用标志控制了fork在内存映射标志 MADV_DONTFORK/DOFORK/WIPEONFORK等）、文件描述符和线程都需要复制给子进程这些状态。操作耗时，且执行exec 后会覆盖整个子进程的虚拟地址空间，浪费大量物理内存。因此才有了COW来减少这个开销。

内核不会复制进程的整个地址空间，而是只复制其页表（即指向与父进程相同的内存页），fork 之后的父子进程的地址空间指向同样的物理内存页。

复制文件锁：访问共享文件时只有一个进程可以进程写操作

定时器：确保每个进程都有机会执行

异步IO操作：发起I/O请求的线程不等I/O操作完成，就继续执行随后的代码，I/O结果用其他方式通知发起I/O请求的程序

跟踪：在进程切换过程中对进程状态和执行情况进行监控和记录，以便分析和调试

Copy on Write机制 #

进程创建之后，操作系统分配一系列虚拟内存页，开始对所有可以访问内存页的进程标记为可读的，当一个进程尝试修改只读页的时候，操作系统创建一个独占的原始页的副本，其他的进程仍然指向原始的只读内存页。只有对副本的修改最对修改的一个进程可见。

fork() 之后，内核会把父进程的所有内存页都标记为只读。一旦其中一个进程尝试写入某个内存页，就会触发一个保护故障（缺页异常），此时会陷入内核。

内核拦截写入，并为尝试写入的进程创建这个页面的一个新副本，恢复这个页面的可写权限，然后重新执行这个写操作，这时就可以正常执行了。

内核会保留每个内存页面的引用数。每次复制某个页面后，该页面的引用数减少一；如果该页面只有一个引用，就可以跳过分配，直接修改。

这种分配过程对于进程来说是透明的，能够确保一个进程的内存更改在另一进程中不可见。

fork 之后可以不执行exec ，直接执行其他方法

KOOM Copy on Write #

Linux SuspendAll方法不会让执行SuspendAll的线程suspend（保留着一个线程）

父进程等待子进程执行完成

为什么先suspend再fork #

如果去掉 fork() 前额外添加的虚拟机暂停请求，直接让 Debug.dumpHprofData() 在子进程暂停虚拟机线程，会发现暂停虚拟机线程的调用将被一直阻塞。

因为 fork() 得出的子进程仅会保留调用 fork() 的唯一线程，而虚拟机线程暂停需要当前线程等待其它线程到达 Suspend Check Point 以通知原线程。但子进程中的其它线程已经不复存在了，等待便不会再有任何回音，因此通过在原进程提前暂停虚拟机线程，欺骗子进程对虚拟机线程状态的检测，才能保证逻辑的正常运行。

hprof #

Hprof文件格式有明确组织方式，Android在Java的基础上新增了部分Tag。

Java Hprof格式 #

Java Hprof格式

整体分为Header和Record数组两部分。

记录hprof的元信息 Hprof-Header

格式名和版本号：JAVA PROFILE 1.0.2 (18byte)
标识符大小：4byte
高位时间戳：4byte
地位时间戳：4byte

Header总共占了18 + 4 + 4 + 4 = 32byte

Record数组 #

记录各个类型对应的数据 Hprof-Record

类型(TAG)：表示Record对应的类型(1Byte)
时间戳(TIME)：发生时间(4byte)
长度(LENGTH)：记录数据的长度(4byte)
记录数据(BODY)：记录的数据(${LENGTH}Byte)

单条Record总共占了1 + 4 + 4 + LENGTH byte

支持的TAG类型 #

一级Tag #

STRING_IN_UTF8 = 0x01
LOAD_CLASS = 0x02
UNLOAD_CLASS = 0x03
STACK_FRAME = 0x04
STACK_TRACE = 0x05
ALLOC_SITES = 0x06
HEAP_SUMMARY = 0x07
START_THREAD = 0x0a
END_THREAD = 0x0b
HEAP_DUMP = 0x0c - 堆内容
CPU_SAMPLES = 0x0d
CONTROL_SETTINGS = 0x0e
HEAP_DUMP_SEGMENT = 0x1c - 堆内容
HEAP_DUMP_END = 0x2c

二级Tag #

主要位于HEAP_DUMP或HEAP_DUMP_SEGMENT中

ROOT_UNKNOWN = 0xff
ROOT_JNI_GLOBAL = 0x01
ROOT_JNI_LOCAL = 0x02
ROOT_JAVA_FRAME = 0x03
ROOT_NATIVE_STACK = 0x04
ROOT_STICKY_CLASS = 0x05
ROOT_THREAD_BLOCK = 0x06
ROOT_MONITOR_USED = 0x07
ROOT_THREAD_OBJECT = 0x08
CLASS_DUMP = 0x20
INSTANCE_DUMP = 0x21
OBJECT_ARRAY_DUMP = 0x22
PRIMITIVE_ARRAY_DUMP = 0x23：占据到80%以上

Android Hprof格式 #

Android Hprof格式

Header #

格式与Java的Header一致

Record数组 #

格式与Java的Record一致

支持的TAG类型 #

一级Tag #

STRING_IN_UTF8 = 0x01
LOAD_CLASS = 0x02
STACK_FRAME = 0x04
STACK_TRACE = 0x05
HEAP_DUMP_SEGMENT = 0x1c
HEAP_DUMP_END = 0x2c

二级Tag #

主要位于HEAP_DUMP_SEGMENT中

Java所有的二级Tag
HEAP_DUMP_INFO = 0xfe：存储的是堆空间的类型，主要有以下三种
- HEAP_ZYGOTE = 0x5A Z 系统堆空间
- HEAP_APP = 0x41 A 应用堆空间
- HEAP_IMAGE = 0x49 I 图片堆空间
ROOT_INTERNED_STRING = 0x89
ROOT_FINALIZING = 0x8a
ROOT_DEBUGGER = 0x8b
ROOT_REFERENCE_CLEANUP = 0x8c
ROOT_VM_INTERNAL = 0x8d
ROOT_JNI_MONITOR = 0x8e
ROOT_UNREACHABLE = 0x90
PRIMITIVE_ARRAY_NODATA = 0xc3

#

完整Android hprof #

查身份证的权力

Fri, 01 Nov 2024 21:00:01 +0800

查身份的权力 #

今日周五, 回家路上心情尚可. 快到小区门口时见到红蓝灯交互闪动, 心想不妙: 又他妈要查身份证. 走到门口时, 果不其然. 心中即使有不甘心仍报上身份证号码.

从小区门口走到卧室的途中越想越气. 遂查阅一番查阅身份相关规定.如下:

中华人民共和国居民身份证法

第十五条　人民警察依法执行职务，遇有下列情形之一的，经出示执法证件，可以查验居民身份证：

　　（一）对有违法犯罪嫌疑的人员，需要查明身份的；

　　（二）依法实施现场管制时，需要查明有关人员身份的；

　　（三）发生严重危害社会治安突发事件时，需要查明现场有关人员身份的；

　　（四）法律规定需要查明身份的其他情形。

　　有前款所列情形之一，拒绝人民警察查验居民身份证的，依照有关法律规定，分别不同情形，采取措施予以处理。

　　任何组织或者个人不得扣押居民身份证。但是，公安机关依照《中华人民共和国刑事诉讼法》执行监视居住强制措施的情形除外。

‍

中华人民共和国主席令第三十八号

**第五十六条**　旅馆业的工作人员对住宿的旅客不按规定登记姓名、身份证件种类和号码的，或者明知住宿的旅客将危险物质带入旅馆，不予制止的，处二百元以上五百元以下罚款。

　　旅馆业的工作人员明知住宿的旅客是犯罪嫌疑人员或者被公安机关通缉的人员，不向公安机关报告的，处二百元以上五百元以下罚款；情节严重的，处五日以下拘留，可以并处五百元以下罚款。
　　第五十七条　房屋出租人将房屋出租给无身份证件的人居住的，或者不按规定登记承租人姓名、身份证件种类和号码的，处二百元以上五百元以下罚款。
　　房屋出租人明知承租人利用出租房屋进行犯罪活动，不向公安机关报告的，处二百元以上五百元以下罚款；情节严重的，处五日以下拘留，可以并处五百元以下罚款。

‍

中华人民共和国人民警察法

第九条 为维护社会治安秩序，公安机关的人民警察对有违法犯罪嫌疑的人员，经出示相应证件，可以当场盘问、检查；经盘问、检查，有下列情形之一的，可以将其带至公安机关，经该公安机关批准，对其继续盘问：

（一）被指控有犯罪行为的；

（二）有现场作案嫌疑的；

（三）有作案嫌疑身份不明的；

（四）携带的物品有可能是赃物的。

对被盘问人的留置时间自带至公安机关之时起不超过二十四小时，在特殊情况下，经县级以上公安机关批准，可以延长至四十八小时，并应当留有盘问记录。对于批准继续盘问的，应当立即通知其家属或者其所在单位。对于不批准继续盘问的，应当立即释放被盘问人。

经继续盘问，公安机关认为对被盘问人需要依法采取拘留或者其他强制措施的，应当在前款规定的期间作出决定；在前款规定的期间不能作出上述决定的，应当立即释放被盘问人。

‍

得出结论: 警察想查就能查. 放弃幻想.

删除.gitignore中的文件

Sun, 27 Oct 2024 13:52:19 +0800

.gitignore文件中可以列举出哪些文件不希望提交到git中, 只对还没有提交的文件生效, 如果已经有文件提交了, 即使添加到.gitignore也不会起作用.这时候可以用命令:

1

git rm -r --cached file/directory

参数含义 #

rm: Remove files from the working tree and from the index.

-r: allow recursive removal

–cached: only remove from the index

京东杨笠梁文道

Fri, 25 Oct 2024 09:00:06 +0800

从我开始听"八分"这个播客节目开始就很喜欢梁文道, 原因是因为梁文道有学识, 谦虚, 又经常在节目中讨论一些观点, 绝大多数时清况下, 我对讨论的事件和观点都很感兴趣, 有许多是我没有想到过的角度.

但是, 凡事都有个但是, 最近有关京东和杨笠的一期, 实在让我不能同意. 首先, 道长(梁文道昵称)的观点认为杨笠冒犯的男士是台上一期演出的男嘉宾, 认为"普信男"说的特制这几个人, 是不是这几个人呢?我找来了杨笠的原话,是这样的说的:

“大家好, 我是杨笠, 我又来了, 跟去年一样, 我还是单身. 就是我也单身太久了吧, 我觉着自从做了这一行以后, 对我的感情生活是可以说是雪上加霜, 我真的是不懂, 我为什么会单身这么久, 我觉着很多男生可能都有点误会我了, 他们就觉得, 我天天在台上讲段子, 感觉很凶, 好像很喜欢攻击男生, 我是不是讨厌男生. 没有, 恰恰相反, 我是因为喜欢你们才攻击你们的. 真的, 我太喜欢你们了, 我喜欢你们喜欢到我都不忍心谈恋爱, 因为我没有办法在众多的你们当中选出一个. 我会想说, 像男人这么美好的东西竟然还要选. 男人不光美好, 还特别神秘, 就是你永远也猜不透, 他那小脑瓜里到底在想些什么, 就是他明明为什么看起来那么普通但是他却可以那么自信. 就是你在这个台上, 看到很多很奇形怪状的男演员, 但是我跟你说, 他们其中没有任何一个想过说我这个长相要是上电视的话是不是得稍微整容, 没有的….”

在舞台上之前的描述说的群体是所有男性, 更具体一些, 根据语境可以说是单身男性. 后面说完"普信男"之后描述了场上的男嘉宾. 前后两句的主体是不一样的, 可以有两种理解:1. 后一句话是前一句的举例; 2. 从头到尾都是在说场上的男嘉宾.

如果开始就是要说在场的男嘉宾, 显然不是要从在场的男嘉宾中找男朋友, 那开始的一句话的语境就是不对的. 所以认为后一句话是举例. 按照这样理解, “普通且自信的"自然就是泛指所有男性了. 感到被冒犯. 并不是因为什么认同, 我也不会觉着这个群体有多么好, 多么伟大, 单纯从我自身出发, 感到被冒犯, 没有被尊重.

再说"脱口秀”, 总有人说"脱口秀"是"冒犯的艺术", 冒犯是从什么时候开始和艺术联系在一起的呢? 又是为什么可以冒犯其他人? 我不认为这个这个正常的, 亦不能认同. 也不存在所谓的强者是不在意冒犯的, 是不是强者从来不是能不能被冒犯的标准和原因.

有人说你破防了(破防了肤浅的指在意了)就是说你, 这样的说法很可笑, 我骂一句什么样的人或者那里的人, 其中你是其中一个, 并附带上谁破防了就是谁,你能同意吗? 不过是为自己收到的不公找一个发泄的出口罢了, 理所当然的认为都是这样.

也不需要讨论诸如怎么别人不在意, 别人不在意是别人的事, 我在意.

我从来不为女性的处境辩解, 有很大一部分是因为男性, 又有一部分是因为女性. 男性更多时候握有更大的权力, 身处更高的位置, 这可以是让女性处在劣势的原因之一. 整个社会包括女性自己, 认为女性就要怎么怎么样, 诸如化妆之类的, 也可以是让女性处在劣势的原因之一. 前提是真的是因为性别是女性而早遭到了不公的待遇, 而不是因为别的原因. 明明是自己的原因还动不动拿自己是女性, 怎么你们都怎么怎么这种做法让我厌恶.

我总是认为无论性别, 长相, 我们都有相同的权利. 在追求, 兴趣, 爱好等等方面, 有许许多多女性做的比男性好, 这也没什么. 除了性别, 我们都是相同的, 一样是人.

国籍与文化认同

Mon, 30 Sep 2024 19:27:32 +0800

在这之前粗浅的认为一个人国籍就是一个人的符号，因此常常对“美籍华人、日籍华人”这样类似的说法感到厌恶，[ENG SUB] 曾经的“猪仔”，马来西亚华人现在过得怎么样？【食贫道】触动了我一下。

除了一个人在法律上的身份(也就是国籍)之外，背后认同的文化也是这个人的一部分。一个是法律上的定义，一个是思想上的归属。文化甚至是可以与国籍分庭抗礼的。

Android扩大点击区域

Sun, 08 Sep 2024 10:28:48 +0800

Android中常用扩大点击区域的方式是为View添加padding, 并重新计算View的尺寸. Android中提供了另一种方式: TouchDelegate

TouchDelegate #

Android TouchDelegate is a powerful tool that helps developers create a custom touch region for a View. This allows developers to extend the area of the View that responds to touch events. For example, if a View is small, developers can use TouchDelegate to increase the area that responds to touch events. This makes it easier to interact with the View and makes the user experience more seamless. The TouchDelegate class also helps developers create custom touch feedback, such as a ripple effect, when the user interacts with a View. This can make the user experience more intuitive and engaging.

用法 #

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


((View) view.getParent()).post(new Runnable() {
 @Override
 public void run() {
 Rect bounds = new Rect();
 view.setEnabled(true);
 view.getHitRect(bounds);

 bounds.top -= top;
 bounds.bottom += bottom;
 bounds.left -= left;
 bounds.right += right;
 TouchDelegate touchDelegate = new TouchDelegate(bounds, view);
 if (view.getParent() instanceof View) {
 ((View) view.getParent()).setTouchDelegate(touchDelegate);
 }
 }
 });

原理 #

为什么可以扩大区域？当View中有点击事件时首先交给TouchDelegate判断，是否在它扩大后的Rect范围内，在范围内把点击的坐标映射到target范围内后，按照正常的事件分发处理。
为什么需要写在父类中？如果在子View中写扩大子View的范围，扩大的范围甚至都不在子View的范围，怎么实现扩大呢。
~~TouchDelegate中滑动判断？~~
怎么避免被代理的子View重复处理事件？先判断TouchDelegate是否消费，若消费事件分发完成，不消费按照正常的流程。

需要注意的是一个父View中只能为一个子View设置TouchDelegate= =|||

Android快捷方式开发指南

Sun, 08 Sep 2024 10:02:20 +0800

Android 快捷方式 #

在Android系统中，快捷方式是一种非常方便的工具，可以帮助用户更快速地访问他们经常使用的应用程序或功能。用户可以在主屏幕或应用程序抽屉中创建快捷方式，并可自定义快捷方式的名称和图标。

要在主屏幕上创建快捷方式，用户可以长按应用程序图标，然后将其拖到主屏幕上。用户还可以在主屏幕上空白的位置上长按，然后选择“快捷方式”菜单，以创建快捷方式。在应用程序抽屉中，用户可以长按应用程序图标，然后将其拖到主屏幕上以创建快捷方式。

除了常规的应用程序快捷方式外，用户还可以创建联系人、网站、设置选项等其他类型的快捷方式。例如，用户可以创建一个联系人快捷方式，这样他们就可以快速拨打某个联系人的电话号码。用户还可以创建一个网站快捷方式，以便更快地访问他们最喜欢的网站。

总之，Android快捷方式是一种非常有用的工具，可以帮助用户更快速地访问他们经常使用的应用程序、联系人、网站等。通过利用快捷方式，用户可以更快地完成任务并提高他们的生产力。

以上内容通过Notion AI生成，没有什么卵用。

原生Android是抽屉的形式，打开抽屉才是所有的APP，桌面上显示的Icon都叫快捷方式，除了常规的把APP从抽屉拖到桌面这种形式，APP体统的shortcut也是可以创建一个单独的Icon，也成为快捷方式。但中国大陆的launcher普遍都是定制的，没有抽屉，更没有所谓的快捷方式。还是尝试一下.

今天主要试一下添加Shortcut，以下是具体内容：

Shortcut #

shortcut是对标iOS上的xx(忘了叫啥)。好处能让用户更快进到想看的Activity。

注册方式 #

静态注册
在AndroidManifest中的MainActivity（真正意义上的，启动后第一个Activity）中引入写好的xml文件，文件中以shortcuts作为根节点。不可以通过ShortcutManager操作静态方式添加的shortcut，会抛出异常。

提示shortcuts找不到声明是正常现象，不影响内部元素提示😒。

|动态注册||| |在Activity中通过ShortcutManager类添加、移除、禁用shortcut，没有限制一定要在MainActivity。id相同时后面的shortcut会覆盖先添加的。||| |动态注册的API通过建造者模式，传递数据也比方便。|||

	静态注册	动态注册
实现方式	在 AndroidManifest.xml 文件中引用写好的 xml 文件	通过 ShortcutManager.addDynamicShortcuts()、ShortcutManager.updateShortcuts()、ShortcutManager.removeDynamicShortcuts() 以及 ShortcutManager.removeAllDynamicShortcuts() 方法添加、更新、移除或禁用动态快捷方式
是否支持动态修改	不支持	支持
是否支持读取快捷方式	支持	支持
是否支持监听快捷方式	不支持	支持
是否支持多个快捷方式	支持	支持
应用启动时是否可用	是	否

💡 无论哪种方式，shortcutId和shortcutShortLabel都是必须的。且都要设置Action为"android.intent.action.VIEW"

Android FFmpeg编译实战

Sun, 08 Sep 2024 09:54:14 +0800

近来学习音视频, ffmpeg又是音视频中绕不开的,于是编译ffmpeg. 试了好多天, 总算摸出点规律, 记录下来给需要的朋友提供一点线索.

编译 #

从ffmpeg仓库克隆源码
安装ndk
执行编译脚本

sysroot #

sysroot被称为逻辑根目录，只在链接过程中起作用，作为交叉编译工具链搜索库文件的根路径，如配置--sysroot=dir，则dir作为逻辑根目录，链接器将在dir/usr/lib中搜索库文件。

脚本 #

ndk路径的tips：

打开Android Studio中SDK Manager，进到Android SDK Location文件夹下

再进到ndk文件夹，里面是你已经下载好的ndk，进到一个版本中，就是ndk的路径。

‍

建议将脚本保存到克隆下来的ffmpeg仓库路径中.

脚本代码：

 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
77
78


#!/bin/bash

# NDK的路径 (在bash.rc、zshrc中设置的路径，其中的NDK_HOME需要配置环境变量，如果你不配，在这改成你自己的也可以。)
NDK_HOME=~/Library/Android/sdk/ndk/25.1.8937393
# NDK_ROOT=你的NDK路径
TOOLCHAIN_PREFIX=$NDK_HOME/toolchains/llvm/prebuilt/darwin-x86_64

echo "<<<<<< FFMPEG 交叉编译 <<<<<<"
echo "<<<<<< 基于当前系统NDK地址： $NDK_HOME <<<<<<"

# 编译的相关参数 
# 目标平台的CPU指令类型 ARMv8
# armv7-a
CPU=armv8-a
# 架构类型 ： ARM
ARCH=arm64
# 操作系统
OS=android
# 平台
PLATFORM=aarch64-linux-android
OPTIMIZE_CFLAGS="-march=$CPU"

# 指定输出路径
PREFIX=~/tools/outputs/ffmpeg/aarch64/$CPU

# SYSROOT
SYSROOT=$TOOLCHAIN_PREFIX/sysroot

# 交叉编译工具链
CROSS_PREFIX=$TOOLCHAIN_PREFIX/bin/llvm-

# Android交叉编译工具链的位置
ANDROID_CROSS_PREFIX=$TOOLCHAIN_PREFIX/bin/${PLATFORM}29

echo ">>>>>> FFMPEG 开始编译 >>>>>>"

# ffmpeg所有configure
# https://github.com/FFmpeg/FFmpeg/blob/master/configure
./configure \
 --prefix=$PREFIX \
 --enable-shared \
 --enable-gpl \
 --enable-neon \
 --enable-hwaccels \
 --enable-postproc \
 --enable-jni \
 --enable-small \
 --enable-mediacodec \
 --enable-decoder=h264_mediacodec \
 --enable-ffmpeg \
 --disable-ffplay \
 --disable-ffprobe \
 --disable-ffplay \
 --disable-avdevice \
 --disable-debug \
 --disable-static \
 --disable-symver \
 --cross-prefix=$CROSS_PREFIX \
 --target-os=$OS \
 --arch=$ARCH \
 --cpu=$CPU \
 --cc=${ANDROID_CROSS_PREFIX}-clang \
 --cxx=${ANDROID_CROSS_PREFIX}-clang++ \
 --enable-cross-compile \
 --sysroot=$SYSROOT \
 --extra-cflags="-Os -fPIC $OPTIMIZE_CFLAGS" \
 --extra-ldflags="$ADDI_LDFLAGS"

make clean

# 创建目标路径,如果不存在的话，最终产物存储在Prefix对应路径之下。
mkdir -p $PREFIX

sudo make -j8

sudo make install

echo "<<<<<< 编译完成，产物存储在:$PREFIX <<<<<<"

找不到从哪抄来的了, 找到了再补上

‍

编译成功后产物的路径中生成四个文件夹, 分别是bin, include, lib, share.

文件夹	包含内容
bin	可执行文件, Android中不需要
lib	so文件
include	头文件
share	示例, 文档. 编译configure禁用了文档, 因此只有示例

‍

集成 #

Android Studio中创建native module.
将产物中的include文件夹复制到新建module的src/main/cpp文件夹下
产物lib文件夹下的so文件复制到module的src/main/jniLibs/ABI

‍

ABI取决于你编译的. 比如你编译的是arm64-v8a的, 上面的ABI就是arm64-v8a. 那么你需要的目标路径就是src/main/jniLibs/arm64-v8a

‍

CMakeLists.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


# cmake version, 创建native module升成
cmake_minimum_required(VERSION 3.22.1)

# 项目名, 创建native module升成
project("native_ffmpeg")

#引入头文件, 引入include文件夹
include_directories(include)

add_library(${CMAKE_PROJECT_NAME} SHARED
 # List C/C++ source files with relative paths to this CMakeLists.txt.
 native_ffmpeg.cpp)

# Set a normal, cache, or environment variable to a given value
# cmake官方这么写解释set, 设置变量
set(ANDROID_SO_DIR ${CMAKE_SOURCE_DIR}/../jniLibs/${ANDROID_ABI})

# add_library: Add a library to the project using the specified source files.
# set_target_properties: Sets properties on targets. The syntax for the command is to list all the targets you want to change, and then provide the values you want to set next.

# avcodec
add_library(avcodec SHARED IMPORTED)
set_target_properties(avcodec PROPERTIES IMPORTED_LOCATION ${ANDROID_SO_DIR}/libavcodec.so)

# avfilter
add_library(avfilter SHARED IMPORTED)
set_target_properties(avfilter PROPERTIES IMPORTED_LOCATION ${ANDROID_SO_DIR}/libavfilter.so)

# avformat
add_library(avformat SHARED IMPORTED)
set_target_properties(avformat PROPERTIES IMPORTED_LOCATION ${ANDROID_SO_DIR}/libavformat.so)

# avutil
add_library(avutil SHARED IMPORTED)
set_target_properties(avutil PROPERTIES IMPORTED_LOCATION ${ANDROID_SO_DIR}/libavutil.so)

# postproc
add_library(postproc SHARED IMPORTED)
set_target_properties(postproc PROPERTIES IMPORTED_LOCATION ${ANDROID_SO_DIR}/libpostproc.so)

# swresample
add_library(swresample SHARED IMPORTED)
set_target_properties(swresample PROPERTIES IMPORTED_LOCATION ${ANDROID_SO_DIR}/libswresample.so)

# swscale
add_library(swscale SHARED IMPORTED)
set_target_properties(swscale PROPERTIES IMPORTED_LOCATION ${ANDROID_SO_DIR}/libswscale.so)

# Specify libraries or flags to use when linking a given target and/or its dependents.
# 还是cmake官方的解释
target_link_libraries(${CMAKE_PROJECT_NAME}
 # List libraries link to the target library
 android
 log
 # ffmpeg libs
 avcodec
 avfilter
 avformat
 avutil
 postproc
 swresample
 swscale)

命令详情参考:

Android NDK开发基础NDK即Native Development Kit，是Android上用来开发c/c++ - 掘金

CMake Tutorial — CMake 3.30.3 Documentation

‍

最后, 点击Android Studio上的小锤子开始build, 完成在module的build/outputs/aar中看到aar.

‍

调用 #

编辑JNI文件

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


#include <jni.h>
#include <string>

// CPP中添加C的头文件
extern "C" {
#include <libavcodec/avcodec.h>
}

extern "C" JNIEXPORT jstring JNICALL
Java_com_example_native_1ffmpeg_NativeLib_stringFromJNI(
 JNIEnv *env,
 jobject /* this */) {
 return env->NewStringUTF(avcodec_configuration());
}

懒人提示: 先写Java native方法或者Kotlin external方法由IDE提示生成CPP文件更方便

‍

依赖ffmpeg模块

1
2
3


dependencies {
	implementation(project(":native-ffmpeg"))
}

Activity:

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


class MainActivity : AppCompatActivity() {
 override fun onCreate(savedInstanceState: Bundle?) {
 super.onCreate(savedInstanceState)
 enableEdgeToEdge()
 setContentView(R.layout.activity_main)
 ViewCompat.setOnApplyWindowInsetsListener(findViewById(R.id.main)) { v, insets ->
 val systemBars = insets.getInsets(WindowInsetsCompat.Type.systemBars())
 v.setPadding(systemBars.left, systemBars.top, systemBars.right, systemBars.bottom)
 insets
 }

		// Return the libavcodec build-time configuration
 findViewById<TextView>(R.id.tv_greeting).setText(NativeLib().stringFromJNI())
 }
}

‍

Android Studio禁用富文本复制

Tue, 06 Aug 2024 07:12:57 +0800

富文本(rich text)和纯文本(plain text)

plain text format contains no formatting information, rich text format includes formatting details such as font size, style, color, and other elements like images, tables, and links.

Android Studio(Idea)中复制代码默认复制的是富文本(rich text),需要从 Android Studio 中复制出代码整理文档时不胜其烦.

记录下关掉默认复制富文本的设置,帮助有同样困扰的朋友.

面向过程和面向对象

Sun, 04 Aug 2024 16:50:33 +0800

小弟以为差别已经体现在了名字上，顾名思义，面向过程即关注点在过程上，通过组合不同的函数（方法）实现某种功能；而面向对象关注点在对象（实例）上，由一个或多个对象的方法，借助属性，共同实现。至于其他的都是上面的差异更具体的表现，而不是原因。

TextView setText发生了什么？

Sun, 28 Jul 2024 09:09:32 +0800

前置知识 #

Span #

既然是setText，想必你一定听过Span的大名，借助Span和SpannableString就可以让文字不光是文字，文字颜色、背景颜色、文字点击、链接还可以自定义更复杂的效果，

MovementMethod #

文字上的点击、光标选中都是由它实现的，详细的之后单独写。

Editor #

和编辑文字相关，之后也单独写。

mTransformation #

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


 /**
 * Sets the transformation that is applied to the text that this
 * TextView is displaying.
 *
 * @attr ref android.R.styleable#TextView_password
 * @attr ref android.R.styleable#TextView_singleLine
 */
 public final void setTransformationMethod(TransformationMethod method) {
 if (mEditor != null) {
 mEditor.setTransformationMethod(method);
 } else {
 setTransformationMethodInternal(method);
 }
 }

BufferType #

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


// definition
@UnsupportedAppUsage
private BufferType mBufferType = BufferType.NORMAL;
 
 
/**
 * Type of the text buffer that defines the characteristics of the text such as static,
 * styleable, or editable.
 */
public enum BufferType {
 NORMAL, SPANNABLE, EDITABLE
}

正文 #

作为Android中最基本的控件，TextView简直是无处不在，最最常用的用法像是textView.setText("test")，无论是传入String，还是SpannableString都能显示，为什么能起作用？

从setText方法找到方法实现：

1
2
3


public final void setText(CharSequence text) {
 setText(text, mBufferType);
 }

嗯？CharSequence?

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


public class String : Comparable<String>, CharSequence{
 ...
}

expect class StringBuilder : Appendable, CharSequence {
 ...
}

public class SpannableString
extends SpannableStringInternal
implements CharSequence, GetChars, Spannable
{
 ...
}

Android中String和StringBuilder都是CharSequence的子类。

mBufferType又是什么东西？先不管它，接着往下找。

 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


/**
 * Sets the text to be displayed and the {@link android.widget.TextView.BufferType}.
 * <p/>
 * When required, TextView will use {@link android.text.Spannable.Factory} to create final or
 * intermediate {@link Spannable Spannables}. Likewise it will use
 * {@link android.text.Editable.Factory} to create final or intermediate
 * {@link Editable Editables}.
 *
 * Subclasses overriding this method should ensure that the following post condition holds,
 * in order to guarantee the safety of the view's measurement and layout operations:
 * regardless of the input, after calling #setText both {@code mText} and {@code mTransformed}
 * will be different from {@code null}.
 *
 * @param text text to be displayed
 * @param type a {@link android.widget.TextView.BufferType} which defines whether the text is
 * stored as a static text, styleable/spannable text, or editable text
 *
 * @see #setText(CharSequence)
 * @see android.widget.TextView.BufferType
 * @see #setSpannableFactory(Spannable.Factory)
 * @see #setEditableFactory(Editable.Factory)
 *
 * @attr ref android.R.styleable#TextView_text
 * @attr ref android.R.styleable#TextView_bufferType
 */
public void setText(CharSequence text, BufferType type) {
 setText(text, type, true, 0);

 // drop any potential mCharWrappper leaks
 mCharWrapper = null;
}

又是嵌套，从上面的代码注释中知道了两点：

text是传入的文字内容；
type定义展示文字类型。

private void setText(CharSequence text, BufferType type,boolean notifyBefore, int oldlen) 聪明的你从名字上一定看出了一些什么，notifyBefore大概率是要不要调用callback了，oldlen是长度。在看代码实现前，你没有疑问吗？即使setText传入SpannableString，type我们可没改，也就是说用的是默认的，里面一定有判断text类型的逻辑。去代码里找答案。（大量代码预警）

 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
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187


private void setText(CharSequence text, BufferType type,
 boolean notifyBefore, int oldlen) {
 mTextSetFromXmlOrResourceId = false;
 if (text == null) {
 text = "";
 }
 // 移除SuggestionSpan，类似Word中拼写检查
 // If suggestions are not enabled, remove the suggestion spans from the text
 if (!isSuggestionsEnabled()) {
 text = removeSuggestionSpans(text);
 }
 if (!mUserSetTextScaleX) mTextPaint.setTextScaleX(1.0f);
 // 跑马灯效果
 if (text instanceof Spanned
 && ((Spanned) text).getSpanStart(TextUtils.TruncateAt.MARQUEE) >= 0) {
 if (ViewConfiguration.get(mContext).isFadingMarqueeEnabled()) {
 setHorizontalFadingEdgeEnabled(true);
 mMarqueeFadeMode = MARQUEE_FADE_NORMAL;
 } else {
 setHorizontalFadingEdgeEnabled(false);
 mMarqueeFadeMode = MARQUEE_FADE_SWITCH_SHOW_ELLIPSIS;
 }
 setEllipsize(TextUtils.TruncateAt.MARQUEE);
 }
 // 按照mFilters过滤文字
 int n = mFilters.length;
 for (int i = 0; i < n; i++) {
 CharSequence out = mFilters[i].filter(text, 0, text.length(), EMPTY_SPANNED, 0, 0);
 if (out != null) {
 text = out;
 }
 }
 // 方法中第三个参数起作用
 if (notifyBefore) {
 if (mText != null) {
 oldlen = mText.length();
 sendBeforeTextChanged(mText, 0, oldlen, text.length());
 } else {
 sendBeforeTextChanged("", 0, 0, text.length());
 }
 }
 boolean needEditableForNotification = false;
 if (mListeners != null && mListeners.size() != 0) {
 needEditableForNotification = true;
 }
 // TextView文字排版相关
 PrecomputedText precomputed =
 (text instanceof PrecomputedText) ? (PrecomputedText) text : null;
 // 可以编辑的内容重置状态，deep copy，最重要的是初始化Editor，后面用到。
 if (type == BufferType.EDITABLE || getKeyListener() != null
 || needEditableForNotification) {
 createEditorIfNeeded();
 mEditor.forgetUndoRedo();
 mEditor.scheduleRestartInputForSetText();
 Editable t = mEditableFactory.newEditable(text);
 text = t;
 setFilters(t, mFilters);
 } else if (precomputed != null) {
 if (mTextDir == null) {
 mTextDir = getTextDirectionHeuristic();
 }
 final boolean autoPhraseBreaking =
 !mUserSpeficiedLineBreakwordStyle && FeatureFlagUtils.isEnabled(mContext,
 FeatureFlagUtils.SETTINGS_AUTO_TEXT_WRAPPING);
 final @PrecomputedText.Params.CheckResultUsableResult int checkResult =
 precomputed.getParams().checkResultUsable(getPaint(), mTextDir, mBreakStrategy,
 mHyphenationFrequency, LineBreakConfig.getLineBreakConfig(
 mLineBreakStyle, mLineBreakWordStyle, autoPhraseBreaking));
 switch (checkResult) {
 case PrecomputedText.Params.UNUSABLE:
 throw new IllegalArgumentException(
 "PrecomputedText's Parameters don't match the parameters of this TextView."
 + "Consider using setTextMetricsParams(precomputedText.getParams()) "
 + "to override the settings of this TextView: "
 + "PrecomputedText: " + precomputed.getParams()
 + "TextView: " + getTextMetricsParams());
 case PrecomputedText.Params.NEED_RECOMPUTE:
 precomputed = PrecomputedText.create(precomputed, getTextMetricsParams());
 break;
 case PrecomputedText.Params.USABLE:
 // pass through
 }
 } else if (type == BufferType.SPANNABLE || mMovement != null) {
 // SPANNABLE deep copy
 text = mSpannableFactory.newSpannable(text);
 } else if (!(text instanceof CharWrapper)) {
 text = TextUtils.stringOrSpannedString(text);
 }
 @AccessibilityUtils.A11yTextChangeType int a11yTextChangeType = AccessibilityUtils.NONE;
 if (AccessibilityManager.getInstance(mContext).isEnabled()) {
 a11yTextChangeType = AccessibilityUtils.textOrSpanChanged(text, mText);
 }
 // 设置autolink更新type
 if (mAutoLinkMask != 0) {
 Spannable s2;
 if (type == BufferType.EDITABLE || text instanceof Spannable) {
 s2 = (Spannable) text;
 } else {
 s2 = mSpannableFactory.newSpannable(text);
 }
 if (Linkify.addLinks(s2, mAutoLinkMask)) {
 text = s2;
 type = (type == BufferType.EDITABLE) ? BufferType.EDITABLE : BufferType.SPANNABLE;
 /*
 * We must go ahead and set the text before changing the
 * movement method, because setMovementMethod() may call
 * setText() again to try to upgrade the buffer type.
 */
 setTextInternal(text);
 if (a11yTextChangeType == AccessibilityUtils.NONE) {
 a11yTextChangeType = AccessibilityUtils.PARCELABLE_SPAN;
 }
 // Do not change the movement method for text that support text selection as it
 // would prevent an arbitrary cursor displacement.
 if (mLinksClickable && !textCanBeSelected()) {
 setMovementMethod(LinkMovementMethod.getInstance());
 }
 }
 }
 // 更新BufferType
 mBufferType = type;
 // 更新文字
 setTextInternal(text);
 // 像是把密码替换成*的文字处理类
 if (mTransformation == null) {
 mTransformed = text;
 } else {
 mTransformed = mTransformation.getTransformation(text, this);
 }
 if (mTransformed == null) {
 // Should not happen if the transformation method follows the non-null postcondition.
 mTransformed = "";
 }
 final int textLength = text.length();
 final boolean isOffsetMapping = mTransformed instanceof OffsetMapping;
 // !!!更新Span
 if (text instanceof Spannable && (!mAllowTransformationLengthChange || isOffsetMapping)) {
 Spannable sp = (Spannable) text;
 // Remove any ChangeWatchers that might have come from other TextViews.
 final ChangeWatcher[] watchers = sp.getSpans(0, sp.length(), ChangeWatcher.class);
 final int count = watchers.length;
 for (int i = 0; i < count; i++) {
 sp.removeSpan(watchers[i]);
 }
 if (mChangeWatcher == null) mChangeWatcher = new ChangeWatcher();
 sp.setSpan(mChangeWatcher, 0, textLength, Spanned.SPAN_INCLUSIVE_INCLUSIVE
 | (CHANGE_WATCHER_PRIORITY << Spanned.SPAN_PRIORITY_SHIFT));
 if (mEditor != null) mEditor.addSpanWatchers(sp);
 if (mTransformation != null) {
 final int priority = isOffsetMapping ? OFFSET_MAPPING_SPAN_PRIORITY : 0;
 sp.setSpan(mTransformation, 0, textLength, Spanned.SPAN_INCLUSIVE_INCLUSIVE
 | (priority << Spanned.SPAN_PRIORITY_SHIFT));
 }
 if (mMovement != null) {
 mMovement.initialize(this, (Spannable) text);
 /*
 * Initializing the movement method will have set the
 * selection, so reset mSelectionMoved to keep that from
 * interfering with the normal on-focus selection-setting.
 */
 if (mEditor != null) mEditor.mSelectionMoved = false;
 }
 }
 if (mLayout != null) {
 checkForRelayout();
 }
 sendOnTextChanged(text, 0, oldlen, textLength);
 onTextChanged(text, 0, oldlen, textLength);
 mHideHint = false;
 if (a11yTextChangeType == AccessibilityUtils.TEXT) {
 notifyViewAccessibilityStateChangedIfNeeded(
 AccessibilityEvent.CONTENT_CHANGE_TYPE_TEXT);
 } else if (a11yTextChangeType == AccessibilityUtils.PARCELABLE_SPAN) {
 notifyViewAccessibilityStateChangedIfNeeded(
 AccessibilityEvent.CONTENT_CHANGE_TYPE_UNDEFINED);
 }
 if (needEditableForNotification) {
 sendAfterTextChanged((Editable) text);
 } else {
 notifyListeningManagersAfterTextChanged();
 }
 if (mEditor != null) {
 // SelectionModifierCursorController depends on textCanBeSelected, which depends on text
 mEditor.prepareCursorControllers();
 mEditor.maybeFireScheduledRestartInputForSetText();
 }
}

乍一看setTextInternal像是更新文字的，点进去才发现是更新变量的。又一看mMovement.initialize(this, (Spannable) text)也很像，点进去发现又是重置状态的。大失所望，又一想文字改变的callback还没看呢！ sendOnTextChanged还是onTextChanged呢，一看sendOnTextChanged有内容而onTextChanged是空实现，那就是sendOnTextChanged。很遗憾虽然有callback，但也不是。

从Span入手 #

ForegroundColorSpan起作用一定要调用什么方法，ForegroundColorSpan和BackgroundColorSpan同时是抽象类CharacterStyle的子类，updateDrawState方法是需要重写的，依我看十有八九是它。

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


for (int j = 0; j < mMetricAffectingSpanSpanSet.numberOfSpans; j++) {
 // Both intervals [spanStarts..spanEnds] and [mStart + i..mStart + mlimit] are NOT
 // empty by construction. This special case in getSpans() explains the >= & <= tests
 if ((mMetricAffectingSpanSpanSet.spanStarts[j] >= mStart + mlimit)
 || (mMetricAffectingSpanSpanSet.spanEnds[j] <= mStart + i)) continu
 boolean insideEllipsis =
 mStart + mEllipsisStart <= mMetricAffectingSpanSpanSet.spanStarts[j]
 && mMetricAffectingSpanSpanSet.spanEnds[j] <= mStart + mEllipsisEnd;
 final MetricAffectingSpan span = mMetricAffectingSpanSpanSet.spans[j];
 if (span instanceof ReplacementSpan) {
 replacement = !insideEllipsis ? (ReplacementSpan) span : null;
 } else {
 // We might have a replacement that uses the draw
 // state, otherwise measure state would suffice.
 span.updateDrawState(wp);
 }
}

验证了上面猜测。但是，Span可以点击呢，当然没有忘记在LinkMovementMethod中实现。

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


case CLICK:
 if (selStart == selEnd) {
 return false;

 ClickableSpan[] links = buffer.getSpans(selStart, selEnd, ClickableSpan.class
 if (links.length != 1) {
 return false;

 ClickableSpan link = links[0];
 if (link instanceof TextLinkSpan) {
 ((TextLinkSpan) link).onClick(widget, TextLinkSpan.INVOCATION_METHOD_KEYBOARD);
 } else {
 link.onClick(widget);
 }
 break;

WeakReference解决内存泄漏

Fri, 28 Jun 2024 21:37:09 +0800

内存泄漏是经常会遇到的问题，内存泄漏简单说就是已经分配出去的内存，不再使用时没有被正确释放，不能再次分配。代码中内存泄漏问题本质就是长生命周期的对象持有了短生命周期的对象，短生命周期对象不能被销毁。内存泄漏严重时会导致OOM。

Java中的有四种内存，常用的分别是强引用、软引用和弱引用（Kotlin也是）。强引用不用多说，只要是通过new关键字创建的对象都是，无论什么时候JVM都不会回收强引用，宁可触发OOM。

被SoftReference包住的称为软引用，像是SoftReference<new Object()>的形式，内存不够时会回收掉只有软引用的对象(一个对象只被软引用)。

弱引用和软引用的形式类似，弱引用的软件词：WeakReference，GC时发现只有弱引用的对象(一个对象只被弱引用)会立马回收。

上面的描述和其他博客的看起来没有太大的差别，除了加粗的”只有“，关键页正是”只有“。

举例：

 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


public class DemoActivity extends AppCompatActivity {
 @Override
 protected void onCreate(@Nullable Bundle savedInstanceState) {
 super.onCreate(savedInstanceState);

 SomethingManager.getInstance().setsSomethingListener(new SomethingManager.SomethingListener() {
 @Override
 public void doSomething() {
 // do something
 }
 });
 }
}


class SomethingManager {
 static SomethingManager sSomethingManager;

 public static SomethingManager getInstance() {
 if (sSomethingManager == null) {
 sSomethingManager = new SomethingManager();
 }
 return sSomethingManager;
 }

 private SomethingListener sSomethingListener;

 public void setsSomethingListener(SomethingListener sSomethingListener) {
 this.sSomethingListener = sSomethingListener;
 }
 
 
 void run(){
 sSomethingListener.doSomething();
 }

 interface SomethingListener {
 void doSomething();
 }

写一个最简单的例子，一个单例对象持有一个listener，理想的情况当然是Activity销毁的时候移除listener。总会有不理想的人忘记了，当Activity销毁时就发生了内容泄漏：长生命周期的对象引用了段生命周期的对象。用弱引用解决：

 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


public class DemoActivity extends AppCompatActivity {
 private SomethingManager.SomethingListener mSomethingListener = new SomethingManager.SomethingListener() {
 @Override
 public void doSomething() {
 // do something
 }
 };

 @Override
 protected void onCreate(@Nullable Bundle savedInstanceState) {
 super.onCreate(savedInstanceState);

 SomethingManager.getInstance().setsSomethingListener(new WeakReference<>(mSomethingListener));
 }
}


class SomethingManager {
 static SomethingManager sSomethingManager;

 public static SomethingManager getInstance() {
 if (sSomethingManager == null) {
 sSomethingManager = new SomethingManager();
 }
 return sSomethingManager;
 }

 private WeakReference<SomethingListener> sSomethingListener;

 public void setsSomethingListener(WeakReference<SomethingListener> sSomethingListener) {
 this.sSomethingListener = sSomethingListener;
 }

 void run() {
 SomethingListener somethingListener = sSomethingListener.get();
 if (somethingListener != null) {
 somethingListener.doSomething();
 }
 }

 interface SomethingListener {
 void doSomething();
 }
}

与刚才的代码有两处不同：

DemoActivity中新增了SomethingListener类型的成员变量；
以弱引用的形式传入SomethingListener实例；

只持有弱引用的对象被GC发现会被立即回收，为了防止被回收，增加一个强引用类型的成员变量，当DemoActivity示例被回收后，强引用对象不存在了，这时候SomethingListener对象只在SomethingManager中有一个弱引用对象，GC时就会回收，因此解决了内存泄漏问题。

20240527-20240531

Sat, 01 Jun 2024 09:53:50 +0800

这一周累死累活，熬到了周六，期间发现了自身存在的一些问题：

Coding #

任务不清晰

一周都在缝缝补补，临近ddl还是不知道还有些完成了，哪些没完成

原因有几个：
- 事前没拆分
- 事中没记录
- 事后没总结
措施：
- 事前拆分任务，列表格
- 过程中更新表格，做记录同时追踪进度
总是把任务想的简单

原因：
- 一部分原因是因为第一条，也有一部分是因为没有认真思考，着急给他人回复
措施：
- 不要着急，着急解决不了问题，还容易出更多问题
- 不能当场给出的，晚点给

为人处世 #

谦逊

厉害的同事不仅是写代码厉害，与人沟通也是一样，有人寻求帮助时，用两种不同的态度回应，最后的结果可能是一样的，都需要我完成某些任务，对其他人的感受是不同的
抛出问题

过程中，难免遇到问题，不一定是因为我的能力不足导致的，可能是对接的同事或者技术问题导致。及时对齐，自己不能解决的问题push montor或者leader及时解决
不要畏惧与人沟通

害怕和人沟通只会拖延，最后还是比避免不了，就算说错了也没关系
描述背景

先让人了解发生的背景，清晰对方需要做什么，神之我提出的解决方案不一定是最好的，有助于更好的方案解决问题。

gravity和layout_gravity

Sat, 27 Apr 2024 19:52:30 +0800

背景 #

从开始写Android不断地有人告诉我，用gravity和layout_gravity控制View的位置，总是不明白两者有什么差别（中途明白过，又忘了😭），又是怎么实现的，最近想起来，赶紧查一查。

实现 #

首先gravity和layout_gravity都是View的一个属性，一直以为（没错，又是以为）类似height和width类似的，每个View都会有的，其实细想一下不是每个View都有。

gravity #

TextView是有gravity的：

 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


// 解析属性
...
case com.android.internal.R.styleable.TextView_gravity:
 setGravity(a.getInt(attr, -1));
...
 
// 赋值
public void setGravity(int gravity) {
 ...
 mGravity = gravity;
 ...
}

// mGravity定义及默认值
private int mGravity = Gravity.TOP | Gravity.START;

// View中能起作用一定是跟测量有关，找到相关代码
public int getExtendedPaddingTop() {
 ...
 final int gravity = mGravity & Gravity.VERTICAL_GRAVITY_MASK;
 if (gravity == Gravity.TOP) {
 return top;
 } else if (gravity == Gravity.BOTTOM) {
 return top + viewht - layoutht;
 } else { // (gravity == Gravity.CENTER_VERTICAL)
 return top + (viewht - layoutht) / 2;
 }
 ...
}

layout_gravity #

layout_gravity哪有呢，LinearLayout：

1

gravity = a.getInt(com.android.internal.R.styleable.LinearLayout_Layout_layout_gravity, -1);

LinearLayout中布局子View的代码。

 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


void layoutVertical(int left, int top, int right, int bottom) {
...
int gravity = lp.gravity;
if (gravity < 0) {
 gravity = minorGravity;
}
final int layoutDirection = getLayoutDirection();
final int absoluteGravity = Gravity.getAbsoluteGravity(gravity, layoutDirection);
switch (absoluteGravity & Gravity.HORIZONTAL_GRAVITY_MASK) {
 case Gravity.CENTER_HORIZONTAL:
 childLeft = paddingLeft + ((childSpace - childWidth) / 2) + lp.leftMargin - lp.rightMargin;
 break;

 case Gravity.RIGHT:
 childLeft = childRight - childWidth - lp.rightMargin;
 break;

 case Gravity.LEFT:
 default:
 childLeft = paddingLeft + lp.leftMargin;
 break;
}

...
}

恰好LinearLayout中也有用到gravity

1
2
3
4
5


// 取到gravity
index = a.getInt(com.android.internal.R.styleable.LinearLayout_gravity, -1);
if (index >= 0) {
 setGravity(index);
}

在设置baselineAligned为true时，gravity才会发挥作用。

Gravity #

Standard constants and tools for placing an object within a potentially larger container. 上面是源码中官方的注释。

可以发现代码中设置Gravity的地方用到了Gravity类，比较好理解Gravity类就是官方提供的一个工具类，让Gravity中每个属性代表的值统一。

总结 #

gravity和layout_gravity和那个View没有关系，你想自定义View的时候实现也可以用；
gravity是控制View内部的内容从哪里开始放置，一般用在View上；
layout_gravity是控制子View怎么布局，一般用在ViewGroup上；
只要你想怎么实现都行。

破解Android绘制常见误区

Sat, 27 Apr 2024 16:56:51 +0800

背景 #

需求涉及到创建View，要求能在指定位置创建View。

在此之前的理解是需要等到View attach到window上才能获取到View的宽高。按照这种思路，先创建一个View，添加到父View，再调整View的位置，尝试后效果不是很理想，会有View位置的变化，视觉上看有闪烁的效果。

尝试通过ChatGPT解决，有了以下对话：

与ChatGPT的问话

View的绘制是可以在外部调用的，方法声明public。所以，View设置内容后可以调用一遍measure方法以确定大小。

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


private fun fixedPosition(view: View) {
 view.layoutParams = FrameLayout.LayoutParams(
 ViewGroup.LayoutParams.WRAP_CONTENT,
 ViewGroup.LayoutParams.WRAP_CONTENT
 )
 view.measure(
 View.MeasureSpec.UNSPECIFIED,
 View.MeasureSpec.UNSPECIFIED
 )
 val viewWidth = view.measuredWidth
 val viewHeight = view.measuredHeight

 val layoutParams = FrameLayout.LayoutParams(
 FrameLayout.LayoutParams.WRAP_CONTENT, // 宽度
 FrameLayout.LayoutParams.WRAP_CONTENT // 高度
 ).apply {
 marginStart = (x - viewWidth / 2).toInt() // 左边界坐标
 topMargin = (y - viewHeight / 2).toInt() // 上边界坐标
 }
 view.layoutParams = layoutParams
}

事后反思是因为先入为主的观念，认为既然View的绘制发生在View内部，就不能允许在外部调用。至于是不是这样，没有深入研究，值得注意。

Android资源匹配规则详解

Sat, 27 Apr 2024 16:48:29 +0800

总是不明白Android运行时使用哪个资源，资源匹配的规则是什么样的，找到对应文档，以此记录。下方内容copy自官方文档，可直接访问查看。

表 2 按优先级顺序列出了有效的配置限定符您可以通过使用短划线分隔每个限定符，从而向一个目录名称添加多个限定符。如果对资源目录使用多个限定符，则必须按照表中所列顺序将相应限定符添加到目录名称中。

表 2. 配置限定符名称。

配置	限定符值	说明
MCC 和 MNC	示例： `mcc310` `mcc310-mnc004` `mcc208-mnc00`	移动设备国家/地区代码 (MCC)，（可选）后跟设备 SIM 卡中的移动网络代码 (MNC)。例如，`mcc310` 是指美国的任一运营商，`mcc310-mnc004` 是指美国的 Verizon 公司，而 `mcc208-mnc00` 是指法国的 Orange 公司。如果设备使用无线电连接（即为 GSM 手机），则 MCC 和 MNC 值来自 SIM 卡。您也可以单独使用 MCC，例如，将国家/地区特定的合法资源加入应用。如果只需根据语言指定，则改用语言、脚本（可选）和区域（可选）限定符（稍后进行介绍）。如果使用 MCC 和 MNC 限定符，请谨慎执行此操作并测试限定符是否按预期工作。另请参阅配置字段 `[mcc](https://developer.android.google.cn/reference/android/content/res/Configuration?hl=zh-cn#mcc)` 和 `[mnc](https://developer.android.google.cn/reference/android/content/res/Configuration?hl=zh-cn#mnc)`，二者分别表示当前的移动设备国家/地区代码和移动网络代码。
语言、脚本（可选）和区域（可选）	示例： `en` `fr` `en-rUS` `fr-rFR` `fr-rCA` `b+en` `b+en+US` `b+es+419` `b+zh+Hant` `b+sr+Latn+RS`	语言通过由两个字母组成的 ISO 639-1 语言代码进行定义，可以选择后跟两个字母组成的 ISO 3166-1-alpha-2 区域码（前缀用小写字母 `r`）。这些代码不区分大小写。`r` 前缀用于区分区域码。您不能单独指定区域。 Android 7.0（API 级别 24）引入对 BCP 47 语言标记的支持，可供您用来限定特定于语言和区域的资源。语言标记由一个或多个子标记序列组成，每个子标记都能优化或缩小由整体标记标识的语言范围。如需了解有关语言标记的详细信息，请参阅用于标识语言的标记。如要使用 BCP 47 语言标记，请将 `b+` 和两个字母的 ISO 639-1 语言代码串联；其后还可选择使用其他子标记，用 `+` 分隔即可。如果用户在系统设置中更改语言，则语言标记可能会在应用的生命周期中发生变更。如需了解这会在运行时期间给应用带来哪些影响，请参阅处理配置更改。如需查看将应用本地化为其他语言的完整指南，请参阅本地化您的应用。另请参阅 `[getLocales()](https://developer.android.google.cn/reference/android/content/res/Configuration?hl=zh-cn#getLocales())` 方法，了解该方法提供的已定义语言区域列表。此列表包含主要的语言区域。
布局方向	`ldrtl` `ldltr`	应用的布局方向。`ldrtl` 是指“布局方向从右到左”。`ldltr` 是指“布局方向从左到右”（默认的隐式值）。此配置适用于布局、可绘制对象或值等任何资源。例如，如需针对阿拉伯语提供某种特定布局，并针对任何其他“从右到左”的语言（例如波斯语或希伯来语）提供某种通用布局，则可使用以下目录： `res/` `layout/` `main.xml`（默认布局） `layout-ar/` `main.xml`（阿拉伯语的特定布局） `layout-ldrtl/` `main.xml`（阿拉伯语以外的任何从右到左的语言，因为“ar”语言限定符的优先级较高）注意：如要为应用启用从右到左的布局功能，则必须将 `SupportsRtl` 设置为 `"true"`，并将 `TargetSdkVersion` 设置为 17 或更高版本。此项为 API 级别 17 中的新增配置。
最小宽度	`sw<N>dp` 示例： `sw320dp` `sw600dp` `sw720dp` 等等	应用可用屏幕区域的最短尺寸。具体而言，应用窗口的 `smallestWidth` 是窗口可用高度和宽度的最小尺寸。您也可将其视为窗口的“最小可能宽度”。您可使用此限定符，让应用界面的可用宽度至少为 `<N>` dp。例如，如果布局要求屏幕区域的最小尺寸始终至少为 600 dp，则可使用此限定符在 `res/layout-sw600dp/` 目录中创建布局资源。仅当可用屏幕的最小尺寸至少为 600 dp（无论 600 dp 表示的边是用户所认为的高度还是宽度）时，系统才会使用这些资源。调整窗口大小（更改可用宽度/高度）或重新定位（可能会更改系统边衬区）时，最小宽度可能会改变。使用最小宽度确定一般屏幕尺寸非常有用，因为宽度通常是设计布局时的驱动因素。界面通常是竖直滚动的，但其在水平方向上所需的最小空间则相对有很多的限制。可用宽度也是确定是否针对手机使用单窗格布局，或针对平板电脑使用多窗格布局的关键因素。因此，您可能最关注每台设备上的最小可能宽度。设备的最小宽度会将屏幕装饰元素和系统界面考虑在内。例如，如果设备屏幕上的永久性界面元素沿着最小宽度轴占据空间，则系统会声明最小宽度小于实际屏幕尺寸，因为这些屏幕像素不适用于您的界面。以下是一些可用于常见屏幕尺寸的值： - 320，适用于屏幕配置如下的设备： - 240x320 ldpi（QVGA 手机） - 320x480 mdpi（手机） - 480x800 hdpi（高密度手机） - 480，适用于 480x800 mdpi 之类的屏幕（平板电脑/手机） - 600，适用于 600x1024 mdpi 之类的屏幕（7 英寸平板电脑） - 720，适用于 720x1280 mdpi 之类的屏幕（10 英寸平板电脑）当应用为多个资源目录提供不同的 `smallestWidth` 限定符值时，系统会使用最接近（但未超出）设备 `smallestWidth` 的值。此项为 API 级别 13 中的新增配置。另请参阅 `android:requiresSmallestWidthDp` 属性（声明与应用兼容的最小 `smallestWidth`）和 `[smallestScreenWidthDp](https://developer.android.google.cn/reference/android/content/res/Configuration?hl=zh-cn#smallestScreenWidthDp)` 配置字段（存放设备的 `smallestWidth` 值）。如需详细了解如何使用此限定符针对不同的屏幕进行设计，请参阅支持不同的屏幕尺寸。
可用宽度和高度	`w<N>dp` `h<N>dp` 示例： `w720dp` `w1024dp` `h720dp` `h1024dp` 等等	指定资源使用的最小可用屏幕宽度或高度（以 `dp` 为单位，由 `<N>` 值定义）。当设备屏幕方向在横屏和竖屏之间切换时、设备折叠或展开时或者系统进入或退出多窗口模式时，系统会将这些配置值与当前的显示宽度和高度进行比较。在多窗口模式下，这些值反映的是包含应用的窗口的宽度和高度，而不是设备屏幕的宽度和高度。同样，对于嵌入的 activity，该值与各个 activity 的宽度和高度（而非屏幕的宽度和高度）。如需了解详情，请参阅 activity 嵌入。可用宽度和高度通常有助于确定是否使用多窗格布局，因为即使是在平板电脑设备上，您通常也不希望在竖屏模式下像横屏模式那样使用多窗格布局。因此，您可以使用这些限定符来指定布局所需的最小宽度和/或高度，而无需同时使用屏幕尺寸和屏幕方向限定符。当应用为这些配置提供具有不同值的多个资源目录时，系统会使用最接近（但未超出）设备当前屏幕宽度的值。系统将实际屏幕宽度与指定宽度之间的差值和实际屏幕高度与指定高度之间的差值相加（未指定的高度和宽度值为 0），以确定最接近的目录。该值会排除窗口边衬区占据的区域，因此，如果设备显示屏的边缘具有永久性界面元素，则宽度和高度值会小于实际屏幕尺寸（即使应用使用 `Window.setDecorFitsSystemWindows` 或 `WindowCompat.setDecorFitsSystemWindows` 以边缘对齐的方式显示）。部分非固定的竖屏装饰（例如可在全屏模式下可隐藏的手机状态栏）和窗口装饰（例如标题栏或操作栏）不在考虑范围之内，因此应用必须准备好处理稍小于其指定值的空间。注意：系统会选择宽度和高度均匹配的资源。因此，强烈建议您同时指定这两种资源，而不是仅指定其中一种资源。例如，如果实际屏幕为 w720dp 乘以 h1280dp，并且其中一个资源符合 w720dp 的条件，另一个资源符合 w700dp-h1200dp 的条件，即使前一个资源与其指定的资源完全匹配，系统也会选择后者。此项为 API 级别 13 中的新增配置。另请参阅 `[screenWidthDp](https://developer.android.google.cn/reference/android/content/res/Configuration?hl=zh-cn#screenWidthDp)` 和 `[screenHeightDp](https://developer.android.google.cn/reference/android/content/res/Configuration?hl=zh-cn#screenHeightDp)` 配置字段，这些字段用于保存当前屏幕的宽度和高度。如需详细了解如何使用此限定符针对不同的屏幕进行设计，请参阅支持不同的屏幕尺寸。
屏幕尺寸	`small` `normal` `large` `xlarge`	- `small`：尺寸类似于低密度 QVGA 屏幕的屏幕。小屏幕的最小布局尺寸约为 320x426 dp。例如，QVGA 低密度屏幕和 VGA 高密度屏幕。 - `normal`：尺寸类似于中等密度 HVGA 屏幕的屏幕。标准屏幕的最小布局尺寸约为 320x470 dp。例如，WQVGA 低密度屏幕、HVGA 中等密度屏幕和 WVGA 高密度屏幕。 - `large`：尺寸类似于中等密度 VGA 屏幕的屏幕。大屏幕的最小布局尺寸约为 480x640 dp。例如，VGA 和 WVGA 中等密度屏幕。 - `xlarge`：明显大于传统中等密度 HVGA 屏幕的屏幕。超大屏幕的最小布局尺寸约为 720x960 dp。在大多数情况下，屏幕超大的设备体积太大，不能放进口袋，最常见的是平板式设备。此项为 API 级别 9 中的新增配置。注意：使用尺寸限定符并不意味着相应资源仅适用于该尺寸的屏幕。如果没有为备用资源提供最符合当前设备配置的限定符，则系统可以使用其中最匹配的资源。注意：如果所有资源均使用大于当前屏幕的尺寸限定符，则系统不会使用这些资源，并且应用会在运行时崩溃。例如，如果所有布局资源均以 `xlarge` 限定符标记，但设备是标准尺寸的屏幕此项为 API 级别 4 中的新增配置。另请参阅 `[screenLayout](https://developer.android.google.cn/reference/android/content/res/Configuration?hl=zh-cn#screenLayout)` 配置字段，该字段用于指示屏幕为小尺寸、标准尺寸还是大尺寸。如需了解详情，请参阅屏幕兼容性概览。
屏幕宽高比	`long` `notlong`	- `long`：宽屏，如 WQVGA、WVGA、FWVGA - `notlong`：非宽屏，如 QVGA、HVGA 和 VGA 此项为 API 级别 4 中的新增配置。此配置完全基于屏幕的纵横比（`long` 屏较宽），与屏幕方向无关。另请参阅 `[screenLayout](https://developer.android.google.cn/reference/android/content/res/Configuration?hl=zh-cn#screenLayout)` 配置字段，该字段用于指示屏幕是否为宽屏。
圆形屏幕	`round` `notround`	- `round`：圆形屏幕，例如圆形可穿戴式设备 - `notround`：方形屏幕，例如手机或平板电脑此项为 API 级别 23 中的新增配置。另请参阅 `[isScreenRound()](https://developer.android.google.cn/reference/android/content/res/Configuration?hl=zh-cn#isScreenRound())` 配置方法，该方法用于指示屏幕是否为圆形屏幕。
广色域	`widecg` `nowidecg`	- `widecg`：显示广色域，如 Display P3 或 AdobeRGB - `nowidecg`：显示窄色域，如 sRGB 此项为 API 级别 26 中的新增配置。另请参阅 `[isScreenWideColorGamut()](https://developer.android.google.cn/reference/android/content/res/Configuration?hl=zh-cn#isScreenWideColorGamut())` 配置方法，该方法用于指示屏幕是否具有广色域。
高动态范围 (HDR)	`highdr` `lowdr`	- `highdr`：显示高动态范围 - `lowdr`：显示低/标准动态范围此项为 API 级别 26 中的新增配置。另请参阅 `[isScreenHdr()](https://developer.android.google.cn/reference/android/content/res/Configuration?hl=zh-cn#isScreenHdr())` 配置方法，该方法用于指示屏幕是否具有 HDR 功能。
屏幕方向	`port` `land`	- `port`：设备处于竖屏模式（纵向） - `land`：设备处于横屏模式（水平）如果用户旋转屏幕，此配置可能会在应用生命周期中发生变化。如需了解这会在运行时期间给应用带来哪些影响，请参阅处理配置更改。另请参阅 `[orientation](https://developer.android.google.cn/reference/android/content/res/Configuration?hl=zh-cn#orientation)` 配置字段，该字段用于指示当前的设备方向。
界面模式	`car` `desk` `television` `appliance` `watch` `vrheadset`	- `car`：设备正在车载基座中显示 - `desk`：设备正在桌面基座中显示 - `television`：设备正在通过电视显示内容，通过将界面投影到离用户较远的大屏幕上，为用户提供“十英尺”体验。该体验主要面向遥控交互或其他非触控式交互 - `appliance`：设备用作不带显示屏的装置 - `watch`：设备配有显示屏，并且可戴在手腕上 - `vrheadset`：设备正在通过虚拟现实耳机显示内容此项为 API 级别 8 中的新增配置；API 13 中的新增电视配置；API 20 中的新增手表配置。如需了解在设备插入基座或从基座中取出时您的应用会如何响应，请参阅确定和监控插接状态和基座类型。如果用户将设备插入基座，此配置可能会在应用生命周期中发生变化。您可以使用 `[UiModeManager](https://developer.android.google.cn/reference/android/app/UiModeManager?hl=zh-cn)` 启用或停用其中的部分模式。如需了解这会在运行时期间给应用带来哪些影响，请参阅处理配置更改。
夜间模式	`night` `notnight`	- `night`：夜晚时光 - `notnight`：日间节目此项为 API 级别 8 中的新增配置。如果夜间模式停留在自动模式（默认），此配置可能会在应用生命周期中发生变化。在这种情况下，该模式会根据当天的时间进行调整。您可以使用 `[UiModeManager](https://developer.android.google.cn/reference/android/app/UiModeManager?hl=zh-cn)` 启用或停用此模式。如需了解这会在运行时期间给应用带来哪些影响，请参阅处理配置更改。
屏幕像素密度 (dpi)	`ldpi` `mdpi` `hdpi` `xhdpi` `xxhdpi` `xxxhdpi` `nodpi` `tvdpi` `anydpi` `_nnn_dpi`	- `ldpi`：低密度屏幕；约为 120 dpi。 - `mdpi`：中密度（传统 HVGA）屏幕；约为 160 dpi。 - `hdpi`：高密度屏幕；约为 240 dpi。 - `xhdpi`：超高密度屏幕；约为 320 dpi。此项为 API 级别 8 中的新增配置。 - `xxhdpi`：超超高密度屏幕；约为 480 dpi。此项为 API 级别 16 中的新增配置。 - `xxxhdpi`：超超超高密度屏幕使用（仅限启动器图标，请参阅支持不同的像素密度）；约为 640 dpi。此项为 API 级别 18 中的新增配置。 - `nodpi`：用于您不希望为匹配设备密度而进行缩放的位图资源。 - `tvdpi`：密度介于 mdpi 和 hdpi 之间的屏幕；约为 213 dpi。这不属于“主要”密度组。它主要用于 720p 电视，而大多数应用都不需要它。对于 1080p 电视面板，请使用 `xhdpi`；对于 4K 电视面板，请使用 `xxxhdpi`。此项为 API 级别 13 中的新增配置。 - `anydpi`：适合所有屏幕密度，其优先级高于其他限定符。这对于矢量可绘制对象非常有用。此项为 API 级别 21 中的新增配置。 - `_nnn_dpi`：用于表示非标准密度，其中 `_nnn_` 是正整数屏幕密度。大多数情况下不使用此限定符。使用标准密度存储分区，可显著减少因支持市场上各种设备屏幕密度而产生的开销。这六种主要密度之间的缩放比例为 3:4:6:8:12:16（tvdpi 密度忽略不计）。因此，9x9 (ldpi) 位图相当于 12x12 (mdpi)、18x18 (hdpi)、24x24 (xhdpi) 位图，依此类推。注意：使用密度限定符并不意味着资源仅适用于该密度的屏幕。如果您没有为备用资源提供最符合当前设备配置的限定符，则系统会使用其中最匹配的资源。如需详细了解如何处理不同屏幕密度以及 Android 如何缩放位图以适应当前密度，请参阅屏幕兼容性概览。
触摸屏类型	`notouch` `finger`	- `notouch`：设备没有触摸屏。 - `finger`：设备有一个专供用户通过手指直接与其交互的触摸屏。另请参阅 `[touchscreen](https://developer.android.google.cn/reference/android/content/res/Configuration?hl=zh-cn#touchscreen)` 配置字段，该字段用于指示设备的触摸屏类型。
键盘可用性	`keysexposed` `keyshidden` `keyssoft`	- `keysexposed`：设备具有可用的键盘。如果设备启用了软件键盘（不无可能），那么即使用户未找到硬件键盘，或者该设备没有硬件键盘，也可使用此限定符。如果设备未提供软件键盘或软件键盘已停用，则只有在向用户公开硬件键盘时，才可使用此限定符。 - `keyshidden`：设备具有可用的硬件键盘，但其处于隐藏状态，且设备未启用软件键盘。 - `keyssoft`：设备已启用软件键盘（无论是否可见）。如果您提供了 `keysexposed` 资源，但未提供 `keyssoft` 资源，则无论键盘是否可见，只要系统已启用软件键盘，其便会使用 `keysexposed` 资源。如果用户打开硬件键盘，此配置可能会在应用生命周期中发生变化。如需了解这会在运行时期间给应用带来哪些影响，请参阅处理配置更改。另请参阅配置字段 `[hardKeyboardHidden](https://developer.android.google.cn/reference/android/content/res/Configuration?hl=zh-cn#hardKeyboardHidden)` 和 `[keyboardHidden](https://developer.android.google.cn/reference/android/content/res/Configuration?hl=zh-cn#keyboardHidden)`，这两个字段分别用于指示硬件键盘的可见性和任一键盘（包括软件键盘）的可见性。
主要的文本输入法	`nokeys` `qwerty` `12key`	- `nokeys`：设备没有用于文本输入的硬件按键。 - `qwerty`：设备具有硬件 QWERTY 键盘（无论其对用户是否可见）。 - `12key`：设备具有包含 12 个按键的硬件键盘（无论其对用户是否可见）。另请参阅 `[keyboard](https://developer.android.google.cn/reference/android/content/res/Configuration?hl=zh-cn#keyboard)` 配置字段，该字段用于指示可用的主要文本输入法。
导航键可用性	`navexposed` `navhidden`	- `navexposed`：导航键可供用户使用。 - `navhidden`：导航键不可用（例如位于合上的盖子后面）。如果用户显示导航键，此配置可能会在应用生命周期中发生变化。如需了解这会在运行时期间给应用带来哪些影响，请参阅处理配置更改。另请参阅 `[navigationHidden](https://developer.android.google.cn/reference/android/content/res/Configuration?hl=zh-cn#navigationHidden)` 配置字段，该字段用于指示导航键是否处于隐藏状态。
主要的非触摸导航方法	`nonav` `dpad` `trackball` `wheel`	- `nonav`：除了使用触摸屏以外，设备没有其他导航设施。 - `dpad`：设备具有用于导航的方向键。 - `trackball`：设备具有用于导航的轨迹球。 - `wheel`：设备具有用于导航方向盘（不常见）。另请参阅 `[navigation](https://developer.android.google.cn/reference/android/content/res/Configuration?hl=zh-cn#navigation)` 配置字段，该字段用于指示可用的导航方法类型。
平台版本（API 级别）	示例： `v3` `v4` `v7` 等等	设备支持的 API 级别。例如，`v1` 对应 API 级别 1（搭载 Android 1.0 或更高版本的设备）；`v4` 对应 API 级别 4（搭载 Android 1.6 或更高版本的设备）。如需了解有关这些值的详细信息，请参阅 Android API 级别文档。

注意： 并非所有版本的 Android 系统都支持所有限定符。使用新限定符会隐式添加平台版本限定符，因此较旧版本系统的设备可以忽略它。例如，使用 w600dp 限定符会自动包括 v13 限定符，因为可用宽度限定符是 API 级别 13 中的新增配置。为避免出现任何问题，请始终包含一组默认资源（一组不包含任何限定符的资源）。如需了解详细信息，请参阅利用资源提供最佳的设备兼容性部分。

限定符命名规则 #

以下是一些使用配置限定符名称时需遵循的规则：

您可以为单组资源指定多个限定符，并使用短划线分隔。例如，drawable-en-rUS-land 适用于屏幕方向为横向且语言为美式英语的设备。
这些限定符必须遵循表 2 中列出的顺序。
- 错误：drawable-hdpi-port/
- 正确：drawable-port-hdpi/
不得嵌套备用资源目录。例如，您的目录不能为 res/drawable/drawable-en/。
值不区分大小写。资源编译器会在处理之前将目录名称转换为小写形式，以避免在不区分大小的文件系统中出现问题。名称中使用的所有大写字母只是为了便于认读。
每种限定符类型仅支持一个值。例如，如需针对西班牙语和法语使用相同的可绘制对象文件，则您不能拥有名为 drawable-es-fr/ 的目录，而是需要两个包含相应文件的资源目录，如 drawable-es/ 和 drawable-fr/。但是，您并不需要真的在这两个位置复制文件，而是可以为资源创建别名，如创建别名资源部分所述。

将备用资源保存到以这些限定符命名的目录后，Android 系统会基于当前设备配置自动使用您应用中的资源。在每次请求资源时，Android 系统会检查包含所请求资源文件的备用资源目录，然后寻找最匹配的资源。

如果没有与特定设备配置匹配的备用资源，则 Android 系统会使用相应的默认资源（一组不包含配置限定符的特定类型的资源）。

创建别名资源 #

如果您想将某一资源用于多种设备配置，但不想以默认资源的形式提供该资源，则无需将同一资源放入多个备用资源目录中。不过，您可以创建备用资源，充当默认资源目录中所保存资源的别名。

注意：并非所有资源都提供能够为另一资源创建别名的机制。特别是，xml/ 目录中的动画资源、菜单资源、原始资源及其他未指定资源均不提供此功能。

例如，假设您有一个应用图标 icon.png，并且需要针对不同语言区域提供该图标的不同版本。但是，加拿大英语和加拿大法语这两种语言区域需使用同一版本。无需将同一图片复制到加拿大英语和加拿大法语的资源目录中。不过，您可以将这两种语言使用的图片保存为除 icon.png 之外的任意名称（例如 icon_ca.png），并将其放入默认的 res/drawable/ 目录中。然后，在 res/drawable-en-rCA/ 和 res/drawable-fr-rCA/ 中创建 icon.xml 文件，使用 <bitmap> 元素引用 icon_ca.png 资源。这样您就可以只保存一个版本的 PNG 文件和两个指向该版本的小型 XML 文件。如需了解详情，请参阅以下部分中的示例。

可绘制对象 #

如要为现有可绘制对象创建别名，请使用 <drawable> 元素：

1
2
3
4


<?xml version="1.0" encoding="utf-8"?> 
<resources>    
<drawable name="icon">@drawable/icon_ca</drawable> 
</resources> 

如果您将此文件保存为 icon.xml并放入备用资源目录中（例如 res/values-en-rCA/），那么它将被编译为可作为 R.drawable.icon 引用的资源，但它实际上是 R.drawable.icon_ca 资源（保存在 res/drawable/ 中）的别名。

布局 #

如要为现有布局创建别名，请使用封装在 <merge> 中的 <include> 元素：

1
2
3
4


<?xml version="1.0" encoding="utf-8"?> 
<merge>    
<include layout="@layout/main_ltr"/> 
</merge> 

如果将此文件保存为 main.xml，则系统会将其编译到可作为 R.layout.main 引用的资源中，但该文件实际是 R.layout.main_ltr 资源的别名。

字符串和其他简单值 #

如需为现有字符串创建别名，则可将所需字符串的资源 ID 用作新字符串的值：

1
2
3
4
5


<?xml version="1.0" encoding="utf-8"?> 
<resources>    
<string name="hello">Hello</string>    
<string name="hi">@string/hello</string> 
</resources> 

R.string.hi 资源现在是 R.string.hello 的别名。

其他简单值的原理相同，例如颜色：

1
2
3
4
5
6


<?xml version="1.0" encoding="utf-8"?> 
<resources>    
<color name="red">#f00</color>    

<color name="highlight">@color/red</color> 
</resources>

original link:应用资源概览 | Android 开发者 | Android Developers

Zip File Format

Sun, 17 Mar 2024 09:13:47 +0800

来源 #

从APPNOTE.TXT - .ZIP File Format Specification找来备份，以防需要时找不到。

内容 #

内容有些长😄。

很奇怪，排板总是有些问题。

 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
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
 100
 101
 102
 103
 104
 105
 106
 107
 108
 109
 110
 111
 112
 113
 114
 115
 116
 117
 118
 119
 120
 121
 122
 123
 124
 125
 126
 127
 128
 129
 130
 131
 132
 133
 134
 135
 136
 137
 138
 139
 140
 141
 142
 143
 144
 145
 146
 147
 148
 149
 150
 151
 152
 153
 154
 155
 156
 157
 158
 159
 160
 161
 162
 163
 164
 165
 166
 167
 168
 169
 170
 171
 172
 173
 174
 175
 176
 177
 178
 179
 180
 181
 182
 183
 184
 185
 186
 187
 188
 189
 190
 191
 192
 193
 194
 195
 196
 197
 198
 199
 200
 201
 202
 203
 204
 205
 206
 207
 208
 209
 210
 211
 212
 213
 214
 215
 216
 217
 218
 219
 220
 221
 222
 223
 224
 225
 226
 227
 228
 229
 230
 231
 232
 233
 234
 235
 236
 237
 238
 239
 240
 241
 242
 243
 244
 245
 246
 247
 248
 249
 250
 251
 252
 253
 254
 255
 256
 257
 258
 259
 260
 261
 262
 263
 264
 265
 266
 267
 268
 269
 270
 271
 272
 273
 274
 275
 276
 277
 278
 279
 280
 281
 282
 283
 284
 285
 286
 287
 288
 289
 290
 291
 292
 293
 294
 295
 296
 297
 298
 299
 300
 301
 302
 303
 304
 305
 306
 307
 308
 309
 310
 311
 312
 313
 314
 315
 316
 317
 318
 319
 320
 321
 322
 323
 324
 325
 326
 327
 328
 329
 330
 331
 332
 333
 334
 335
 336
 337
 338
 339
 340
 341
 342
 343
 344
 345
 346
 347
 348
 349
 350
 351
 352
 353
 354
 355
 356
 357
 358
 359
 360
 361
 362
 363
 364
 365
 366
 367
 368
 369
 370
 371
 372
 373
 374
 375
 376
 377
 378
 379
 380
 381
 382
 383
 384
 385
 386
 387
 388
 389
 390
 391
 392
 393
 394
 395
 396
 397
 398
 399
 400
 401
 402
 403
 404
 405
 406
 407
 408
 409
 410
 411
 412
 413
 414
 415
 416
 417
 418
 419
 420
 421
 422
 423
 424
 425
 426
 427
 428
 429
 430
 431
 432
 433
 434
 435
 436
 437
 438
 439
 440
 441
 442
 443
 444
 445
 446
 447
 448
 449
 450
 451
 452
 453
 454
 455
 456
 457
 458
 459
 460
 461
 462
 463
 464
 465
 466
 467
 468
 469
 470
 471
 472
 473
 474
 475
 476
 477
 478
 479
 480
 481
 482
 483
 484
 485
 486
 487
 488
 489
 490
 491
 492
 493
 494
 495
 496
 497
 498
 499
 500
 501
 502
 503
 504
 505
 506
 507
 508
 509
 510
 511
 512
 513
 514
 515
 516
 517
 518
 519
 520
 521
 522
 523
 524
 525
 526
 527
 528
 529
 530
 531
 532
 533
 534
 535
 536
 537
 538
 539
 540
 541
 542
 543
 544
 545
 546
 547
 548
 549
 550
 551
 552
 553
 554
 555
 556
 557
 558
 559
 560
 561
 562
 563
 564
 565
 566
 567
 568
 569
 570
 571
 572
 573
 574
 575
 576
 577
 578
 579
 580
 581
 582
 583
 584
 585
 586
 587
 588
 589
 590
 591
 592
 593
 594
 595
 596
 597
 598
 599
 600
 601
 602
 603
 604
 605
 606
 607
 608
 609
 610
 611
 612
 613
 614
 615
 616
 617
 618
 619
 620
 621
 622
 623
 624
 625
 626
 627
 628
 629
 630
 631
 632
 633
 634
 635
 636
 637
 638
 639
 640
 641
 642
 643
 644
 645
 646
 647
 648
 649
 650
 651
 652
 653
 654
 655
 656
 657
 658
 659
 660
 661
 662
 663
 664
 665
 666
 667
 668
 669
 670
 671
 672
 673
 674
 675
 676
 677
 678
 679
 680
 681
 682
 683
 684
 685
 686
 687
 688
 689
 690
 691
 692
 693
 694
 695
 696
 697
 698
 699
 700
 701
 702
 703
 704
 705
 706
 707
 708
 709
 710
 711
 712
 713
 714
 715
 716
 717
 718
 719
 720
 721
 722
 723
 724
 725
 726
 727
 728
 729
 730
 731
 732
 733
 734
 735
 736
 737
 738
 739
 740
 741
 742
 743
 744
 745
 746
 747
 748
 749
 750
 751
 752
 753
 754
 755
 756
 757
 758
 759
 760
 761
 762
 763
 764
 765
 766
 767
 768
 769
 770
 771
 772
 773
 774
 775
 776
 777
 778
 779
 780
 781
 782
 783
 784
 785
 786
 787
 788
 789
 790
 791
 792
 793
 794
 795
 796
 797
 798
 799
 800
 801
 802
 803
 804
 805
 806
 807
 808
 809
 810
 811
 812
 813
 814
 815
 816
 817
 818
 819
 820
 821
 822
 823
 824
 825
 826
 827
 828
 829
 830
 831
 832
 833
 834
 835
 836
 837
 838
 839
 840
 841
 842
 843
 844
 845
 846
 847
 848
 849
 850
 851
 852
 853
 854
 855
 856
 857
 858
 859
 860
 861
 862
 863
 864
 865
 866
 867
 868
 869
 870
 871
 872
 873
 874
 875
 876
 877
 878
 879
 880
 881
 882
 883
 884
 885
 886
 887
 888
 889
 890
 891
 892
 893
 894
 895
 896
 897
 898
 899
 900
 901
 902
 903
 904
 905
 906
 907
 908
 909
 910
 911
 912
 913
 914
 915
 916
 917
 918
 919
 920
 921
 922
 923
 924
 925
 926
 927
 928
 929
 930
 931
 932
 933
 934
 935
 936
 937
 938
 939
 940
 941
 942
 943
 944
 945
 946
 947
 948
 949
 950
 951
 952
 953
 954
 955
 956
 957
 958
 959
 960
 961
 962
 963
 964
 965
 966
 967
 968
 969
 970
 971
 972
 973
 974
 975
 976
 977
 978
 979
 980
 981
 982
 983
 984
 985
 986
 987
 988
 989
 990
 991
 992
 993
 994
 995
 996
 997
 998
 999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290
1291
1292
1293
1294
1295
1296
1297
1298
1299
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343
1344
1345
1346
1347
1348
1349
1350
1351
1352
1353
1354
1355
1356
1357
1358
1359
1360
1361
1362
1363
1364
1365
1366
1367
1368
1369
1370
1371
1372
1373
1374
1375
1376
1377
1378
1379
1380
1381
1382
1383
1384
1385
1386
1387
1388
1389
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399
1400
1401
1402
1403
1404
1405
1406
1407
1408
1409
1410
1411
1412
1413
1414
1415
1416
1417
1418
1419
1420
1421
1422
1423
1424
1425
1426
1427
1428
1429
1430
1431
1432
1433
1434
1435
1436
1437
1438
1439
1440
1441
1442
1443
1444
1445
1446
1447
1448
1449
1450
1451
1452
1453
1454
1455
1456
1457
1458
1459
1460
1461
1462
1463
1464
1465
1466
1467
1468
1469
1470
1471
1472
1473
1474
1475
1476
1477
1478
1479
1480
1481
1482
1483
1484
1485
1486
1487
1488
1489
1490
1491
1492
1493
1494
1495
1496
1497
1498
1499
1500
1501
1502
1503
1504
1505
1506
1507
1508
1509
1510
1511
1512
1513
1514
1515
1516
1517
1518
1519
1520
1521
1522
1523
1524
1525
1526
1527
1528
1529
1530
1531
1532
1533
1534
1535
1536
1537
1538
1539
1540
1541
1542
1543
1544
1545
1546
1547
1548
1549
1550
1551
1552
1553
1554
1555
1556
1557
1558
1559
1560
1561
1562
1563
1564
1565
1566
1567
1568
1569
1570
1571
1572
1573
1574
1575
1576
1577
1578
1579
1580
1581
1582
1583
1584
1585
1586
1587
1588
1589
1590
1591
1592
1593
1594
1595
1596
1597
1598
1599
1600
1601
1602
1603
1604
1605
1606
1607
1608
1609
1610
1611
1612
1613
1614
1615
1616
1617
1618
1619
1620
1621
1622
1623
1624
1625
1626
1627
1628
1629
1630
1631
1632
1633
1634
1635
1636
1637
1638
1639
1640
1641
1642
1643
1644
1645
1646
1647
1648
1649
1650
1651
1652
1653
1654
1655
1656
1657
1658
1659
1660
1661
1662
1663
1664
1665
1666
1667
1668
1669
1670
1671
1672
1673
1674
1675
1676
1677
1678
1679
1680
1681
1682
1683
1684
1685
1686
1687
1688
1689
1690
1691
1692
1693
1694
1695
1696
1697
1698
1699
1700
1701
1702
1703
1704
1705
1706
1707
1708
1709
1710
1711
1712
1713
1714
1715
1716
1717
1718
1719
1720
1721
1722
1723
1724
1725
1726
1727
1728
1729
1730
1731
1732
1733
1734
1735
1736
1737
1738
1739
1740
1741
1742
1743
1744
1745
1746
1747
1748
1749
1750
1751
1752
1753
1754
1755
1756
1757
1758
1759
1760
1761
1762
1763
1764
1765
1766
1767
1768
1769
1770
1771
1772
1773
1774
1775
1776
1777
1778
1779
1780
1781
1782
1783
1784
1785
1786
1787
1788
1789
1790
1791
1792
1793
1794
1795
1796
1797
1798
1799
1800
1801
1802
1803
1804
1805
1806
1807
1808
1809
1810
1811
1812
1813
1814
1815
1816
1817
1818
1819
1820
1821
1822
1823
1824
1825
1826
1827
1828
1829
1830
1831
1832
1833
1834
1835
1836
1837
1838
1839
1840
1841
1842
1843
1844
1845
1846
1847
1848
1849
1850
1851
1852
1853
1854
1855
1856
1857
1858
1859
1860
1861
1862
1863
1864
1865
1866
1867
1868
1869
1870
1871
1872
1873
1874
1875
1876
1877
1878
1879
1880
1881
1882
1883
1884
1885
1886
1887
1888
1889
1890
1891
1892
1893
1894
1895
1896
1897
1898
1899
1900
1901
1902
1903
1904
1905
1906
1907
1908
1909
1910
1911
1912
1913
1914
1915
1916
1917
1918
1919
1920
1921
1922
1923
1924
1925
1926
1927
1928
1929
1930
1931
1932
1933
1934
1935
1936
1937
1938
1939
1940
1941
1942
1943
1944
1945
1946
1947
1948
1949
1950
1951
1952
1953
1954
1955
1956
1957
1958
1959
1960
1961
1962
1963
1964
1965
1966
1967
1968
1969
1970
1971
1972
1973
1974
1975
1976
1977
1978
1979
1980
1981
1982
1983
1984
1985
1986
1987
1988
1989
1990
1991
1992
1993
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
2025
2026
2027
2028
2029
2030
2031
2032
2033
2034
2035
2036
2037
2038
2039
2040
2041
2042
2043
2044
2045
2046
2047
2048
2049
2050
2051
2052
2053
2054
2055
2056
2057
2058
2059
2060
2061
2062
2063
2064
2065
2066
2067
2068
2069
2070
2071
2072
2073
2074
2075
2076
2077
2078
2079
2080
2081
2082
2083
2084
2085
2086
2087
2088
2089
2090
2091
2092
2093
2094
2095
2096
2097
2098
2099
2100
2101
2102
2103
2104
2105
2106
2107
2108
2109
2110
2111
2112
2113
2114
2115
2116
2117
2118
2119
2120
2121
2122
2123
2124
2125
2126
2127
2128
2129
2130
2131
2132
2133
2134
2135
2136
2137
2138
2139
2140
2141
2142
2143
2144
2145
2146
2147
2148
2149
2150
2151
2152
2153
2154
2155
2156
2157
2158
2159
2160
2161
2162
2163
2164
2165
2166
2167
2168
2169
2170
2171
2172
2173
2174
2175
2176
2177
2178
2179
2180
2181
2182
2183
2184
2185
2186
2187
2188
2189
2190
2191
2192
2193
2194
2195
2196
2197
2198
2199
2200
2201
2202
2203
2204
2205
2206
2207
2208
2209
2210
2211
2212
2213
2214
2215
2216
2217
2218
2219
2220
2221
2222
2223
2224
2225
2226
2227
2228
2229
2230
2231
2232
2233
2234
2235
2236
2237
2238
2239
2240
2241
2242
2243
2244
2245
2246
2247
2248
2249
2250
2251
2252
2253
2254
2255
2256
2257
2258
2259
2260
2261
2262
2263
2264
2265
2266
2267
2268
2269
2270
2271
2272
2273
2274
2275
2276
2277
2278
2279
2280
2281
2282
2283
2284
2285
2286
2287
2288
2289
2290
2291
2292
2293
2294
2295
2296
2297
2298
2299
2300
2301
2302
2303
2304
2305
2306
2307
2308
2309
2310
2311
2312
2313
2314
2315
2316
2317
2318
2319
2320
2321
2322
2323
2324
2325
2326
2327
2328
2329
2330
2331
2332
2333
2334
2335
2336
2337
2338
2339
2340
2341
2342
2343
2344
2345
2346
2347
2348
2349
2350
2351
2352
2353
2354
2355
2356
2357
2358
2359
2360
2361
2362
2363
2364
2365
2366
2367
2368
2369
2370
2371
2372
2373
2374
2375
2376
2377
2378
2379
2380
2381
2382
2383
2384
2385
2386
2387
2388
2389
2390
2391
2392
2393
2394
2395
2396
2397
2398
2399
2400
2401
2402
2403
2404
2405
2406
2407
2408
2409
2410
2411
2412
2413
2414
2415
2416
2417
2418
2419
2420
2421
2422
2423
2424
2425
2426
2427
2428
2429
2430
2431
2432
2433
2434
2435
2436
2437
2438
2439
2440
2441
2442
2443
2444
2445
2446
2447
2448
2449
2450
2451
2452
2453
2454
2455
2456
2457
2458
2459
2460
2461
2462
2463
2464
2465
2466
2467
2468
2469
2470
2471
2472
2473
2474
2475
2476
2477
2478
2479
2480
2481
2482
2483
2484
2485
2486
2487
2488
2489
2490
2491
2492
2493
2494
2495
2496
2497
2498
2499
2500
2501
2502
2503
2504
2505
2506
2507
2508
2509
2510
2511
2512
2513
2514
2515
2516
2517
2518
2519
2520
2521
2522
2523
2524
2525
2526
2527
2528
2529
2530
2531
2532
2533
2534
2535
2536
2537
2538
2539
2540
2541
2542
2543
2544
2545
2546
2547
2548
2549
2550
2551
2552
2553
2554
2555
2556
2557
2558
2559
2560
2561
2562
2563
2564
2565
2566
2567
2568
2569
2570
2571
2572
2573
2574
2575
2576
2577
2578
2579
2580
2581
2582
2583
2584
2585
2586
2587
2588
2589
2590
2591
2592
2593
2594
2595
2596
2597
2598
2599
2600
2601
2602
2603
2604
2605
2606
2607
2608
2609
2610
2611
2612
2613
2614
2615
2616
2617
2618
2619
2620
2621
2622
2623
2624
2625
2626
2627
2628


File: APPNOTE.TXT - .ZIP File Format Specification
Version: 6.2.0 - NOTIFICATION OF CHANGE
Revised: 04/26/2004
Copyright (c) 1989 - 2004 PKWARE Inc., All Rights Reserved.

I. Purpose
----------

This specification is intended to define a cross-platform,
interoperable file format. Since its first publication
in 1989, PKWARE has remained committed to ensuring the 
interoperability of the .ZIP file format through this
specification. We trust that all .ZIP compatible vendors
and application developers that have adopted this format
will share and support this commitment.


II. Disclaimer
--------------

Although PKWARE will attempt to supply current and accurate
information relating to its file formats, algorithms, and the
subject programs, the possibility of error or omission can not 
be eliminated. PKWARE therefore expressly disclaims any warranty 
that the information contained in the associated materials relating 
to the subject programs and/or the format of the files created or
accessed by the subject programs and/or the algorithms used by
the subject programs, or any other matter, is current, correct or
accurate as delivered. Any risk of damage due to any possible
inaccurate information is assumed by the user of the information.
Furthermore, the information relating to the subject programs
and/or the file formats created or accessed by the subject
programs and/or the algorithms used by the subject programs is
subject to change without notice.

If the version of this file is marked as a NOTIFICATION OF CHANGE,
the content defines an Early Feature Specification (EFS) change 
to the .ZIP file format that may be subject to modification prior 
to publication of the Final Feature Specification (FFS). This
document may also contain information on Planned Feature 
Specifications (PFS) defining recognized future extensions.

III. Change Log
---------------

Version Change Description Date
------- ------------------ ----------
5.2 -Single Password Symmetric Encryption 07/16/2003
 storage

6.1.0 -Smart Card compatibility 01/20/2004
 -Documentation on certificate storage

6.2.0 -Introduction of Central Directory 04/26/2004
 Encryption for encrypting metadata
 -Added OS/X to Version Made By values


VI. General Format of a .ZIP file
---------------------------------

 Files stored in arbitrary order. Large .ZIP files can span multiple
 diskette media or be split into user-defined segment sizes. 

 Overall .ZIP file format:

 [local file header 1]
 [file data 1]
 [data descriptor 1]
 . 
 .
 .
 [local file header n]
 [file data n]
 [data descriptor n]
 [archive decryption header] (EFS)
 [archive extra data record] (EFS)
 [central directory]
 [zip64 end of central directory record]
 [zip64 end of central directory locator] 
 [end of central directory record]


 A. Local file header:

 local file header signature 4 bytes (0x04034b50)
 version needed to extract 2 bytes
 general purpose bit flag 2 bytes
 compression method 2 bytes
 last mod file time 2 bytes
 last mod file date 2 bytes
 crc-32 4 bytes
 compressed size 4 bytes
 uncompressed size 4 bytes
 file name length 2 bytes
 extra field length 2 bytes

 file name (variable size)
 extra field (variable size)

 B. File data

 Immediately following the local header for a file
 is the compressed or stored data for the file. 
 The series of [local file header][file data][data
 descriptor] repeats for each file in the .ZIP archive. 

 C. Data descriptor:

 crc-32 4 bytes
 compressed size 4 bytes
 uncompressed size 4 bytes

 This descriptor exists only if bit 3 of the general
 purpose bit flag is set (see below). It is byte aligned
 and immediately follows the last byte of compressed data.
 This descriptor is used only when it was not possible to
 seek in the output .ZIP file, e.g., when the output .ZIP file
 was standard output or a non seekable device. For Zip64 format
 archives, the compressed and uncompressed sizes are 8 bytes each.

 D. Archive decryption header: (EFS)

 The Archive Decryption Header is introduced in version 6.2
 of the ZIP format specification. This record exists in support
 of the Central Directory Encryption Feature implemented as part of 
 the Strong Encryption Specification as described in this document.
 When the Central Directory Structure is encrypted, this decryption
 header will precede the encrypted data segment. The encrypted
 data segment will consist of the Archive extra data record (if
 present) and the encrypted Central Directory Structure data.
 The format of this data record is identical to the Decryption
 header record preceding compressed file data. If the central 
 directory structure is encrypted, the location of the start of
 this data record is determined using the Start of Central Directory
 field in the Zip64 End of Central Directory record. Refer to the 
 section on the Strong Encryption Specification for information
 on the fields used in the Archive Decryption Header record.


 E. Archive extra data record: (EFS)

 archive extra data signature 4 bytes (0x08064b50)
 extra field length 4 bytes
 extra field data (variable size)

 The Archive Extra Data Record is introduced in version 6.2
 of the ZIP format specification. This record exists in support
 of the Central Directory Encryption Feature implemented as part of 
 the Strong Encryption Specification as described in this document.
 When present, this record immediately precedes the central 
 directory data structure. The size of this data record will be
 included in the Size of the Central Directory field in the
 End of Central Directory record. If the central directory structure
 is compressed, but not encrypted, the location of the start of
 this data record is determined using the Start of Central Directory
 field in the Zip64 End of Central Directory record. 


 F. Central directory structure:

 [file header 1]
 .
 .
 . 
 [file header n]
 [digital signature] 

 File header:

 central file header signature 4 bytes (0x02014b50)
 version made by 2 bytes
 version needed to extract 2 bytes
 general purpose bit flag 2 bytes
 compression method 2 bytes
 last mod file time 2 bytes
 last mod file date 2 bytes
 crc-32 4 bytes
 compressed size 4 bytes
 uncompressed size 4 bytes
 file name length 2 bytes
 extra field length 2 bytes
 file comment length 2 bytes
 disk number start 2 bytes
 internal file attributes 2 bytes
 external file attributes 4 bytes
 relative offset of local header 4 bytes

 file name (variable size)
 extra field (variable size)
 file comment (variable size)

 Digital signature:

 header signature 4 bytes (0x05054b50)
 size of data 2 bytes
 signature data (variable size)

 With the introduction of the Central Directory Encryption 
 feature in version 6.2 of this specification, the Central 
 Directory Structure may be stored both compressed and encrypted. 
 Although not required, it is assumed when encrypting the
 Central Directory Structure, that it will be compressed
 for greater storage efficiency. Information on the
 Central Directory Encryption feature can be found in the section
 describing the Strong Encryption Specification. The Digital 
 Signature record will be neither compressed nor encrypted.

 G. Zip64 end of central directory record

 zip64 end of central dir 
 signature 4 bytes (0x06064b50)
 size of zip64 end of central
 directory record 8 bytes
 version made by 2 bytes
 version needed to extract 2 bytes
 number of this disk 4 bytes
 number of the disk with the 
 start of the central directory 4 bytes
 total number of entries in the
 central directory on this disk 8 bytes
 total number of entries in the
 central directory 8 bytes
 size of the central directory 8 bytes
 offset of start of central
 directory with respect to
 the starting disk number 8 bytes
 zip64 extensible data sector (variable size)

 The above record structure defines Version 1 of the 
 Zip64 end of central directory record. Version 1 was 
 implemented in versions of this specification preceding 
 6.2 in support of the ZIP64(tm) large file feature. The 
 introduction of the Central Directory Encryption feature 
 implemented in version 6.2 as part of the Strong Encryption 
 Specification defines Version 2 of this record structure. 
 Refer to the section describing the Strong Encryption 
 Specification for details on the version 2 format for 
 this record.


 H. Zip64 end of central directory locator

 zip64 end of central dir locator 
 signature 4 bytes (0x07064b50)
 number of the disk with the
 start of the zip64 end of 
 central directory 4 bytes
 relative offset of the zip64
 end of central directory record 8 bytes
 total number of disks 4 bytes
 
 I. End of central directory record:

 end of central dir signature 4 bytes (0x06054b50)
 number of this disk 2 bytes
 number of the disk with the
 start of the central directory 2 bytes
 total number of entries in the
 central directory on this disk 2 bytes
 total number of entries in
 the central directory 2 bytes
 size of the central directory 4 bytes
 offset of start of central
 directory with respect to
 the starting disk number 4 bytes
 .ZIP file comment length 2 bytes
 .ZIP file comment (variable size)

 J. Explanation of fields:

 version made by (2 bytes)

 The upper byte indicates the compatibility of the file
 attribute information. If the external file attributes 
 are compatible with MS-DOS and can be read by PKZIP for 
 DOS version 2.04g then this value will be zero. If these 
 attributes are not compatible, then this value will 
 identify the host system on which the attributes are 
 compatible. Software can use this information to determine
 the line record format for text files etc. The current
 mappings are:

 0 - MS-DOS and OS/2 (FAT / VFAT / FAT32 file systems)
 1 - Amiga 2 - OpenVMS
 3 - Unix 4 - VM/CMS
 5 - Atari ST 6 - OS/2 H.P.F.S.
 7 - Macintosh 8 - Z-System
 9 - CP/M 10 - Windows NTFS
 11 - MVS (OS/390 - Z/OS) 12 - VSE
 13 - Acorn Risc 14 - VFAT
 15 - alternate MVS 16 - BeOS
 17 - Tandem 18 - OS/400
 19 - OS/X (Darwin) 20 thru 255 - unused

 The lower byte indicates the ZIP specification version 
 (the version of this document) supported by the software 
 used to encode the file. The value/10 indicates the major 
 version number, and the value mod 10 is the minor version 
 number. 

 version needed to extract (2 bytes)

 The minimum supported ZIP specification version needed to 
 extract the file, mapped as above. This value is based on 
 the specific format features a ZIP program must support to 
 be able to extract the file. If multiple features are
 applied to a file, the minimum version should be set to the 
 feature having the highest value. New features or feature 
 changes affecting the published format specification will be 
 implemented using higher version numbers than the last 
 published value to avoid conflict.

 Current minimum feature versions are as defined below:

 1.0 - Default value
 1.1 - File is a volume label
 2.0 - File is a folder (directory)
 2.0 - File is compressed using Deflate compression
 2.0 - File is encrypted using traditional PKWARE encryption
 2.1 - File is compressed using Deflate64(tm)
 2.5 - File is compressed using PKWARE DCL Implode 
 2.7 - File is a patch data set 
 4.5 - File uses ZIP64 format extensions
 4.6 - File is compressed using BZIP2 compression*
 5.0 - File is encrypted using DES
 5.0 - File is encrypted using 3DES
 5.0 - File is encrypted using original RC2 encryption
 5.0 - File is encrypted using RC4 encryption
 5.1 - File is encrypted using AES encryption
 5.1 - File is encrypted using corrected RC2 encryption**
 5.2 - File is encrypted using corrected RC2-64 encryption**
 6.1 - File is encrypted using non-OAEP key wrapping***
 6.2 - Central directory encryption


 * Early 7.x (pre-7.2) versions of PKZIP incorrectly set the
 version needed to extract for BZIP2 compression to be 50
 when it should have been 46.

 ** Refer to the section on Strong Encryption Specification
 for additional information regarding RC2 corrections.

 *** Certificate encryption using non-OAEP key wrapping is the
 intended mode of operation for all versions beginning with 6.1.
 Support for OAEP key wrapping should only be used for
 backward compatibility when sending ZIP files to be opened by
 versions of PKZIP older than 6.1 (5.0 or 6.0).

 When using ZIP64 extensions, the corresponding value in the
 Zip64 end of central directory record should also be set. 
 This field currently supports only the value 45 to indicate
 ZIP64 extensions are present.

 general purpose bit flag: (2 bytes)

 Bit 0: If set, indicates that the file is encrypted.

 (For Method 6 - Imploding)
 Bit 1: If the compression method used was type 6,
 Imploding, then this bit, if set, indicates
 an 8K sliding dictionary was used. If clear,
 then a 4K sliding dictionary was used.
 Bit 2: If the compression method used was type 6,
 Imploding, then this bit, if set, indicates
 3 Shannon-Fano trees were used to encode the
 sliding dictionary output. If clear, then 2
 Shannon-Fano trees were used.

 (For Methods 8 and 9 - Deflating)
 Bit 2 Bit 1
 0 0 Normal (-en) compression option was used.
 0 1 Maximum (-exx/-ex) compression option was used.
 1 0 Fast (-ef) compression option was used.
 1 1 Super Fast (-es) compression option was used.

 Note: Bits 1 and 2 are undefined if the compression
 method is any other.

 Bit 3: If this bit is set, the fields crc-32, compressed 
 size and uncompressed size are set to zero in the 
 local header. The correct values are put in the 
 data descriptor immediately following the compressed
 data. (Note: PKZIP version 2.04g for DOS only 
 recognizes this bit for method 8 compression, newer 
 versions of PKZIP recognize this bit for any 
 compression method.)

 Bit 4: Reserved for use with method 8, for enhanced
 deflating. 

 Bit 5: If this bit is set, this indicates that the file is 
 compressed patched data. (Note: Requires PKZIP 
 version 2.70 or greater)

 Bit 6: Strong encryption. If this bit is set, you should
 set the version needed to extract value to at least
 50 and you must also set bit 0. If AES encryption
 is used, the version needed to extract value must 
 be at least 51.

 Bit 7: Currently unused.

 Bit 8: Currently unused.

 Bit 9: Currently unused.

 Bit 10: Currently unused.

 Bit 11: Currently unused.

 Bit 12: Reserved by PKWARE for enhanced compression.

 Bit 13: Used when encrypting the Central Directory to indicate 
 selected data values in the Local Header are masked to
 hide their actual values. See the section describing 
 the Strong Encryption Specification for details.

 Bit 14: Reserved by PKWARE.

 Bit 15: Reserved by PKWARE.

 compression method: (2 bytes)

 (see accompanying documentation for algorithm
 descriptions)

 0 - The file is stored (no compression)
 1 - The file is Shrunk
 2 - The file is Reduced with compression factor 1
 3 - The file is Reduced with compression factor 2
 4 - The file is Reduced with compression factor 3
 5 - The file is Reduced with compression factor 4
 6 - The file is Imploded
 7 - Reserved for Tokenizing compression algorithm
 8 - The file is Deflated
 9 - Enhanced Deflating using Deflate64(tm)
 10 - PKWARE Data Compression Library Imploding
 11 - Reserved by PKWARE
 12 - File is compressed using BZIP2 algorithm

 date and time fields: (2 bytes each)

 The date and time are encoded in standard MS-DOS format.
 If input came from standard input, the date and time are
 those at which compression was started for this data. 
 If encrypting the central directory and general purpose bit 
 flag 13 is set indicating masking, the value stored in the 
 Local Header will be zero. 

 CRC-32: (4 bytes)

 The CRC-32 algorithm was generously contributed by
 David Schwaderer and can be found in his excellent
 book "C Programmers Guide to NetBIOS" published by
 Howard W. Sams & Co. Inc. The 'magic number' for
 the CRC is 0xdebb20e3. The proper CRC pre and post
 conditioning is used, meaning that the CRC register
 is pre-conditioned with all ones (a starting value
 of 0xffffffff) and the value is post-conditioned by
 taking the one's complement of the CRC residual.
 If bit 3 of the general purpose flag is set, this
 field is set to zero in the local header and the correct
 value is put in the data descriptor and in the central
 directory. If encrypting the central directory and general 
 purpose bit flag 13 is set indicating masking, the value 
 stored in the Local Header will be zero. 

 compressed size: (4 bytes)
 uncompressed size: (4 bytes)

 The size of the file compressed and uncompressed,
 respectively. If bit 3 of the general purpose bit flag
 is set, these fields are set to zero in the local header
 and the correct values are put in the data descriptor and
 in the central directory. If an archive is in zip64 format
 and the value in this field is 0xFFFFFFFF, the size will be
 in the corresponding 8 byte zip64 extended information 
 extra field. If encrypting the central directory and general 
 purpose bit flag 13 is set indicating masking, the value stored 
 for the uncompressed size in the Local Header will be zero. 

 file name length: (2 bytes)
 extra field length: (2 bytes)
 file comment length: (2 bytes)

 The length of the file name, extra field, and comment
 fields respectively. The combined length of any
 directory record and these three fields should not
 generally exceed 65,535 bytes. If input came from standard
 input, the file name length is set to zero. 

 disk number start: (2 bytes)

 The number of the disk on which this file begins. If an 
 archive is in zip64 format and the value in this field is 
 0xFFFF, the size will be in the corresponding 4 byte zip64 
 extended information extra field.

 internal file attributes: (2 bytes)

 Bits 1 and 2 are reserved for use by PKWARE.

 The lowest bit of this field indicates, if set, that
 the file is apparently an ASCII or text file. If not
 set, that the file apparently contains binary data.
 The remaining bits are unused in version 1.0.

 The 0x0002 bit of this field indicates, if set, that a 
 4 byte variable record length control field precedes each 
 logical record indicating the length of the record. This 
 flag is independent of text control characters, and if used 
 in conjunction with text data, includes any control 
 characters in the total length of the record. This value is 
 provided for mainframe data transfer support.

 external file attributes: (4 bytes)

 The mapping of the external attributes is
 host-system dependent (see 'version made by'). For
 MS-DOS, the low order byte is the MS-DOS directory
 attribute byte. If input came from standard input, this
 field is set to zero.

 relative offset of local header: (4 bytes)

 This is the offset from the start of the first disk on
 which this file appears, to where the local header should
 be found. If an archive is in zip64 format and the value
 in this field is 0xFFFFFFFF, the size will be in the 
 corresponding 8 byte zip64 extended information extra field.

 file name: (Variable)

 The name of the file, with optional relative path.
 The path stored should not contain a drive or
 device letter, or a leading slash. All slashes
 should be forward slashes '/' as opposed to
 backwards slashes '\' for compatibility with Amiga
 and Unix file systems etc. If input came from standard
 input, there is no file name field. If encrypting
 the central directory and general purpose bit flag 13 is set 
 indicating masking, the file name stored in the Local Header 
 will not be the actual file name. A masking value consisting 
 of a unique hexadecimal value will be stored. This value will 
 be sequentially incremented for each file in the archive. See
 the section on the Strong Encryption Specification for details 
 on retrieving the encrypted file name. 

 extra field: (Variable)

 This is for expansion. If additional information
 needs to be stored for special needs or for specific 
 platforms, it should be stored here. Earlier versions 
 of the software can then safely skip this file, and 
 find the next file or header. This field will be 0 
 length in version 1.0.

 In order to allow different programs and different types
 of information to be stored in the 'extra' field in .ZIP
 files, the following structure should be used for all
 programs storing data in this field:

 header1+data1 + header2+data2 . . .

 Each header should consist of:

 Header ID - 2 bytes
 Data Size - 2 bytes

 Note: all fields stored in Intel low-byte/high-byte order.

 The Header ID field indicates the type of data that is in
 the following data block.

 Header ID's of 0 thru 31 are reserved for use by PKWARE.
 The remaining ID's can be used by third party vendors for
 proprietary usage.

 The current Header ID mappings defined by PKWARE are:

 0x0001 ZIP64 extended information extra field
 0x0007 AV Info
 0x0008 Reserved for future Unicode file name data (PFS)
 0x0009 OS/2
 0x000a NTFS 
 0x000c OpenVMS
 0x000d Unix
 0x000e Reserved for file stream and fork descriptors
 0x000f Patch Descriptor
 0x0014 PKCS#7 Store for X.509 Certificates
 0x0015 X.509 Certificate ID and Signature for 
 individual file
 0x0016 X.509 Certificate ID for Central Directory
 0x0017 Strong Encryption Header
 0x0018 Record Management Controls
 0x0019 PKCS#7 Encryption Recipient Certificate List
 0x0065 IBM S/390 (Z390), AS/400 (I400) attributes 
 - uncompressed
 0x0066 Reserved for IBM S/390 (Z390), AS/400 (I400) 
 attributes - compressed

 Third party mappings commonly used are:


 0x07c8 Macintosh
 0x2605 ZipIt Macintosh
 0x2705 ZipIt Macintosh 1.3.5+
 0x2805 ZipIt Macintosh 1.3.5+
 0x334d Info-ZIP Macintosh
 0x4341 Acorn/SparkFS 
 0x4453 Windows NT security descriptor (binary ACL)
 0x4704 VM/CMS
 0x470f MVS
 0x4b46 FWKCS MD5 (see below)
 0x4c41 OS/2 access control list (text ACL)
 0x4d49 Info-ZIP OpenVMS
 0x4f4c Xceed original location extra field
 0x5356 AOS/VS (ACL)
 0x5455 extended timestamp
 0x554e Xceed unicode extra field
 0x5855 Info-ZIP Unix (original, also OS/2, NT, etc)
 0x6542 BeOS/BeBox
 0x756e ASi Unix
 0x7855 Info-ZIP Unix (new)
 0xfd4a SMS/QDOS

 Detailed descriptions of Extra Fields defined by third 
 party mappings will be documented as information on
 these data structures is made available to PKWARE. 
 PKWARE does not guarantee the accuracy of any published
 third party data.

 The Data Size field indicates the size of the following
 data block. Programs can use this value to skip to the
 next header block, passing over any data blocks that are
 not of interest.

 Note: As stated above, the size of the entire .ZIP file
 header, including the file name, comment, and extra
 field should not exceed 64K in size.

 In case two different programs should appropriate the same
 Header ID value, it is strongly recommended that each
 program place a unique signature of at least two bytes in
 size (and preferably 4 bytes or bigger) at the start of
 each data area. Every program should verify that its
 unique signature is present, in addition to the Header ID
 value being correct, before assuming that it is a block of
 known type.

 -ZIP64 Extended Information Extra Field (0x0001):

 The following is the layout of the ZIP64 extended 
 information "extra" block. If one of the size or
 offset fields in the Local or Central directory
 record is too small to hold the required data,
 a ZIP64 extended information record is created.
 The order of the fields in the ZIP64 extended 
 information record is fixed, but the fields will
 only appear if the corresponding Local or Central
 directory record field is set to 0xFFFF or 0xFFFFFFFF.

 Note: all fields stored in Intel low-byte/high-byte order.

 Value Size Description
 ----- ---- -----------
 (ZIP64) 0x0001 2 bytes Tag for this "extra" block type
 Size 2 bytes Size of this "extra" block
 Original 
 Size 8 bytes Original uncompressed file size
 Compressed
 Size 8 bytes Size of compressed data
 Relative Header
 Offset 8 bytes Offset of local header record
 Disk Start
 Number 4 bytes Number of the disk on which
 this file starts 

 This entry in the Local header must include BOTH original
 and compressed file sizes.

 -OS/2 Extra Field (0x0009):

 The following is the layout of the OS/2 attributes "extra" 
 block. (Last Revision 09/05/95)

 Note: all fields stored in Intel low-byte/high-byte order.

 Value Size Description
 ----- ---- -----------
 (OS/2) 0x0009 2 bytes Tag for this "extra" block type
 TSize 2 bytes Size for the following data block
 BSize 4 bytes Uncompressed Block Size
 CType 2 bytes Compression type
 EACRC 4 bytes CRC value for uncompress block
 (var) variable Compressed block

 The OS/2 extended attribute structure (FEA2LIST) is 
 compressed and then stored in it's entirety within this 
 structure. There will only ever be one "block" of data in 
 VarFields[].

 -NTFS Extra Field (0x000a):

 The following is the layout of the NTFS attributes 
 "extra" block. (Note: At this time the Mtime, Atime
 and Ctime values may be used on any WIN32 system.) 

 Note: all fields stored in Intel low-byte/high-byte order.

 Value Size Description
 ----- ---- -----------
 (NTFS) 0x000a 2 bytes Tag for this "extra" block type
 TSize 2 bytes Size of the total "extra" block
 Reserved 4 bytes Reserved for future use
 Tag1 2 bytes NTFS attribute tag value #1
 Size1 2 bytes Size of attribute #1, in bytes
 (var.) Size1 Attribute #1 data
 .
 .
 .
 TagN 2 bytes NTFS attribute tag value #N
 SizeN 2 bytes Size of attribute #N, in bytes
 (var.) SizeN Attribute #N data

 For NTFS, values for Tag1 through TagN are as follows:
 (currently only one set of attributes is defined for NTFS)

 Tag Size Description
 ----- ---- -----------
 0x0001 2 bytes Tag for attribute #1 
 Size1 2 bytes Size of attribute #1, in bytes
 Mtime 8 bytes File last modification time
 Atime 8 bytes File last access time
 Ctime 8 bytes File creation time

 -OpenVMS Extra Field (0x000c):

 The following is the layout of the OpenVMS attributes 
 "extra" block.

 Note: all fields stored in Intel low-byte/high-byte order.

 Value Size Description
 ----- ---- -----------
 (VMS) 0x000c 2 bytes Tag for this "extra" block type
 TSize 2 bytes Size of the total "extra" block
 CRC 4 bytes 32-bit CRC for remainder of the block
 Tag1 2 bytes OpenVMS attribute tag value #1
 Size1 2 bytes Size of attribute #1, in bytes
 (var.) Size1 Attribute #1 data
 .
 .
 .
 TagN 2 bytes OpenVMS attribute tage value #N
 SizeN 2 bytes Size of attribute #N, in bytes
 (var.) SizeN Attribute #N data

 Rules:

 1. There will be one or more of attributes present, which 
 will each be preceded by the above TagX & SizeX values. 
 These values are identical to the ATR$C_XXXX and 
 ATR$S_XXXX constants which are defined in ATR.H under 
 OpenVMS C. Neither of these values will ever be zero.

 2. No word alignment or padding is performed.

 3. A well-behaved PKZIP/OpenVMS program should never produce
 more than one sub-block with the same TagX value. Also,
 there will never be more than one "extra" block of type
 0x000c in a particular directory record.

 -UNIX Extra Field (0x000d):

 The following is the layout of the Unix "extra" block.
 Note: all fields are stored in Intel low-byte/high-byte 
 order.

 Value Size Description
 ----- ---- -----------
 (UNIX) 0x000d 2 bytes Tag for this "extra" block type
 TSize 2 bytes Size for the following data block
 Atime 4 bytes File last access time
 Mtime 4 bytes File last modification time
 Uid 2 bytes File user ID
 Gid 2 bytes File group ID
 (var) variable Variable length data field

 The variable length data field will contain file type 
 specific data. Currently the only values allowed are
 the original "linked to" file names for hard or symbolic 
 links, and the major and minor device node numbers for
 character and block device nodes. Since device nodes
 cannot be either symbolic or hard links, only one set of
 variable length data is stored. Link files will have the
 name of the original file stored. This name is NOT NULL
 terminated. Its size can be determined by checking TSize -
 1. Device entries will have eight bytes stored as two 4
 byte entries (in little endian format). The first entry
 will be the major device number, and the second the minor
 device number.
 
 -PATCH Descriptor Extra Field (0x000f):

 The following is the layout of the Patch Descriptor "extra"
 block.

 Note: all fields stored in Intel low-byte/high-byte order.

 Value Size Description
 ----- ---- -----------
 (Patch) 0x000f 2 bytes Tag for this "extra" block type
 TSize 2 bytes Size of the total "extra" block
 Version 2 bytes Version of the descriptor
 Flags 4 bytes Actions and reactions (see below) 
 OldSize 4 bytes Size of the file about to be patched 
 OldCRC 4 bytes 32-bit CRC of the file to be patched 
 NewSize 4 bytes Size of the resulting file 
 NewCRC 4 bytes 32-bit CRC of the resulting file 

 Actions and reactions

 Bits Description
 ---- ----------------
 0 Use for auto detection
 1 Treat as a self-patch
 2-3 RESERVED
 4-5 Action (see below)
 6-7 RESERVED
 8-9 Reaction (see below) to absent file 
 10-11 Reaction (see below) to newer file
 12-13 Reaction (see below) to unknown file
 14-15 RESERVED
 16-31 RESERVED

 Actions

 Action Value
 ------ ----- 
 none 0
 add 1
 delete 2
 patch 3

 Reactions
 
 Reaction Value
 -------- -----
 ask 0
 skip 1
 ignore 2
 fail 3

 Patch support is provided by PKPatchMaker(tm) technology and is 
 covered under U.S. Patents and Patents Pending.

 -PKCS#7 Store for X.509 Certificates (0x0014):

 This field contains information about each of the certificates 
 files may be signed with. When the Central Directory Encryption 
 feature is enabled for a ZIP file, this record will appear in 
 the Archive Extra Data Record, otherwise it will appear in the 
 first central directory record and will be ignored in any 
 other record.
 
 Note: all fields stored in Intel low-byte/high-byte order.

 Value Size Description
 ----- ---- -----------
 (Store) 0x0014 2 bytes Tag for this "extra" block type
 TSize 2 bytes Size of the store data
 TData TSize Data about the store


 -X.509 Certificate ID and Signature for individual file (0x0015):

 This field contains the information about which certificate in 
 the PKCS#7 store was used to sign a particular file. It also 
 contains the signature data. This field can appear multiple 
 times, but can only appear once per certificate.

 Note: all fields stored in Intel low-byte/high-byte order.

 Value Size Description
 ----- ---- -----------
 (CID) 0x0015 2 bytes Tag for this "extra" block type
 TSize 2 bytes Size of data that follows
 TData TSize Signature Data

 -X.509 Certificate ID and Signature for central directory (0x0016):

 This field contains the information about which certificate in 
 the PKCS#7 store was used to sign the central directory structure.
 When the Central Directory Encryption feature is enabled for a 
 ZIP file, this record will appear in the Archive Extra Data Record, 
 otherwise it will appear in the first central directory record.

 Note: all fields stored in Intel low-byte/high-byte order.

 Value Size Description
 ----- ---- -----------
 (CDID) 0x0016 2 bytes Tag for this "extra" block type
 TSize 2 bytes Size of data that follows
 TData TSize Data

 -Strong Encryption Header (0x0017) (EFS):

 Value Size Description
 ----- ---- -----------
 0x0017 2 bytes Tag for this "extra" block type
 TSize 2 bytes Size of data that follows
 Format 2 bytes Format definition for this record
 AlgID 2 bytes Encryption algorithm identifier
 Bitlen 2 bytes Bit length of encryption key
 Flags 2 bytes Processing flags
 CertData TSize-8 Certificate decryption extra field data
 (refer to the explanation for CertData
 in the section describing the 
 Certificate Processing Method under 
 the Strong Encryption Specification)


 -Record Management Controls (0x0018):

 Value Size Description
 ----- ---- -----------
(Rec-CTL) 0x0018 2 bytes Tag for this "extra" block type
 CSize 2 bytes Size of total extra block data
 Tag1 2 bytes Record control attribute 1
 Size1 2 bytes Size of attribute 1, in bytes
 Data1 Size1 Attribute 1 data
 .
 .
 .
 TagN 2 bytes Record control attribute N
 SizeN 2 bytes Size of attribute N, in bytes
 DataN SizeN Attribute N data


 -PKCS#7 Encryption Recipient Certificate List (0x0019): (EFS)

 This field contains the information about each of the certificates
 that files may be encrypted with. This field should only appear 
 in the archive extra data record. This field is not required and 
 serves only to aide archive modifications by preserving public 
 encryption data. Individual security requirements may dictate 
 that this data be omitted to deter information exposure.

 Note: all fields stored in Intel low-byte/high-byte order.

 Value Size Description
 ----- ---- -----------
 (CStore) 0x0019 2 bytes Tag for this "extra" block type
 TSize 2 bytes Size of the store data
 TData TSize Data about the store

 TData:

 Value Size Description
 ----- ---- -----------
 Version 2 bytes Format version number - must 0x0001 at this time
 CStore (var) PKCS#7 data blob


 -MVS Extra Field (0x0065):

 The following is the layout of the MVS "extra" block.
 Note: Some fields are stored in Big Endian format.
 All text is in EBCDIC format unless otherwise specified.

 Value Size Description
 ----- ---- -----------
 (MVS) 0x0065 2 bytes Tag for this "extra" block type
 TSize 2 bytes Size for the following data block
 ID 4 bytes EBCDIC "Z390" 0xE9F3F9F0 or
 "T4MV" for TargetFour
 (var) TSize-4 Attribute data


 -OS/400 Extra Field (0x0065):

 The following is the layout of the OS/400 "extra" block.
 Note: Some fields are stored in Big Endian format.
 All text is in EBCDIC format unless otherwise specified.

 Value Size Description
 ----- ---- -----------
 (OS400) 0x0065 2 bytes Tag for this "extra" block type
 TSize 2 bytes Size for the following data block
 ID 4 bytes EBCDIC "I400" 0xC9F4F0F0 or
 "T4MV" for TargetFour
 (var) TSize-4 Attribute data


 Third-party Mappings:
 
 -ZipIt Macintosh Extra Field (long) (0x2605):

 The following is the layout of the ZipIt extra block 
 for Macintosh. The local-header and central-header versions 
 are identical. This block must be present if the file is 
 stored MacBinary-encoded and it should not be used if the file 
 is not stored MacBinary-encoded.

 Value Size Description
 ----- ---- -----------
 (Mac2) 0x2605 Short tag for this extra block type
 TSize Short total data size for this block
 "ZPIT" beLong extra-field signature
 FnLen Byte length of FileName
 FileName variable full Macintosh filename
 FileType Byte[4] four-byte Mac file type string
 Creator Byte[4] four-byte Mac creator string


 -ZipIt Macintosh Extra Field (short, for files) (0x2705):

 The following is the layout of a shortened variant of the
 ZipIt extra block for Macintosh (without "full name" entry).
 This variant is used by ZipIt 1.3.5 and newer for entries of
 files (not directories) that do not have a MacBinary encoded
 file. The local-header and central-header versions are identical.

 Value Size Description
 ----- ---- -----------
 (Mac2b) 0x2705 Short tag for this extra block type
 TSize Short total data size for this block (12)
 "ZPIT" beLong extra-field signature
 FileType Byte[4] four-byte Mac file type string
 Creator Byte[4] four-byte Mac creator string
 fdFlags beShort attributes from FInfo.frFlags,
 may be omitted
 0x0000 beShort reserved, may be omitted


 -ZipIt Macintosh Extra Field (short, for directories) (0x2805):

 The following is the layout of a shortened variant of the
 ZipIt extra block for Macintosh used only for directory
 entries. This variant is used by ZipIt 1.3.5 and newer to 
 save some optional Mac-specific information about directories.
 The local-header and central-header versions are identical.

 Value Size Description
 ----- ---- -----------
 (Mac2c) 0x2805 Short tag for this extra block type
 TSize Short total data size for this block (12)
 "ZPIT" beLong extra-field signature
 frFlags beShort attributes from DInfo.frFlags, may
 be omitted
 View beShort ZipIt view flag, may be omitted


 The View field specifies ZipIt-internal settings as follows:

 Bits of the Flags:
 bit 0 if set, the folder is shown expanded (open)
 when the archive contents are viewed in ZipIt.
 bits 1-15 reserved, zero;


 -FWKCS MD5 Extra Field (0x4b46):

 The FWKCS Contents_Signature System, used in
 automatically identifying files independent of file name,
 optionally adds and uses an extra field to support the
 rapid creation of an enhanced contents_signature:

 Header ID = 0x4b46
 Data Size = 0x0013
 Preface = 'M','D','5'
 followed by 16 bytes containing the uncompressed file's
 128_bit MD5 hash(1), low byte first.

 When FWKCS revises a .ZIP file central directory to add
 this extra field for a file, it also replaces the
 central directory entry for that file's uncompressed
 file length with a measured value.

 FWKCS provides an option to strip this extra field, if
 present, from a .ZIP file central directory. In adding
 this extra field, FWKCS preserves .ZIP file Authenticity
 Verification; if stripping this extra field, FWKCS
 preserves all versions of AV through PKZIP version 2.04g.

 FWKCS, and FWKCS Contents_Signature System, are
 trademarks of Frederick W. Kantor.

 (1) R. Rivest, RFC1321.TXT, MIT Laboratory for Computer
 Science and RSA Data Security, Inc., April 1992.
 ll.76-77: "The MD5 algorithm is being placed in the
 public domain for review and possible adoption as a
 standard."

 file comment: (Variable)

 The comment for this file.

 number of this disk: (2 bytes)

 The number of this disk, which contains central
 directory end record. If an archive is in zip64 format
 and the value in this field is 0xFFFF, the size will 
 be in the corresponding 4 byte zip64 end of central 
 directory field.


 number of the disk with the start of the central
 directory: (2 bytes)

 The number of the disk on which the central
 directory starts. If an archive is in zip64 format
 and the value in this field is 0xFFFF, the size will 
 be in the corresponding 4 byte zip64 end of central 
 directory field.

 total number of entries in the central dir on 
 this disk: (2 bytes)

 The number of central directory entries on this disk.
 If an archive is in zip64 format and the value in 
 this field is 0xFFFF, the size will be in the 
 corresponding 8 byte zip64 end of central 
 directory field.

 total number of entries in the central dir: (2 bytes)

 The total number of files in the .ZIP file. If an 
 archive is in zip64 format and the value in this field
 is 0xFFFF, the size will be in the corresponding 8 byte 
 zip64 end of central directory field.

 size of the central directory: (4 bytes)

 The size (in bytes) of the entire central directory.
 If an archive is in zip64 format and the value in 
 this field is 0xFFFFFFFF, the size will be in the 
 corresponding 8 byte zip64 end of central 
 directory field.

 offset of start of central directory with respect to
 the starting disk number: (4 bytes)

 Offset of the start of the central directory on the
 disk on which the central directory starts. If an 
 archive is in zip64 format and the value in this 
 field is 0xFFFFFFFF, the size will be in the 
 corresponding 8 byte zip64 end of central 
 directory field.

 .ZIP file comment length: (2 bytes)

 The length of the comment for this .ZIP file.

 .ZIP file comment: (Variable)

 The comment for this .ZIP file. ZIP file comment data
 is stored unsecured. No encryption or data authentication
 is applied to this area at this time. Confidential information
 should not be stored in this section.

 zip64 extensible data sector (variable size)

 (currently reserved for use by PKWARE)


 K. General notes:

 1) All fields unless otherwise noted are unsigned and stored
 in Intel low-byte:high-byte, low-word:high-word order.

 2) String fields are not null terminated, since the
 length is given explicitly.

 3) Local headers should not span disk boundaries. Also, even
 though the central directory can span disk boundaries, no
 single record in the central directory should be split
 across disks.

 4) The entries in the central directory may not necessarily
 be in the same order that files appear in the .ZIP file.

 5) Spanned/Split archives created using PKZIP for Windows
 (V2.50 or greater), PKZIP Command Line (V2.50 or greater),
 or PKZIP Explorer will include a special spanning 
 signature as the first 4 bytes of the first segment of
 the archive. This signature (0x08074b50) will be 
 followed immediately by the local header signature for
 the first file in the archive. A special spanning
 marker may also appear in spanned/split archives if the
 spanning or splitting process starts but only requires
 one segment. In this case the 0x08074b50 signature
 will be replaced with the temporary spanning marker
 signature of 0x30304b50. Spanned/split archives
 created with this special signature are compatible with
 all versions of PKZIP from PKWARE. Split archives can
 only be uncompressed by other versions of PKZIP that
 know how to create a split archive.

 6) If one of the fields in the end of central directory
 record is too small to hold required data, the field
 should be set to -1 (0xFFFF or 0xFFFFFFFF) and the
 Zip64 format record should be created.

 7) The end of central directory record and the
 Zip64 end of central directory locator record must
 reside on the same disk when splitting or spanning
 an archive.

V. UnShrinking - Method 1
-------------------------

Shrinking is a Dynamic Ziv-Lempel-Welch compression algorithm
with partial clearing. The initial code size is 9 bits, and
the maximum code size is 13 bits. Shrinking differs from
conventional Dynamic Ziv-Lempel-Welch implementations in several
respects:

1) The code size is controlled by the compressor, and is not
 automatically increased when codes larger than the current
 code size are created (but not necessarily used). When
 the decompressor encounters the code sequence 256
 (decimal) followed by 1, it should increase the code size
 read from the input stream to the next bit size. No
 blocking of the codes is performed, so the next code at
 the increased size should be read from the input stream
 immediately after where the previous code at the smaller
 bit size was read. Again, the decompressor should not
 increase the code size used until the sequence 256,1 is
 encountered.

2) When the table becomes full, total clearing is not
 performed. Rather, when the compressor emits the code
 sequence 256,2 (decimal), the decompressor should clear
 all leaf nodes from the Ziv-Lempel tree, and continue to
 use the current code size. The nodes that are cleared
 from the Ziv-Lempel tree are then re-used, with the lowest
 code value re-used first, and the highest code value
 re-used last. The compressor can emit the sequence 256,2
 at any time.

VI. Expanding - Methods 2-5
---------------------------

The Reducing algorithm is actually a combination of two
distinct algorithms. The first algorithm compresses repeated
byte sequences, and the second algorithm takes the compressed
stream from the first algorithm and applies a probabilistic
compression method.

The probabilistic compression stores an array of 'follower
sets' S(j), for j=0 to 255, corresponding to each possible
ASCII character. Each set contains between 0 and 32
characters, to be denoted as S(j)[0],...,S(j)[m], where m<32.
The sets are stored at the beginning of the data area for a
Reduced file, in reverse order, with S(255) first, and S(0)
last.

The sets are encoded as { N(j), S(j)[0],...,S(j)[N(j)-1] },
where N(j) is the size of set S(j). N(j) can be 0, in which
case the follower set for S(j) is empty. Each N(j) value is
encoded in 6 bits, followed by N(j) eight bit character values
corresponding to S(j)[0] to S(j)[N(j)-1] respectively. If
N(j) is 0, then no values for S(j) are stored, and the value
for N(j-1) immediately follows.

Immediately after the follower sets, is the compressed data
stream. The compressed data stream can be interpreted for the
probabilistic decompression as follows:

let Last-Character <- 0.
loop until done
 if the follower set S(Last-Character) is empty then
 read 8 bits from the input stream, and copy this
 value to the output stream.
 otherwise if the follower set S(Last-Character) is non-empty then
 read 1 bit from the input stream.
 if this bit is not zero then
 read 8 bits from the input stream, and copy this
 value to the output stream.
 otherwise if this bit is zero then
 read B(N(Last-Character)) bits from the input
 stream, and assign this value to I.
 Copy the value of S(Last-Character)[I] to the
 output stream.

 assign the last value placed on the output stream to
 Last-Character.
end loop

B(N(j)) is defined as the minimal number of bits required to
encode the value N(j)-1.

The decompressed stream from above can then be expanded to
re-create the original file as follows:

let State <- 0.

loop until done
 read 8 bits from the input stream into C.
 case State of
 0: if C is not equal to DLE (144 decimal) then
 copy C to the output stream.
 otherwise if C is equal to DLE then
 let State <- 1.

 1: if C is non-zero then
 let V <- C.
 let Len <- L(V)
 let State <- F(Len).
 otherwise if C is zero then
 copy the value 144 (decimal) to the output stream.
 let State <- 0

 2: let Len <- Len + C
 let State <- 3.

 3: move backwards D(V,C) bytes in the output stream
 (if this position is before the start of the output
 stream, then assume that all the data before the
 start of the output stream is filled with zeros).
 copy Len+3 bytes from this position to the output stream.
 let State <- 0.
 end case
end loop

The functions F,L, and D are dependent on the 'compression
factor', 1 through 4, and are defined as follows:

For compression factor 1:
 L(X) equals the lower 7 bits of X.
 F(X) equals 2 if X equals 127 otherwise F(X) equals 3.
 D(X,Y) equals the (upper 1 bit of X) * 256 + Y + 1.
For compression factor 2:
 L(X) equals the lower 6 bits of X.
 F(X) equals 2 if X equals 63 otherwise F(X) equals 3.
 D(X,Y) equals the (upper 2 bits of X) * 256 + Y + 1.
For compression factor 3:
 L(X) equals the lower 5 bits of X.
 F(X) equals 2 if X equals 31 otherwise F(X) equals 3.
 D(X,Y) equals the (upper 3 bits of X) * 256 + Y + 1.
For compression factor 4:
 L(X) equals the lower 4 bits of X.
 F(X) equals 2 if X equals 15 otherwise F(X) equals 3.
 D(X,Y) equals the (upper 4 bits of X) * 256 + Y + 1.

VII. Imploding - Method 6
-------------------------

The Imploding algorithm is actually a combination of two distinct
algorithms. The first algorithm compresses repeated byte
sequences using a sliding dictionary. The second algorithm is
used to compress the encoding of the sliding dictionary output,
using multiple Shannon-Fano trees.

The Imploding algorithm can use a 4K or 8K sliding dictionary
size. The dictionary size used can be determined by bit 1 in the
general purpose flag word; a 0 bit indicates a 4K dictionary
while a 1 bit indicates an 8K dictionary.

The Shannon-Fano trees are stored at the start of the compressed
file. The number of trees stored is defined by bit 2 in the
general purpose flag word; a 0 bit indicates two trees stored, a
1 bit indicates three trees are stored. If 3 trees are stored,
the first Shannon-Fano tree represents the encoding of the
Literal characters, the second tree represents the encoding of
the Length information, the third represents the encoding of the
Distance information. When 2 Shannon-Fano trees are stored, the
Length tree is stored first, followed by the Distance tree.

The Literal Shannon-Fano tree, if present is used to represent
the entire ASCII character set, and contains 256 values. This
tree is used to compress any data not compressed by the sliding
dictionary algorithm. When this tree is present, the Minimum
Match Length for the sliding dictionary is 3. If this tree is
not present, the Minimum Match Length is 2.

The Length Shannon-Fano tree is used to compress the Length part
of the (length,distance) pairs from the sliding dictionary
output. The Length tree contains 64 values, ranging from the
Minimum Match Length, to 63 plus the Minimum Match Length.

The Distance Shannon-Fano tree is used to compress the Distance
part of the (length,distance) pairs from the sliding dictionary
output. The Distance tree contains 64 values, ranging from 0 to
63, representing the upper 6 bits of the distance value. The
distance values themselves will be between 0 and the sliding
dictionary size, either 4K or 8K.

The Shannon-Fano trees themselves are stored in a compressed
format. The first byte of the tree data represents the number of
bytes of data representing the (compressed) Shannon-Fano tree
minus 1. The remaining bytes represent the Shannon-Fano tree
data encoded as:

 High 4 bits: Number of values at this bit length + 1. (1 - 16)
 Low 4 bits: Bit Length needed to represent value + 1. (1 - 16)

The Shannon-Fano codes can be constructed from the bit lengths
using the following algorithm:

1) Sort the Bit Lengths in ascending order, while retaining the
 order of the original lengths stored in the file.

2) Generate the Shannon-Fano trees:

 Code <- 0
 CodeIncrement <- 0
 LastBitLength <- 0
 i <- number of Shannon-Fano codes - 1 (either 255 or 63)

 loop while i >= 0
 Code = Code + CodeIncrement
 if BitLength(i) <> LastBitLength then
 LastBitLength=BitLength(i)
 CodeIncrement = 1 shifted left (16 - LastBitLength)
 ShannonCode(i) = Code
 i <- i - 1
 end loop

3) Reverse the order of all the bits in the above ShannonCode()
 vector, so that the most significant bit becomes the least
 significant bit. For example, the value 0x1234 (hex) would
 become 0x2C48 (hex).

4) Restore the order of Shannon-Fano codes as originally stored
 within the file.

Example:

 This example will show the encoding of a Shannon-Fano tree
 of size 8. Notice that the actual Shannon-Fano trees used
 for Imploding are either 64 or 256 entries in size.

Example: 0x02, 0x42, 0x01, 0x13

 The first byte indicates 3 values in this table. Decoding the
 bytes:
 0x42 = 5 codes of 3 bits long
 0x01 = 1 code of 2 bits long
 0x13 = 2 codes of 4 bits long

 This would generate the original bit length array of:
 (3, 3, 3, 3, 3, 2, 4, 4)

 There are 8 codes in this table for the values 0 thru 7. Using 
 the algorithm to obtain the Shannon-Fano codes produces:

 Reversed Order Original
Val Sorted Constructed Code Value Restored Length
--- ------ ----------------- -------- -------- ------
0: 2 1100000000000000 11 101 3
1: 3 1010000000000000 101 001 3
2: 3 1000000000000000 001 110 3
3: 3 0110000000000000 110 010 3
4: 3 0100000000000000 010 100 3
5: 3 0010000000000000 100 11 2
6: 4 0001000000000000 1000 1000 4
7: 4 0000000000000000 0000 0000 4

The values in the Val, Order Restored and Original Length columns
now represent the Shannon-Fano encoding tree that can be used for
decoding the Shannon-Fano encoded data. How to parse the
variable length Shannon-Fano values from the data stream is beyond
the scope of this document. (See the references listed at the end of
this document for more information.) However, traditional decoding
schemes used for Huffman variable length decoding, such as the
Greenlaw algorithm, can be successfully applied.

The compressed data stream begins immediately after the
compressed Shannon-Fano data. The compressed data stream can be
interpreted as follows:

loop until done
 read 1 bit from input stream.

 if this bit is non-zero then (encoded data is literal data)
 if Literal Shannon-Fano tree is present
 read and decode character using Literal Shannon-Fano tree.
 otherwise
 read 8 bits from input stream.
 copy character to the output stream.
 otherwise (encoded data is sliding dictionary match)
 if 8K dictionary size
 read 7 bits for offset Distance (lower 7 bits of offset).
 otherwise
 read 6 bits for offset Distance (lower 6 bits of offset).

 using the Distance Shannon-Fano tree, read and decode the
 upper 6 bits of the Distance value.

 using the Length Shannon-Fano tree, read and decode
 the Length value.

 Length <- Length + Minimum Match Length

 if Length = 63 + Minimum Match Length
 read 8 bits from the input stream,
 add this value to Length.

 move backwards Distance+1 bytes in the output stream, and
 copy Length characters from this position to the output
 stream. (if this position is before the start of the output
 stream, then assume that all the data before the start of
 the output stream is filled with zeros).
end loop

VIII. Tokenizing - Method 7
---------------------------

This method is not used by PKZIP.

IX. Deflating - Method 8
------------------------

The Deflate algorithm is similar to the Implode algorithm using
a sliding dictionary of up to 32K with secondary compression
from Huffman/Shannon-Fano codes.

The compressed data is stored in blocks with a header describing
the block and the Huffman codes used in the data block. The header
format is as follows:

 Bit 0: Last Block bit This bit is set to 1 if this is the last
 compressed block in the data.
 Bits 1-2: Block type
 00 (0) - Block is stored - All stored data is byte aligned.
 Skip bits until next byte, then next word = block 
 length, followed by the ones compliment of the block
 length word. Remaining data in block is the stored 
 data.

 01 (1) - Use fixed Huffman codes for literal and distance codes.
 Lit Code Bits Dist Code Bits
 --------- ---- --------- ----
 0 - 143 8 0 - 31 5
 144 - 255 9
 256 - 279 7
 280 - 287 8

 Literal codes 286-287 and distance codes 30-31 are 
 never used but participate in the huffman construction.

 10 (2) - Dynamic Huffman codes. (See expanding Huffman codes)

 11 (3) - Reserved - Flag a "Error in compressed data" if seen.

Expanding Huffman Codes
-----------------------
If the data block is stored with dynamic Huffman codes, the Huffman
codes are sent in the following compressed format:

 5 Bits: # of Literal codes sent - 256 (256 - 286)
 All other codes are never sent.
 5 Bits: # of Dist codes - 1 (1 - 32)
 4 Bits: # of Bit Length codes - 3 (3 - 19)

The Huffman codes are sent as bit lengths and the codes are built as
described in the implode algorithm. The bit lengths themselves are
compressed with Huffman codes. There are 19 bit length codes:

 0 - 15: Represent bit lengths of 0 - 15
 16: Copy the previous bit length 3 - 6 times.
 The next 2 bits indicate repeat length (0 = 3, ... ,3 = 6)
 Example: Codes 8, 16 (+2 bits 11), 16 (+2 bits 10) will
 expand to 12 bit lengths of 8 (1 + 6 + 5)
 17: Repeat a bit length of 0 for 3 - 10 times. (3 bits of length)
 18: Repeat a bit length of 0 for 11 - 138 times (7 bits of length)

The lengths of the bit length codes are sent packed 3 bits per value
(0 - 7) in the following order:

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

The Huffman codes should be built as described in the Implode algorithm
except codes are assigned starting at the shortest bit length, i.e. the
shortest code should be all 0's rather than all 1's. Also, codes with
a bit length of zero do not participate in the tree construction. The
codes are then used to decode the bit lengths for the literal and 
distance tables.

The bit lengths for the literal tables are sent first with the number
of entries sent described by the 5 bits sent earlier. There are up
to 286 literal characters; the first 256 represent the respective 8
bit character, code 256 represents the End-Of-Block code, the remaining
29 codes represent copy lengths of 3 thru 258. There are up to 30
distance codes representing distances from 1 thru 32k as described
below.

 Length Codes
 ------------
 Extra Extra Extra Extra
 Code Bits Length Code Bits Lengths Code Bits Lengths Code Bits Length(s)
 ---- ---- ------ ---- ---- ------- ---- ---- ------- ---- ---- ---------
 257 0 3 265 1 11,12 273 3 35-42 281 5 131-162
 258 0 4 266 1 13,14 274 3 43-50 282 5 163-194
 259 0 5 267 1 15,16 275 3 51-58 283 5 195-226
 260 0 6 268 1 17,18 276 3 59-66 284 5 227-257
 261 0 7 269 2 19-22 277 4 67-82 285 0 258
 262 0 8 270 2 23-26 278 4 83-98
 263 0 9 271 2 27-30 279 4 99-114
 264 0 10 272 2 31-34 280 4 115-130

 Distance Codes
 --------------
 Extra Extra Extra Extra
 Code Bits Dist Code Bits Dist Code Bits Distance Code Bits Distance
 ---- ---- ---- ---- ---- ------ ---- ---- -------- ---- ---- --------
 0 0 1 8 3 17-24 16 7 257-384 24 11 4097-6144
 1 0 2 9 3 25-32 17 7 385-512 25 11 6145-8192
 2 0 3 10 4 33-48 18 8 513-768 26 12 8193-12288
 3 0 4 11 4 49-64 19 8 769-1024 27 12 12289-16384
 4 1 5,6 12 5 65-96 20 9 1025-1536 28 13 16385-24576
 5 1 7,8 13 5 97-128 21 9 1537-2048 29 13 24577-32768
 6 2 9-12 14 6 129-192 22 10 2049-3072
 7 2 13-16 15 6 193-256 23 10 3073-4096

The compressed data stream begins immediately after the
compressed header data. The compressed data stream can be
interpreted as follows:

do
 read header from input stream.

 if stored block
 skip bits until byte aligned
 read count and 1's compliment of count
 copy count bytes data block
 otherwise
 loop until end of block code sent
 decode literal character from input stream
 if literal < 256
 copy character to the output stream
 otherwise
 if literal = end of block
 break from loop
 otherwise
 decode distance from input stream

 move backwards distance bytes in the output stream, and
 copy length characters from this position to the output
 stream.
 end loop
while not last block

if data descriptor exists
 skip bits until byte aligned
 read crc and sizes
endif

X. Enhanced Deflating - Method 9
--------------------------------

The Enhanced Deflating algorithm is similar to Deflate but
uses a sliding dictionary of up to 64K. Deflate64(tm) is supported
by the Deflate extractor. 

XI. BZIP2 - Method 12
---------------------

BZIP2 is an open-source data compression algorithm developed by 
Julian Seward. Information and source code for this algorithm
can be found on the internet.

XII. Traditional PKWARE Encryption
----------------------------------

The following information discusses the decryption steps
required to support traditional PKWARE encryption. This
form of encryption is considered weak by today's standards
and its use is recommended only for situations with
low security needs or for compatibility with older .ZIP 
applications.

XIII. Decryption
----------------

The encryption used in PKZIP was generously supplied by Roger
Schlafly. PKWARE is grateful to Mr. Schlafly for his expert
help and advice in the field of data encryption.

PKZIP encrypts the compressed data stream. Encrypted files must
be decrypted before they can be extracted.

Each encrypted file has an extra 12 bytes stored at the start of
the data area defining the encryption header for that file. The
encryption header is originally set to random values, and then
itself encrypted, using three, 32-bit keys. The key values are
initialized using the supplied encryption password. After each byte
is encrypted, the keys are then updated using pseudo-random number
generation techniques in combination with the same CRC-32 algorithm
used in PKZIP and described elsewhere in this document.

The following is the basic steps required to decrypt a file:

1) Initialize the three 32-bit keys with the password.
2) Read and decrypt the 12-byte encryption header, further
 initializing the encryption keys.
3) Read and decrypt the compressed data stream using the
 encryption keys.

Step 1 - Initializing the encryption keys
-----------------------------------------

Key(0) <- 305419896
Key(1) <- 591751049
Key(2) <- 878082192

loop for i <- 0 to length(password)-1
 update_keys(password(i))
end loop

Where update_keys() is defined as:

update_keys(char):
 Key(0) <- crc32(key(0),char)
 Key(1) <- Key(1) + (Key(0) & 000000ffH)
 Key(1) <- Key(1) * 134775813 + 1
 Key(2) <- crc32(key(2),key(1) >> 24)
end update_keys

Where crc32(old_crc,char) is a routine that given a CRC value and a
character, returns an updated CRC value after applying the CRC-32
algorithm described elsewhere in this document.

Step 2 - Decrypting the encryption header
-----------------------------------------

The purpose of this step is to further initialize the encryption
keys, based on random data, to render a plaintext attack on the
data ineffective.

Read the 12-byte encryption header into Buffer, in locations
Buffer(0) thru Buffer(11).

loop for i <- 0 to 11
 C <- buffer(i) ^ decrypt_byte()
 update_keys(C)
 buffer(i) <- C
end loop

Where decrypt_byte() is defined as:

unsigned char decrypt_byte()
 local unsigned short temp
 temp <- Key(2) | 2
 decrypt_byte <- (temp * (temp ^ 1)) >> 8
end decrypt_byte

After the header is decrypted, the last 1 or 2 bytes in Buffer
should be the high-order word/byte of the CRC for the file being
decrypted, stored in Intel low-byte/high-byte order. Versions of
PKZIP prior to 2.0 used a 2 byte CRC check; a 1 byte CRC check is
used on versions after 2.0. This can be used to test if the password
supplied is correct or not.

Step 3 - Decrypting the compressed data stream
----------------------------------------------

The compressed data stream can be decrypted as follows:

loop until done
 read a character into C
 Temp <- C ^ decrypt_byte()
 update_keys(temp)
 output Temp
end loop


XIV. Strong Encryption Specification (EFS)
------------------------------------------

Version 5.x of this specification introduced support for strong 
encryption algorithms. These algorithms can be used with either 
a password or an X.509v3 digital certificate to encrypt each file. 
This format specification supports either password or certificate 
based encryption to meet the security needs of today, to enable 
interoperability between users within both PKI and non-PKI 
environments, and to ensure interoperability between different 
computing platforms that are running a ZIP program. 

Password based encryption is the most common form of encryption 
people are familiar with. However, inherent weaknesses with 
passwords (e.g. susceptibility to dictionary/brute force attack) 
as well as password management and support issues make certificate 
based encryption a more secure and scalable option. Industry 
efforts and support are defining and moving towards more advanced 
security solutions built around X.509v3 digital certificates and 
Public Key Infrastructures(PKI) because of the greater scalability, 
administrative options, and more robust security over traditional 
password based encryption. 

Most standard encryption algorithms are supported with this
specification. Reference implementations for many of these 
algorithms are available from either commercial or open source 
distributors. Readily available cryptographic toolkits make
implementation of the encryption features straight-forward. 
This document is not intended to provide a treatise on data 
encryption principles or theory. Its purpose is to document the 
data structures required for implementing interoperable data 
encryption within the .ZIP format. It is strongly recommended that 
you have a good understanding of data encryption before reading 
further.

The algorithms introduced in Version 5.0 of this specification 
include:

 RC2 40 bit, 64 bit, and 128 bit
 RC4 40 bit, 64 bit, and 128 bit
 DES
 3DES 112 bit and 168 bit
 
Version 5.1 adds support for the following:

 AES 128 bit, 192 bit, and 256 bit


Version 6.1 introduces encryption data changes to support 
interoperability with SmartCard and USB Token certificate storage 
methods which do not support the OAEP strengthening standard.

Version 6.2 introduces support for encrypting metadata by compressing 
and encrypting the central directory data structure to reduce information 
leakage. Information leakage can occur in legacy ZIP applications 
through exposure of information about a file even though that file is 
stored encrypted. The information exposed consists of file 
characteristics stored within the records and fields defined by this 
specification. This includes data such as a files name, its original 
size, timestamp and CRC32 value. 

Central Directory Encryption provides greater protection against 
information leakage by encrypting the Central Directory structure and 
by masking key values that are replicated in the unencrypted Local 
Header. ZIP compatible programs that cannot interpret an encrypted 
Central Directory structure cannot rely on the data in the corresponding 
Local Header for decompression information. 

Extra Field records that may contain information about a file that should 
not be exposed should not be stored in the Local Header and should only 
be written to the Central Directory where they can be encrypted. This 
design currently does not support streaming. Information in the End of 
Central Directory record, the ZIP64 End of Central Directory Locator, 
and the ZIP64 End of Central Directory record are not encrypted. Access 
to view data on files within a ZIP file with an encrypted Central Directory
requires the appropriate password or private key for decryption prior to 
viewing any files, or any information about the files, in the archive. 

Older ZIP compatible programs not familiar with the Central Directory 
Encryption feature will no longer be able to recognize the Central 
Directory and may assume the ZIP file is corrupt. Programs that 
attempt streaming access using Local Headers will see invalid 
information for each file. Central Directory Encryption need not be 
used for every ZIP file. Its use is recommended for greater security. 
ZIP files not using Central Directory Encryption should operate as 
in the past. 

The details of the strong encryption specification for certificates 
remain under development as design and testing issues are worked out 
for the range of algorithms, encryption methods, certificate processing 
and cross-platform support necessary to meet the advanced security needs 
of .ZIP file users today and in the future. 

This feature specification is intended to support basic encryption needs 
of today, such as password support. However this specification is also 
designed to lay the foundation for future advanced security needs.

Encryption provides data confidentiality and privacy. It is 
recommended that you combine X.509 digital signing with encryption 
to add authentication and non-repudiation.


Single Password Symmetric Encryption Method:
-------------------------------------------

The Single Password Symmetric Encryption Method using strong 
encryption algorithms operates similarly to the traditional 
PKWARE encryption defined in this format. Additional data 
structures are added to support the processing needs of the 
strong algorithms.

The Strong Encryption data structures are:

1. General Purpose Bits - Bits 0 and 6 of the General Purpose bit 
flag in both local and central header records. Both bits set 
indicates strong encryption. Bit 13, when set indicates the Central
Directory is encrypted and that selected fields in the Local Header
are masked to hide their actual value.


2. Extra Field 0x0017 in central header only.

 Fields to consider in this record are:

 Format - the data format identifier for this record. The only
 value allowed at this time is the integer value 2.

 AlgId - integer identifier of the encryption algorithm from the
 following range

 0x6601 - DES
 0x6602 - RC2 (version needed to extract < 5.2)
 0x6603 - 3DES 168
 0x6609 - 3DES 112
 0x660E - AES 128 
 0x660F - AES 192 
 0x6610 - AES 256 
 0x6702 - RC2 (version needed to extract >= 5.2)
 0x6801 - RC4
 0xFFFF - Unknown algorithm

 Bitlen - Explicit bit length of key

 40
 56
 64
 112
 128
 168
 192
 256
 
 Flags - Processing flags needed for decryption

 0x0001 - Password is required to decrypt
 0x0002 - Certificates only
 0x0003 - Password or certificate required to decrypt

 Values > 0x0003 reserved for certificate processing


3. Decryption header record preceding compressed file data.

 -Decryption Header:

 Value Size Description
 ----- ---- -----------
 IVSize 2 bytes Size of initialization vector (IV)
 IVData IVSize Initialization vector for this file
 Size 4 bytes Size of remaining decryption header data
 Format 2 bytes Format definition for this record
 AlgID 2 bytes Encryption algorithm identifier
 Bitlen 2 bytes Bit length of encryption key
 Flags 2 bytes Processing flags
 ErdSize 2 bytes Size of Encrypted Random Data
 ErdData ErdSize Encrypted Random Data
 Reserved1 4 bytes Reserved certificate processing data
 Reserved2 (var) Reserved for certificate processing data
 VSize 2 bytes Size of password validation data
 VData VSize-4 Password validation data
 VCRC32 4 bytes Standard ZIP CRC32 of password validation data

 IVData - The size of the IV should match the algorithm block size.
 The IVData can be completely random data. If the size of
 the randomly generated data does not match the block size
 it should be complemented with zero's or truncated as
 necessary. If IVSize is 0,then IV = CRC32 + Uncompressed
 File Size (as a 64 bit little-endian, unsigned integer value).

 Format - the data format identifier for this record. The only
 value allowed at this time is the integer value 3.

 AlgId - integer identifier of the encryption algorithm from the
 following range

 0x6601 - DES
 0x6602 - RC2 (version needed to extract < 5.2)
 0x6603 - 3DES 168
 0x6609 - 3DES 112
 0x660E - AES 128 
 0x660F - AES 192 
 0x6610 - AES 256 
 0x6702 - RC2 (version needed to extract >= 5.2)
 0x6801 - RC4
 0xFFFF - Unknown algorithm

 Bitlen - Explicit bit length of key

 40
 56
 64
 112
 128
 168
 192
 256
 
 Flags - Processing flags needed for decryption

 0x0001 - Password is required to decrypt
 0x0002 - Certificates only
 0x0003 - Password or certificate required to decrypt

 Values > 0x0003 reserved for certificate processing

 ErdData - Encrypted random data is used to generate a file
 session key for encrypting each file. SHA1 is 
 used to calculate hash data used to derive keys.
 File session keys are derived from a master session
 key generated from the user-supplied password.
 If the Flags field in the decryption header contains 
 the value 0x4000, then the ErdData field must be 
 decrypted using 3DES.


 Reserved1 - Reserved for certificate processing, if value is
 zero, then Reserved2 data is absent. See the explanation
 under the Certificate Processing Method for details on
 this data structure.

 Reserved2 - If present, the size of the Reserved2 data structure 
 is located by skipping the first 4 bytes of this field 
 and using the next 2 bytes as the remaining size. See
 the explanation under the Certificate Processing Method
 for details on this data structure.

 VSize - This size value will always include the 4 bytes of the
 VCRC32 data and will be greater than 4 bytes.

 VData - Random data for password validation. This data is VSize
 in length and VSize must be a multiple of the encryption
 block size. VCRC32 is a checksum value of VData. 
 VData and VCRC32 are stored encrypted and start the
 stream of encrypted data for a file.

4. Single Password Central Directory Encryption

Central Directory Encryption is achieved within the .ZIP format by 
encrypting the Central Directory structure. This encapsulates the metadata 
most often used for processing .ZIP files. Additional metadata is stored for 
redundancy in the Local Header for each file. The process of concealing 
metadata by encrypting the Central Directory does not protect the data within 
the Local Header. To avoid information leakage from the exposed metadata 
in the Local Header, the fields containing information about a file are masked. 

Local Header:

Masking replaces the true content of the fields for a file in the Local 
Header with false information. When masked, the Local Header is not 
suitable for streaming access and the options for data recovery of damaged
archives is reduced. Extra Data fields that may contain confidential
data should not be stored within the Local Header. The value set into
the Version needed to extract field should be the correct value needed to
extract the file without regard to Central Directory Encryption. The fields 
within the Local Header targeted for masking when the Central Directory is 
encrypted are:

 Field Name Mask Value
 ------------------ ---------------------------
 compression method 0
 last mod file time 0
 last mod file date 0
 crc-32 0
 compressed size 0
 uncompressed size 0
 file name (variable size) Base 16 value from the
 range 1 - FFFFFFFFFFFFFFFF
 represented as a string whose
 size will be set into the
 file name length field

The Base 16 value assigned as a masked file name is simply a sequentially
incremented value for each file starting with 1 for the first file. 
Modifications to a ZIP file may cause different values to be stored for 
each file. For compatibility, the file name field in the Local Header 
should never be left blank. As of Version 6.2 of this specification, 
the Compression Method and Compressed Size fields are not yet masked.

Encrypting the Central Directory:

Encryption of the Central Directory does not include encryption of the 
Central Directory Signature data, the ZIP64 End of Central Directory
record, the ZIP64 End of Central Directory Locator, or the End
of Central Directory record. The ZIP file comment data is never
encrypted.

Before encrypting the Central Directory, it may optionally be compressed.
Compression is not required, but for storage efficiency it is assumed
this structure will be compressed before encrypting. Similarly, this 
specification supports compressing the Central Directory without
requiring that it also be encrypted. Early implementations of this
feature will assume the encryption method applied to files matches the 
encryption applied to the Central Directory.

Encryption of the Central Directory is done in a manner similar to
that of file encryption. The encrypted data is preceded by a 
decryption header. The decryption header is known as the Archive
Decryption Header. The fields of this record are identical to
the decryption header preceding each encrypted file. The location
of the Archive Decryption Header is determined by the value in the
Start of the Central Directory field in the ZIP64 End of Central
Directory record. When the Central Directory is encrypted, the
ZIP64 End of Central Directory record will always be present.

The layout of the ZIP64 End of Central Directory record for all
versions starting with 6.2 of this specification will follow the
Version 2 format. The Version 2 format is as follows:

The first 48 bytes will remain identical to that of Version 1.
The record signature for both Version 1 and Version 2 will be
0x06064b50. Immediately following the 48th byte, which identifies 
the end of the field known as the Offset of Start of Central 
Directory With Respect to the Starting Disk Number will begin the 
new fields defining Version 2 of this record. 

New fields for Version 2:

Note: all fields stored in Intel low-byte/high-byte order.

 Value Size Description
 ----- ---- -----------
 Compression Method 2 bytes Method used to compress the
 Central Directory
 Compressed Size 8 bytes Size of the compressed data
 Original Size 8 bytes Original uncompressed size
 AlgId 2 bytes Encryption algorithm ID
 BitLen 2 bytes Encryption key length
 Flags 2 bytes Encryption flags
 HashID 2 bytes Hash algorithm identifier
 Hash Length 2 bytes Length of hash data
 Hash Data (variable) Hash data

The Compression Method accepts the same range of values as the 
corresponding field in the Central Header.

The Compressed Size and Original Size values will not include the
data of the Central Directory Signature which is compressed or
encrypted.

The AlgId, BitLen, and Flags fields accept the same range of values
the corresponding fields within the 0x0017 record. 

Hash ID identifies the algorithm used to hash the Central Directory 
data. This data does not have to be hashed, in which case the
values for both the HashID and Hash Length will be 0. Possible 
values for HashID are:

 Value Algorithm
 ------ ---------
 0x0000 none
 0x0001 CRC32
 0x8003 MD5
 0x8004 SHA1

When the Central Directory data is signed, the same hash algorithm
used to hash the Central Directory for signing should be used.
This is recommended for processing efficiency, however, it is 
permissible for any of the above algorithms to be used independent 
of the signing process.

The Hash Data will contain the hash data for the Central Directory.
The length of this data will vary depending on the algorithm used.

The Version Needed to Extract should be set to 62.

The value for the Total Number of Entries on the Current Disk will
be 0. These records will no longer support random access when
encrypting the Central Directory.

When the Central Directory is compressed and/or encrypted, the
End of Central Directory record will store the value 0xFFFFFFFF
as the value for the Total Number of Entries in the Central
Directory. The value stored in the Total Number of Entries in
the Central Directory on this Disk field will be 0. The actual
values will be stored in the equivalent fields of the ZIP64
End of Central Directory record.

Decrypting and decompressing the Central Directory is accomplished
in the same manner as decrypting and decompressing a file.


5. Useful Tips

Strong Encryption is always applied to a file after compression. The
block oriented algorithms all operate in Cypher Block Chaining (CBC) 
mode. The block size used for AES encryption is 16. All other block
algorithms use a block size of 8. Two ID's are defined for RC2 to 
account for a discrepancy found in the implementation of the RC2
algorithm in the cryptographic library on Windows XP SP1 and all 
earlier versions of Windows.

A pseudo-code representation of the encryption process is as follows:

Password = GetUserPassword()
RD = Random()
ERD = Encrypt(RD,DeriveKey(SHA1(Password)))
For Each File
 IV = Random()
 VData = Random()
 FileSessionKey = DeriveKey(SHA1(IV + RD))
 Encrypt(VData + VCRC32 + FileData,FileSessionKey)
Done

The function names and parameter requirements will depend on
the choice of the cryptographic toolkit selected. Almost any
toolkit supporting the reference implementations for each
algorithm can be used. The RSA BSAFE(r), OpenSSL, and Microsoft
CryptoAPI libraries are all known to work well. 

Certificate Processing Method:
-----------------------------

The Certificate Processing Method for ZIP file encryption remains 
under development. The information provided here serves as a guide
to those interested in certificate-based data decryption. This
information may be subject to change in future versions of this
specification and is subject to change without notice.

OAEP Processing with Certificate-based Encryption:

Versions of PKZIP available during this development phase of the 
certificate processing method may set a value of 61 into the 
version needed to extract field for a file. This indicates that 
non-OAEP key wrapping is used. This affects certificate encryption 
only, and password encryption functions should not be affected by 
this value. This means values of 61 may be found on files encrypted
with certificates only, or on files encrypted with both password
encryption and certificate encryption. Files encrypted with both
methods can safely be decrypted using the password methods documented.

OAEP stands for Optimal Asymmetric Encryption Padding. It is a
strengthening technique used for small encoded items such as decryption
keys. This is commonly applied in cryptographic key-wrapping techniques
and is supported by PKCS #1. Versions 5.0 and 6.0 of this specification 
were designed to support OAEP key-wrapping for certificate-based 
decryption keys for additional security. 

Support for private keys stored on Smart Cards or Tokens introduced
a conflict with this OAEP logic. Most card and token products do 
not support the additional strengthening applied to OAEP key-wrapped 
data. In order to resolve this conflict, versions 6.1 and above of this 
specification will no longer support OAEP when encrypting using 
digital certificates. 

Certificate Processing Data Fields:

The Certificate Processing Method of this specification defines the
following additional data fields:


1. Certificate Flag Values

Additional processing flags that can be present in the Flags field of both 
the 0x0017 field of the central directory Extra Field and the Decryption 
header record preceding compressed file data are:

 0x0007 - reserved for future use
 0x000F - reserved for future use
 0x0100 - Indicates non-OAEP key wrapping was used. If this
 this field is set, the version needed to extract must
 be at least 61. This means OAEP key wrapping is not
 used when generating a Master Session Key using
 ErdData.
 0x4000 - ErdData must be decrypted using 3DES-168, otherwise use the
 same algorithm used for encrypting the file contents.
 0x8000 - reserved for future use


2. CertData - Extra Field 0x0017 record certificate data structure

The data structure used to store certificate data within the section
of the Extra Field defined by the CertData field of the 0x0017
record are as shown:

 Value Size Description
 ----- ---- -----------
 RCount 4 bytes Number of recipients. 
 HashAlg 2 bytes Hash algorithm identifier
 HSize 2 bytes Hash size
 SRList (var) Simple list of recipients hashed public keys

 
 RCount This defines the number intended recipients whose 
 public keys were used for encryption. This identifies
 the number of elements in the SRList.

 HashAlg This defines the hash algorithm used to calculate
 the public key hash of each public key used
 for encryption. This field currently supports
 only the following value for SHA-1

 0x8004 - SHA1

 HSize This defines the size of a hashed public key.

 SRList This is a variable length list of the hashed 
 public keys for each intended recipient. Each 
 element in this list is HSize. The total size of 
 SRList is determined using RCount * HSize.


3. Reserved1 - Certificate Decryption Header Reserved1 Data:

 Value Size Description
 ----- ---- -----------
 RCount 4 bytes Number of recipients. 
 
 RCount This defines the number intended recipients whose 
 public keys were used for encryption. This defines
 the number of elements in the REList field defined below.


4. Reserved2 - Certificate Decryption Header Reserved2 Data Structures:


 Value Size Description
 ----- ---- -----------
 HashAlg 2 bytes Hash algorithm identifier
 HSize 2 bytes Hash size
 REList (var) List of recipient data elements


 HashAlg This defines the hash algorithm used to calculate
 the public key hash of each public key used
 for encryption. This field currently supports
 only the following value for SHA-1

 0x8004 - SHA1

 HSize This defines the size of a hashed public key
 defined in REHData.

 REList This is a variable length of list of recipient data. 
 Each element in this list consists of a Recipient
 Element data structure as follows:


 Recipient Element (REList) Data Structure:

 Value Size Description
 ----- ---- -----------
 RESize 2 bytes Size of REHData + REKData
 REHData HSize Hash of recipients public key
 REKData (var) Simple key blob


 RESize This defines the size of an individual REList 
 element. This value is the combined size of the
 REHData field + REKData field. REHData is defined by
 HSize. REKData is variable and can be calculated
 for each REList element using RESize and HSize.

 REHData Hashed public key for this recipient.

 REKData Simple Key Blob. The format of this data structure
 is identical to that defined in the Microsoft
 CryptoAPI and generated using the CryptExportKey()
 function. The version of the Simple Key Blob
 supported at this time is 0x02 as defined by
 Microsoft.

5. Certificate Processing - Central Directory Encryption:

Central Directory Encryption using Digital Certificates will 
operate in a manner similar to that of Single Password Central
Directory Encryption. This record will only be present when there 
is data to place into it. Currently, data is placed into this
record when digital certificates are used for either encrypting 
or signing the files within a ZIP file. When only password 
encryption is used with no certificate encryption or digital 
signing, this record is not currently needed. When present, this 
record will appear before the start of the actual Central Directory 
data structure and will be located immediately after the Archive 
Decryption Header if the Central Directory is encrypted.

The Archive Extra Data record will be used to store the following
information. Additional data may be added in future versions.

Extra Data Fields:

0x0014 - PKCS#7 Store for X.509 Certificates
0x0016 - X.509 Certificate ID and Signature for central directory
0x0019 - PKCS#7 Encryption Recipient Certificate List

The 0x0014 and 0x0016 Extra Data records that otherwise would be 
located in the first record of the Central Directory for digital 
certificate processing. When encrypting or compressing the Central 
Directory, the 0x0014 and 0x0016 records must be located in the 
Archive Extra Data record and they should not remain in the first 
Central Directory record. The Archive Extra Data record will also 
be used to store the 0x0019 data. 

When present, the size of the Archive Extra Data record will be
included in the size of the Central Directory. The data of the
Archive Extra Data record will also be compressed and encrypted
along with the Central Directory data structure.

6. Certificate Processing Differences:

The Certificate Processing Method of encryption differs from the
Single Password Symmetric Encryption Method as follows. Instead
of using a user-defined password to generate a master session key,
cryptographically random data is used. The key material is then
wrapped using standard key-wrapping techniques. This key material
is wrapped using the public key of each recipient that will need
to decrypt the file using their corresponding private key.

This specification currently assumes digital certificates will follow
the X.509 V3 format for 1024 bit and higher RSA format digital
certificates. Implementation of this Certificate Processing Method
requires supporting logic for key access and management. This logic
is outside the scope of this specification.


License Agreement:
-----------------

The features set forth in this Section XIV (the "Strong Encryption 
Specification") are covered by a pending patent application. Portions of 
this Strong Encryption technology are available for use at no charge 
under the following terms and conditions. 

1. License Grant. 

 a. NOTICE TO USER. PLEASE READ THIS ENTIRE SECTION XIV OF THE 
 APPNOTE (THE "AGREEMENT") CAREFULLY. BY USING ALL OR ANY PORTION OF THE 
 LICENSED TECHNOLOGY, YOU ACCEPT ALL THE TERMS AND CONDITIONS OF THIS 
 AGREEMENT AND YOU AGREE THAT THIS AGREEMENT IS ENFORCEABLE LIKE ANY 
 WRITTEN NEGOTIATED AGREEMENT SIGNED BY YOU. IF YOU DO NOT AGREE, DO NOT 
 USE THE LICENSED TECHNOLOGY.
 
 b. Definitions.
 
 i. "Licensed Technology" shall mean that proprietary technology now or 
 hereafter owned or controlled by PKWare, Inc. ("PKWARE") or any 
 subsidiary or affiliate that covers or is necessary to be used to give 
 software the ability to a) extract and decrypt data from zip files 
 encrypted using any methods of data encryption and key processing which 
 are published in this APPNOTE or any prior APPNOTE, as supplemented by 
 any Additional Compatibility Information; and b) encrypt file contents 
 as part of .ZIP file processing using only the Single Password Symmetric 
 Encryption Method as published in this APPNOTE or any prior APPNOTE, as 
 supplemented by any Additional Compatibility Information. For purposes 
 of this AGREEMENT, "Additional Compatibility Information" means, with 
 regard to any method of data encryption and key processing published in 
 this or any prior APPNOTE, any corrections, additions, or clarifications 
 to the information in such APPNOTE that are required in order to give 
 software the ability to successfully extract and decrypt zip files (or, 
 but solely in the case of the Single Password Symmetric Encryption Method, 
 to successfully encrypt zip files) in a manner interoperable with the 
 actual implementation of such method in any PKWARE product that is 
 documented or publicly described by PKWARE as being able to create, or 
 to extract and decrypt, zip files using that method.

 ii. "Licensed Products" shall mean any products you produce that 
 incorporate the Licensed Technology.
 
 c. License to Licensed Technology.
 
 PKWARE hereby grants to you a non-exclusive license to use the Licensed 
 Technology for the purpose of manufacturing, offering, selling and using 
 Licensed Products, which license shall extend to permit the practice of all 
 claims in any patent or patent application (collectively, "Patents") now or 
 hereafter owned or controlled by PKWARE in any jurisdiction in the world 
 that are infringed by implementation of the Licensed Technology. You have 
 the right to sublicense rights you receive under the terms of this AGREEMENT 
 for the purpose of allowing sublicensee to manufacture, offer, sell and use 
 products that incorporate all or a portion of any of your Licensed Products, 
 but if you do, you agree to i) impose the same restrictions on any such 
 sublicensee as these terms impose on you and ii) notify the sublicensee, 
 by means chosen by you in your unfettered discretion, including a notice on 
 your web site, of the terms of this AGREEMENT and make available to each 
 sublicensee the full text of this APPNOTE. Further, PKWARE hereby grants to 
 you a non-exclusive right to reproduce and distribute, in any form, copies of 
 this APPNOTE, without modification. Notwithstanding anything to the contrary 
 in this AGREEMENT, you have the right to sublicense the rights, without any of 
 the restrictions described above or elsewhere in this AGREEMENT, to use, offer 
 to sell and sell Licensed Technology as incorporated in executable object code 
 or byte code forms of your Licensed Products. Any sublicense to use the 
 Licensed Technology incorporated in a Licensed Product granted by you shall 
 survive the termination of this AGREEMENT for any reason. PKWARE warrants that 
 this license shall continue to encumber the Licensed Technology regardless of 
 changes in ownership of the Licensed Technology.
 
 d. Proprietary Notices.
 
 i. With respect to any Licensed Product that is distributed by you either 
 in source code form or in the form of an object code library of externally 
 callable functions that has been designed by you for incorporation into third 
 party products, you agree to include, in the source code, or in the case of 
 an object code library, in accompanying documentation, a notice using the 
 words "patent pending" until a patent is issued to PKWARE covering any 
 portion of the Licensed Technology or PKWARE provides notice, by means 
 chosen by PKWARE in its unfettered discretion, that it no longer has any 
 patent pending covering any portion of the Licensed Technology. With respect 
 to any Licensed Product, upon your becoming aware that at least one patent has 
 been granted covering the Licensed Technology, you agree to include in any 
 revisions made by you to the documentation (or any source code distributed 
 by you) the words "Pat. No.", or "Patent Number" and the patent number or 
 numbers of the applicable patent or patents. PKWARE shall, from time to time, 
 inform you of the patent number or numbers of the patents covering the 
 Licensed Technology, by means chosen by PKWARE in its unfettered discretion, 
 including a notice on its web site. It shall be a violation of the terms of 
 this AGREEMENT for you to sell Licensed Products without complying with the 
 foregoing marking provisions.
 
 ii. You acknowledge that the terms of this AGREEMENT do not grant you any 
 license or other right to use any PKWARE trademark in connection with the sale, 
 offering for sale, distribution and delivery of the Licensed Products, or in 
 connection with the advertising, promotion and offering of the Licensed Products. 
 You acknowledge PKWARE's ownership of the PKZIP trademark and all other marks 
 owned by PKWARE.
 
 e. Covenant of Compliance and Remedies.

 To the extent that you have elected to implement portions of the Licensed 
 Technology, you agree to use reasonable diligence to comply with those portions 
 of this Section XIV, as modified or supplemented by Additional Compatibility 
 Information available to you, describing the portions of the Licensed Technology 
 that you have elected to implement. Upon reasonable request by PKWARE, you will 
 provide written notice to PKWARE identifying which version of this APPNOTE you 
 have relied upon for your implementation of any specified Licensed Product.
 
 If any substantial non-compliance with the terms of this AGREEMENT is determined 
 to exist, you will make such changes as necessary to bring your Licensed Products 
 into substantial compliance with the terms of this AGREEMENT. If, within sixty 
 days of receipt of notice that a Licensed Product fails to comply with the terms 
 of this AGREEMENT, you fail to make such changes as necessary to bring your 
 Licensed Products into compliance with the terms of this AGREEMENT, PKWARE may 
 terminate your rights under this AGREEMENT. PKWARE does not waive and expressly 
 reserves the right to pursue any and all additional remedies that are or may 
 become available to PKWARE.
 
 f. Warranty and Indemnification Regarding Exportation.
 
 You realize and acknowledge that, as between yourself and PKWARE, you are fully 
 responsible for compliance with the import and export laws and regulations of 
 any country in or to which you import or export any Licensed Products, and you 
 agree to hold PKWARE harmless from any claim of violation of any such import 
 or export laws.
 
 g. Patent Infringement.

 You agree that you will not bring or threaten to bring any action against PKWARE 
 for infringement of the claims of any patent owned or controlled by you solely 
 as a result of PKWARE's own implementation of the Licensed Technology. As its 
 exclusive remedy for your breach of the foregoing agreement, PKWARE reserves 
 the right to suspend or terminate all rights granted under the terms of this 
 AGREEMENT if you bring or threaten to bring any such action against PKWARE, 
 effective immediately upon delivery of written notice of suspension or 
 termination to you. 

 h. Governing Law. 

 The license granted in this AGREEMENT shall be governed by and construed under 
 the laws of the State of Wisconsin and the United States. 

 i. Revisions and Notice.

 The license granted in this APPNOTE is irrevocable, except as expressly set 
 forth above. You agree and understand that any changes which PKWARE determines 
 to make to this APPNOTE shall be posted at the same location as the current 
 APPNOTE or at a location which will be identified by means chosen by PKWARE, 
 including a notice on its web site, and shall be available for adoption by you 
 immediately upon such posting, or at such other time as PKWARE shall determine. 
 Any changes to the terms of the license published in a subsequent version of 
 this AGREEMENT shall be binding upon you only with respect to your products 
 that (i) incorporate any Licensed Technology (as defined in the subsequent 
 AGREEMENT) that is not otherwise included in the definition of Licensed 
 Technology under this AGREEMENT, or (ii) that you expressly identify are to 
 be licensed under the subsequent AGREEMENT, which identification shall be by 
 written notice with reference to the APPNOTE (version and release date or other 
 unique identifier) in which the subsequent AGREEMENT is published. PKWARE 
 agrees to identify each change to this APPNOTE by using a unique version and 
 release date identifier or other unique identifier.
 
 j. Warranty by PKWARE

 PKWare, Inc. warrants that it has the right to grant the license hereunder.
 
XV. Change Process
------------------

In order for the .ZIP file format to remain a viable definition, this
specification should be considered as open for periodic review and
revision. Although this format was originally designed with a 
certain level of extensibility, not all changes in technology
(present or future) were or will be necessarily considered in its
design. If your application requires new definitions to the
extensible sections in this format, or if you would like to 
submit new data structures, please forward your request to
zipformat@pkware.com. All submissions will be reviewed by the
ZIP File Specification Committee for possible inclusion into
future versions of this specification. Periodic revisions
to this specification will be published to ensure interoperability. 
We encourage comments and feedback that may help improve clarity 
or content.

XVI. Acknowledgements
---------------------

In addition to the above mentioned contributors to PKZIP and PKUNZIP,
I would like to extend special thanks to Robert Mahoney for suggesting
the extension .ZIP for this software.

XVII. References
----------------

 Fiala, Edward R., and Greene, Daniel H., "Data compression with
 finite windows", Communications of the ACM, Volume 32, Number 4,
 April 1989, pages 490-505.

 Held, Gilbert, "Data Compression, Techniques and Applications,
 Hardware and Software Considerations", John Wiley & Sons, 1987.

 Huffman, D.A., "A method for the construction of minimum-redundancy
 codes", Proceedings of the IRE, Volume 40, Number 9, September 1952,
 pages 1098-1101.

 Nelson, Mark, "LZW Data Compression", Dr. Dobbs Journal, Volume 14,
 Number 10, October 1989, pages 29-37.

 Nelson, Mark, "The Data Compression Book", M&T Books, 1991.

 Storer, James A., "Data Compression, Methods and Theory",
 Computer Science Press, 1988

 Welch, Terry, "A Technique for High-Performance Data Compression",
 IEEE Computer, Volume 17, Number 6, June 1984, pages 8-19.

 Ziv, J. and Lempel, A., "A universal algorithm for sequential data
 compression", Communications of the ACM, Volume 30, Number 6,
 June 1987, pages 520-540.

 Ziv, J. and Lempel, A., "Compression of individual sequences via
 variable-rate coding", IEEE Transactions on Information Theory,
 Volume 24, Number 5, September 1978, pages 530-536.

opoojkk

20260730

最近的变化

裁员 #

朋友 #

搬家 #

后续 #

Android 17 MessageQueue 无锁化实现解析

分发 #

三种状态 #

插入消息 #

ACTIVE #

PARKED #

TIMEDPARK #

两个队列有什么不同 #

状态什么时候恢复 Active #

总结 #

Android 启动 Activity 的多种方式

原生方式 #

显示启动 #

隐式启动 #

封装 #

工厂方法 #

DSL / Builder #

三方库 #

对比 #

Vue录音模块状态机重构笔记

背景 #

状态失控 #

异步时序 #

重构一：明确状态 #

重构二：用会话 ID 隔离异步回调 #

重构三：状态驱动UI #

重构四：状态日志面板 #

重构结果 #

反思 #

密封类描述状态 #

状态驱动 UI #

对比 #

2025年终总结

生活 #

工作 #

读书 #

新年目标 #

Compose Compiler 深入解析：从参数注入到重组执行的 IR 变换全流程

为什么设置 clipChildren = false 可以突破父 View 边界？

设置clipChildren = false #

setClipChildren 做了哪些事？ #

RenderNode#setClipToBounds() #

nSetClipToBounds 在 Native 层 #

clipToBounds 如何真正影响绘制？ #

小结 #

Android 字符串资源加载流程解析

Android 字符串资源解析全流程解析 #

从 Context 到 AssetManager #

JNI 层：统一的资源访问入口 #

GetResource：查找资源、识别类型 #

FindEntry：拆解 ID 并遍历所有设备配置 #

FindEntryInternal：匹配策略 #

Res_value：完整结构（string = 字符串池索引） #

异常处理 #

加载流程图（示意） #

C++ 学习笔记：指针与引用

指针是什么 #

引用 #

总结 #

从模拟信号到补码：计算机如何存储和计算数字

模电 #

采样 #

量化 #

编码 #

数电 #

补码 #

原码（符号+原数字） #

反码 #

反码的数学本质 #

为什么是 2^n - 1? #

按位取反的数学本质 #

通用规律 #

为什么需要循环进位 #

使用 `ext` 属性集中管理 #

使用 `buildSrc` 模块 #