昨天在騰訊大廈參與了鵝廠AlloyTeam召開的AC2015前端大會，度過了充滿精彩和收獲的一個下午，用一句話形容這次前端Event應該是“誠意滿滿，干貨滿滿”。
說實話，這次AlloyTeam沒有對與會人員做嚴格的身份認證，基本到了就能參與，因此整個騰大的多功能廳下午是爆滿了人。我去的其實算早了，卻也只能搶到很后面的座位。許多去的晚的同行都只好站着或坐地板上參與。
本次AC大會也做了全程的官方視頻錄制，據悉后續將在慕課網上線，屆時有興趣的朋友可以去關注下。
大會起始環節是一個神秘項目的首秀—— 一款H5游戲坦克爭霸（TankStrike）的公開，它的線上地址可以戳這里體驗。
坦克爭霸是一款挺全面也頗具特色的web游戲，你可以選擇不同屬性的坦克（有的血量厚，有的速度快）來應戰，戰斗時也除了常規的開火還能打出定位導彈，能根據敵方坦克的移動而修改自身彈道方向。
具體的玩法和特性就留給大家去線上體驗了，這里不贅言，作為騰訊內部玩H5玩的最溜的AlloyTeam來說，能開發出這樣優秀有趣的作品倒也情理之中。
接着是 show girls 們來拉動現場氣氛了，據說都是我廠可愛的妹子們~
有一種團隊叫AlloyTeam+
這是第一個分享環節，由 AlloyTeam 的 Leader 於濤主持，介紹了此次召開AC大會的初衷——AlloyTeam每年都有許多酷炫好玩的開源項目，希望每年都能有這樣的機會跟大家一同分享。
這意味着后續每一年，AlloyTeam都會召開一次AC大會，作為深圳的一次前端盛事了（不過還是建議明年好好驗下參會者身份嘛，不然對早早報名了的朋友不太公平）
於先生接着做了前端行業趨勢的分析，如PPT所示是醬的，看着是機會多多：
當前前端領域的工程師可以說是越來越多，因此才能招到漂亮的女神妹子來擼碼，不過他也因此拋出一個看法—— “市場不是缺少前端，而是缺少優秀的前端工程師”。
隨着前端領域技術點的日益豐富，前端行業雖然入門簡單，卻存在深入難的瓶頸，因此鼓勵大家做到“精於業務而不限於業務”。
另外於先生也分享了其對當前行業技術趨勢的歸納——”移動化“和”復雜化“，表示當前前端技術已逐步滲透到移動端領域，我們還可以利用它來完成許多復雜的動畫和游戲。
接着是向與會者介紹了 AlloyTeam 團隊，包括名字的寓意、團隊的規模和運作方式等，也介紹了這些年來 AlloyTeam 的一些重要的開源項目，包括應用在web QQ上的JX框架、CodeTank在線（玩）學（游）代（戲）碼平台、H5體感游戲“牆來了”、H5專業級圖像處理引擎AlloyImage、 AlloyStick骨骼動畫引擎等，也透露了16年的主要研發項目為在線創作平台iPresst和在線動畫創建平台AlloyAnimation。
最后於先生表示將在未來開啟“+計划”，把AlloyTeam團隊開源，做第一個“無邊界的開放技術組織”，有興趣有能力的小伙伴可以加入成為AlloyTeam的合作伙伴，擁有參與項目的機會，從而同步獲得更多AlloyTeam的資源和技術經驗，還有機會進入AlloyTeam的名人榜呢~
我有我特色——開發眼中的移動交互
第二個分享環節是號稱”老教授“的潘佳韓主持，他把簡單的頁面拆分為MVC模式——M代表”HTML"，V代表“CSS",C代表”JS“（就一個比喻，不要跟我們常規說的MVC框架搞混了），從這個角度來厘清PC web開發與移動web開發的差異（交互角度上）。
老教授針對不同案例都錄制了一些交互對比視頻，主要是”點擊“和”長列表滾動“倆種行為的交互對比，從而講了一些基礎概念、常見交互問題和解決方案。
1. 點擊交互
鑒於很多PC web的頁面是沒有針對瀏覽器來做移動開發的，所以當用戶用移動設備訪問這些頁面時，經常需要通過手勢來放大縮小視口中的內容，為了方便，常規移動端瀏覽器都提供了雙擊放大/縮小視口內容的功能，因此，瀏覽器對”click“點擊事件做了300ms的延遲來區分單擊和雙擊事件（如果沒有延遲，雙擊的第一擊可能就觸發了其它的行為）。
但是當你的頁面已經是基於移動端來做開發的，這300ms的延遲就顯得多余了，會讓很多單擊事件顯得滯后，造成糟糕的交互體驗。
常規我們會使用 zepto 的 tap 事件來替代 click，tap 實際上是由 touchstart、touchmove、touchend 三個手勢事件來協調完成事件判斷是否觸發的——當用戶手勢滑動距離夠短、時間足夠快，那么就觸發對應的綁定事件。
不過話說這里到沒提到常用的 fastclick~
另外在交互優化這塊也建議我們要關注點擊態的反饋——用戶點擊的瞬間要有及時的外觀反饋。
我們常常會利用 :active 偽類來設置某元素被點擊時的點擊態樣式，但也存在一個問題——滾動頁面的元素的時候也會觸發該反饋。建議的解決方案卻也簡單：點擊元素時動態給其加上帶點擊態的class，再在150ms后動態去掉該樣式。
2. 長列表滾動
開始先拋出了兩個概念——”全局滾動“ 和 ”局部滾動“，前者指滾動條位於body或更頂層，后者指滾動條位於body下的某節點內。
然后是寫樣式最常遇到的滾動問題了—— ios在”全局滾動“的情況下默認開啟彈性滾動特性，但在”局部滾動“的情況下則不開啟，導致滾動內容時顯得非常干涉。
建議的解決方案如下：
body{-webkit-overflow-scrolling:touch;} /*子節點會繼承*/ .scroll-elm{overflow:auto}
另外ios在滾動時還容易出現一個出界bug——已經滾到邊緣時再繼續拉動會拉出一些沒內容的空白區域，這個區域的背景色還很可能跟滾動列表的背景顏色不同：
就此ios 滾動bug的解決方案有：
⑴ 引入 scrollFix 解決（具體查看這篇文章；
⑵ 全局滾動改為局部滾動，頁面的固定區域禁止touchmove默認事件；
另外關於”出界“部分背景色跟滾動列表不一致的，老教授建議不要直接設置滾動元素的背景色，另外說了個好消息——ios8開始，safari出界部分的背景色已經可以和 body 背景色保持一致。
至於安卓設備，其在局部滾動的情況下可能會存在反應滯后、滾動條斷開的bug，因此老教授建議安卓頁面盡量都采用全局滾動的頁面結構。
那么當你的頁面有上下固定、中間滾動的需求時，應當如何將其作為全局滾動的形式呢？機智的老教授給了答案：
話說這里其實我也存在一個問題——安卓和ios可能需要匹配不同的樣式來做滾動優化，那么如何做一套樣式匹配兩種情況呢？
剛好后面的問答環節有人問到同樣的問題，老教授表示可以在一開始時通過ua識別來給頁面html標簽加上對應的樣式（比如 class='ios-style'），以這種形式來讓頁面節點獲取到對應的樣式（比如 .ios-style div{...}）。
點擊和滾動的交互優化講完，老教授開始分享”鍵盤定制“的交互優化——通過不同場景出來不同鍵盤：
建議開發時依據場景給 input 標簽設定好對應的 type 值（url / email/ tel / number / search）來拉起對應的鍵盤。
不過注意在 ios9 中使用 type='search' 的情況下，要求 input 得掛在 <form> 下才會展示出對應外觀，所以常規就是乖乖裹層帶有 action 的 <form> 然后禁用 onsubmit 的默認行為。
此處也簡單介紹了pattern特性的使用：
另外有時候設備會在你輸入英文名稱時默認首字母大寫，或者在你輸入英文詞匯時啟動自動糾錯（底部出現波浪形），這兩種默認開啟的功能可以通過配置 autocapitalize='off' 和 autocorrect='off' 特性來關閉。
時間都去哪了——移動 Web 首屏優化實踐
該環節由高級前端工程師 Johnny 郭碧青主持，開始時拋出了一些問題和首屏時間的概念，然后開始討論影響首屏加載時間的因素，包括DOM與資源的加載、解析和渲染，還有網絡過程中的耗時：
其中 RTT 表示 Round-TripTime，即“往返時延”，表示從發送端發送數據開始，到發送端收到來自接收端的確認（接收端收到數據后便立即發送確認），總共經歷的時延。
關於不同網絡環境下的RTT，Johnny 分享了一些數據：
通過數據研究可獲得一個結論——web頁面在網絡上的耗時總是遠大於瀏覽器（解析渲染資源、執行腳本等）耗時的，因此針對網絡耗時的部分來着手優化是減少首屏時間的關鍵。
關於頁面測速的方法，Johnny也分享了兩種原生實現—— Navigation Timing 和 Resource Timing 。
后續就是實打實的一些優化方案了，主要包括了如下建議：
⑴ DNS預解析
即預先解析那些用戶后續可能會訪問到的域名，這樣用戶再訪問那些頁面的時候可減少DNS的解析耗時，使用的是H5的 prefetch 特性：
<meta http-equiv=”x-dns-prefetch-control” content=”on”/> <link rel=”dns-prefetch” href=”http://a.qq.com”/> <link rel=”dns-prefetch” href=”http://b.qq.com”/>
⑵ 域名收斂
說的簡單點就是單條請求獲取多個資源，該方案在騰訊內部應用的還是挺多的。
這里舉個例子吧，比如下面這條請求就一口氣返回了對應的多個腳本資源：
⑶ 鏈路復用
這里主要是針對網絡耗時所做的優化，具體方案為開啟長連接（keep alive）功能：
也提及了未來的 http2.0 規范，隨着長連接的普及可以減少很多耗費在RTT上的時間。
不過這里沒有提及SPDY，雖然是被拋棄的貨，但還沒有徹底退出市場（騰訊內部其實也開過幾次SPDY的課程）。
⑷ 組件化開發
鼓勵頁面資源按需異步加載和渲染，最好能先在服務端（Node）做渲染處理，這塊屬於直出的概念了。
另外也建議前后端組件同構（React的服務端渲染會是個好例子）。
⑸ 資源加載優化
例如利用webpack進行打包，再通過頁面路由按需加載/卸載相關資源。
⑹ 圖片懶加載
<img>插入DOM樹時先進行可視區域計算，如果不在可視區域則 scroll 后再賦予src。
⑺ 緩存利用
詳盡一切變態方法來利用緩存，就手Q這個客戶端而言，企鵝做了不少的優化，包括緩存頁面上次訪問的數據（下次打開時先復用該數據，再做cgi請求來更新），還有離線包。
這里也介紹了興趣部落頁面的數據緩存框架：
也順道舉了個例子，部落首頁獲取到的帖子標題、作者和點贊數，可以先存到本地（localStorage），用戶打開該帖子時先直接從緩存去復用這塊數據，然后再通過cgi請求做更新，減少白屏時間：
⑻ 離線包
也是手Q客戶端獨有的功能，可以將業務資源永久地保存在本地，用戶取相關資源時直接從離線包去取，而無須發送http請求。
不過這塊僅支持公司內部業務，並未對外開放接口。
參會者“五分鍾”分享
該環節共有三位同行做了精彩的分享，分別是“逐幀動畫的像素差優化”、“React單頁面性能調優”和“前端心路歷程”。
“逐幀動畫的像素差優化”的目標主要是盡可能地壓縮圖片資源的體積，當我們走css3逐幀動畫時難免會用上一張體積很大的雪碧圖，那么可以通過對比雪碧圖里不同幀的圖像的像素差，再組成僅由像素差合成的雪碧圖來作為動畫背景，可以大大減少雪碧圖大小。
個人覺得這個想法比較新穎，但執行起來會比較困難，不太清楚有沒有啥生成像素差雪碧圖的自動化工具。該分享后續本來提供了個微信二維碼讓與會者掃一掃加入了解更多該方案，但鑒於五分鍾的時間太短，我才打開微信他就被“請”下去（PPT也關了）換另一位分享者了，這個還蠻遺憾的。(p.s. 后續跟作者要到例子拉，大家可以看看)
“React單頁面性能調優”的分享主要提及路由切換時，若頁面虛擬DOM較多的時候，它們的切換會存在性能問題，然后分享了一些建議，比如以計數路由的形式來決定虛擬DOM是否做卸載處理（怎么有點像以往的JS垃圾回收機制呢）：
不過五分鍾時間太短沒法了解的詳細，看下他的總結吧（坐的很后面所以都是放大拍的照片，糊是一定的）：
“心路歷程”的分享者米愛個人風格蠻幽（浮）默（誇），一開始還以為他來踢場搗亂的，不過后面發現他講的還是挺有意思，PPT也做的很用心。
手Q Hybird App 優化之路
由前端高級工程師賴曉思主持，主要分為“首屏數據展示耗時優化”和“長列表滾動優化”倆部分。
首屏數據展示耗時優化部分主要是建議首屏的數據盡量不要依賴cgi請求，例如利用 localStorage 緩存數據來做優先展示.
這里取了興趣部落縮略圖緩存的例子，即帖子打開的時候，優先顯示首頁所用過的小圖，然后再通過cgi去取大圖，減少白屏時間：
鑒於圖片均配置了較大的 max-age 緩存設置，所以短時間內重新拉取圖片時是不會再發送http請求的。
接着也是介紹了手Q這個自主研發的客戶端的一些優勢，比如使用了 mqq 這種集成在手Q內的 native 組件，在頁面使用時會先通過js判斷用戶當前環境，如果是手Q訪問則直接調用 native mqq，否則才發請求去下載遠程資源。
另外鑒於客戶端上打開一個新的 webview 是比較耗時的事情（安卓平台可能會有1.5-2.3s的空白等待時間），如何利用這塊時間是值得思考的事情。
就此 mqq 組件提供了 dispathEvent 和 addEventListener 接口，可以在綁定webview創建/銷毀時的事件，從而得以在webview創建的時候預先去拉取cgi數據。
接着是長列表滾動的一些優化。先是分享了一些業務視頻，對比各個滾動方案效果，並逐步做了這些建議：
⑴ iscroll 的滾動性能較差（會不斷監聽滾動事件並觸發回調），當數據較多時很容易造成卡頓（特別在安卓上）
故建議避免使用iscroll，而是以 div 局部滾動的形式來替代它，但該方案在滾動很快的時候可能會出現閃白的問題。
⑵ 依舊推薦使用局部滾動，不過把滾動層與內容層做分離——利用添加了 pointer-event:none 的元素可以實時觸發scroll事件的特性：
不過該方案在部分設備（小米）中也存在內容跳動（而不是滾動）的問題，會讓用戶體驗變得很糟糕，原因是 div 的 scroll 雖能被實時觸發，但 scroll 過程中產生的樣式變更要等到 scroll 結束后才被渲染。
⑶ 模擬滾動，且滾動的過程動態刪除/新增列表中的DOM，防止節點太多導致的性能問題。但頻繁的DOM操作會導致不斷觸發layout，配置低的機器容易卡頓。
⑷ 利用canvas繪制，這樣頁面上就只有一個畫布元素了，此處的示例用了 canvasList。不過使用canvas也存在一些問題，例如當繪制區域較大時，FPS會明顯降低，部分低配設備會不流暢。另外畫布存在交互障礙的問題（無法直接獲取上方的內容）。
⑸ 滾動過程復用dom。話說這也的確是終極方案了，這么做一來不會積累太多DOM節點，二來由於僅僅修改了DOM中的內容，也不會頻繁觸發layout。阿里的滾動組件也利用了這個概念。直接上張圖吧：
最后是長列表滾動優化的總結：
源自手Q Web 的最佳實踐——Abstract 前端開發生態
壓軸環節吧，由 Dorsy 王斌主持，介紹了興趣部落現在所應用上的 Abstract 框架，屬於一個撥出衣服（HTML、css），只關注邏輯的框架，並把所有模塊歸納為兩種關系——“同時渲染” 和 “互斥關系”。
另外也介紹了其配套的類ng模板 sodaRender。
感興趣的朋友可以直接去其官網了解下，這里就不多說了。
總結
整體來說這是一場精心准備的分享大會，帶給了我們許多有趣和值得回味的干貨。話說在 AlloyTeam 開源了多個項目后還能試着做更進一步、更深層次的技術分享可謂難能可貴，天朝的IT圈子還是很需要這樣的分享、交流精神的。
也希望往后的AC大會都能愈辦愈出色，只是弱弱地建議下，雖然開放給更多感興趣的朋友來加入這次活動是好事，但擠掉了報名者的位置還是覺得不妥當。
另外短信最好溫馨提示帶只筆嘛，既然希望我們填寫問卷，但只帶電腦沒帶筆的孩紙傷不起，連紀念服都沒的換有木有。
對了，如果能多搞幾個排插給與會者的設備充電就更好了，我的傻多戴XPS撐了四小時直接沒電撲街。。。
這次的匯總就寫到這吧，后續官方也會掛視頻上來，有興趣的朋友屆時可以再去看一看，個人還是非常推薦的。共勉~
