每日杂谈Android Performance Patterns 学习记录

Swimming in Threadpools. (Androi

2017-04-19  本文已影响5人  Gzw丶南山

上次的视频中讲了 HandlerThread 的使用场景,而这次视频主要讲解了关于线程池的使用场景,视频链接如下:

https://www.youtube.com/watch?v=uCmHoEY1iTM

下面就开始我们的视频内容学习吧。

你是一位很棒的开发人员,而你也正在开发一款很棒的 App,但令人头疼的是,管理所有独立的线程并为他们分配任务可能并不容易,可能还会引起脱发(哈哈哈),So,请不加入“秃顶俱乐部”,当然这只是那个人幽默的提醒我们管理很多线程足以令人头疼。

当我们将一个大任务分解成若干小任务时,使用线程池是一个不错的选择。

一般情况下,我们会使用这样的线程模型, 在不同线程中去做不同事情,这样配置确实在处理顺序任务时没什么问题,但有时候还是会有些问题。

一般的线程模型.png

比如,当我需要解码 40 个 Bitmap 时,假如每次解码任务会持续 4 ms,那我将这 40 个任务扔到同一个工作线程中,那么依然还是会消耗 160 ms。

顺序执行解码任务.png

不过如果你创建了 10 个线程,让它们分别开始工作,那只需要 16 ms 就可以完成 40 Bitmap 的解析。


10 个线程并行处理.png

但这样依然会遇到一些问题,比如我们如何正确的在这些线程之间传递任务,分配任务,并管理它们,这确实让人头疼。

在写代码之前其实不用担心,因为 ThreadPoolExecutor 可以帮我们解决这些问题。

这个类帮我们生成线程,并管理这些线程,包括执行任务,管理它们的生命周期,比如当线程池中的某个线程有一段时间没有被分配任务,那么它会帮我们关闭这个线程,所以它可以帮我们处理繁重的并行任务。

ThreadPoolExecutor.png

但这里也有一个小问题,也算是一个小小的警告,我们在线程池中究竟创建多少个线程好呢?

在技术上,我们可以根据自己的需要,创建非常多的线程来使用,不过并不意味着线程越多越好,这样并不明智。

并不是越多越好.png

因为 CPU 只能并发执行确定数量的线程。

一旦超过那个数量,那么 CPU 就会根据任务的重要性来执行这些线程,所以这里也涉及到线程的优先级。

当线程过多就会根据优先级来执行.png

所以我们应该找一个合适的平衡点,来获取一个最大的收益。而且线程的创建并不能那么随意,因为每个线程都有自己的内存开销。

寻找合适线程数,来谋求最大收益.png

所以你的 App 需要在核心数与收益递减的线程数之间找到一个平衡点(这句可能翻译不是很准确)。

但你在创建线程池时,你可以指定初始线程数,指定最大线程数等等,当任务量变化时活跃线程数也会随之变化并达到某个平衡。

创建线程池时.png

Runtime.getRuntime().availableProcessors(); 这个方法的可以获得可用的处理器数量,但返回值并不能反映设备中真实的物理内核数,因为设备会因为某些方面,如省电,而停用一个或多个 CPU,所以假如你的设备有两个 CPU,但其中一个休息了,那么该方法的返回值就只会返回 1。

我们需要知道的是线程池同样也不能解决我们所有的线程问题,我们需要根据自己的真实的需求决定我们采取什么解决方案。

根据需求来决定使用哪个类.png

视频最后还提到了 Renderscript 和 Systrace,不过这两个我暂时都接触过,不过官网有使用它们的资料可以去看一看。

Renderscript
https://developer.android.com/guide/topics/renderscript/compute.html
Systrace
https://developer.android.com/studio/profile/systrace-commandline.html

本期视频内容到此为止,如有任何问题可以留言交流。

上一篇下一篇

猜你喜欢

热点阅读