参考：点击打开链接
最简单的是我们使用glide，picasso等第三方加载图片库来做缓存，易于使用、代码简洁。
glide使用：点击打开链接
下面介绍优化的方法和原理
Bitmap优化
比如说系统图片库里展示的图片大都是用手机摄像头拍出来的，这些图片的分辨率会比我们手机屏幕的分辨率高得多。大家应该知道，我们编写的应用程序都是有一定内存限制的，程序占用了过高的内存就容易出现OOM(OutOfMemory)异常。
我们可以通过下面的代码看出每个应用程序最高可用内存是多少。
int maxMemory = (int) (Runtime.getRuntime().maxMemory() / 1024);
Log.d("TAG", "Max memory is " + maxMemory + "KB"); 因此在展示高分辨率图片的时候，最好先将图片进行压缩。压缩后的图片大小应该和用来展示它的控件大小相近，在一个很小的ImageView上显示一张超大的图片不会带来任何视觉上的好处，但却会占用我们相当多宝贵的内存，而且在性能上还可能会带来负面影响。下面我们就来看一看，如何对一张大图片进行适当的压缩，让它能够以最佳大小显示的同时，还能防止OOM的出现。
BitmapFactory这个类提供了多个解析方法(decodeByteArray, decodeFile, decodeResource等)用于创建Bitmap对象，我们应该根据图片的来源选择合适的方法。比如SD卡中的图片可以使用decodeFile方法，网络上的图片可以使用decodeStream方法，资源文件中的图片可以使用decodeResource方法。这些方法会尝试为已经构建的bitmap分配内存，这时就会很容易导致OOM出现。为此每一种解析方法都提供了一个可选的BitmapFactory.Options参数，将这个参数的inJustDecodeBounds属性设置为true就可以让解析方法禁止为bitmap分配内存，返回值也不再是一个Bitmap对象，而是null。虽然Bitmap是null了，但是BitmapFactory.Options的outWidth、outHeight和outMimeType属性都会被赋值。这个技巧让我们可以在加载图片之前就获取到图片的长宽值和MIME类型，从而根据情况对图片进行压缩。如下代码所示：
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; 为了避免OOM异常，最好在解析每张图片的时候都先检查一下图片的大小，除非你非常信任图片的来源，保证这些图片都不会超出你程序的可用内存。
现在图片的大小已经知道了，我们就可以决定是把整张图片加载到内存中还是加载一个压缩版的图片到内存中。以下几个因素是我们需要考虑的：
预估一下加载整张图片所需占用的内存。
为了加载这一张图片你所愿意提供多少内存。
用于展示这张图片的控件的实际大小。
当前设备的屏幕尺寸和分辨率。
比如，你的ImageView只有128*96像素的大小，只是为了显示一张缩略图，这时候把一张1024*768像素的图片完全加载到内存中显然是不值得的。
那我们怎样才能对图片进行压缩呢？
通过设置BitmapFactory.Options中inSampleSize的值就可以实现。比如我们有一张2048*1536像素的图片，将inSampleSize的值设置为4，就可以把这张图片压缩成512*384像素。原本加载这张图片需要占用13M的内存，压缩后就只需要占用0.75M了(假设图片是ARGB_8888类型，即每个像素点占用4个字节)。下面的方法可以根据传入的宽和高，计算出合适的inSampleSize值：
public static int calculateInSampleSize(BitmapFactory.Options options,
int reqWidth, int reqHeight) {
// 源图片的高度和宽度
final int height = options.outHeight;
final int width = options.outWidth;
int inSampleSize = 1;
if (height > reqHeight || width > reqWidth) {
// 计算出实际宽高和目标宽高的比率
final int heightRatio = Math.round((float) height / (float) reqHeight);
final int widthRatio = Math.round((float) width / (float) reqWidth);
// 选择宽和高中最小的比率作为inSampleSize的值，这样可以保证最终图片的宽和高
// 一定都会大于等于目标的宽和高。
inSampleSize = heightR atio < widthRatio ? heightRatio : widthRatio;
}
return inSampleSize;
} public static Bitmap decodeSampledBitmapFromResource(Resources res, int resId,
int reqWidth, int reqHeight) {
// 第一次解析将inJustDecodeBounds设置为true，来获取图片大小
final BitmapFactory.Options options = new BitmapFactory.Options();
options.inJustDecodeBounds = true;
BitmapFactory.decodeResource(res, resId, options);
// 调用上面定义的方法计算inSampleSize值
options.inSampleSize = calculateInSampleSize(options, reqWidth, reqHeight);
// 使用获取到的inSampleSize值再次解析图片
options.inJustDecodeBounds = false;
return BitmapFactory.decodeResource(res, resId, options);
}
下面的代码非常简单地将任意一张图片压缩成100*100的缩略图，并在ImageView上展示。
[java] view plaincopy
mImageView.setImageBitmap(
decodeSampledBitmapFromResource(getResources(), R.id.myimage, 100, 100));
在过去，我们经常会使用一种非常流行的内存缓存技术的实现，即软引用或弱引用 (SoftReference or WeakReference)。但是现在已经不再推荐使用这种方式了，因为从 Android 2.3 (API Level 9)开始，垃圾回收器会更倾向于回收持有软引用或弱引用的对象，这让软引用和弱引用变得不再可靠。另外，Android 3.0 (API Level 11)中，图片的数据会存储在本地的内存当中，因而无法用一种可预见的方式将其释放，这就有潜在的风险造成应用程序的内存溢出并崩溃。
为了能够选择一个合适的缓存大小给LruCache, 有以下多个因素应该放入考虑范围内，例如：
你的设备可以为每个应用程序分配多大的内存？
设备屏幕上一次最多能显示多少张图片？有多少图片需要进行预加载，因为有可能很快也会显示在屏幕上？
你的设备的屏幕大小和分辨率分别是多少？一个超高分辨率的设备（例如 Galaxy Nexus) 比起一个较低分辨率的设备（例如 Nexus S），在持有相同数量图片的时候，需要更大的缓存空间。
图片的尺寸和大小，还有每张图片会占据多少内存空间。
图片被访问的频率有多高？会不会有一些图片的访问频率比其它图片要高？如果有的话，你也许应该让一些图片常驻在内存当中，或者使用多个LruCache 对象来区分不同组的图片。
你能维持好数量和质量之间的平衡吗？有些时候，存储多个低像素的图片，而在后台去开线程加载高像素的图片会更加的有效。
并没有一个指定的缓存大小可以满足所有的应用程序，这是由你决定的。你应该去分析程序内存的使用情况，然后制定出一个合适的解决方案。一个太小的缓存空间，有可能造成图片频繁地被释放和重新加载，这并没有好处。而一个太大的缓存空间，则有可能还是会引起 java.lang.OutOfMemory 的异常。
下面是一个使用 LruCache 来缓存图片的例子：
private LruCache<String, Bitmap> mMemoryCache;
@Override
protected void onCreate(Bundle savedInstanceState) {
// 获取到可用内存的最大值，使用内存超出这个值会引起OutOfMemory异常。
// LruCache通过构造函数传入缓存值，以KB为单位。
int maxMemory = (int) (Runtime.getRuntime().maxMemory() / 1024);
// 使用最大可用内存值的1/8作为缓存的大小。
int cacheSize = maxMemory / 8;
mMemoryCache = new LruCache<String, Bitmap>(cacheSize) {
@Override
protected int sizeOf(String key, Bitmap bitmap) {
// 重写此方法来衡量每张图片的大小，默认返回图片数量。
return bitmap.getByteCount() / 1024;
}
};
}
public void addBitmapToMemoryCache(String key, Bitmap bitmap) {
if (getBitmapFromMemCache(key) == null) {
mMemoryCache.put(key, bitmap);
}
}
public Bitmap getBitmapFromMemCache(String key) {
return mMemoryCache.get(key);
} 在这个例子当中，使用了系统分配给应用程序的八分之一内存来作为缓存大小。在中高配置的手机当中，这大概会有4兆(32/8)的缓存空间。一个全屏幕的 GridView 使用4张 800x480分辨率的图片来填充，则大概会占用1.5兆的空间(800*480*4)。因此，这个缓存大小可以存储2.5页的图片。
当向 ImageView 中加载一张图片时,首先会在 LruCache 的缓存中进行检查。如果找到了相应的键值，则会立刻更新ImageView ，否则开启一个后台线程来加载这张图片。
public void loadBitmap(int resId, ImageView imageView) {
final String imageKey = String.valueOf(resId);
final Bitmap bitmap = getBitmapFromMemCache(imageKey);
if (bitmap != null) {
imageView.setImageBitmap(bitmap);
} else {
imageView.setImageResource(R.drawable.image_placeholder);
BitmapWorkerTask task = new BitmapWorkerTask(imageView);
task.execute(resId);
}
}
BitmapWorkerTask 还要把新加载的图片的键值对放到缓存中。
class BitmapWorkerTask extends AsyncTask<Integer, Void, Bitmap> {
// 在后台加载图片。
@Override
protected Bitmap doInBackground(Integer... params) {
final Bitmap bitmap = decodeSampledBitmapFromResource(
getResources(), params[0], 100, 100);
addBitmapToMemoryCache(String.valueOf(params[0]), bitmap);
return bitmap;
}
} 掌握了以上两种方法，不管是要在程序中加载超大图片，还是要加载大量图片，都不用担心OOM的问题了!
另外需要注意的是：没有必要使用硬件加速的界面建议关掉硬件加速
通过DDMS的heap跟踪发现，相比于关闭硬件加速，在打开硬件加速的情况下会消耗更多的内存，但有的界面打开或者关闭硬件加速对程序的运行效率并没有太大的影响，此种情况下可以考虑在AndroidManifest.xml文件中关闭掉对应Activity的硬件加速
<!-- 设置界面 -->
<activity
android:name=".SettingActivity"
android:hardwareAccelerated="false"
android:screenOrientation="sensorLandscape"
android:theme="@style/Translucent_NoTitle">
</activity>如果Activity中某个View需要关闭硬件加速，但整个Activity不能关闭，可以调用view层级关闭硬件加速的方法：
// view.setLayerType || 在定义view的构造方法中调用该方法
setLayerType(View.LAYER_TYPE_SOFTWARE, null);AnimationDrawable也是一个耗内存大户，图片帧数越多耗内存越大，具体可以查看AnimationDrawable的源码，在AnimationDrawable实例化的时候，Drawable的createFromXmlInner方法会调用AnimationDrawable的inflate方法，该方法里面有一个while循环去一次性将所有帧都读取出来，也就是在初始化的时候就将所有的帧读在内存中了，有多少张图片，它就要消耗对应大小的内存。
虽然可以通过如下方式释放AnimationDrawable占用的内存，但是当退出使用AnimationDrawable的界面，再次进入使用其播放动画时，会报使用已经回收了的图片的异常，这个应该是Android对图片的处理机制导致的，虽然Activity被finish掉了，但是这个Activity中使用到的图片还是在内存中，如果被回收，下次进入时就会报异常信息：
通常情况下我会自定义一个ImageView来实现AnimationDrawable的功能，根据图片之间切换的时间间隔来定时设置ImageView的背景图片，这样始终只是一个ImageView实例，更换的只是其背景，占用内存会比AnimationDrawable小很多：
/**
* 图片动态切换器
*
* */
public class AnimImageView {
private static final int MSG_START = 0xf1;
private static final int MSG_STOP = 0xf2;
private static final int STATE_STOP = 0xf3;
private static final int STATE_RUNNING = 0xf4;
/* 运行状态*/
private int mState = STATE_RUNNING;
private ImageView mImageView;
/* 图片资源ID列表*/
private List<Integer> mResourceIdList = null;
/* 定时任务*/
private Timer mTimer = null;
private AnimTimerTask mTimeTask = null;
/* 记录播放位置*/
private int mFrameIndex = 0;
/* 播放形式*/
private boolean isLooping = false;
public AnimImageView( ){
mTimer = new Timer();
}
/**
* 设置动画播放资源
*
* */
public void setAnimation( HanziImageView imageview, List<Integer> resourceIdList ){
mImageView = imageview;
mResourceIdList = resourceIdList;
}
/**
* 开始播放动画
* @param loop 时候循环播放
* @param duration 动画播放时间间隔
* */
public void start(boolean loop, int duration){
stop();
isLooping = loop;
mFrameIndex = 0;
mState = STATE_RUNNING;
mTimeTask = new AnimTimerTask( );
mTimer.schedule(mTimeTask, 0, duration);
}
/**
* 停止动画播放
*
* */
public void stop(){
if (mTimeTask != null) {
mFrameIndex = 0;
mState = STATE_STOP;
mTimer.purge();
mTimeTask.cancel();
mTimeTask = null;
mImageView.setBackgroundResource(0);
}
}
/**
* 定时器任务
*
*
*/
class AnimTimerTask extends TimerTask {
@Override
public void run() {
if(mFrameIndex < 0 || mState == STATE_STOP){
return;
}
if( mFrameIndex < mResourceIdList.size() ){
Message msg = AnimHanlder.obtainMessage(MSG_START,0,0,null);
msg.sendToTarget();
}else{
mFrameIndex = 0;
if(!isLooping){
Message msg = AnimHanlder.obtainMessage(MSG_STOP,0,0,null);
msg.sendToTarget();
}
}
}
}
private Handler AnimHanlder = new Handler(){
public void handleMessage(android.os.Message msg) {
switch (msg.what) {
case MSG_START:{
if(mFrameIndex >=0 && mFrameIndex < mResourceIdList.size() && mState == STATE_RUNNING){
mImageView.setImageResource(mResourceIdList.get(mFrameIndex));
mFrameIndex++;
}
}
break;
case MSG_STOP:{
if (mTimeTask != null) {
mFrameIndex = 0;
mTimer.purge();
mTimeTask.cancel();
mState = STATE_STOP;
mTimeTask = null;
mImageView.setImageResource(0);
}
}
break;
default:
break;
}
}
};
}1、尽量将Activity中的小图片和背景合并，一张小图片既浪费布局的时间，又平白地增加了内存占用；
2、不要在Activity的主题中为Activity设置默认的背景图片，这样会导致Activity占用的内存翻倍：
<!--千万不要在主题中为Activity设置默认背景
<style name="Activity_Style" parent="@android:Theme.Holo.Light.NoActionBar">
<item name="android:background">@drawable/*</item>
</style>
扫一扫
959
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
