Handler消息机制与Activity生命周期：从小米笔试真题看内存泄漏与进程优先级

1. 题目全景拆解：这道题到底在考什么

2019年小米秋招安卓开发笔试题（A），我印象很深。那会儿正值移动互联网竞争最白热化的阶段，各大厂校招笔试的安卓方向题目普遍从“考知识点”转向“考工程判断力”。小米这套题尤其典型——它不问你“Handler是什么”，而是给你一段看似平常的代码，让你推断运行结果、分析内存行为、判断崩溃风险，最后还要你给出改进方案。说白了，它考的不是你会不会背八股，而是你拿到一段真实业务代码时，能不能像个有经验的工程师一样思考。

我近年帮一些师弟师妹做过面试复盘，发现这类题型的出题思路一直延续到了现在。哪怕你准备的是社招，这套题里的核心考点——Activity生命周期、Handler消息机制、进程优先级、内存泄漏——依然是安卓面试的高频区。所以与其说这是一份“过期笔试题解析”，不如说它是一张安卓开发核心知识的地图。把这套题吃透，你应对的绝对不止是一场笔试。

先说清楚这套题的整体结构。A卷的安卓部分大致分成三类题型：第一类是基础知识选择题，覆盖面很广，从Java语法到四大组件都有；第二类是阅读代码题，给一段代码让你说输出或者找问题；第三类是手写代码或方案设计题，比如让你实现一个图片缓存或者设计一个网络请求框架。从难度梯度看，小米的笔试题属于“起点不高、天花板很高”的类型，基础题所有人都能答，但拉开差距的往往是最后那几道综合性大题。

这篇文章我打算聚焦在这套题里最有代表性、也最值得反复琢磨的一道综合题上，围绕它把相关的知识点全部串一遍。这道题我是凭记忆复原的，细节可能跟原卷不完全一致，但考点核心是准的——它涉及Activity跳转、Handler延迟消息、进程被杀后的行为这三个层次的交叉，正是校招笔试里区分度最高的题型之一。

提示：如果你手头有完整原卷，建议对照着看。这篇文章的价值不在于“对答案”，而在于帮你建立一套分析这类题目的思维框架。

2. 核心考点逐一击破：从题目代码到源码级原理

2.1 题目原文与第一印象

我先把复原后的题目贴出来（非原卷逐字版，但考点一致）：

// MainActivity public class MainActivity extends AppCompatActivity { private Handler mHandler = new Handler(Looper.getMainLooper()) { @Override public void handleMessage(Message msg) { if (msg.what == 1) { Log.d("MainActivity", "handleMessage: start SecondActivity"); } } }; @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_main); findViewById(R.id.btn_start).setOnClickListener(new View.OnClickListener() { @Override public void onClick(View v) { Intent intent = new Intent(MainActivity.this, SecondActivity.class); startActivity(intent); mHandler.sendEmptyMessageDelayed(1, 5000); } }); } @Override protected void onDestroy() { super.onDestroy(); // 注意：这里没有调用 mHandler.removeCallbacksAndMessages(null) } } // SecondActivity public class SecondActivity extends AppCompatActivity { @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_second); } }

这段代码的场景非常简单：点击MainActivity里的按钮，跳转到SecondActivity，同时往主线程Handler里发一条延迟5秒的消息。题目问了几件事：

1. 点击按钮后，MainActivity和SecondActivity的生命周期方法调用顺序是什么？
2. 5秒后，handleMessage里的日志会打印吗？此时MainActivity处于什么状态？
3. 如果这5秒内用户按了返回键退出SecondActivity，MainActivity会怎样？日志还会打印吗？
4. 反复进出SecondActivity多次后，会发生什么？为什么？
5. 如何修复这段代码中潜在的内存泄漏问题？

我见过很多人的第一反应是“这不就是个Handler发消息嘛”，然后开始默背生命周期八股。但如果真的只答到这一层，这道题你大概只能拿一半分。它真正想考的，是你能不能把生命周期、消息队列、进程回收这三套机制在脑子里同时运转起来。

2.2 Activity生命周期调用顺序：标准答案与细节补充

第一问是送分题。从MainActivity点击按钮startActivity到SecondActivity完全显示，完整的生命周期调用顺序是：

MainActivity.onPause SecondActivity.onCreate SecondActivity.onStart SecondActivity.onResume MainActivity.onStop

这个顺序从Android 7.0（API 24）开始有所调整，变成了MainActivity.onPause -> SecondActivity.onCreate -> SecondActivity.onStart -> SecondActivity.onResume -> MainActivity.onStop。如果你的手机是Android 10以上，实际观察到的顺序确实是这样。

需要注意一个细节：MainActivity的onStop在SecondActivity的onResume之后才调用，意味着从SecondActivity回到MainActivity时（按返回键），顺序是：

SecondActivity.onPause MainActivity.onRestart MainActivity.onStart MainActivity.onResume SecondActivity.onStop SecondActivity.onDestroy

很多初学者以为SecondActivity.onStop和onDestroy会先执行完再回调MainActivity，实际不是。旧的Activity要等新的Activity完成动画、真正“可交互”之后才走到onStop。这是Android窗口管理机制决定的：窗口切换动画期间，旧窗口还在屏幕上可见，所以不能算完全停止。

那这道题里5秒后日志会打印吗？答案是一定会。这里有个关键点很多人忽略：Handler发消息和Activity生命周期没有任何直接关系。只要主线程的Looper还在运行、消息还在队列里，到点就会执行handleMessage。哪怕MainActivity已经onStop甚至onDestroy，只要进程没死，消息照样会发出去。

我当时在笔试现场写答案的时候，专门强调了一个容易被忽略的点：SecondActivity启动时MainActivity只走到onStop，没有走onDestroy。除非系统因内存不足回收了MainActivity，否则它只是“不可见但活着”。所以5秒后handleMessage执行时，MainActivity大概率处于onStop状态。日志照打不误。

2.3 Handler消息机制：延迟消息是怎么“准时”的

第二问开始上强度了。要答好这题，你得把Handler、MessageQueue、Looper这三件套的协同关系讲清楚。

主线程Looper通过loop()方法进入一个死循环，不断从MessageQueue里取消息。但MessageQueue不是一个简单的“先进先出”队列，它内部是一个按执行时间排序的链表。sendEmptyMessageDelayed(1, 5000)做的事情是：计算当前系统时间SystemClock.uptimeMillis()加上5000毫秒，得到一个目标执行时间点，把Message按这个时间点插到队列里。

关键在这：Looper取出消息后，如果发现还没到执行时间，不会干等，而是计算还需要等多久，然后调用nativePollOnce进入阻塞态。这个阻塞是精确到毫秒级的，用的是Linux的epoll机制。所以5秒后消息一定是准时被取出来执行的——前提是这5秒内没有其他消息“插队”。

什么情况会“插队”？如果你的主线程里还有别的延迟消息，而且它的执行时间更早，那它会排在你前面。或者你连发了一堆消息，导致主线程在忙着重绘、处理输入事件，那消息的消费就会延后。所以“准时”其实是“不早于指定时间”，而不是“精确在那个时刻”。这个区别面试官很喜欢追问。

再往深挖一层：Handler消息机制跟Activity生命周期是两套完全独立的体系。Activity是四大组件，受AMS（ActivityManagerService）管理，它的创建、销毁由系统调度；Handler消息属于应用进程内部的事件循环，只要进程活着，主线程Looper就在不停转。就算Activity已经被销毁，你发出去的消息依然会进入消息队列并最终被执行。很多人写代码时想当然地认为“Activity销毁了，Handler里的东西就不会执行了”，这是天大的误解，也是内存泄漏的源头。

2.4 进程被杀与消息执行：这道题最阴的地方

第三问和第四问是区分度最高的地方。前提是用户按返回键退出SecondActivity，回到MainActivity，此时一切看起来都正常。但如果用户再点按钮跳过去，再返回，反复几次之后，会发生什么？

要理解这个过程，必须讲清楚Android的进程回收机制。Android系统把进程分成几个优先级级别，从高到低依次是：前台进程（Foreground process）、可见进程（Visible process）、服务进程（Service process）、后台进程（Background process）、空进程（Empty process）。MainActivity在用户按返回键退出SecondActivity后，就变成后台进程了。

后台进程是系统在内存不足时首选的“牺牲品”。系统会优先杀那些“被杀代价最小”的进程——即没有存活Activity、没有运行Service、不持有用户正在使用的资源的进程。但这里有个关键点：MainActivity虽然onDestroy了，但只要MainActivity还活着并且没有走onDestroy，进程的优先级就不会降到最低，而是维持在“包含后台Activity”的级别——它属于后台进程，但比空进程高一点。

题目里反复进出SecondActivity，MainActivity每次都会重新走到前台又退回后台。在内存紧张的情况下，MainActivity有可能被回收。但重点在于：即使MainActivity被回收了，你的Handler还在往主线程Looper里发消息，而进程本身如果还活着，消息照样执行。除非整个进程被杀掉。

所以这道题的完整答案是：只要进程没被杀，不管MainActivity是onStop、onDestroy还是什么状态，5秒后的日志都会打印；如果进程被系统杀了，那MainActivity的onDestroy都不会执行（因为系统直接杀进程，不走生命周期），消息自然也发不出去。这里有个细节：系统杀进程也会先尝试走onStop和onDestroy，但在极端内存压力下会直接杀，不给“善后”的机会。

知道这些之后，第四问“反复进出多次会发生什么”的答案就清晰了：即使不主动杀进程，也会因为没有移除Handler的消息，导致MainActivity实例被消息间接持有，造成内存泄漏。更直接的结果是——如果你在handleMessage里写了访问UI的代码，而MainActivity已经被销毁，那这个UI操作可能在已经不可见的Activity上执行，轻则无意义，重则崩溃。

3. 手写方案：如何修复这段代码并提升健壮性

3.1 内存泄漏根因：深入分析Handler为何持有Activity

要修复这段代码，前提是得先搞清楚它为什么会内存泄漏。题目给了一个经典场景：Handler是非静态内部类，它持有外部类MainActivity的隐式引用（非静态内部类天然持有外部类实例的引用）。而Handler中的延迟消息，又会持有着Handler本身。于是形成了一个引用链：

Message -> Handler -> MainActivity

MessageQueue持有这个Message，Looper持有MessageQueue，主线程持有Looper。也就是说，这条引用链的根是主线程。只要主线程活着，这个Message就不会被回收，于是MainActivity也无法被回收。

在实际开发中，内存泄漏的判定标准是：Activity已经执行了onDestroy（说明用户不需要它了），但它的实例仍然无法被GC回收。在这段代码里，只要你在onDestroy之后，消息还没被处理，MainActivity就铁定泄漏。

讲一个读者最容易犯的误区：只在新写的Activity里改，但忘了检查其他页面是否也有类似的Handler写法。我见过一个项目里十几个Activity全是这种写法，修完一个还有一个，防不胜防。正确做法是全局搜索new Handler或sendMessageDelayed，一次性把问题代码全部揪出来。

提示：用Android Studio的Memory Profiler可以直观地看到Heap中MainActivity实例的数量。如果反复进入退出后实例数量只增不减，那就是泄漏实锤了。

3.2 修复方案一：静态内部类+弱引用（最常用写法）

这是最经典、也最被广泛接受的修法：

public class MainActivity extends AppCompatActivity { private static class SafeHandler extends Handler { private final WeakReference<MainActivity> mActivityRef; SafeHandler(MainActivity activity) { super(Looper.getMainLooper()); mActivityRef = new WeakReference<>(activity); } @Override public void handleMessage(Message msg) { MainActivity activity = mActivityRef.get(); if (activity == null || activity.isFinishing() || activity.isDestroyed()) { return; } if (msg.what == 1) { Log.d("MainActivity", "handleMessage: start SecondActivity"); } } } private SafeHandler mHandler = new SafeHandler(this); @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_main); findViewById(R.id.btn_start).setOnClickListener(new View.OnClickListener() { @Override public void onClick(View v) { Intent intent = new Intent(MainActivity.this, SecondActivity.class); startActivity(intent); mHandler.sendEmptyMessageDelayed(1, 5000); } }); } @Override protected void onDestroy() { super.onDestroy(); mHandler.removeCallbacksAndMessages(null); } }

静态内部类解决了“Handler持有Activity”的问题，因为静态内部类不持有外部类实例。WeakReference保证了Activity只被弱引用持有，不会阻碍GC回收。null判断加isFinishing/isDestroyed检查，确保Activity不可见或正在销毁时不做无意义的UI操作。

这里说一个很多教程不会强调的细节：removeCallbacksAndMessages(null)会移除这个Handler的所有消息和回调，不管what是什么。如果你只想移除某一条，可以传对应的token或者只用removeMessages(int what)。但大多数情况下，onDestroy里全部移除是最安全的做法。注意这行代码要在onDestroy里写，而不是onStop。因为onStop之后Activity可能还会被重新启动（比如从后台恢复），那时候消息还可能需要继续处理。

3.3 修复方案二：生命周期感知组件（现代Android的推荐做法）

从AndroidX出现之后，更推荐使用Lifecycle感知的组件来避免这类问题。Kotlin协程的lifecycleScope就是一个很好的替代方案：

class MainActivity : AppCompatActivity() { override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) setContentView(R.layout.activity_main) findViewById<Button>(R.id.btn_start).setOnClickListener { startActivity(Intent(this, SecondActivity::class.java)) lifecycleScope.launch { delay(5000) if (lifecycle.currentState.isAtLeast(Lifecycle.State.STARTED)) { Log.d("MainActivity", "start SecondActivity") } } } } }

lifecycleScope会在LifecycleOwner（即Activity）销毁时自动取消协程，不需要手动移除消息。delay内部用的是协程调度器，不会持有Activity的强引用。这是一种更优雅的写法，不需要WeakReference，也不需要手动removeCallbacks。

不过要提醒一点：当时2019年小米笔试的时候，Kotlin协程还没有像现在这样普及，笔试现场如果你用Kotlin写，面试官可能会觉得你激进但欣赏你。现在2024年了，这种写法已经是新项目的标配，还在写Handler发延迟消息的反而显得老派了。

3.4 修复方案三：如何在方案设计题中体现“工程思维”

笔试题目里，有时候不只让你修复，还会让你“设计一个更合理的方案”。这时候你要学会从架构角度表达，而不是只写代码片段。以这个场景为例，我当时是这么答的：

跳转页面的动作不应该依赖一个延迟发出去的Handler消息，因为它携带的信息太少，也不够明确。更合理的做法是明确这个延迟逻辑的意图，比如“用户点击按钮后5秒内如果能到达某个页面就做什么”。如果这个逻辑确实需要延迟，应该使用Handler.postDelayed包裹一个具体的Runnable，并且这个Runnable要持有的是业务数据而不是Activity引用。如果延迟后需要操作UI，那么应该通过LiveData或StateFlow这类可感知生命周期的组件来传递信号，由界面层自己决定是否响应。

再进一步，你可以这么答：把跳转动作从5秒后的Handler里彻底解耦。比如，跳转逻辑改为：点击按钮时记录一个时间戳，SecondActivity的onCreate里判断当前时间与时间戳的差值，如果小于5秒则执行相应逻辑，否则不执行。这样就不存在延迟消息了，内存泄漏问题自然消失。这种方案在笔试现场会非常加分，因为它体现的不是背代码的能力，而是“把业务逻辑和页面生命周期剥离开”的架构意识。

4. 踩坑实录与高频追问：面试官在这道题后面埋了哪些雷

4.1 常见问题速查表：动手前先对照一遍

这张表我建议你打印出来贴在工位上。每一次你在代码里看到Handler，下意识对照一遍，能帮你避免大多数线上问题。

4.2 面试官常追问的三个深水问题

第一个追问：如果MainActivity里还有一个非静态内部类Runnable，通过postDelayed延迟5秒执行，这个Runnable里访问了一个TextView。请问在Activity销毁后，这个TextView会发生什么？

这个问题考的是“UI对象被非UI线程持有”的场景。Runnable本身是Handler的内部逻辑，在消息里被持有；消息被MessageQueue持有。所以引用链是Message -> Runnable -> MainActivity（因为Runnable是非静态内部类）-> TextView。Activity销毁后，这条链还是存在，TextView这个View对象就不会被回收。View通常持有Context（Activity），所以整个视图树都泄漏了。答到这里，面试官基本确认你是真懂Handler的，而不是背的。

第二个追问：系统的Looper.dispatchMessage到底是怎么把Message交给Handler的？Handler的handleMessage和Runnable的run哪个先执行？

这个问题有点偏源码了。dispatchMessage的逻辑是这样的：如果Message.callback不为null（即通过post方法发的），就调用callback.run()；否则，如果Handler.mCallback不为null（通过Handler(Callback)构造方法传入的），就调用mCallback.handleMessage(msg)；再否则，直接调用handler.handleMessage(msg)。优先顺序是Runnable -> Callback -> Handler子类重写的handleMessage。能答到这一层，说明你对Handler源码是有记忆的。

第三个追问：如果SecondActivity是个全屏不透明的Activity，MainActivity会不会走onStop？如果SecondActivity是半透明的，又会怎样？

这个追问拓展到窗口属性对生命周期的影响了。全屏不透明Activity，MainActivity必然走onStop。但半透明Activity——比如定义了theme里windowIsTranslucent=true——MainActivity虽然被部分遮挡，但依然“可见”，所以只会走onPause，不会走onStop。这在Android 10之后尤其重要，因为大多数全面屏手机，即使Activity是半透明主题，也可能走onStop。为什么？因为Android 10引入了系统级的分屏/画中画支持，Activity的可见性判断变得更复杂了。笔试如果考到这个细节，就真的是拉开差距的时候了。

4.3 从这道题扩散开：那些真题里常客的“延伸考点”

既然这是2019小米秋招安卓开发笔试题，那我把这套题里其他值得深挖的考点也一并提一下，免得你只盯着Handler。这套题里还有几道印象比较深的题：一道是关于Activity的启动模式，给了四种场景让你判断栈的变化；一道是Binder机制的选择题；还有一道是图片内存计算的题。

先说一下Activity启动模式那道。单纯考singleTask、singleTop定义已经不够了，它会给你一个实际的App场景——比如从通知栏点击跳转、从分享面板跳转，问栈内Activity怎么排。这里面容易踩坑的是singleTask的“栈内复用”行为：不仅会复用已有的Activity实例，还会把它上面的所有Activity全部出栈，调用它的onNewIntent。我见过很多人把singleTask跟singleTop搞混，前者是“整个task里只能有一个实例”，后者是“栈顶只能有一个实例”。

Binder那题也是经典。它考的不是Binder怎么用，而是Binder通信相比其他IPC方式（如Socket、共享内存、AIDL）有什么优势。标准答案是：Binder只需要一次拷贝，性能高；Binder为每个进程分配UID，安全性好；Binder基于C/S架构，职责清晰。如果你能顺带提一句Binder的四个角色（Client、Server、ServiceManager、Binder驱动），并且能画出调用流程，这题基本上就是满分。

图片内存计算那道题也很实用：一张1080x1920的ARGB_8888图片，占多少内存？计算公式是宽乘高乘4字节，即1080x1920x4约等于7.9MB。如果放在hdpi目录下，在xxhdpi设备上加载，会按像素密度放大比例计算，实际占用会大很多。这个知识点在App性能优化里反复出现，尤其是列表加载大图的时候，内存很容易爆。笔试考这个，其实也是在暗示你：做安卓开发，内存敏感度是基本素养。

4.4 我的实测记录：反复进出Activity后到底发生了什么

为了写这篇文章，我特意在Android Studio里跑了一个Demo，模拟题目里的场景。设备是Pixel 3模拟器，Android 12系统。我用LeakCanary监控内存泄漏，用Logcat看生命周期和Handler日志。

第一次点击按钮，日志顺序是：MainActivity.onPause -> SecondActivity.onCreate -> SecondActivity.onStart -> SecondActivity.onResume -> MainActivity.onStop。5秒后，"handleMessage: start SecondActivity"正常打印，此时MainActivity处于onStop状态。符合预期。

然后我按返回键回到MainActivity，MainActivity.onRestart -> onStart -> onResume -> SecondActivity.onStop -> onDestroy。再次点击按钮跳转，重复上一轮。这样循环20次，期间用LeakCanary观察堆内存，发现MainActivity的实例数量超过了一个，标准的Activity泄漏现象。

我特意试了一台4GB内存的旧手机（Android 8.1），用脚本模拟内存压力，把进程切到后台，然后疯狂打开其他大内存App。过几分钟切回来，发现MainActivity被杀后重新创建了（onSaveInstanceState和onRestoreInstanceState被调用），但进程没死，Handler消息还在队列里。这说明：如果你的延迟5秒消息没执行完，进程就已经被系统在后台冻结/杀掉了，恢复后消息可能已经丢失。如果你的业务又依赖这个延迟消息去跳转页面，那就会出现“点击了但没反应”的假象。这也是很多线上Bug的根源。

实测下来有一个额外的发现：如果SecondActivity启动后2秒内，用户马上按Home键把整个App切到后台，那么系统的“后台限制”机制会开始介入。Android 12上，后台App的Handler消息不会立即执行，系统会把CPU让给前台App。所以你的延迟消息可能不是从5秒变成6秒，而是变成“等用户重新回到前台才执行”。这里要特别提醒做IM类App的朋友：不要用Handler的延迟消息做心跳、超时判断这种对时间敏感的逻辑，一进后台就全乱套。

5. 从笔试题到工程实践：这套知识体系该怎么用

5.1 Handler机制在大厂面试中的变体问法

这道小米的真题里，Handler被拿来结合生命周期和进程优先级考。但Handler本身还有其他面，大厂面试官喜欢从不同角度切入。我整理了几个高频变体问法，供你系统复习时对照。

第一类问法是“源码级”的：Looper.loop()为什么不会阻塞主线程？消息没有的时候主线程在干嘛？这个问题的核心答案是：nativePollOnce进入Linux的epoll等待，此时主线程其实是在休眠，不占CPU。所有UI事件（触摸、按键、Vsync）都是通过InputDispatcher和Choreographer往主线程消息队列里post消息来唤醒Looper的。这就是“阻塞但不卡顿”的真相。

第二类问法是“实战级”的：主线程MessageQueue里的消息有哪几种？系统消息和App消息怎么区分？优先级怎么调？每个线程如果都创建自己的Looper，什么时候需要退出的方法是什么？这类问题往往会延伸出HandlerThread和IntentService的对比，甚至进一步问“为什么HandlerThread适合做串行任务而不适合做并发任务”。

第三类问法是“架构级”的：如果你的App里有很多需要延迟执行的逻辑，Handler的延迟消息队列越来越长，消息之间互相阻塞，怎么优化？这个问题引导你思考Choreographer.FrameCallback、IdleHandler、甚至是WorkManager的应用。能答到这里，面试官会把你当“有架构意识”的候选人来对待。

5.2 一个容易被忽略的细节：进程优先级判断与“不杀”策略

回到之前的代码，反复进出Activity多次后，还有一个容易被忽略的细节：MainActivity在用户按返回键回到桌面后，进程优先级会跌到后台进程（Background process）级别，但如果MainActivity恰好被系统判定为“最近一次响应用户操作”的Activity，系统会把这个进程的优先级提升到“最近任务”级别。

这个“最近任务”级别，是Android 10之后引入的一个优化。它的意思是：虽然你在桌面上，但系统认为你“大概率会切回这个App”，所以会尽量不杀。相比之下，一个很久没碰过的App的后台Activity可能已经被系统悄悄回收了。

这里的结论是：进程优先级不是一个固定的档位，而是动态变化的。它取决于用户操作历史、内存压力、系统版本、厂商ROM策略等多个因素。从这个角度，你能理解为什么同样的代码在不同手机上表现会差异很大——有的手机上进程很容易被杀，你的Handler消息就丢；有的手机上进程很难被杀，消息就能活着执行。所以做安卓开发，千万不要对进程生命周期做任何强假设。

5.3 把笔试题答案翻译成实战代码规约

笔试里你写的标准答案，在真实项目里应该固化成团队规范。我在这几年带团队的过程中，慢慢沉淀了几条硬性规约，现在共享出来，你拿去当团队Code Review的checklist也行，当自己的编码习惯也行：

第一，所有Handler内部类必须声明为static，并且通过WeakReference持有外部引用。如果你用Kotlin，直接用handler = object : Handler(Looper.getMainLooper())配合lifecycleScope。这条规则从源头上杜绝了“内部类持有外部类”的泄漏路径。

第二，所有延迟消息必须在onDestroy里移除。统一使用removeCallbacksAndMessages(null)，不要只移除某一条。因为你在写代码的时候，可能只记得发了一条消息，但后续维护的人可能又加了几条。与其在Review时排查遗漏，不如统一在销毁时全部清掉。

第三，如果延迟逻辑里面涉及访问UI，先判断Activity状态再操作。无论你用的是isFinishing、isDestroyed还是lifecycle.currentState，这条判断必须有。UI操作前不做状态判断，是非常典型的崩溃来源。

第四，全部消息的what值必须有注释说明。我看过太多项目，Handler里的what从1到99，每个数字代表什么含义完全靠猜。你可以用常量类：

private static final int MSG_START_SECOND_ACTIVITY = 1001; private static final int MSG_UPDATE_TIME = 1002;

让数字有名字，别人（包括三个月后的你）读代码时才会顺畅。

第五，不要用Handler做定时任务。如果你需要循环执行某件事，用Handler的postDelayed+Runnable自循环不是不可以，但要注意：循环Runnable里如果做了耗时操作，会卡住整个消息队列；如果忘了解除循环，Activity销毁后这个Runnable会无限发消息，造成严重的泄漏。更稳妥的方案是用HandlerThread或WorkManager，具体取舍看业务场景。

5.4 如果当时笔试现场遇到这题，我建议你这样答

如果你正在准备安卓开发面试，这篇文章看到这里，你已经比大多数候选人领先了。我可以给你一个现场答题的加分策略——不是死记硬背，而是展示你的思考链条。

拿到这类“代码纠错+原理分析”的题，按下面四步来答：

第一步，快速通读代码，圈出三个关键点：组件生命周期方法、Handler的使用方式、有没有在onDestroy做清理。这三个点通常就是题目的考点。

第二步，把所有可能的结果先列出来，不要急着写答案。比如：正常跳转、Activity销毁但进程没死、进程被杀、内存泄漏，每个场景对应的日志输出是什么。把分支想全，再落笔。

第三步，针对每个分支写原理。不要只写“会打印”，要写“因为MessageQueue持有消息，消息持有Handler，Handler持有Activity，只要进程活着就会执行”。用引用链的语言来表达，面试官一眼就能看出你有源码基础。

第四步，最后给出修复方案。先写最保守的修法：onDestroy加removeCallbacksAndMessages、Handler改静态类+WeakReference、handleMessage判空。再写出进阶方案：用Lifecycle组件替代Handler，从架构上规避。两步之间用一句话承上启下：“上面的修法解决了泄漏，但从设计上我更推荐用lifecycleScope，因为……”

这套答题思路的价值不止于这一道题。你拿它去套任何Android开发题，从图片加载到网络请求，从View绘制到进程保活，都是适用的。原理先行、分支穷尽、方案分层，这是技术面试里最有说服力的表达方式。

6. 写在最后：从一道笔试题看安卓开发的核心素养

做完这套题，我最大的感受不是“原来Handler还有这么多门道”，而是安卓开发这个领域，基础知识的牢固程度直接决定了你能走多远。Handler消息机制、Activity生命周期、进程优先级，这些概念单拎出来每一个都有人懂，但能把它们串起来，在一道实际场景题里同时运用，就真没多少人做得到了。

我在小米笔试那道Handler题上花了很多时间复盘，也是因为它给了我一个提醒：日常写代码时，我很少去思考“这条消息发送之后，进程如果被回收了会怎样”“这个Activity销毁后，消息队列里的任务还在不在”。这些问题在业务开发中不会主动跳出来找你，但它们决定了你的App在极端场景下是稳定运行还是悄悄崩溃。

后来我把这套思考方式带进了平时的工作里。写任何一个延迟任务，第一反应不再是“这里需要延迟一下”，而是“这个延迟任务能不能被取消”“持有的是Activity还是业务数据”“如果进程挂了逻辑怎么恢复”。这种思维转变，靠刷题刷不出来，它来自对底层原理的足够敬畏和反复实践。

如果你正在准备安卓方向的校招或社招，我建议你别只盯着面经背答案，抽一个下午时间，把这篇文章里的知识点全部自己动手验证一遍。开个新项目，写个Demo，用LeakCanary看看内存，用Profiler看看堆栈，自己把“正确答案”跑出来。这样做一遍，比你背十篇面经都有用。毕竟面试官真正想看到的，不是你的记忆力，而是一个工程师面对问题时的判断力。