1.I/O篇
1.1磁盘I/O
- 项目要求不需要实时性和及时性尽可能的多用缓存，因为看你导致重复读写，在一些系统API中每次都可能需要重复打开文件导致磁盘IO读写性能浪费。
例如SharedPreferences的commit每一次的commit都进行了一次文件的打开和关闭，因此尽可能的使用一次commit方法即可。利用混存来保存多次写入的数据，延迟写入，从而减少写入次数。
- 避免主线程进行读写，移到子线程中处理I/O事宜。因为有可能发生『放大效应』（简单来讲放大效应是在随机读写时需要清理当前磁盘的块整理的过程，和顺序读写不同在于整理过程需要耗费一定的性能导致明明只写8KB的大小却需要调度到512KB）会让平时是多毫秒的操作放大几十倍，导致主线程长时间未响应导致的体验不佳。但是数据是见面的来源，么有数据也无法展示相应的核心内容，所以移入子线程只是解决的第一步，最重要的是如何真正的减少I/O甚至避免I/O操作。
- 合理的I/O缓存设置Buffer的大小。可以根据业务和机器性能环境来适当的调整，在读写时使用缓冲区开可以减少读写的次数，从而减少了切换内核态的次数提高效率。一般推荐Buffer大小为8KB。
1.2数据库I/O
- 数据库连接打开后先不要关闭，保存这个连接，在应用程序退出在关闭。具体可以看一下SQLiteDatabase源码，getWritableDatabases（）方法的注释就有说明一旦打开数据库该连接就会被缓存，以供下一次使用，只有当真正不需要的时候调用close（）即可。
- 适当使用AUTO_INCREATEMENT，因为这个主键字段需要维护一张内部的sqllite_sequence表来保证不重复，因此磁盘读写次数也会从2次增加到11次，增加了额外的开销。因此建议客户端需要拿主键和服务端校对数据的时候需要保证主键唯一性即可。
附上SQLite官网的一句话：AUTOINCREATEMENT关键字会增加CPU、内存和磁盘空间以及磁盘IO的负担，所以尽量不要使用，除非必须。其实通常情况下都是不必须的。
3.Bitmap图片解析I/O
- 在Android4.4以上Bitmap的读取不要使用decodeFile和decodeResource效率很低，建议使用Stream的方式（例如decodeStream、decodeResourceStream）。原因是因为4.4后代码更改直接使用native方法去去写磁盘没经过缓存因此多次I/O操作导致的性能浪费。
2内存篇
一般内存问题氛围几个大类常驻内存问题（主要是图片缓存）、泄露问题（主要是Activity泄露）、GC问题（关键是GC For Alloc）后果都是会导致App Crash、闪退、后台被杀、卡顿等。
分析内存泄露可以通过一些工具，也可以观察一下内存曲线。
- 第一步观察内存曲线开启timeline工具的内存记录，重复操作同一个功能观察内存是否一直增长。
- 第二步记录内存快照，对某些引起内存增长的操作记录后dump两三遍
- 第三步快照立分析内存泄露的点
- 善用Context被ApplicationContext，注意隐形的持有，可能会导致的内存泄露。
- 官方建议开启子线程最好有停止自己的条件这样后面不会导致快速关闭窗口的时候导致内存泄露。
3.网络篇
优化网络性能无非看三个问题：业务成功率、业务网络延时、业务宽带成本。（推荐一个优秀的若网络模拟工具ATC）
- 业务成功率：正常网络信号好的情况下业务请求成功率是没什么大问题的，但是弱信号（简单看成手机信号只有一两格的时候），网络信令发送困难，而且还有可能导致不断切换网络、切换基站。APP能做的就是在应用层做重试。但是网络重试也要有一定的规则不要盲目重试。
- 业务网络延时：可以从dns和和长连接入手来缩短消耗
- 业务宽带成本：一般有三种方式压缩（从图片和传输资源入手）、增量（从更新入手）、去重复（避免重复下载利用好缓存）。
4.CPU篇
- 一般可以通过Android Studio的CPU消耗来查看CPU的使用情况。
- 还可以使用Linux命令例如top和ps
- 合理利用CPU和GPU在一定的程度上互相调节。
- 合理的使用线程调度充分利用CPU
5.电池篇
1.使用周期性的AlarmManager来进行数据上报最好有多个功能合并不要开多个。
2.合理的规避一些轮询操作。非必要不要多次唤醒机器，例如一些WifiLock、WakeLock等。