anr 原因

/*
1. 前台ANR发生后，系统会马上去抓取现场的信息，用于调试分析，收集的信息如下: 
	1. 将am_anr信息输出到EventLog，也就是说ANR触发的时间点接近的就是EventLog中输出的am_anr信息
	2. 收集以下重要进程的各个线程调用栈trace信息，保存在 data/anr/traces.txt文件 
		1. 当前发生ANR的进程，system_server进程以及所有persistent进程 audioserver, cameraserver, mediaserver, surfaceinger等重要的native进程，CPU使用率排名前5的进程 
	3. 将发生ANR的reason以及CPU使用情况信息输出到main log 
	4. 将traces文件和CPU使用情况信息保存到dropbox，即 data/system/dropbox目录 
	5. 对用户可感知的进程则弹出ANR对话框告知用户，对用户不可感知的进程发生ANR则直接杀掉 
2. 分析步骤 
	a. 定位发生ANR时间点 
	b. 查看trace信息 
	c. 分析是否有耗时的message，binder调用，锁的竞争，CPU资源的抢占 
	d. 结合具体的业务场景的上下文来分析

*/

/*
1. 主线程尽量只做UI相关的操作，避免耗时操作，比如过度复杂的UI绘制，网络操作，文件IO操作 
2. 避免主线程跟工作线程发生锁的竞争，减少系统耗时binder的调用，
谨慎使用sharePreference，注意主线程执行provider query操作

总之，尽可能减少主线程的负载，让其空闲待命，以期可随时响应用户操作
*/

/*
OOM 就是传说中的OutOfMemory，内存占用超出了app的大允许范围

产生原因 
Android中的大部分内存问题归根结底都是Bitmap的问题 
数组 List Map等集合没及时释放，或者使用的时候没关注当前App剩余可用内存量 
数据库游标问题 
构造Adapter时，没有使用缓存的convertView
*/

/*
图片优化压缩方式大概可以分为以下几类：
	更换图片格式，质量压缩，采样率压缩，缩放压缩，调用jpeg压缩等
	
	png：无损压缩图片格式，支持Alpha通道，Android切图素材多采用此格式
	jpeg：有损压缩图片格式，不支持背景透明，适用于照片等色彩丰富的大图压缩，不适合logo
	webp：是一种同时提供了有损压缩和无损压缩的图片格式，派生自视频编码格式VP8

采用webp能够在保持图片清晰度的情况下，可以有效减小图片所占有的磁盘空间大小
预测编码的原理是基于前面编码好的宏块，预测多余的动作颜色等信息，属于帧内预测
[.link](https://zhuanlan.zhihu.com/p/23648251)
*/


/*
设置 inJustDecodeBounds 属性为true可以在解码的时候避免内存的分配，它会返回一个null的Bitmap
但是可以获取到 outWidth, outHeight 与 outMimeType。构造Bitmap之前优先读图片的尺寸与类型。
*/

/*
BitmapFactory.Options options = new BitmapFactory.Options();
options.inJustDecodeBounds = true;
BitmapFactory.decodeResource(getResources(), R.id.myimage, options);
int imageHeight = options.outHeight;
int imageWidth = options.outWidth;
String imageType = options.outMimeType;
*/

/*
为了避免java.lang.OutOfMemory 的异常，我们需要在真正解析图片之前检查它的尺寸

加载一个按比例缩小的版本到内存中，通过上面的步骤我们已经获取到了图片的尺寸，
因素需要考虑：
	评估加载完整图片所需要耗费的内存。
	程序在加载这张图片时可能涉及到的其他内存需求。
	呈现这张图片的控件的尺寸大小。
	屏幕大小与当前设备的屏幕密度。
*/

/*
例如，如果把一个大小为1024x768像素的图片显示到大小为128x96像素的ImageView，就没有必要把整张原图都加载到内存中。

解码器加载缩小版本的图片到内存中，需要BitmapFactory.Options 设置 inSampleSize 值。
分辨率为2048x1536的图片，设置 inSampleSize 为4，产出512x384大小的Bitmap。
加载缩小图片使用0.75MB的内存，加载完整尺寸的图片，需要12MB（前提Bitmap的配置是 ARGB_8888）
*/

/*
质量压缩：
并不会改变图片在内存中的大小，仅仅会减小图片所占用的磁盘空间的大小，
因为质量压缩不会改变图片的分辨率，而图片在内存中的大小是根据
width*height*一个像素的所占用的字节数计算的，宽高没变，在内存中占用的大小自然不会变，
质量压缩的原理是通过改变图片的位深和透明度来减小图片占用的磁盘空间大小，所以不适合作为缩略图，
可以用于想保持图片质量的同时减小图片所占用的磁盘空间大小
*/

/*
采样率压缩
 采样率压缩是通过设置BitmapFactory.Options.inSampleSize，来减小图片的分辨率，进而减小图片所占用的磁盘空间和内存大小。
 设置的inSampleSize会导致压缩的图片的宽高都为1/inSampleSize，整体大小变为原始图片的inSampleSize平方分之一，当然，这些有些注意点：
 1、inSampleSize小于等于1会按照1处理
 2、inSampleSize只能设置为2的平方，不是2的平方则最终会减小到最近的2的平方数，如设置7会按4进行压缩，设置15会按8进行压缩。 
*/

/*
缩放压缩
 通过减少图片的像素来降低图片的磁盘空间大小和内存大小，可以用于缓存缩略图
 如果不需要图片的透明度，可以将ARGB_8888改成RGB_565，这样之前每个像素占用4个字节，现在只需要2个字节，节省了一半的大小
*/

/*
 1、使用webp格式的图片可以在保持清晰度的情况下减小图片的磁盘大小，是一种比较优秀的，google推荐的图片格式
 2、质量压缩：可以减小图片占用的磁盘空间，不会减小在内存中的大小
 3、采样率压缩：可以通过改变分辨率来减小图片所占用的磁盘空间和内存空间大小，但是采样率只能设置2的n次方，可能图片的最优比例在中间
 4、尺寸压缩：同样也是通过改变分辨率来减小图片所占用的磁盘空间和内存空间大小，缩放的尺寸没有什么限制
	 既然尺寸压缩和采样率压缩都是通过改变图片的分辨率来降低大小，有什么区别吗？
	 其中一个原因已经说明了，采样率的压缩比例会受到限制，尺寸压缩不会，但是采样率压缩的清晰度会比尺寸压缩的清晰度要好一些
	 缩小同样的倍数的情况下，采样率压缩看起来会比较柔和一些，尺寸压缩则锯齿比较多
*/

/*
内存缓存与磁盘缓存
*/

/*
为了给LruCache选择一个合适的大小，需要考虑到下面一些因素：

	应用剩下了多少可用的内存?
	多少张图片会同时呈现到屏幕上？有多少图片需要准备好以便马上显示到屏幕？
	设备的屏幕大小与密度是多少？一个具有特别高密度屏幕（xhdpi）的设备，像Galaxy Nexus会比Nexus S（hdpi）
	需要一个更大的缓存空间来缓存同样数量的图片。
	Bitmap的尺寸与配置是多少，会花费多少内存？
	图片被访问的频率如何？是其中一些比另外的访问更加频繁吗？如果是，那么我们可能希望在内存中保存那些最常访问的图片
	或者根据访问频率给Bitmap分组，为不同的Bitmap组设置多个LruCache对象。
	是否可以在缓存图片的质量与数量之间寻找平衡点？某些时候保存大量低质量的Bitmap会非常有用
	加载更高质量图片的任务可以交给另外一个后台线程。
*/

/*
如果图片会被更频繁的访问，使用ContentProvider或许会更加合适，比如在图库应用中。

内存缓存的检查是可以在UI线程中进行的，磁盘缓存的检查需要在后台线程中处理。
磁盘操作永远都不应该在UI线程中发生。当图片处理完成后，Bitmap需要添加到内存缓存与磁盘缓存中，方便之后的使用。
*/