MessageDigest
http://blog.csdn.net/hudashi/article/details/8394158
用于为应用程序提供信息摘要算法的功能，如 MD5 或 SHA 算法。简单点说就是用于生成散列码。信息摘要是安全的单向哈希函数，它接收任意大小的数据，输出固定长度的哈希值。
MessageDigest 通过其getInstance系列静态函数来进行实例化和初始化。MessageDigest 对象通过使用 update 方法处理数据。任何时候都可以调用 reset方法重置摘要。一旦所有需要更新的数据都已经被更新了，应该调用 digest 方法之一完成哈希计算并返回结果。
对于给定数量的更新数据，digest方法只能被调用一次。digest
方法被调用后，MessageDigest 对象被重新设置成其初始状态。
LinkedBlockingDeque：双向并发阻塞队列
http://www.tuicool.com/articles/AfIv6v
从数据结构和功能需求上可以得到以下结论：
1.要想支持阻塞功能，队列的容量一定是固定的，否则无法在入队的时候挂起线程。也就是capacity是final类型的。
2.既然是双向链表，每一个结点就需要前后两个引用，这样才能将所有元素串联起来，支持双向遍历。也即需要prev/next两个引用。
3.双向链表需要头尾同时操作，所以需要first/last两个节点，当然可以参考LinkedList那样采用一个节点的双向来完成，那样实现起来就稍微麻烦点。
4.既然要支持阻塞功能，就需要锁和条件变量来挂起线程。这里使用一个锁两个条件变量来完成此功能。
有了上面的结论再来研究LinkedBlockingDeque的优缺点。
1.优点当然是功能足够强大，同时由于采用一个独占锁，因此实现起来也比较简单。所有对队列的操作都加锁就可以完成。同时独占锁也能够很好的支持双向阻塞的特性。
2.凡事有利必有弊。缺点就是由于独占锁，所以不能同时进行两个操作，这样性能上就大打折扣。从性能的角度讲LinkedBlockingDeque要比LinkedBlockingQueue要低很多，比CocurrentLinkedQueue就低更多了，这在高并发情况下就比较明显了
LIFOLinkedBlockingDeque
后进先出阻塞队列。重写LinkedBlockingDeque的offer(…)函数如下：
public boolean offer(T e) {
return super.offerFirst(e);
}
让LinkedBlockingDeque插入总在最前，而remove()本身始终删除第一个元素，所以就变为了后进先出阻塞队列。
ThreadPoolExecutor
http://825635381.iteye.com/blog/2184680
ThreadPoolExecutor(int corePoolSize,
int maximumPoolSize,
long keepAliveTime,
TimeUnit unit,
BlockingQueue<Runnable> workQueue,
ThreadFactory threadFactory,
RejectedExecutionHandler handler)
corePoolSize： 线程池维护线程的最少数量
maximumPoolSize：线程池维护线程的最大数量
keepAliveTime： 线程池维护线程所允许的空闲时间
unit： 线程池维护线程所允许的空闲时间的单位
workQueue： 线程池所使用的缓冲队列
threadFactory:新建线程工厂（继承ThreadFactory）
handler： 线程池对拒绝任务的处理策略
AtomicInteger
http://blog.csdn.net/u012734441/article/details/51619751
AtomicInteger介绍
AtomicInteger是一个提供原子操作的Integer类，通过线程安全的方式操作加减。
AtomicInteger使用场景
AtomicInteger提供原子操作来进行Integer的使用，因此十分适合高并发情况下的使用
LinkedHashMap
http://www.cnblogs.com/yejg1212/archive/2013/04/01/2992921.html
http://blog.csdn.net/ns_code/article/details/37867985
非线程安全的，只在单线程环境下使用
public LinkedHashMap(
int initialCapacity, float loadFactor, boolean accessOrder)
参数说明：
initialCapacity 初始容量大小，使用无参构造方法时，此值默认是16
loadFactor 加载因子，使用无参构造方法时，此值默认是 0.75f
accessOrder false： 基于插入顺序 true： 基于访问顺序 （基于访问的顺序，get一个元素后，这个元素被加到最后(使用了LRU 最近最少被使用的调度算法)）
以下BaseImageDownloader.java
**Android 中的MimeType与MimeTypeMap **
Android中MimeType的用途
Intent-Filter中的<data>有一个mimeType . 它的作用是告诉Android系统本Activity可以处理的文件的类型。如设置为 “text/plain”表示可以处理“.txt”文件。
MimeTypeMap类
MimeTypeMap类是专门处理mimeType的类
** ThumbnailUtils工具类来是实现缩略图**
Bitmap createVideoThumbnail(String filePath, int kind)
创建一张视频的缩略图。如果视频已损坏或者格式不支持可能返回null
Bitmap extractThumbnail(Bitmap source, int width, int height, int options)
创建所需尺寸居中缩放的位图。
参数： source： 需要被创造缩略图的源位图对象
width： 生成目标的宽度
height： 生成目标的高度
options：在缩略图抽取时提供的选项
bitmap.compress(Bitmap.CompressFormat.JPEG, 30, baos);//30 是压缩率，表示压缩70%; 如果不压缩是100，表示压缩率为0
Uri.parse(string)
通用资源标志符（Universal Resource Identifier, 简称"URI"）。Uri代表要操作的数据，Android上可用的每种资源 - 图像、视频片段等都可以用Uri来表示。Android平台而言，URI主要分三个部分：
scheme
authority
path
其中authority又分为host和port。格式如下：
scheme://host:port/path
实际的例子：
我们很经常需要解析Uri，并从Uri中获取数据。Android系统提供了两个用于操作Uri的工具类，分别为UriMatcher 和ContentUris
Uri uri = Uri.parse("macappstores://itunes.apple.com:80/us/app/xcode/id497799835?mt=12#retry");
String scheme = uri.getScheme();//macappstores
int port = uri.getPort();//80
String host = uri.getHost();//itunes.apple.com
String path = uri.getPath();//us/app/xcode/id497799835
List<String > a = uri.getPathSegments();//{"us","app","xcode","id497799835"}
String last = uri.getLastPathSegment();//id497799835
String mt = uri.getQueryParameter("mt");//12
String authority = uri.getAuthority();//itunes.apple.com:80
String fragment = uri.getFragment();//retry
Android之MediaStore
我们经常会使用MediaStore来获取手机的音频、图片、视频等相关信息。下面3个是常见的内部类：
MediaStore.Audio获取音频信息的类
MediaStore.Images获取图片信息
MediaStore.Video获取视频信息
