上次的视频中讲了 HandlerThread 的使用场景，而这次视频主要讲解了关于线程池的使用场景，视频链接如下：
下面就开始我们的视频内容学习吧。
你是一位很棒的开发人员，而你也正在开发一款很棒的 App，但令人头疼的是，管理所有独立的线程并为他们分配任务可能并不容易，可能还会引起脱发（哈哈哈），So，请不加入“秃顶俱乐部”，当然这只是那个人幽默的提醒我们管理很多线程足以令人头疼。
当我们将一个大任务分解成若干小任务时，使用线程池是一个不错的选择。
一般情况下，我们会使用这样的线程模型， 在不同线程中去做不同事情，这样配置确实在处理顺序任务时没什么问题，但有时候还是会有些问题。
比如，当我需要解码 40 个 Bitmap 时，假如每次解码任务会持续 4 ms，那我将这 40 个任务扔到同一个工作线程中，那么依然还是会消耗 160 ms。
不过如果你创建了 10 个线程，让它们分别开始工作，那只需要 16 ms 就可以完成 40 Bitmap 的解析。
但这样依然会遇到一些问题，比如我们如何正确的在这些线程之间传递任务，分配任务，并管理它们，这确实让人头疼。
在写代码之前其实不用担心，因为 ThreadPoolExecutor 可以帮我们解决这些问题。
这个类帮我们生成线程，并管理这些线程，包括执行任务，管理它们的生命周期，比如当线程池中的某个线程有一段时间没有被分配任务，那么它会帮我们关闭这个线程，所以它可以帮我们处理繁重的并行任务。
但这里也有一个小问题，也算是一个小小的警告，我们在线程池中究竟创建多少个线程好呢？
在技术上，我们可以根据自己的需要，创建非常多的线程来使用，不过并不意味着线程越多越好，这样并不明智。
因为 CPU 只能并发执行确定数量的线程。
一旦超过那个数量，那么 CPU 就会根据任务的重要性来执行这些线程，所以这里也涉及到线程的优先级。
所以我们应该找一个合适的平衡点，来获取一个最大的收益。而且线程的创建并不能那么随意，因为每个线程都有自己的内存开销。
所以你的 App 需要在核心数与收益递减的线程数之间找到一个平衡点（这句可能翻译不是很准确）。
但你在创建线程池时，你可以指定初始线程数，指定最大线程数等等，当任务量变化时活跃线程数也会随之变化并达到某个平衡。
Runtime.getRuntime().availableProcessors(); 这个方法的可以获得可用的处理器数量，但返回值并不能反映设备中真实的物理内核数，因为设备会因为某些方面，如省电，而停用一个或多个 CPU，所以假如你的设备有两个 CPU，但其中一个休息了，那么该方法的返回值就只会返回 1。
我们需要知道的是线程池同样也不能解决我们所有的线程问题，我们需要根据自己的真实的需求决定我们采取什么解决方案。
视频最后还提到了 Renderscript 和 Systrace，不过这两个我暂时都接触过，不过官网有使用它们的资料可以去看一看。
Renderscript
https://developer.android.com/guide/topics/renderscript/compute.html
Systrace
https://developer.android.com/studio/profile/systrace-commandline.html
本期视频内容到此为止，如有任何问题可以留言交流。
