主线程与UI线程：Android单线程模型、Looper与Handler

说起Android的线程模型，很多人第一反应是「不能在主线程做耗时操作」。没错，但这背后到底怎么回事？咱们今天彻底掰扯清楚。

3.1 为什么Android是单线程模型

Android的UI框架不是线程安全的。说白了，所有UI组件的访问、修改，都只能在同一个线程里进行。这个线程就是主线程（也叫UI线程）。

我早年刚做Android时，遇到过一个很诡异的问题：App启动时偶尔卡住几秒，再点一下又好了。查了半天，才发现是某个同事在Activity的onCreate里直接做了一次网络请求。嗯，那会儿年轻，不知道这其实已经踩了ANR的坑了。

为什么不能多线程随便改UI？你想想看，如果两个线程同时修改同一个TextView的内容，最终显示成什么？系统没法保证一致性，干脆规定：所有UI操作都排队到主线程里做。这样虽然牺牲了并行性，但换来了的安全。

3.2 Looper与Handler：主线程的"消息管家"

主线程空闲的时候在干嘛？它其实一直在转一个死循环——Looper循环。Looper在循环里不断从MessageQueue里取消息，取到一条就交给Handler去处理。这个过程你每天写代码都在用，但很多人没细想过。

来看一个最常见的例子：

// 主线程中创建Handler
val handler = object : Handler(Looper.getMainLooper()) {
    override fun handleMessage(msg: Message) {
        // 这里一定在主线程执行
        textView.text = msg.obj.toString()
    }
}

// 在子线程中发送消息
thread {
    val result = doHeavyWork()
    handler.obtainMessage(0, result).sendToTarget()
}

Looper.getMainLooper()返回的就是主线程的Looper实例。每个线程只能有一个Looper，主线程的Looper在ActivityThread.main()里就已经启动好了。我习惯把Looper理解成「消息队列的监管员」，它只管从队列里拿消息，不管消息是什么内容。

Handler则更灵活，它负责把消息塞进MessageQueue，也负责在消息被取出后执行回调。你可以在主线程创建Handler，也可以在子线程创建（只要子线程先调了Looper.prepare()）。

3.3 为什么不能在主线程做耗时操作

现在你应该明白了：主线程的Looper一直在循环取消息，处理那些消息（比如触摸事件、布局绘制、动画回调）。如果你在主线程里做了耗时操作（比如读写大文件、网络请求、复杂的加密计算），会发生什么？

Looper卡住了。它拿不到下一条消息，因为当前消息还没处理完。于是触摸消息得不到响应，界面60帧的刷新被阻塞，用户点哪都没反应。系统监测到这个现象——如果主线程阻塞超过5秒（具体看版本），就会弹出来那个让人头皮发麻的「应用无响应」对话框。

我曾经在一个电商项目里，上线后收到了大量ANR报告。定位后发现是一个定制键盘组件在输入时用了主线程去解密一个几十MB的加密字典。你想想看，用户打字都要卡几秒，体验能不崩吗？

那Compose里怎么保证UI不卡？Compose的UI执行也是在主线程，但它的重组机制可以配合协程在子线程做计算。比如用withContext(Dispatchers.IO)做耗时操作，然后把结果通过状态交给Compose在主线程刷新。这不是新知识，但很多人没把「单线程模型」和「Compose重组」联系起来。

我建议每个Android开发者都该在心里画一遍这张图：

3.4 实践中的避坑指南

知道了理论，我们用实战来说话。以下是我在项目里踩过的几个典型的「主线程耗时」坑：

• SharedPreferences的Commit操作：同步写磁盘，在复杂数据量下可能卡主线程。我遇到过用户反馈「Setttings页面点保存就ANR」，排查后发现是一个JSON对象直接commit到SP里，数据量大了以后主线程等了几秒。解决方案：改用apply（异步写，但也不完美），或者换DataStore。
• Bitmap的decodeStream：加载大图时直接在UI线程解析，容易被系统检测到。我记得有个相册列表，滑动时每张图片都在主线程decode，2秒后直接ANR。后来用Glide或者自己用子线程加载就解决了。
• 加密操作：这是咱们课程的重点。AES/CBC/PKCS5Padding加解密本身计算量不大，但如果数据量到几十MB，或者密钥派生用PBKDF2反复迭代，主线程跑一次可能1~3秒。我在做加密聊天App时，对方发的文件解密在主线程做，导致界面假死。后来用协程的withContext(Dispatchers.Default)把加密计算扔到通用线程池就OK了。

再强调一遍：Looper是主线程的命根子，Handler是跟命根子打交道的管道。 你如果不小心占用了Looper的去拿消息的时间，ANR就像定时炸弹一样等着你。

我个人的习惯是，在项目里写一个MainThreadChecker工具类：

object MainThreadChecker {
    fun assertNotMainThread(tag: String) {
        if (Looper.myLooper() == Looper.getMainLooper()) {
            throw IllegalStateException("$tag 不应该在主线程执行！")
        }
    }
    fun assertMainThread(tag: String) {
        if (Looper.myLooper() != Looper.getMainLooper()) {
            throw IllegalStateException("$tag 必须在主线程执行！")
        }
    }
}

配合单元测试或者Debug构建里启用，可以早期发现那些不小心在主线程做的耗时操作。说真的，这个习惯帮我至少避免了三次上线后的ANR事故。

嗯，关于单线程模型和Looper/Handler的底层逻辑，咱们就聊到这儿。下次写Compose时，记得在脑子里过一遍那张图——你写的每个LaunchedEffect、每个snapshotFlow其实都在跟这个模型打交道。理解了这些，后续Compose的异步优化才有根基。