開發移動網頁應用的一些技術指導

開發移動網頁應用的一些技術指導

 (2012-03-26 14:25:42)

轉載▼

標籤：  雜談

分類： 技術編程

雖然本文的主題主要針對移動開發，不過我認爲這些技術也適用於通常的網頁應用。個人全部決定和數據點都符合如下幾點：

• 只支持JavaScript(CoffeeScript和Dart是否兼容還有待觀察，不過我會盡可能避免選擇它們而引起的異常)
• 在最新的移動瀏覽器裏運行正常（如iOS 5, Android 4）

選擇MVC(模型－視圖－控制器)方案

模型－視圖－控制器方案用在天然界面的應用的開發裏已經數十年了。其基本思路是分離數據層（存儲，通信，數據）和表示層（用戶界面，動畫，輸入）。雖然有其它相似的模式，例如MVVM（Model View ViewModel），可是最主要的想法是要在表示層和數據層之間有明確區別，使得代碼可以更加簡潔和穩定運行。

 

目前已經有衆多JavaScript模型—視圖—控制器框架可使用。其中一些，如Backbone.js和Spine.js，都使用純代碼編寫，而另一些，像Knockout.js和Angular則須要DOM數據綁定屬性。對分離視圖和數據的MVC系統來講，依託HTML5的數據和DOM屬性彷佛有些不妥。所以我不使用Knockout和Angular框架。基於個人原始需求，Spine.js用CoffeeScript來寫比較簡單。

對於大部分框架來講，Backbone.js的使用時間更長（可能除了JavaScriptMVC，一個停用的項目），還擁有愈來愈多的開源社區。個人應用程序棧一直使用Backbone.js。爲了獲得更多選擇MVC的信息，我查看了TodoMVC，它實現了相同的Todo應用程序使用不一樣的MVC框架。你也能夠看看 MVC framework comparison這篇文章，它推薦Ember.js這個場景裏的新文件。我尚未機會使用它，可是它在個人計劃之中。

選擇一個模板引擎

若是想要在網絡上創建一個真正的應用程序，你不可避免地要創建大型DOM樹。相對使用JavaScript API操做DOM，它能夠更簡潔高效地使用基於字符串的模板，而不是寫HTML。通常來講，JS模板已經發展到使用奇怪的常規腳本，它在腳本標記內嵌入模板內容：<script id="my-template" type="text/my-template-language">...</script>。使用全部模板引擎的基本模式是把模板做爲一個字符串來加載並構建模板參數，而後經過模板引擎運行模板和相關參數。

Backbone.js依賴於Underscore.js，它是一種複雜語法寫的受限模板引擎。此外，還有其它模板可供選擇，例如jQuery Templates，Handlebars.js，Mustache.js。JQuery團隊開發的jQuery模板已通過時了，因此我沒有考慮它。Mustache是一個跨語言的模板系統，它的特色是簡單而且成熟，能夠支持儘量簡單的邏輯。事實上，Mustache中最複雜的構造是一種遍歷對象數組的方法。Handlebars.js至關依賴Mustache，它加入了一些不錯的功能，如預編譯模板和模板表達式。對我而言，我並不須要這些附加功能，也沒必要選擇Mustache.js做爲個人模板平臺。

通常來講，我認爲現有的模板框架在功能上差異都不大，所以選擇哪一個在很大程度上是我的喜愛問題。

選擇一個CSS框架

CSS框架是必不可少的工具，它使用便利功能（如變量）擴展CSS的功能集。這是一種建立分層CSS選擇器和一些更先進的功能的方法。這樣作實質上是建立了一種新的語言：CSS加強版（暫且叫它CSS++）。爲便於開發，一些框架在瀏覽器中執行一個JavaScript編寫的CSS++解釋器，而其餘框架則讓你監控一個CSS++文件，並在有任何更改的時候編譯它。全部的CSS框架都應提供命令行工具把CSS++編譯成CSS來部署。

就像模板語言同樣有不少功能類似的選擇。個人選擇是出於我的的語法偏好。我更喜歡SCSS，由於它避免了怪異的語法（如@）。SCSS的缺點之一是：它並無附帶一個JavaScript解釋器（有一個非官方的解釋器，可是我沒有試過），只使用一個命令行觀察器。其它相似的CSS框架，包括LESS和Stylus。

如何佈置視圖

HTML5提供了多種方式來佈置內容，但MVC框架並無提供使用這些佈局技術的建議，這有時讓程序員們很難作出決定。

通常來講，相對定位比較適合文檔，但不適用於應用。顯然，絕對定位應儘可能避免，尤爲是表格佈局。許多Web開發人員已經轉向使用浮動屬性對齊元素，但這並非構建應用程序視圖的最佳方法，由於它沒有優化相似於應用程序的佈局，從而致使許多奇怪的問題和infamous clearfix hacks。

多年來，通過對各類網絡佈局技術的實驗，我認爲一個固定位置和flexbox模型相結合的移動互聯網應用是一個理想的選擇。我使用的固定位置是固定在屏幕上的界面元素（標題，側邊欄，頁腳等等）。Flexbox模型則很是適合在頁面（水平或垂直方向）上佈置層疊視圖。它是惟一爲界面設計明確優化的CSS盒模型，與Android的Linearout管理頗爲類似。有關flexbox模型的更多信息，請閱讀Paul的文章，並注意該規範被替換爲一個新的且不向下兼容的版本。

自適應Web應用程序

最後一節是關於這一問題：我大力提倡建立設備特定的用戶界面。這意味着須要根據不一樣的狀況從新編寫視圖代碼部分。幸運的是，MVC模式使得重複使用多個視圖（如平板電腦和手機）的單一模式更加簡單。

IOS上的Flipboard軟件很好的演示了這一設想，它爲平板電腦和手機用戶的不一樣設備尺寸提供了相應的開發經驗。

手機界面進行優化以便單手垂直滑動。

 

平板電腦的界面方便雙手從不一樣方向操做。

 

輸入注意事項

處於移動狀態時，用戶與應用程序的主要交互方式是用手指觸摸屏幕。這與使用鼠標的交互不一樣，因爲屏幕上有額外的9點須要跟蹤，開發人員在編寫移動應用程序時儘可能少使用鼠標事件。此外，鼠標事件在移動中點擊有300ms延遲的問題（有一個著名的touch-based解決方法）。有關使用移動瀏覽器時這些事件的更多詳細信息，請參閱my touch events article這篇文章。

僅僅靠s/mousedown/touchstart/使用你全部的事件處理程序是不夠的。用戶但願可以靠一套全新的手勢使用觸摸設備，好比在屏幕上滑動，例如瀏覽圖像列表。雖然蘋果公司有一個不爲人知的gesturesAPI，但卻沒有一套網絡上開放的手勢檢測規範。事實上咱們須要一個JavaScript庫以便於識別一些經常使用手勢。

如何使其脫機工做

爲了讓一個應用程序脫機工做，你須要作兩件事情：

1.資源可用（經過AppCache，Filesystem API等等實現）

2.數據可用（經過LocalStorage，WebSQL，IndexedDB等等實現）

實踐中，在網絡上構建脫機應用是一個棘手的問題。通常來講脫機功能一開始就應該在應用程序中構建。若是不重寫重要代碼很難讓現有的網絡應用程序脫機工做。此外，各類脫機運行技術經常受到未知存儲的限制，而且沒法肯定超出限制時會發生什麼不可預料的狀況。最後，還有一些脫機技術問題，尤爲是AppCache，正像我在先前的文章中描述的。

編寫可以真正脫機運行的應用程序有一個很是有趣的方法：「先脫機」。換句話說，你寫的一切都是在沒有網絡鏈接的狀況下運行的，只有同步數據須要網絡鏈接。在Backbone.js MVC模型中，這能夠很好地適應自定義Backbone.sync適配器。

單元測試

通常來講，你的用戶界面很難進行單元測試。但若是你使用MVC模型徹底隔離用戶界面，那麼測試將變得簡單。Qunit是一個至關不錯的選擇，特別是它容許使用它的start()和stop()方法對異步代碼進行單元測試。

總結

總之，我使用Backbone.js MVC，Mustache.js模板，SCSS做爲CSS框架，CSS Flexbox渲染視圖，自定義觸摸事件，Qunit完成單元測試。經過這些編寫個人移動網絡應用程序。關於脫機支持，我仍將嘗試使用各類技術實現，並在之後的文章中介紹它們。雖然我相信這裏列出的每類工具（如MVC）十分必要，但我也認可本文中描述的許多技術是通用的（如Handlebars和Mustache）。

原文連接：A mobile web application tech stack