![]() |
VOOZH | about |
本文為《程式設計師》2016年12月期原創文章,未經允許請勿轉載,更多精彩文章請訂閱2017年《程式設計師》。
在即將過去一年,我經歷了兩個項目:一個是基於 React 與響應式設計的房地產搜索網站;一個則是基於 Angular.js 與 Ionic 1 的金融混合應用。而這兩個不同的項目,正好可以代表移動 Web 的兩個方向。在這一年裡,一些前端框架已經趨於穩定,我們可以看到諸如 React 這樣的框架在一些大型項目中的採用。除了這些常規的移動 Web
應用,在今年九月底微信小程序的火熱,也開啟了移動 Web 的一扇新門;Google 推出的 PWA 也讓越來越多的開發者看到了移動 Web 的更多可能性。
面臨的問題及考驗
儘管網絡速度正在變得越來越快,但是移動 Web 頁面的體積也越來越大。單頁面應用的體積在首次加載時,仍然值得我們好好研究——如何更快展示用戶需要的內容,而不是讓用戶在頁面加載的過程中等待著讓他們離開。除了使用服務端渲染來優化初次體驗,我們還需要設置緩存,使用一些技術策略來加快用戶打開的速度。
然而,我們仍然還面臨著一堆亟需解決的問題。比如在服務端採用微服務架構來加速開發,當我們需要在一個頁面里請求大量 API 時,微服務架構就會成為一個新的問題。當用戶在請求過程中切換頁面時,就需要中斷大量 Promise 請求。因此就需要使用 GraphQL 或 Falcor 這樣的 API 框架來減少客戶端 API 請求。
➤安全
除去上面這些內部因素,移動 Web 應用還飽受外部因素困擾。在2016年,我們發現越來越多的移動站點正深受運營商劫持的影響,由於 HTTP 協議是明文的,而流量都要經過運營商,因此運營商可以輕而易舉地在頁面中植入廣告。這時,解決問題的有效辦法就是全站 HTTPS。與此同時,對於安全的考慮也仍然值得注意。我們意外地發現一些移動 Web 網站只在前台做了數據校驗,而缺少後台的數據檢驗,這會帶來相當大的安全隱患。
➤臃腫的前端代碼
前端項目正在變得越來越臃腫,體積讓人難以接受。在缺乏單元測試的項目里,維護這樣的一個前端項目正在變得舉步維艱。當後台走向微服務的同時,前端走向微前端也變得可以接受。一個應用程式可將基本需求分解為不同的幾個前端頁面,如面向用戶、面向管理員。
儘管已經有了如 React 這樣的 CSS in JS 的框架,維護 UI 組件仍然是一個相當大的考驗。移動 Web 對於屏幕大小有更高的要求,響應式設計會帶來更多代碼。樣式代碼數量的增加,對於前端的樣式架構有了更大挑戰。如我們所見 SCSS 或 SASS 這樣的 CSS 預編譯器可以帶來更少的代碼,而對於項目中的新人來說,仍然是個問題——在項目進行過程中,我們往往關注於如何更快地交付功能。
相似地,我們也可以在社區開發的開源庫上看到一些「微前端」趨勢。藉助於 ES6 的模塊化功能,我們可以在項目中只 import 所需的函數,在使用 webpack 打包的過程中也會刪去那些不需要的模塊。過去我們使用一個庫的某個方法時,可能就會考慮直接創建一個類似的庫,而不是引入——原因是這個庫對於應用來說太大了。
框架及工具
從傳統 Web 網站到單頁面應用遷移的第一個難題是:是否真的需要單頁面應用?單頁面應用更多的是帶來用戶體驗的提升,然而很多網站並不需要這種變化,大部分網站只需要支持更好的響應式設計。
在上一個項目里,我們使用了 React 來替換之前的桌面及移動站點。除了代碼老舊之外,還有部分原因:業務變更時需要修改三份代碼。舊有的舊面網站代碼可以追溯到2010以前,難以維護;移動站點是在2013年底創建的,使用當時流行的 Backbone + Mustache + Require.js 技術棧;與此同時還有手機 App。
當我們決定做一個移動單頁面應用時,就需要開發考慮對於技術方案的選擇。
➤框架選型
而在這一年裡,開發人員在做技術選型時,發生了一些有趣的變化。首先是 React 對於大部分的開發人員來說,存在學習曲線比較陡峭的問題,JSX、虛擬 DOM、組件化、同構等,使其無法成為短期項目的首選;其次是 Angular 2.0 的跳崖性升級,使得相當多的開發人員無法選擇 Angular.js 1.x 的版本,而2.0在接近年底才完成,且周邊的組件還有待完善;因此,我們發現 Vue.js 由於其簡單並且容易上手,在今年顯得特別受歡迎。
幸運的是:上述三個框架,都有對於混合應用的應對方案。這使得我們在設計系統架構的時候,更容易復用代碼。
2016年裡,在移動和桌面 Web 使用 Angular.js,移動端使用基於 Angular.js 的 Ionic 框架是非常不錯的技術選型。Ionic 擁有相當多設計優美的 UI 組件,這些組件可以讓我們輕輕鬆鬆地做出移動應用。並且,我們也可以和 Web 端共用 filter、directives、services 等的內容。相信在2017年,Angular 2.0 搭配基於 Angular 2.0 的 Ionic 仍然是好選擇。
我們也可以使用 React 框架來做類似的事。儘管有相當多的開發者選擇使用了 React Native,但是這不意味著我們需要在移動端使用它。在移動端使用 Cordova + React 也是一個不錯的選擇——既然可以使用 React 做響應式設計來匹配不同的屏幕大小,那麼也可以很輕鬆地使用 Cordova + React 來達到同樣的目的。
同理於 Vue.js,儘管 Weex 還不是很成熟,但是使用 Cordova + Vue.js 也仍然不錯。
➤開發工具越來越完善
在這一年裡,我們發現能選擇的開發工具越來越多。不同的開發商都在不斷創造開發工具,這些工具可以幫助我們編寫出更好的代碼,開發出符合用戶需求的軟體。
現在市面上的主流前端開發工具都已經可以支持 ES6、TypeScript,並且不同的瀏覽器對於 ES6 的支持力度也在提高,Edge、Firefox、Chrome 對於 ES6 特性的支持度均在90%以上,而 Safari 瀏覽器則達到了100%。這也意味著對於面向 iOS 的移動 Web 應用,可以很隨意地在這些設備上使用 ES6 語言了。
並且各瀏覽器對於行動裝置的調試能力都在不斷提高。在開發移動 Web 頁面時,我們使用 Chrome 瀏覽器來匹配行動裝置。而在新版本的 Safari 里也提供了「進入響應式設計模式」的功能,它可以模擬常見 iPad、iPhone 顯示網頁,甚至可以模擬 iPhone 橫屏。
Adobe 在今年推出了 UX 工具 Experience Design(官方縮寫XD),可以為 UX 設計師快速創建出用於行動裝置的網站或者應用程式。這個工具除了具備響應式設計能力,還可以實現簡單的 App Demo,如在桌面上點擊某個頁面跳轉,並具備有頁面間跳轉的效果。這可以讓開發者更容易理解產品的設計原型,創建出更符合需求的產品。
提供更好的用戶體驗
對於在早期已經採用單頁面應用的團隊來說,他們面臨的一項新挑戰是:如何提供更好的用戶體驗。
相當有意思的一點是,我們發現業務人員對於移動 Web 的要求更高了,他們希望有著類似於移動應用的用戶體驗。過去,在移動 Web 領域使用 Tap 事件來代替 Click 事件只是一個開始——使用 FastClick 這樣的庫來規避 Click 事件的延遲。
手勢交互: 下拉時刷新在移動 Web 上已經不是新鮮的事,我們還要類似於微信的左右滑動切換不同的頁面,除此還會有旋轉、縮放等功能。
適配屏幕大小: 對於行動裝置來說,屏幕是個大問題,應用既要支持 iPhone 這樣的小屏幕,還要匹配上 iPad 這樣的設備。可以使用媒體查詢來解決,但設置合適的字體還是問題。px、em 已經很難滿足要求了,我們還需要 rem 這樣可以根據網頁的根元素來設置字體大小的單位。
過去,我們關注的移動 Web 流暢度主要集中於緩存。當緩存已經成為了業界的通用模式時,人們便開始尋求更多的解決方案。如對於流量來自 Google 的網站來說,他們可以使用 Accelerated Mobile Pages(AMP)技術來加快網頁的加載,這可以為新聞和博客網站帶來更快的訪問速度。
與桌面相比,移動 Web 頁面對流暢度有著更高的要求,這主要是受限於行動裝置。儘管新 iPhone 提供了相當快的處理能力,各大 Android 設備生產商在競爭中也在不斷提高設備的處理能力,但是仍然有相當多的用戶使用舊版行動裝置。
在移動網頁上,除了採用支持 Virtual DOM 的框架來提高性能,還可以採用 Virtual Scroll 機制——只渲染足夠填充 Viewport 大小的數據集,頁面滾動時再渲染新數據,以此改善移動端列表頁面數據過多的問題。
除了對於頁面本身的優化,還有相當多的內容是對於資源和 API 優化。Facebook 創建了 GraphQL 來減少 API 的請求,一次請求多個需要的 API;Netflix 創建了 Falcor 來合併多個數據源。這些都可以加快移動應用的響應速度,除此我們還注意到 Service worker 開始受到開發者追棒。
Service worker 是在 Web 應用和瀏覽器與網絡之間的代理伺服器,旨在創建更好的離線體驗。並且可以依據當前網絡是否可用、伺服器是否有內容更新來採取合適的策略。同時它還支持通知推送及後台 API。
在這一年裡,我們也看到了一些新東西正在展露頭角,Google 推出了 Progressive Web Apps(PWA),微信也推出了小程序。
用戶只需要在微信客戶端下載相應的小程序,就可以直接使用,用完即可離開。由於微信本身的封閉屬性,小程序的運營和推廣上仍然會有相當多的難點,同時也造成了一些傳播上的難題。
不過微信自帶了 WebView,開發者在開發時只需要針對不同作業系統的設備開發軟體即可,不容易再遇到不同版本上的瀏覽器差異。同時微信小程序使用自己的 Web 框架,開發者需要重新上手這個框架,由於小程序還處於測試版,仍然還有相當多的 Bug。
PWA 是 Google 在 Google I/O 2016 大會上強調的移動 Web 應用程式方向,我們可以翻譯為「漸進式應用」。它結合了 Web 和原生應用程式的優勢,提供了更好的用戶體驗:
它為開發混合應用的開發者提供了一個新方向,雖然受限於國內 Chrome 普及率,但是我們仍然很看好這項技術。
在這一年裡,我們也看到了 Google 正在推進 Web NFC API、Web Bluetooth API、Web USB API 等原生 API 的發展。現在,已經可以在 Chrome 瀏覽器上通過編寫 JavaScript 來開發藍牙應用,這也使得 PWA 可以製作出更富有質量的移動 Web 應用。
作者簡介: 黃峰達,ThoughtWorks 軟體開發工程師,CSDN 博客專家。長期活躍於 GitHub,專注於物聯網和前端領域。出版著作《自己動手設計物聯網》,以及《Growth:全棧增長工程師指南》等六本電子書,並譯有《物聯網實戰指南》。
技術之路,共同進步,歡迎投稿、約稿、給文章糾錯,請發送郵件至mobile@csdn.net。