嘿，这个问题挺有意思的，我之前也碰到过类似的情况。其实核心原因是Android 8.0（API 26）对View的UI更新逻辑做了底层优化，和Android 6、7的线程检查机制完全不一样：

• 在Android 7及以下版本中，当你在子线程调用TextView.setText()这类UI操作时，只要View已经附着到Window（比如Activity走完onCreate流程后），ViewRootImpl里的checkThread()方法会直接校验当前线程是否为主线程，一旦不是就立刻抛出CalledFromWrongThreadException。
• 而从Android 8.0开始，Google调整了这个逻辑：当非主线程尝试更新UI时，系统会自动把这个UI操作通过Handlerpost到主线程去执行，不会直接崩溃。不过这里有个前提——如果当前View还没完成attach到Window的过程，或者处于某些特殊状态，还是可能触发异常，但大部分常规场景下不会出现崩溃了。

不过必须提醒：绝对不要依赖这个系统兜底行为！子线程更新UI本身就违反Android的设计规范，哪怕不崩溃，也可能导致UI状态不一致、绘制错乱或者潜在的性能隐患。正确的做法还是通过标准方式确保UI操作在主线程执行，比如：

正确实现示例（Java） #

// 替换你子线程里的setText操作
runOnUiThread(new Runnable() {
    @Override
    public void run() {
        textContent.setText("更新后的文本内容");
    }
});

正确实现示例（Kotlin 协程） #

lifecycleScope.launch {
    withContext(Dispatchers.Main) {
        textContent.text = "更新后的文本内容"
    }
}

内容的提问来源于stack exchange，提问作者王治海