Android复杂RecyclerView UI初始化耗时约100ms：是否正常及优化方案咨询

先直接给你个结论：如果你的RecyclerView承载的是上百个带动态JNI属性的EditText，初始化耗时100ms属于合理但有优化空间的范围。下面我分两部分给你详细拆解：

一、这个耗时是否正常？ #

Android中，RecyclerView初始化的耗时受三个核心因素影响：

1. View本身的复杂度：EditText是相对重的View（自带输入逻辑、文本渲染），每个还要设置多个属性（颜色、内边距、字体大小等）；
2. JNI调用开销：你当前每个Item要调用6次nativeGetXXXProperty，跨JNI边界的调用本身有固定开销，上百个Item就会累积成可观的耗时；
3. 主线程阻塞：所有JNI调用和数据加载都在主线程执行，会挤占UI渲染的时间。

综合来看，100ms的耗时在中高端设备上属于可接受水平，中低端设备可能会略高，但都远低于Android的ANR阈值（500ms），所以这个数值是正常的，但完全可以通过优化进一步压缩。

二、具体优化方案（结合你的代码） #

1. 批量拉取JNI属性，减少跨边界调用次数 #

你当前的实现中，每个Item需要调用6次native方法，这是最大的性能瓶颈之一——单次JNI调用的开销虽小，但累积起来非常可观。

优化思路：在Native层新增一个批量返回Item属性的方法，一次性获取单个Item的所有属性，把JNI调用次数从每个Item6次降到1次。

代码修改示例：

首先在MainActivity的companion object中新增native方法：

external fun nativeGetItemProps(index: Int): ItemProps

然后在Native层实现这个方法，直接返回封装好的ItemProps对象（需要确保ItemProps是可跨JNI传递的类型，比如实现Parcelable，或者用C++构造后序列化传递）。

之后修改Adapter的loadProps方法：

private fun loadProps(index: Int): ItemProps {
    return MainActivity.nativeGetItemProps(index)
}

这一步通常能减少50%以上的JNI相关耗时。

2. 异步加载数据，避免阻塞主线程 #

你当前在主线程同步执行所有JNI数据加载，会直接拉长UI初始化的耗时，甚至导致启动时的轻微卡顿。建议把数据加载逻辑移到后台线程，完成后再回到主线程更新Adapter。

代码修改示例（用Coroutine实现）：

fun setInitialData(count: Int) {
    // 用IO调度器在后台加载数据
    CoroutineScope(Dispatchers.IO).launch {
        val newItems = mutableListOf<ItemProps>()
        for (i in 0 until count) {
            newItems.add(MainActivity.nativeGetItemProps(i))
        }
        // 回到主线程更新Adapter
        withContext(Dispatchers.Main) {
            items.clear()
            items.addAll(newItems)
            notifyItemRangeInserted(0, items.size)
        }
    }
}

这样修改后，主线程的UI初始化时间会瞬间缩短（不再包含JNI调用的耗时），用户能更快看到基础UI，数据加载的开销被转移到后台。

3. 优化ViewHolder与属性设置 #

• 复用通用属性：如果多个Item的部分属性（比如字体大小、背景色）相同，可以在Adapter中缓存这些值，避免重复设置；
• 用Style统一配置：把EditText的通用默认属性（比如默认字体、内边距）放到Style中，减少每个Item的动态属性设置次数；
• 避免过度初始化：EditText的部分属性（比如光标颜色、输入类型）如果不需要动态设置，就不要调用对应的set方法，减少View的布局计算开销。

4. 按需加载，而非一次性加载全部数据 #

如果Item数量远超屏幕可见范围（比如几百个），可以不用一次性加载所有Item的属性，而是只加载当前屏幕可见的Item属性，剩下的在onBindViewHolder时再动态获取。这样初始加载的JNI调用次数会大幅减少，把耗时分散到滚动过程中，而非集中在初始化阶段。

三、优化后的预期效果 #

通过上述优化，你可以把初始化耗时压缩到30-60ms左右，具体取决于设备性能和Item数量。即使保留部分JNI调用，主线程的阻塞时间也会被控制在极低水平，完全不会影响启动体验。

内容来源于stack exchange