1. 背景
app的照片墙功能中,满屏是小的图片
加载速度是惨不忍睹
2. 分析
抽取几张预览图在浏览器分析,发现大部分的耗时集中在等待服务器响应
项目使用Glide作为图片加载控件,使用glide默认的配置的话,里面有以下的设置:
即glide加载的线程池的配置,使用cpu数量与4的最小值,即线程池的核心线程和最大线程数不超过4个
因为一次性最大同时加载4个预览图,而预览图的最大耗时在等待服务器响应;导致在照片墙上只能同时一行4个循环加载。
3. 解决
因此是否可以加大可同时运行请求预览图的线程数,这样可以避免等待耗时影响程度;
发现里面有可设置的方法GlideExecutor的多个方法,比如我们选择无限制的线程数:newUnlimitedSourceExecutor
,这样在运行中确实大大提升同时加载的图片速度。
但是有个问题,滚动列表容易卡顿,也容易内存溢出,同时N多个在解码,这个估计比较耗内存
因此正确的姿势是使用
GlideExecutor.newSourceExecutor来设置
因为这个耗时在等待,算是io操作,因此可以设置2倍的cpu数或更多来实现加载的提速
需要注意的问题是,设置更多的线程数,在低端的机型可能会内存溢出,需要多测试来设置合理值。
Okhttp
Okhttp的并发数的默认配置如下:
源码中okhttp3.Dispatcher这个类里面提供了
maxRequests = 64: 最大并发请求数为64
maxRequestsPerHost = 5: 每个主机域名下最大请求数为5
同个域名只支持5个并发,这个参数在多个预览图片拉取下就会存在瓶颈。
这块也可以根据实际来配置合适的并发数