查看详情

使用 Enzyme 进行 React 组件测试进阶

很早之前，写过一篇 《使用enzyme 测试你的 React 组件》, 综合叙述了如何利用 Karma + Webpack + Enzyme 进行组件的测试， 从而确保我们的质量。 相对而言，这次会丰富一些，比如组件的 UI 事件以及 redux 引入后的测试。 项目使用 yarn-react-webpack-seed 为案例，你可以在项目里找到源码。 建立测试 安装 karma $ npm install karma karma-chai karma-chrome-launcher karma-coverage karma-jasmine karma-sourcemap-loader jasmine-core karma-webpack --save-dev 安装 enzyme 相关 npm install enzyme redux-mock-store enzyme-adapter-react-16 jasmine-enzyme --save-dev 在项目建立 test 目录，新增 karma.conf.js 然后在 package. 详情 »

查看详情

使用 JavaScript 探测网络状态

同步 https://medium.com/@JackPu/how-javascript-detect-the-network-status-42f3a6d85f96 在某些情况下，我们的开发者需要指导是否由于网络中断的原因导致 request 失败。 以及我们需要网络重新连接后，我们需要执行一些代码。 naviagtor.onLine naviagtor.onLine 是一个非常好实用的 API. 它可以告诉开发者现在网络是连接还是断开的状态。并且它已经覆盖了绝大多数现代浏览器。 navigator.onLine caniuse figures 而在比较老的 IE8 浏览器，我们小使用 online 事件进行监听。 document.addEventListenner(‘online’, () => { // todo }); document.addEventListenner(‘offline’, () => { // todo }) 网络心跳检测 然后很早的时候，很多浏览器还不支持 naviagtor.onLine。开发者只能通过 XHR 和 Image 发送心跳轮询来判断是否还处在网络连接的状态。 const pingUrl = ‘https://ipv4.icanhazip.com'; 详情 »

查看详情

使用原生 Web Share API 进行内容分享

Chrome 75 开始支持 Web Share API - Level 2, 这也就意味着你可以通过 JS 分享 文件，链接或者文本到其他的 App 了。 其实这个需求很早很早，我们的 PM 就开始提了，关于实现，目前比较成熟的是通过 JS Bridge，然后利用 APP 的能力唤起分享面板。但是我们还是无法通过 Chrome 或者 Safari 实现页面内通过 JS 执行唤起分享面板。详情可以见《H5 互动营销》。 canShare() 以及 share() 当然目前这个还是一个处在实验性的 API ，我们还是需要去做一些兼容性判断。分享文件，我们还需要确认这些文件是否处于可分享的状态。可以尝试 Chrome 团队给的代码 const shareData = { files: filesArray }; if (navigator.canShare & 详情 »

查看详情

移动平均(EWMA)在 HLS.JS 的实践

才开始大家一直在想，什么是移动均线？ 哪里会用到？？ 对于常规的页面，实际上很难说需要到具体到有需要用到 网络宽带的预估，但是对于流媒体或者上传服务时候，这个就很重要了，我们需要根据不同网速情况，做策略上的更改，从而改善体验。 做视频播放的很多童鞋，经常在 Youtube 上看到这么一个仪表盘，界面。 大家会看到网速的实际情况。 如果叫大家来实现，实际上，或许很轻而易举会想到用一个网络资源的请求，和时间来完成做一次除法就OK了。 const start = Date.now() fetch(url, {}).then((result) => { const end = Date.now(); const bw = length / (end - start) * 8000; }) 似乎，这样就可以表示一个当前分片的网速了，但是我们实际上并不会用当前的瞬时值作为一个衡量当前宽带是否满足我们播放某种清晰度的标准。 而 hls.js 巧妙的借鉴了 移动平均 来反映当前网络的一个趋势。 移动平均 移动平均（moving average，MA），又称“ 详情 »

查看详情

解决 Synchronous XHR in page dismissal 的问题

如果你更新了最新的 Chrome (大约 >= 73 的部分版本)，发现有些日志没有发送的时候，需要引起注意了。你需要关注是否有一些异常或者警告产生类似 Uncaught DOMException: Failed to execute 'send' on 'XMLHttpRequest': Failed to load 'https://xxxx/': Synchronous XHR in page dismissal. 目前还并不能明确具体会在什么版本采用这个策略，当前有可能只是部分版本限制了 至今， Synchronous XHR 都是不被推荐使用的，但是我们还是会在一些特殊场景中使用到，比如页面 unload 或者 beforeunload 用于表示用户离开页面的数据发送。不过不好的消息便是，Chrome 正计划限制这类似的请求。 于是乎我们看到了很多人在最近几天发布了这个问题 传送门 https://stackoverflow.com/questions/55676319/ajax-synchronous-request-failing-in-chrome 目前比较好的解决方式只有 navigator.sendBeacon(), 它不会阻塞 main 详情 »

查看详情

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, 详情 »