Android下的OOM异常、内存抖动和界面卡顿

OOM异常、内存抖动和界面卡顿：
1、OOM：可能由内存泄漏引起，泄漏的内存多了，可供使用的内存越来越少，遇到一些需要开辟内存的时候，就会报OOM(OutOfMemory)异常。
2、加载一些大的Bitmap的时候，瞬间就把分配给进程的内存全部占满。解决方式：图片的边界压缩。还有一种情况是：加载了多个占用内存较多的对象，也包括Bitmap对象，这时候，应用在运行的时候加载并保存了多个较大的Bitmap，导致可用内存急剧减少。因此，我们对于多个大量占据内存空间的对象，应该使用软应用或虚引用来持有该对象，使得GC在内存吃紧的时候可以回收该对象释放空间。并且在Bitmap不使用的时候，使用recycle()来主动释放内存空间。

内存抖动：
常见的内存抖动是：不断频繁的创建和短时间内释放对象，就会造成内存抖动。瞬间产生的大量的对象会严重占用内存区域，当达到阈值，剩余空间不够的时候就会触发GC。即使每次分配的对象占用了很少的内存，但是他们叠加在一起会增加Heap的压力。GC启动时会占用CPU等资源，直接导致应用运行受到影响，可能出现界面操作不流畅等现象。

界面卡顿：(
磁盘读写也要放在子线程中！磁盘读写中可能其他进程占用了I/O口，等待I/O口的过程会导致整个磁盘操作流程变慢。所以它是比较耗时的操作。)
界面卡顿指的是短时间内界面对用户的操作没有响应。
常见的界面卡顿原因：
Android应用的UI绘制和用户操作消息分发都发生在应用主线程，如果主线程来不及处理UI更新和响应用户操作，用户就会感觉应用发生了卡顿。因此卡顿发生时常常伴随着主线程阻塞。如果在主线程中进行磁盘读写、网络操作或者大量计算（可能是数据库的读写）时，常常会导致主线程被阻塞，发生界面卡顿。
4000

过度绘制：
过度绘制一般指的是屏幕上的某些区域在一帧中被多次绘制，一般在界面的同一个地方叠加了多个控件。这样会加重CPU的工作负担，可能导致应用运行过程中频繁掉帧。一般来说，最好把绘制控制在2层以下，3层有时候是不可避免的，尽量避免。4次基本是不允许的。

为了减少过度绘制，开发者应减少复杂的、层次较多的布局，去掉多余的背景色。
简单的界面尽量使用线性布局，较为复杂的界面可以使用相对布局，
避免嵌套过多的线性布局，可以使用ViewStub来动态加载界面。

启动分析：
冷启动：当启动应用后，后台没有该应用的进程，此时系统会创建一个新的进程分配给该应用。冷启动因为系统会创建一个新的进程分配给它，所以会先创建和初始化Application类，随后创建和初始化MainActivity类（包括一系列测量、布局、绘制），最后显示在界面上。
热启动：当启动应用时，后台已有该应用的进程（例：按back键，home键，应用虽然会退出，但是该应用的进程依然会保留在后台，可进入任务列表查看）所以热启动不会创建新的Application实例，而是直接创建和初始化MainActivity。一般来说，热启动的时间一般小于冷启动的时间。

严苛模式：
严苛模式是一种辅助的开发工具，帮助开发者发现那些由于编码过程中不注意而造成的问题。
严苛模式（StrictMode）经常用于捕获在应用主线程中进行的磁盘读写操作和网络请求。由于应用主线程是接收UI操作消息和执行界面渲染的地方，为了使应用更加流畅和更快响应，请不要在主线程中执行磁盘读写和网络请求。当然，这也能避免系统弹出ANR对话框和提高应用性能稳定性的好方法。
严苛模式能发现的错误包括：
a。应用在主线程中进行磁盘读写。
b。应用在主线程中进行网络请求。
c。应用在主线程中的某些自定义方法的执行时间比较长。
d。SQLCursor对象在使用后没有关闭。
e。继承了Closeable接口的对象在使用后没有关闭。
f。某一Activity有较多的实例。
g。文件读取接口暴露给外部应用。
h。注册某些对象（广播接收器、观察者、Listener等）后没有取消注册。
i。没有使用加密网络（HTTPS）进行网络数据传输。