异步 Inflate 管理器：用线程池预加载与安全回退加速首帧渲染

Android 的 View 创建天然和 Context、Theme、资源、构造函数有关。传统写法是在 Activity 或 Fragment 的主线程中调用 inflate，这个过程简单直接，但在复杂页面中可能造成明显卡顿。首页、活动页、详情页、搜索结果页——布局层级深、组件类型多、首屏展示时间敏感，inflate 成为首帧优化绕不开的一环。

异步 inflate 并不是新概念，但要在真实工程中稳定使用，需要处理更多边界：不是所有 View 都能在后台线程创建；有些自定义 View 在构造函数里访问主线程状态；有些属性读取依赖 Activity 的主题；有些业务逻辑在创建阶段就注册监听或访问窗口。单纯把 inflate 放进线程池，很容易遇到偶现崩溃或上下文泄漏。

我们项目里的实现位于 common/preload/AsyncInflateManager.kt。它不是简单调用平台 AsyncLayoutInflater，而是自己维护了任务 map、CountDownLatch、线程池和 MutableContextWrapper。页面可以提前提交 AsyncInflateItem，真正需要 View 时通过 getInflatedView 消费：如果后台已经完成，直接返回；如果正在 inflate，可以等待 latch；如果失败或未开始，则回退到 UI 线程同步 inflate。

MutableContextWrapper：上下文替换的关键

后台阶段可以用较安全的 Context 创建 View（来自 Application 并叠加必要主题包装），消费阶段再把 baseContext 替换成真实 Activity Context。这样既避免预加载阶段强持有旧页面，又保证 View 后续 startActivity、取主题、取资源时仍然正确：

class AsyncInflateManager(
    private val executor: ExecutorService,
    private val inflaterFactory: InflaterFactory,
    private val reporter: InflateReporter
) {
    fun preload(request: InflateRequest): InflateHandle {
        val future = executor.submit<InflateResult> {
            val safeContext = MutableContextWrapper(inflaterFactory.safeBaseContext())
            val inflater = inflaterFactory.create(safeContext)

            runCatching {
                val view = inflater.inflate(request.layoutName, parent = null)
                InflateResult.Success(view, safeContext)
            }.getOrElse { error ->
                InflateResult.Failure(error)
            }
        }
        return InflateHandle(request, future, inflaterFactory, reporter)
    }
}

消费阶段必须在主线程，核心逻辑是”有结果就用，没有就快速回退”：

class InflateHandle(
    private val request: InflateRequest,
    private val future: Future<InflateResult>,
    private val inflaterFactory: InflaterFactory,
    private val reporter: InflateReporter
) {
    fun consume(realContext: Context, parent: ViewGroup?): View {
        checkMainThread()

        val result = runCatching {
            future.get(8, TimeUnit.MILLISECONDS)
        }.getOrNull()

        return when (result) {
            is InflateResult.Success -> {
                result.wrapper.baseContext = realContext
                reporter.reportAsyncHit(request.scene, request.layoutName)
                result.view
            }
            is InflateResult.Failure -> {
                reporter.reportAsyncFailed(request.scene, result.error.safeName())
                inflateOnMain(realContext, parent)
            }
            null -> {
                reporter.reportAsyncTimeout(request.scene, request.layoutName)
                future.cancel(true)
                inflateOnMain(realContext, parent)
            }
        }
    }

    private fun inflateOnMain(context: Context, parent: ViewGroup?): View {
        return inflaterFactory.create(context).inflate(request.layoutName, parent)
    }
}

失败回退的两个层次

失败回退分两类。一类是后台 inflate 已经失败，消费时直接在 UI 线程同步 inflate。另一类是消费时后台任务还没完成，管理器可以短暂等待一个很小的时间窗口（8 毫秒）；如果超时，放弃等待并同步 inflate。这样能避免为了等待异步结果反而阻塞首帧。

消费等待时间要短。异步 inflate 的收益来自”提前完成”，不是在首帧时长时间等待。消费时如果结果还没准备好，应该快速回退 UI 线程同步 inflate，而不是阻塞几十毫秒等后台任务。

页面侧接入

页面可以把预加载放到更早的生命周期，比如路由命中或数据请求开始时：

class ExamplePageController(
    private val asyncInflateManager: AsyncInflateManager
) {
    private var headerHandle: InflateHandle? = null

    fun onPrepare() {
        headerHandle = asyncInflateManager.preload(
            InflateRequest(
                layoutName = "screen_header",
                scene = "example_page",
                parentPolicy = ParentPolicy.ATTACH_LATER
            )
        )
    }

    fun onCreateView(context: Context, container: ViewGroup): View {
        val header = headerHandle?.consume(context, container)
            ?: inflateSynchronously(context, container)
        bindHeader(header)
        container.addView(header)
        return container
    }

    fun onDestroy() {
        headerHandle?.cancelIfUnused()
        headerHandle = null
    }
}

对外接口保持保守，默认只允许白名单布局：

class InflatePolicy(
    private val enabled: Boolean,
    private val allowList: Set<String>
) {
    fun canAsyncInflate(layoutName: String): Boolean {
        if (!enabled) return false
        if (layoutName !in allowList) return false
        return true
    }
}

落地中的关键约束

不要把绑定逻辑放到后台 inflate。设置文本、注册点击、订阅数据、读取 Activity、访问 Window、启动动画都应在主线程执行。后台阶段只负责创建 View 层级。

自定义 View 如果在构造函数里访问主线程 Looper、创建 Handler、读取全局单例状态或触发异步任务，都可能不适合后台创建。接入前应先做白名单验证。

线程池要小而稳定。inflate 是 CPU 和资源解析密集型任务，线程过多会和主线程抢 CPU，反而加剧卡顿。通常使用一到两个后台线程即可，并限制队列长度，页面销毁后及时取消任务。

指标需要同时看命中率和失败率。只看平均首帧可能掩盖长尾风险。建议观察异步命中次数、后台失败次数、消费超时次数、主线程回退次数、页面首帧变化和相关崩溃率。只有命中率足够高、失败率足够低、首帧确实改善，才值得扩大范围。

异步 Inflate 的本质不是把所有布局创建都丢到后台，而是在页面生命周期中提前完成一部分确定、可控、收益明显的工作。MutableContextWrapper 提供了一个实用的上下文替换手段，但它不是万能保证。工程上必须配合白名单、短等待、失败回退、生命周期取消和指标观测，才能把这类优化从实验变成稳定能力。一个成熟的管理器应该让业务低成本接入，也能低成本撤回。最终评价标准不是”多少布局异步化”，而是用户是否更快看到可交互页面，同时线上稳定。