1.内存泄漏的场景。
- 内存抖动：在较短时间内，反复的发生内存增长的回收。【onDraw里面new对象】
- 内存泄漏：本该释放的对象，一直无法释放，最终导致程序可用的内存越来越少，甚至无内存可用（OOM）.
1.1.资源对象未关闭引起的内存泄露。
Cursor,Socket在Activity销毁的时候，没有关闭。
EventBus或者广播在Activity销毁的时候，没有注销。
1.2.Handler|AsyncTask引起的内存泄漏.
原因：Handler是通过内部类来创建的，内部类持有外部类Activity的引用，也就是说Handler持有Activity的引用，当通过Handler发送延时Message的时候，因为Message中target就是Handler对象，也就是Message持有handler引用，而handle持有Activity引用，所以当我们关闭Activity的时候，activity的引用也是没有办法被回收。
1.3.使用单例模式，由于单例对象一直持有Activity对象，即使当Activity销毁了，mActivity对象也没法被回收。
示例：
public class AppManagerXiangxue {
private static AppManagerXiangxue instance;
private Activity mActivity;
private AppManagerXiangxue(Activity mActivity) {
this.mActivity= mActivity;
}
public static AppManagerXiangxue getInstance(Activity mActivity) {
if (instance != null) {
instance = new AppManagerXiangxue(mActivity);
}
return instance;
}
}
2.性能优化
2.1.布局优化
使用ConstraintLayout约束布局，减少嵌套，使用include复用,merge,ViewStub标签。
2.2.绘制优化
onDraw里面不要创建新的局部变量，因为onDraw可能会被频繁调用，从而导致内存抖动，onDraw不要做耗时任务，否者会导致view绘制过程不流畅。
2.3.内存优化。
【Android Profile 内存分析】 EventBus,File，Cursor,Brocast使用后，在onDestory需要注销.
2.4.线程优化.【Androd Profile 线程分析，看哪些线程占用的cpu时间较长】 使用线程池，可以复用核心线程池，减少频繁创建线程带来的性能开销。
2.5.启动速度优化. 任务异步加载处理
5.应用启动优化
- 黑白屏问题
- CPU Profile查看 java/kotlin method的执行时间
- 图片+动画 （SplashActivity） 3,2,1s按钮倒计时
- xml 布局优化，LayoutInspect查看xml的层级，手机打开开发者选项--- 调试GDP过度绘制
-
不在onCreate中初始化首屏非必须初始化的代码，像一些无关紧要的SDK的初始化，可以放到 onWindowFocusChange(hasFocus){ hasFocus=true后进行SDK.init初始化}
-
使用CPU Profile (Record java/kotlin method)在debug状态下查看每个方法的执行时间.
-
使用Momory Profile ( Record Java/kotlin 或者 Record Native C/C++)在debug状态下查看一段时间内，堆内存的对象分布情况
-- 使用Momory Profile Capture Heap dum (捕捉堆转储文件 .hprof文件)
- 使用MemoryAnalyerTool分析内存泄漏情况.
原理：通过堆内存快照对比（2个已经转换的.hprof文件），可以通过比较，在同一个页面某个时间的堆内存分布情况，如果有多出的对象就说明是被泄漏的对象
