作者：Dag-Inge Aas，webrtcHacks（原文链接）
翻译：刘通
原标题：Autoplay restrictions and WebRTC (Dag-Inge Aas)
前文链接：自动播放限制与WebRTC-1
不只是关于<audio>和<video>
现在事实证明，新的自动播放政策更改会影响<audio>和<video>标签以外的其他内容。WebRTC中常见的UX模式是向用户提供有关麦克风输入音量的反馈。为此，需要使用AudioContext来分析音频，并且AudioContext采用MediaStream将其波形以桶的形式输出。不会有音频通过扬声器播放，但由于某些原因，因为AudioContext从理论上讲允许你输出音频，所以连分析音频也是不可以的。
这个问题首先在12月份报告给了Webkit，六天之后就已经添加了补丁。在页面已经捕获音频和视频的情况下，这个补丁将会允许AudioContext工作。
那么既然已经有补丁了，那本文的意义又是什么呢？事实证明，Chrome犯了与Safari一样的错误。尽管这会影响许多WebRTC提供商，但Google却选择了一直在此事上保持沉默。大家曾经做过很多次尝试想让Google发布一个关于自动播放对WebRTC影响的PSA，但目前为止Google什么都没有做。
MEI分数搅乱你的测试
我们是如何陷入这种混乱的状态的？当然，许多开发人员都必须在Chrome 66稳定版本发生改变之前对他们的AudioContext代码进行测试，这样才能够有效的针对每个用户。这也是MEI困扰你的地方。你会发现，频繁与页面进行交互会给你带来更高的MEI分数，这意味着经常在自己的产品上进行新版本测试的开发人员就不太可能会遇到该错误，因为他们有音频来进行播放并且分析。
正如MEI一直保持的状态，即使隐身模式也无法帮助你。只有用一个全新的用户开启Chrome才能暴露此问题，这一点即使是对于经验丰富的Google QA人员也很容易被忽略。
浏览器厂商应该做些什么？
Chrome公布了很多关于自动播放政策变更的声明，但是美而有一个提到了WebRTC或MediaStreams。好像已经被人们忘记了的Permission API并没有得到更新，所以开发人员无法同步测试是否需要提示用户输入操作。其中一个建议是，如果像Safari做的那样正在捕获页面，则允许AudioContext输出音频。但这看起来更像是黑客攻击而不是一个正式的解决方案。当不涉及getUserMedia时，它也不支持分析音频的其他合法用例。
对于浏览器厂商的一个具体的解决方案是，让媒体的权限来影响媒体参与指数。如果用户已授予对用户媒体的永久访问权限，那么无论用户是否正在捕获，都应该认为网页足够信任以输出音频，而无需用户交互。毕竟在这一点上，用户相信你不会在他们不知情的情况下向数百万的用户广播麦克风和摄像头内容，因此这在当时并不是什么大的顾虑。
如何在应用程序中解决这个问题
幸运的是你有几件事可以做，这取决于你想要解决的问题。当我们在iOS Safari浏览器上遇到这个问题的时候，做了这些事情。
添加playsinline
为了修复没有声音的视频，需要在视频元素上添加playsinline属性。现在可以查到很多方法来告诉你如何去做。它适用于Safari和Chrome浏览器，并且在其他浏览器中没有不利影响。
用户手势
要想修复音频波形可视化器，只需要添加一个用户手势即可。我们很幸运，因为我们有能力添加多个步骤而不影响我们视频通话的启动流程。你有可能不这么幸运。所以在Google解决此问题之前，除了添加用户操作手势以外，没有其他的解决办法。
没有针对于界面声音的解决方法
目前还没有解决界面声音的方法。有些人正在尝试创建已给AudioContext，该应用程序可以在你传递声音的应用中再次使用，但是我没有验证过这么做是否真的可行。Safari的情况会更好一点。只要你正在进行捕捉，你就可以播放聊天消息和通话的声音，但是你可能不希望只是为了让用户注意到有来电而使用启用用户媒体。
正如你所看到的，在有更长期的解决方案之前，你可以采取一些措施来解决此问题。不要忘了持续的关注此bug以获得最新的更新。
