版权声明:本文为博主原创文章,遵循 CC 4.0 BY-SA版权协议,转载请附上原文出处链接和本声明。
本人最近开发的app是一款电视机顶盒android app,该app打开后会去向服务器求取各个位置的图片,图片内容是服务器后台事先上传并配置好的。客户端哪个页面,哪个位置放哪张图片,都是服务端配置的。所以app开启后的2,3秒内可能要请求十几、甚至几十张图片,并快速显示出来。通常情况下是没有问题的,但是有个别情况图片开始加载到全部加载完毕需要一二十秒,这个问题困扰了我好久。下面是我们的解决过程。
首先怀疑网络问题
服务器开发人员反复实验多次,无论请求十张还是上百张,服务器都是快速返回图片数据,绝不至于要一二十秒;
怀疑图片加载引擎出问题
先后用了五种图片加载引擎都会出现这种问题(用到的加载引擎有, ImageReq, FinalBitmap, facebook的fresco引擎,xutils, Picasso,共五种,其中fresco 和xutils 在机顶盒上加载效果更好一些)。如果是加载引擎的问题,总不能所有引擎都有问题吧。
所以很可能代码里哪里出错了,或者图片请求过程哪里出错了。
一个一个图片请求排查
经过给一个个图片加载请求过程加log并排查,发现只有当最开始请求的图片链接种有“无效链接”时才会有引擎加载慢的问题。
譬如,app开启时要同时请求十几张图片,而最开始的几张图片连接时无效的或者客户端永远请求不到的,这时候引擎图片请求就卡在这里,直到这几张图片请求出现网络报错或者“timeout”后才继续执行后面的“链接正常”的图片请求。这几张无效的图片请求导致后面十几张或几十张图片请求滞后。
当然若是最后几张图片出现“无效链接”则不会导致所有图片加载慢,此时最多是最后几张图片加载不出来。
只有最开始几张图片无效时才会出现这个问题。问题终于找到了。
解决方法
这种无效链接而加载慢的问题,是客户端的原因吗?有一部分,图片请求时timeout时间太长了,所以最好自己能控制timeout时间,而不是全都交给引擎解决。1s内秒获取不到,就通知timeout。当然还有服务端的原因:因为客户端无法识别你这个链接是有效还是无效,譬如多加个字母,少加个数字客户端都无从知晓。所以最好也在服务端排查,为什