查看详情

Is Service Worker in Sandbox

其实这个话题,对很多人而言,如果之前没有细致了解过 Chrome 设计架构,还真不好说出答案,不过好在 Chrome 官方写了四篇文章,详细的阐释 Chrome 适合实现多进程,以及其具体作用的。 Chrome 的多进程设计 输入 URL 浏览器做了什么 Renderer process 如何渲染页面 Chrome 与页面的事件交互 那么 Service Worker 是否运行在沙箱中呢? 我们先看下 Chrome 的多进程架构。 图1 浏览器多进程模型 如图所示,Chrome 包含多个进程,而其中 Browser Process 主要负责浏览器的 UI(比如上面那些插件图标显示,每个tab 的控制,输入框的交互事件等等...),Renderer Process 顾名思义,则是最为核心,我们每个页面渲染的进程,即我们每打开一个 Tab 访问某个页面,就会产生一个 Renderer Process。而 详情 »

查看详情

聊聊 Timing-Allow-Origin 和 Access-Control-Expose-Headers

一般我们如果做页面性能分析,我们自己带着 Chrome 的 PageSpeed 或者 Audit 就可以了。但是如果我们涉及对关键资源的网络请求的性能埋点的话,我们可以尝试利用 PerformanceTiming 。 它提供了诸如一系列 connectStart domainLookupStart responseEnd 等时间戳的数据。我们可以轻松借用这个 API 做页面的 Performance 的数据埋点。比如可以使用: const pt = performance.timing; const domReady = pt.domInteractive - pt.navigationStart //... 初次之外,我们可以利用 getEntries() 来筛选关键资源,比如你希望埋点的 JS 或者 CSS 资源又或者视频音频资源。 const resource = performance.getEntriesByType('resource'); resource.forEach((item) => { // handle your resource timing data 详情 »

查看详情

使用键盘的媒体按键控制视频播放

Chrome 将会在 73 的版本,带来新的媒体控制策略。其中为了推进 PWA 的进度,扩展了媒体播放与键盘的交互。 如果我们使用 Mac 的话,大家一定见过最上面(如果带 touch bar,则是 touch bar) 快进,下一曲,暂停,静音等按键。 很早之前我们介绍过 使用 mediaSession 实现媒体播放的控制 ,在移动端设备上,你可以在锁屏或者通知栏来进行 Web 音乐的播放,而现在,你可以在 PC 上实现这些功能。 navigator.mediaSession.setActionHandler('previoustrack', function() { console.log('prevoious') }); navigator.mediaSession.setActionHandler('nexttrack', function() { console.log('next') }); navigator.mediaSession.setActionHandler('play', function( 详情 »

查看详情

【转】Web端H.265播放器研发解密

原文地址: mp.weixin.qq.com 作者: 林晚 (淘宝技术) 很早之前写过 Web 播放 H265 的文章,今天淘宝的童鞋带来了更进一步的研究,包括音频的同步,以及对 WebAssembly 的使用,目前该方案其实并不太推荐部署到生产环境,一方面是出于性能帧数丢失,另一方面整个工程复杂度的考虑,不过还是可以学习下整体的思路。 随着音视频业务的快速发展,作为前端工程师,我们团队也逐步深入到音视频编解码领域,涉及到流媒体技术中的文本、图形、图像、音频和视频多种理论知识的学习,并有机会大规模应用到具体实践中。 我们自研了Web播放器并支持h.265解码,保持画质不变情况下,将码流降低50%,达到减少带宽成本,真正做到了h265解码播放的全域覆盖。本文主要分享了我们基于WebAssembly实现H.265格式的解封装、解码和播放。 背景 H.265又称HEVC(全称High Efficiency Video Coding,高效率视频编码),是ITU-T H.264/MPEG-4 AVC标准的继任者。相比H.264,H.265拥有更高的压缩率, 详情 »

查看详情

HLS.JS 自定义 分片 TS 请求 URL

很早之前写过 hls.js 源码解读【1】 ,基本分析了 hls.js 这个库的设计和实现。阅读源码一方面是为了吸收对方设计或者编码上的优点,当然也有可能是另外一个原因,就是一些需求从表面的文档里找不到具体的实现思路。 默认情况下,我们并不需要对解析出来的 ts 分片地址做改造,但是如果真的需要的话,其实有两个思路。 思路 1 复写 Loader 。 自己实现一个关于请求的 Loader ,通过配置传入类似; class XhrLoader extends Hls.DefaultConfig.loader { constructor(config) { super(config); var load = this.load.bind(this); this.load = function(context, config, callbacks) { // your code to handle context.url load(context,config, 详情 »

修复 CALL_AND_RETRY_LAST Node 运行问题

最近使用 react-native 的时候遇到了下面的异常: CALL_AND_RETRY_LAST Allocation failed - process out of memory 大概是因为你在 JS 执行比较大的 JSON.parse() 的时候,这个时候比较直接的办法是设置 --max_old_space_size。 在你的 .bash_profile 增加这一话就 Ok了。 export NODE_OPTIONS=--max_old_space_size=4096 这只是临时的一个解决方法,有时间还是需要 debug 到源码查看具体哪一个环节出了问题。 详情 »

查看详情

iOS 12 静音模式下 AudioContext 无法正常播放的 Bug

最近收到用户反馈,网页的背景音乐播放没有声音。 然后我们就按照正常的流程 Debug 。但是我拿到我的 iPhone 7 测试的时候,但是发现是可以正常播放的,但是 iPhone XS 确没有办法播放。 而且这次非常悬疑的是,iPhone XS 的又是可以正常播放虾米音乐的的歌曲。 此时此刻,宝宝的心情,只能用如下图表示: 随后开始看代码,项目的背景音乐是启用了 AudioContext 。这个时候我们强制设置 AudioContext 的音量来,看下是不是 iPhone XS 的问题; const audioCtx = new AudioContext(); let source = aCtx.createBufferSource(); let buf; const gainNode = aCtx.createGain(); // Create a gainNode reference. gainNode.connect(aCtx.destination); // Add context to gainNode 详情 »

查看详情

聊聊新的 Media API Media Capabilities

关于我们探测是否浏览器能够支持某种视频的播放,我们经常用的 MediaSource.isTypeSupported() 或者 HTMLMediaElement.canPlayType() 来判断,详情可以参看 《探测浏览器对 video 和 audio 的兼容性》 。不过今天介绍一个新的 API , Chrome 在版本 64 开始支持的 navigator.mediaCapabilities;它解决的问题是我们支持了这些格式,但是在当前设备那种格式表现最好呢? Media Capabilities 在 wicg 组的草案中明确描述了: This specification intends to provide APIs to allow websites to make an optimal decision when picking media content for the user. The APIs will expose information about 详情 »

查看详情

AV1 VS HEVC VS VP9

之前写了关于 Web 对 H.265/HEVC 的播放支持,如果有兴趣的童鞋可以前往 《Web 播放 H.265视频》 了解,今天主要介绍 AV1(AOMedia Video 1) 和 H.265 的对比。 H.265/HEVC H.264 的成功,导致开发组开始尝试新的编码优化,H.265/HEVC 的编码架构大致上和H.264/AVC的架构相似, 而 H.265 的编码单位可以选择从最小的 8x8 到最大的 64x64, 同时,H.265的帧内预测模式支持33种方向(H.264只支持8种),并且提供了更好的运动补偿处理和矢量预测方法。反复的质量比较测试已经表明,在相同的图象质量下,相比于H.264,通过H.265编码的视频大小将减少大约 39-44% 。而 详情 »

查看详情

使用 Chrome 原生 lazyload 属性进行图片懒加载

在最近的 《Chrome Dev Summit - Key Techniques for Fast Websites》 ,Chrome 团队的成员介绍了,原生的 lazyload 属性即将登陆 Chrome。 一听到 lazyload ,大家可能印象最深的是就是早期瀑布流 Pinterest 网站的的加载效果。效果如下; 实现效果可以参考很早之前写的关于图片的 placeholder《实现类似Pinterest 的图片预加载功能》。这是我们需要通过 JS 来进行一些图片的加载和替换。很开心,Chrome 给了大家尝鲜这个属性的机会,我们在 W3C 的草案中,很早就可以看到对于这个属性的定义; The lazyload attribute is a boolean and IDL attribute that indicates the priority order in which the User Agent should 详情 »