Android AutofillService内存泄漏问题求助（LeakCanary检测到）

从你提供的LeakCanary报告和代码来看，泄漏的核心原因已经明确：

泄漏链分析 #

GC Root是Native层的全局变量，指向android.service.autofill.AutofillService$1（系统Binder Stub类），这个Stub作为非静态内部类，持有你的MyAutofillService实例的强引用。当Service执行onDestroy后，Binder Stub因被Native层长期持有，导致Service实例无法被GC回收，最终造成内存泄漏。

你的协程代码里用WeakReference持有Service实例的操作其实没起到作用——因为泄漏的根源不在协程，而在系统框架层的Binder引用。

排查与解决思路 #

1. 清理Service内的额外强引用
   检查MyAutofillService中是否持有单例、静态变量或其他长生命周期对象的强引用，尽量替换为弱引用或软引用，减少Service实例被额外持有的可能。

2. 优化协程作用域与逻辑

   • 你的serviceScope在onDestroy时已经取消，这部分是正确的，但可以进一步优化协程逻辑：将数据获取等业务逻辑封装到静态内部类或独立的工具类中，避免在协程lambda中直接捕获this（Service实例），从根源切断协程对Service的强引用。
   • 移除不必要的WeakReference，因为它对当前泄漏问题无帮助，反而增加代码复杂度。

3. 规避系统框架潜在问题
   根据LeakCanary提示，若AutofillService$1是系统框架类，可能是Android 34（你当前SDK版本）的特定bug。可以尝试：

   • 测试不同Android版本设备，确认泄漏是否仅存在于特定版本；
   • 将Service中的核心业务逻辑迁移到静态内部类中，让Service仅作为系统回调的中转层，减少Service实例被持有的风险。

4. 验证泄漏是否为“假阳性”
   Binder Stub的特性是会被保留到另一端（系统进程）GC为止，有时LeakCanary会误报这类跨进程引用导致的“延迟回收”。可以等待更长时间后再次检查，或使用Android Studio的Profiler手动触发GC，确认是否真的无法回收。

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