接口回调模式本身不导致内存泄漏，问题在于引用关系的生命周期管理；应遵循“谁注册、谁注销”原则，避免短生命周期对象被长生命周期对象长期持有，注册需在有效生命周期内进行并配对及时注销。
接口回调模式本身不导致内存泄漏，问题出在引用关系的生命周期管理上。核心原则是：谁注册、谁注销；短生命周期对象不应被长生命周期对象长期持有。
回调接口定义与注册时机
定义清晰的回调接口，明确方法语义和调用边界。注册必须发生在持有者（如Activity、Fragment或业务对象）处于有效生命周期阶段时，避免在onCreate之前或onDestroy之后注册。
- 接口应只暴露必要方法，避免冗余回调增加管理负担
- 注册前检查持有者状态（例如Activity.isFinishing()、isDestroyed()）
- 不要在静态上下文（如Application或单例）中直接持有可能为Activity/Fragment的回调实例
避免强引用导致的生命周期绑定
当回调实现类是内部类或匿名类时，它默认持有外部类的强引用。若回调被长生命周期对象（如后台服务、全局监听器）持有，外部Activity就无法被回收。
- 优先使用静态内部类 + WeakReference 持有外部上下文
- 非必要不使用匿名内部类实现回调；如需使用，确保其作用域严格受限
- 对Java/Kotlin中的lambda表达式保持警惕——它们可能隐式捕获this或局部变量
及时注销与资源清理
回调注册后必须配对注销，且注销逻辑要覆盖所有退出路径（包括异常分支）。不能依赖“理论上不会走到这里”来省略清理代码。
- 在Activity.onDestroy()、Fragment.onDestroyView()等明确的销毁点执行unregister
- 在异步任务完成、网络请求结束、相机停止采集等业务终点同步注销
- 使用try-finally或try-with-resources保障注销语句一定执行
SDK级回调的特殊处理（如海康MV_CC_RegisterImageCallBackEx）
原生SDK回调（C/C++层触发、Python/Java层接收）中，pData等指针指向的内存由SDK管理，Python/Java层不可长期保存或跨回调使用。
- 回调函数内完成数据拷贝（如numpy.array(ctypes.cast(pData, ...))），再交由主线程或队列处理
- 禁止将pFrameInfo或pData保存为类成员变量或全局变量
- 确认SDK文档中关于回调函数执行时限的要求，避免在回调中执行耗时操作阻塞SDK线程
