Android TV应用Leanback ListRowPresenter滚动时ANR崩溃求助

我来帮你分析下这个Leanback ListRowPresenter导致的ANR问题，结合你提供的日志和描述，咱们一步步拆解：

问题场景回顾 #

开发Android TV应用时，使用Leanback组件的ListRowPresenter实现横向列表，左右滚动过程中应用偶尔出现ANR崩溃。你已经将核心业务逻辑放到子线程执行，UI层仅处理少量任务，但问题仍然存在。

崩溃日志分析 #

从你提供的Logcat日志来看，核心问题是Input dispatching timed out，也就是输入事件分发超时，因为主线程被阻塞无法及时处理按键滚动事件。关键的CPU使用数据显示：

CPU usage from 329ms to 835ms later (2018-05-27 09:54:56.834 to 2018-05-27 09:54:57.339):
99% 6764/: 99% user + 0% kernel
100% 6764/an.: 100% user + 0% kernel

这说明崩溃发生时，你的应用主线程几乎被占满，虽然业务逻辑在子线程，但UI层和Leanback组件相关的操作肯定存在隐性的耗时阻塞。

完整日志如下：

system_process E/ActivityManager: ANR in <package name> (<package name>.MainActivity) PID: 6764 Reason: Input dispatching timed out (Waiting to send key event because the focused window has not finished processing all of the input events that were previously delivered to it. Outbound queue length: 0. Wait queue length: 1.) Load: 0.9 / 0.39 / 0.18 CPU usage from 208977ms to 0ms ago (2018-05-27 09:51:27.527 to 2018-05-27 09:54:56.505): 0.4% 1306/surfaceflinger: 0.1% user + 0.3% kernel 0.3% 1611/system_server: 0.2% user + 0.1% kernel / faults: 6915 minor 0.2% 1311/audioserver: 0% user + 0.2% kernel / faults: 3 minor 0.1% 1327/adbd: 0% user + 0.1% kernel / faults: 3442 minor 0.1% 2215/com.estrongs.android.pop: 0% user + 0% kernel / faults: 1198 minor 1 major 0.1% 2405/com.google.android.gms: 0% user + 0% kernel / faults: 2389 minor 0% 2073/com.google.android.gms.persistent: 0% user + 0% kernel / faults: 344 minor 0% 1812/com.android.systemui: 0% user + 0% kernel / faults: 171 minor 0% 2121/com.google.android.leanbacklauncher: 0% user + 0% kernel / faults: 851 minor 0% 8/rcu_preempt: 0% user + 0% kernel 0% 1255/logd: 0% user + 0% kernel / faults: 19 minor 0% 2255/com.android.defcontainer: 0% user + 0% kernel / faults: 248 minor 0% 1253/jbd2/vdc-8: 0% user + 0% kernel 0% 6289/logcat: 0% user + 0% kernel 0% 7/migration/0: 0% user + 0% kernel 0% 12/ksoftirqd/1: 0% user + 0% kernel 0% 682/kworker/u4:2: 0% user + 0% kernel 0% 1247/kworker/0:1H: 0% user + 0% kernel 0% 1302/healthd: 0% user + 0% kernel 0% 1305/servicemanager: 0% user + 0% kernel 0% 1322/netd: 0% user + 0% kernel / faults: 217 minor 0% 1828/sdcard: 0% user + 0% kernel 0% 2153/com.google.android.leanbacklauncher.recommendations: 0% user + 0% kernel / faults: 24 minor 0% 2551/.esfm: 0% user + 0% kernel / faults: 7 minor 0% 6292/kworker/1:1: 0% user + 0% kernel +0% 6764/<package name>: 0% user + 0% kernel 34% TOTAL: 33% user + 1.1% kernel + 0% iowait + 0.1% softirq CPU usage from 329ms to 835ms later (2018-05-27 09:54:56.834 to 2018-05-27 09:54:57.339): 99% 6764/<package name>: 99% user + 0% kernel 100% 6764/an.<app name>: 100% user + 0% kernel 1.9% 1611/system_server: 0% user + 1.9% kernel 51% TOTAL: 51% user + 0% kernel

排查方向与解决方案 #

结合Leanback组件的特性，给你几个具体的排查和优化点：

• 检查自定义ListRowPresenter的实现：如果你重写了onBindRowViewHolder、onUnbindRowViewHolder或者视图回收相关方法，仔细检查这些方法内是否有耗时操作——比如同步读取本地文件、复杂的视图属性计算、Bitmap同步解码等。这些操作单次执行可能很快，但滚动时会被频繁调用，累积起来就会阻塞主线程。
• 优化数据绑定逻辑：即使业务逻辑在子线程，数据回调到主线程后如果做了复杂的视图初始化或数据解析，也会影响主线程。建议：
  • 提前在子线程完成数据的预处理（比如字符串格式化、图片URL转Bitmap的异步处理）
  • 使用Leanback提供的异步工具或Jetpack Coroutine来处理UI层的异步绑定操作
• 验证视图复用机制：确保你正确使用了ViewHolder复用，没有在滚动时重复创建View实例。另外，检查是否有自定义的动画或过渡效果，Leanback的默认动画已经做了优化，自定义动画如果处理不当会增加主线程负担。
• 排查隐性主线程耗时操作：比如同步的SharedPreferences编辑提交、主线程中执行的数据库查询、甚至是频繁的Log输出（大量日志也会占用CPU资源）。
• 使用CPU Profiler精准定位：这是最有效的方式——打开Android Studio的CPU Profiler，在滚动列表时录制主线程的调用栈，找到占用CPU时间最高的方法，直接定位阻塞点。

内容的提问来源于stack exchange，提问作者Morteza Jalambadani