SWT 重启案例分析（一）

最新推荐文章于 2024-05-17 07:57:54 发布
原创 最新推荐文章于 2024-05-17 07:57:54 发布 · 562 阅读 · 1 ·
CC 4.0 BY-SA版权
和你一起终身学习，这里是程序员Android

 

极力推荐文章：欢迎收藏
Android 干货分享 

 

本篇文章主要介绍 Android 开发中的部分知识点，通过阅读本篇文章，您将收获以下内容:

1.MTK AEE Log分析工具
2.AEE Log分析流程
3.system_server 卡死案例分析及解决

本文主要针对 Exception Type: system_server_watchdog , system_server卡死找出的分析以及解决方案。

一、MTK AEE Log分析工具

MTK AEE Log 获取方式：

关注微信公众号： 程序员Android
回复 aee 即可获取解析重启db log的工具。

二、AEE Log分析流程

1. 使用AEE 工具解析 dbg 文件。

使用解析db.fatal.02.SWT.dbg

AEE Log 解析出来的文件

2.分析解析出来的exp_main等文件

exp_main 文件会记录发生重启时候的 log 打印信息。

部分重启异常 Log信息如下：

$** *** *** *** *** *** *** *** Fatal *** *** *** *** *** *** *** **$
Build Info: 'alps-mp-o1.mp7:alps-mp-o1.mp7:mt6765:S01,ACE/AS0618/AS0618:8.1.0/O11019/1548123508:user/release-keys'
Flavor Info: 'None'
Exception Log Time:[Thu Mar 14 14:00:03 CST 2019] [38684.729626]

Exception Class: SWT
Exception Type: system_server_watchdog

Current Executing Process: 
system_server


Trigger time:[2019-03-14 14:00:03.711844] pid:1029

Backtrace: 
Process: system_server
Subject: Blocked in handler on ActivityManager (ActivityManager)
Build: ACE/AS0618/AS0618:8.1.0/O11019/1548123508:user/release-keys

**exp_main 文件解析 **
从开头的Log总体信息概览，我们可以看到 发生重启的时间、类型，触发重启的进程以及PID、系统Blocked 的地方。

结合exp_main以及 trace分析重启 Log
Log分析如下：

// 1.重启触发时间，以及PID 
Trigger time:[2019-03-14 14:00:03.711844] pid:1029
// 2.Blocked 的进程
Backtrace: 
Process: system_server
Subject: Blocked in handler on ActivityManager (ActivityManager)
// 3.根据PID 查看Trace信息
----- pid 1029 at 2019-03-14 13:59:58 -----
Cmd line: system_server

... ...
// 4.根据Backtrace 查看Blocked的信息
"ActivityManager" prio=5 tid=11 Blocked

... ...
// 5.tid=11 等待 tid=106的线程释放资源锁
  - waiting to lock <0x090691f3> (a android.util.ArrayMap) held by thread 106  
... ...

// 6.查看tid = 106 持锁情况
"backup" prio=5 tid=106 Waiting
... ... 

  at java.lang.Object.wait(Native method)
  - waiting on <0x06a44c62> (a com.android.server.am.ContentProviderRecord)
// 7.死锁卡住的地方
  at com.android.server.am.ActivityManagerService.getContentProviderImpl(ActivityManagerService.java:12127)
  - locked <0x06a44c62> (a com.android.server.am.ContentProviderRecord)
  
  ...  ...

"Binder:1029_8" prio=5 tid=107 Blocked
// 8.log中  tid=107 被 106 Blocked 进一步问题的加重
  at com.android.server.notification.RankingHelper.getRecord(RankingHelper.java:258)
  - waiting to lock <0x090691f3> (a android.util.ArrayMap) held by thread 106
  
$** *** *** *** *** *** *** *** Fatal *** *** *** *** *** *** *** **$

Log 分析大致过程截图

完整 log 请在公众号上获取

3.system_server 卡死案例分析及解决

通过 Log 找到卡死原因后，解决此问题。
需要修改ActivityManagerService类。

代码路径如下：alps/frameworks/base/services/core/java/com/android/server/am/ActivityManagerService.java

解决思路：
避免 provider 长时间持锁触发MTK 60s 的SWT 重启机制，设置超时时间，超过时间就要释放资源锁，避免发生此问题。

diff 修改方案如下：

--- a/[alps/frameworks/base/services/core/java/com/android/server/am/ActivityManagerService.java](http://192.168.11.104/gitweb/?p=alps-mp-o1.mp1-V1.git;a=blob;f=alps/frameworks/base/services/core/java/com/android/server/am/ActivityManagerService.java;h=d5e2e1411f3698a829e997d402c7482ec277fa8c;hb=d5e2e1411f3698a829e997d402c7482ec277fa8c)

+++ b/[alps/frameworks/base/services/core/java/com/android/server/am/ActivityManagerService.java](http://192.168.11.104/gitweb/?p=alps-mp-o1.mp1-V1.git;a=blob;f=alps/frameworks/base/services/core/java/com/android/server/am/ActivityManagerService.java;h=03208f78a2bf3167b4f0790019326e3939cc5444;hb=03208f78a2bf3167b4f0790019326e3939cc5444)

@@ [-545,7](http://192.168.11.104/gitweb/?p=alps-mp-o1.mp1-V1.git;a=blob;f=alps/frameworks/base/services/core/java/com/android/server/am/ActivityManagerService.java;h=d5e2e1411f3698a829e997d402c7482ec277fa8c;hb=d5e2e1411f3698a829e997d402c7482ec277fa8c#l545) [+545,9](http://192.168.11.104/gitweb/?p=alps-mp-o1.mp1-V1.git;a=blob;f=alps/frameworks/base/services/core/java/com/android/server/am/ActivityManagerService.java;h=03208f78a2bf3167b4f0790019326e3939cc5444;hb=03208f78a2bf3167b4f0790019326e3939cc5444#l545) @@ public class ActivityManagerService extends IActivityManager.Stub

     // How long we wait for an attached process to publish its content providers

     // before we decide it must be hung.

     static final int CONTENT_PROVIDER_PUBLISH_TIMEOUT = 10*1000;

-

+    // How long we wait for provider to be notify before we decide it may be hung.

+    static final int CONTENT_PROVIDER_WAIT_TIMEOUT = 20*1000;

+       

     // How long we wait for a launched process to attach to the activity manager

     // before we decide it's never going to come up for real, when the process was

     // started with a wrapper for instrumentation (such as Valgrind) because it

@@ [-1745,6](http://192.168.11.104/gitweb/?p=alps-mp-o1.mp1-V1.git;a=blob;f=alps/frameworks/base/services/core/java/com/android/server/am/ActivityManagerService.java;h=d5e2e1411f3698a829e997d402c7482ec277fa8c;hb=d5e2e1411f3698a829e997d402c7482ec277fa8c#l1745) [+1747,7](http://192.168.11.104/gitweb/?p=alps-mp-o1.mp1-V1.git;a=blob;f=alps/frameworks/base/services/core/java/com/android/server/am/ActivityManagerService.java;h=03208f78a2bf3167b4f0790019326e3939cc5444;hb=03208f78a2bf3167b4f0790019326e3939cc5444#l1747) @@ public class ActivityManagerService extends IActivityManager.Stub

     static final int PUSH_TEMP_WHITELIST_UI_MSG = 68;

     static final int SERVICE_FOREGROUND_CRASH_MSG = 69;

     static final int DISPATCH_OOM_ADJ_OBSERVER_MSG = 70;

+        static final int CONTENT_PROVIDER_WAIT_TIMEOUT_MSG = 71;

     static final int START_USER_SWITCH_FG_MSG = 712;

     static final int NOTIFY_VR_KEYGUARD_MSG = 74;

@@ [-2108,6](http://192.168.11.104/gitweb/?p=alps-mp-o1.mp1-V1.git;a=blob;f=alps/frameworks/base/services/core/java/com/android/server/am/ActivityManagerService.java;h=d5e2e1411f3698a829e997d402c7482ec277fa8c;hb=d5e2e1411f3698a829e997d402c7482ec277fa8c#l2108) [+2111,12](http://192.168.11.104/gitweb/?p=alps-mp-o1.mp1-V1.git;a=blob;f=alps/frameworks/base/services/core/java/com/android/server/am/ActivityManagerService.java;h=03208f78a2bf3167b4f0790019326e3939cc5444;hb=03208f78a2bf3167b4f0790019326e3939cc5444#l2111) @@ public class ActivityManagerService extends IActivityManager.Stub

                 synchronized (ActivityManagerService.this) {

                     mActivityStarter.doPendingActivityLaunchesLocked(true);

                 }

+            } break;

+                       case CONTENT_PROVIDER_WAIT_TIMEOUT_MSG: {

+                ContentProviderRecord cpr = (ContentProviderRecord)msg.obj;

+                synchronized (ActivityManagerService.this) {

+                    processContentProviderWaitTimedOutLocked(cpr);

+                }

             } break;

             case KILL_APPLICATION_MSG: {

                 synchronized (ActivityManagerService.this) {

@@ [-7029,7](http://192.168.11.104/gitweb/?p=alps-mp-o1.mp1-V1.git;a=blob;f=alps/frameworks/base/services/core/java/com/android/server/am/ActivityManagerService.java;h=d5e2e1411f3698a829e997d402c7482ec277fa8c;hb=d5e2e1411f3698a829e997d402c7482ec277fa8c#l7029) [+7038,31](http://192.168.11.104/gitweb/?p=alps-mp-o1.mp1-V1.git;a=blob;f=alps/frameworks/base/services/core/java/com/android/server/am/ActivityManagerService.java;h=03208f78a2bf3167b4f0790019326e3939cc5444;hb=03208f78a2bf3167b4f0790019326e3939cc5444#l7038) @@ public class ActivityManagerService extends IActivityManager.Stub

         cleanupAppInLaunchingProvidersLocked(app, true);

         removeProcessLocked(app, false, true, "timeout publishing content providers");

     }

+       

+    @GuardedBy("this")

+    private final void processContentProviderWaitTimedOutLocked(ContentProviderRecord cpr) {

+        try {

+            if (mLaunchingProviders.contains(cpr)) {

+                if (DEBUG_MU) Slog.v(TAG_MU,

+                    "Remove from mLaunchingProviders, " + cpr

+                    + " launchingApp=" + cpr.launchingApp);

+                mLaunchingProviders.remove(cpr);

+            }

+            if (DEBUG_MU) Slog.v(TAG_MU,

+                "RemoveMessages CONTENT_PROVIDER_WAIT_TIMEOUT_MSG, " + cpr

+                + " launchingApp=" + cpr.launchingApp);

+            mHandler.removeMessages(CONTENT_PROVIDER_WAIT_TIMEOUT_MSG, cpr);

+            synchronized (cpr) {

+                cpr.notifyAll();

+                cpr.launchingApp = null;

+            }

+        } catch (Exception e) {

+            if (DEBUG_MU) Slog.v(TAG_MU,

+                "processContentProviderWaitTimedOutLocked exception, " + e);

+        }

+    }

+       

     private final void processStartTimedOutLocked(ProcessRecord app) {

         final int pid = app.pid;

         boolean gone = false;

@@ [-12124,11](http://192.168.11.104/gitweb/?p=alps-mp-o1.mp1-V1.git;a=blob;f=alps/frameworks/base/services/core/java/com/android/server/am/ActivityManagerService.java;h=d5e2e1411f3698a829e997d402c7482ec277fa8c;hb=d5e2e1411f3698a829e997d402c7482ec277fa8c#l12124) [+12157,33](http://192.168.11.104/gitweb/?p=alps-mp-o1.mp1-V1.git;a=blob;f=alps/frameworks/base/services/core/java/com/android/server/am/ActivityManagerService.java;h=03208f78a2bf3167b4f0790019326e3939cc5444;hb=03208f78a2bf3167b4f0790019326e3939cc5444#l12157) @@ public class ActivityManagerService extends IActivityManager.Stub

                     if (conn != null) {

                         conn.waiting = true;

                     }

+                                       // add 20s wait timeout，avoid 

+                    if (!mHandler.hasMessages(CONTENT_PROVIDER_WAIT_TIMEOUT_MSG, cpr)) {

+                        if (DEBUG_MU) Slog.v(TAG_MU,

+                            "SendMessageDelayed CONTENT_PROVIDER_WAIT_TIMEOUT_MSG, " + cpr

+                            + " launchingApp=" + cpr.launchingApp);

+                        Message msg = mHandler.obtainMessage(CONTENT_PROVIDER_WAIT_TIMEOUT_MSG);

+                        msg.obj = cpr;

+                        mHandler.sendMessageDelayed(msg, CONTENT_PROVIDER_WAIT_TIMEOUT);

+                    } else {

+                        if (DEBUG_MU) Slog.v(TAG_MU,

+                            "There is another waiting to start provider " + cpr

+                            + " launchingApp=" + cpr.launchingApp

+                            + ", not send CONTENT_PROVIDER_WAIT_TIMEOUT_MSG again");

+                    }

+                                       

                     cpr.wait();

                 } catch (InterruptedException ex) {

                 } finally {

                     if (conn != null) {

                         conn.waiting = false;

+                    }

+                                       // remove wait time out message

+                    if (mHandler.hasMessages(CONTENT_PROVIDER_WAIT_TIMEOUT_MSG, cpr)) {

+                        if (DEBUG_MU) Slog.v(TAG_MU,

+                            "After wait removeMessages CONTENT_PROVIDER_WAIT_TIMEOUT_MSG, "

+                            + cpr + " launchingApp=" + cpr.launchingApp);

+                            mHandler.removeMessages(CONTENT_PROVIDER_WAIT_TIMEOUT_MSG, cpr);

                     }

                 }

             }

长按识别二维码，领福利

至此，本篇已结束，如有不对的地方，欢迎您的建议与指正。同时期待您的关注，感谢您的阅读，谢谢！

如有侵权，请联系小编，小编对此深感抱歉，届时小编会删除文章，立即停止侵权行为，请您多多包涵。

小礼物走一走，来简书关注我

Android 开机过程中发送自定义广播卡顿造成anr 导致死机案例分析
安卓兼职framework和app工程师的博客
10-01 453
在系统开发过程中，在开机的过程中，发现卡顿死机问题也是非常麻烦的，再开发过程中，发现在 发送自定义广播开启指示灯的过程中，由于广播超时造成anr导致watchdog死机重启的问题，接下来 分析相关问题，接下来解决这个问题
SWT 重启案例分析（六）
程序员Android
06-20 529
极力推荐文章：欢迎收藏Android 干货分享 本篇文章主要介绍Android开发中的部分知识点，通过阅读本篇文章，您将收获以下内容: 一、拷贝大文件，IO wait 高，导致SWT重启 二、高IO wait 导致重启的 解决方案 一、拷贝大文件，IO wait 高，导致SWT重启 1.通过AEE抓取的log 部分Log如下： Aee lo...
MTK平台的SWT异常的简单总结（2）——SWT原理和分析
Flying snow
06-05 2312
Android user/userdebug版本因受Security限制，导致在M版本之后打开mtklogger也只能抓到fatal db，不能抓普通的ANR db，O版本开始默认不会抓取第三方APP的ANR db。当SWT的两次有效trace打印的call stack完全一样时，才认为是block issue，重点从call stack来入手分析，常规分析流程如上图。SWT —— （swt_time – swt_timeout – 10s）~ （swt_time + 10s），之间的两次trace。
MTK system_server 卡死导致手机重启案例分析
程序员Android
07-30 2220
和你一起终身学习，这里是程序员Android经典好文推荐，通过阅读本文，您将收获以下知识点:一、MTK AEE Log分析工具二、AEE Log分析流程三、system_server 卡死案例分析及解决本文主要针对Exception Type: system_server_watchdog,system_server卡死找出的分析以及解决方案。一、MTK AEE Log分析工具MTK AEE...
手机重启案例分析
程序员Android
05-17 583
和你一起终身学习，这里是程序员Android经典好文推荐，通过阅读本文，您将收获以下知识点:一、MTK AEE Log分析工具二、AEE Log分析流程三、system_server 卡死案例分析及解决本文主要针对Exception Type: system_server_watchdog,system_server卡死找出的分析以及解决方案。一、MTK AEE Log分析工具MTK AEE...
MTK平台-老化版本开启aee日志
z1804362542的博客
02-26 999
老化版本开启aee日志，aee dump
SWT 重启案例分析（五）
程序员Android
06-20 370
极力推荐文章：欢迎收藏Android 干货分享 本篇文章主要介绍Android开发中的部分知识点，通过阅读本篇文章，您将收获以下内容: 一、Service not registered 异常导致手机重启 二、Service not registered 解决方案 2.1 修改ContextImpl类 2.2 修改 TransportManager 类 一、S...
SWT 重启案例分析（七）
程序员Android
06-20 267
极力推荐文章：欢迎收藏Android 干货分享 本篇文章主要介绍Android开发中的部分知识点，通过阅读本篇文章，您将收获以下内容: 一、线程死锁导致系统重启 二、小编能力有限，正在寻求解决方案 一、线程死锁导致系统重启 死锁Trace分析如下： 死锁导致重启log简析 1. TID =1 Block 等待 TID=9 释放锁 TID =1...
IO wait 高，导致SWT重启案例分析
程序员Android
07-28 211
和你一起终身学习，这里是程序员Android经典好文推荐，通过阅读本文，您将收获以下知识点:一、拷贝大文件，IO wait 高，导致SWT重启二、高IO wait 导致重启的 解决方案一、拷贝大文件，IO wait 高，导致SWT重启1.通过AEE抓取的log部分Log如下：Aee log2.高 IO 导致CPU 使用率过高部分Log如下：Block IO 很高导致重启二、高IO wa...
gbd 分析core文件_SWT-重启案例分析（一）
weixin_29572661的博客
12-29 383
和您一起终身学习，这里是程序员Android本篇文章主要介绍 Android 开发中的部分知识点，通过阅读本篇文章，您将收获以下内容: 一、MTK AEE Log分析工具 二、AEE Log分析流程 三、system_server 卡死案例分析及解决本文主要针对 Exception Type: system_server_watchdog , system_server卡死找出的分析以及解决方案。...
MTK GAT调试工具，里面有打开dbg文件的工具
08-12
MTK GAT调试工具，里面有打开dbg文件的工具，目录位于gat-win32-3\gat-win32-3\prebuilt\QATT\aee_extract.exe
android swt问题分析,Android 重启问题分析指南
weixin_34614674的博客
05-27 955
阅读五分钟，每日十点，和您一起终身学习，这里是程序员Android本篇文章主要介绍 Android 开发中的部分知识点，通过阅读本篇文章，您将收获以下内容:一、 AEE 系统机制简介二、AEE 重启异常分类介绍三、重启问题快速分析归类指南之 Kernel Exception四、重启问题快速分析归类指南之 Watchdog Timeout五、重启问题快速分析归类指南之 Hardware Reboot...
android调试日志不输出：AEE some logs have been lost
天才小汪汪
07-26 1874
最近公司的项目出现了一些偶尔卡死、ANR等状况，但是又不是经常出现，很难复现过程。查了一下anr日志，居然只有一次记录，其他情况都没存下来，所以也不知如何下手修复，只能先通过logcat来进行一下观察调试。 在调试观察过程中，每次还没等到出现异常（因为具体不知道哪里出情况，不好打断点，所以就全部输出了），日志就不输出了！！也就是只输出了一会儿，然后就没下文了，或者零零散散出现一两个，这简直不能忍...
如何直接打开aee db文件？分析重启，anr等问题
qq_28852011的博客
06-22 1950
[DESCRIPTION] 当发生异常后，除了有mtklog外，还有aee_exp目录下的db，很多异常分析都是基于db的。db是一个压缩的2进制文件，无法直接打开。 GAT（MTK网站可以下载，但是我下载的只有32位版本）里的logviewer可以直接打开解压，但是操作繁琐，这里提供一个直接双击打开db的方法。 [SOLUTION] 在windows操作系统上，可以将某个文件关联一个应用程序，双击这个文件就可以启动该应用程序打开。比如txt文件，双击后notepad.exe会打开txt文件。.
android swt问题分析,Android系统跑monkey测试发生SWT system_server问题log简单分析
weixin_28781243的博客
05-27 682
首先从手机导出DB文件，使用MediatekLogView解析db.fatal.00.SWT.dbg，打开__exp_main.txt文件，可以看到Fatal的详细信息。Exception Class: SWTException Type: system_server_watchdogCurrent Executing Process:system_serverTrigger time:[2010...
Dexopt代码修改导致的低概率Android soft watchdog timeout
沉思
03-26 1826
现象：使用过程中手机低概率卡住，等待30s左右死机重启，6580-O1平台.分析：Exception Class: SWTException Type: system_server_watchdogCurrent Executing Process: system_serverTrigger time:[2018-01-01 00:16:30.483495] pid:639Backtrace: P...
MTK debug工具GAT
liaokesen168的博客
10-31 1916
GAT工具需要使用.db文件存放目录为：taglog/TagLog/db.fatal.02.KE
mtklog结构及分析
热门推荐
u011714701的专栏
11-29 1万+
1.mtklog简介：mtklog是由log生成工具MTKLogger生成的一系列问题追踪文件，其主要作用就是对系统或者应用产生的异常进行快速定位，从而解决问题。 mtklog 的分类：MDLog、Mobile Log、Network Log，可能出现的aee_exp log MD log：medom 相关底层的log Mobile Log：主要是Android log 和kernel lo
SWT问题
最新发布
09-17
<think> 我们正在讨论的是SWT（Software Watchdog）问题，尤其是在Android系统中的表现。SWT是Android系统中用于监控系统服务响应的一种看门狗机制，当系统服务（如主线程）长时间未响应时，SWT会触发系统重启以防止系统挂死。根据引用[2]和引用[3]，我们可以了解到SWT的原理和常见原因。 用户提到想查找关于SWT问题的相关解决方案或信息。结合引用[2]中的内容，我们了解到SWT重启的原因可能包括： 1. 主线程（UI线程）被阻塞（如锁竞争、死锁、长时间操作） 2. Binder通信超时（Server端未及时响应） 3. Native方法执行时间过长 4. SurfaceFlinger卡住 5. Zygote Fork进程卡住 6. Dump时间过长（如生成ANR日志耗时太久） 另外，引用[3]解释了UI线程的重要性，即所有UI操作必须在同一线程中执行，否则会导致资源竞争和效率低下。 因此，针对SWT问题，我们可以从以下几个方面提供解决方案： ### 1. **分析日志定位问题** 根据引用[2]： - 搜索日志中的关键字`watchdog`，找到触发SWT的具体服务（如`ActivityManager`、`SurfaceFlinger`等）。 - 搜索关键字`held by`，检查是否有线程持有锁时间过长。 - 检查Binder的Server端（如AMS、WMS等）是否响应超时，通过Binder线程的调用栈分析。 ### 2. **解决主线程阻塞** - **避免在主线程执行耗时操作**：如网络请求、数据库操作、复杂计算等，应使用工作线程（如`AsyncTask`、`HandlerThread`、`ThreadPoolExecutor`）处理。 - **减少同步锁竞争**：避免在主线程中等待其他线程的锁，尤其是跨进程的Binder调用。如果必须使用锁，确保锁的持有时间尽可能短。 - **检查死锁**：使用工具（如`adb shell dumpsys window`或`adb shell dumpsys activity`)检查主线程的锁持有情况，排查循环等待。 ### 3. **优化Binder通信** - **确保Binder服务端及时响应**：Binder调用（尤其是非oneway）应在5秒内完成，否则会触发ANR或SWT。优化服务端逻辑，避免阻塞。 - 使用`adb shell dumpsys batterystats --binder`监控Binder调用耗时。 - 如果Binder调用对端进程繁忙，可考虑增加Binder线程池大小（通过`ProcessState::setThreadPoolMaxThreadCount`在Native层或`Binder.setMaxThreads`在Java层）。 ### 4. **处理Native层问题** - 如果日志显示Native方法执行时间过长（如引用[2]中的案例4.4），使用`perfetto`或`systrace`工具分析CPU使用情况。 - 检查JNI方法是否执行了复杂操作，优化算法或移到子线程。 ### 5. **SurfaceFlinger和图形系统** - 如果SurfaceFlinger卡住（引用[2]中4.5），检查GPU驱动或硬件合成器（HWC）是否异常。更新GPU驱动或禁用硬件加速测试。 - 减少过度绘制，优化UI布局。 ### 6. **Zygote优化** - Zygote fork进程耗时过长（引用[2]中4.6）通常由资源竞争引起。确保Zygote启动时加载的预加载类/资源不过多。可通过`adb shell dumpsys meminfo zygote`检查内存。 ### 7. **避免Dump操作超时** - 生成ANR日志或`dumpsys`输出时，避免在系统服务中保存过多历史数据。优化`dump`方法，分页输出或异步处理。 ### 示例：解决主线程阻塞导致的SWT ```java // 错误示例：在主线程执行耗时操作 public void onClick(View view) { // 模拟耗时操作（>5秒） try { Thread.sleep(10000); } catch (InterruptedException e) { e.printStackTrace(); } } // 正确做法：使用工作线程 public void onClick(View view) { new Thread(() -> { // 执行耗时操作 try { Thread.sleep(10000); } catch (InterruptedException e) { e.printStackTrace(); } // 更新UI需切回主线程 runOnUiThread(() -> textView.setText("Done")); }).start(); } ``` ### 总结 解决SWT问题的核心是**确保系统关键服务（尤其是主线程和Binder线程）及时响应**。通过日志分析定位阻塞点，优化代码逻辑，避免长时间阻塞。同时，监控工具（如`systrace`、`perfetto`）和系统命令（如`dumpsys`）是辅助分析的关键[^2][^3]。 §§相关问题§§ 1. 如何通过日志分析Android SWT重启的具体原因？ 2. 有哪些工具可以监控Android主线程的阻塞情况？ 3. 如何优化Binder通信以避免超时？ </think> ### SWT问题分析与解决方案 SWT（Software Watchdog）是Android系统的软件看门狗机制，用于监控系统关键服务响应状态。当系统服务响应超时（默认5秒）时，SWT会触发系统重启以防止系统完全挂死。以下是针对SWT问题的全面分析与解决方案： #### 1. **SWT问题诊断方法** [^2] - **日志关键字段搜索**： - `adb logcat | grep "watchdog"`：定位SWT重启事件 - `adb logcat | grep "held by"`：查找锁竞争导致的线程阻塞 - `adb shell dumpsys activity processes`：检查Binder服务端状态 - **线程阻塞分析**： ```bash # 检查持有锁的线程 adb shell dumpsys window | grep -A 10 "Blocked in" ``` #### 2. **常见原因与解决方案** - **主线程阻塞**（UI线程）[^3]: - **现象**：UI无响应导致SWT重启 - **解决**： ```java // 将耗时操作移出主线程 new Thread(() -> { // 后台任务（如网络请求/数据库操作） runOnUiThread(() -> updateUI()); // UI更新需切回主线程 }).start(); ``` - **Binder通信超时**： - **诊断**：检查Binder对端服务是否阻塞（`dumpsys activity top`） - **优化**： - 服务端添加`oneway`关键字（异步调用） - 增大Binder线程池：`BinderInternal.setMaxThreads(32)` - **Native方法卡死** [^2]: - **现象**：`SystemServer`卡在JNI调用 - **工具**：使用`perfetto`抓取Native调用栈 - **滚动视图问题**（SWT组件相关）[^4]: - **修复滚动条异常**： ```java // 避免使用getOrigin()获取大偏移量 ScrollBar hBar = scrolledComposite.getHorizontalBar(); int scrollPos = hBar.getSelection(); // 正确获取滚动位置 ``` #### 3. **预防性措施** - **锁优化**： - 使用`tryLock()`替代阻塞锁 - 设置锁超时：`lock.tryLock(500, TimeUnit.MILLISECONDS)` - **性能监控**： ```bash adb shell am hang --allow-restart # 模拟ANR测试 ``` - **系统参数调整**： ```bash adb shell setprop debug.checkjni 1 # 开启JNI检查 adb shell setprop persist.sys.watchdog.timeout 10000 # 延长超时阈值(ms) ``` #### 4. **典型案例分析** [^2] - **SurfaceFlinger卡死**： - 现象：图形合成器未及时返回`VSYNC` - 解决：更新GPU驱动或禁用硬件加速 - **Zygote进程卡住**： - 诊断：`adb shell ps | grep zygote` - 措施：清理预加载资源或重启`zygote` > **关键提示**：80%的SWT问题由主线程阻塞或跨进程死锁引起，优先检查UI线程和Binder通信链[^3]。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

程序员Android

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

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

余额充值