摘要：介紹微信風格的，與客戶端體驗一致，這個自己去微信上看吧，略。微信調試一件套，網頁授權模擬集成代理遠程調試。這些在微信開發者中心有介紹，略。年微信開發經驗的人，終于又成為了零年開發經驗的人，重新走上了踩坑之路。

活動地址：http://fequan.com/2016/

注意：英文不好，小記也帶有自己理解，部分內容可能包含嚴重的個人想法，不會按原話翻譯，隨機寫得也亂，建議等幾天找錄播或 PPT 得到源文理解。

作者網站是：http://www.stepanp.com/

先簡單說個同構（通用）應用的概念：前端服務器端功能雙向映射

過去，rails 中 路由、校驗、視圖都在 rails 中完成，js 只是用于做一些動畫

現在，用 backbone 來構建單頁不刷新頁面，javascript 負責了路由、校驗、視圖等功能，成為了主角（目錄結構仿照 rails）

介紹了 todomvc 看看同一種 todo 功能，用不同的類庫來實現會是怎么寫的

模板可以在 rails 中寫，也可以在 javascript 中寫，但很快就會失控，你如何判斷這個功能模板應該在哪端寫，類似功能的模板你怎么復用？

如果前后端都是 JS 的話，是不是就解決了這個問題？前后端共享路由、驗證、視圖邏輯

那么問題又來了，后端并沒有 DOM，怎么用前端的寫法來呈現 DOM 結構？

寫一個虛擬 DOM ！前后端代碼共享，React 應運而生。

優點：

共享代碼（代碼習慣一致，我們不再需要在前后端切換語言）

提升性能（計算邏輯放在后端執行，做到直出效果）

利于 SEO（后端吐出靜態 HTML，必然帶來了 SEO 效果）

那么，我們用什么技術棧來做這些事情呢？

React（視圖模板共享）

Webpack + babel + family（構建工具）

ReactRouter （路由）

Redux（存儲）

React 有了虛擬 DOM ，所以我們可以在服務器端很舒服地寫 DOM 組件邏輯
接下來介紹 react 基礎語法，幾段代碼示例，略。
需要注意的是，服務器端可以寫虛擬 DOM 的邏輯，但事件綁定是需要到了瀏覽器端才能真正綁定的，可以理解為服務器端只為我們生成了模板，到了瀏覽器服端后不需要重新計算虛擬 DOM 的結構，用服務器端算好的 DOM 結構直接渲染，并直接添加事件綁定后即可。

構建工具用 webpack打包 + babel 轉換 ES6/7 自然是目前最好的選擇啦。

路由用 ReactRouter，聲明式路由
瀏覽器端使用 ReactRouter 的browser history 功能，服務器端則使用 match 功能（考慮瀏覽器端禁用 JS 后，頁面還能否渲染出來）。

存儲用 redux，一個請求到來創建一個組件的同時，創建一個 store（即時創建，方便銷毀避免內存泄露）

把舊數據緩存到 window.__DATA__，初始化時考慮使用緩存數據，感覺這個做法比較傳統，初始化組件時在數據返回前先使用這份舊數據

拉取數據，單頁應用必然是使用 ajax 異步去拉數據，這里講師推薦了 isomorphic-fetch 模塊來做 ajax 請求，講師說這是同構應用中拉取數據的關鍵，我沒明白什么意思，回頭翻 PPT。。。

最后作者展望了下 JS 的未來，大一統不同的終端（iOS/Android等），希望能用 JS 來做不同端上視圖、驗證、路由等功能。呼吁我們去做這種事情，但我覺得不大可能。。。

介紹 JS-SDK，說的東西在微信開發文檔中都有寫，我就懶得打了，略。

手機機型統計圖，作者貼了張微信安卓客戶端機型前十的分布圖，基本都是低端機，那叫一個慘，這個等 PPT 出來直接看吧。

介紹 X5，優點的為的是抹平不同 Android 版本不同 Webview 的坑，缺點是帶來自己的 X5 坑（有點多）。

這里我體會比較深了，微信緩存清理比較蛋疼，客戶端做的強緩存，對于普通用戶來講節省流量，對于我們開發來講就繁瑣了，微信設置中清緩存不一定有效。可以考慮 URL 中加時間戳的辦法（記得 HTML 也要加，否則都不去拉 HTML 了）

黑科技：//triggerWebViewCacheCleanup 來清緩存！

布局方面，flex 只是部分支持，建議用 autoprefixer 等工具來補，只支持類似 -webkit-box 這種老寫法，只能怪 X5 用的 webkit 內核版本太老了。

動畫效果，偽元素不能使用動畫效果，這個我也深有體會，建議用實體標簽來模擬。

視頻播放，controlrs 是不能隱藏的（除非你有白名單），ontimeupdate 事件可以觸發，但 currentTime 是不準確的，autoplay 是不能使用的，這個是 iOS 普遍的問題，不經用戶交互是無法自動播放媒體的，那監聽 WXJSBridgeReady 事件再播放就好了（用戶有交互）。

cookie 和 localStorage 失效的問題，聽到后我都驚呆了。。。原因不明。這是不可靠的存儲，不要太過于依賴。建議是 cookie 和 localStorage 都存一份。

UIWebView 有個 bug: 手勢右滑和點返回按鈕關閉 Webview 是行為不一致的，建議用 hash 來做歷史記錄管理。

介紹 WeUI, 微信風格的 UI，與客戶端體驗一致，這個自己去微信 github 上看 demo 吧，略。

WeUI 有 jquery/react/vue 版本，這點很贊。

微信調試一件套，網頁授權、JS-SDK 模擬、集成 Chrome DevTools、代理、weinre 遠程調試。這些在微信開發者中心有介紹，略。

X5 升級，改用了 Blink 內核，到現在 3 月 19 號未知，灰了大約 70%，計劃到月底全量。

X5-Blink 有哪些新特性呢？

Chrome inspect

標準的緩存策略

完整支持 flex

canvas 支持 CSS 設置背景色了

filter: blur 模糊可以用了

優化了動畫卡頓問題

偽元素支持動畫了

尼瑪，PPT 太快，我剛肚子餓了還幾點沒記錄到，別打我

升級后，很多坑自動沒了，但我覺得肯定也會帶來更多坑。XXX 年微信開發經驗的人，終于又成為了零年開發經驗的人，重新走上了踩坑之路。

父子組件之間的數據傳遞、渲染、錯誤捕獲，接入外部的 Store

先來看看 UI Component 需要什么

有數據/狀態（data/state）

UI 邏輯

可重用

需要測試

React 組件在 ComponentDidMount 時發起 ajax 數據，設置 setState 后，更新組件數據，重新渲染。

錯誤捕獲的做法是，將 error 傳進 state 中 this.setState({error: null}); 判斷有 error 顯示 Error 組件
處理 loading 的做法也是，將 loading 傳進去 this.setState({isLoaded: false}); 判斷有 isLoaded 顯示菊花

對于 UI Component 來說，它不在需要關心數據哪里來的，只關心將 Container Component 傳遞下來的數據，進行渲染（無狀態）。

我對講師將的 Container Component 的理解是：Container Component 專門負責管理數據，然后將數據傳遞給子組件，也就是 UI Component（單向數據流）

多個組件需要復用統一份數據，所以我們需要有一個地方來存儲通用數據，這就是 Store.

通過拿到一個 action ,改變了一個 store, 再將數據傳遞回去，這是一個簡單的函數行為，而 flux 的實現就過于冗余，所以有了 redux。

其實就是監聽到一個 action 將傳過來的 state 進行合并，然后把新的 state 傳遞回去。

強調無狀態的組件（stateless component），一個組件就是一個函數，接受輸入，將渲染結果輸出。
如果一個父組件里面要產生很多子組件，那你就該將這個組件抽離出來，變成一個函數，給父組件使用。
這里講師拿 underscore 的 _render 做反例，問題在于 render 嵌套太深，不好調試。
而無狀態組件，只關注輸入，保證輸出。

所以建議是，組件嵌套不要太深，保證同時只有一個組件，接收一個輸入，具有一份輸出。（好繞）

這里講的比較抽象，需要看了 PPT demo 代碼才好理解，略（別打我）。

使用裝飾器，不改變原有組件的前提下，加一下修飾包裝后，返回一個新的組件（被賦予了額外的組件或行為）
好處就是，UI 層可以專心做渲染的事情，通過添加額外的裝飾器，來產生不同功能的定制化組件，那么這個 UI 層組件，就做到了可重用。

很多數組操作用 forEach 都可以完成，下面三個也都是數組具備的的方法，只是一些小技巧而已。
用 map 替代 forEach, 簡化數據
用 filter 替代 forEach, 篩選數據
用 reduce 快速產生一個新對象

todos.reduce((todos, todo) => {
     todos[todo.id] = todo;
     return todos;
}, {})

這幾點技巧，加上 ES6 的箭頭函數來用，很多時候一行代碼就能處理完，能讓我們的代碼更加簡潔、可讀。

講師最后推薦了一個鏈接給大家看看：GitHub - ReactiveX/learnrx: A series of interactive exercises for learning Microsoft"s Reactive Extensions Library for Javascript.GitHub - ReactiveX/learnrx: A series of interactive exercises for learning Microsoft"s Reactive Extensions Library for Javascript.

這個講題給我最大的體會就是，去深入思考如何真正得做可重用的組件化，同時讓這份代碼更加可讀。

這個主題沒聽全，期待其他同學補充，略。

開場拿出 react/angular/week 調侃：你不會敢說你會前端？
前端在于難學，而是大家不知道怎么學。如何成為像 hax 一樣的前端？

20% 知識：JS、DOM、Device API、CSS、DOM、HTML、HTTP、jQuery、React ...
80% 能力：編程能力、架構能力、工程能力

編程能力：解決問題的能力（基礎）
架構能力：一定規模后帶來架構問題
工程問題：關于人的問題，怎么讓一個團隊里的人怎么協作好

怎么提升知識與能力？

你寫代碼的初心是什么，你期望把程序寫過來的感覺是什么？

建立并弄清楚自己的知識體系。

為了區分好 id 和 name 的區別，winter 借了十本書去查閱這個問題。

舉例怎么建立自己的知識體系。

尋找線索

比如學 JS, 控制臺輸入 for (var k in window) 看看有哪些屬性，你了解這些東西么，查閱書籍能找到么？

比如學 python，你了解全局有哪些東西么？

看附錄

查源碼

反射

建立聯系

childNodes/parentNode nextSibling/previousSibling 等有哪些關聯，你理解么？顧名思義，舉一反三，串起來學習。

美感

完備性（比如 jQuery 有 append 就有 prepend）

操作同組數據（setTimeout/setInterval/clearTimeout/clearInterval）

歸類

畫思維導圖，例如你知道 zepto 有哪些 API 可以用么，能分類整理完整為一棵樹么？

ajax

collection

dom

util

見到前端爭議的時候，你如何追本溯源找到知識？比如你知道閉包的解釋，誰說的對么？

查 wiki 看歷史，誰定義了閉包這個概念：P J Landin

查 Google 論文, P J 在一個期刊上發了篇文章，看看原文怎么定義閉包的

閉包兩部分：

環境部分 environment

控制（表達式）部分 control part

通過辯證地最本溯源得到正確的判斷，不斷獲得自信和社區聲譽，這對于新人來說非常重要（擺脫新手 拍死前浪）

追本溯源

論文

郵件列表

代碼提交記錄（commits/issues）

挑戰

推翻舊知識，建立新知識，這是一個循環的過程，不斷完善知識體系

能力培養沒有捷徑，但有投入的技巧。

推薦一本教材：《C++程序設計語言》（為什么是教材不叫書？因為沒有習題）

推薦一本書：《黑客與畫家》

習題很重要。習題很重要。習題很重要。

靠自然的提升不太可能，需要刻意的大量的訓練。

主動性

被動的 996 不會有成長

每天主動再加幾個小時學習才會有幫助

習慣養成

保持在學習區、痛苦區工作（擺脫舒適區）

系統訓練

一萬個小時理論太難，那從二十個小時開始呢？

作者是 @foobartel (新浪微博和推特) http://foobartel.com/

開場白：Nobody likes to wait.（含義：我們等待了 HTTP/2 太多年。）

開一個網站只需要 2-3 秒，用戶就會覺得快。超過 4 秒沒打開，50% 的用戶就會選擇離開，超過 8-10 秒，用戶就會離開。

所以在 2-3 秒內打開頁面，用戶基本就不會抱怨。

不要以為很多用戶都在用 wifi 打開網頁速度很快，我們要考慮 3G/GPRS 甚至是離線的用戶網絡，所以更快才是更好。

現有的性能優化技巧：文件合并、精靈圖片、內聯圖片、域名共享

渲染樹的過程，DOM 布局與繪制（重繪）：

等待 DOM 和 CSSDOM 構建渲染樹

渲染樹節點

計算布局、定位和尺寸

繪制

渲染 CSS/JS/HTML，避免或減少各種阻塞問題

每個請求都帶有開銷，請求順序優化。

最佳渲染路徑：讓內容更快的出現在頁面上（減少白屏時間）

HTTP/0.9
HTTP/1.0 1996
HTTP/1.1 1999

帶寬的線性提高并沒有帶來頁面加載速度的線性提高，這是協議帶來的問題（連接數有限，RTT 請求時間固定開銷）

RTT 相比帶寬，對性能的影響更大。

都支持多路復用

都支持頭部壓縮

都支持服務器端推送

HTTP2 支持優先級請求

HTTP2 向后兼容 HTTP/1.1

HTTP/1.1 中我們為了減少體積和請求數，會做很多的合并。
HTTP/2 中同一個域名只會使用同一個 TCP 連接多路復用（不需要資源合并、資源內嵌）

不需要 CDN combo 合并了

不需要 JS/CSS 內嵌了

不需要使用雪碧圖了

HTTP/1.1 下很多優化技巧我們都可以拋棄，因為請求已經很廉價

HTTP/1.1 中我們為了打破瀏覽器并發請求次數的顯示，將多個資源分布在不同的域名下。
HTTP/2 中，請求廉價，同域復用連接（理論上是無限的），所以我們要做域名收歸。減少 DNS 解析反而成為了正確）

HTTP/2 中減少資源請求，域名分發不再必要，但HTTP/1.1 其他已有的優化技巧，還是需要繼續使用，如 DNS 查找、減少重定向、使用 CDN、重用 CDN、開啟壓縮、開啟緩存等。所幸的是，HTTP/2 是向后兼容的。

開啟 SSL/TLS

服務器開啟 支持，如 apache 的 mod_http2 模塊

檢查客戶端支持，caniuse.com 查兼容程度