原文链接

—— 以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事件触发情况：
   

1. wkwebview内核:这里说明一下关于ios的wkwebview内核是ios从ios8开始提供的新型webview内核，和之前的uiwebview相比，性能要好，具体大家可以自行查看关于wkwebview的相关概念。
2. 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适合需要保留原始图片信息、需要支持透明度的图片。