首页 — 笔记

Mon, 01 Jan 0001 00:00:00 +0000

客户端开发。技术栈：Android、HarmonyOS（鸿蒙）、React Native。

有过 短视频 / 直播 场景下的 直播间搭建与业务落地 经历。目前主要工作方向在 跨端与动态化。

Mon, 01 Jan 0001 00:00:00 +0000

Android ANR 问题详解

1. 核心结论：什么是 ANR？

ANR（Application Not Responding）是 Android 系统保护用户体验的最后防线。它的本质是系统跨进程的超时监控：系统核心进程（SystemServer）发现应用主线程未能在规定时间内响应特定事件，从而强制弹窗让用户干预（等待或关闭应用）。

核心解决思路：将耗时操作移出主线程，并优化主线程的锁与资源争用。

2. 为什么需要 ANR 机制？

如果应用在主线程卡死，用户将无法进行任何交互，手机看起来像“死机”了一样。

目的：把“关闭卡死应用”的选择权交还给用户，避免劣质应用霸占系统资源。
设计权衡（上帝视角监控）：系统并没有去监控应用主线程的每一个函数调用耗时（那会带来巨大的性能开销）。系统只对特定的核心组件和输入事件进行超时监控。如果应用在主线程执行了 4 秒的耗时操作，只要没碰到输入事件和组件生命周期，系统是不会管的。

3. ANR 的触发场景与阈值

发生 ANR 的场景严格限定在以下四类（分别对应不同的系统服务监控）：

场景	触发阈值	监控负责人
Input 触摸/按键	5 秒	InputDispatcher (WMS 体系)
BroadcastReceiver	前台 10 秒 / 后台 60 秒	ActivityManagerService (AMS)
Service	前台 20 秒 / 后台 200 秒	ActivityManagerService (AMS)
ContentProvider	10 秒	ActivityManagerService (AMS)

4. 核心原理：ANR 是如何监控并触发的？

Android 实现 ANR 的核心思想是**“跨进程监控”**：监控方在系统进程，被监控方在应用进程。主要分为两套模型：

Mon, 01 Jan 0001 00:00:00 +0000

Android Context 相关问题

面试一句话：Context 是“当前应用上下文”的抽象接口，真正干活的是 ContextImpl，ContextWrapper 代理一层给 Activity/Service/Application 用；Application 的 Context 进程单例、生命周期最长，Activity/Service 各有一个。Context 个数 = 1 个 Application + N 个 Activity + M 个 Service。详见笔记《Android 面试·分章系统复习》相关章节。

阅读建议：先看 面试两问 和选型，再 是什么 / 整体结构 / 创建时机，最后 注意点。

面试两问（结论前置）

1. Application、Activity、Service 的 Context 有什么区别？

类型	生命周期	典型用途	注意
Application	进程级单例，与进程同生共死	全局配置、单例、getSharedPreferences、getSystemService	不要长期持 Activity 引用，易泄漏
Activity	随 Activity 创建/销毁	启动 Activity、布局 inflate、主题、startActivityForResult	带主题，和界面绑定
Service	随 Service 创建/销毁	后台逻辑、getSystemService、不带 UI 的能力	无主题、无 UI

2. App 里有几个 Context？
1 个 Application + 所有 Activity 实例数 + 所有 Service 实例数（每个 Activity/Service 对应一个 Context）。

Mon, 01 Jan 0001 00:00:00 +0000

Android Handler

面试可先答：四件套 Message、MessageQueue、Looper、Handler；线程切换本质是多线程共享同一 MessageQueue，通过 Handler 投递、Looper 分发；子线程需 Looper.prepare() + loop()；注意内存泄漏与 removeCallbacksAndMessages。详见笔记《Android 面试·分章系统复习》第七章 Handler 机制。

阅读建议：先看 应用场景 与 四件套，再 线程切换本质、ThreadLocal、同步屏障，最后 HandlerThread 案例 与 常见问题。

应用场景

Android 更新 UI 必须在主线程执行。Handler 用于在不同线程之间传递消息，把「更新 UI」等任务投递到主线程执行。

核心模块与架构（四件套）

组件	作用
Message	消息载体，含 `what`、`obj`、`target`（归属 Handler）、`when`（执行时间）
MessageQueue	按时间顺序排列的优先级单链表
Looper	线程内的死循环，从 MessageQueue 取消息并分发
Handler	发送消息入队，并接收 Looper 回传的消息在对应线程处理

架构示意：

线程切换的本质：数据如何跨越线程？

结论：多线程共享同一个 MessageQueue 对象，通过 Handler 引用实现跨线程投递。

绑定引用：Handler 创建时绑定一个 Looper（及该 Looper 唯一的 MessageQueue）。
跨线程入队：任意线程调用 handler.sendMessage()，底层都是操作该 Handler 持有的 mQueue。
同步：MessageQueue.enqueueMessage 内用 synchronized(this) 保证线程安全。
唤醒执行：消息入队后，通过 Linux epoll 唤醒正在阻塞的线程，由该线程的 Looper 取消息并执行。

线程隔离：ThreadLocal

问题：Handler 如何保证绑定的 Looper 就是目标线程的？
原理：Looper 用 ThreadLocal 存储，每个线程一份独立副本，保证「一个线程只有一个 Looper」，实现线程间资源隔离。

进阶：同步屏障（Sync Barrier）

定义：target == null 的特殊消息。
作用：屏障后的普通消息被挂起，只允许异步消息通过。
场景：Choreographer 收到 VSYNC 时插入同步屏障，让 UI 绘制（异步消息）优先执行，保证流畅。
注意：屏障须用 token 手动移除，否则普通消息会一直被阻塞。

实战：HandlerThread

子线程使用 Handler 的标准写法：

Mon, 01 Jan 0001 00:00:00 +0000

Android View 绘制与布局：从应用到屏幕的渲染管线

本文目标：打破“只背 View 三部曲”的局限，用一条完整的渲染管线把「应用层代码」到「屏幕显示」的整个链路串联起来。不仅知其然（流程是什么），更知其所以然（为什么要这么设计）。

阅读建议：

想快速建立整体认知 👉 读一、核心结论
想了解一帧画面的诞生全貌 👉 读二、渲染管线与 VSYNC 机制
想深入理解 View 三大核心步骤与底层数据结构 👉 读三、主线程遍历详解（measure / layout / draw）
遇到卡顿、拿不到宽高、自定义 View 等问题 👉 读四、常见场景与排障指南

一、核心结论

不要把「只有 View 三步」当成渲染的全部；这三步仅仅是应用侧准备数据的过程，真正的上屏必须经过合成与显示链路。现代 Android 渲染的宏观分工如下：

主线程（UI 线程）：负责遍历视图树（measure / layout），并把绘制操作录制成图纸（draw 指令），不直接操作像素。
渲染线程（RenderThread）与 GPU：接手主线程录制好的图纸，利用 GPU 真正把指令变成像素（栅格化）。
系统合成守护进程（SurfaceFlinger）：负责把各个 App 和系统 UI（状态栏、导航栏）的图层合成在一起，最终送到屏幕。

二、渲染管线与 VSYNC 机制

屏幕是一行行刷新的，如果代码随时随地去修改像素，极易出现画面撕裂。为此，Android 设计了基于 VSYNC（垂直同步信号） 的节奏控制流水线。

1. 一帧画面的 5 个阶段全貌

sequenceDiagram
    participant Disp as 物理屏幕 & VSYNC
    participant Choreo as 框架层 (Choreographer)
    participant Main as 应用主线程 (UI 线程)
    participant RT as 渲染线程 (RenderThread)
    participant SF as 系统合成进程 (SurfaceFlinger)

    Disp->>Choreo: 1. 发出 VSYNC 节拍 (如每 16.6ms)
    Choreo->>Main: 2. 触发回调，唤醒主线程
    Note over Main: 3. 遍历视图树<br/>(measure -> layout -> draw)
    Main->>RT: 4. 同步绘制指令 (DisplayList)
    Note over RT: 5. GPU 栅格化，生成像素缓冲
    RT->>SF: 6. 跨进程提交缓冲
    Note over SF: 7. 多窗口/图层合成
    SF->>Disp: 8. 送显上屏 (等待下一次 VSYNC)

节拍器（VSYNC）：屏幕按固定频率发出的“滴答”声，统一渲染节奏。
传达室与发令枪（Choreographer）：应用调用 invalidate() 时，是向它“注册”一个任务，等待下一个 VSYNC 发令枪响，才唤醒主线程干活。
主线程遍历（View 三部曲）：主线程确认视图大小（measure）、位置（layout），并录制绘制指令（draw）。
独立包工头（RenderThread + GPU）：主线程录制完图纸后立刻交接给它。它负责真正的“上色”（栅格化），让主线程能解放出来去响应触摸事件。
幕后大 Boss（SurfaceFlinger）：Android 专属的独立系统守护进程。负责把手机所有图层跨进程汇总上屏。

2. 底层设计的演进与解惑

疑问一：为什么不在 VSYNC 到来“之前”一有空就提前画好？ 为了保证画面“绝对新鲜”并将零散的更新“打包”。等到 VSYNC 到来的一瞬间才去采集触摸位置和动画时间，画出来的才最贴合用户的当下操作，极大降低了输入延迟。同时避免 16.6ms 内多次无用的重复重绘。

Mon, 01 Jan 0001 00:00:00 +0000

Android 生命周期监听：演进史与对应实现

用途：梳理 Android 生命周期监听机制的发展脉络、对应时代的实现方式，以及为什么会发生这些演进。理解了「痛点与解法」，写代码时自然就能选对 API。
建议阅读顺序：先看 一、当前最佳实践速查（结论），再按时间线阅读「为什么这么发展」。

一、当前最佳实践速查（结论）

不管历史怎么变，现在写代码请认准以下规范：

场景	当前推荐做法	淘汰/避坑的做法
写生命周期感知的组件（如相机、传感器）	实现 `DefaultLifecycleObserver`，用 `lifecycle.addObserver()` 注册	❌ 不再使用 `@OnLifecycleEvent` 注解
在 Fragment 中操作 UI（如更新 TextView）	必须绑定 `viewLifecycleOwner.lifecycle`	❌ 不要绑定 Fragment 自身的 `lifecycle`
Kotlin 中收集 Flow / StateFlow	`viewLifecycleOwner.lifecycleScope` + `repeatOnLifecycle(STARTED)`	❌ 不要直接在协程里裸 `collect`（后台耗电）
进程级前后台判断	`ProcessLifecycleOwner.get().lifecycle`	❌ 不要在 BaseActivity 里自己计数

二、第一阶段：手写回调的「刀耕火种」时代

1. 对应实现

在 Activity / Fragment 的生命周期方法中，手动调用业务组件的注册与注销。

class MyActivity : AppCompatActivity() {
    private val locationListener = MyLocationListener()

    override fun onStart() {
        super.onStart()
        locationListener.start() // 手动开始
    }

    override fun onStop() {
        locationListener.stop()  // 手动停止
        super.onStop()
    }
}

2. 为什么会演进？（痛点）

God Activity（上帝类）：UI 控制器里塞满了各种无关业务（定位、网络、视频播放）的启停逻辑，代码极度臃肿。
极易出错：onStart 和 onStop 必须对称。一旦开发者忘记写注销代码，就会导致内存泄漏或后台崩溃。
组件无法独立：业务组件无法做到「自给自足」，必须依赖外部 UI 控制器主动通知它。

三、第二阶段：AAC Lifecycle 诞生与注解时代（2017）

为了解决上述痛点，Google 推出了 Android Architecture Components (AAC)，引入了 Lifecycle 和 LifecycleOwner。组件终于可以「自己监听」生命周期了。

Mon, 01 Jan 0001 00:00:00 +0000

锁的应用场景

多线程访问共享资源时需要加锁，避免数据错乱。不同锁的代价和适用场景不同，选对了才能既有正确性又有性能。

选型速查（结论在前）

先看场景，再选手段：

临界区较长（如一段业务逻辑）→ 互斥锁（synchronized、ReentrantLock）
临界区很短（如改一个计数）→ 自旋锁 / 原子变量（AtomicInteger、LongAdder）
读多写少（如配置、缓存）→ 读写锁 或 CopyOnWrite、ConcurrentHashMap
冲突概率高 → 悲观锁（先加锁再操作）
冲突概率低 → 乐观锁（先改再校验，版本号或 CAS）
只关心「一个变量写了别人立刻看到」、且无复合操作 → volatile（标志位、DCL 单例）

需要超时、可中断、公平锁或多条件队列 → 用 ReentrantLock 而不是 synchronized。

加锁粒度尽量小，锁住的代码越少越好。

一、核心概念

临界区

临界区（Critical Section）：访问共享资源、且在同一时刻只应被一个线程执行的那段代码。

加锁就是为了保护临界区，保证不会有两个线程同时进入同一临界区。
直观理解：被锁包住的那段代码、需要互斥执行的那一段。

锁类型总览

锁	拿不到锁时	适用场景	典型例子
互斥锁	阻塞，让出 CPU	临界区较长	扣款、写日志
自旋锁	忙等	临界区很短	引用计数、原子变量
读写锁	读可并发，写独占	读多写少	配置表、缓存
悲观锁	先加锁再操作	冲突概率高	FOR UPDATE、synchronized
乐观锁	先改再校验	冲突概率低	版本号、CAS、Git

互斥锁：阻塞、让出 CPU（有上下文切换）。
自旋锁：忙等、不释放 CPU，一般用 CAS；适合极短临界区。
读写锁：读共享、写独占；互斥锁、自旋锁、读写锁都是悲观锁的实现。
乐观锁：先改再验证，失败则重试。

二、可重入与不可重入

问题：同一线程能否对同一把锁连续加锁两次（或多次）而不死锁？