遇到这种ANR（应用无响应）崩溃但Logcat被冗余日志刷屏、看不到核心报错的情况确实头疼，我来给你一步步梳理解决思路：

一、先定位ANR的真实原因 #

ANR发生时，系统其实会生成专门的日志文件，这比被刷屏的Logcat靠谱多了：

• 导出ANR专属日志：通过ADB命令拉取traces.txt文件，这里面会详细记录ANR发生时所有线程的调用栈，是定位问题的关键：

  adb pull /data/anr/traces.txt
  

• 过滤Logcat冗余日志：先把刷屏的TransactionService日志过滤掉，只关注你的应用相关的Error级别日志，在终端可以用：

  adb logcat *:E | grep "你的应用包名"
  

  或者在Android Studio的Logcat面板里，直接设置包名过滤，同时把日志级别调到Error，这样就能避开无关日志的干扰。

二、处理TransactionService重复启动的问题 #

从你给出的重复日志来看，MMS的TransactionService一直在反复启动，这很可能是拖垮应用导致ANR的诱因：

• 检查应用内的MMS相关逻辑：看看你的应用有没有注册短信/彩信相关的广播接收器，或者有没有触发MMS发送、接收的操作，是不是这些逻辑导致服务被反复唤起。
• 排查Service启动模式：日志里的case 2对应START_STICKY模式，这种模式下服务被杀死后会自动重启，如果服务本身存在异常（比如启动后立刻崩溃），就会陷入无限重启循环，疯狂占用系统资源，最终引发ANR。如果是你自定义的类似服务，赶紧检查onStartCommand的返回值和服务内部逻辑。
• 排查系统MMS应用：如果不是你的应用触发的，那可能是系统自带的MMS应用出问题了，试试清除MMS应用的缓存和数据，或者重启设备，看能不能停止这些重复日志。

三、额外排查方向 #

• 主线程阻塞检查：ANR最常见的原因就是主线程做了耗时操作（比如同步网络请求、大数据库读写），检查你的应用主线程代码，把这些操作移到子线程或者用异步任务处理。
• 内存泄漏检测：长期内存泄漏会耗尽系统资源，最终也会引发ANR，用Android Studio的Profiler工具检测内存使用情况，定位泄漏点及时修复。

内容的提问来源于stack exchange，提问作者Prason Ghimire