android缓存池
‘壹’ Android性能优化总结
常用的Android性能优化方法：
一、布局优化：
1）尽量减少布局文件的层级。
层级少了，绘制的工作量也就少了，性能自然提高。
2）布局重用 <include标签>
3）按需加载：使用ViewStub,它继承自View,一种轻量级控件，本身不参与任何的布局和绘制过程。他的layout参数里添加一个替换的布局文件，当它通过setVisibility或者inflate方法加载后，它就会被内部布局替换掉。
二、绘制优化：
基于onDraw会被调用多次，该方法内要避免两类操作：
1）创建新的局部对象，导致大量垃圾对象的产生，从而导致频繁的gc，降低程序的执行效率。
2）不要做耗时操作，抢CPU时间片，造成绘制很卡不流畅。
三、内存泄漏优化：
1）静态变量导致内存泄漏 比较明显
2）单例模式导致的内存泄漏 单例无法被垃圾回收，它持有的任何对象的引用都会导致该对象不会被gc。
3）属性动画导致内存泄漏 无限循环动画，在activity中播放，但是onDestroy时没有停止的话，动画会一直播放下去，view被动画持有，activity又被view持有，导致activity无法被回收。
四、响应速度优化：
1）避免在主线程做耗时操作 包括四大组件，因为四大组件都是运行在主线程的。
2）把一些创建大量对象等的初始化工作放在页面回到前台之后，而不应该放到创建的时候。
五、ListView的优化：
1）使用convertView，走listView子View回收的一套：RecycleBin 机制
主要是维护了两个数组，一个是mActiveViews,当前可见的view,一个是mScrapViews，当前不可见的view。当触摸ListView并向上滑动时，ListView上部的一些OnScreen的View位置上移，并移除了ListView的屏幕范围，此时这些OnScreen的View就变得不可见了，不可见的View叫做OffScreen的View，即这些View已经不在屏幕可见范围内了，也可以叫做ScrapView，Scrap表示废弃的意思，ScrapView的意思是这些OffScreen的View不再处于可以交互的Active状态了。ListView会把那些ScrapView（即OffScreen的View）删除，这样就不用绘制这些本来就不可见的View了，同时，ListView会把这些删除的ScrapView放入到RecycleBin中存起来，就像把暂时无用的资源放到回收站一样。
当ListView的底部需要显示新的View的时候，会从RecycleBin中取出一个ScrapView，将其作为convertView参数传递给Adapter的getView方法，从而达到View复用的目的，这样就不必在Adapter的getView方法中执行LayoutInflater.inflate()方法了。
RecycleBin中有两个重要的View数组，分别是mActiveViews和mScrapViews。这两个数组中所存储的View都是用来复用的，只不过mActiveViews中存储的是OnScreen的View，这些View很有可能被直接复用；而mScrapViews中存储的是OffScreen的View，这些View主要是用来间接复用的。
2）使用ViewHolder避免重复地findViewById
3)快速滑动不适合做大量异步任务，结合滑动监听，等滑动结束之后加载当前显示在屏幕范围的内容。
4）getView中避免做耗时操作，主要针对图片：ImageLoader来处理(原理：三级缓存)
5）对于一个列表，如果刷新数据只是某一个item的数据，可以使用局部刷新，在列表数据量比较大的情况下，节省不少性能开销。
六、Bitmap优化：
1）减少内存开支：图片过大，超过控件需要的大小的情况下，不要直接加载原图，而是对图片进行尺寸压缩，方式是BitmapFactroy.Options 采样，inSampleSize 转成需要的尺寸的图片。
2）减少流量开销：对图片进行质量压缩，再上传服务器。图片有三种存在形式：硬盘上时是file，网络传输时是stream，内存中是stream或bitmap，所谓的质量压缩，它其实只能实现对file的影响，你可以把一个file转成bitmap再转成file，或者直接将一个bitmap转成file时，这个最终的file是被压缩过的，但是中间的bitmap并没有被压缩。bitmap.compress(Bitmap.CompressFormat.PNG,100,bos);
七、线程优化：
使用线程池。为什么要用线程池？
1、从“为每个任务分配一个线程”转换到“在线程池中执行任务”
2、通过重用现有的线程而不是创建新线程，可以处理多个请求在创建销毁过程中产生的巨大开销
3、当使用线程池时，在请求到来时间 ，不用等待系统重新创建新的线程，而是直接复用线程池中的线程，这样可以提高响应性。
4、通过和适当调整线程池的大小 ，可以创建足够多的线程以使处理器能够保持忙碌状态，同时还可以防止过多线程相互竞争资源而使应用程序耗尽内存或者失败。
5、一个App里面所有的任务都放在线程池中执行后，可以统一管理 ，当应用退出时，可以把程序中所有的线程统一关闭，避免了内存和CPU的消耗。
6、如果这个任务是一个循环调度任务，你则必须在这个界面onDetach方法把这个任务给cancel掉，如果是一个普通任务则可cancel，可不cancel，但是最好cancel
7、整个APP的总开关会在应用退出的时间把整个线程池全部关闭。
八、一些性能优化建议：
1）避免创建过多对象，造成频繁的gc
2)不要过多使用枚举，枚举占用的空间比整型大很多
3）字符串的拼接使用StringBuffer、StringBuilder来替代直接使用String,因为使用String会创建多个String对象，参考第一条。
4）适当使用软引用，（弱引用就不太推荐了）
5）使用内存缓存和磁盘缓存。
‘贰’ 谈谈RecyclerView中的缓存
Android深入理解RecyclerView的缓存机制
RecyclerView在项目中的使用已经很普遍了，可以说是项目中最高频使用的一个控件了。除了布局灵活性、丰富的动画，RecyclerView还有优秀的缓存机制，本文尝试通过源码深入了解一下RecyclerView中的缓存机制。
RecyclerView做性能优化要说复杂也复杂，比如说布局优化，缓存，预加载等等。其优化的点很多，在这些看似独立的点之间，其实存在一个枢纽：Adapter。因为所有的ViewHolder的创建和内容的绑定都需要经过Adaper的两个函数onCreateViewHolder和onBindViewHolder。
因此我们性能优化的本质就是要减少这两个函数的调用时间和调用的次数。如果我们想对RecyclerView做性能优化，必须清楚的了解到我们的每一步操作背后，onCreateViewHolder和onBindViewHolder调用了多少次。因此，了解RecyclerView的缓存机制是RecyclerView性能优化的基础。
为了理解缓存的应用场景，本文首先会简单介绍一下RecyclerView的绘制原理，然后再分析其缓存实现原理。
RecyclerView滑动时会触发onTouchEvent#onMove，回收及复用ViewHolder在这里就会开始。我们知道设置RecyclerView时需要设置LayoutManager,LayoutManager负责RecyclerView的布局，包含对ItemView的获取与复用。以LinearLayoutManager为例，当RecyclerView重新布局时会依次执行下面几个方法：
上述的整个调用链：onLayoutChildren()->fill()->layoutChunk()->next()->getViewForPosition(),getViewForPosition()即是是从RecyclerView的回收机制实现类Recycler中获取合适的View，下面主要就来从看这个Recycler#getViewForPosition()的实现。
上述逻辑用流程图表示：
RecyclerView在Recyler里面实现ViewHolder的缓存，Recycler里面的实现缓存的主要包含以下5个对象：
public final class Recycler {
final ArrayList mAttachedScrap = new ArrayList<>();
ArrayList mChangedScrap = null;
RecyclerView在设计的时候讲上述5个缓存对象分为了3级。每次创建ViewHolder的时候，会按照优先级依次查询缓存创建ViewHolder。每次讲ViewHolder缓存到Recycler缓存的时候，也会按照优先级依次缓存进去。三级缓存分别是：
使用自定义ViewCacheExtension后，view离屏后再回来不会走onBindViewHolder()方法。
holder.setIsRecyclable(false)，这样的话每次都会走onCreateViewHolder()和onBindViewHolder()方法
1.提前初始化viewHolder，放到缓存池中
viewPool.putRecycledView(adapter.onCreateViewHolder(recyclerView, 1))
2.提前初始化view，在onCreateViewHolder的时候去取view
3.自定义ViewCacheExtension
4.适当的增加cacheSize
4.公用缓存池，比如多个viewPager+fragment场景使用，或者全局单利缓存池，感觉用户不大。
有2中做法有值
第一种
第二种
不会，因为prefetch（GapWorker中的一个方法）之后mViewCacheMax会变成mRequestedCacheMax + extraCache
有2种方式可以让缓存失效
第一种
recyclerView.setItemViewCacheSize(-1)
第二种
recyclerView.setItemViewCacheSize(0)
layoutManager.isItemPrefetchEnabled = false
设置不缓存后，来回滑动让view进入屏幕离开屏幕，viewHolder的item时会多次走onBindViewHolder()方法。
‘叁’ RecyclerView缓存原理及优化方向
Android新增的Recyclerview主要用于代替ListView。Recyclerview可扩展性强。
RecyclerView做性能优化要说复杂也复杂，比如说布局优化，缓存，预加载等等。
其优化的点很多，在这些看似独立的点之间，其实存在一个枢纽：Adapter。
因为所有的ViewHolder的创建和内容的绑定都需要经过Adaper的两个函数 onCreateViewHolder和onBindViewHolder 。
因此我们性能优化的本质就是要 **减少这两个函数的调用时间和调用的次数** 。
如果我们想对RecyclerView做性能优化，必须清楚的了解到我们的每一步操作背后，onCreateViewHolder和onBindViewHolder调用了多少次。
因此，了解RecyclerView的缓存机制是RecyclerView性能优化的基础。
为了简化问题，绘制原理介绍提供以下假设：
（1）类的职责介绍
LayoutManager：接管RecyclerView的Measure，Layout，Draw的过程
Recycler：缓存池
Adapter：ViewHolder的生成器和内容绑定器。
（2）绘制过程简介
RecyclerView缓存基本上是通过三个内部类管理的， Recycler 、 RecycledViewPool 和 ViewCacheExtension 。
Recycler
用于管理已经废弃或者与RecyclerView分离的ViewHolder，为了方便理解这个类，整理了下面的资料，内部类的成员变量和他们的含义：
RecycledViewPool
RecycledViewPool类是用来缓存Item用，是一个ViewHolder的缓存池，如果多个RecyclerView之间用 setRecycledViewPool(RecycledViewPool) 设置同一个RecycledViewPool，他们就可以共享Item。
其实RecycledViewPool的内部维护了一个Map，里面以不同的viewType为Key存储了各自对应的ViewHolder集合。可以通过提供的方法来修改内部缓存的Viewholder。
ViewCacheExtension
开发者可自定义的一层缓存，是虚拟类ViewCacheExtension的一个实例，开发者可实现方法getViewForPositionAndType(Recycler recycler, int position, int type)来实现自己的缓存。
屏幕内缓存指在屏幕中显示的ViewHolder，这些ViewHolder会缓存在mAttachedScrap、mChangedScrap中 ：
当列表滑动出了屏幕时，ViewHolder会被缓存在 mCachedViews ，其大小由mViewCacheMax决定，默认DEFAULT_CACHE_SIZE为2，可通过Recyclerview.setItemViewCacheSize()动态设置。
可以自己实现ViewCacheExtension类实现自定义缓存，可通过Recyclerview.setViewCacheExtension()设置。
ViewHolder在首先会缓存在 mCachedViews 中，当超过了个数（比如默认为2）， 就会添加到 RecycledViewPool 中。
在有限的mCachedViews中如果存不下ViewHolder时，就会把ViewHolder存入RecyclerViewPool中。
* 按照Type来查找ViewHolder
* 每个Type默认最多缓存5个
RecycledViewPool 会根据每个ViewType把ViewHolder分别存储在不同的列表中，每个ViewType最多缓存DEFAULT_MAX_SCRAP = 5 个ViewHolder，如果RecycledViewPool没有被多个RecycledView共享，对于线性布局，每个ViewType最多只有一个缓存，如果是网格有多少行就缓存多少个。
Recyclerview在获取ViewHolder时按四级缓存的顺序查找，如果没找到就创建。其中只有RecycledViewPool找到时才会调用 bindViewHolder，其它缓存不会重新bindViewHolder 。
通过了解RecyclerView的四级缓存，我们可以知道，RecyclerView最多可以缓存 N（屏幕最多可显示的item数） + 2 (屏幕外的缓存) + 5*M (M代表M个ViewType，缓存池的缓存)，只有RecycledViewPool找到时才会重新调用 bindViewHolder。
RecyclerView在Recyler里面实现ViewHolder的缓存，Recycler里面的实现缓存的主要包含以下5个对象：
RecyclerView在设计的时候讲上述5个缓存对象分为了3级。
每次创建ViewHolder的时候，会按照优先级依次查询缓存创建ViewHolder 。
三级缓存分别是：
RecyclerView缓存原理，有图有真相
关于Recyclerview的缓存机制的理解
‘肆’ android开发三大框架
XUtil框架、volley、ImageLoader框架。XUtil框架：Android中的orm框架，一行代码就可以进行增删改查；支持事务，默认关闭；可通过注解自定型行誉义表名，列名，外键，唯一性约束，NOT NULL约束，CHECK约束等（需要混淆的时候请注解表名和列名）。 
XUtil框架、volley、ImageLoader框架。
1、XUtil框架：
主要有四大模块：
（1） 数据库模块：Android中的orm框架，一行代码就可以进行增删改查；支持事务，默认关闭；可通过注解自定义表名，列名，外键，唯一性约束，NOT NULL约束，CHECK约束等（需要混淆的时候请注解表名和列名）；支持绑定外键，保存实体时外键关联实体自动保存或更新；自动加载外键关联实体，支持延时加载；支持链式表达查询，更直观的查询语义，参考下面的介绍或sample中的例子。
（2）注解模块卜段：android中的ioc框架，完全注解带做方式就可以进行UI，资源和事件绑定；新的事件绑定方式，使用混淆工具混淆后仍可正常工作；目前支持常用的20种事件绑定，参见ViewCommonEventListener类和包com.lidroid.xutils.view.annotation.event。
（3）网络模块：支持同步，异步方式的请求；支持大文件上传，上传大文件不会oom；支持GET，POST，PUT，MOVE，COPY，DELETE，HEAD，OPTIONS，TRACE，CONNECT请求；下载支持301/302重定向，支持设置是否根据Content-Disposition重命名下载的文件；返回文本内容的请求（默认只启用了GET请求）支持缓存，可设置默认过期时间和针对当前请求的过期时间。
（4）图片缓存模块：加载bitmap的时候无需考虑bitmap加载过程中出现的oom和android容器快速滑动时候出现的图片错位等现象；支持加载网络图片和本地图片；内存管理使用lru算法，更好的管理bitmap内存；可配置线程加载线程数量，缓存大小，缓存路径，加载显示动画等…
2、volley：JSON，图像等的异步下载；网络请求的排序（scheling）网络请求的优先级处理缓存多级别取消请求和Activity和生命周期的联动（Activity结束时同时取消所有网络请求）。
3、ImageLoader框架：支持多线程图片加载。提供丰富的细节配置，比如线程池大小，HTPP请求项，内存和磁盘缓存，图片显示时的参数配置等等；提供双缓存，支持加载过程的监听；提供图片的个性化显示配置接口。
‘伍’ Android 【手撕Glide】--Glide缓存机制（面试）
本文源码解析基于Glide 4.6.1
系列文章
Android 【手撕Glide】--Glide缓存机制
Android 【手撕Glide】--Glide缓存机制（面试）
Android 【手撕Glide】--Glide是如何关联生命周期的？
Glide缓存分为内存缓存和磁盘缓存，其中内存缓存是由弱引用+LruCache组成。
取的顺序是：弱引用、LruCache、磁盘
存的顺序是：磁盘、弱引用、LruCache
这张亲手制作的图片，方便大家更直观的理解缓存机制的整体流程，结合文末总结效果更佳。喜欢的记得点赞！
概述
1、弱引用是由这样一个HashMap维护，key是缓存的key，这个key由图片url、width、height等10来个参数组成；value是图片资源对象的弱引用形式。
2、LruCache是由一个LinkedHashMap维护，根据Lru算法来管理图片。大致的原理是利用linkHashMap链表的特性，把最近使用过的文件插入到列表头部，没使用的图片放在尾部；然后当图片大小到达预先设置的一个阀值的时候 ，按算法删除列表尾部的部分数据。由于篇幅有限，这里不讲解LruCache和DiskLruCache的底层原理，这里推荐一篇 图解LinkedHashMap原理
这是Glide自定义的LruCache
存取原理
取数据
在内存缓存中有一个概念叫图片引用计数器 ，具体来说是在 EngineResource 中定义一个 acquired 变量用来记录图袜指正片被引用的次数，调用 acquire() 方法会让变量加1，调用 release() 方法会让变量减1。
获取图片资源是先从弱引用取缓存，拿到的话，引用计数+1；没有的话从LruCache中拿缓存，拿到的话，引用计数逗枝也是+1，同时把图片从LruCache缓存转移到弱应用缓存池中；再没有的话就通过 EngineJob 开启线程池去加载图片，拿到的话，引用计数也是+1，会把图片放到弱引用。
存数据
很明显，这是加载图片之后的事情。通过 EngineJob 开启线程池去加载图片，取到数据之后，会回调到主线程，把图片存到弱引用。当图片不再使用的时候，比如说暂停请求或者加载完毕或者清除资源时，就会将其从弱引用中转移到告悔 LruCache 缓存池中。 总结一下，就是正在使用中的图片使用 弱引用 来进行缓存，暂时不用的图片使用 LruCache 来进行缓存的功能;同一张图片只会出现在 弱引用 和 LruCache 中的一个。
为什么要引入软引用？
1、分压策略，减少Lrucache 中 trimToSize 的概率。如果正在remove的是张大图，lrucache正好处在临界点，此时remove操作，将延缓Lrucache的 trimToSize 操作；
2 提高效率：弱引用用的是 HashMap ，Lrucache用的是 LinkedHashMap ,从访问效率而言，肯定是 HashMap 更高。
Glide磁盘缓存策略（4.x）
如果在内存缓存中没获取到数据会通过 EngineJob 开启线程池去加载图片,这里有2个关键类： DecodeJob 和 EngineJob 。 EngineJob 内部维护了线程池，用来管理资源加载，当资源加载完毕的时候通知回调； DecodeJob 是线程池中的一个任务。
磁盘缓存是通过 DiskLruCache 来管理的,根据缓存策略，会有2种类型的图片， DATA (原始图片)和 RESOURCE （转换后的图片）。磁盘缓存依次通过 ResourcesCacheGenerator 、 SourceGenerator 、 DataCacheGenerator 来获取缓存数据。 ResourcesCacheGenerator 获取的是转换过的缓存数据； SourceGenerator 获取的是未经转换的原始的缓存数据； DataCacheGenerator 是通过网络获取图片数据再按照按照缓存策略的不同去缓存不同的图片到磁盘上。
Glide缓存分为 弱引用+ LruCache+ DiskLruCache ，其中读取数据的顺序是：弱引用 > LruCache > DiskLruCache>网络；写入缓存的顺序是：网络 --> DiskLruCache--> LruCache-->弱引用
内存缓存分为弱引用的和 LruCache ，其中正在使用的图片使用弱引用缓存，暂时不使用的图片用 LruCache缓存，这一点是通过 图片引用计数器（acquired变量）来实现的，详情可以看内存缓存的小结。
磁盘缓存就是通过DiskLruCache实现的，根据缓存策略的不同会获取到不同类型的缓存图片。它的逻辑是：先从转换后的缓存中取；没有的话再从原始的（没有转换过的）缓存中拿数据；再没有的话就从网络加载图片数据，获取到数据之后，再依次缓存到磁盘和弱引用。
参考：
面试官：简历上最好不要写Glide，不是问源码那么简单
原来面试的时候写精通Glide，这样问我这样答
‘陆’ Android线程池ThreadPoolExecutor详解
传统的多线程是通过继承Thread类及实现Runnable接口来实现的，每次创建及销毁线程都会消耗资源、响应速度慢，且线程缺乏统一管理，容易出现阻塞的情况，针对以上缺点，线程池就出现了。
线程池是一个创建使用线程并能保存使用过的线程以达到复用的对象，简单的说就是一块缓存了一定数量线程的区域。
1.复用线程：线程执行完不会立刻退出，继续执行其他线程；
2.管理线程：统一分配、管理、控制最大并发数；
1.降低因频繁创建&销毁线程带来的性能开销，复用缓存在线程池中的线程；
2.提高线程执行效率&响应速度，复用线程：响应速度；管理线程：优化线程执行顺序，避免大量线程抢占资源导致阻塞现象；
3.提高对线程的管理度；
线程池的使用也比较简单，流程如下：
接下来通过源码来介绍一下ThreadPoolExecutor内部实现及工作原理。
线程池的最终实现类是ThreadPoolExecutor，通过实现可以一步一步的看到，父接口为Executor:
其他的继承及实现关系就不一一列举了，直接通过以下图来看一下：
从构造方法开始看：
通过以上可以看到，在创建ThreadPoolExecutor时，对传入的参数是有要求的：corePoolSize不能小于0；maximumPoolSize需要大于0，且需要大于等于corePoolSize；keepAliveTime大于0；workQueue、threadFactory都不能为null。
在创建完后就需要执行Runnable了，看以下execute()方法：
在execute()内部主要执行的逻辑如下：
分析点1：如果当前线程数未超过核心线程数，则将runnable作为参数执行addWorker()，true表示核心线程，false表示非核心线程；
分析点2：核心线程满了，如果线程池处于运行状态则往workQueue队列中添加任务，接下来判断是否需要拒绝或者执行addWorker()；
分析点3：以上都不满足时 [corePoolSize=0且没有运行的线程，或workQueue已经满了] ，执行addWorker()添加runnable，失败则执行拒绝策略；
总结一下：线程池对线程创建的管理，流程图如下：
在执行addWorker时，主要做了以下两件事：
分析点1：将runnable作为参数创建Worker对象w，然后获取w内部的变量thread；
分析点2：调用start()来启动thread；
在addWorker()内部会将runnable作为参数传给Worker，然后从Worker内部读取变量thread，看一下Worker类的实现：
Worker实现了Runnable接口，在Worker内部，进行了赋值及创建操作，先将execute()时传入的runnable赋值给内部变量firstTask，然后通过ThreadFactory.newThread(this)创建Thread，上面讲到在addWorker内部执行t.start()后，会执行到Worker内部的run()方法，接着会执行runWorker(this)，一起看一下：
前面可以看到，runWorker是执行在子线程内部，主要执行了三件事：
分析1：获取当前线程，当执行shutdown()时需要将线程interrupt()，接下来从Worker内部取到firstTask，即execute传入的runnable，接下来会执行；
分析2：while循环，task不空直接执行；否则执行getTask()去获取，不为空直接执行；
分析3：对有效的task执行run()，由于是在子线程中执行，因此直接run()即可，不需要start()；
前面看到，在while内部有执行getTask()，一起看一下：
getTask()是从workQueue内部获取接下来需要执行的runnable，内部主要做了两件事：
分析1：先获取到当前正在执行工作的线程数量wc，通过判断allowCoreThreadTimeOut[在创建ThreadPoolExecutor时可以进行设置]及wc > corePoolSize来确定timed值；
分析2：通过timed值来决定执行poll()或者take()，如果WorkQueue中有未执行的线程时，两者作用是相同的，立刻返回线程；如果WorkQueue中没有线程时，poll()有超时返回，take()会一直阻塞；如果allowCoreThreadTimeOut为true，则核心线程在超时时间没有使用的话，是需要退出的；wc > corePoolSize时，非核心线程在超时时间没有使用的话，是需要退出的；
allowCoreThreadTimeOut是可以通过以下方式进行设置的：
如果没有进行设置，那么corePoolSize数量的核心线程会一直存在。
总结一下：ThreadPoolExecutor内部的核心线程如何确保一直存在，不退出？
上面分析已经回答了这个问题，每个线程在执行时会执行runWorker()，而在runWorker()内部有while()循环会判断getTask()，在getTask()内部会对当前执行的线程数量及allowCoreThreadTimeOut进行实时判断，如果工作数量大于corePoolSize且workQueue中没有未执行的线程时，会执行poll()超时退出；如果工作数量不大于corePoolSize且workQueue中没有未执行的线程时，会执行take()进行阻塞，确保有corePoolSize数量的线程阻塞在runWorker()内部的while()循环不退出。
如果需要关闭线程池，需要如何操作呢，看一下shutdown()方法：
以上可以看到，关闭线程池的原理：a. 遍历线程池中的所有工作线程；b. 逐个调用线程的interrupt()中断线程（注：无法响应中断的任务可能永远无法终止）
也可调用shutdownNow()来关闭线程池，二者区别：
shutdown()：设置线程池的状态为SHUTDOWN，然后中断所有没有正在执行任务的线程；
shutdownNow()：设置线程池的状态为STOP，然后尝试停止所有的正在执行或暂停任务的线程，并返回等待执行任务的列表；
使用建议：一般调用shutdown()关闭线程池；若任务不一定要执行完，则调用shutdownNow()；
总结一下：ThreadPoolExecutor在执行execute()及shutdown()时的调用关系，流程图如下：
线程池可以通过Executors来进行不同类型的创建，具体分为四种不同的类型，如下：
可缓存线程池：不固定线程数量，且支持最大为Integer.MAX_VALUE的线程数量：
1、线程数无限制
2、有空闲线程则复用空闲线程，若无空闲线程则新建线程
3、一定程度上减少频繁创建/销毁线程，减少系统开销
固定线程数量的线程池：定长线程池
1、可控制线程最大并发数(同时执行的线程数)
2、超出的线程会在队列中等待。
单线程化的线程池：可以理解为线程数量为1的FixedThreadPool
1、有且仅有一个工作线程执行任务
2、所有任务按照指定顺序执行，即遵循队列的入队出队规则
定时以指定周期循环执行任务
一般来说，等待队列 BlockingQueue 有: ArrayBlockingQueue 、 LinkedBlockingQueue 与 SynchronousQueue 。
假设向线程池提交任务时，核心线程都被占用的情况下:
ArrayBlockingQueue ：基于数组的阻塞队列，初始化需要指定固定大小。
当使用此队列时，向线程池提交任务，会首先加入到等待队列中，当等待队列满了之后，再次提交任务，尝试加入队列就会失败，这时就会检查如果当前线程池中的线程数未达到最大线程，则会新建线程执行新提交的任务。所以最终可能出现后提交的任务先执行，而先提交的任务一直在等待。
LinkedBlockingQueue ：基于链表实现的阻塞队列，初始化可以指定大小，也可以不指定。
当指定大小后，行为就和 ArrayBlockingQueue一致。而如果未指定大小，则会使用默认的 Integer.MAX_VALUE 作为队列大小。这时候就会出现线程池的最大线程数参数无用，因为无论如何，向线程池提交任务加入等待队列都会成功。最终意味着所有任务都是在核心线程执行。如果核心线程一直被占，那就一直等待。
SynchronousQueue ：无容量的队列。
使用此队列意味着希望获得最大并发量。因为无论如何，向线程池提交任务，往队列提交任务都会失败。而失败后如果没有空闲的非核心线程，就会检查如果当前线程池中的线程数未达到最大线程，则会新建线程执行新提交的任务。完全没有任何等待，唯一制约它的就是最大线程数的个数。因此一般配合Integer.MAX_VALUE就实现了真正的无等待。
但是需要注意的是， 进程的内存是存在限制的，而每一个线程都需要分配一定的内存。所以线程并不能无限个。
‘柒’ Recyclerview多种场景下的优化
因为APP设计的原因，Recyclerview是我在Android中最常用的组件，我们公司的APP几乎每一个页面都会包含至少一个Recyclerview，本篇文章主要介绍一些我个人在工作中总结、收集的recyclerview优化经验。
1.不要在onBindViewHolder中设置点击事件和耗时操作
Recyclerview的onBindViewHoler主要负责将数据与holder绑定，它在列表滑动时会不停的被调用。如果在onBindViewHolder中设定监听操作，会导致已经的绑定点击事件的view，被重复绑定监听操作。
点击事件的监听可以在onCreateViewHolder中设定。一些会创建新对象的操作，也需要根据实际情况考虑从onBindViewHolder中迁移到onCreateViewHolder。
注意： onBindViewHolder运行在UI线程中，如果进行了耗时操作，会导致页面卡顿。并且onBindViewHolder中只应该进行数据的绑定，而不应该进行数据的处理和计算等操作。
2.Recyclerview嵌套Recyclerview的优化
Recyclerview嵌套Recyclerview最经典的运用就是，一个纵向滑动的列表内部的每个item是一个可以横向滑动的Recyclerview，比如说GooglePlay。
这种情况可以使用LinearLayoutManager.setInitialPrefetchItemCount()设定
横向列表初次显示时可见item的个数。如果横向滑动的View中数据量很少，并且不需要横向刷新时，也可以考虑使用HorizontalScrollView实现。
关于这个API的官方文档翻译如下：
如果将此值设置为大于此视图中可见的视图数可能会导致不必要的绑定工作，并且会增加创建和活动使用的视图数。
3.多个RecycerView共用RecycledViewPool
在大多数APP中都有这样一种场景，一个ViewPager中包含多个Fragment，而Fragment中主体是Recyclerview，并且Recyclerview中item view的布局是相同的。例如 微博等
这种情况下，Recyclerview可以设定统一的缓存池用来提高性能。
新建缓存池：
设定缓存池：
4.精确的更新数据使用DiffUtil
在Recyclerview中提供了多种数据数据刷新方式
虽然有了这些刷新方式，但是实际开发中，存在这样一种情况，新数据集与旧数据集仅有一部分数据存在差异。
例如：刷新一个联系人列表，联系人列表中部分联系人的头像有变化，但是姓名和手机号码等信息未发生变化。这种情况以往都是使用notifyDataChanged方法刷新全部数据，但是刷新全部数据的会导致整个布局重绘，Recyclerview中针对这种情况还提供了另一种粒度更小的刷新方式 DiffUti
这里不打算去讲DiffUtil的具体用法，只需要记住DiffUtil的使用场景即可： 列表中存在多个Item的数据需要刷新，但是新数据集与旧数据集存在重复的情况
5.灵活设定setHasFixedSize
在Recyclerview中使用以下方法时，会触发requestLayout()
requestLayout()会重新计算item的大小，如果item的布局文件已经将宽高设为固定大小，可以设定setHasFixedSize(true)，来避免Recyclerview重新计算item的大小。
6.优化Item的布局
布局优化是个老生长谈的问题，本质上就是减少嵌套，ConstraintLayout是google推出的一个用于减少布局嵌套的新layout，但是在Recyclerview中使用ConstraintLayout会导致cpu使用率上升，暂时不推荐使用，不过ConstraintLayout 2.0版本已经进入beta测试，期待后续会有优化。
7.数据非常少时，使用ListView
不知道你有没有考虑过这样的问题，RecyclerView用已经如此强大，用得人也越来越多，为什么最新的Android系统中ListView依然没有被标注为"过时"。
RecyclerView重新设计了缓存机制，新的缓存机制更加强大，更适合处理大量数据的显示，但是这种缓存机制会占据更多的内存，当一个列表页面实际数据项非常少的时候，ListView往往比RecyclerView更合适。