关于android内存优化的几点建议

1.及时清理不用的对象数据

android内存优化主要集中在对数据的处理之后没有集中销毁原有的集合数据
比如MVP模式，从model层传递过来的数据在view层进行了重新封装之后原有集合内部的数据依旧保持内存占用，相当于内存保留了两份，而这两份数据指向不同的地址，而对于java虚拟机来说，回收内存是通过主动调用系统GC来进行遍历回收，而遍历回收是如遇root比较深，遍历时间比较久，在GC争抢到CPU时间片的时候，很容易导致主线程堵塞，不仅内存会升高，对于APP的稳定性和用户体验极为不利
例：
model：
requestData（param）
{
url = string；
request(url)
runnable.run(request)
}
presenter:
setData(param)
{
view.setData(param)
}
view:
setData(param)
{
list = param.get(param)
//此时应该清空param，在不影响数据重复使用的情况下
param = null；
}

2.尽量使用局部变量，减少不必要的成员变量的使用

有的成员变量只是用了一次，但是因为代码习惯，设置为了成员变量，这个时候就应注意这些小细节，有时候内存就是由这一点点累积起来的

3.尽量不使用static修饰

提供相应的get和set方法供外部使用，静态数据在内存中的生命周期更长

4.避免死循环

在代码中尽量不要使用死循环，除非项目需要，就算要使用到死循环，比如后台推送什么的，也要结合广播和设置相应的flag来停止循环

5.合理使用线程

使用线程尽量使用线程池来管理，new出来的线程一旦线程开启就很难去关闭，除非抛异常，线程池可以很好的管理线程的开启、暂停和关闭，并且线程还能重复使用，避免了不必要的内存开销

6.android大图处理

android中内存开销最大的还属于大图的加载，三级缓存就不应说了，不做三级缓存，对于流量和内存都是致命的，除此之外，还要根据不同的容器空间对图片的处理做相应的调整，例如：listview中加载图片，可以根据用户的操作手势来判断图片的加载形式，用户在飞速滑动的时候可以不加载图片或者加载低像素图片（要么后台保存两份展示图片，或者前台进行不同的逻辑判断，根据使用的第三方库或者自己的缓存方式对图片进行相应的压缩，这个时候用户不会考虑到图片展现清晰度问题，而是会考虑到app的体验问题，可想如果每个item都去记载大图，滑动必定会卡顿），viewpager加载图片的是考虑到viewpager的缓存页卡问题，可以再current的页卡上展示原始图片，其他缓存页卡直接加载压缩图片，对于降低内存开销比较重要。gridview和recycleview的加载形式和listview基本差不多，都是可以根据相应的用户操作进行相应的图片加载。对于大图的加载也可以类微信朋友圈一样，在初始展示的总是最大压缩比例图片，当用户想要进行点击查看的时候可以发送请求，重新获取原始图片

7.无节制发送请求

对于app来说，前台和后台的交互式是数据存储和呈现的桥梁，而android来说，数据请求都是在子线程中进行了，每个请求都是一个任务，而这些任务耗费的内存远比一些集合占据的内存都要高，无节制的发送请求其实对于有些app来说也是没办法避免的，比如网络中断，这时候可以界面提示用户进行操作，避开代码自主发送失败的请求，还有一些考虑不周的情况，譬如微信摇一摇功能，如果不设置时间戳，每摇一次发送一个请求，不仅会导致数据紊乱，对于内存方面也是一大诟病

8.内存泄露平时多注意

内存泄露主要集中在引用不当，流未关闭（finally中关闭，防止抛异常未及时关闭），数据库游标未关闭，动态广播未注销，图片未及时回收等，这些问题应平时注意到，养成良好的编码习惯

9.尽量使用工厂、单例模式

使用工厂和单例模式减少对象重复创建