開發移動 Web 應用程序：何時、為什麼以及如何

地球上有 68 億人，其中 51 億人擁有手機。 而今天，這些設備中越來越多的設備是智能手機。 根據皮尤研究中心最近的一項研究，在過去 5 年中，通過智能手機訪問互聯網的用戶數量增加了一倍多，下載和使用移動應用程序的用戶數量也增加了一倍多。 在手機上使用互聯網或電子郵件的人中，超過三分之一的人主要通過他們的手持設備上網。

事實上，移動計算正變得越來越普遍……而且它很棒。

當然，除非它不是。

作為移動設備用戶，沒有什麼比設計不佳的移動 Web 應用程序甚至原生應用程序更令人沮喪和難以駕馭的了。

作為一名移動應用程序開發人員，沒有什麼比努力支持盡可能廣泛的移動客戶端更令人惱火的了，每個移動客戶端都有自己令人沮喪的特質。 無論您選擇開發移動網絡、原生應用程序還是混合應用程序，支持多種移動瀏覽器、更多奇特的設備以及掌握各種平台確實是一種非常痛苦的體驗。

當然，今天並不是每個開發人員都需要擔心支持移動客戶端。 但移動設備和應用程序日益普遍的性質強烈表明，那些今天不需要支持移動客戶端的人在不久的將來很可能需要這樣做。 因此，如果您還沒有考慮開發移動應用程序，那麼您可能應該考慮。

移動 Web 應用 vs. 原生應用 vs. 混合應用

與大多數技術選擇一樣，對於要開發的移動應用程序類型，沒有一刀切的答案。 有許多 Web 應用程序最佳實踐需要考慮，但並非所有這些都是技術性的。 你的目標受眾是誰？ 他們更喜歡移動網絡還是原生應用？ 原生應用和混合應用有什麼區別？ 您擁有哪些開發資源，他們最熟悉哪些移動技術？ 您為您的產品設想的許可和銷售模式是什麼？

一般來說（儘管總是有例外），移動網絡應用程序路由比原生移動應用程序路由更快、更便宜，尤其是當目標是支持廣泛的設備時。 相反，移動設備的原生功能（如運動傳感器等）可能對您的應用程序至關重要，但只能通過原生應用程序訪問（因此，這將使移動 Web 應用程序的選擇成為非給你的開胃菜）。

除了舊的 Web 應用程序與原生應用程序的問題之外，混合移動應用程序可能是您的正確答案，具體取決於您的要求和資源限制。 混合應用程序，如原生應用程序，在設備本身上運行（而不是在瀏覽器內部），但使用 Web 技術（HTML5、CSS 和 JavaScript）編寫，通常由混合應用程序框架支持。 更具體地說，混合應用程序在本機容器內運行，並利用設備的瀏覽器引擎（但不是瀏覽器）來呈現 HTML 並在本地處理 JavaScript。 Web 到本機的抽象層允許訪問在移動 Web 應用程序中無法訪問的設備功能，例如加速度計、相機和本地存儲。

但無論您做出何種選擇——無論是移動網絡應用程序、原生應用程序還是混合應用程序——都要小心充分研究並確認您的假設。 例如，出於本移動 Web 應用程序開發教程的目的，您可能已經決定為電子商務開發一個本地移動應用程序來銷售您的產品。 但是，據 Hubspot 稱，73% 的智能手機用戶表示他們使用移動網絡而不是本地應用程序進行購物......所以，在這種情況下，你可能賭錯了。

然後，當然，還有時間和預算的實際考慮。 正如我最喜歡的諺語之一所說， “更快、更好、更便宜……選擇任何兩個” 。 雖然上市時間和成本限制在 Web 應用程序開發中至關重要，但在過程中不要對質量做出過分妥協也很重要。 初次體驗不佳的用戶很難恢復信心。

事實上，移動網絡、原生和混合應用程序都是完全不同的野獸，每一種都有自己獨特的優勢和挑戰。 本移動 Web 開發教程特別側重於在開發功能強大、直觀且易於使用的移動 Web 應用程序時採用的方法和工具，以及應避免的陷阱。

移動 Web 應用開發需要詳細規劃

確定您（或您客戶）的需求是應用程序開發、移動或其他方面最重要的最佳實踐之一。 仔細研究目標功能以確定它們是否可以在您的移動 Web 應用程序中實現。 當您已經投入時間和資源來設計基於 Web 的界面和支持基礎架構時，意識到您的一個或多個基本客戶端功能不受支持，這是非常令人沮喪且非常低效的。

移動網絡應用程序開發新手的另一個常見問題是假設桌面瀏覽器的基於網絡的代碼將在移動瀏覽器中“按原樣”工作。 不是。 肯定存在差異，如果你不知道它們，它們肯定會咬你。 例如，HTML5 <video>標籤的自動播放功能不適用於移動瀏覽器。 類似地，現在大多數移動瀏覽器不支持（或至少不始終支持）CSS transition和opacity屬性。 您還會遇到移動平台上的某些 Web API 方法的問題，例如需要 Adob​​e Flash 的 SoundCloud 音樂流 API，大多數移動設備不支持該 API。

移動 Web 應用程序開發中一個特別複雜的因素是移動設備的壽命往往比桌面顯示器的壽命短得多（美國手機的平均壽命約為 21 個月）。 這些較短的設備壽命，伴隨著新移動設備和技術的不斷發布，產生了不斷變化的目標設備格局。 雖然在瀏覽器中工作確實通過使您免受許多特定於設備的問題的影響而在一定程度上緩解了這個問題，但您仍然需要設計一個支持許多不同屏幕分辨率的基於瀏覽器的視圖（以及針對橫向和縱向方向進行適當調整） ）。

還需要考慮支持 Apple 的 Retina 顯示器（液晶顯示器的像素密度足夠高，以至於人眼無法在典型的觀看距離上辨別單個像素）。 包括 iPhone、iPod Touch、iPad、MacBook Pro、iPad Mini 和 iPad Air 在內的幾款 Apple 產品都提供 Retina 顯示屏。 特別是對於移動 Web 應用程序，重要的是要意識到 Retina 顯示屏會使低分辨率圖像（通常提供給移動設備）看起來很模糊，並且可能會出現像素化。 在這些情況下，最好的應用程序開發解決方案是讓服務器識別出請求來自 Retina 設備，然後向客戶端提供替代的更高分辨率圖像。

如果您想使用一些很酷的 HTML5 內容，請記住提前驗證您正在尋找的功能是否在您的客戶可能使用的設備環境中受支持。 例如，在 iOS 6 及更高版本中，不支持導航器getUserMedia功能，因為相機只能通過本機應用程序訪問。 caniuse.com 和 html5test.com 是檢查特定設備和瀏覽器支持的兩個重要資源。

CSS3 媒體查詢還可以幫助您為每個設備提供定制的內容。 下面是一些用於捕獲不同設備特徵的示例代碼，例如像素密度、屏幕分辨率和方向：

 /* For lower than 700px resolutions */ @media (max-width: 700px) { ... } /* Same as last but with the device orientation on land scape */ @media (max-width: 700px) and (orientation: landscape) { ... } /* Including width and orientation you can add a media type clause, in this case 'tv' */ @media tv and (min-width: 700px) and (orientation: landscape) { ... } /* for low resolution display with background-image */ .image { background-image: url(/path/to/my/image.png); background-size: 200px 300px; height: 300px; width: 200px; } /* for high resolution (Retina) display with background-image */ @media only screen and (min--moz-device-pixel-ratio: 2), only screen and (-o-min-device-pixel-ratio: 2/1), only screen and (-webkit-min-device-pixel-ratio: 2), only screen and (min-device-pixel-ratio: 2) { -repeat; background-size: 200px 400px; /* rest of your styles... */ } }

優化您的移動 Web 應用程序的性能

“天哪，這東西太慢了！” 作為移動 Web 應用程序開發人員，這些可能是您最想從某個用戶那裡聽到的最後一句話。 因此，您必須仔細考慮如何減少和優化每個字節和服務器傳輸以減少用戶的等待時間。 期望傳輸總是通過 WiFi 網絡完成是不現實的，您應該知道，60% 的移動網絡用戶表示他們希望網站在 3 秒或更短的時間內加載到他們的手機上（來源）。 同樣，谷歌發現，每增加 5 秒的加載時間，流量就會下降 20%（還值得注意的是，搜索引擎將加載時間視為其頁面質量得分計算的一部分）。

作為本移動 Web 應用程序開發教程的一部分，這裡有一些技巧可以幫助優化移動 Web 應用程序的性能並最大限度地減少延遲：

• 圖像優化。 眾所周知，圖像加載時間是影響移動設備頁面加載的最大性能問題之一。 使用在線圖像優化器（例如 smushit.com）有助於解決此問題。
• 代碼壓縮。 根據您擁有的代碼量，壓縮 JavaScript 和 CSS 文件可能會對性能產生重大影響。
• 數據庫查詢。
  • 一些移動設備瀏覽器接受的 cookie 不如桌面瀏覽器多，這可能導致需要執行比平時更多的查詢。 因此，在支持移動 Web 應用程序客戶端時，服務器端緩存尤其重要。
  • 請記住使用適當的過濾器來阻止 SQL 查詢注入，否則可能會危及您的站點和服務器的安全性。
• 內容交付網絡 (CDN)。 如果您計劃提供大量視頻、圖像、音頻文件或其他類型的媒體，強烈建議使用 CDN。 一些更常見的商業 CDN 包括 Amazon S3、Microsoft Windows Azure 和 MaxCDN。 使用 CDN 的優勢很多，包括：
  • 改進的下載性能。 利用 CDN 的資源，您可以分配負載、節省帶寬並提高性能。 更好的 CDN 提供更高的可用性、更低的網絡延遲和更低的數據包丟失。 此外，許多 CDN 提供全球分佈的數據中心選擇，使下載可以從更靠近用戶位置的服務器進行（導致更少的網絡躍點和更快的下載）。
  • 更多並發下載。 瀏覽器通常會限制與單個域的並發連接數，之後會阻止其他下載，直到之前的下載之一完成。 從同一站點下載許多大文件時，您經常可以看到此限制。 每個額外的 CDN（在不同的域上）都允許額外的並發下載。
  • 增強分析。 許多商業 CDN 提供使用報告，可以補充您自己的網站分析，並可以更好地量化視頻觀看和下載。 例如，GTmetrix 有一個出色的網站報告工具，用於監控和優化您網站上加載的資源。

移動 Web 應用程序開發工具

“為正確的工作選擇正確的工具”是一句古老的格言，它同樣適用於軟件開發，就像它適用於任何其他領域一樣。 本教程提供並介紹了一些用於移動 Web 應用程序開發的更流行和廣泛使用的工具，但請記住，很可能還有其他工具是用於開發移動 Web 應用程序的“正確”工具，具體取決於您的要求和可用資源。

選擇正確的 JavaScript 移動 Web 應用程序框架

由於移動 Web 應用程序開發往往會帶來許多相同的常見挑戰——例如跨瀏覽器兼容性以及移動瀏覽器中的 HTML 和 CSS 不一致——已經開發了專門用於解決這些問題的框架（基於 HTML5 和 CSS3）和在各種智能手機和平板電腦上盡可能完美地工作。 這些移動網絡應用程序框架中的大多數都是輕量級的，這有助於促進快速移動網絡瀏覽，而不會影響您網站的外觀和感覺。

將我們的視野擴展到移動領域之外，如果有一個流行的 JavaScript 框架值得一提，那就是 jQuery。 如果您熟悉桌面版本，我建議您嘗試將 jQuery Mobile 用於您的移動 Web 應用程序。 它有一個小部件庫，可將語義標記轉換為手勢友好格式，使觸摸屏上的操作變得容易。 最新版本由一個非常輕量級的代碼庫組成，其中包含許多真正可以改善您的 UI 的圖形元素。

另一種替代品 Sencha Touch 也在迅速獲得市場份額。 它提供了出色的整體性能，並有助於生成在很大程度上看起來和感覺像原生界面的移動 Web 用戶界面。 它的全功能小部件庫基於 Sencha 的 ExtJS JavaScript 庫。

以下是比較 jQuery Mobile 和 Sencha Touch 時需要考慮的一些關鍵差異：

• 看和感覺。 一般來說，Sencha Touch 應用程序的外觀和感覺比 jQuery 移動應用程序更清晰和優越，但重要的是要記住，這種反應往往是高度主觀的。
• 可擴展性。 jQuery Mobile 提供了許多 3rd 方擴展，並且本質上被設計為高度可擴展的，而 Sencha Touch 目前更像是一個“封閉”框架。
• 設備支持。 與 Sencha Touch 相比，jQuery Mobile 目前針對的設備橫截面更大。
• HTML“對比” JavaScript。 jQuery 主要以 HTML 為中心（即，在 JavaScript 中擴展和操作現有的 HTML），而 Sencha Touch 編碼則完全基於 JavaScript。 （順便說一下，這是一個例子，說明您的開發團隊的技能組合在您選擇技術時非常重要。）
• 外部依賴。 jQuery mobile 需要 jQuery 和 jQuery UI 來進行 DOM 操作，而 Sencha Touch 沒有外部依賴項。
• 學習曲線。 大多數開發人員發現 jQuery 的啟動時間少於 Sencha Touch，這可能是由於大部分 Web 開發人員已經熟悉標準 jQuery 庫。

響應式框架和移動 Web 應用程序

近年來，越來越多的響應式框架開始出現，其中兩個目前最流行的是 Bootstrap 和 Foundation。 簡而言之，響應式框架簡化並簡化了基於 Web 的響應式 UI 設計和實現，將最常見的佈局和 UI 範例封裝到一個可重用、性能優化的框架中。 這些框架大多基於 CSS 和 JavaScript，其中許多是開源的、免費下載且易於定制的。 除非您有一組非常特殊的要求，否則使用其中一個框架可能會降低設計和實現移動 Web 應用程序的工作量。

檢查兩個主要選項 Bootstrap 和 Foundation，需要考慮的一些關鍵差異包括：

• 目標平台。 雖然 Bootstrap 確實支持移動設備、平板電腦和桌面設備，但它主要面向桌面使用。 另一方面，Foundation 基本上適用於所有屏幕尺寸和類型。
• 瀏覽器兼容性。 Bootstrap 兼容 IE7 或更高版本，而 Foundation 僅兼容 IE9 或更高版本。
• 佈局和組件的多樣性。 Bootstrap 的 UI 元素集合比 Foundation 提供的要多得多。
• 自動調整大小。 使用 Foundation，網格會根據當前瀏覽器的高度和寬度進行收縮和拉伸，而 Bootstrap 僅支持基於標準屏幕尺寸集的預定義網格尺寸集。

調試和測試移動 Web 應用程序

調試移動 Web 應用程序可能會很棘手並且有些令人沮喪，特別是如果您需要四處尋找不同的設備進行測試，或安裝 SDK 以模擬（通常不完美）目標客戶端平台。

在這種情況下，移動 Web 開發（與原生應用程序開發相比）的一個明顯優勢是您可以利用標準的基於瀏覽器的開發人員工具來調試您的應用程序。 根據我個人對遠程調試的偏好，我在本應用程序開發教程中推薦的是帶有 DevTools 的 Chrome。 其他標準選項包括帶有 Firebug 的 Firefox 或 Opera 的 Dragonfly 工具。

我喜歡 Chrome 及其 DevTools 的一些原因包括：

• Chrome 的 DevTools 中的移動模擬器。 這可能是選擇 Chrome 來調試移動 Web 應用程序的唯一充分理由。 主要功能包括模擬觸摸事件、用戶代理欺騙、網絡帶寬限制、地理位置覆蓋、設備方向覆蓋和 CSS 媒體類型模擬。
• 交互式編輯器。 能夠即時編輯 JavaScript 或 CSS。
• 高級 JavaScript 調試器。 允許 DOM 斷點並提供分析 JavaScript 代碼執行時間的能力。
• 內置 JSON 和 XML 查看器。 避免需要任何插件來檢查服務器響應。
• 直接通過 USB 支持 Android 調試橋 (ADB) 協議。 便於遠程調試會話的簡單實例化。 （這是谷歌關於如何在 Chrome 中開始遠程調試的一個很好的教程。）
• 動態檢查資源。 允許您檢查應用程序的本地數據源，包括 IndexedDB 或 Web SQL 數據庫、本地和會話存儲、cookie 和應用程序緩存資源。 您還可以快速檢查應用程序的視覺資源，包括圖像、字體和样式表。

要測試您的 Web 應用程序的佈局和交叉瀏覽兼容性，您還可以使用一些有用的在線工具，例如 BrowserStack。 只需輸入您的應用程序的 URL，選擇瀏覽器、版本和操作系統，您就會在該環境中獲得站點的模擬視圖（和加載速度）。 用於此目的的另一個有用工具是 CrossBrowserTesting。

包起來

隨著當今市場上和使用中的移動設備數量、種類和復雜性的持續快速增長，對有效、用戶友好、高性能移動應用程序的需求可能會大幅增加。 因此，能夠智能高效地開發這些應用程序將繼續至關重要。

在移動設備的 Web、本機和混合移動應用程序選項之間進行選擇時，必須考慮許多因素。 每個都有自己的優勢，但移動 Web 應用程序通常代表您最有效的開發（以及上市時間）選項。 如果您選擇走這條路，我希望這個移動 Web 應用程序開發教程能幫助您更直接、更成功地到達目的地。