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

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

第一篇《你絕對想不到的LinkedIn如何構建iPad新應用》主要包括三個方面的內容：

• LinkedIn and themobile web

LinkedIn開始越來越多的采用HTML5來開發移動Web應用。

• Now, with more Node.js

大量使用了node.js。

• “Responsive design” just doesn’t work

他們認為響應式網頁設計對簡單的、一次性的網站很有用，但是對應用或者社交網絡來說，它沒有那么好。

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

而下面一篇文章講述了LinkedIn是如何使用HTML5在iOS中實現平滑無限滾動以及內存和性能優化的。

LinkedIn iPad版：用HTML5的5項技術實現無限平滑滾動

作者：TrunalBhanse

譯者：蔣宇捷

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

什么是“流”？

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

移動設備上無限列表的挑戰

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

技巧1：移除圖像

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

技巧2：隱藏頁面

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

技巧3：刪除頁面

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

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

圖1

圖2

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

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

[html]

1. getConfig : function() {
2.  
3. //默認設置
4. var config = {
5. size : 3,
6. maxVisibleOnOneSide : 1,
7. };
8.  
9. //根據設備更新設置
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：避免縮放和盒陰影

按照之前的經驗，我們使用兩個HTML / CSS的優化技巧來改善性能：

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

技術5：減少DOM節點

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

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

圖3

技術實現的視頻

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

失敗的嘗試

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

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

---