Android中点击返回键时如何清除SecondActivity分配的所有资源

• 实现MainActivity跳转SecondActivity的交互流程，在SecondActivity中开启独立线程执行涉及上百个类的复杂数学计算，计算完成后将结果展示在TextView中，返回MainActivity的流程运行正常。
• 通过Android Studio性能剖析发现，计算逻辑关联的多个类（包含静态变量、枚举）长期驻留内存，手动清理部分静态变量仅能减少部分驻留资源，无法实现彻底清除。
• 需求为找到可行方案，在用户点击返回键时，彻底释放SecondActivity关联的所有计算逻辑相关资源。

• 类元数据驻留与实例对象泄漏是两类完全独立的问题：被类加载器加载到JVM中的类（含静态域、枚举实例），只要类加载器本身未被回收，类的元数据就会常驻Metaspace内存，不属于常规GC可直接回收的堆内存范畴，这也是手动清理静态变量也无法彻底消除类驻留的核心原因。
• 示例代码存在直接的引用泄漏：后台线程的Runnable因为调用了SecondActivity的非静态calculate()方法，会持有SecondActivity的强引用；如果用户在计算执行过程中按返回键退出Activity，这个未绑定生命周期的裸线程会长期拖住Activity实例，连带它引用的所有计算逻辑对象、视图对象都无法被GC回收。
• 手动清理静态变量的方案存在本质缺陷：随Apk打包的业务类由系统BootClassLoader加载，只要App进程不退出，这些类根本无法被卸载；手动清空静态变量仅修改了静态域的引用值，既不会卸载类本身，还可能因其他业务逻辑依赖这些静态值引发崩溃。

修复可直接回收的实例泄漏 #

• 解耦后台任务与Activity的引用绑定：将计算逻辑的入参拆分为独立的值对象，不再让后台线程持有Activity的强引用。例如将原来的非静态calculate()方法改造为纯静态方法，入参仅传递基础类型、可序列化的纯数据对象，不接触Activity的视图、非静态成员。
• 为计算任务添加生命周期绑定：
  • 使用ExecutorService提交计算任务，在SecondActivity的onDestroy()回调中主动调用shutdownNow()终止所有未执行完成的计算任务，切断后台线程对Activity的引用链。
  • 销毁Activity时移除Handler队列中所有未处理的消息，避免Activity销毁后Handler仍然持有视图引用。
• 主动清理计算产生的临时大对象：计算过程中生成的数组、中间结果缓存，在任务完成或Activity销毁时将强引用置空，避免这些对象被静态域、全局单例长期持有。

隔离计算模块实现全量释放 #

如果确实需要在返回SecondActivity时，将计算逻辑对应的类元数据、静态变量、枚举实例全部彻底从内存中移除：

• 放弃手动遍历所有计算类的静态域逐一清空值的方案：这种方式维护成本极高，极易漏清。
• 对计算逻辑模块做类加载隔离：将计算相关的代码、资源单独打包为独立的jar/dex文件，存放于App私有沙盒目录下，通过自定义DexClassLoader单独加载这部分逻辑。
• SecondActivity触发onDestroy()时，将所有与该自定义ClassLoader相关的引用全部置空（包括其加载的类实例、静态变量引用、正在执行的计算任务引用），JVM会在后续Full GC过程中自动卸载这个独立类加载器，连带它加载的所有类、静态变量、枚举实例、类持有的所有堆引用都会被彻底回收。
• 注意：该方案仅适合隔离体量极大、调用频率低的独立计算模块，不要将App核心业务类放入独立ClassLoader加载，否则会大幅提升类加载的性能开销。

无需特殊处理的正常驻留 #

• 枚举实例的驻留是JVM的默认设计，只要枚举类被加载，单例枚举实例就会存在，这部分内存占比极小，不需要特意清理。
• 随Apk打包的普通业务类，只要不持有大的堆对象引用，类元数据在Metaspace的驻留是正常现象，这类类只有App进程退出时才会被回收，属于Android应用的正常运行机制，并非内存泄漏，不需要为了“彻底清除类驻留”强行修改现有代码。

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