Android中解码Bitmap应选用哪种Scheduler？线程调度选型疑问

首先咱们先把两个候选调度器的核心定位理清楚，再结合你的实际场景来分析：

核心差异：Schedulers.io() vs Schedulers.computation() #

• Schedulers.io()：这是个可动态扩展的线程池，空闲线程会在一段时间后自动回收，专门针对IO密集型任务（磁盘读写、网络请求这类存在阻塞等待的操作）设计。因为IO操作时线程会处于阻塞状态，可扩展的线程池能保证并发任务不会因为线程不足而排队等待。
• Schedulers.computation()：线程数固定等于设备的CPU核心数，专门用于纯CPU密集型计算（比如数据运算、复杂逻辑处理）。固定线程数的设计是为了避免过多线程导致CPU上下文切换开销，最大化利用CPU算力。

结合你的场景分析 #

你用的BitmapFactory.decodeResource()其实包含两个阶段：

1. 从磁盘读取资源文件（IO密集型操作）
2. 对图片数据进行解码压缩（CPU密集型操作）
   而且你的Bitmap只有100万像素，单任务耗时约50ms，属于轻量级的图片处理任务。

选择建议 #

我更推荐你使用Schedulers.io()，原因如下：

1. 你的任务并非纯计算，而是IO+CPU的混合场景，io()线程池更适配这种复合需求。如果用computation()，当同时有多个这类图片任务时，会占用计算线程池的资源，可能影响APP中其他真正需要纯CPU计算的任务。
2. 50ms的单任务耗时很短，就算io()线程池临时创建几个线程，也不会带来明显的上下文切换开销。反而如果用computation()，当图片加载任务并发量上来时，可能会因为线程数不足导致任务排队，拖慢整体加载速度。
3. 从实际开发的实践来看，大多数图片加载的异步任务（比如Glide内部的线程池设计思路）都会偏向使用类似io()的可扩展线程池，来平衡IO等待和CPU计算的需求。

当然，如果你的APP中几乎没有其他CPU密集型任务，用computation()也不会有太大问题，但io()的通用性和场景适配性会更好。

最后给你的代码提个小优化建议：可以把调度器实例抽成全局单例复用，避免重复创建：

// 全局复用的IO调度器实例
val ioScheduler = Schedulers.io()

// 业务代码中使用
Observable.fromCallable { 
    BitmapFactory.decodeResource(resources, resourceId) 
}
.subscribeOn(ioScheduler)
.observeOn(AndroidSchedulers.mainThread())
.subscribe { bitmap -> 
    imageView.setImageBitmap(bitmap) 
}

内容的提问来源于stack exchange，提问作者fdermishin