造成卡顿的原因

1. 内存泄露

• 内存溢出 out of memory，是指程序在申请内存时，没有足够的内存空间供其使用，出现out of memory；比如申请了一个integer,但给它存了long才能存下的数，那就是内存溢出。
• 内存泄露 memory leak，是指程序在申请内存后，无法释放已申请的内存空间，一次内存泄露危害可以忽略，但内存泄露堆积后果很严重，无论多少内存,迟早会被占光。

通俗来讲，内存泄露不仅仅会造成应用内存占用过大，还会导致应用卡顿，造成不好的用户体验，至于，为什么一个“小小的”内存泄露会造成应用卡顿。

当对象在Young Generation中存活了一段时间之后，如果没被干掉，那么会被移动到Old Generation中，同理，最后会移动到Permanent Generation中。那么用脚想一想就知道，如果内存泄露了，那么，抱歉，你那块内存随时间推移自然而然将进入Permanent Generation中，然鹅，内存不是白菜，想要多少就有多少，这里，因为沙盒机制的原因，分配给你应用的内存当然是有那么一个极限值的，你不能逾越，好了，你那块造成泄露内存的对象占着茅坑不拉屎，剩下来可以供其他对象发挥的内存空间就少了；打个比方，舞台小了，演员要登台表演，没有多余空间，他就只能等待其他演员下来他才能表演啊，这等待的时间，是没法连续表演的，所以就卡了嘛。

2. 频繁GC

频繁GC会造成卡顿，想必你经过上面的洗礼，已经知道了为什么，不错，当然也是因为“舞台空间不足，新的演员上台表演需要先让表演完的下来”。那么造成这种现象的原因是什么呢？

a、内存泄露，好的，你懂了，不用讲了，这个必须有可能会造成。

b、大量对象短时间被创建，又在短时间内“需要”被释放，注意这里的需要，其实是不得不，为什么，同样是因为“舞台空间不够了”，举个例子，在onDraw中new 对象，因为onDraw大约16ms会执行一次。脑补一下，每秒中创建大约60个对象，嗯，骚年，你以为Young Generation是白菜么，想拿多少就拿多少，对不起，这里是限量的，这里用完了，在来申请，我就得去回收一些回来，我回收总得耗时间吧，耗时间，好吧，onDraw 等着等着就错过了下一个16ms的执行了，如是，用户看起来就卡了。

c、Java中Stop-The-World机制简称STW，是在执行垃圾收集算法时，Java应用程序的其他所有线程都被挂起（除了垃圾收集帮助器之外）。为什么会有全局停顿？ 类比在聚会时打扫房间，聚会时很乱，又有新的垃圾产生，房间永远打扫不干净，只有让大家停止活动了，才能将房间打扫干净。STW（Stop-The-World）停顿的过程中，JVM会暂停所有的应用程序线程，此时应用程序会停止对用户请求的响应，这对于要求低延迟的系统来说，因此所导致的高延迟是不可接受的。

新生代的串行、PartNew，Part scavenge 收集器都需要STW，下面举一下STW的组合：

• Young GC类算法：Serial Young GC（DefNew）、Parallel Young GC、ParNew GC；
• Full GC类算法：Serial Old GC、PS MarkSweep GC / Parallel Old GC、Full GC for CMS算法、Full GC for G1 GC算法；
• G1 GC算法：Young GC/Mixed GC 是stw的；G1 GC算法在其标记阶段某几个时段是stop the world的，比如初始标记（initial mark）、再标记（remark）、清理（cleanup）阶段；
• CMS（Old）GC算法只在初始标记（initial mark）和再标记（remark）阶段stw一下；

3. OOM问题

呵呵，这个问题，想必经过前面1、2的洗礼，你应该已经明白这个什么原因导致的，你可以想想一下"舞台上将要上的一个演员是一个巨大胖子，即便不表演的演员都下来了，他还是挤不上去，怎么办，演砸了，还能怎么办，直接崩溃，散场！"造成这个问题的原因，可能有：

• 内存泄露
• 大量不可见的对象占据内存，这个其实，很常见，只是大家可能一直不太关心罢了，比如，请求接口返回了列表有100项数据，每项数据比如有100个字段，其中你用户展示数据的只有10几个而已，但是，你解析的时候，剩下的99个不知不觉吃了你的内存，当，有个胖子要内存时1980）or更大，而且你一下子还加载个几十张，扛得住么？所以了解一下inSampleSize，或者，如果图片归你们上传管理，你可以借助万象优图，他为你做了剪切好不同尺寸的图片，这样省得你在客户端做图片缩放了。