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

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

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

作者網(wǎng)站是：http://www.stepanp.com/

先簡單說個同構(gòu)（通用）應(yīng)用的概念：前端服務(wù)器端功能雙向映射

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

現(xiàn)在，用 backbone 來構(gòu)建單頁不刷新頁面，javascript 負(fù)責(zé)了路由、校驗、視圖等功能，成為了主角（目錄結(jié)構(gòu)仿照 rails）

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

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

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

那么問題又來了，后端并沒有 DOM，怎么用前端的寫法來呈現(xiàn) DOM 結(jié)構(gòu)？

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

優(yōu)點：

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

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

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

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

React（視圖模板共享）

Webpack + babel + family（構(gòu)建工具）

ReactRouter （路由）

Redux（存儲）

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

構(gòu)建工具用 webpack打包 + babel 轉(zhuǎn)換 ES6/7 自然是目前最好的選擇啦。

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

存儲用 redux，一個請求到來創(chuàng)建一個組件的同時，創(chuàng)建一個 store（即時創(chuàng)建，方便銷毀避免內(nèi)存泄露）

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

拉取數(shù)據(jù)，單頁應(yīng)用必然是使用 ajax 異步去拉數(shù)據(jù)，這里講師推薦了 isomorphic-fetch 模塊來做 ajax 請求，講師說這是同構(gòu)應(yīng)用中拉取數(shù)據(jù)的關(guān)鍵，我沒明白什么意思，回頭翻 PPT。。。

最后作者展望了下 JS 的未來，大一統(tǒng)不同的終端（iOS/Android等），希望能用 JS 來做不同端上視圖、驗證、路由等功能。呼吁我們?nèi)プ鲞@種事情，但我覺得不大可能。。。

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

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

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

這里我體會比較深了，微信緩存清理比較蛋疼，客戶端做的強緩存，對于普通用戶來講節(jié)省流量，對于我們開發(fā)來講就繁瑣了，微信設(shè)置中清緩存不一定有效?？梢钥紤] URL 中加時間戳的辦法（記得 HTML 也要加，否則都不去拉 HTML 了）

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

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

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

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

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

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

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

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

微信調(diào)試一件套，網(wǎng)頁授權(quán)、JS-SDK 模擬、集成 Chrome DevTools、代理、weinre 遠(yuǎn)程調(diào)試。這些在微信開發(fā)者中心有介紹，略。

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

X5-Blink 有哪些新特性呢？

Chrome inspect

標(biāo)準(zhǔn)的緩存策略

完整支持 flex

canvas 支持 CSS 設(shè)置背景色了

filter: blur 模糊可以用了

優(yōu)化了動畫卡頓問題

偽元素支持動畫了

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

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

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

先來看看 UI Component 需要什么

有數(shù)據(jù)/狀態(tài)（data/state）

UI 邏輯

可重用

需要測試

React 組件在 ComponentDidMount 時發(fā)起 ajax 數(shù)據(jù)，設(shè)置 setState 后，更新組件數(shù)據(jù)，重新渲染。

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

對于 UI Component 來說，它不在需要關(guān)心數(shù)據(jù)哪里來的，只關(guān)心將 Container Component 傳遞下來的數(shù)據(jù)，進(jìn)行渲染（無狀態(tài)）。

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

多個組件需要復(fù)用統(tǒng)一份數(shù)據(jù)，所以我們需要有一個地方來存儲通用數(shù)據(jù)，這就是 Store.

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

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

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

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

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

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

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

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

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

講師最后推薦了一個鏈接給大家看看：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.

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

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

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

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

編程能力：解決問題的能力（基礎(chǔ)）
架構(gòu)能力：一定規(guī)模后帶來架構(gòu)問題
工程問題：關(guān)于人的問題，怎么讓一個團(tuán)隊里的人怎么協(xié)作好

怎么提升知識與能力？

你寫代碼的初心是什么，你期望把程序?qū)戇^來的感覺是什么？

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

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

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

尋找線索

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

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

看附錄

查源碼

反射

建立聯(lián)系

childNodes/parentNode nextSibling/previousSibling 等有哪些關(guān)聯(lián)，你理解么？顧名思義，舉一反三，串起來學(xué)習(xí)。

美感

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

操作同組數(shù)據(jù)（setTimeout/setInterval/clearTimeout/clearInterval）

歸類

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

ajax

collection

dom

util

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

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

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

閉包兩部分：

環(huán)境部分 environment

控制（表達(dá)式）部分 control part

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

追本溯源

論文

郵件列表

代碼提交記錄（commits/issues）

挑戰(zhàn)

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

能力培養(yǎng)沒有捷徑，但有投入的技巧。

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

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

習(xí)題很重要。習(xí)題很重要。習(xí)題很重要。

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

主動性

被動的 996 不會有成長

每天主動再加幾個小時學(xué)習(xí)才會有幫助

習(xí)慣養(yǎng)成

保持在學(xué)習(xí)區(qū)、痛苦區(qū)工作（擺脫舒適區(qū)）

系統(tǒng)訓(xùn)練

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

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

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

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

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

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

現(xiàn)有的性能優(yōu)化技巧：文件合并、精靈圖片、內(nèi)聯(lián)圖片、域名共享

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

等待 DOM 和 CSSDOM 構(gòu)建渲染樹

渲染樹節(jié)點

計算布局、定位和尺寸

繪制

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

每個請求都帶有開銷，請求順序優(yōu)化。

最佳渲染路徑：讓內(nèi)容更快的出現(xiàn)在頁面上（減少白屏?xí)r間）

HTTP/0.9
HTTP/1.0 1996
HTTP/1.1 1999

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

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

都支持多路復(fù)用

都支持頭部壓縮

都支持服務(wù)器端推送

HTTP2 支持優(yōu)先級請求

HTTP2 向后兼容 HTTP/1.1

HTTP/1.1 中我們?yōu)榱藴p少體積和請求數(shù)，會做很多的合并。
HTTP/2 中同一個域名只會使用同一個 TCP 連接多路復(fù)用（不需要資源合并、資源內(nèi)嵌）

不需要 CDN combo 合并了

不需要 JS/CSS 內(nèi)嵌了

不需要使用雪碧圖了

HTTP/1.1 下很多優(yōu)化技巧我們都可以拋棄，因為請求已經(jīng)很廉價

HTTP/1.1 中我們?yōu)榱舜蚱茷g覽器并發(fā)請求次數(shù)的顯示，將多個資源分布在不同的域名下。
HTTP/2 中，請求廉價，同域復(fù)用連接（理論上是無限的），所以我們要做域名收歸。減少 DNS 解析反而成為了正確）

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

開啟 SSL/TLS

服務(wù)器開啟 支持，如 apache 的 mod_http2 模塊

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