本文主要记载

Android 稳定性优化主要注意一下几点：

  • 执行超时 (Timeout)

    长时间无法执行完成。对于 Android 系统来说,比较常见的便是 Service 、Broadcast、provider 以及 input , 当普通 app 进程超过一定时间没有执行完, 则会弹出应用无响应 (Application Not Responding, ANR) 的对话框。如果该 app 运行在 system 进程，更准确的来说,应该是 (System Not Responding, SNR) 。 虽然有 ANR 和 SNR 之分, 但习惯上大家都统称为 ANR 问题。

    • Service Timeout：比如前台服务在 20s 内未执行完成。
    • broadcast Timeout：比如前台广播在 10s 内未执行完成。
    • ContentProvider Timeout：内容提供者执行超时。
    • InputDispatching Timeout：输入事件分发超时 5s ，包括按键和触摸事件。

  • *异常崩溃 (Crash) *

    异常崩溃 (Crash) 的问题, 毫无疑问这不是时间上能解决的问题, 而是出现了未知的异常. 一旦触发崩溃会出现相应的调用栈, 但不糊输出各个进程的traces。

    • Java 崩溃

      理解Java Crash处理流程

      往往是抛出了一个未捕获的异常 uncaughtException 而导致的崩溃. 那是不是把所有的异常都 catch 住系统就没有问题呢？这个是要分情况的，有时候的异常强制崩溃可能会留下更大的问题，有些异常的抛出是需要深入分析 Root Cause ，从根源来解决问题, 而非简单粗糙的捕获住所有的异常.

    • Native 崩溃

      理解Native Crash处理流程

      由于进程收到 signal信号而引发的崩溃。当进程收到信号，并会触发信号处理函数，通过 socket 发送信息到 debuggerd 进程，debuggerd 进程收到事件后通过 ptrace attach 到目标进程, 获取 cpu/memory/traces 等关键信息后 dettach 。Native crash 情况比较多, 其中最为场景便是SIGSEGV 段错误异常，往往是内存出现异常，比如访问了权限不足的内存地址等。