Mar 23, 2026

牛客面经 - 等 offer 时玩了会儿手机

链接：https://www.nowcoder.com/users/843246725

腾讯客户端

介绍一下 TCP 三次握手，为什么是三次？两次行不行？

嗯，关于 TCP 的三次握手，这算是一个非常经典的基础问题了。结论先行的话，三次握手的核心目的不是为了“打招呼”，而是为了在不可靠的链路上，可靠地同步双方的序列号（Sequence Number），并确认双方的收发能力都是正常的。

咱们先对一下流程。第一步，客户端发一个 SYN 包，带上自己的初始序列号 $seq = x$ 。这时候客户端进入 SYN_SENT 状态。第二步，服务端收到后，得回一个 SYN + ACK，它的 $ack$ 必须是 $x + 1$ ，表示“我收到你的请求了”，同时带上自己的初始序列号 $seq = y$ ，服务端进入 SYN_RCVD 状态。第三步，客户端收到后，再回一个 ACK， $ack = y + 1$ ，客户端进入 ESTABLISHED 状态。服务端收到这个 ACK 后，也进入 ESTABLISHED。到这，连接就建好了。

那为什么非得是三次，两次行不行？ 其实，两次是绝对不行的，主要会导致服务端出现严重的资源浪费和状态同步问题。

这里最核心的一个场景就是“失效的连接请求突然又到达了服务端”。你想啊，如果客户端发了第一个 SYN，结果网络卡了，客户端等不及了，又重发了一个 SYN。这时候第二个连接成功并结束了。结果过了一会儿，第一个卡住的 SYN 终于到了服务端。

如果是两次握手，服务端收到这个过时的 SYN 后，回一个 ACK，连接就算建立了。但这时候客户端其实根本没想连，它会直接忽略这个 ACK。结果呢？服务端在那儿傻傻地开辟了资源等着，这种“僵尸连接”要是多了，服务端的内存和连接数很快就爆了。所以说，如果只有两次握手，受害者主要是服务端。

其实从信息论的角度来看，三次握手也是“最小确认次数”。客户端需要确认：我的发、我的收、你的发、你的收都正常；服务端也需要确认这四项。三次握手刚好能让双方都完成这四项确认。

我在做 Android 开发的时候，虽然应用层用的是 OkHttp 或者 Retrofit，但其实底层在建立 TCP 连接时，这些逻辑都在内核协议栈里跑。理解这个流程对于排查一些复杂的 Connection Timeout 或者 SocketException 非常有帮助，尤其是在移动网络这种不稳定的环境下。

谈谈你对 TCP 滑动窗口机制的理解

嗯，说到 TCP 的滑动窗口（Sliding Window），其实它的本质就是一种“流量控制”机制，用来平衡发送方的发送速度和接收方的处理能力，防止接收缓冲区溢出。

如果不引入窗口的概念，TCP 就会退化成“发一个、确认一个”的模式，那在长肥网络（时延高、带宽大）里，效率就太低了，链路带宽全浪费在等 ACK 的路上了。

滑动窗口的工作原理大概是这样的：TCP 的首部里有一个 Window Size 字段。接收方在给发送方回 ACK 的时候，会顺便告诉对方：“我这儿现在还有多大的地儿（接收缓冲区剩余空间）能接数据”。

发送方会维护一个发送窗口，它把数据分成四类：

已经发送且收到确认的。
已经发送但还没收到确认的。
允许发送但还没发的（这就是窗口内剩余的部分）。
暂时不允许发送的（超出了窗口范围）。

当发送方收到 ACK 后，窗口就会向右“滑动”。比如我收到了 $seq = 100$ 的确认，那窗口的左边界就拉到 101。

在这个过程中，有一个非常重要的细节叫做累积确认（Cumulative Acknowledgment）。就是说，如果接收方发了一个 $ack = 500$ ，那就意味着 $500$ 之前的所有字节都已经正确收到了。这大大提高了传输效率。

但我之前研究性能优化的时候发现，滑动窗口虽然解决了流量控制，但它解决不了网络拥塞。所以 TCP 还有一套拥塞窗口（cwnd），它和**接收窗口（rwnd）**共同决定了发送方到底能发多少数据，公式大概是：发送上限 = min(rwnd, cwnd)。

在 Android 应用开发中，我们如果遇到大文件上传或者下载速度突然掉下去，除了考虑网络信号，有时候也得分析是不是服务端的接收窗口太小，或者因为网络波动触发了 TCP 的快速重传，导致窗口频繁收缩。理解这一点，对于我们优化 App 的网络传输性能非常关键。

听说过 QUIC 吗？它解决了什么问题？

嗯，QUIC 我确实关注过，它是 Google 提出来的基于 UDP 的传输层协议，现在已经是 HTTP/3 的基础了。

简单来说，QUIC 的出现就是为了解决 TCP 协议在现代互联网（尤其是移动互联网）环境下的一些“陈年旧疾”。 既然 TCP 的逻辑已经固化在操作系统的内核里、很难修改了，Google 就干脆在应用层基于 UDP 重新造了一个轮子。

它主要解决了这么几个核心问题：

第一，彻底解决了 TCP 的队头阻塞（Head-of-Line Blocking）问题。 在 TCP 里，如果你一个包丢了，后面所有的包都得停下来等这个包重传，因为 TCP 要保证字节流的绝对顺序。但 QUIC 在一个连接里支持多个独立的 Stream。如果你某个 Stream 的包丢了，只会影响这一个 Stream，其他的 Stream 照样传。这对于我们 Android 应用里同时加载多张图片或者多个接口请求的场景，优化非常明显。

第二，极速握手，实现 0-RTT 或 1-RTT 开屏。 传统的 TCP + TLS 握手，通常需要 3 个 RTT（往返时间）才能开始传数据。而 QUIC 把传输层和加密层握手合并了。如果是曾经连接过的服务器，它能实现 0-RTT 握手，数据直接跟着握手包一起发。对于追求极致冷启动速度的 App 来说，这简直是神技。

第三，连接迁移（Connection Migration）。 这个对我们移动开发太有用了！以前我们在 Android 手机上，从 Wi-Fi 切换到 4G/5G，IP 地址变了，TCP 连接肯定得断掉重连，用户就会感觉到明显的转圈或者卡顿。但 QUIC 不看 IP，它用一个 64 位的 Connection ID 来识别连接。只要 ID 没变，即便你切换了网络、换了 IP，连接依然能无缝保持。

其实像字节跳动、腾讯这些大厂，在自家的 App（比如抖音、视频号）里早就大规模应用 QUIC 或者自研的类 QUIC 协议了。我之前在看一些开源的网络库，比如 Cronet（Chromium 的网络栈），就有专门去了解它是怎么在 Android 端集成 QUIC 的。

虽然它基于 UDP，但它在应用层实现了可靠性传输、流量控制和拥塞控制。我觉得未来 QUIC 会成为移动端网络通信的主流。

操作系统进程和线程的区别

嗯，关于进程和线程的区别，这其实是操作系统的基础，但在 Android 开发里，理解这两者的边界对优化性能和处理稳定性非常重要。结论先行的话，进程是操作系统分配资源的基本单位，而线程是 CPU 任务调度的基本单位。

我们可以把进程想象成一个工厂，它拥有独立的厂房、电力、原材料等资源；而线程就是工厂里的工人，多个工人共享工厂里的这些资源，分工协作去完成任务。

展开来说，有这么几个核心的区别点：

首先是资源隔离与共享。每个进程都有自己独立的虚拟地址空间，比如 Linux 下进程间的内存是不通的。这就意味着一个进程崩了，通常不会直接影响到另一个进程。而线程是跑在进程内部的，同一个进程下的所有线程共享该进程的堆空间（Heap）和方法区，每个线程只拥有自己私有的程序计数器（PC）和栈（Stack）。

其次是开销问题。创建一个进程的开销很大，因为它需要操作系统分配内存空间、加载代码段、初始化 PCB（进程控制块）等。而线程非常轻量，创建和销毁都很快。更重要的是上下文切换（Context Switch），进程切换涉及页表（Page Table）的切换，会导致 CPU 缓存（TLB）失效；而同一进程内的线程切换不需要切页表，开销要小得多。

在 Android 的环境下，我对这两者的体会更深一点。比如 Android 默认是一个应用对应一个进程，但我们可以通过 android:process 属性让某些组件跑在独立进程里。为什么要这么干呢？其实就是为了隔离风险或者突破内存限制。比如一些大型 App 的 Webview 模块或者推送 Service，如果放在主进程，一旦内存泄露或者崩溃，整个 App 就挂了。

而线程方面，我们最熟悉的就是 UI 线程（Main Thread）。Android 要求所有的 UI 操作必须在主线程，而耗时操作必须在子线程。这里其实就涉及到了线程同步的问题，因为多线程共享内存，如果没有处理好竞态条件，就会出现数据不一致或者死锁。

所以我个人的理解是：进程给了系统稳定性，而线程给了系统并发能力。 在 Android 开发中，我们要利用好多进程的隔离性，同时也要处理好多线程的并发控制。

协程？协程相比线程的优势？

其实我最近在做 Android 项目的时候，已经全面从 RxJava 转向 Kotlin Coroutines（协程） 了。简单一句话概括：协程是运行在线程之上的轻量级调度单元，它的核心优势在于用同步的代码风格写出异步的逻辑，并且拥有极高的执行效率。

很多人管协程叫“微线程”，但我觉得更准确的说法是用户态线程。

相比于传统的线程，协程的优势主要体现在三个方面：

第一，是极高的执行效率。线程的切换是由内核控制的，涉及用户态和内核态的切换，成本很高。而协程的切换是由程序自己（在 JVM 层面）控制的，不涉及内核调用。你可以理解为在一个线程里，有多个任务在“轮流”使用 CPU，但这个切换非常轻量。

第二，是极低的内存占用。创建一个线程通常需要分配 $1MB$ 左右的栈空间，而一个协程初始化只需要几百个字节。这就意味着，我可以在一个应用里轻松开启几万个协程，而要是开几万个线程，系统早就 OOM（内存溢出）了。

第三，也是对我们 Android 开发者最直观的一点，就是非阻塞式挂起（Non-blocking Suspend）。以前我们写异步回调，要么是嵌套 Hell，要么是 RxJava 的各种操作符，阅读起来比较费劲。在协程里，我们可以用 suspend 关键字。当协程执行到耗时操作（比如网络请求）时，它会“挂起”，把线程资源让出来给别人用，等结果回来了，它再“恢复”执行。在代码上看，它就像顺序执行一样：

Kotlin

val user = api.getUser() // 挂起，不阻塞线程
updateUI(user)           // 恢复，自动切回主线程

我在读协程源码时，注意到它的底层其实是一个 Continuation（续体） 的传递。编译器会把 suspend 函数编译成一个状态机。每一段被挂起点的代码，都是状态机里的一个状态。

总的来说，协程并没有取代线程，它只是在线程之上做了一层封装，让我们能以更低的人力成本（代码可读性）和更低的系统成本（内存开销）去处理高并发任务。

常见的进程之间的通信方式？

在 Linux 层面和 Android Framework 层面，进程间通信（IPC）的方式其实非常多样。总的来说，它们可以分为 Linux 传统 IPC 和 Android 特有的 IPC。

首先说说 Linux 传统的 IPC 方式：

管道（Pipe）：这是一种半双工的通信，数据只能单向流动。它又分匿名管道（用于父子进程）和命名管道（FIFO）。
消息队列（Message Queue）：消息的链表，存放在内核中。相比管道，它支持随机查询，不一定按先进先出。
信号量（Semaphore）：它其实不是用来传大量数据的，更多是作为一种锁机制，用来处理进程间的同步。
套接字（Socket）：这是最通用的，可以跨网络通信，也可以在本机进程间（Unix Domain Socket）通信。Android 的 Zygote 接收 AMS 请求创建进程，用的就是 Socket。
共享内存（Shared Memory）：这是最快的一种方式，后面我会详细展开。

然后重点说说 Android 针对移动端做的优化方式：

Binder：这是 Android 的招牌。它的优势在于性能（只需一次拷贝）和安全性。Android 绝大多数的服务调用（比如调用系统相机、获取地理位置）都是通过 Binder 实现的。
ContentProvider：虽然它是四大组件之一，但底层也是基于 Binder，专门用于进程间的数据共享。
Messenger：它是对 Binder 的一种简单封装，通过 Handler 发送 Message，适合简单的、低频的跨进程消息传递。
广播（Broadcast）：基于观察者模式，通过 Intent 进行通信，虽然灵活但效率相对较低。

我之前在分析 AOSP 的输入系统（Input System）时，发现它用的是 InputChannel。这个 InputChannel 本质上是封装了 Unix Domain Socket。这让我意识到，虽然 Binder 很快，但对于像触摸事件这种极其频繁、对实时性要求极高的数据，Socket 或者共享内存可能是更合适的选择。

所以面试官问到这里，我会强调：没有最好的方式，只有最合适的方案。对于系统服务调用用 Binder，对于大数据传输用共享内存，对于低频消息用 Messenger。

共享内存的优势？

讲到共享内存，它在所有进程间通信（IPC）机制中，速度绝对是王者。它的核心优势只有一个字：快。之所以快，是因为它实现了数据的“零拷贝”逻辑（在用户空间层面看）。

我们可以对比一下。比如用管道或者 Socket 传数据，数据需要经历这样的过程：

发送方把数据从自己的用户空间缓冲区 copy_from_user 拷贝到内核缓冲区。
接收方再把数据从内核缓冲区 copy_to_user 拷贝到自己的用户空间。这里一共发生了两次拷贝，而且涉及两次系统调用导致的上下文切换。

而共享内存的逻辑是：操作系统在物理内存里开辟一块区域，然后通过 mmap 把这块物理内存同时映射到进程 A 和进程 B 的虚拟地址空间。这样，进程 A 往这块内存里写东西，进程 B 几乎是瞬间就能看到，完全不需要经过内核的转发。

在 Android 中，这种机制被封装成了 Ashmem（Anonymous Shared Memory，匿名共享内存）。

Ashmem 有两个非常显著的特点：第一，是刚才说的极速。在 Android 中，最典型的应用就是 Bitmap 的传输。早期的 Android 版本里，跨进程传大图很容易 OOM，后来改为把 Bitmap 数据放到 Ashmem 里，进程间只传一个文件描述符（FD）。第二，是特有的回收机制。Ashmem 允许系统在内存不足时，回收掉那些被标记为 "unpin" 的内存块。这对于移动端这种内存紧张的环境非常友好。

不过，共享内存也不是完美的。它的优势也是它的劣势。 因为多个进程可以同时访问这块内存，所以它不提供同步机制。如果两个进程同时往里写，数据就乱套了。所以在使用共享内存时，我们通常需要配合**信号量（Semaphore）**或者 Mutex（互斥锁） 来保证数据安全。

我之前看过 SurfaceFlinger 的源码，UI 的渲染缓冲（GraphicBuffer）其实就是基于匿名共享内存的。App 作为生产者在 Buffer 上画图，SurfaceFlinger 作为消费者去读，两者之间通过特定的同步机制（Fence）来协作。这种设计支撑起了 Android 流畅的 UI 表现。

信号是怎么进行进程同步的？

嗯，关于信号（Signal），其实它是 Unix/Linux 系统中一种非常古老的异步通信机制。简单来说，信号就像是一个进程对另一个进程的“拍肩膀”提醒，告诉对方某个特定的事件发生了。

虽然信号主要用于异步通知，但通过特定的组合，我们确实可以用它来实现进程同步。

在底层的实现上，信号同步的核心其实是两个动作：发送信号和等待信号。比如进程 A 需要等待进程 B 完成某个任务后才能继续执行。这时候，进程 A 可以调用 sigsuspend() 或者 sigwait() 进入挂起状态，主动放弃 CPU。等进程 B 完成任务后，再通过 kill() 系统调用发一个自定义信号（比如 SIGUSR1）给进程 A。这时候内核会唤醒进程 A，它收到信号后就会去执行预设的 Signal Handler（信号处理函数），处理完后接着跑后面的代码。这就完成了一次简单的同步。

我在看 AOSP 源码，特别是 ART 虚拟机和 Debuggerd 这一块时，发现 Android 内部大量使用了信号。

最典型的一个例子就是 ANR 的堆栈抓取。当系统发现一个应用响应超时时，SystemServer 进程会向目标应用进程发送一个 SIGQUIT（信号 3）。应用进程里有一个专门的 SignalCatcher 线程，它一直阻塞在 sigwait 上。一旦收到这个信号，它就会被唤醒，然后去 dump 当前所有线程的堆栈信息，最后写到 /data/anr/traces.txt 里。这其实就是一种利用信号实现的“跨进程任务同步”。

不过，信号同步也有它的局限性。首先，信号是不带负载的，你只能知道“发生了什么类型的事”，但没法直接传复杂的数据；其次，信号是不可靠的（除非是实时信号），如果短时间内发了多个相同的信号，内核可能只会记录一个。

所以，在 Android 开发中，如果我们要处理复杂的进程同步，通常会优先考虑 Binder 或者 Semaphore（信号量）。信号更多是被用在底层的异常处理（比如 SIGSEGV 段错误）或者系统级的状态通知上。

多进程多线程的死锁问题？死锁什么情况下发生？如何解决？

死锁（Deadlock）真的是开发中的噩梦，尤其是逻辑复杂了之后。结论先行的话，死锁就是两个或多个执行单元（线程或进程）因为互相持有对方需要的资源，同时又在等待对方释放资源，导致大家都卡死在那，谁也动不了。

要发生死锁，必须同时满足四个必要条件，这也就是著名的 Coffman 条件：

互斥条件：资源一次只能被一个执行单元占用。
请求与保持条件：我已经拿到了资源 A，但我还在等资源 B，而且我不放手里的 A。
不剥夺条件：别人手里的资源，我不能强行抢过来，只能等他自己放。
循环等待条件：形成了一个闭环，比如 A 等 B，B 等 C，C 又在等 A。

在 Android 开发中，我遇到过最典型的死锁其实是 Binder 线程耗尽导致的死锁。比如进程 A 同步调用进程 B，进程 B 内部又反过来同步调用进程 A。如果这时候进程 A 的 Binder 线程池已经满了，它就没法处理 B 发过来的请求，而 A 又在等 B 的返回，这就形成了跨进程的循环等待。

那怎么解决死锁呢？ 通常有三个层面的策略：

第一是预防（Prevention）。最简单的办法就是破坏循环等待。我们可以规定，所有的线程在获取多个锁的时候，必须按照固定的顺序。比如必须先拿 Lock A 再拿 Lock B，这样就不会出现“你拿 A 等 B，我拿 B 等 A”的情况了。

第二是避免（Avoidance）。在分配资源前先算一算，如果给了你资源，系统会不会进入不安全状态。这就涉及到了后面会提到的银行家算法。

第三是检测与恢复。在 Android Framework 里，有一个非常有名的机制叫 Watchdog（看门狗）。SystemServer 里很多核心服务（比如 AMS、WMS）都会实现 Watchdog.Monitor 接口。Watchdog 会定期去检查这些服务的锁是否被长时间占用。如果发现某个服务卡住了（比如超过 1 分钟没响应），Watchdog 就会认为发生了死锁或者严重的阻塞，然后直接杀掉 SystemServer 进程，导致系统重启。虽然这很暴力，但它保证了系统不会永远死在那里。

我们在写 App 代码时，通常会用 ReentrantLock 的 tryLock(timeout) 来代替 synchronized。如果规定时间内拿不到锁，就直接报错或者走回退逻辑，而不是死等。这样能极大提高系统的健壮性。

银行家算法

嗯，提到死锁避免，银行家算法（Banker's Algorithm） 绝对是最经典的理论。它是 Dijkstra 大神提出来的。核心思想非常直观：系统在处理资源请求时，会先模拟分配一下，看分出去之后系统还是不是“安全的”。如果分出去后，至少还存在一种顺序能让所有进程都顺利跑完，那就分；否则，就拒绝请求。

之所以叫这个名字，是因为它模拟了银行家放贷的场景：银行家得保证手里留的钱，至少能满足某一个客户的全部需求，等这个客户还钱了，再满足下一个。

要理解这个算法，得关注四个核心数据结构（我们可以把它想象成几个矩阵）：

最大需求矩阵 (Max)：每个进程最多需要多少资源。
已分配矩阵 (Allocation)：现在每个进程手里有多少资源。
需求矩阵 (Need)：每个进程还差多少资源，计算公式是： $Need = Max - Allocation$
可用资源向量 (Available)：系统现在手里还剩多少。

算法的执行逻辑是这样的： 当一个进程提出资源申请时，系统先检查：申请量是否超过了它声明的最大值，以及系统现在够不够分。如果够分，系统就假装分给它，然后更新数据，接着跑一遍安全性检查算法（Safety Algorithm）。

安全性检查会去找：现在 Available 的资源，能不能满足某个进程的 Need？如果能，就假设这个进程跑完了，把它手里的资源全部回收回来，更新 Available。接着再找下一个能满足的。如果所有的进程都能按某个顺序排好队跑完，我们就说这个状态是 Safe（安全） 的，这时候才会真正把资源发下去。

那在真实的 Android 或者 Linux 系统里，真的在用银行家算法吗？ 其实几乎不用。

原因有两个：首先是性能开销太高。每次申请资源都要跑一遍矩阵运算，对于高频的系统调用来说太慢了。其次是前提条件太理想化。银行家算法要求在进程启动前就知道它一生中需要的资源最大量（Max），但在现代操作系统里，进程是动态变化的，我们很难预知一个 App 以后会打开多少个文件、申请多少内存。

所以，虽然银行家算法在理论上非常优美，但在像 Android 这样的复杂系统中，我们更多还是靠锁顺序规范、超时机制以及像 Watchdog 这样的监控重启机制来解决死锁问题。不过，理解这个算法能帮我们建立一种“资源预警”的思维模式。

LRU两个功能get(key) 和 put(key, value)，要求时间复杂度O(1)

嗯，LRU（Least Recently Used，最近最少使用）算法在 Android 开发里实在是太常见了。比如我们常用的 LruCache，底层其实就是基于这个逻辑来做内存缓存的，防止像 Bitmap 这样的大对象把内存撑爆。

结论先行：要实现 get 和 put 都是 $O(1)$ 的复杂度，核心方案就是使用“哈希表 + 双向链表”组合在一起的数据结构。

其实在 Java 里，我们甚至不需要手写，LinkedHashMap 只要在构造函数里把 accessOrder 设置为 true，它天然就是一个 LRU。但我之前研究过它的实现原理，手动实现的话，逻辑是这样的：

首先，为什么要用哈希表？因为我们要 $O(1)$ 的查询。如果只用链表，找一个 key 得遍历，那是 $O(n)$ 。那为什么要用双向链表？因为 LRU 要求把最近访问的元素移到头部，把最久没用的从尾部删掉。单向链表在删除节点时，需要找到前驱节点，那是 $O(n)$ ，而双向链表配合哈希表存节点引用，可以实现 $O(1)$ 的删除和插入。

具体的操作流程是：

get(key)：我们先从哈希表里找。如果没找到，直接返回 -1 或者 null。如果找到了，因为这个元素刚刚被访问过，所以我们要把它从链表的当前位置抠出来，挪到链表的头部（代表最新访问）。最后返回它的 value。
put(key, value)：
- 先查哈希表。如果 key 已经存在了，那就更新它的 value，然后同样把它移动到链表头部。
- 如果 key 不存在，我们要先判断当前的 Capacity（容量）。如果已经满了，我们就得把链表尾部的那个节点删掉，同时别忘了在哈希表里也把它删了。
- 最后，创建一个新节点，插到链表头部，并存入哈希表。

我在看 Android 的 LruCache 源码时发现，它的 get 方法里其实就有一行 map.get(key)，因为 LinkedHashMap 在 get 的时候，如果开启了 accessOrder，它内部会触发一个 afterNodeAccess 的回调，自动把节点移到末尾（它的实现是末尾为最新，逻辑是一样的）。

所以总结一下， $O(1)$ 的秘诀就是：用 Hash 找位置，用双向链表管顺序。

快排、斐波那契递归、二分查找的时间复杂度和斐波那契递归的优化

关于这几个经典算法的复杂度，我平时写算法题的时候经常会做对比和分析，其实它们分别代表了不同的算法思想。

首先是快排（Quick Sort）。快排是一种分治（Divide and Conquer）的思想。

平均时间复杂度是 $O(n \log n)$ 。它的逻辑是选一个基准点（Pivot），把数组分成两半。
最坏时间复杂度是 $O(n^2)$ 。这通常发生在数组已经是有序的，或者每次选的 Pivot 都是最大/最小值，导致递归树变成了一个长长的单链。
空间复杂度是 $O(\log n)$ ，这主要是递归产生的栈空间开销。

接着是二分查找（Binary Search）。这是处理有序数组的神器。

时间复杂度是 $O(\log n)$ 。因为它每次都能排除掉一半的搜索区间。
前提条件是数据必须是有序的，而且支持随机访问（所以通常是数组）。

然后是斐波那契递归（Fibonacci Recursion）。如果我们写最简单的 f(n) = f(n-1) + f(n-2)：

时间复杂度非常恐怖，是 $O(2^n)$ 。
原因是它存在大量的重复计算。比如算 f(5) 要算 f(4) 和 f(3)，算 f(4) 又要算一遍 f(3)。你可以想象这棵递归树，越往下分支越多，完全是指数级增长。

关于斐波那契递归的优化，我总结了三种渐进的方案：

第一种是备忘录法（自顶向下）。既然重复计算多，那我们就用一个数组或者 HashMap 把算过的结果存起来。每次递归前先查表，有就直接拿。这样时间复杂度就直接降到了 $O(n)$ ，空间复杂度也是 $O(n)$ 。

第二种是迭代法 / 动态规划（自底向上）。其实我们不需要递归栈。我们直接从 f(1)、f(2) 开始往后推。

Java

for (int i = 3; i <= n; i++) {
    sum = a + b;
    a = b;
    b = sum;
}

这种方式的时间复杂度是 $O(n)$ ，如果我们只用两个变量来存前两项的值，空间复杂度可以优化到 $O(1)$ 。这也是面试中最推荐的写法。

第三种比较硬核，是矩阵快速幂。利用斐波那契数列的矩阵变换公式，配合快速幂算法，可以将时间复杂度进一步降低到 $O(\log n)$ 。虽然在 $n$ 比较小的时候看不出优势，但当 $n$ 达到千万级别时，这个优化是非常显著的。

在 Android 开发中，其实这种思想也随处可见，比如 Layout 嵌套过多导致的重复测量，本质上也是一种类似斐波那契递归的“冗余计算”。所以我们提倡扁平化布局（ConstraintLayout），本质上也是为了把 $O(2^n)$ 或者更复杂的复杂度降到线性的 $O(n)$ 。

字节客户端

进程与线程的区别？

嗯，关于进程和线程，这是操作系统最基础的概念了。简单来说，进程是资源分配的最小单位，而线程是 CPU 调度的最小单位。我们可以把进程想象成一个工厂的车间，而线程就是车间里干活的工人。

其实在 Android 开发里，这两个概念体会得非常明显。当我们启动一个 App 时，系统会为这个 App 创建一个独立的进程，并且分配一套独立的内存空间。这意味着，进程之间是相互隔离的。如果一个 App 崩溃了，通常不会影响到其他 App 的运行，这就是因为进程隔离保证了系统的稳定性。

而线程呢，是跑在进程内部的。一个进程可以包含多个线程，它们共享这个进程的资源，比如堆内存、全局变量、打开的文件描述符等等。所以线程之间的通信比进程快得多，但也带来了一个问题：如果多个线程同时操作一个数据，就容易出并发安全问题。

我之前在看 AOSP 源码，特别是 ActivityThread 的时候，发现 Android 应用启动后默认就有一个“主线程”，也就是 UI 线程。其实主线程也是通过 Thread 类创建出来的，只不过它里面跑了一个 Looper 循环。

总结一下它们的区别，主要有这么几点：

拥有资源不同：进程拥有独立的地址空间和资源，而线程基本不拥有系统资源，只是一段执行流。
健壮性不同：一个进程崩了，在多进程模式下不会连累别人；但一个线程要是触发了段错误（Segmentation Fault），整个进程可能就直接 OOM 或者 Crash 了。
开销不同：创建或销毁进程的开销很大，因为涉及内存分配、页表映射；而线程的切换相对轻量很多，只需要保存寄存器和栈信息。

所以在 Android 里，我们既要利用多线程（比如用线程池）来处理耗时任务，保证 UI 顺滑；也要在某些特殊场景下使用多进程（通过 android:process 属性），比如为了避开单进程内存限制，或者是做推送这种需要保活的服务。

进程之间怎么通信？你用过哪些？

既然进程之间是内存隔离的，那它们要“说话”就必须通过内核（Kernel）。常见的 IPC（进程间通信）方式有很多，包括 Linux 原生的管道、信号量、共享内存、Socket，以及 Android 专门定制的 Binder。

在我平时的开发和源码阅读中，接触最多的肯定还是 Binder。其实我们在写代码时用的 AIDL，底层就是 Binder。比如我在之前的一个项目中，需要做一个跨进程的插件化框架，插件跑在独立的进程里，主进程需要调用插件的服务，这时候就必须用 AIDL 来定义接口。

除了 Binder，我其实还用过以下几种：

Messenger：它是对 Binder 的一种封装，用起来像 Handler 一样发消息。优点是它处理请求是串行的，所以不用担心线程安全问题，适合一些轻量级的跨进程调用。
ContentProvider：虽然它是四大组件之一，但它的本质也是跨进程通信。我之前在处理多进程共享数据库的时候，就是通过 ContentProvider 来对外暴露数据的，它底层其实也用到了 Binder。
Socket：这个在应用层开发用得少，但在 Framework 层非常重要。比如我之前分析 Zygote 启动流程时发现，系统服务通过 Socket 发送指令给 Zygote，让它 fork 出新的应用进程。还有就是调试时用的 adb，也是基于 Socket 的。
共享内存（Anonymous Shared Memory, Ashmem）：它的速度最快。Android 里的 SurfaceFlinger 在传递图形数据缓冲区（GraphicBuffer）时，其实就利用了共享内存，配合 Binder 传递文件描述符（FD），实现了超大规模数据的高效传输。

总的来说，如果是普通的业务逻辑跨进程，首选 Binder；如果是传递大量大数据（比如图片、视频流），那我会考虑 共享内存；如果是简单的跨进程通知，广播（Broadcast） 也是一种方式。

操作系统分配给进程的资源有哪些？

嗯，这个问题其实涉及到操作系统是怎么“养活”一个进程的。结论先行，操作系统分配给进程的资源主要包括：虚拟地址空间、物理内存、CPU 执行时间、文件描述符，以及必要的系统标识符（如 PID/UID）。

展开细说的话，我觉得可以分为以下几个核心部分：

第一是内存资源。系统会给每个进程分配一个独立的虚拟地址空间（比如 32 位系统下是 $4GB$ ）。在这个空间里，又细分为：

代码段：存放程序的可执行二进制代码。
数据段：存放全局变量和静态变量。
堆（Heap）：我们通过 malloc 或者 Java 里的 new 申请的内存都在这。
栈（Stack）：存放函数的局部变量、参数和返回地址。

第二是文件资源。在 Linux 里“万物皆文件”，所以进程持有的打开文件、Socket 连接、管道等，系统都会分配一个 文件描述符（File Descriptor, FD） 来追踪。我之前调试过一个 Bug，就是因为代码里打开流没关，导致 FD 泄露，最后进程报了 Too many open files 的错误崩掉了。

第三是处理器资源。也就是 CPU 时间片。操作系统通过调度算法，决定这个进程能占用 CPU 多久。

第四是状态和标识。包括 PID（进程 ID）、UID（用户 ID）。在 Android 系统的权限模型里，UID 非常关键。每个 App 默认都有唯一的 UID，系统根据这个 UID 来限制它能访问哪些受保护的资源。

还有就是一些进程上下文。当进程被切出 CPU 时，它的寄存器状态、程序计数器（PC）等数据都要被保存下来。

在 Android 里，还有一个特殊的“资源管理”，就是 OOM Adj 评分。AMS 会根据进程的状态（比如是在前台还是后台）给进程分配一个分数。当系统内存紧张时，Low Memory Killer (LMK) 就会根据这个分数来决定杀掉哪些进程来回收资源。

为什么内存管理要采用分页管理？为什么不用分段？

内存管理从“分段”演进到“分页”，其实是为了解决两个核心痛点：内存碎片问题和内存利用率问题。结论是：分页机制通过将内存切成固定大小的微小块，彻底解决了外部碎片，并且能更好地支持虚拟内存。

咱们先聊聊分段（Segmentation）。分段是比较符合人类逻辑的，比如把内存分成代码段、数据段、堆栈段。每个段的长度是不固定的。它的致命缺点是外部碎片。比如我先分了三个段，中间那个段被回收了，空出了 $10MB$ 的空位。但我现在想申请一个 $11MB$ 的段，明明总空闲内存够，但因为这 $10MB$ 不连续，我还是申请不到。这就导致了严重的内存浪费。

为了解决这个问题，就引入了分页（Paging）。分页不再考虑逻辑上的“段”，而是把物理内存和虚拟内存都切成固定大小的块，通常一页是 $4KB$ 。它的优势非常明显：

解决外部碎片：因为页的大小是固定的，系统可以把物理内存中任何空闲的页，映射到虚拟内存的任何位置。即使物理内存是散落在各处的，但在虚拟空间看来，它们可以是连续的。
离散分配：我们不需要在物理内存里找一块连续的大空间，只要空闲页的总数够，就能运行程序。
支持置换算法：因为页很小，系统可以灵活地把暂时不用的页交换到磁盘（Swap/ZRAM），用的时候再加载回来。这种细粒度的控制，分段是很难做到的。

虽然分页会带来一点点内部碎片（比如我只申请 $1KB$ ，但系统必须给我一页 $4KB$ ，剩下的 $3KB$ 就浪费了），但比起分段导致的巨大外部碎片，这点代价完全可以接受。

我平时看 Android 内存指标（比如 Procrank 出来的结果）时，会看到 VSS、RSS、PSS、USS。其实这些指标的计算，背后逻辑全都是基于页的。比如 PSS 就会把多个进程共享的共享库内存页，按比例摊分到每个进程头上。这种精确的内存统计，也是依赖分页机制和 页表（Page Table） 的映射关系才能实现的。

其实现在的系统通常是段页式结合：先在逻辑上分段（方便权限控制，比如代码段只读），然后在物理实现上分页（方便内存分配）。这也是硬件 MMU（内存管理单元） 工作的基本逻辑。

HTTPS 如何加密？

嗯，关于 HTTPS 的加密，简单来说它其实不是一种单一的加密算法，而是一套结合了对称加密、非对称加密和摘要算法的混合方案。它的核心思路是：用非对称加密来安全地交换“对称密钥”，然后用对称加密来高效地传输实际业务数据。

我之前在研究 OkHttp 源码的时候，特意去看过它的 RealConnection 是怎么建立 TLS 连接的。整个过程大致可以分成三个阶段：

第一个阶段是身份验证（数字证书）。这是为了防止“中间人攻击”。当客户端向服务器发起请求时，服务器会发回一个 CA 证书。客户端（比如 Android 系统的 Conscrypt 引擎）会去校验这个证书是不是权威机构颁发的、有没有过期、域名对不对。如果校验通过，客户端就能拿到服务器的公钥。

第二个阶段是密钥协商（非对称加密）。这时候客户端会生成一个随机数，作为后续通信的“对称密钥”。然后用刚才拿到的服务器公钥，把这个随机数加密后发给服务器。因为只有服务器有对应的私钥，所以只有它能解开这个随机数。到这一步，双方就达成了一个只有彼此知道的“暗号”。

第三个阶段是数据传输（对称加密）。既然双方都有了同一个对称密钥（比如 AES），后续的所有业务数据就都用这个密钥加密。对称加密的效率非常高，适合处理大量的图片、JSON 数据。

其实这里还有一个细节，就是为了防止数据被篡改，HTTPS 还会用到摘要算法（比如 SHA-256）。每一段数据都会带上一个 MAC（消息认证码），接收方收到后会重新计算一遍，对比一下就知道数据有没有被动过。

我在做 Android 开发的时候，经常会遇到**证书锁死（Certificate Pinning）**的需求。其实就是在 App 里硬编码服务器证书的哈希值，防止用户在系统里手动安装了恶意抓包工具的根证书。理解了 TLS 的握手流程，做这种安全加固的时候思路就会非常清晰。

TCP 为什么要四次挥手？三次不行吗？

这个问题的核心在于 TCP 是全双工的（Full-Duplex）。简单来说，四次挥手是为了确保通信双方都能体面地关闭各自的数据发送通道，谁也不欠谁的数据。

为什么要四次而不是三次呢？咱们可以带入一下场景。当客户端发送 FIN 包（告诉服务器“我没数据要发了”）时，服务器收到后会立刻回一个 ACK。但这时候，服务器可能还有没发完的数据。

如果是三次挥手，也就是把服务器的 ACK 和它自己的 FIN 合并成一个包，那就会强制要求服务器在收到客户端关闭请求的一瞬间，也必须立刻关闭。这显然不符合实际情况。

具体的流程是这样的：

第一次挥手：客户端发送 FIN，进入 FIN_WAIT_1 状态。
第二次挥手：服务器收到后回一个 ACK，告诉客户端“我知道你没数据了”。这时候客户端进入 FIN_WAIT_2。注意，此时服务器还能继续给客户端发数据，这个状态叫“半关闭”。
第三次挥手：等服务器把手头剩下的数据全发完了，它才会发送自己的 FIN 包，进入 LAST_ACK 状态。
第四次挥手：客户端收到服务器的 FIN 后，回最后一个 ACK，然后进入 TIME_WAIT 状态。

这里其实有一个面试常考的点，就是 为什么客户端要等 2MSL 才能彻底关闭？ 其实我之前看过 Linux 内核的网络栈实现，设置这个时间是为了防止最后一个 ACK 丢了，导致服务器收不到反馈而不断重发 FIN。同时，这也能保证在这一对 IP 和端口上产生的旧数据包在网络中彻底消失，不会干扰下一次新连接。

所以，三次挥手虽然看着省事，但它没法保证服务器端的数据能完整传完。四次挥手这种“先断一半，再断另一半”的设计，才是最稳妥的。

系统重启的时候意外断电，数据的完整性如何保证，因为很多操作不是原子的。

这确实是一个非常棘手的问题，尤其是在移动设备上。核心的解决思路只有两个：一个是利用文件系统的日志机制（Journaling），另一个是应用层的原子提交（Atomic Commit）。

首先，在文件系统层。现在 Android 用的基本都是 Ext4 或者 F2FS。这些文件系统都有“日志”功能。当系统要写一个大文件时，它不会直接去改磁盘上的原始数据，而是先在日志区记录一下：“我准备要把 A 改成 B”。等数据写完了，再把这条日志标记为已完成。如果写到一半断电了，重启时系统扫描日志区，发现有一个任务“开了头没结尾”，就会自动把这部分脏数据回滚掉，保证文件系统的结构不损坏。

其次，在 Android Framework 层，针对配置文件的修改，Google 提供了一个非常有用的工具类叫 AtomicFile。我之前看 JobSchedulerService 或者 SettingsProvider 源码时经常看到它。它的原理很简单：

它先创建一个 .bak 备份文件。
把新数据写入到一个临时文件。
写入成功后，通过 rename 这个原子性的系统调用，把临时文件替换成正式文件。
最后删掉备份。如果中间断电了，重启后发现正式文件坏了，它就会从 .bak 恢复，保证数据至少是断电前的那个正确版本。

最后是数据库层。SQLite 默认是支持事务的。它在修改数据前会产生一个 Journal 文件 或者 WAL 文件（预写日志）。哪怕你在 commit 的那一毫秒断电了，SQLite 重启后也能根据日志文件把数据恢复到事务开始前的状态，或者继续完成提交。

所以，保证完整性的关键在于：永远不要直接覆盖原始数据，而是先写副本或日志，最后通过一个原子性的操作（比如指针切换或文件名替换）来生效。

写前日志（WAL）的详细工作机制是怎样的？

嗯，讲到数据安全和性能的平衡，WAL（Write-Ahead Logging） 绝对是绕不开的话题。它的核心思想正如其名：在对数据进行任何实际修改之前，必须先将修改操作记录到日志文件中。

在 Android 的 SQLite 里，默认模式往往就是 WAL。我们可以从三个维度来看它的工作机制。

第一是写入流程。在传统的 Journal 模式下，改数据要锁住整个数据库，性能很差。但在 WAL 模式下，当你执行一个 UPDATE 时，SQLite 不会去动原数据库文件（.db），而是把这个改动“追加”到旁边的 .db-wal 文件末尾。因为是顺序追加，不需要磁盘寻道，所以写入速度非常快。

第二是读取流程。这时候就有点意思了。如果一个线程想读数据，它会先去 WAL 日志里找，看有没有最新的版本；如果日志里没有，再去原数据库文件里读。这意味着，读操作和写操作可以同时进行，互不阻塞。这对于 Android 这种多线程并发读写的场景来说，性能提升非常明显。

第三是检查点（Checkpoint）机制。WAL 日志不能无限增长，否则读取会变慢（因为要在日志里找半天）。所以系统会定期执行 Checkpoint 操作，把 WAL 文件里的修改同步回原数据库文件，然后清空日志。在 Android 里，通常当 WAL 文件达到一定大小（比如 $1000$ 个页）时，就会触发自动合并。

我之前在研究 AOSP 里的 SQLiteConnection 时，发现 WAL 模式还有一个天然的优势，就是极强的崩溃恢复能力。因为原数据库文件在整个写入过程中是完全没动的，哪怕写日志的时候断电了，原文件依然是完好的。重启后，系统只需要重放（Redo）或者忽略掉不完整的日志条目即可。

总结一下，WAL 机制其实就是用空间换时间，利用顺序写的高效和读写分离的并发性，在保证 ACID 特性的前提下，极大提升了数据库的吞吐量。

C++ 虚函数怎么实现的？

嗯，说到 C++ 的虚函数，这其实是实现运行时多态的核心。简单来说，它的底层实现主要依靠两样东西：虚函数表（vtable）和虚函数表指针（vptr）。

其实，当我们为一个类声明了 virtual 函数时，C++ 编译器就会在编译阶段为这个类生成一张 vtable（虚函数表）。这张表本质上是一个函数指针数组，里面按顺序存放着这个类所有虚函数的地址。如果是子类重写了父类的虚函数，那么子类 vtable 里对应位置的地址就会被替换成子类自己的函数地址。

然后，在每个类对象的内存空间的头部（通常是前 4 或 8 个字节），编译器会悄悄插入一个 vptr（虚函数指针）。这个指针指向的就是该类对应的 vtable。

当你通过父类指针调用一个虚函数时，比如 ptr->func()，底层的执行逻辑其实是这样的：

先根据对象头的 vptr 找到对应的 vtable。
根据函数在表中的偏移量（offset），取出对应的函数地址。
跳转到那个地址去执行代码。

其实我在看 Android Framework 的 Native 层代码时，比如 SurfaceFlinger 或者 AudioFlinger，里面大量使用了这种多态机制。比如 BnInterface 或者各种 RefBase 相关的子类。理解了虚函数表，就能明白为什么虚函数调用比普通函数慢一点点，因为它多了一次内存寻址的开销，而且由于是运行时动态绑定的，编译器也很难对它进行内联优化。

虚函数表和虚函数表指针是每个类一个还是每个对象一个？

这个细节其实挺关键的，面试的时候经常会被问到。结论非常明确：虚函数表（vtable）是每个类一份，而虚函数表指针（vptr）是每个对象一份。

我们可以从内存效率的角度去理解： vtable 里面存的是函数地址，这些地址对于同一个类的所有实例来说都是一模一样的。所以，编译器为了节省空间，会把 vtable 放在程序的只读数据段（.rodata）。不管你 new 了 100 个还是 1000 个对象，在内存里永远只有这一份表。

而 vptr 就不一样了。它是存在于每个对象的内存实例里的。为什么呢？因为在一个多态的环境下，比如一个 Animal* 指针，它在运行时可能指向 Cat 对象，也可能指向 Dog 对象。程序必须通过这个具体的对象实例，才能找到它对应的那个 vtable。如果 vptr 不是每个对象一份，系统就没法区分这个指针到底该去查哪张表了。

所以总结一下：vtable 是类的静态信息，全局唯一；vptr 是对象的成员变量，每个实例都有自己的一份，用来指向属于自己类的那个“导航表”。

delete 和 delete[] 的区别？

嗯，这两者最本质的区别在于：它们告诉编译器该如何处理“析构”和“内存释放”的范围。delete 是用来释放单个对象的，而 delete[] 是专门用来释放对象数组的。

如果我用 new 申请了一个对象，那必须用 delete。这时候，系统会先调用这个对象的析构函数，然后释放那一块内存。

但如果我用 new[] 申请了一个数组，比如 auto* arr = new MyClass[10]，情况就复杂了。这时候内存里不仅有 10 个 MyClass 的实例，系统通常还会在数组头部多申请一点空间来记录“10”这个数组长度。当我们调用 delete[] arr 时：

编译器会先去查那个隐藏的长度信息，知道数组里有 10 个元素。
然后它会循环调用这 10 个元素的析构函数，从后往前（通常是这样）一个个销毁。
最后，把整块连续的内存还给堆管理器。

如果你写错了，对数组用了普通的 delete，那后果可能很严重。 它只会调用第一个元素的析构函数，剩下的 9 个元素就直接“暴毙”了，它们的析构函数不会被执行。如果这些对象内部持有了文件句柄或者其他的堆内存，就会导致内存泄露。更糟糕的是，由于 delete 和 delete[] 在底层分配器内存块的管理方式可能不同，这种不匹配的操作有时甚至会导致程序直接 Crash。

delete[] 释放的过程是怎样的？

其实 delete[] 的释放过程就像是一个精密的“拆除工程”。它的核心逻辑是：读取计数器 -> 循环析构 -> 整体释放。

我之前专门查过编译器（比如 GCC/Clang）是怎么处理这一块的。当你执行 ptr = new MyClass[n] 的时候，编译器实际分配的内存空间往往比 $n \times sizeof(MyClass)$ 稍微大那么一点点（比如多出 4 或者 8 个字节）。这个多出来的头部位置，我们通常管它叫 Cookie。

具体的过程大概是这样的：

获取步长和个数：当你调用 delete[] ptr 时，运行时库会根据指针 ptr 往前偏移一点，读取出之前存进去的数组长度 $n$ 。
逆序析构：有了这个 $n$ ，编译器就会生成一段代码，起一个循环，调用这 $n$ 个对象的析构函数。为什么要逆序？这其实是遵循 C++ “先构造的后析构”的原则。
内存回收：等所有的析构函数都跑完了，delete[] 最终会调用底层的 free 或者类似的内存管理函数，把包含 Cookie 在内的整块连续内存全部交还给系统。

其实在 Android Native 开发里，我们现在更多会推荐使用 std::vector 或者智能指针（如 std::unique_ptr<T[]>），因为它们会自动处理这些细节，避免手动调用 delete[] 忘加方括号导致的低级错误。

什么是右值引用？必须用 move() 函数转换吗？

关于右值引用，这是 C++11 引入的一个非常伟大的特性。它的核心目的就是为了实现“移动语义（Move Semantics）”，从而减少不必要的拷贝，提升性能。

通俗点说，右值引用（T&&） 就是专门用来绑定那些“即将销毁”的临时对象的（比如函数的返回值、字面量）。在传统的 C++ 里，如果你想把一个临时对象赋值给另一个对象，必须经过一次“拷贝”，这对于大的容器（比如 std::vector）来说非常耗时。而有了右值引用，我们可以直接把临时对象里的资源（比如指针）“偷”过来，把原来的指针置空。这就是所谓的“移动”而不是“拷贝”。

至于 std::move()，其实很多人对它有误解。结论是：它并不真的“移动”任何东西，它本质上就是一个强制类型转换（static_cast）。

它把一个左值（有名字、能取地址的对象）强转成一个右值引用。为什么要这么做呢？比如我有一个变量 A，我后面再也不用它了，我想把它“移动”给 B。但是编译器很保守，它看到 A 有名字，会把它当成左值。这时候我就需要显式调用 std::move(A)，告诉编译器：“嘿，你可以把 A 当成右值处理，去触发 B 的移动构造函数吧”。

所以，并不是必须用 move()：

如果你处理的本身就是一个临时对象（比如 return MyClass();），编译器会自动把它识别为右值，不需要 move()。
只有当你需要把一个本来是左值的长命对象，提前终结它的生命周期并转移资源时，才需要用到 std::move()。

其实在 Android Framework 源码里，右值引用用得非常多。比如在处理 Parcel 或者是 Binder 通信时，为了避免大数据块的拷贝，经常会看到移动语义的身影。理解了这一点，写出的 Native 代码性能会有质的飞跃。

有一个整数数组，这个数组里的元素顺序是不确定的，现在我们要查找第 K 大元素，有什么方法？

嗯，查找第 K 大元素是一个非常经典的算法题。结论先行的话，最常用的主要有三种方案：直接排序、堆排序优化，以及最优的快速选择算法（Quick Select）。

首先，最直观的方法肯定就是全排序。我们可以直接用 Arrays.sort()，在 Java 里底层对于基本类型通常是双轴快排，排完序之后直接取倒数第 K 个位置的元素。这种方法代码最简单，但时间复杂度是 $O(n \log n)$ 。如果数组非常大，比如有几千万个数据，全排序就显得有点浪费了。

第二个思路是利用小顶堆（Min-Heap）。我们可以维护一个大小只有 K 的小顶堆。遍历数组的时候，如果当前元素比堆顶大，就把它替换进去并重新堆化。遍历完一遍后，堆顶的那个元素就是第 K 大的。这种方法的复杂度是 $O(n \log k)$ 。它的好处是空间效率高，尤其适合处理那种“流式数据”，就是数据量大到内存放不下，或者数据是在不断产生的情况。在 Java 里，我们可以直接用 PriorityQueue 来实现。

第三个，也是面试中面试官最想听到的，就是快速选择算法（Quick Select）。它的思想源自于快速排序。快排的每一轮 partition 操作，其实都会把一个基准值（pivot）放到它最终确定的位置上。

如果这个位置正好是 $n - K$ ，那我们就找到了。
如果这个位置比 $n - K$ 大，说明第 K 大的数在左半边，我们只需要递归去处理左边。
反之，就处理右边。

这种方法的好处是，我们不需要对两边都进行递归，平均时间复杂度可以达到 $O(n)$ 。虽然最坏情况下会退化到 $O(n^2)$ ，但通过随机选择 pivot，基本可以规避这个问题。

其实在 Android 开发里，这种 Top K 的问题偶尔也会遇到，比如我们要展示耗电量最高的前几个 App，或者内存占用排名的统计。如果数据量不是天文数字，Quick Select 往往是性能表现最均衡的选择。

建堆的时间复杂度是多少？

这是一个特别容易产生误解的点。直接给结论：建堆（Heapify）的时间复杂度是 $O(n)$ ，而不是很多人直觉认为的 $O(n \log n)$ 。

我之前专门推导过这个过程。虽然往堆里插入一个元素的复杂度是 $O(\log n)$ ，如果我们通过 $n$ 次插入来建堆，那确实是 $O(n \log n)$ 。但通常我们说“建堆”，是指原地（In-place）建堆，也就是从最后一个非叶子节点开始，由下往上进行“下滤（Sift Down）”操作。

为什么要快一些呢？其实我们可以从每个节点移动的最大高度来算：

堆底部的节点最多，但它们的高度很低，几乎不需要移动。
堆顶部的节点虽然离地面远，移动步数多，但这种节点非常少。

如果我们把所有节点移动的步数加起来，会得到一个等比数列求和： $S = \sum_{h=1}^{\log n} \frac{n}{2^h} \times (h-1)$ 经过数学推导，这个级数是收敛的，最终的结果就是 $O(n)$ 。

所以，在处理 Top K 问题或者进行堆排序时，第一步初始建堆的过程是非常高效的，主要的开销其实是在后续不断弹出堆顶、重新调整的那部分逻辑上。

上述场景题（第 K 大元素）还有更优的方法吗？

如果我们已经讨论到了 $O(n)$ 的 Quick Select，再往上优化，其实就要看具体的业务场景和数据分布了。结论是：在特定条件下，我们可以利用计数排序的思想达到稳定的 $O(n)$ ，或者在海量数据下使用分布式处理。

第一种情况是数据范围有限。比如，如果我知道这个整数数组里的数字都在 0 到 10000 之间，那其实可以用计数排序（Counting Sort）。我开一个 10001 大小的数组，统计每个数字出现的次数，然后从大到小累加次数，直到加到 K 为止。这种方式的复杂度是 $O(n + m)$ ，其中 m 是数据的范围。这在某些特定业务场景下（比如统计考试排名）比 Quick Select 还要快。

第二种情况是针对海量数据（大数据场景）。如果数组大到一台机器的内存根本塞不下，比如有 100 亿个整数，这时候 Quick Select 就没法直接用了。这时候我们会采用分治法（MapReduce 思想）：

把数据切分成很多个小块，分发到不同的机器上。
每台机器算自己那块数据的 Top K。
最后把所有机器的 Top K 汇总到一起，再算一次总的 Top K。这其实也是大厂在处理日志统计、搜索热词时最常用的思路。

还有一种比较极端的优化，叫 Median of Medians（中位数的中位数算法）。它是为了解决 Quick Select 在极端情况下退化到 $O(n^2)$ 的问题。它通过一组复杂的取中值逻辑，保证了 pivot 的选择绝对不会太差，从而在最坏情况下也能保证 $O(n)$ 。不过这个算法实现起来非常复杂，常数项也大，在实际工程中其实很少直接用，更多是理论上的优化。

所以说，没有绝对的“最优”，只有最适合场景的方案。在 Android 端上，通常 Quick Select 或者小顶堆就足够应付绝大多数情况了。

手撕题：单循环链表

（注：面试官提到单循环链表，通常会要求实现基本结构、插入删除，或者是考察经典的环路判定问题。这里我以实现一个基础的单循环链表及其核心操作，并顺带提到约瑟夫环应用为例来回答。）

嗯，单循环链表其实就是在单链表的基础上，把最后一个节点的 next 指针指向了头节点，形成了一个圈。它的核心在于：我们要时刻注意判断循环结束的条件不再是 p == null，而是 p->next == head。

我先口述一下它的基本结构实现。首先我们要定义一个 Node 内部类：

Java

class Node {
    int data;
    Node next;
    Node(int data) { this.data = data; }
}

对于单循环链表，我通常会维护一个 head 指针。

在做插入操作时，如果是在头部插入，流程是这样的：

先创建一个新节点 newNode。
如果链表是空的，那就让 newNode.next = newNode，然后 head = newNode。
如果不为空，我需要先遍历到链表的尾部（找到 p.next == head 的节点），把尾部的 next 指向 newNode，再让 newNode.next = head，最后更新 head = newNode。

删除操作也是类似的，最关键的一点是要找到待删除节点的前驱节点。如果要删的是头节点，同样得先找到尾节点来更新它的 next。

其实单循环链表最经典的场景就是解决约瑟夫环（Josephus Problem）。我记得之前看一些算法题，比如有 $n$ 个人围成一圈报数，数到 $m$ 的人出列。用单循环链表来模拟这个过程是最直观的：

我们先建好这个环。
然后用一个指针在上面跳，每跳 $m-1$ 步，就删掉下一个节点。
直到最后 p.next == p，剩下的就是幸存者。

还有一个面试常考的点是环路检测。虽然单循环链表本身就是环，但面试官经常会问：给你一个普通的单链表，怎么判断它里面是否有环？这时候我会用到 Floyd 判圈算法（也叫快慢指针）。定义两个指针 slow 和 fast，slow 走一步，fast 走两步。如果存在环，它们一定会在环内相遇。这个算法在 AOSP 源码的某些逻辑处理（比如检查某些 Task 栈是否存在循环引用）中，其实也有类似的影子。

手写这类代码时，我习惯先画图，把那几个 next 指针的指向搞清楚，特别是边界情况（比如只有一个节点或者只有两个节点时），这样写出来的代码才稳健。

快手客户端

客户端卡顿如何排查？Android 绘制过程是怎样的？

嗯，提到卡顿排查，这其实是一个从“现象”到“工具分析”再到“底层原理”的过程。

先说结论，排查卡顿我会优先使用 Systrace（或者现在推荐的 Perfetto） 来看掉帧的具体位置。卡顿的本质就是每一帧的渲染产出没能赶上 Vsync 信号的频率。

我平时的排查思路是这样的：首先我会通过 Profile GPU Rendering 观察条形图。如果某一帧特别高，我会用 Perfetto 抓一个 Trace。在 Trace 里，我会重点看主线程的 Choreographer#doFrame 这一块。

如果是 Input/Animation 耗时长，说明逻辑太重。
如果是 Traversal 耗时长，那基本就是 Layout 嵌套太深或者 onMeasure 里有复杂的计算。
如果是 EnqueueBuffer 阻塞，那往往是 RenderThread 渲染压力太大，或者 GPU 忙不过来。

聊到绘制过程，其实在 Framework 层它是分应用层逻辑和系统层渲染两步走的。在应用层，起点是 ViewRootImpl.performTraversals()。它会依次触发 performMeasure、performLayout 和 performDraw。其实我读源码时发现，从 Android 5.0 引入 RenderThread 之后，UI 线程的 draw 过程只是把绘制指令（DisplayList）记录下来，然后通过一个同步的操作送给 RenderThread。

真正干重活的是 RenderThread。它会调用 OpenGL 或者 Vulkan 的 API，把这些指令转化成 GPU 能识别的命令，最后通过 nsecs_t 时间戳对齐 Vsync 信号，把 Buffer 提交给 SurfaceFlinger。

所以排查卡顿不能只看主线程，有时候是 RenderThread 里的 DrawFrame 耗时太久，比如 Bitmap 太大导致上传纹理（Texture Upload）超时，这种在 Trace 里看 uploadData 这个标签就能一眼看出来。

synchronized 和 volatile 介绍

这两个关键字是并发编程里的“老朋友”了。

先说结论，synchronized 保证的是原子性、可见性和有序性，是重量级的锁机制；而 volatile 保证的是可见性和有序性（禁止指令重排），但不保证原子性，它是靠 内存屏障（Memory Barrier） 实现的。

其实，synchronized 在 JVM 里的实现非常精妙。它在 Java 对象头里有个 Mark Word。早期的它确实是直接调用 OS 的互斥量，性能很重，但现在有锁升级机制：偏向锁 -> 轻量级锁 -> 重量级锁。我在处理多线程同步，比如单例模式或者线程安全的计数器时，会优先考虑它的语义完整性。

再说 volatile。它解决的是 JMM（Java内存模型） 里的缓存一致性问题。简单来说，每个线程有自己的工作内存，volatile 确保了变量被修改后，会立即强制刷新回主内存，并且让其他线程的缓存失效。它最经典的用法就是 DCL（双重检查锁定）单例模式。为什么要加 volatile？其实是为了禁止指令重排。因为 new 一个对象在底层分三步：分配空间、初始化、赋值引用。如果不加 volatile，CPU 可能会先赋值引用再初始化，这时候另一个线程拿到的可能就是一个还没初始化的“半成品”对象。

其实在 Framework 源码里，比如 ActivityThread 里的某些状态标记位，经常能看到 volatile，就是为了保证在不同线程切换时，状态是绝对同步的。

实习期间的技改提升及内存指标体现

在实习期间，我参与过一个关于图片资源管理和内存优化的技改项目。当时背景是 App 在低端机型上 OOM 率比较高，且冷启动时的内存在不断飙升。

先说结论，我主要是通过 线上内存监控工具的建设 和 大图检测插件 做的优化。技改的提升主要体现在 OOM 率下降了约 $15%$ ，以及主界面 PSS 占用降低了 $40MB$ 左右。

关于内存空间的提升，我主要通过以下几个维度来衡量：

第一是 PSS（Proportional Set Size）。这是最核心的指标，因为它按比例计算了共享库的占用，最能反映 App 实际消耗的物理内存。我们通过自研的工具，在排查时还会细看 Private Dirty（私有脏页），因为这部分内存是无法被系统回收的，直接决定了进程是否会被 Low Memory Killer 杀掉。

第二是 JVM Heap 堆内存。我们重点关注 Dalvik Heap 的利用率。如果堆内存持续走高且 GC 频繁（通过 Trace 观察到 GC_FOR_ALLOC 频繁出现），那就说明存在内存泄漏或者是瞬时对象分配压力太大。

第三个指标是 匿名共享内存（Ashmem）。在 Android 8.0 之后，Bitmap 的像素数据移到了 Native 堆。我们当时发现 Native 内存暴涨，最后通过 Hook Canvas.drawBitmap 发现是有些 UI 场景重复加载了超大分辨率的图，导致单张图就占了 $20MB$ 以上。

最后，衡量技改成功与否，我们还会看 VSS（Virtual Set Size），虽然它在 64 位系统上不那么敏感，但在 32 位系统上，如果虚拟内存耗尽，也会直接导致 pthread_create 失败抛出 OOM。

通过这些指标的闭环监控，我们当时成功定位并修复了三个核心模块的内存泄漏，最终让线上 crash 率有了明显的优化。

GC 算法有哪些？有针对 GC 做过优化吗？

嗯，关于 GC 算法，其实在 JVM 和 Android 的 ART 虚拟机里有几种经典的实现。

首先说结论，常见的算法包括 标记-清除（Mark-Sweep）、复制（Copying） 和 标记-整理（Mark-Compact）。而 Android 现在的 ART 虚拟机，主要是基于**分代回收（Generational GC）**的思想，结合了多种算法来平衡停顿时间和吞吐量。

其实在 Android 8.0 之后，ART 默认使用的是 Concurrent Copying (CC) 算法。它的牛逼之处在于，它在进行对象移动和压缩时，大部分时间是跟应用线程并发执行的。通过引入“读取屏障（Read Barrier）”，它极大地缩短了 Stop-The-World (STW) 的时间，所以我们在新系统上感觉卡顿少了很多。

关于 GC 优化，我在做应用层开发和 Framework 调试时，主要从“减少对象分配”和“防止内存泄漏”两个维度切入：

第一，避免在频繁调用的地方创建对象。最典型的就是 onDraw 方法。如果在 onDraw 里 new Paint() 或者 new Path()，每一秒 60 帧，那就是一堆短命对象，会迅速占满 Young Gen，触发频繁的 Minor GC，导致所谓的“内存抖动”。我一般会把这些对象做成成员变量复用。

第二，善用数据结构。我会优先使用 Android 提供的 SparseArray 或者 LongSparseArray 来替代 HashMap。因为 HashMap 每一个 Entry 都是一个对象，而 SparseArray 是通过双数组（Binary Search）实现的，能省掉不少拆装箱的开销，从而减轻 GC 压力。

第三，大对象的及时回收。比如 Bitmap，在 Android 高版本虽然像素数据在 Native 堆，但 Java 层的回收依然会触发 Native 内存释放。我会在不需要时主动调用 recycle()，或者配合 LruCache 严格控制内存占用，防止触发系统级的强力 GC 或者 OOM。

我之前读过 ART 的 Heap.cpp 源码，发现系统在内存紧缺时会触发 CollectGarbageInternal。了解了这些底层逻辑后，我在写代码时会更有意识地去控制对象的生命周期。

实习中 Redis 复合键结构设计、TPS 及优化方案

在实习期间，我参与过一个业务场景的缓存设计。当时我们采用了 业务前缀:用户ID:行为类型 这种复合键（Composite Key）结构。

先说结论，这样设计的核心理由是 实现多维度的快速定位和命名空间隔离。它既方便了批量查询（比如用 SCAN 配合前缀匹配），也规避了 Key 冲突，同时提高了可读性。当时的单机 TPS 大约在 $8000$ 到 $1.2W$ 左右，属于中等规模的请求量。

如果 TPS 扩大十倍（达到 $10W+$ 级），我会从这几个方面做优化：

Redis Cluster 分片：单机肯定扛不住了，需要通过分片将压力均匀分布到多个节点。
引入 Pipeline：减少网络 RTT 开销。把多个命令打包发送，尤其是在批量写入复合键时，性能提升非常大。
多级缓存（L1 Cache）：在 App 进程内或者服务端内存里加一层 Guava Cache 或者 Caffeine。针对热点 Key，直接在内存返回，不到 Redis 这一层。
连接池优化：调整 Jedis/Lettuce 的连接池参数，防止在高并发下因为获取连接而造成阻塞。

关于 Bitmap 方案和 TTL 方案：

Bitmap：我们主要用它做用户签到或活跃统计。它非常省内存，一个 Bit 位代表一个用户状态， $1亿$ 个用户也就 $12MB$ 左右。但要注意 “偏移量过大” 的问题，如果 Offset 分布极稀疏，会导致底层分配很大的空间。
TTL（过期时间）：这是保证缓存新鲜度的关键。要注意 “缓存雪崩”，我当时在设计时，会对 TTL 加一个随机扰动值，防止大量 Key 在同一时刻集体过期。

监控设计上，我会新增：

大 Key（BigKey）监控：如果一个复合键下挂了太多的哈希字段，查询时会阻塞单线程的 Redis。
命中率监控：如果命中率跌得厉害，说明缓存设计或者数据预热有问题。
慢日志监控：记录执行时间超过 $10ms$ 的命令。

关于 CPU 性能和平台性变化的指标：在移动端平台，CPU 性能指标不仅看 Load Average，更要看 频率（Frequency）限制 和 核心调度（Affinity）。

平台性变化：比如 ARM 的 大小核架构（big.LITTLE）。在高性能需求时，我们要确保关键线程（如 RenderThread）运行在大核上。
温度限制（Thermal Throttling）：手机发烫时，CPU 会降频，这时候即使逻辑没变，帧率也会掉。所以排查性能时，必须把 “当前频率” 和 “温度” 作为一个基准参考值。

HashMap 的底层实现与线程安全 List 的选型

嗯，聊到 HashMap，这算是 Java 集合框架里最经典的面试题了。

先说结论，HashMap 的本质是一个 “数组 + 链表 + 红黑树” 的结构。它通过 hash() 算法将 Key 映射到数组下标。当发生哈希碰撞时，先用链表处理；当链表长度超过 $8$ 且数组长度达到 $64$ 时，为了优化查询效率，会转换成红黑树。

其实我在看 JDK 源码时，印象最深的是它的 扩容（resize） 机制。它的数组长度始终保持为 $2$ 的幂次方，这样在计算下标时可以用 (n - 1) & hash 代替取模运算，效率非常高。而且扩容时，它并不是简单地重新计算，而是通过位运算判断原 Hash 值的某一位是 $0$ 还是 $1$ ，从而决定是留在原位还是移动到“原位置 + 旧容量”的位置。

至于 ConcurrentHashMap，它是怎么保证线程安全的呢？在 Java 8 之后，它摒弃了早期的分段锁（Segment），转而采用 “CAS + synchronized” 的细粒度锁。它只锁住链表或红黑树的头节点，这样只要不是访问同一个 Hash 桶，多个线程就能并发写入，性能提升很大。

那如果我们要用一个线程安全的 List 呢？通常有三种选择：

CopyOnWriteArrayList：这是最常用的。它的核心逻辑是 “写时复制”。当你往里写数据时，它会先 lock 住，然后把底层的 Object[] 数组拷贝一份，在副本上修改完后再把引用指回去。这种设计非常适合 “读多写少” 的场景，因为读操作是完全无锁的。
Collections.synchronizedList：它其实就是一个包装类，给所有的公共方法都加了 synchronized。虽然安全，但并发性能比较差。
Vector：这个现在基本不用了，它的机制跟 synchronizedList 类似，但它属于历史遗留代码，扩容机制也不够灵活。

所以，如果是我在 Android 业务逻辑里处理异步数据流，比如管理监听器列表，我一般会首选 CopyOnWriteArrayList。

Java 常见的异常体系与 finally 失效场景

异常处理是系统稳定性的基石。

先说结论，Java 的异常基类是 Throwable，下分两个大分支：Error 和 Exception。而我们通过 try-catch-finally 捕获时，在某些极端情况下，比如 System.exit() 或者 线程被强杀，finally 块是不会执行的。

首先简单捋一下体系：

Error：一般是 JVM 层面的严重问题，程序通常无法自救。比如 OutOfMemoryError（堆溢出）、StackOverflowError（栈溢出，常见于死循环递归）。我在做 Framework 开发时，这种错误一旦发生，基本就是进程崩溃重启。
Exception：分为 编译时异常（Checked Exception） 和 运行时异常（Runtime Exception）。像 IOException 就是典型的编译时异常，强制你捕获；而像 NullPointerException、IndexOutOfBoundsException 这种，通常是逻辑不够严谨导致的。

关于 finally 无法被处理的情况，其实有这么几种可能：

使用了 System.exit(int)：如果在 try 块里直接杀掉了虚拟机，主线程都没了，finally 自然跑不到。
无限循环或线程阻塞：如果在 try 块里进了一个死循环，或者调用了某个一直不返回的 Native 方法，执行流根本走不到 finally。
系统掉电或内核崩溃（Kernel Panic）：这是硬件级别的停机。
守护线程（Daemon Thread）的中断：如果 try-finally 是在守护线程里执行的，而当所有非守护线程结束时，JVM 会直接退出，此时守护线程的 finally 不保证一定执行。

其实我之前写代码时还遇到一个坑，就是在 finally 里写了 return。这会覆盖掉 try 块里的返回值或者抛出的异常，导致逻辑非常难排查，所以现在我的习惯是 finally 只做资源回收（比如 close()），绝不写逻辑跳转。

实习中的灰度发布与状态机具体设计

在实习期间，我参与过一个功能模块的上线管理。当时为了保证大版本更新的平稳过渡，我们自研了一套基于 状态机（State Machine） 的灰度发布系统。

先说结论，灰度发布的核心是 “分流策略”，而状态机则是为了 管理发布单的生命周期。通过状态机，我们能确保发布流程在“待发布、灰度中、全量、回滚”这些状态间转换时，逻辑是绝对闭环且幂等的。

具体的状态机设计是这样的：我们定义了四个核心状态：

INIT（初始态）：配置完灰度比例（比如 $5%$ ）和过滤规则（比如仅限内测用户）。
GRAYING（灰度中）：此时系统会根据 User ID 的 Hash 值 取模，匹配命中的用户会下发新的配置。
FULL_RELEASE（全量态）：灰度数据观察 OK（比如 Crash 率没波动），通过状态机切换到全量。
ROLLBACK（已回滚）：一旦触发告警，一键切换到回滚态，状态机强行将版本降级。

在灰度策略设计上，我印象比较深的是“多维度分流”：

我们不只看百分比，还支持 白名单 和 标签属性（比如特定机型、特定地域）。
分流算法用了 MurmurHash 算法，因为它计算速度快而且分布非常均匀，避免了某些 Hash 算法在特定分片下的数据倾斜。

为什么用状态机？ 其实如果不写状态机，代码里就会充斥着大量的 if-else。用了状态机（我们当时参考了 AOSP 里 StateMachine 的设计模式），每一个状态只处理自己感兴趣的 Message。比如在 GRAYING 状态下，只接受 PROVE_SUCCESS（灰度成功）或者 EMERGENCY_STOP（紧急停止）事件。

这种设计的最大好处是可追踪。每一单灰度到了哪个阶段，之前经历了什么跳转，后台日志一清二楚。这在多人协作的大厂环境里，对排查线上发布问题非常有帮助。

AI 的使用、知识图谱设计及与 SQL 系统的转化效率

嗯，关于 AI 和知识图谱这一块，其实是我在做一些自动化工具和数据治理时的尝试。我主要是利用大模型（LLM）作为“大脑”，把非结构化的技术文档转化为结构化的知识图谱，再通过它去辅助生成 SQL 或者直接查询。

先说结论，知识图谱的设计核心在于 “本体（Ontology）建模”。我将 Android 开发里的组件、权限、API 建模为节点，将调用关系、约束关系建模为边。提升转化效率的关键在于 “结构化 Prompt 约束” 和 “中间层 DSL 映射”，而不是让 AI 直接去猜 SQL 逻辑。

具体设计上，我的知识图谱采用了 属性图（Property Graph） 模型。比如，一个节点可能是 Activity 类，它的属性包含它的包名、基类；边则代表 startActivity 的调用或者 intent-filter 的匹配。

为了提升它与 SQL 系统 的转化效率，我当时做了几件事：

模式对齐（Schema Mapping）：我给 SQL 数据库的每一个表和字段都定义了详细的语义描述。AI 在生成 SQL 之前，先去知识图谱里检索相关的“实体元数据”，这就相当于给 AI 准备了一份“参考书”。
Text-to-Cypher / Text-to-SQL 的双路校验：如果直接生成 SQL 往往会因为表结构太复杂而报错。我会先让 AI 生成简单的图查询语句（Cypher），在图谱里锁定实体 ID 后，再反向生成针对 SQL 数据库的精准 WHERE 条件。
引入微调（SFT）和 Few-Shot：我准备了大概 $200$ 多个典型的 Android 开发查询案例（比如“查找所有申请了 CAMERA 权限且在主线程做 IO 操作的类”）。通过这种方式，AI 对 SQL 逻辑的理解准确率提升到了 $90%$ 以上。

其实我觉得最难的部分是 逻辑推理的闭环。知识图谱能提供全局的关系视图，而 SQL 擅长处理具体的数值记录。通过知识图谱预处理掉复杂的关联关系，能极大减轻 SQL 系统在做多表 Join 时的压力，转化效率自然就上来了。

Android 里的 Message, MessageQueue, Looper, Handler 之间的关系

这四个组件可以说是 Android 异步机制的“四大支柱”。我在读 ActivityThread 源码的时候，天天都要跟它们打交道。

先说结论，它们的关系可以看作是一个 “生产-分发-消费” 的闭环模型。Handler 负责生产和消费消息，MessageQueue 负责存储，而 Looper 则是驱动整个传送带转动的电机。

具体细节上，我们可以把它们串起来看：

Handler：它是我们最常操作的接口。它就像一个“快递员”，你可以通过它 sendMessage。但你要注意，Handler 在创建时会通过 Looper.myLooper() 获取当前线程的 Looper，并关联到 Looper 持有的那个 MessageQueue 上。
MessageQueue：它名义上叫队列，其实底层是一个 单链表，按消息的执行时间（when 字段）从小到大排列。它就像一条“传送带”。
Looper：它是最关键的驱动者。一个线程只能有一个 Looper，它是通过 ThreadLocal 来保证唯一性的。它内部有一个死循环 loop()，不停地调用 queue.next() 去拿消息。如果传送带上没货，它就通过 nativePollOnce 阻塞住，释放 CPU；有货了就赶紧唤醒。
Message：它就是我们要运送的“货物”。它里面有一个很重要的字段叫 target，其实就是发它的那个 Handler。

当 Looper 拿到一条 Message 后，它会调用 msg.target.dispatchMessage(msg)，这样货又回到了 Handler 的手里，最终触发 handleMessage 或者 Runnable。

其实我在看源码的时候发现了一个很有意思的细节：为了提高效率，Message 内部实现了一个 对象池（Message Pool）。我们用 Message.obtain() 而不是 new Message()，就是为了复用这些对象，减轻 GC 的压力。这在我自己写高性能组件时，也是一个非常值得借鉴的思路。

内存泄漏的情况及解决方法

在 Android 开发中，内存泄漏（Memory Leak）几乎是每个开发者都会遇到的痛点。我在实习期间也专门排查过这类问题。

先说结论，内存泄漏的本质是 长生命周期的对象持有了短生命周期对象的强引用，导致短生命周期对象在需要被回收时，由于 GC Root 可达而无法释放。我一般通过 LeakCanary 自动检测，配合 Android Profiler 和 MAT（Memory Analyzer Tool） 进行堆转储分析来解决。

我写过也修过几种最典型的情况：

第一种是 非静态内部类/匿名内部类持有 Activity 引用。比如我在 Activity 里定义了一个非静态的 Handler 或者 Thread。因为非静态内部类默认持有外部类的 this 引用，如果 Activity 销毁了，但 Handler 里的消息还没处理完，或者 Thread 还在跑，Activity 就泄露了。

解决方法：把 Handler 定义成 static 静态内部类，然后对 Activity 使用 WeakReference（弱引用）。这样 GC 发现只有弱引用指向 Activity 时，就会直接回收它。

第二种是 静态变量持有 Context。我曾见过有人为了方便，在单例里存了一个 Activity 的 Context。这会导致 Activity 永远无法退出。

解决方法：尽量使用 ApplicationContext，它的生命周期跟 App 进程一样长，存它没风险。

第三种是 资源未注销或未关闭。比如 EventBus 注册了没 unregister，或者 BroadcastReceiver 没解绑，还有 IO 流、数据库 Cursor 没 close。

解决方法：利用 Android 的生命周期回调，在 onDestroy 或 onStop 里严格执行注销逻辑。现在我会更多地使用 Lifecycle-aware components（如 ViewModel 和 LiveData），它们能自动感知生命周期，极大减少了这种低级错误。

其实在分析内存快照时，我重点看的是 GCRoot 路径。只要找到那条不该存在的引用链，问题就迎刃而解了。之前针对一个 Native 层的内存泄漏，我还研究过 Malloc Debug 机制，那又是另一个层面的排查了。