虽然目前手机已经进入大内存时代，但是在电视机上内存还是少的可怜，公司的机型内存一般在512M-1.5G区间，就算是一个1.5G内存的机器，内置30个左右的app开机内存剩余也就几百M了，所以应用如何节省内存还是非常必要的，另外应用内存的泄露也对用户体验及流畅度的一个比较大的阻碍，所以说内存优化对于应用开发还是比较重要的，下面就对本人在应用开发中对内存优化的一些理解做下归纳总结
1. 内存占用过大问题
大家是否有同样的感受呢，项目开发送测后，经常被吐槽内存占用过大，内存占用过大往往对于新手来说是比较头疼的问题，其实内存过大的问题90%以上都是图片导致的，这就需要我们对图片的展示进行一定优化，尽量少占内存，压缩图片的技术比较常见了，这里就详谈了，这里我推荐几个开源库给大家进行图片展示，我们可以使用Volley和Picasso来处理图片，对缓存等数据进行配置，来解决应用内存占用过大的问题，使用开源库的好处就是，框架成熟，性能优（如果有不熟悉的同学，请自行搜索关于这两个开源库的使用的文章吧）
2. OOM异常
大家在开发应用时应该偶尔会出现OOM异常，应用在运行过程中直接挂掉，导致这个问题一般有两个原因，一是调用了某个接口申请的内存超过了系统分配给应用的最大值，二是内存泄露，内存泄露问题下面我会单独讲，先说一下第一点，举个简单的例子就是一张大图片在decodeFile之前没有进行压缩，这是新手常犯的错误，这种问题只要看堆栈打印，找到对应的sourcecode就可以解决了，比较头疼的是内存泄露问题，下面会单独讲一下，其实你会发现追查内存泄露并不是那么难
3. 内存泄露
在Java中有些对象的生命周期是有限的，当它们完成了特定的逻辑后将会被垃圾回收；但是，如果在对象的生命周期本来该被垃圾回收时这个对象还被别的对象所持有引用，那就会导致内存泄漏；这样的后果就是随着我们的应用被长时间使用，他所占用的内存越来越大
上面代码就是一个最简单的内存泄露的例子，单例持有了activity的实例，单例销毁之前activity无法被销毁，那么我们除了看阅读代码怎么发现内存泄露呢，当然是用工具，在这里简单起见直接推荐大家使用Android Studio自带的Memory Monitor，没有推荐MAT是因为这个是eclipse插件，来回切换比较麻烦，打开adb调试后，就可以观察进程的内存使用情况，具体请看图片，
从图中Memory的信息可以看出应用内存的变化，如果我们重复进入某个界面时内存一直在增长那么基本可以肯定发生了内存泄露了，定位到是哪个activity后，我们再使用Allocation Tracking工具，来查找泄露点，关于工具的使用这里就不详细详解了，使用Allcation Tracking工具可以帮助我们追踪内存分配信息，按顺序排列，这样我们就能清晰看出来某一个操作的内存是如何一步一步分配出来的。比如在有内存抖动的可疑点，我们可以通过查看其内存分配轨迹来看短时间内有多少相同或相似的对象被创建，进一步找出发生问题的代码
最后给出一些避免内存泄露发生的建议：
•Context使用不当造成内存泄露；不要对一个Activity Context保持长生命周期的引用（譬如上面概念部分给出的示例）。尽量在一切可以使用应用ApplicationContext代替Context的地方进行替换。
•非静态内部类的静态实例容易造成内存泄漏；即一个类中如果你不能够控制它其中内部类的生命周期（例如Activity中的一些特殊Handler等），则尽量使用静态类和弱引用来处理
•使用静态Handler。
•对象的注册与反注册没有成对出现造成的内存泄露；譬如注册广播接收器、注册监听等。
•创建与关闭没有成对出现造成的泄露；譬如Cursor资源必须手动关闭，WebView必须手动销毁，流等对象必须手动关闭等。•不要在执行频率很高的方法或者循环中创建对象，可以使用HashTable等创建一组对象容器从容器中取那些对象，而不用每次new与释放。