一款应用ANR的分析思路总结

最新推荐文章于 2024-05-06 20:27:05 发布
最新推荐文章于 2024-05-06 20:27:05 发布
阅读量1.7k 收藏 1
点赞数 1
CC 4.0 BY-SA版权
分类专栏： android应用ANR分析。 文章标签： ANR分析 arn分析
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/qq_28852011/article/details/72154772
本文通过分析WhatsApp在大量输入表情符号时出现的应用无响应(ANR)现象，详细介绍了从ANR日志、事件日志及系统日志中查找问题根源的方法，并提供了具体的堆栈跟踪分析。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >

案例：whatsapp输入框内一直输入表情符号导致ANR
1、在misc\anr文件中找的arn堆栈log信息
suspend all histogram: Sum: 180.110ms 99% C.I. 20.680us-8069.119us Avg: 874.320us Max: 140167us
DALVIK THREADS (69):
"main" prio=5 tid=1 Runnable
  | group="main" sCount=0 dsCount=0 obj=0x73cfa448 self=0xb7660290
  | sysTid=9653 nice=0 cgrp=default sched=0/0 handle=0xb6f2fc00
  | state=R schedstat=( 0 0 0 ) utm=9323 stm=358 core=3 HZ=100
  | stack=0xbe427000-0xbe429000 stackSize=8MB
  | held mutexes= "mutator lock"(shared held)
  at android.text.TextUtils.lastIndexOf(TextUtils.java:181)
  at android.text.TextUtils.lastIndexOf(TextUtils.java:154)
  at android.text.DynamicLayout.reflow(DynamicLayout.java:202)
  at android.text.DynamicLayout.-wrap0(DynamicLayout.java:-1)
  at android.text.DynamicLayout$ChangeWatcher.reflow(DynamicLayout.java:662)
  at android.text.DynamicLayout$ChangeWatcher.onSpanAdded(DynamicLayout.java:681)
  at android.text.SpannableStringBuilder.sendSpanAdded(SpannableStringBuilder.java:1053)
  at android.text.SpannableStringBuilder.setSpan(SpannableStringBuilder.java:759)
  at android.text.SpannableStringBuilder.setSpan(SpannableStringBuilder.java:658)
  at com.whatsapp.f.b.a(EmojiFormatter.java:303)
  at com.whatsapp.util.ba.a(StringUtils.java:151)
  at com.whatsapp.Conversation$30.afterTextChanged(Conversation.java:747)
  at android.widget.TextView.sendAfterTextChanged(TextView.java:8003)
  at android.widget.TextView$ChangeWatcher.afterTextChanged(TextView.java:10166)
  at android.text.SpannableStringBuilder.sendAfterTextChanged(SpannableStringBuilder.java:1043)
  at android.text.SpannableStringBuilder.replace(SpannableStringBuilder.java:560)
  at android.text.SpannableStringBuilder.replace(SpannableStringBuilder.java:492)
  at android.text.SpannableStringBuilder.replace(SpannableStringBuilder.java:491)
  at com.whatsapp.Conversation$20.a(Conversation.java:3081)
  at com.whatsapp.EmojiPicker.a(EmojiPicker.java:603)
  at com.whatsapp.nl.onClick(unavailable:1484)
  at android.view.View.performClick(View.java:5209)
  at android.view.View$PerformClick.run(View.java:21166)
  at android.os.Handler.handleCallback(Handler.java:739)
  at android.os.Handler.dispatchMessage(Handler.java:95)
  at android.os.Looper.loop(Looper.java:148)
  at android.app.ActivityThread.main(ActivityThread.java:5452)
  at java.lang.reflect.Method.invoke!(Native method)
  at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:781)
  at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:671)
其中tid=1表示主线程提示信息是Runnable，表示主线程没有阻塞
其中sysTid=9653是此应用的进程ID.
红色部分为应用导致ANR具体位置。
2、events.log中搜索9653或者am_anr找到ANR原因
05-10 11:28:18.454 1384 1448 I am_anr : [0,9653,com.whatsapp,954760772,Input dispatching timed out
3、system.log中查看CPU使用情况(关键字CUP usage from )
05-10 11:28:24.800 1384 1448 E ActivityManager: ANR in com.whatsapp (com.whatsapp/.Conversation)
05-10 11:28:24.800 1384 1448 E ActivityManager: PID: 9653
05-10 11:28:24.800 1384 1448 E ActivityManager: Reason: Input dispatching timed out (Waiting to send non-key event because the touched window has not finished processing certain input events that were delivered to it over 500.0ms ago. Wait queue length: 2. Wait queue head age: 8027.7ms.)
05-10 11:28:24.800 1384 1448 E ActivityManager: Load: 6.74 / 6.39 / 5.29
CPU usage from 5586ms to 6137ms later:
05-10 11:28:24.800 1384 1448 E ActivityManager: 99% 9653/com.whatsapp: 99% user + 0% kernel / faults: 32 minor
05-10 11:28:24.800 1384 1448 E ActivityManager: 99% 9653/com.whatsapp: 99% user + 0% kernel
05-10 11:28:24.800 1384 1448 E ActivityManager: 14% 9308/com.duapps.recorder: 12% user + 1.8% kernel
05-10 11:28:24.800 1384 1448 E ActivityManager: 5.4% 9640/gle.aac.encoder: 5.4% user + 0% kernel
05-10 11:28:24.800 1384 1448 E ActivityManager: 3.6% 9639/MediaCodec_loop: 3.6% user + 0% kernel
05-10 11:28:24.800 1384 1448 E ActivityManager: 1.8% 9635/MediaCodec_loop: 0% user + 1.8% kernel
05-10 11:28:24.800 1384 1448 E ActivityManager: 1.8% 9643/ScreenCaptureTa: 1.8% user + 0% kernel
05-10 11:28:24.800 1384 1448 E ActivityManager: 1.8% 9644/audioencode out: 1.8% user + 0% kernel
05-10 11:28:24.800 1384 1448 E ActivityManager: 1.8% 9645/audioencode in : 1.8% user + 0% kernel
05-10 11:28:24.800 1384 1448 E ActivityManager: 1.8% 9650/MPEG4Writer: 0% user + 1.8% kernel
05-10 11:28:24.800 1384 1448 E ActivityManager: 12% 230/mediaserver: 12% user + 0% kernel
05-10 11:28:24.800 1384 1448 E ActivityManager: 7.2% 9619/AudioIn_20: 7.2% user + 0% kernel
05-10 11:28:24.800 1384 1448 E ActivityManager: 1.8% 1507/AudioOut_2: 0% user + 1.8% kernel
05-10 11:28:24.800 1384 1448 E ActivityManager: 1.8% 9637/rd.h264.encoder: 1.8% user + 0% kernel
05-10 11:28:24.800 1384 1448 E ActivityManager: 9.1% 1384/system_server: 1.8% user + 7.2% kernel
05-10 11:28:24.800 1384 1448 E ActivityManager: 7.2% 1448/ActivityManager: 0% user + 7.2% kernel
05-10 11:28:24.800 1384 1448 E ActivityManager: 1.8% 2296/Binder_C: 0% user + 1.8% kernel
05-10 11:28:24.800 1384 1448 E ActivityManager: 1.8% 4627/Binder_F: 1.8% user + 0% kernel
05-10 11:28:24.800 1384 1448 E ActivityManager: 7.2% 235/memsicp: 0% user + 7.2% kernel
05-10 11:28:24.800 1384 1448 E ActivityManager: 5.4% 85/focal-wait-queu: 0% user + 5.4% kernel
05-10 11:28:24.800 1384 1448 E ActivityManager: 1.1% 86/sensor_report_e: 0% user + 1.1% kernel
05-10 11:28:24.800 1384 1448 E ActivityManager: 1.1% 88/watchdog_feeder: 0% user + 1.1% kernel
05-10 11:28:24.800 1384 1448 E ActivityManager: 1.8% 174/logd: 0% user + 1.8% kernel
05-10 11:28:24.800 1384 1448 E ActivityManager: 1.8% 8159/logd.reader.per: 0% user + 1.8% kernel
05-10 11:28:24.800 1384 1448 E ActivityManager: 1.2% 205/servicemanager: 0% user + 1.2% kernel
05-10 11:28:24.800 1384 1448 E ActivityManager: 1.4% 1624/com.android.systemui: 1.4% user + 0% kernel
05-10 11:28:24.800 1384 1448 E ActivityManager: 1.4% 2186/sdcard: 0% user + 1.4% kernel
05-10 11:28:24.800 1384 1448 E ActivityManager: 1.5% 8034/slog: 1.5% user + 0% kernel
05-10 11:28:24.800 1384 1448 E ActivityManager: 1.5% 8115/slog: 1.5% user + 0% kernel
05-10 11:28:24.800 1384 1448 E ActivityManager: 39% TOTAL: 33% user + 5.5% kernel
红色部分显示应用的耗时操作导致cpu使率用很高。
4、查看的log分析文档中表示要查看trach.txt中的堆栈信息（此文件信息和misc\anr中的堆栈信息log相同）
第一步，先pull出/data/anr/traces.txt文件。
第二步，查看app被杀死时的进程id，你这里我看是7889。
第三步，查看traces.txt里关于该进程id的信息。
5、我试着反编译whatsapp这个应用看看具体的代码，但是他的加密做的非常好，看不到log中打印类的具体内容。

ANR实战案例3 - 应用在部分低端机ANR优化案例
Android百晓生的博客
05-15 903
相对于中高端机，低端机上出现ANR的频率更高，且更为棘手，笔者总结了长期实际开发者低端机ANR的解决案例，可参考文中解决方案。
Android 卡顿与 ANR 的分析实践
weixin_47388410的博客
09-12 1902
针对客户端开发的“终生之敌”——卡顿和 ANR 问题，本文将深入剖析系统消息队列机制和常见的卡顿与 ANR 成因，并介绍监控工具 **LooperMonitor** 如何借助多维分析平台 MDAP 的智能聚合和可视化看板，为业务方提供更精准、易用的分析能力。
记一次普通的ANR
bigbigmajia的博客
02-08 1025
项目场景： 起因仍然是测试在测试的时候突然发现某个页面进去之后就会点不动，而且只在华为机型上出现，别的机型并没有，于是就去看这个问题。 首先发生场景是在MainActivity的几个Fragment中的一个Fragment，切到这个Fragment过一会就会点不动，发生ANR。这个Fragment中就两个Viewpager，几个Recyclerview，唯一会动的就一个LottieAnimationView和一个会自动滑动的Viewpager，看上去属实平平无奇不应该发生什么问题。 原因分析： 当然出现了A
Android ANR分析-笔记
且听真言
10-17 4517
ANR:Application Not Responding，即应用无响应。
ANR分析思路简析
feelinghappy的专栏
08-29 794
案例：whatsapp输入框内一直输入表情符号导致ANR 1、在misc\anr文件中找的arn堆栈log信息 suspend all histogram: Sum: 180.110ms 99% C.I. 20.680us-8069.119us Avg: 874.320us Max: 140167us DALVIK THREADS (69): "main" prio=5 tid=1 Runnabl...
Android Native层异常分析
SuperLi
03-22 3763
Android Native报错定位 今天调试Android stagefright模块，修改MediaCodec.cpp文件时，一不小心在代码里写了个空指针进去。 于是得到了下面这个报错日志： --------- beginning of crash libc : Fatal signal 11 (SIGSEGV), code 1, fault addr 0x0 in tid 5104 (...
MediaCodec_loop 崩溃
jacke121的专栏
05-10 3778
MediaCodec_loop 崩溃
Android ANR问题总结
热门推荐
内核工匠
08-27 1万+
一、概述ANR（Application Not Responding）， 如果 Android 应用的界面线程处于阻塞状态的时间过长，会触发“应用无响应”(ANR) 错误。如果应用位于前台...
ANR 优化实践系列2 监控工具与分析思路
liuwg1226的专栏
07-04 896
概述 在前文，我们对 ANR 优化实践系列1 设计原理及影响因素 进行了介绍，并对影响 ANR 的不同场景进行归类。但是依靠现有的系统日志，不足以完成复杂场景的问题归因，而且有些信息从应用侧无法获取，这就导致很多线上问题更加棘手；因此我们在应用侧探索了新的监控能力，以弥补信息获取不足的短板。同时对日常分析过程中用到日志信息和分析思路进行总结，以帮忙大家更好的掌握分析技巧，下面我们就来看看相关实现。 Raster 监控工具 俗话说：“工欲善其事，必先利其器”，日常分析 ANR 问题也是如此，一个好的监控工具不
Android ANR触发机制及日志分析
zenmela2011的专栏
01-28 3433
1.ANR Application Not Responding，即应用程序未响应。Android系统要求一些事件在一定时间范围内完成，如果超过预定时间未得到有效响应或响应时间过长，就会造成ANR。 Android中有4种ANR发生场景： ①点击事件(按键和触摸事件）：点击事件在5s内未被处理就会产生ANR，日志描述为Input event dispatching timed out。 ②服务Service： 前台Service20s内、后台Service 200s内未完成启动就会产生ANR，日志描
ANR分析
全能小码农
12-05 789
http://blog.youkuaiyun.com/dadoneo/article/details/8270107
Android ANR 总结
easonguolong的博客
01-18 1446
解决ANR一直是Android 开发者需要掌握的重要技巧，一般从三个方面着手。开发阶段：通过工具检查各个方法的耗时，卡顿情况，发现一处修改一处。线上阶段：这个阶段主要依靠监控工具发现ANR并上报，比如matrix。分析阶段：如果线上用户发生ANR，并且你获取了一份日志，这就涉及了本文要分享的内容——ANR日志分析技巧。
深入理解 MediaCodec 硬解码初始化
xiaowang_lj的博客
07-03 1266
方法，实际由 MediaCodecList::getCodecInfo(…实际响应方为 MediaPlayerService::getCodecList()，这个函数内部调用了 MediaCodecList::getLocalInstance()，又绕了回去（因为调用进程和响应进程是不同的，虽然都使用了同一个类的中的函数）。RTLD_NOW： 需要在 dlopen 返回前，解析出所有未定义符号，如果解析不出来，在 dlopen 会返回 NULL，错误为：undefined symbol: xxxx…
java.lang.OutOfMemoryError: pthread_create (1040KB stack) failed: Try again
09-11 3855
1. java.lang.OutOfMemoryError: pthread_create (1040KB stack) failed: Try again 09-09 02:00:19.416 10109 13806 13806 E AndroidRuntime: FATAL EXCEPTION: main 09-09 02:00:19.416 10109 13806 13806 E AndroidRuntime: Process: com.sec.android.app.camera,...
Traces文件分析ANR问题
baidu_32472003的博客
09-20 3415
Traces文件分析ANR问题 我们在开发调试过程中遇到ANR问题大多是可以通过DDMS方法来分析问题原因的，但是所有的ANR问题不一定会在开发阶段出现，如果在测试或者发版之后出现了ANR问题，那么就需要通过traces文件来分析。根据之前的分析我们知道，traces文件位于/data/anr目录下，即便是没有root的手机也是可以通过adb命令将该文件pull出来，一个traces文件中包含了...
Exoplayer(10)-MediaCodec配置和初始化过程
weixin_42448721的博客
12-21 947
在Exoplayer(9)-视频渲染器工作流程 我们了解到视频渲染器在初始化时会配置和初始化MediaCodec,本篇内容主要梳理MediaCodec 配置获取和MediaCodec初始化过程。
ANR异常分析
kaf_ka的博客
04-22 212
ANR分析：通过log和trace文件 pull出/data/anr/traces.txt文件
Android13 MediaCodec创建流程分析
liuning1985622的博客
05-06 1057
static MediaCodec createDecoderByType(String type)：实例化支持给定MIME类型(如"video/avc")的输入数据的首选解码器。static MediaCodec createEncoderByType(String type)：实例化支持给定MIME类型(如"video/avc")的输出数据的首选编码器。
深入探索 Android 内存优化（炼狱级别）
idaretobe的专栏
03-09 3686
前言 成为一名优秀的Android开发，需要一份完备的知识体系，在这里，让我们一起成长为自己所想的那样~。 本篇是 Android 内存优化的进阶篇，难度可以说达到了炼狱级别，建议对内存优化不是非常熟悉的仔细看看前篇文章：Android性能优化之内存优化，其中详细分析了以下几大模块： 1）、Android的内存管理机制 2）、优化内存的意义 3）、避免内存泄漏 4）、优化内存空间 5）、图片管理模块的设计与实现 如果你对以上基础内容都比较了解了，那么我们便开始 Android 内...
android15 ANR定屏
最新发布
07-19
<think>我们正在处理关于Android 15中ANR导致界面定屏的问题。根据用户查询，需要提供解决方案或调试方法。结合之前的引用内容，我们可以总结出ANR的一般分析方法和解决思路，并针对Android 15进行说明（注意：Android 15可能引入新的特性或变化，但核心ANR分析机制类似）。 核心思路： 1. ANR产生的原因：主线程被阻塞超过一定时间（如输入事件5秒，广播10秒等）。 2. 分析步骤：收集日志（traces.txt, logcat），定位主线程堆栈，分析阻塞原因。 由于Android 15是最新版本，可能提供更先进的工具（如新的分析工具或API），但基本方法不变。我们可以从以下几个方面展开： 步骤1：确认ANR发生 - 查看系统日志（logcat）中是否有ANR记录，搜索关键字“ANR in”或“ActivityManager: ANR”。 - 检查/data/anr/目录下的traces.txt文件（需要root权限）或者使用adb bugreport命令获取完整的报告。 步骤2：分析ANR原因 - 在日志中找到发生ANR的进程和线程（通常是主线程），查看其堆栈信息。 - 分析堆栈中调用的方法，找出耗时操作（如IO操作、网络请求、数据库操作、锁竞争等）。 步骤3：解决策略 - 将耗时操作移出主线程，使用工作线程（如Thread, HandlerThread, AsyncTask, ExecutorService等）或协程（Kotlin协程）执行。 - 优化主线程中的操作，避免复杂计算和大量循环。 - 检查是否有死锁或锁竞争，特别是主线程中等待子线程锁的情况。 - 使用StrictMode帮助检测主线程中的磁盘读写和网络访问。 步骤4：使用Android 15可能的新特性或工具 - 虽然Android 15的具体特性尚未完全公布（截至2023年），但可以关注Android Studio的最新工具（如Profiler）和系统提供的ANR分析工具（如Android Vitals）的更新。 - Android 15可能提供更详细的ANR报告，例如包含CPU使用率、锁信息等。 步骤5：测试验证 - 使用模拟ANR场景的工具（如adb shell am hang）进行测试。 - 使用性能分析工具（如Systrace）监控应用性能。 根据引用[3]中的经验，不能仅凭堆栈信息完全确定问题，因为可能存在堆栈漂移。因此，需要结合代码逻辑和日志进行综合判断。 下面我们将详细展开这些步骤，并提供一些实用的命令和代码示例。 详细步骤： 1. 获取ANR日志 - 使用adb命令抓取日志： ```bash adb logcat -d > logcat.txt # 获取当前日志 adb bugreport > bugreport.zip # 获取完整的bug报告（包括traces.txt等） ``` 注意：在Android 15中，获取ANR日志的方式可能没有变化，但注意权限问题（如需要用户授权或开启开发者选项）。 2. 分析日志 - 在logcat中搜索ANR关键字，找到发生ANR的包名和原因。 - 在bugreport中，查看/data/anr/目录下的文件，特别是traces.txt，找到主线程的堆栈。 3. 代码检查 - 检查主线程中是否有耗时操作，例如： - 文件读写（特别是大文件） - 网络请求（必须放在后台线程） - 数据库操作（特别是大量数据操作） - 复杂计算（如图像处理、加密解密等） - 使用StrictMode检测主线程中的磁盘和网络操作（在Application或Activity的onCreate中设置）： ```java if (BuildConfig.DEBUG) { StrictMode.setThreadPolicy(new StrictMode.ThreadPolicy.Builder() .detectDiskReads() .detectDiskWrites() .detectNetwork() .penaltyLog() .build()); } ``` 4. 使用性能分析工具 - Android Studio Profiler：可以监控CPU、内存等，查看主线程的耗时方法。 - Systrace：系统级跟踪工具，可以查看线程状态（如运行、休眠、等待锁等）： ```bash python systrace.py -o mytrace.html sched gfx view wm am app ``` 然后使用浏览器打开mytrace.html，搜索主线程（通常名为包名+主线程名），查看ANR时间段内的状态。 5. 解决常见问题 - 如果发现主线程中有网络请求，应使用后台线程或协程： ```kotlin // Kotlin协程示例 lifecycleScope.launch(Dispatchers.IO) { // 网络请求 val result = apiService.getData() withContext(Dispatchers.Main) { // 更新UI } } ``` - 如果主线程中有数据库操作，考虑使用Room数据库并配合协程或LiveData进行异步查询。 6. 避免ANR的最佳实践 - 使用IntentService处理长时间后台任务。 - 对于广播接收器，避免在onReceive()中执行耗时操作，使用goAsync()或启动Service处理。 - 优化布局，避免过度绘制和复杂的布局嵌套。 7. Android 15可能的新特性 - 关注Android 15的开发者文档，看是否有新的ANR分析工具或API。 - 使用Android Vitals（在Google Play控制台）分析ANR问题。 注意：由于Android 15尚未广泛使用（截至2023年），上述方法基于之前版本的通用方法。当Android 15发布后，应查阅官方文档以获取最新信息。 相关问题： 1. 如何在没有root权限的情况下获取ANR日志？ 2. 如何使用Systrace分析ANR问题？ 3. 在Android 15中，ANR的超时时间是否有变化？ 请根据上述步骤尝试解决ANR问题，如果遇到具体问题，可进一步分析。</think>### Android 15 ANR导致界面定屏的解决方法 当Android 15应用发生ANR（Application Not Responding）导致界面定屏时，可通过以下系统化方法诊断和解决： --- ### **1. 确认ANR触发条件** [^1] - **输入事件超时**：主线程5秒内未响应触摸/按键事件 - **广播超时**：BroadcastReceiver 10秒内未完成执行 - **服务超时**：Service前台20秒/后台200秒未完成启动 ```java // 示例：主线程模拟阻塞（实际需避免） public void onClick(View v) { SystemClock.sleep(6000); // 超过5秒触发ANR } ``` --- ### **2. 关键日志分析** #### (1) 获取ANR日志 ```bash adb pull /data/anr/traces.txt # 直接获取ANR堆栈 adb bugreport # 完整系统报告（含CPU/线程状态） ``` #### (2) 分析重点（logcat搜索）[^2] ```log E/ActivityManager: ANR in com.example.app (主线程堆栈) W/Binder: Blocked thread waiting on lock (锁竞争提示) I/Choreographer: Skipped 60 frames (UI渲染阻塞) ``` --- ### **3. 主线程阻塞定位** #### 典型场景及解决方案： | **阻塞类型** | **解决方案** | **代码示例** | |-------------------|---------------------------------------------|---------------------------------------------| | **文件/网络IO** | 迁移到WorkManager或协程 | `Dispatchers.IO`执行耗时操作 | | **复杂计算** | 使用`ThreadPoolExecutor`异步处理 | `executor.execute(() -> heavyCalculation())`| | **跨进程死锁** | 检查`Binder`调用超时（添加超时机制） | `binderProxy.linkToDeath()` | | **数据库锁竞争** | 优化Room查询/使用异步查询API | `@Query` + `LiveData` | --- ### **4. Android 15新特性适配** #### (1) **后台限制增强** ```xml <!-- AndroidManifest.xml声明前台服务类型 --> <service android:name=".MyService" android:foregroundServiceType="location|camera" /> ``` #### (2) **ANR诊断工具升级** - **`StrictMode`增强检测**： ```java StrictMode.setVmPolicy(new VmPolicy.Builder() .detectLeakedClosableObjects() .penaltyLog() .build()); ``` - **`ANRWatchDog`库**：实时监控主线程阻塞 ```gradle implementation 'com.github.anrwatchdog:anrwatchdog:1.4.0' ``` --- ### **5. 高级调试技巧** #### (1) Systrace性能分析 ```bash python systrace.py --app=com.example.app sched gfx view wm am ``` ![Systrace示例](https://developer.android.com/static/images/tools/performance/systrace-cpu-usage.png) _主线程阻塞段显示红色警告_ #### (2) 模拟ANR测试 ```bash adb shell am hang --allow-restart # 强制触发ANR场景 ``` --- ### **6. 预防机制** 1. **主线程监控**： ```java Handler handler = new Handler(Looper.getMainLooper()); handler.postDelayed(() -> { throw new RuntimeException("MainThread blocked!"); }, 5000); // 5秒阈值 ``` 2. **异步初始化**： ```kotlin class MyApp : Application() { override fun onCreate() { super.onCreate() CoroutineScope(Dispatchers.Default).launch { initSDK() // 异步初始化 } } } ``` > **关键提示**：Android 15强化了[后台服务限制](https://developer.android.com/about/versions/15/behavior-changes-15)，ANR分析需结合`adb shell dumpsys activity processes`检查进程状态[^3]。 ---
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值