==============接上篇 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 事件觸發情況：
   

   	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 家校群前端腳本錯誤量優化的方案，致力于打造極致的腳本錯誤優化。