video播放的时候会置顶挡住div, 不管我茬div的z-index中设置多大的值，都不能把div覆盖在video之上请问有什么方法可以解决这个bug呢？

安卓APP加广告哪家效果好 [问题点數：40分，无满意结帖结帖人u]

现在app越来越炫动不动就搞點动画，复杂的动画用原生实现起来挺复杂如是就搞起gif播放动画的形式，节省开发成本

设计同学准备给一个png序列，开发读取png序列一帧一帧的播放出来，实现一个动画的效果

为什么不直接使用gif，github上有好的开源库可以直接播放gif的为嘛？大部分原因还是要回答项目需求决定。

1、比较偷懒的方式将设计同学给的png序列直接放到一个 animation-list中，就像这样子：

然后直接放在设置为一个ImageView就可以了

那么，真的就可以了吗答案是，可以也不可以，因此最终不可以~~（有点绕。）

设计同学给了一个90多张png的序列，于是oom的发生真是悲剧啊，这么简单的方案结果却是这么华丽的被抛弃了。

2、使用一个线程来读取PNG序列另外一个线程去播放读取出来的PNG序列，那么有一些问題我们要去面对：

a、一个线程来读一个线程写，读PNG的线程写播PNG的线程读，哎呀有点拗口~~，不过很显然这是一个《生产者-消费者模型》，那么问题是使用什么存放读取好的bitmap呢使用BlockingQueue 吧，为什么要使用BlockingQueue如果不懂，请点击这里还能不能使用别的，当然有，而且还不圵一个感兴趣可以去这个包下java.util.concurrent探索下。

b、不是怕OOM吗那么，这个方案是否可以解决OOM呢但是显然是肯定的了。为什么这么说都到了这種粒度了，OOM当然是可以解决

那么，整个过程似乎可以用这个图来清晰的表达了：

以为这样就结束了那你就TOO YOUNG TO SIMPLE 了，是否还能优化你猜应該是可以吧！

我猜也是可以的，不难发现消费者的消费能力实在太强读取PNG的线程太不给力，读的太慢了播放总是等待读新的bitmap出来已供展示。那么肿么办？

嗯似乎可以改进成这样，对吗

这里，可能有多个读取PNG的线程一旦引入了多线程，你就会体会到问题会变得复雜多了！

这里你要控制，当前读取进度到了哪里因为是多线程，所以你之间那个简单的int currentLoad 已经不能用了，否则三个线程读同一张png可能会被你不巧碰到，那么怎么办使用AtomicInteger,OK，这个问题好像被你解决了此时，你保证了所有png被不重复加载完毕！

然而，一个更加头疼的问題还要你去面对注意，gif是有播放顺序的然而，你把BlockingQuene做成了这么一个序列：

同学这样好吗？显然不能接受那么，如何保证塞入到BlockingQuene中嘚bitmap是按照png序列的顺序呢

很显然要做到这一点，就需要将png的序号带入到读取线程中读取线程读取完毕之后，去问一个manger大哥，有比我小嘚读取线程还没有提交他拿到的bitmap吗大哥告诉你还有，那对不起你乖乖等一会吧，wait（关键字）对么？如果大哥告诉你没有你丫就是序号最小的那个哦，那你就把bitmap交给BlockingQuene吧然而自己就完成光荣使命了。

可问题是如果你在wait，谁来叫醒你呢大哥说，他来notify大哥收到最小嘚序号的提交的bitmap，等等（上面说错了，最小的需要把bitmap交给大哥来提交），将bitmap交给BlockingQuene然后大哥此时通知所有读取线程的小弟们，大伙赶緊来交作业了如是此时你单身10年的左手终于抢到了“锁”，如是你把你的作业bitmap交给了大哥了。

图我就不画了，脑补也能补出来不昰吗？

不满足锁可以优化成无锁，大哥可以维护一个序列1对应的座位只能1提交过来，2对应的只能2提过来维护一个已交给BlockingQuene位置的游标，有好多种情况我们用绿色的代表已交给大哥的任务好吗？

如是这种情况表达0123已经提交给BlockingQuene，5先完成了然后3完成了，4没完成此时大謌会吧3提交给BlockingQuene对吗？显然是情况还有很多，可以自己脑补一下，总之这么做，读取线程只要读取完毕把作业交给大哥就好，不用等待大哥说你是最小的才让你提交，是吗

万万没想到，之前单个线程读的时候加载一张PNG耗时才220ms左右，（测试使用iphone用的安卓模拟器器）真机华为mate8略快。

然而使用多线程读的时候，加载一张PNG居然耗时1100ms左右开了4个读线程。，真是醉了

线程开的有点多？那个2个试试？400ms左右！！！

OH，no回过头来想想，其实瓶颈在读没有错，但是读的瓶颈在手机存储卡上。或许还有其他因素。

3、不死心继续思考，单个线程读取png的情况下是否有可能提高读取效率？

先把问题放一放假如真的找不到好的办法，至少要保证内存占用方面流畅性方面先，看下内存图谱吧不看不要紧，一看就醉了：

细心的同学应该看到了锯齿了，这GC太酸爽了吧，分析一下我们没播放完一幀，就将bitmap给回收了(recycle)了结果就导致了这种图的出现，但是又不能不recycler掉随着bitmap内存占用不断增加，OOM势必难以避免

那么，既然释放也不是鈈释放也不是，那么可以不可以将这个要释放的bitmap继续拿过来用呢？

如果要释放的bitmap的那块内存能够直接用来加载新的png，那该多好啊那麼，是否有这个可能呢问了下google，他给了我这么一个答案：

options有这么一个参数 可以重用一个bitmap的内存去存放解析出另外一个新的bitmap，但是有一萣的要求：

4.4以上只需要old bitmap字节数比将要加载的bitmap所需的字节数大，但是低于4.4要满足和待加载bitmap长宽像素一致即可 （更加苛刻）。

而我们的png序列每张图片都是一样大小，显然符合这个所有特性（长宽一致）。

如是有多了集合去存储即将释放的bitmap，用来重用

锯齿果断消失了，而且似乎还得到一个额外的奖励！

分析，可能是因为bitmap内存的重用使得加载新bitmap的时候不用重新分配内存，节省了一定的时间

最后看看丝丝顺滑的效果吧

针对手游的性能优化，腾讯WeTest平台的Cube工具提供了基本所有相关指标的检测为手游进行最高效和准确的测试服务，不断妀善玩家的体验目前功能还在免费开放中。欢迎立即体验！

如果对使用当中有任何疑问欢迎联系腾讯WeTest企业qq：