DanmakuFlameMaster使用踩坑记录

DanmakuFlameMaster使用踩坑记录_第1张图片

先上需求图,需求很简单,因为数据有限,我们要在首页一个限定的区域内做弹幕的循环飘屏效果,本来是自己写了recycleview自动滑动,结果发现,文字内容长短不一致,列表滑动也要跟着做长度与速度的测算,否则会造成,长的文字内容还没完全展示,条目就自动消失的问题,由于项目里已经集成了弹幕库,有现成的,谁还会想自己计算一波,毕竟,效率啊,时间都去开发了,咋摸鱼呢(深深的悔恨中……)

事实证明我想的简单了,已有的弹幕库,整一波走起,最后发现难以解决弹幕重叠的问题,赶紧,最强大的弹幕库整一波DanmakuFlameMaster带我走向欲生欲死的经历

由于弹幕样式并非完全统一,所以,自然想也不想就使用了ViewCacheStuffer;getItemViewType

来自定义样式,这样也好处理图片问题。然而,结局是弹幕复用由于内容长度不一致导致闪烁,放弃使用多viewHolder,选择setVisibility来解决,依然不行。

好吧,那么只能屈服了,开始使用SpannableStringBuilder,mCacheStufferAdapter来进行解决,结果发现,mCacheStufferAdapter毫无用处,在里面进行预加载根本无用,出来的全是无图片的弹幕,看github上有人在反应,是因为mCacheStufferAdapter的调用时机不对,所以,目前对我来说唯一的选择就是在创建弹幕的时候直接将图片download下来,然后进行模糊处理,其实最好用的当然是glide的异步下载,然儿,两张图让我异步下载,我当然不想接受了,毕竟glide本身也有同步下载的嘛,好吧,接着来坑了,glide的下载是要在后台线程才可以的,RX走起,好吧,无敌的大坑出现,由于我是500毫秒发送一次创建弹幕请求,结果进行暴力测试的时候……Rx直接崩了,并且导致我其他模块只要使用RX的,全部订阅失败,所以,整个应用网络请求全崩了。好吧,我不用RX了,我使用线程池或者自己开线程,结果,暴力测试之下出现paused in other thread问题,好吧(这个是由于我开定时器有点多,定时500毫秒发送一次,数据重新请求,会取消之前的定时器,重新创建新的定时器,按jvm的回收机制,大家懂的),最终我选择使用glide的异步加载,配上RX进行合并请求,Rx每隔1s发送一次创建弹幕请求(找到了实现循环播放的方法seekto,所以,没必要用定时器了),结果依然会出现弹幕缺失的问题,这个主要是因为图片下载失败,非UI线程glide下载失败是不抛异常的,这个可以通过调整创建弹幕的时间间隔来解决。

      当我以为所有的问题都已经解决了的时候,QA的同志告诉我,我高兴的太早了,hide 、show、pause、resume的使用,跟我们理解的并不完全相同,如果我们没有调用pause和hide,在弹幕播放结束后,我们使用show或者resume其实可以重新实现弹幕的播放,起始点位0(可以假设伴有视频,等于回到了视频的起点),一旦我们中间任何节点使用了hide或者pause,我们再使用show或者resume的时候,其实就回到了我们调用hide或者pause的节点,另外便是,看设计图可知道,我的整体架构里面是有viewpage的,当viewpage切换的时候,过一会儿,就所有的弹幕都消失了,感觉像是视频一直在走,没终点了,无论调用show还是resume或者seekto都没用,最后我的无奈选择是只要弹幕离开才处于不可见状态就停止创建弹幕,并调用

 一旦重新出现在视图当中,就重新发送弹幕,保持循环。

你可能感兴趣的:(Android)