一、资源未关闭造成的内存泄漏:

BraodcastReceiver, ContentObserver, File,Cursor,Stream,Bitmap
解决方案:
在Activity销毁时及时关闭或者注销。

二、Context造成的内存泄漏:

常见的工具类,Helper类,ViewModel,repository中会疯狂的使用context
解决方案:
能使用Application的Context就不要使用 Activity的Context

三、使用static静态修饰(比如使用自定义View问题)

Static对象中持有了view

举例说明：
假设有一个 ScrollViewHelper 类，它持有了一个 View（如 Activity 中的某个 View）的引用：

public class ScrollViewHelper {// 这个静态变量会导致内存泄漏public static View myView;public static void bindScrollBehavior(View view) {myView = view;// 假设进行一些滚动绑定操作}
}

在上述代码中，ScrollViewHelper 通过静态变量 myView 持有了 View 的引用。即使 Activity 被销毁了，ScrollViewHelper 仍然持有这个 View，这就会导致内存泄漏。

解决方案1：及时置为 null：
当 Activity 销毁时，应该将 ScrollViewHelper .myView 置为 null，以便垃圾回收器能够回收它：

public class MyActivity extends AppCompatActivity {@Overrideprotected void onDestroy() {super.onDestroy();// 及时清理静态引用ScrollViewHelper .myView = null;}
}

解决方案2：使用 WeakReference：
使用 WeakReference 来持有 View，这样 View 对象就不会阻止它被垃圾回收：

public class ScrollViewHelper {// 使用弱引用来避免内存泄漏public static WeakReference<View> myView;public static void bindScrollBehavior(View view) {myView = new WeakReference<>(view);// 假设进行一些滚动绑定操作}
}

通过使用 WeakReference，即使 Activity 销毁，myView 对象也不会阻止 View 被垃圾回收。

四、Handler内存泄露

mHandler是Handler的非静态匿名内部类的实例,所以它持有外部类Activity的引用,消息队列是在一个Looper线程中不断轮询处理消
息,那么当这个Activity退出时消息队列中还有未处理的消息或者正在处理消息,而消息队列中的Message持有mHandler实例的引用,mHandler又
持有Activity的引用,所以导致该Activity的内存资源无法及时回收,引发内存泄漏。

解决方案:
创建一个静态Handler内部类,然后对Handler持有的对象象使用弱引用,这样在回收时也可以回收Handler持有的对象,这样虽然避免了
Activity 泄漏,不过 Looper线程的消息队列中还是可能会有待处理的消息,所以在Activity的onDestroy时或者 onStop时应该移除消息队列中的消息

Handler内存泄漏详细文章链接：
https://blog.csdn.net/qq_43290288/article/details/125589243