查看详情

解决微信小游戏排行榜 Android 模糊问题

最近用 Cocos Creator (cc) 开发微信小游戏。由于 微信小游戏存在 主域和子域的隔离； 主域，你的主要游戏场景，和一些交互按钮等内容； 子域，主要用于获取用户数据和排行榜的显示； 微信这样分开也是为了更好地保护用户数据，防止数据泄露。因此一定要合理的设计自己的主域和子域； 凡是设计从微信里获取数据的比如用户头像，游戏成绩等；一定需要在子域的canvas 完成绘制； 实际在完成排行榜的功能时候遇到了一点兼容性的问题，Android 的部分机型(自己这边全部复现)和 iOS 设备上存在画布模糊的问题: ios 的截图如下: 搜索了一下，发现没有多少人提出这样的问题，但是看别的游戏也存在同样的问题； 不过，灵机一动！！！ 如果前端接触 canvas 的话，才开始都会遇到一个问题，就是再 PC 上看着挺好的，但是在移移动端就模糊了，因为这里存在一个 设备上物理像素和设备独立像素(device-independent pixels (dips))的比例 因此你的 canvas 设置的像素要比实际多出一些比如会有: canvas.width = window.innerWidth * window. 详情 »

微信活动宣传页实践

最近大量时间参与到做一些宣传类的活动页，这里主要记录一些自己的心得。差不多一周会完成三个左右，还算比较紧凑。 选好模版 好的模板可以节省你非常多的时间，我理解的模版类似这样: 模版 = sass + es6 + webpack + server + html 自己选用的 ykit 作为脚手架，可以很方便的进行前端工程化的配置； 其次还有比较重要的就是明确自己页面的功能类型，比如是动画效果为主，这需要选择合适的基础框架，由于自己是一页一页切换的，所以，自己选用了 swiper ,它可以很好将每个 slide 组合起来； html 模板可以方便帮助你设置一些微信分享的 icon 和内容，这些你值需要根据自己的业务 填写响应字段或者数据就好； 微信分享 微信分享又两种链路，一种是基于 url 传递，还有一种是基于 图片的二维码形式，由于会存在被封的可能性，第二种的形式现在页比较多。很多时候大家都可以通过一个活动，计算初某种结果，然后生成一种图片，然后用户保存到自己手机。 当然第一种，也可以实现动态短链来防止被封的可能性。后面主要说第二种形式； 根据用户的动态生成的内容，比如选项或者输入，需要将 dom 结点转换成 base64 的图像， 详情 »

使用 core-version-manager 解决版本号的问题

最近在写工具处理的时候，想到做这么一个库，用于解决版本号之间的问题，比如打小，比较等问题。常见的比如确定 A/B 两个版本谁比较新，又或者 选出一系列版本中最大的。于是 core-version-manager(名字有点土) Github 怎么使用 $ npm install --save core-version-manager 引入模块； import version from 'core-version-manager' API check() 检测传入的是不是一个版本号； version.check('1.2.4') next() 传入版本的下一个版本号； version.next('1.2.4') // 1.2.5 pre() 传入版本的前一个版本号； version.pre('1.2.4') // 1.2.3 max() 获取传入一系列版本中的最大的版本号； version. 详情 »

JS 中匹配任意字符方案

背景，最近需要匹配出某段脚本里的字符串比如: <script type="text/javascript">window._debug = false</script> 从中截取 到下面内容: window._debug = false 第一时间想到了 .* 来进行中间的匹配: /<script .+>(.*)<\/script>/ 但是实际情况是，大多数脚本和测试的是不一样，都是多行的，会存在换行符。 <script type="text/javascript"> window._debug = false window._obj = { a: 1, b: 2 } </script> 这个时候你可以使用取反的字符匹配类似来避免: var reg 详情 »

PWA fetch 事件不生效

PWA fetch 事件不生效 最近接入 PWA ([Progressive Web App](Progressive Web App)), 我们不是 从 0 开始做，而是基于现在已有的架构，我们是服务端 Node 层做大前端支持，前端构建基于 Ykit 来进行 less 和 es6 的处理。 大概照着 官方教程 做的时候，无非就是注册 service worker, 然后标记需要缓存的资源，然后再进行请求拦截。巴拉巴拉巴拉~~~ 感觉应该很 easy 的事情，然而问题来了： 我注册了 service worker , 打开控制台 然后你可以到这里点击这里： 查看缓存的资源列表。然后点击进去调试，没有发现异常，install active 事件都触发了，但是 唯独 fetch 事件没有触发。 大概弄清楚原因后，首先谷歌了， 详情 »

查看详情

使用 JS 直接截取 视频片段 生成 gif 动画

最近大家对这个表情 非常熟悉。 最近看到 张大大 《纯前端实现可传图可字幕台词定制的GIF表情生成器》 写的关于 前端做 GIF 的文章。由于最近也一直接触的视频，所以就干脆直接再进一步，以后直接通过一个库快速生成 gif 。 直接放参考 DEMO 效果 实现原理 其实相对而言，也是利用了一个核心库 gif.js, 它可以直接将传入 canvas 对象实现截图然后保存为最后 blob 对象。 var gif = new GIF({ workers: 2, quality: 10 }); // add an image element gif.addFrame(imageElement); // or a canvas element gif.addFrame(canvasElement, {delay: 200}); // or copy the pixels from a 详情 »

查看详情

使用 mediaSession 实现媒体播放的通知栏控制

Chrome 在其移动版本的 57 开始后 支持了一个的 新的 API mediasession。(目前桌面版本浏览器不支持) 它能够做什么呢？ 你可以通过提供自定义的 metadata 信息来设置通知栏的效果。 我们以音频为例的话，差不多是你可以在播放音乐的时候你可以设置锁屏或者通知栏上的效果: 1: 默认播放 2：通知栏 3： 锁屏 我们看小具体的代码: if ('mediaSession' in navigator) { navigator.mediaSession.metadata = new MediaMetadata({ title: 'Never Gonna Give You Up', artist: 'Rick Astley', album: 'Whenever You Need Somebody', artwork: [ { src: 'https://dummyimage.com/96x96', sizes: '96x96', type: 'image/png' 详情 »

查看详情

Chrome 新的自动播放策略

最近看 来自 Chrome 团队在 IO 2018上的 分享 《Build awesome media experiences on the web》 。大概主要是说关于 音视频在 Chrome 上的更新。其中业务团队需要及时关注新的 自动播放策略，虽然在去年9月份 Chrome 团队就更新了博客 《Autoplay Policy Changes》。 Chrome 会在 2018年 的第二个季度，采取新的自动播放策略。自己在去年 2017年9月 更新了关于 最新的 Webkit 内核团队关于新版本的 Safari 的 《MacOS High Sierra Safari 11限制了 video 自动播放》 一些处理方法，而这些方法也可以运用到现在的 Chrome 自动播放策略中去。 自动播放的策略调整 如图中所示: 页面中的视频处于静音状态下是允许自动播放的，大概这个产品交互可以参考 微博的主站策略 如果用户与当前页面有任何的交互比如点击或者 详情 »

FFmpeg 比较实用的命令

ffmpeg 是一款非常强大的音视频处理工具，它可以完成对视频的编码，解码以及整合等等功能。它有着强大的命令行操作选项，下面罗列一下非常使用的命令，方便大家处理视频(不依赖Adobe Premiere 等比较复杂软件)。 截取分帧的图片 ffmpeg -i video.mp4 thumb%04d.jpg -hide_banner 获取某一帧的图片 ffmpeg -i video.mp4 -ss 00:00:07.000 -vframes 1 thumb.jpg 截取某个片段 ffmpeg -i video.mp4 -t 00:00:50 -c copy small-1.mp4 -ss 00:00:50 -codec copy small-2.mp4 剥离音轨 详情 »

查看详情

引入 Brotli 进行 Web Server的压缩

目前我们大多数网站都是启用的 gzip 来进行 资源传输的压缩，这有利于我们更加快速的访问我们的网站；但是除了 gzip 外，我们或许还有别的选项，而且性能会更好，比如 Facebook 便是启用的 Brotli 算法; Brotli Brotli 最初发布于2015年，用于网络字体的离线压缩。Google软件工程师在2015年9月发布了包含通用无损数据压缩的Brotli增强版本，特别侧重于HTTP压缩。新版本还展现了跨平台的性能改进，以及减少解码所需的内存。 与常见的通用压缩算法不同，Brotli使用一个预定义的120千字节字典。该字典包含超过13000个常用单词、短语和其他子字符串，这些来自一个文本和HTML文档的大型语料库。预定义的算法可以提升较小文件的压缩密度。 对全球1000个访问量比较大的地址进行测试，使用 Brotli 算法可以得到明显的性能改善: 14% smaller than gzip for JavaScript 21% smaller than gzip for HTML 17% smaller than gzip for CSS 使用brotli取代deflate来对文本文件压缩通常可以增加20%的压缩密度，而压缩与解压缩速度则大致不变。 当然如同 HTTP2, 详情 »