原文链接

—— 以 webpack 文档部署为例子

Overview

Some friends and I have been running webpack-china for a few months.
After a few months effort, most doc translation job have also been done. We keep tracking the master and you will see Chinese version does not lag behind too much.

(pretty much the same and http2 is also applied)

在现在这样一个前端技术迅速发展的时代，一不留神就出现了许多新的技术知识。
为了能够让大家更加系统的学习前端的精华知识，经过了一段时间的研究和精心准备，
AlloyTeam 决定发行 Alloy 周刊。

知识点 1: 移动 web 滚动问题

在移动端，使用滚动来处理业务逻辑的情况有很多，例如列表的滚动加载数据，下拉刷新等等都需要利用滚动的相关知识，但是滚动事件在不同的移动端机型却又有不同的表现，下面就来一一总结一下。

1. 滚动事件：即 onscroll 事件，形成原因通俗解释是当子元素的高度超过父元素的高度时且父元素的高度时定值 window 除外，就会形成滚动条，滚动分为两种：局部滚动和 body 滚动。
2. onscroll 方法： 一般情况下当我们需要监听一个滚动事件时通常会用到 onscroll 方法来监听滚动事件的触发。
   如果在浏览器上调试这个方法在浏览器上很好用，但是如果跑在手机端就没有想象中的效果了。
3. body 滚动：在移动端如果使用 body 滚动，意思就是页面的高度由内容自动撑大，body 自然形成滚动条，这时我们监听 window.onscroll，发现 onscroll 并没有实时触发，只在手指触摸的屏幕上一直滑动时和滚动停止的那一刻才触发, 采用了 wk 内核的 webview 除外。
   
   

   body 滚动
   局部滚动

4. 局部滚动：在移动端如果使用局部滚动，意思就是我们的滚动在一个固定宽高的 div 内触发，将该 div 设置成 overflow:scroll/auto; 来形成 div 内部的滚动，这时我们监听 div 的 onscroll 发现触发的时机区分 android 和 ios 两种情况，具体可以看下面表格：
5. 不同机型 onscroll 事件触发情况：
   

   	body 滚动	局部滚动
   ios	不能实时触发	不能实时触发
   android	实时触发	实时触发
   ios wkwebview 内核	实时触发	实时触发

6. wkwebview 内核: 这里说明一下关于 ios 的 wkwebview 内核是 ios 从 ios8 开始提供的新型 webview 内核，和之前的 uiwebview 相比，性能要好，具体大家可以自行查看关于 wkwebview 的相关概念。
7. body 滚动和局部滚动 demo：这里我需要指出的是在采用 wkwebview 内核的页面中 scroll 是可以实时触发的，如果使用的是原本的 uiwebview 则不能够实时触发，手 q 目前使用的是 uiwebview 而新版微信使用的是 wkwebview，大家可以分别使用来尝试一下下面的 demo：
   局部滚动

   body 滚动
   
   分别用 ios 手 q 和微信和 android 手 q 体验会有不同的结果。

知识点 2: 关于模拟滚动

1. 有了上面介绍的关于滚动的知识，理解的模拟滚动就不难了。
2. 正常的滚动：我们平时使用的 scroll，包括上面讲的滚动都属于正常滚动，利用浏览器自身提供的滚动条来实现滚动，底层是由浏览器内核控制。
3. 模拟滚动：最典型的例子就是 iscroll 了，原理一般有两种：
   
   1). 监听滚动元素的 touchmove 事件，当事件触发时修改元素的 transform 属性来实现元素的位移，让手指离开时触发 touchend 事件，然后采用 requestanimationframe 来在一个线型函数下不断的修改元素的 transform 来实现手指离开时的一段惯性滚动距离。
   
   2). 监听滚动元素的 touchmove 事件，当事件触发时修改元素的 transform 属性来实现元素的位移，让手指离开时触发 touchend 事件，然后给元素一个 css 的 animation，并设置好 duration 和 function 来实现手指离开时的一段惯性距离。
4. 这两种方案对比起来各有好处，第一种方案由于惯性滚动的时机时由 js 自己控制所以可以拿到滚动触发阶段的 scrolltop 值，并且滚动的回调函数 onscroll 在滚动的阶段都会触发。
5. 第二种方案相比第一种要劣势一些，区别在于手指离开时，采用的时 css 的 animation 来实现惯性滚动，所以无法直接触发惯性滚动过程中的 onscroll 事件，只有在 animation 结束时才可以借助 animationend 来获取到事件，当然也有一种方法可以实时获取滚动事件，也是借助于 requestanimationframe 来不断的去读取滚动元素的 transform 来拿到 scrolltop 同时触发 onscroll 回调。
6. 关于模拟滚动和正常滚动，两者在性能上差别还是比较明显的，下面时两个 demo，可以扫描体验一下：
   正常滚动

   模拟滚动
   
   衡量滚动是否流畅的指标 fps，我这边也统计了一下正常滚动和模拟滚动的 fps 数据：
   
   正常滚动
   
   模拟滚动
   
   模拟滚动的 fps 值波动较大，这样滚动起来会有明显的卡顿感觉，各位体验的时候如果滚动超过 10 屏之后就可以明显感觉到两着的区别。
   
   在使用模拟滚动时，浏览器在 js 层面会消耗更多的性能去改变 dom 元素的位置，在 dom 复杂层级深的页面更为高，所以在长列表滚动时还要使用正常滚动更好。

知识点 3: 滚动和下拉刷新

1. 下拉刷新的元素在页面顶部，正常浏览时不可见的。
2. 当在页面顶部往下滚动时出现下拉刷新元素，当手指离开时收起。
3. 以上两点时实现一个下拉刷新组件的基本步骤，结合我们上述关于滚动的描述，我们可以这样实现下拉刷新：
   
   方案 1：借助 iscroll 的原理，整个页面使用模拟滚动，将下拉刷新元素放在顶部，当页面滚动到顶部下拉时，下拉刷新元素随着页面的滚动出现，当手指离开时收回，此方案实现起来较为简单直接借助 iscoll 即可，但是使用了模拟滚动之后在正常的列表滚动时性能上不如正常滚动。
   方案 2：页面使用正常滚动，将下拉刷新元素放置在顶部 top 值为负值（正常情况下不可见），当页面处于顶部时下拉，这时监听 touchmove 事件，修改 scrollcontent 的 tranlateY 值，同时修改下拉刷新元素的 tranlateY 值，将两者同时位移来将下拉刷新元素显示出来，手指离开时（touchend）收回，这种方案满足了在正常列表滚动时使用原生的滚动节省性能，只在下拉刷新时使用模拟滚动来实现效果。
   方案 3：方案 2 的改良版，唯一不同是将下拉刷新元素和 scrollcontent 放在一个 div 里，将下拉刷新元素的 margintop 设为负值，在下拉刷新时，只需要修改 scrollcontent 一个元素的 tranlateY 值即可实现下拉，在性能上要比方案 2 好。
   
4. 在采用了上述方案之后，还会有一个性能上的问题就是：当页面的列表过长，dom 元素过多时，在模拟滚动，下拉刷新这段时间内，页面也会有卡顿现象，这里采取了一个优化策略即：
   
   1) 列表较长时 dom 数量较多时，在触发下拉刷新的时机时将页面视窗之外的 dom 元素隐藏或者存放在 fragment 里面。
   2) 在刷新完成之后手指离开（touchend）时将隐藏的元素显示出来。
   3) 需要注意的是，隐藏和显示视窗外的元素这个操作在下拉刷新时只会执行一次，并且只有在下拉刷新时才会执行。

AlloyPullRefresh

1. 基于上述知识点，我写了一个下拉刷新组件，各位可以参考使用，如有问题，请多多指出！

https://github.com/AlloyTeam/AlloyPullRefresh/

名词解释

AST：Abstract Syntax Tree, 抽象语法树

DI: Dependency Injection, 依赖注入

===============================================================

Babel 的解析引擎

Babel 使用的引擎是 babylon，babylon 并非由 babel 团队自己开发的，而是 fork 的 acorn 项目，acorn 的项目本人在很早之前在兴趣部落 1.0 在构建中使用，为了是做一些代码的转换，是很不错的一款引擎，不过 acorn 引擎只提供基本的解析 ast 的能力，遍历还需要配套的 acorn-travesal, 替换节点需要使用 acorn-，而这些开发，在 Babel 的插件体系开发下，变得一体化了

原文链接

写在前面

先说说 Store 系统是干什么的！为什么要造这样一个东西？能够给系统架构带来什么？

当我们组件之间，拥有共享的数据的时候，经常需要进行组件通讯。在 Omi 框架里，父组件传递数据给子组件非常方便：

• 通过在组件上声明 data-* 或者 :data-* 传递给子节点
• 通过在组件上声明 data 或者 :data 传递给子节点（支持复杂数据类型的映射）
• 声明 group-data 把数组里的 data 传给一堆组件传递（支持复杂数据类型的映射）

注：上面带有冒号的是传递 javascript 表达式

原文链接

写在前面

Omi 框架可以通过在组件上声明 data-* 把属性传递给子节点。
Omi 从设计之初，就是往标准的 DOM 标签的标准传递方式靠齐。比如：

• 下划线自动转驼峰， data-page-index 传到子组件就变成 this.data.pageIndex
• data-xx 传递到子节点全都变成字符串，如 data-page-index="1"到子节点中 this.data.pageIndex 就是字符串"1"

输入在移动端是一个很常用的功能，那么输入框必然是一个很重要的部分。然而，移动端输入框总会遇到各种各样的问题，无论是样式还是 ios 和 android 两端体验不一致都是很让我们头疼的问题，那么如何使移动 web 的输入框体验更贴近原生也成了一个需要我们多多思考和研究的问题。

原文地址

在前端开发工作中，除了项目开发保质保量上线以外，项目的数据监控也应该配套起来，确保线上的正常运转。如上报 pv 监控项目是否正常运转；测速上报反应项目质量；脚本错误监控作为监控中重要一环，当页面发生报错的时候，通过上报错误信息，能及时发现存在问题，修复优化、减少损失。

本文基于在手 Q 家校群前端脚本错误量优化的方案，致力于打造极致的脚本错误优化。

原文链接

写在前面

Omi 框架经过几十个版本的迭代，越来越简便易用和强大。
经过周末的连续通宵加班加点，Omi v1.0 版本终于问世。虽然版本遵循小步快跑、频繁迭代，但是 Omi 团队成员都有着克制之心，处女座占了半壁江山，所以 Omi 的 API 除了增量的 API，其他的历史 API 没有任何变化。

• Github：https://github.com/AlloyTeam/omi

废话不多说，这就为大家介绍到目前 1.0 版本为止，关于 Omi，你必须知道的点点滴滴。

前言

现在时富媒体时代，图片的重要性对于数十亿互联网用户来说不言而喻，图片本身就是像素点阵的合集，但是为了如何更快更好的存储图片而诞生了各种各样的图片格式：jpeg、png、gif、webp 等，而这次我们要拿来开刀的，就是 png。

简介

首先，png 是什么鬼？我们来看看 wiki 上的一句话简介：

Portable Network Graphics (PNG) is a raster graphics file format that supports lossless data compression.

也就是说，png 是一种使用无损压缩的图片格式，而大家熟知的另外一种图片格式——jpeg 则是采用有损压缩的方式。用通俗易懂的方式来讲，当原图片数据被编码成 png 格式后，是可以完全还原成原本的图片数据的，而编码成 jpeg 则会损耗一部分图片数据，这是因为两者的编码方式和定位不同。jpeg 着重于人眼的观感，保留更多的亮度信息，去掉一些不影响观感的色度信息，因此是有损耗的压缩。png 则保留原始所有的颜色信息，并且支持透明／alpha 通道，然后采用无损压缩进行编码。因此对于 jpeg 来说，通常适合颜色更丰富、可以在人眼识别不了的情况下尽可能去掉冗余颜色数据的图片，比如照片之类的图片；而 png 适合需要保留原始图片信息、需要支持透明度的图片。