（1）当存储键值对的键为int类型，并且数据量不大（千级以内）的情况下，使用是SparseArray来代替HashMap，存取效率更高。
（2）Handler的优化：
非静态内部类持有外部类的引用，页面退出后，由于Handler没有发送完消息，导致持有的外部类不能及时销毁，解决办法：使用静态内部类加弱引用的方式。
（3）正确的使用Context：
上下文环境，用于获取资源文件，启动Activity，获取系统文件目录，错误的使用单例会造成内存泄漏，单例模式中如果传入的context是一个Activity或者Service实例，那么会在应用退出前，单例一直存在，activity或service引用一直被单例持有，从而不能被垃圾回收器回收，关联的view也不能被释放，正确的做法是使用applicationContext，它的生命周期与应用是一样的。
（4）避免创建重复的对象，避免在循环中重复创建相同的对象。避免在重复调用的方法中频繁创建对象，（例如onMeasure中new 对象），短时间创建和销毁大量的对象会造成内存抖动，原理是gc过程整体上市并行的，但是中间有串行的部分，内部的STW指令就是停止一切操作，如果这个指令被频繁调用，则会引起页面的卡顿。
（5）基本数据类型和String类型的常量，建议使用static final修饰，因为final修饰的常量会进入静态dex文件的域初始化部分，这时对于常量的调用不会涉及类的初始化，而是直接调用字面量。
（6）类内部调用属性时，尽量避免使用getter/setter，而是直接访问变量，没有JIT编译时，速度是3倍，有JIT时，速度是7倍。
（7）项目中的图片，尽量使用webP格式，既能保证图片质量，又能减小大小。
（8）启动优化，采用dispatcher方式，将各个SDK需要初始化的内容放入子线程中执行，采用图的结构确定先后关系，避免在application主线程中占用过多时间来进行初始化操作。异步，利用多线程提高TPS
（9）电量优化：定位采用gps定位精度最高，但是最消耗电量，移动基站，精度差一些，能省一部分电量，被动定位最省电，精度最差。
尽量避免定时器轮询的使用，如果必要的情况下，减少循环请求的次数与频率。
BroadcastReceiver要及时关闭，相当于一个系统级别监控器，耗费电量。
service不用时要销毁，
（10）网络请求优化：OKHTTP默认采用gzip压缩，一旦自己手动在请求header中加入gzip，那么就需要在响应中自己进行解压缩，（OKHTTP回认为使用者会自己定义加压与处理逻辑），gzip 压缩可以将请求与返回的数据进行压缩，从而减少数据传输量，进而节省流量。加快传输速度。
1）请求头中keep-alive，可以减少TCP连接次数，防止因多次连接造成的资源浪费。
2）请求过程中使用rxjava合并请求，也可以减少连接次数。
3）懒加载与预加载的合理使用。viewpager+fragment可实现懒加载，页面展示时再加载。
4）图片做必要的缓存操作，请求图片时最高告知需求大小，防止造成不必要的数据传输，
5）HTTP必须加timeout时间，
6）开启gzip压缩
7）根据http头信息中的Cache-Control及expires域确定是否缓存请求结果。
8）减少网络请求次数，服务器端适当做请求合并。
（11）布局优化：
减少布局嵌套层级，merge减少层数，include可以布局复用，ViewStub可以节省加载内存，只有显示时才占用内存。性能上? ?ConstraintLayout? ?优于 FrameLayout 优于? LinearLayout? ?优于? RelativeLayout，ConstraintLayout? ?有自己的布局优化算法。
避免过度绘制，减少使用background，分四个等级? ?红色? >? 黄色 > 蓝色 >绿色，绿色是最优的绘制，红色黄色则是需要优化的。
lint进行布局检查
（12）内存优化：
使用leakCanary来查找内存泄漏，从而进行优化。内部原理是：通过RefWatcher来监控activity 的生命周期与销毁情况，并且会主动调用gc，如果调用gc过后，引用仍然存在，则证明该点存在泄漏。使用HeapAnalyzerService来对内存检测结果进行分析。
MVP架构中，如果p层长期持有v层的实例，导致v层的对象难以回收，而v层一般是activity或者Fragment，因此需要在p层使用v层的弱引用或是在p层中实现v层的销毁方法，处理销毁的逻辑。