Flutter iOS加载网络/本地图片时内存泄漏导致崩溃问题排查

一、先定位EXC_BAD_ACCESS的核心原因 #

这个错误是野指针访问——某个对象已经被释放，但后续代码还在引用它。结合崩溃栈里的thunk for @escaping @Sendable，大概率是异步回调（比如上传完成通知、图片加载回调）在页面切换后，还在访问已经销毁的页面/对象。而且只在release模式出现，是因为正式版会做更激进的内存优化，对象被更快回收，debug模式有额外检查会延迟释放。

具体排查点：

• 检查上传后的回调逻辑：Firebase上传完成的回调、通知UI更新的代码，有没有在页面销毁时及时移除？比如Flutter页面的dispose()方法里，有没有取消上传任务、移除监听？如果原生层的回调持有了已销毁的FlutterViewController，就会触发野指针。
• 检查ExtendedImage的加载任务：页面切换后，之前页面的图片加载请求有没有被取消？就算禁用了缓存，未完成的加载回调回来时，页面已经不存在，也会导致崩溃。
• 排查状态更新时机：如果上传完成后调用setState更新UI，但此时页面已经被pop，就会操作已销毁的Widget，引发崩溃。

二、针对release模式的专属排查手段 #

• 用Xcode attach到正式版进程调试：打包TestFlight或Adhoc版本，安装到iPhone 14上，然后用Xcode的Debug > Attach to Process找到你的应用，开启Zombie Objects（Xcode菜单Product > Scheme > Edit Scheme > Diagnostics里勾选Zombie Objects），这样访问已释放对象时会给出具体的对象信息，而不是模糊的内存地址错误。
• 临时关闭编译优化：在ios/Podfile里给你的target添加config.build_settings['SWIFT_OPTIMIZATION_LEVEL'] = '-Onone'，或者用flutter build ios --release --no-tree-shake-icons编译，看崩溃是否消失，缩小是优化导致的问题范围。

三、针对性代码调整建议 #

• 页面销毁时彻底清理资源：
  • 在页面的dispose()方法里，调用Firebase上传任务的cancel()，终止未完成的上传，避免后续回调触发。
  • 移除所有相关监听：比如图片加载状态的监听、Firebase的通知监听，确保没有遗留的回调引用。
  • 对于ExtendedImage，可以手动取消加载任务，比如通过ExtendedImageProvider的cancel方法，或者清空当前页面的图片缓存键。
• 绑定异步逻辑到页面生命周期：
  • 用WidgetsBinding.instance.addPostFrameCallback包裹UI更新代码，确保只在页面存在时执行。
  • 优先用ExtendedImage.network直接加载Firebase的下载URL，代替先下载到内存再用ExtendedImage.memory，减少内存持有时间，也避免手动管理内存带来的问题。
  • 所有状态更新必须通过setState或状态管理工具（比如Provider、Riverpod），不要直接操作Widget实例。
• 检查iOS原生层的通知监听：
  • 崩溃栈提到了Notification，可能是原生层（比如image_picker或Firebase Storage的原生代码）注册了通知但没在合适时机注销。检查AppDelegate或自定义插件代码，确保通知监听在页面销毁时移除。
  • 测试不同iOS版本：如果条件允许，把测试设备升级到iOS 17或降级到16.5，确认是否是iOS 16.6.1的系统特定bug。

四、其他尝试方向 #

• 替换ExtendedImage为原生Image组件：如果用原生Image.network/Image.memory不会崩溃，那问题大概率在extended_image的实现上，可以回退到旧版本或者提交issue到其仓库。
• 检查内存泄漏：用Xcode的Memory Graph Debugger查看正式版运行时的内存情况，看是否有图片相关对象被异常持有或释放。
• 升级Flutter版本：尝试升级到最新稳定版（比如3.16+），看是否是Flutter 3.13.7的已知bug被修复。

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