回答一

资源对象没关闭造成的内存泄漏（如： Cursor、File等）
ListView 的 Adapter 中没有使用缓存的 ConvertView
Bitmap 对象不在使用时调用recycle()释放内存
集合中对象没清理造成的内存泄漏（特别是 static 修饰的集合）
接收器、监听器注册没取消造成的内存泄漏
Activity 的 Context 造成的泄漏，可以使用 ApplicationContext
Handler 造成的内存泄漏问题（一般由于 Handler 生命周期比其外部类的生命周期长引起的）

回答二

1、内存泄漏的根本原因在于生命周期长的对象持有了生命周期短的对象的引用
2、常见场景
（1）资源对象没关闭造成的内存泄漏（如： Cursor、File等）
（2）全局集合类强引用没清理造成的内存泄漏（特别是 static 修饰的集合）
（3）接收器、监听器注册没取消造成的内存泄漏，如广播，eventsbus
（4）Activity 的 Context 造成的泄漏，可以使用 ApplicationContext
（5）单例中的static成员间接或直接持有了activity的引用
（6）非静态内部类持有父类的引用，如非静态handler持有activity的引用
3、如何避免内存泄漏
（1）编码规范上：
①资源对象用完一定要关闭，最好加finally
②静态集合对象用完要清理
③接收器、监听器使用时候注册和取消成对出现
④context使用注意生命周期，如果是静态类引用直接用ApplicationContext
⑤使用静态内部类
⑥结合业务场景，设置软引用，弱引用，确保对象可以在合适的时机回收
（2）建设内存监控体系
线下监控：
①使用ArtHook检测图片尺寸是否超出imageview自身宽高的2倍
②编码阶段Memery Profile看app的内存使用情况，是否存在内存抖动，内存泄漏，结合Mat分析内存泄漏
线上监控：
①上报app使用期间待机内存、重点模块内存、OOM率
②上报整体及重点模块的GC次数，GC时间
③使用LeakCannery自动化内存泄漏分析
总结：
上线前重点在于线下监控，把问题在上线前解决；上线后运营阶段重点做线上监控，结合一定的预警策略及时处理
4、真的出现低内存，设置一个兜底策略
低内存状态回调，根据不同的内存等级做一些事情，比如在最严重的等级清空所有的bitmap，关掉所有界面，直接强制把app跳转到主界面，相当于app重新启动了一次一样，这样就避免了系统Kill应用进程，与其让系统kill进程还不如浪费一些用户体验，自己主动回收内存