Android应用SCREEN_OFF广播触发ANR问题求助（涉及paint.getTextBounds）

核心原因分析 #

SCREEN_OFF广播本身就在主线程（UI线程）分发，你又通过runOnUiThread把getImageWithMeasures的执行绑定到UI线程——相当于在本就有时间限制的主线程里叠加了耗时操作。paint.getTextBounds如果处理长文本、复杂字体，很容易占用主线程超过5秒，直接触发ANR。

具体解决步骤 #

• 将耗时操作移至后台线程：放弃在UI线程执行getImageWithMeasures，改用线程池、AsyncTask或协程（Kotlin）处理。示例代码：

  ExecutorService executor = Executors.newSingleThreadExecutor();
  executor.execute(new Runnable() {
      @Override
      public void run() {
          final Bitmap bm = getImageWithMeasures(true, true);
          // 需更新UI时再切回主线程
          HelloArActivity.this.runOnUiThread(new Runnable() {
              @Override
              public void run() {
                  // 处理Bitmap的UI更新逻辑
              }
          });
      }
  });
  

• 简化SCREEN_OFF广播中的操作：SCREEN_OFF广播的回调时间敏感度极高，系统对其处理有严格时限。如果生成Bitmap不是必须在此刻执行，考虑延迟到屏幕点亮时处理，或者提前预生成Bitmap并缓存。
• 优化paint.getTextBounds性能：若文本固定或重复，提前计算并缓存bounds结果；若文本过长，考虑分段处理或简化字体样式（比如避免使用复杂自定义字体）。
• 规范广播注册：如果是静态注册的SCREEN_OFF广播，改为动态注册，并在Activity销毁时及时注销，避免不必要的回调。动态注册的广播同样在主线程执行，需严格规避耗时操作。

额外说明 #

ANR本身不会直接导致崩溃，但系统可能因ANR强制杀死进程，或后续UI操作因ANR引发异常，才会出现崩溃。解决ANR的核心逻辑就是保证主线程不被阻塞。

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