惠州哪家做网站好,wordpress升级注意,石家庄网络公司有哪些,上海网站建设案例原文地址#xff1a;http://android.xsoftlab.net/training/displaying-bitmaps/cache-bitmap.html
往UI界面中加载单张图片的过程是很简单的#xff0c;然而如果需要在某个时刻同时加载大量的图片#xff0c;那么这事情就有些复杂了。在很多情况下#xff0c;比如使用了L…原文地址http://android.xsoftlab.net/training/displaying-bitmaps/cache-bitmap.html
往UI界面中加载单张图片的过程是很简单的然而如果需要在某个时刻同时加载大量的图片那么这事情就有些复杂了。在很多情况下比如使用了ListView、GridView或者是ViewPager来展示一定数量的图片在本质上这些情况下屏幕的快速滑动会导致大量的图片被集中展示在屏幕上。
类似这样通过回收移除到屏幕之外的子View的组件会抑制内存的使用(也就是说它们本身不会滥用内存)。垃圾回收器还会释放你所加载的位图假设你没有使用任何持久化引用的话。这真是极好的但是为了保持流畅的UI效果你可能需要在它们每次重新返回到屏幕的时候对它们按照常规的方式重新处理。内存缓存及磁盘缓存可以在这里提供帮助可以使这些组件快速的重新加载已经处理过的图片。
这节课将会讨论在加载多张图片的时候如何通过使用内存缓存以及磁盘缓存来使UI界面更加流畅响应速度更快。
使用内存缓存
内存缓存提供了一种快速访问位图的能力不过这会花费宝贵的内存空间。类LruCache极其适合用来处理缓存图片的任务它会将最近使用到的位图的引用存放在一个LinkedHashMap对象上并会在超过内存设计大小之前将最后一个没有用到的成员给驱除。 Note: 在过去使用SoftReference或者是WeakReference来缓存图片是最受欢迎的一种缓存方式然而却并不推荐这么用。在Android 2.3之后垃圾回收器对soft/weak引用的回收更加强制这会使得这些引用几乎无效。此外在Android 3.0之前位图的字节数据被存储在本地内存中可以预见这些数据是不会被释放的这会导致程序很容易超过自身的内存限制然后崩溃。 为了给LruCache选择合适的尺寸有几个因素应该被考虑在内
Activity或者程序在常规状态下的内存使用量是多少?在同一时间最多会有多少图片集中显示在屏幕上?有多少内存需要为准备显示到屏幕上的图片所用?设备屏幕的大小和尺寸分别是多少?在加载相同图片数量的情况下像Galaxy Nexus这种超高的密度(xhdpi)的设备与Nexus S(hdpi)相比则需要更大的内存。图片的尺寸多大?配置是什么?加载这个位图的时候需要花费的内存是多少?图片的访问有多频繁?会比其它位图访问更频繁吗?如果是这样可能你需要将它们永远保持在内存中了或者甚至是有多个LruCache对象来为图片分组。你可以在数量与质量之间取得平衡吗?某些时候存储大量的低质图片是很有用处的可能会潜在的存在一些后台任务来加载一些高质量的版本。
这里特别没有指定尺寸或者配置不过这适用所有的应用程序这取决于对内存使用情况的分析并需要找到一个适合的解决方案。缓存设置的太小会导致无意义的额外开销缓存设置的太大会再次引起java.lang.OutOfMemory异常应该将大小设置为应用的常规内存使用量之外的剩余内存之间。
下面是使用LruCache缓存位图的一个例子
private LruCacheString, Bitmap mMemoryCache;
Override
protected void onCreate(Bundle savedInstanceState) {...// Get max available VM memory, exceeding this amount will throw an// OutOfMemory exception. Stored in kilobytes as LruCache takes an// int in its constructor.final int maxMemory (int) (Runtime.getRuntime().maxMemory() / 1024);// Use 1/8th of the available memory for this memory cache.final int cacheSize maxMemory / 8;mMemoryCache new LruCacheString, Bitmap(cacheSize) {Overrideprotected int sizeOf(String key, Bitmap bitmap) {// The cache size will be measured in kilobytes rather than// number of items.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);
} Note: 在这个例子中有八分之一的内存被分配给了缓存。在正常的设备上(hdpi)这大概是4MB(32/8)左右。一个铺满了图片的GridView在全屏状态下的800*480的设备上所占的内存大概是1.5MB(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) {mImageView.setImageBitmap(bitmap);} else {mImageView.setImageResource(R.drawable.image_placeholder);BitmapWorkerTask task new BitmapWorkerTask(mImageView);task.execute(resId);}
}
BitmapWorkerTask中也需要对内存缓存进行添加或更新:
class BitmapWorkerTask extends AsyncTaskInteger, Void, Bitmap {...// Decode image in background.Overrideprotected Bitmap doInBackground(Integer... params) {final Bitmap bitmap decodeSampledBitmapFromResource(getResources(), params[0], 100, 100));addBitmapToMemoryCache(String.valueOf(params[0]), bitmap);return bitmap;}...
}
使用磁盘缓存
内存缓存对于最近浏览过的图像的快速加载非常有用然而却不能将所有的图像都存放在内存缓存中。像GridView这样的组件在加载大数据集的时候可以轻易的将内存缓存填满。程序在运行的过程中可能会被其它任务打断比如一个来电这时在后台的任务可能就会被杀死内存缓存也会被销毁。一旦用户返回了界面那么程序就需要再次重新处理每张图片。
那么磁盘缓存在这些情况下就很有帮助了它可以存储处理过的图片并会辅助提升图片的加载时间在图片不再在内存缓存中存在的时候。当然在磁盘上获取一张图片要比内存中要慢并且还需要开启单独的工作线程这和从磁盘上读取数据的时间一样都不可预估。 Note:ContentProvider可能更适合用来存放被缓存过的图像如果这些图像的访问更加频繁的话就像在相册应用中的情况一样。 从Android Source中更新的示例代码使用了一个DiskLruCache的实现。下面是个更新后的版本它对已有的内存缓存增加了磁盘缓存
private DiskLruCache mDiskLruCache;
private final Object mDiskCacheLock new Object();
private boolean mDiskCacheStarting true;
private static final int DISK_CACHE_SIZE 1024 * 1024 * 10; // 10MB
private static final String DISK_CACHE_SUBDIR thumbnails;
Override
protected void onCreate(Bundle savedInstanceState) {...// Initialize memory cache...// Initialize disk cache on background threadFile cacheDir getDiskCacheDir(this, DISK_CACHE_SUBDIR);new InitDiskCacheTask().execute(cacheDir);...
}
class InitDiskCacheTask extends AsyncTaskFile, Void, Void {Overrideprotected Void doInBackground(File... params) {synchronized (mDiskCacheLock) {File cacheDir params[0];mDiskLruCache DiskLruCache.open(cacheDir, DISK_CACHE_SIZE);mDiskCacheStarting false; // Finished initializationmDiskCacheLock.notifyAll(); // Wake any waiting threads}return null;}
}
class BitmapWorkerTask extends AsyncTaskInteger, Void, Bitmap {...// Decode image in background.Overrideprotected Bitmap doInBackground(Integer... params) {final String imageKey String.valueOf(params[0]);// Check disk cache in background threadBitmap bitmap getBitmapFromDiskCache(imageKey);if (bitmap null) { // Not found in disk cache// Process as normalfinal Bitmap bitmap decodeSampledBitmapFromResource(getResources(), params[0], 100, 100));}// Add final bitmap to cachesaddBitmapToCache(imageKey, bitmap);return bitmap;}...
}
public void addBitmapToCache(String key, Bitmap bitmap) {// Add to memory cache as beforeif (getBitmapFromMemCache(key) null) {mMemoryCache.put(key, bitmap);}// Also add to disk cachesynchronized (mDiskCacheLock) {if (mDiskLruCache ! null mDiskLruCache.get(key) null) {mDiskLruCache.put(key, bitmap);}}
}
public Bitmap getBitmapFromDiskCache(String key) {synchronized (mDiskCacheLock) {// Wait while disk cache is started from background threadwhile (mDiskCacheStarting) {try {mDiskCacheLock.wait();} catch (InterruptedException e) {}}if (mDiskLruCache ! null) {return mDiskLruCache.get(key);}}return null;
}
// Creates a unique subdirectory of the designated app cache directory. Tries to use external
// but if not mounted, falls back on internal storage.
public static File getDiskCacheDir(Context context, String uniqueName) {// Check if media is mounted or storage is built-in, if so, try and use external cache dir// otherwise use internal cache dirfinal String cachePath Environment.MEDIA_MOUNTED.equals(Environment.getExternalStorageState()) ||!isExternalStorageRemovable() ? getExternalCacheDir(context).getPath() :context.getCacheDir().getPath();return new File(cachePath File.separator uniqueName);
} Note:因为磁盘缓存的初始化需要磁盘操作所以这个过程不应该放在UI线程中执行。然而这也意味着在缓存初始化之前这是个访问的机会。为了做到这一点需要有个lock对象来保证在缓存被初始化之前APP没有从磁盘缓存中读取数据。 内存缓存在UI线程中执行检查磁盘缓存在后台线程中执行检查。磁盘操作绝不应该放入UI线程。当图像处理完毕后最终被处理过的图片应当被添加到内存缓存及磁盘缓存中以便备用。
处理配置变更
如果在运行时发生了变更比如屏幕的方向发生了改变会引起Android销毁并重启运行中的Activity你可能想要避免再一次处理图像这样一旦配置发生了改变可以使用户有一个流畅快速的用户体验。
幸运的是你有一个非常赞的内存缓存方案可以使用设置了setRetainInstance(true)的Fragment它可以将缓存传入新的Activity实例。在activity重新创建的时候这个被保留存在的Fragment会被重新附加在Activity上你可以获得原先内存缓存的访问能力这使得图像可以快速的被获得并被重新填充在ImageView对象中。
下面这个例子使用了引用LruCache的Fragment并通过了配置更改的问题
private LruCacheString, Bitmap mMemoryCache;
Override
protected void onCreate(Bundle savedInstanceState) {...RetainFragment retainFragment RetainFragment.findOrCreateRetainFragment(getFragmentManager());mMemoryCache retainFragment.mRetainedCache;if (mMemoryCache null) {mMemoryCache new LruCacheString, Bitmap(cacheSize) {... // Initialize cache here as usual}retainFragment.mRetainedCache mMemoryCache;}...
}
class RetainFragment extends Fragment {private static final String TAG RetainFragment;public LruCacheString, Bitmap mRetainedCache;public RetainFragment() {}public static RetainFragment findOrCreateRetainFragment(FragmentManager fm) {RetainFragment fragment (RetainFragment) fm.findFragmentByTag(TAG);if (fragment null) {fragment new RetainFragment();fm.beginTransaction().add(fragment, TAG).commit();}return fragment;}Overridepublic void onCreate(Bundle savedInstanceState) {super.onCreate(savedInstanceState);setRetainInstance(true);}
}
为了测试这项输出试着在有和没有Fragment的情况下旋转设备。你应该会注意到这个过程几乎没有延迟。任何图像如果没有在内存缓存中找到那么这就为磁盘缓存提供了用武之地如果都没有的话那么常规的处理方法就会出场。
