==============接上篇 HTTP/2 Server Push 详解（上）=================

译者注：上文介绍了 HTTP/2 Server Push 的基本概念和用法，下面继续深入实际使用的性能和考量。

如何分辨 Server Push 是否生效

目前，我们已经通过 Link 首部来告诉服务器推送一些资源。剩下的问题是，我们怎么知道是否生效了呢？

这还要看不同浏览器的情况。最新版本Chrome将在开发者工具的网络发起栏中展示推送的资源。

Chrome显示服务器推送的资源（大图）

原文：https://www.smashingmagazine.com/2017/04/guide-http2-server-push/

作者：Jeremy Wagner

译者按：网络优化一直是译者长期研究的方向，HTTP/2 的理论学习也已做了不少，随着这项标准的推进，越来越多特性被大家开始使用。作为 HTTP/2 最激动人心的特性，Server Push 在性能提升的效果被寄予了很高期望，却因其对传统 B/S 架构的开发模式影响较大未能广泛实践。如何更好地使用这项能力，让我们跟着作者深入探索～

========================译文分割线===========================

在过去的一年时间，HTTP/2 的出现为关注性能的开发者带来了显著的变化。HTTP/2 已经不再是我们期待中的特性，而是伴着 Server Push（服务端推送）能力已然到来。

除了解决常见的 HTTP/1 性能问题（比如，首部阻塞和未压缩的报头），HTTP/2 还提供了 Server Push 能力！服务端推送允许我们向用户发送一些还没有被访问的资源。这是一种获得 HTTP/1 优化实践（例如内联）所带来性能提升的优雅方式，同时也避免了原先实践的一些缺点。

本文中，你将了解什么是 Server Push，它的工作原理与解决了哪些问题。同时你也将学习如何使用它，判断它是否正常运作，以及它对性能的影响。让我们开始吧！

原文链接

—— 以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家校群前端脚本错误量优化的方案，致力于打造极致的脚本错误优化。