测试环境如下：
一台阿里云单逻辑cpu的云主机，带宽足够，部署了ubuntu 14.04下的mcu服务器端。配置了基本例子所需的ssl证书、域名、ip等内容。测试基本例子的发布订阅功能正常。
一台macbook pro笔记本电脑做订阅端，通过chrome（Version 58.0.3029.96 (64-bit)）访问https://[domain.com]/?mix=false&publish=false 订阅可能的发布流。同时开了chrome://webrtc-internals观测相关的分辨率、码率信息。
另一台安卓手机（华为PE-TL10，另一台手持式专用安卓设备也可以复现此问题）当发布端发布前置摄像头视频，分两种情况测试：
1.采用最新chrome android客户端，通过访问https://[domain.com]/?mix=false 发布前置摄像头，js脚本中发布的时候，限制编码器为vp8，分辨率为648*480，帧率不限，码率不限；
2.采用v3.3.1的官方android客户端，修改了这几处代码：i).取消了对h264编码的混合流的订阅；ii) 设置了前置摄像头发布，限制编码器为vp8，分辨率为648*480，帧率不限，码率不限。通过在配置页面设置https://[domain.com]/ 网址发布；
两种情况发布的流有显著的差异，前一种web端js客户端发布视频的时候，发布整体码率在20kBps~150kBps之间波动，通常稳定在70kBps，降低了一阵就会恢复，分辨率稳定在648*480，帧率在17fps左右，画质较清晰，无明显马赛克或色块效应；
第二种用android sdk的客户端发布，发布整体码率一开始在50kBps上下波动，经过5s~10s之后，发布整体码率逐渐下降到10~15kBps，通常稳定在10kBps，长时间无法恢复，分辨率从640*480降到320*240甚至更低，画质较模糊，帧率在17fps左右，有明显马赛克或色块效应，可以用惨不忍睹不忍直视来形容；但是关闭app，重新发布，发布整体码率又能回到50kBps，然后过了一会儿，再次降低到10kBps左右。
通过测试环境对比分析可知，问题很大概率出在安卓sdk发布流时对网络带宽及延迟抖动的自适应算法上面，比如带宽估计过低，或者丢包应对异常，导致发布流的码率和分辨率在发布之后急剧下降，影响了整体的画质。
诚然，webrtc带宽自适应编解码引擎的代码量很大，平时更新也很多，但是安卓chrome内核和安卓sdk的vp8发布效果差这么多，实现代码差异如此之大，也太让人匪夷所思了。
