LinkedIn 5月2日發(fā)布了新的iPad版本，它基于HTML5制作，在體驗(yàn)和界面上非常出色，在使用中可以發(fā)現(xiàn)它和原生應(yīng)用基本沒有任何差別。

關(guān)于這個(gè)版本，有兩篇文章非常有價(jià)值，深入的介紹了Mobile Web App和HTML5移動(dòng)開發(fā)的原理和方法。

第一篇《你絕對(duì)想不到的LinkedIn如何構(gòu)建iPad新應(yīng)用》主要包括三個(gè)方面的內(nèi)容：

• LinkedIn and themobile web

LinkedIn開始越來越多的采用HTML5來開發(fā)移動(dòng)Web應(yīng)用。

• Now, with more Node.js

大量使用了node.js。

• “Responsive design” just doesn’t work

他們認(rèn)為響應(yīng)式網(wǎng)頁設(shè)計(jì)對(duì)簡單的、一次性的網(wǎng)站很有用，但是對(duì)應(yīng)用或者社交網(wǎng)絡(luò)來說，它沒有那么好。

-------- -------- -------- -------- 華麗的分隔線

而下面一篇文章講述了LinkedIn是如何使用HTML5在iOS中實(shí)現(xiàn)平滑無限滾動(dòng)以及內(nèi)存和性能優(yōu)化的。

LinkedIn iPad版：用HTML5的5項(xiàng)技術(shù)實(shí)現(xiàn)無限平滑滾動(dòng)

作者：TrunalBhanse

譯者：蔣宇捷

這是在一系列博客文章中的第二篇，我們將聊聊LinkedIn新的iPad應(yīng)用。在第一篇文章中，我們談到了如何使用HTML5本地存儲(chǔ)建立敏捷的移動(dòng)體驗(yàn)，而這篇文章我要講講當(dāng)實(shí)現(xiàn)一個(gè)無限翻頁的列表時(shí)所面臨的挑戰(zhàn)。

什么是“流”？

當(dāng)iPad項(xiàng)目開始時(shí)，我們考慮過如何才能為用戶創(chuàng)造一個(gè)引人入勝的內(nèi)容消費(fèi)體驗(yàn)。我們決定以“流”的方式來展示文章、網(wǎng)絡(luò)更新，以及其他類似的內(nèi)容：一個(gè)可以無限翻頁的界面。這里是頁面流的第一頁：

移動(dòng)設(shè)備上無限列表的挑戰(zhàn)

和臺(tái)式機(jī)相比，移動(dòng)設(shè)備具有更少的內(nèi)存和更低的CPU主頻。如果在HTML頁面中渲染很長的列表，你會(huì)面臨運(yùn)行設(shè)備崩潰的危險(xiǎn)。這使得在移動(dòng)設(shè)備上構(gòu)建大型的HTML5互動(dòng)應(yīng)用成為一個(gè)挑戰(zhàn)。Native技術(shù)提供了UITableViewController來建立長的，無限滾動(dòng)的列表。UITableView包含可復(fù)用的UITableViewCells來優(yōu)化內(nèi)存，性能以及響應(yīng)。而針對(duì)HTML5我們沒有任何現(xiàn)成解決方案。因此，我們將自己實(shí)現(xiàn)一個(gè)！

技巧1：移除圖像

UIWebView或者移動(dòng)Safari瀏覽器對(duì)圖像有嚴(yán)格限制。我們的頁面流里鋪滿了大尺寸圖像，所以很快就會(huì)達(dá)到上限。一種選擇是使用HTML5Canvas繪制圖像，不會(huì)帶來內(nèi)存問題。然而我們發(fā)現(xiàn)在畫布上繪制非常大的圖像相當(dāng)緩慢，所以我們不得不采取另一種方法：當(dāng)一副圖像完全“流”出屏幕時(shí)，用另一副非常小的圖像替換img標(biāo)簽的“SRC”屬性。這能確保渲染大型圖像所使用的內(nèi)存被定期釋放。此外，我們保證并沒有引入圖像空src屬性的錯(cuò)誤。

技巧2：隱藏頁面

釋放圖像并沒有回收足夠的內(nèi)存來防止崩潰。因此，我們開始通過將CSS 的visibility屬性設(shè)置為hidden 來隱藏流的獨(dú)立頁面（圖2表示“隱藏”的頁面）。經(jīng)過這種調(diào)整，我們不僅看到了更多的內(nèi)存被回收（這樣應(yīng)用程序就不會(huì)崩潰），而且渲染速度也更快，因?yàn)闉g覽器不會(huì)為界面上“隱藏”的頁面進(jìn)行繪制。

技巧3：刪除頁面

采用隱藏的頁面可以覆蓋80％的情況。但是余下的20％仍然會(huì)導(dǎo)致應(yīng)用程序崩潰！我們更進(jìn)一步，開始刪除不需要的頁面。作為副作用，如果我們刪除當(dāng)前頁面左側(cè)的頁面，頁面流會(huì)左移，而用戶將失去所在位置。為了保持滾動(dòng)位置，我們不得不在移除頁面時(shí)（即DOM節(jié)點(diǎn)）用同樣高度和寬度的空白頁面來取代（圖2中示意的“占位符”）。例如，如果用戶正在瀏覽第5頁，我們刪除第0頁，并用占位符取而代之。

采用了上述的3種技術(shù)，我們的流開始類似于下面圖里的樣子。 正如你可以在圖1中看到的一樣，如果用戶正在查看第3頁，前一頁和后一頁將完全加載。而當(dāng)用戶決定向前或者向后翻頁時(shí)，他可以看到完全呈現(xiàn)的頁面。當(dāng)用戶試圖滾動(dòng)時(shí)，我們開始加載圖像并渲染頁面。它可以在iPad模擬器上完美運(yùn)行，但在實(shí)際設(shè)備上，你可以看到滾動(dòng)性能的下降。

圖1

圖2

正如圖2所示，當(dāng)用戶翻動(dòng)到第5頁，第0和第1頁將會(huì)被刪除，第2頁將會(huì)隱藏，而第3頁移除了所有圖像。此時(shí)，用戶可以繼續(xù)向前翻頁，其它頁面將根據(jù)它們和可見頁面之間的距離來決定是移除圖像、隱藏還是刪除自身。

我們不得不為不同版本的iPad使用一個(gè)可變大小的“窗口”。例如，iPad1內(nèi)存最少，所以我們不得不給它一個(gè)非常小的窗口：

[html]

1. getConfig : function() {
2.  
3. //默認(rèn)設(shè)置
4. var config = {
5. size : 3,
6. maxVisibleOnOneSide : 1,
7. };
8.  
9. //根據(jù)設(shè)備更新設(shè)置
10. if($isDesktop || $native.isNative() && $os.ipad) {
11. //檢測(cè)是ipad1還是ipad2
12. if($isDesktop || $native.getDeviceVersion() > 1) {
13. config.size = 7;
14. config.maxVisibleOnOneSide = 2;
15. }
16. }
17. return config;
18.  
19. }

 

技巧4：避免縮放和盒陰影

按照之前的經(jīng)驗(yàn)，我們使用兩個(gè)HTML / CSS的優(yōu)化技巧來改善性能：

• 通過HTML IMG標(biāo)簽中指定寬度和高度屬性來避免客戶端縮放圖像
• 避免CSS盒陰影：它在WebKit下很慢

技術(shù)5：減少DOM節(jié)點(diǎn)

經(jīng)過上述優(yōu)化，你是否預(yù)期應(yīng)用再也不會(huì)崩潰？錯(cuò)了！在測(cè)試過程中，上述技巧讓應(yīng)用程序運(yùn)行的時(shí)間更長，但一段時(shí)間后它仍然會(huì)崩潰。

根據(jù)之前iPhone應(yīng)用的經(jīng)驗(yàn)，我們知道保持DOM節(jié)點(diǎn)最少是平滑滾動(dòng)和保證足夠內(nèi)存的關(guān)鍵點(diǎn)。 記住這一點(diǎn)后，我們將所有占位所用的節(jié)點(diǎn)合并為一個(gè)虛擬的，相同大小的節(jié)點(diǎn)。結(jié)果是：不管我們滑動(dòng)到多少頁，頁面流不會(huì)在任何設(shè)備上崩潰！最終機(jī)制如圖3所示：

圖3

技術(shù)實(shí)現(xiàn)的視頻

這里有一個(gè)當(dāng)用戶滑動(dòng)翻頁時(shí)，DOM所表現(xiàn)出來行為的視頻。左邊我們?cè)贑hrome窗口中加載頁面流。而在右邊，我們通過Chrome的開發(fā)者工具來展示如何添加或刪除節(jié)點(diǎn)和通過虛擬頁面的寬度來填補(bǔ)被刪除的網(wǎng)頁。 請(qǐng)注意DOM節(jié)點(diǎn)是如何保持在一個(gè)恒定的數(shù)量的，以及UL 的第一個(gè)li節(jié)點(diǎn)（“虛擬”節(jié)點(diǎn)）大小是如何增長的（你可能需要全屏播放視頻來看）。

失敗的嘗試

我們并沒有在第一時(shí)間得到正確的結(jié)果，所以必須要列出我們一些曾經(jīng)失敗的嘗試。我們最開始使用多個(gè)UIWebViews來各自渲染一個(gè)頁面并用UISwipeGestureRecognizer來翻頁。 然而我們很快就意識(shí)到，在本地應(yīng)用程序使用多個(gè)Web視圖在內(nèi)存和性能方面是一種糟糕的方式。

隨后我們嘗試了和3-DIV類似的方法。它可以工作，但是我們對(duì)滑動(dòng)翻頁的性能并不滿意。 有時(shí)如果用戶在翻頁，我們同時(shí)在渲染一個(gè)頁面，單線程的UIWebView 將無法添加到頁面流里面。

---