【译】预加载视频实现快速播放

作者:François Beaufort | 译:Vicky·Ye 原文地址:https://developers.google.com/web/fundamentals/media/fast-playback-with-video-preload 在以往的项目中,只要有视频的存在,那么就会是个让人费神的项目。且不说对它的适配兼容问题,只说它的加载问题就能说上半天了。本文作者从视频预加载的各种方法入手,讨论了如何让视频播放速度更快的解决办法。 众所周知,能更快速的播放视频意味着会有更的多人观看到你的视频。在本文中,我将探索通过用户主动触发预加载资源来加速视频播放的技术。 注意: 除非另有说明,否则本文也适用于audio元素。 视频地址:https://developers.google.com/web/fundamentals/media/fast-playback-with-video-preload 致谢:版权所有Blender Foundation | www.blender.org 。 TL; DR 这很棒… 但… 视频preload属性 易用于Web服务器上托管的唯一文件。 浏览器可能完全忽略该属性。 HTML文档完全加载和解析后,资源才开始获取。 当应用程使用MSE扩展媒体时,MSE会忽略媒体元素上的preload属性。 Link preload 强制浏览器发出视频资源请求,但不会阻止文档的onload事件。 HTTP Range请求不兼容。 兼容MSE和文档片断。 获取完整资源时,文件只能是小型媒体(< 5MB)。 手动缓冲 完全控制 复杂的错误需要网页来处理。 视频预加载(preload)属性 如果视频资源是托管在Web服务器上的唯一文件,您可能会使用 video 标签的 preload属性来提示浏览器预加载的信息或内容量。 但这意味着Media Source Extensions(MSE)与 preload 将不兼容。 资源的获取将仅在HTML文档初始加载和解析完成后启动(例如, DOMContentLoaded事件已触发),而实际上在获取资源时将触发完全不同的 window.onload事件。 将 preload属性设置为 metadata表示用户不想马上加载视频,但是需要预先获取其元数据(尺寸,轨道列表,时长等)。 请注意,从Chrome 64开始, preload的默认值是 metadata(以前是 […]

不依赖wifi热点的移动web真机测试解决方案Carefree

简介:从此我厂移动web真机测试告别 wifi 热点。 厂外的小伙伴看到这篇文章标题可能会感到莫名其妙,真机测试移动 web 与 wifi 热点有神马关系?的确,通常情况下真机测试移动端 web 确实用不到 wifi 热点。不过,我厂的前端开发和测试小伙伴对此一定不会感到陌生,我们受这个问题困扰太久太久了。 手机真机测试经常有需要访问开发电脑的场景,比如: 访问开发电脑本地的开发文件 使用电脑 hosts 在电脑上抓包、调试页面 …… 而我厂的手机和开发用电脑处于不同网络,无法直接互访。所以,不少小伙伴无奈使用电脑发射 wifi 热点给手机连接,使其处于同一局域网,以实现互访。这种方案的问题可归结为两大方面:一是政策方面,我厂信息安全规定明确禁止发射个人 wifi 热点;二是体验方面,发射 wifi 热点繁琐且不稳定,影响工作效率。 针对这个工作中的痛点,我们现提出一套不需要 wifi 热点的跨平台移动 web 真机测试解决方案,希望它能缓解小伙伴的些许困扰,像这个方案的名字 Carefree 一样,快乐舒畅的工作。 Carefree 解决方案由“服务端 whistle ”和“ webpack 插件 @nutui/carefree ”两部分组成。 服务端 whistle 现在主流的代理调试工具有 Fiddler 、 Charles 和这两年在前端流行起来的 whistle 。 whistle (读音[ˈwɪsəl],拼音[wēisǒu])是一个基于 Node 实现的跨平台 web 调试代理工具,主要用于查看、修改 […]

小程序实战总结

本文从小程序框架、 api 、组件、应用四个方面入手,说明在开发过程中遇到的问题,并给出处理方案。 小程序虽然具有相对完善的文档,但难免文档中会有解释不清晰,不易被人发现,甚至未曾提及的问题。本文从具体的业务场景出发,汇总笔者在原生小程序日常开发中遇到的常见问题,并给出相应的解决方案,希望能够将这些细节经验分享给需要的童鞋。 框架 运行机制与更新机制 运行机制: 小程序启动会有两种情况,一种是「冷启动」,一种是「热启动」。 假如用户已经打开过某小程序,然后在一定时间内再次打开该小程序,此时无需重新启动,只需将后台态的小程序切换到前台,这个过程就是热启动;冷启动指的是用户首次打开或小程序被微信主动销毁后再次打开的情况,此时小程序需要重新加载启动。 小程序没有重启的概念。 当小程序进入后台,客户端会维持一段时间的运行状态,超过一定时间后(目前是5分钟)会被微信主动销毁。 当短时间内(5s)连续收到两次以上收到系统内存告警,会进行小程序的销毁。 更新机制: 小程序冷启动时如果发现有新版本,将会异步下载新版本的代码包,并同时用客户端本地的包进行启动,即新版本的小程序需要等下一次冷启动才会应用上。 如果需要马上应用最新版本,可以使用 wx.getUpdateManager API 进行处理。 虽然文档中有对这一部分进行说明,但是隐蔽比较深,还是需要重点说明一下,理解运行机制就可以解释为什么刚关闭的小程序打开之后还能保存之前的状态,理解更新机制就明白新发版的小程序为什么需要删除旧的版本再下载新的版本再能有新版的内容了。 如何清除小程序缓存呢? 通过太空囊’…’按钮—打开调试—console—wechat—wx.clearStorage()方法清除,此方法删除 storage 中的数据。 通过微信的”发现”tab签—小程序—长按或者右滑删除指定小程序,此方式彻底卸载该小程序,也就清除了所有内容,包括 storage 中缓存数据、场景值、页面堆栈等。 预览与远程调试的区别 小程序的调试方式有多种,可以通过预览亦可通过远程调试,这两者有何区别呢? 将两者生成的二维码转为url: 预览 URL 为:https://mp.weixin.qq.com/a/~~xxt10QprXmU~rsguk7Cm9P3v2MCXJdpacg~~ 远程调试 URL 为:https://mp.weixin.qq.com/a/~~Rot_QPKUIn8~mzI5kQoA3w4QN0H6nkejvQ~~ 由此可见工作方式都为将本地小程序打包上传至微信侧,扫码访问远程小程序服务。不同点总结如下: 可以有多台真机同时预览,只能有一台真机远程调试。 预览忽略断点,远程调试会有断点。 预览可以忽略部分报错,远程调试有报错将无法运行。 生命周期 生命周期又分页面的生命周期与组件的生命周期,以页面的生命周期为例,不同的生命周期会对应不同的生命周期方法。 onLoad: 页面加载,一个页面只会调用一次。 onShow: 页面显示,每次打开页面都会调用一次。 onReady: 页面初次渲染完成,一个页面只会调用一次,代表页面已经准备妥当,可以和视图层进行交互。 onHide: 页面隐藏,当 navigateTo 或底部 tab 切换时调用。 onUnload: 页面卸载。 进行页面编码之前需要考虑到哪些数据是只需要加载一次的(放到 onload […]

【译】关于GraphQL,你需要知道这些

作者:Weblab Technology | 译:kongfanjia 原文地址: https://medium.com/@weblab_tech/graphql-everything-you-need-to-know-58756ff253d8 【译者注:链接序号对应下面索引列表,另外可以点击阅读原文查看详细的链接文章】 在你已经构建并使用了 REST API 很长一段时间后,最近可能听说了一个 API 技术领域的的新星 —— GraphQL。有些人说它很好,但另一些人并不这么认为。现在,我相信你一定会好奇 GraphQL 到底是什么,它与传统方法有什么不同? 本文的主要目的是强调 GraphQL 的主要特性并讨论这一特定 API 规范的主要优点和缺点。 GraphQL 通常被描述为一种前端导向的 API 技术,因为它允许前端开发人员用比以前更简单的方式请求数据。Facebook 推出的这种查询语言的目的是以直观和可调的格式来制定客户端应用程序,来描绘其数据的先决条件及交互。最棒的一点是该语言不依赖于任何特定的数据库管理系统,并且被我们当前使用的数据格式和编码方式所支持。 传统 REST 的一个基本问题是客户端无法个性化请求数据集。除此之外,运行和控制多个接口是另一个难点,因为客户端总是需要从多个接口请求数据。 在搭建一个 GraphQL 服务器时,最重要的是用单一的 URL 入口来完成数据获取和更改。因此,用户可以通过传送一个说明所需内容的查询字符串来从服务器请求数据集。 在我们继续之前,在这里您可以找到我们的个人经验。 https://github.com/weblab-technology/graphql-example GraphQL VS REST REST 和 GraphQL 的相似之处是它们都用于构建 API 并且通过 HTTP 进行管理。 就差异而言,REST 主要是一个以网络为中心的软件的结构概念,没有规范,也不获取明确的工具集。它更专注于 API 的稳定耐用性而非最优的性能。 而 GraphQL 是一种设计用于通过 […]

【译】React 优化:虚拟 DOM 详解

作者:Alexey Ivanov、 Andy Barnov | 译:大辉 原文地址:https://evilmartians.com/chronicles/optimizing-react-virtual-dom-explained 本文将带你学习 React 的虚拟 DOM,并应用这些知识来加速你的应用程序。在这个对框架内部进行全面友好的初步介绍中,我们将揭开JSX的神秘面纱,向您展示React如何做出渲染决策,解释如何找到瓶颈,并分享一些提示以避免常见错误。 React 持续领跑前端世界并且没有下降迹象的原因之一,就是其平易近人的学习曲线。在用 JSX 和 “State vs Props” 的概念武装你的大脑之后,你就可以开始开发了。 但要真正掌握 React,你需要有 React 思想。本文试着从这个方面来帮助你。下面通过我们其中的一个的项目 React table 来了解一下: 如果你已经熟悉 React 的工作方式,可以直接跳至“优化:挂载/卸载”这节来继续阅读。 (图中是一个在 eBay 的业务中拥有庞大数据的 React table) 通过这上百行动态的并且可过滤的数据行,来理解框架的细节对于保证用户的流畅体验是至关重要。 当程序出错的时候,你很容易感受到,输入文字变得卡顿,复选框检查都需要一秒钟的时间,模态框也很难显示出来。 为了解决这些问题,我们这篇文章要涵盖 React 组件从定义到在页面上呈现(然后更新)的整个生命周期。系好安全带,我们要发车了。 JSX 的原理 在前端圈中称为“转译”的过程,其实用“汇编”来描述是更正确的术语。 React 开发者推荐你使用一种混合了 HTML 和 JavaScript 的语法,即 JSX 来编写你的组件。但浏览器对 JSX 及其语法并不理解。浏览器只理解 JavaScript,所以 JSX 必须转换为 […]

© 2018 JDC. All Rights Reserved.