Flutter Android应用偶发重启后崩溃问题排查求助

一、核心崩溃问题：旧Platform Channel回调触发的悬空引用 #

1. 拦截无效的Channel消息发送 #

在Android Native侧，所有通过Platform Channel向Flutter发送消息的逻辑前，必须先检查FlutterJNI的绑定状态，避免向已分离的引擎发送消息：

// 在发送Channel消息前添加检查
if (flutterEngine != null && flutterEngine.getFlutterJNI().isAttached()) {
    methodChannel.invokeMethod("yourCallbackMethod", responseData);
} else {
    // 记录日志并丢弃回调，防止崩溃
    Log.w("PlatformChannel", "FlutterJNI已分离，跳过无效回调");
}

2. 绑定回调与页面/引擎生命周期 #

• Flutter侧：在发起Native请求的页面中，通过WidgetsBindingObserver监听页面销毁或应用生命周期变化，一旦页面被dispose，主动通知Native侧取消对应请求的回调。
• Native侧：维护一个请求ID与回调的映射表，收到Flutter侧的取消通知时，标记对应回调为无效，网络请求完成后不再发送Channel消息。

3. 排查Flutter引擎重启的触发原因 #

• 查看系统日志中的lowmemorykiller条目，确认是否是系统内存不足导致Flutter引擎被重启（Native进程保留但Flutter层重启）。
• 检查Flutter侧跳转新页面的代码，是否存在意外触发引擎重启的逻辑（比如错误使用了引擎重启API，或者第三方插件的异常行为）。

二、符号化崩溃栈失败的解决 #

1. 核对BuildId的完整性 #

使用命令查看符号文件的完整BuildId：

objdump -s --section .note.gnu.build-id <你的符号文件路径>

将输出的BuildId与崩溃日志中的BuildId对比，确认是否是日志中BuildId被截断导致的匹配失败，确保使用对应架构（arm64-v8a/armeabi-v7a）的符号文件。

2. 手动符号化内存地址 #

如果自动符号化工具失效，提取崩溃栈中的内存地址，使用addr2line命令手动解析：

addr2line -f -C -e <符号文件路径> <崩溃栈中的内存地址>

注意要使用与崩溃设备架构一致的符号文件（比如Xiaomi 11T是arm64-v8a，对应app/build/intermediates/flutter/release/arm64-v8a下的符号文件）。

3. 确认符号文件与应用版本匹配 #

确保符号文件是编译当前崩溃版本应用时生成的，与应用使用的Flutter SDK版本完全一致，不要混用不同编译版本的符号文件。

三、复现与验证 #

• 在测试设备上模拟低内存场景（比如后台打开多个大型应用，使用开发者工具触发内存压力），尝试复现Flutter引擎重启的情况，验证修复后的代码是否能避免崩溃。
• 向受影响用户推送修复后的测试版本，收集日志确认问题是否解决。

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