AlloyTeam2015前端大會都說了啥

昨天在騰訊大廈參與了鵝廠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」/>

⑵ 域名收斂

說的簡單點就是單條請求獲取多個資源，該方案在騰訊內部應用的仍是挺多的。

這裏舉個例子吧，好比下面這條請求就一口氣返回了對應的多個腳本資源：

http://imgcache.gtimg.cn/c/=/club/qv/pkg/qv_1.x.x.js,/clubact/premin/jquery.webStorage.min.js,/clubact/common/oz.js,/clubact/common/aid.js,/clubact/common/mustache.js,/clubact/common/nav/youxi_nav.js

⑶ 鏈路複用

這裏主要是針對網絡耗時所作的優化，具體方案爲開啓長鏈接（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撐了四小時直接沒電撲街。。。

此次的彙總就寫到這吧，後續官方也會掛視頻上來，有興趣的朋友屆時能夠再去看一看，我的仍是很是推薦的。共勉~