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

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

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

• LinkedIn and themobile web

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

• Now, with more Node.js

大量使用了node.js。

• “Responsive design” just doesn’t work

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

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

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

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

作者：TrunalBhanse

譯者：蔣宇捷

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

什么是“流”？

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

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

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

技巧1：移除圖像

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

技巧2：隱藏頁面

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

技巧3：刪除頁面

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

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

圖1

圖2

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

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

[html]

1. getConfig : function() {
2.  
3. //默認設(shè)置
4. var config = {
5. size : 3,
6. maxVisibleOnOneSide : 1,
7. };
8.  
9. //根據(jù)設(shè)備更新設(shè)置
10. if($isDesktop || $native.isNative() && $os.ipad) {
11. //檢測是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)驗，我們使用兩個HTML / CSS的優(yōu)化技巧來改善性能：

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

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

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

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

圖3

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

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

失敗的嘗試

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

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

---