Watchdog in Android

本文深入探讨了Android系统中的Watchdog机制,包括其在SystemServer中的实现方式、作用及如何通过检查关键服务来防止死锁。以InputManagerServer为例,展示了如何利用Watchdog确保系统稳定性。

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

Watchdog in Android

这里讲的Watchdog是AndoirdFramework中提到Watchdog类,不是一般CPU中用于系统复位的Watchdog硬件. 我认为Android的Watchdog就是系统一种软件检查一些关键服务是否发生死锁的机制

1,先看一下Watchdog在Android中的位置

image

2,在SystemServer使用单例模式构造自己

SystemServer.java
 
Slog.i(TAG, "Init Watchdog");
            Watchdog.getInstance().init(context, battery, power, alarm,
                    ActivityManagerService.self());
 
//////////////////////////
Watchdog.java
    public static Watchdog getInstance() {
10          if (sWatchdog == null) {
11              sWatchdog = new Watchdog();
12          }
13   
14          return sWatchdog;
15      }
16   
17      private Watchdog() {
18          super("watchdog");
19          mHandler = new HeartbeatHandler();     //得到一个mHander用于发送MONITOR message 去Check 相关Service
20      }
21   
22      public void init(Context context, BatteryService battery,
23              PowerManagerService power, AlarmManagerService alarm,
24              ActivityManagerService activity) {
25          mResolver = context.getContentResolver();
26          mBattery = battery;
27          mPower = power;
28          mAlarm = alarm;
29          mActivity = activity;
30   
31          context.registerReceiver(new RebootReceiver(),
32                  new IntentFilter(REBOOT_ACTION));
33          mRebootIntent = PendingIntent.getBroadcast(context,
34                  0, new Intent(REBOOT_ACTION), 0);
35   
36          context.registerReceiver(new RebootRequestReceiver(),
37                  new IntentFilter(Intent.ACTION_REBOOT),
38                  android.Manifest.permission.REBOOT, null);
39   
40          mBootTime = System.currentTimeMillis();
41      }
42   

3,Watchog是继承处Thread,它必须要实现run()方法,而且这个run()方法也是由SystemServer start()的。

SystemServer.java
Watchdog.getInstance().start();
 
Watchdog.java
 public void run() {
        boolean waitedHalf = false;
        while (true) {          //循环检查
            mCompleted = false;     //通过mCompleted来检查相关进程是否正常返回
            mHandler.sendEmptyMessage(MONITOR); //set MONITOR Messager
10   
11              synchronized (this) {
12                 ... //分半时逻辑实现
13            }
14  }
15   
16   
17   for (int i = 0 ; i < size ; i++) {
18                          mCurrentMonitor = mMonitors.get(i);
19                          mCurrentMonitor.monitor(); //调用所有实现了Moniter接口中的monitor函数,看是正常返回
20                      }
21   

4,以InputMangerServer为例是如何实现Watchdog来检查系统的关键服务是否发生死锁

InputManagerService.java
   // Called by the heartbeat to ensure locks are not held indefinitely (for deadlock detection).
    @Override
    public void monitor() {
        synchronized (mInputFilterLock) { }
        nativeMonitor(mPtr);
    }
->
static void nativeMonitor(JNIEnv* env, jclass clazz, jint ptr) {
10      NativeInputManager* im = reinterpret_cast<NativeInputManager*>(ptr);
11   
12      im->getInputManager()->getReader()->monitor();     //分别调用InputReader和InputDispatcher的monitor()
13      im->getInputManager()->getDispatcher()->monitor();
14  }
15  ->
16  void InputReader::monitor() {
17      // Acquire and release the lock to ensure that the reader has not deadlocked.
18      mLock.lock();
19      mEventHub->wake();
20      mReaderIsAliveCondition.wait(mLock);
21      mLock.unlock();
22   
23      // Check the EventHub
24      mEventHub->monitor();
25  }
26  ->
27  inline status_t Condition::wait(Mutex& mutex) {
28      return -pthread_cond_wait(&mCond, &mutex.mMutex);     //判断线程是否活
29  }
30   
31  ->
32  void InputDispatcher::monitor() {
33      // Acquire and release the lock to ensure that the dispatcher has not deadlocked.
34      mLock.lock();
35      mLooper->wake();
36      mDispatcherIsAliveCondition.wait(mLock);   //同样,mDispatchcherIsAliveCondition也是一个Condition类
37      mLock.unlock();
38  }
39  ->
40  void EventHub::monitor() {
41      // Acquire and release the lock to ensure that the event hub has not deadlocked.
42      mLock.lock();
43      mLock.unlock();
44  }
45   
### 回答1: "watchdog: Blocked in handler on UI thread (android.ui)" 是 Android 应用程序中常见的错误消息。它表示在应用程序的主线程(UI 线程)上执行的某个代码块被阻塞,导致用户界面无法响应。 这个错误通常由以下几个原因引起: 1. 长时间运行的任务: 如果应用程序的主线程上执行了需要较长时间才能完成的操作(例如读取大量数据或下载文件),则 UI 线程可能会被阻塞。 2. 阻塞 I/O 操作: 如果应用程序的主线程上执行了阻塞 I/O 操作(例如读取网络或文件系统中的数据),则 UI 线程可能会被阻塞。 3. 耗时的计算: 如果应用程序的主线程上执行了耗时的计算操作(例如计算大量数据或执行复杂算法),则 UI 线程可能会被阻塞。 为了解决这个问题,你可以尝试以下方法: 1. 在应用程序的主线程上执行耗时的操作是不好的,因此应该使用后台线程或 AsyncTask 等技术来执行长时间运行的任务或阻塞 I/O 操作。 2. 将耗时的计算操作放在后台线程上执行,以避免阻塞 UI 线程。 3. 使用 Android 的性能分析工具,例如 Traceview 或 Systrace,来识别和解决应用程序中的性能问题。 4. 使用 Android 的异步机制,例如 Handler、AsyncTask、Loader 和 IntentService 等来处理后台任务,从而避免 UI 线程的阻塞。 5. 使用 RecyclerView 或 ListView 等来避免在 UI 线程上加载大量数据。在使用这些视图时,可以使用异步加载技术,例如使用 AsyncTask 加载数据,或使用 Glide 或 Picasso 等图片加载库加载图片。 ### 回答2: 首先,"watchdog: Blocked in handler on ui thread (android.ui)"错误是指在Android的UI线程上的处理程序被阻塞了。这个错误通常是由于在UI线程上执行了长时间运行的操作造成的,导致应用程序的响应性能下降甚至崩溃。 要解决这个问题,可以进行以下几个步骤的分析思路: 1. 查看错误日志:在开发过程中,应该经常查看应用程序的日志,以便快速定位错误。搜索关键字"watchdog: Blocked in handler on ui thread (android.ui)",找到相关的错误日志信息。 2. 定位UI线程阻塞的位置:根据错误日志中的信息,定位到代码中导致UI线程阻塞的位置。可能是某个长时间运行的耗时操作,如网络请求、数据库访问或者复杂的计算。 3. 分析耗时操作:对定位到的代码段进行深入分析,确定耗时操作的原因。可以使用Log输出来查看代码执行的时间,进一步定位导致阻塞的具体原因。 4. 优化耗时操作:一旦找到了导致UI线程阻塞的耗时操作,应该考虑进行优化。可以通过使用异步处理、线程池等技术将耗时操作放在后台线程中执行,而不阻塞UI线程。 5. 使用Handler和MessageQueue:在一些特殊情况下,无法将耗时操作完全放在后台线程中执行,还可以考虑使用Handler和MessageQueue来处理一些耗时操作。通过将任务分解为小块并使用Handler发送消息,然后在UI线程上按序处理这些消息,可以降低UI线程的负载。 总的来说,解决"watchdog: Blocked in handler on ui thread (android.ui)"错误需要通过分析日志、定位问题代码、优化耗时操作等步骤来解决。重点是将耗时操作放到后台线程中执行,避免阻塞UI线程,以确保应用程序的响应性能和稳定性。 ### 回答3: 当我们在Android开发中遇到watchdog: Blocked in handler on ui thread (android.ui)的错误时,一般是由于在UI线程上执行了耗时操作引起的。 为了保证App的流畅性和响应性,Android设备规定UI操作只能在UI线程上执行,一旦在UI线程上执行了耗时操作,就会导致界面卡顿、ANR(Application Not Responding)甚至崩溃。 分析这个问题的思路如下: 1. 找出具体的错误信息和报错位置。通过查看Logcat中的详细日志信息,我们可以找到watchdog: Blocked in handler on ui thread (android.ui)错误的具体信息和堆栈跟踪。 2. 定位到错误的代码。通过查看错误信息中的堆栈跟踪,可以找到触发错误的具体代码位置。 3. 检查代码是否执行了耗时操作。查看错误位置附近的代码,判断是否有可能执行了耗时操作,例如网络请求、数据库查询、大数据处理等。 4. 将耗时操作移到子线程。如果确定错误是由于在UI线程上执行了耗时操作引起的,需要将该操作移到子线程中执行。可以使用多线程技术,如AsyncTask、HandlerThread、ThreadPoolExecutor等,在子线程中执行耗时操作,并在操作完成后通过Handler或runOnUiThread回到UI线程更新UI。 5. 优化耗时操作。除了将耗时操作移到子线程外,还可以尝试优化耗时操作本身,减少执行时间,例如使用算法优化、数据缓存、减少IO操作等。 6. 避免在UI线程中执行耗时操作。在编写代码时,需要时刻注意不要在UI线程中执行耗时操作,特别是网络请求、数据处理、文件读写等,应该采用异步操作或者使用线程池进行处理。 总之,分析watchdog: Blocked in handler on ui thread (android.ui)错误的思路主要是定位错误位置,并确定是否有耗时操作在UI线程上执行。如果确实有耗时操作,在将其移到子线程的同时,还要考虑优化操作本身以提升App的性能和用户体验。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

打赏作者

可夫小子

感谢大佬!

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

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

打赏作者

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

抵扣说明:

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

余额充值