基于Flash版的Desktop sharing性能优化过程

性能优化是个比较漫长的过程，性能优化，往往需要先找到突破点-也就是程序最耗费性能的地方在哪里。

 

第一步优化：

我们在做Flash版的Desktop Sharing的性能优化过程中，发现了以下问题：

1.发现Red5 0.7版本存在内存泄露

2.抓屏出的一帧数据特别是关键帧经过ZLIB压缩以后，最大的图片大小达2M

 

这个是我们最初做测试时发现的问题，于是我们做了以下的努力：

1.升级到Red5 0.9版本，内存泄露问题不再出现

2.Screen Video Codec 1 Format是无损的压缩方式，桌面数据经过压缩以后达2.0M，显然我们系统的性能问题已经非常明显，要么就找到更好的Codec，要么就放弃。经过大家共同的努力，我们找到了Screen Video Codec 2 Format，经过codec的改进，压缩后的数据大小由原来的2M byte，变成现在的350KB。

 

第二步优化：

3.350KB的数据是不是仍然很大，确实很大，怎么办？能不能继续减少数据量，数据量减少就意味着让用户等待时间就减少了。我们的desktop sharing系统是先抓屏，然后数据和上一帧数据进行对比，只传递变化的部分，要减少数据，我们需要从源头上下功夫，用户桌面的分辨率千差万别，从1024*768到主流的1440*900在到1600*1000+，用户桌面分辨率越大，我们抓屏出来的数据越大，我们不需要给用户这么大数据，我们可以让1024以上分辨率的电脑，做个缩略scale，变成原来的0.8倍，这样数据是不是只有原来的0.64倍了，数据量减少了1/3，我们的性能又提高了三分之一。

 

第三步优化：

经过上面的两个措施的优化，发现系统的性能有明显的提升，同样的条件下，共享数据的延时从原来的30s变成了7s。我们并没有甘心这样的性能，这7s的时间花在哪里了，于是我们把每个函数执行的时间一一做log，发现了两个问题：

1.Windows 自带的Vector数据结构在大数据量的情况下，存在明显的性能问题，cpu占用很高，另外一个是时间耗费很大，从截屏到压缩一帧数据最大需要4s左右，于是我们自己写了byteBuffer对象，使得性能有了本质的提升，截屏到压缩数据最大的时间从原来的4s到现在的800ms。显然，这里的优化也是很明显的。

2.显然延时进一步减少，我们同样没有满足这样的数据，我们要做到最好。继续跟踪发现，rtmp发送程序有很大的性能问题，项目组为了让控制命令包和语音包的发送优先级更大，人为地做了拆包处理，其目的是为了在桌面视频包发送过程中，一旦有语音包或者控制命令包过来，立即把语音包或者控制命令包优先级提高，保证这种数据包优先发送。但是遗憾的是，项目组在拆包性能上遇到了很大的挑战，我们不能等待，首先我们想到的是，既然拆包存在问题，那就先不拆包，于是我们把MTU设置从原来的1400 bytes到300KB。经过这个试验，发送程序的时间果然小很多，由原来的5s减小到现在的1.4s。

 

第四步优化：

上面已经介绍我们的desktop sharing系统的数据是只传递变化的部分，这样可以做到数据量尽量的小，但是这里有个问题，例如，一个meeting里面刚开始有两个人，一个是host，另外一个attendee A，当attendee B join meeting的时候，发送端仍然只会发送变化的部分，这样对用户B而言，是不是只是能看到变化的那部分桌面了。刚开始我们想到最简单的方法是20秒钟传递一个关键帧，这样对于刚才的case，我们就可以有方法解决了。显然这个不是最好的解决方案，有没有更好的方案？有，肯定有，我们后来想到为什么不只是在用户join meeting的时候再让发送端发送关键帧呢，显然这个做法是非常好的。

 

最终结果从原来的30s到现在的3s，性能有了数10倍的提升。