別闖進Hybrid App的誤區

　　Hybrid App，一種開發模式，兼顧Web和Native的一種開發模式。有人說它把Web App扼殺在搖籃裡，有人說它把Native App引向一個新階段。我說，它是一把雙刃劍，千萬別闖進它的誤區。本文是筆者在實踐Hybrid App開發模式過程中總結出的一些經驗教訓，供讀者參考。Hybrid App雖好，可萬萬不能倉促選擇，盲目運用。

　　智慧手機日益普及，移動網際網路亂戰日趨白熱化，開發一個應用早就不是技術圈熱議的話題，iOS和Android上的App已經成了每個網際網路產品的標配。“唯快不破”也是中被移動網際網路人尊為鐵律，快速迭代，高效開發，低成本上線是每一個App開發團隊追求的目標。同時，隨著HTML 5的不斷升溫和智慧手機硬體效能的提高，Hybrid App的概念應運而生。這種“Native搭臺，HTML 5唱戲”的Hybrid App開發模式一時間受到各個開發團隊追捧，快速進入了大量開發團隊，成為主流開發模式。

　　Hybrid App優點眾多，Web前端工程師0成本介入，不依賴版本的實時更新，快速實現跨平臺需求，等等。而另一個方面，2012年Hybrid App的踐行者Facebook決定大量棄用App中的HTML頁面，轉向更加Native化的方案。Facebook的這一舉措也給Hybrid App方案的敲響了警鐘，這似乎並不是一個完美的方案。

 

　　本文主要跟大家分享一下我團隊和個人在Hybrid App的實踐中遇到的問題，提醒大家不要闖進Hybrid App的誤區。

　誤區一：為了HTML 5而Hybrid App。

　　HTML 5在Hybrid App模式中是一個最常被提起的概念。HTML 5作為一個HTML 4.0.1和XHTML 1.0的升級版，基於舊版本有更強大的表現功能，並加入了Local Storage等技術，確實為Web頁面提供了更大的想象空間和更多的可能性。但HTML 5處在目前的發展階段，受到瀏覽器相容性和手機硬體效能水平的影響，它所能提供的功能與Native仍然有很大差距。

　　所以，我認為作為工程師要明確一款App採用Hybrid App模式的根本原因是什麼。作為一款App其最根本的功能是滿足使用者的需求，而並不是服務某項新技術。因此當決定採用Hybrid App去構建一款應用時，應該從應用本身功能特點和整個團隊的開發資源配比統一考慮，是否有必要同時又有能力去駕馭一款“Native搭臺，HTML唱戲”的Hybrid App。類似“HTML 5的時代已經到來，如果我們不這麼做就變土鱉了，錯過這場技術革新的大潮，終將被這個時代所淘汰”的話真不是一個有責任心的工程師應該發出的聲音。

　誤區二：忽略關鍵因素

　　在談到Hybrid App的場合我們更多提及的是它有諸多優點，如何架構一個Hybrid App，怎麼讓Web和Native和諧共處，然而Web開發中會被忽略的一些因素少被提起，這些因素又恰恰經常是一個Web頁面能否正常執行在App中的決定性因素。

　　Web開發是基於PC的一種開發模式，開發者使用PC瀏覽器模擬App中的Web View進行除錯。PC瀏覽器與手機Web View的區別是巨大的，能支配的CPU資源，最大佔有的記憶體，執行的網路環境，滑鼠操作與觸控操作的區別，瀏覽器對CSS/JS的解析和對事件處理，等等。

　　App工程師，無論是iOS還是Android，最敏感的一個問題莫過於記憶體管理，而在Web開發則對這個問題沒有過多注意。這就經常導致同一個功能介面Native實現中會通過一些技術手段，把記憶體容量控制在作業系統允許的範圍內保證App正常執行。如果以Web方式接入App的頁面沒有一個明確的標準和嚴格的驗收機制，相應的Web實現則不會過多考慮這方面的問題，而且瀏覽器也沒有給前端工程師提供足夠的Api支援處理記憶體問題，導致在某些條件下造成App無法正常執行，甚至Crash。

　　同樣的問題會出現在網路環境方面，雖然現在wifi覆蓋越來越廣，3G網路也日益普及，但App執行的網路環境與PC相比仍然有著巨大差距，wifi和蜂窩網路的切換，基站變化等諸多因素都會導致網路間歇性斷開。Web開發總是預設有一個穩定的網路環境，因此在對於不穩定網路環境問題的處理上也有所欠缺。沒有明確的對於低速網路或不穩定網路訪問的處理，在很多情況下這些頁面也會非常不給面子。

　誤區三：富互動導致體驗差

　　這裡所謂的體驗問題一分為二：一是與手機平臺預設互動習慣不一致的體驗，二是與同樣功能Native介面存在的體驗差距。

　　無論在Android還是iOS平臺上，都有各自的一套互動習慣，包括視覺風格，介面切換，操作習慣等，與Web習慣完全不同。如果使用Web方式開發富互動的頁面，或多頁面功能就會出現這樣的問題。

　　以iOS介面切換為例，系統風格是新介面自右向左推入，後退時介面自左向右推出，而舊介面保持狀態。Web開發的預設習慣則是重新整理頁面，無論新載入頁面或是後退，都會對頁面進行重新整理。因此使用Web模式開發多介面功能就面臨這樣的互動習慣差異，造成體驗上的損失。當然Web方式也可模擬Native的互動方式，但這樣的模擬首先提高了開發成本，有悖於最初的高效原則，從效果上看，也很難達到Native的流暢性。

　　另一個方面，也是上述提到的與Native相比，同樣的功能在效能上存在巨大差距。Web介面上JS對HTML Node的操作需要消耗大量的CPU資源，手機CPU的效能還不能與PC相提並論，就算在智慧手機之間，硬體水準也參差不齊，一個可以在iPhone 5上流暢執行的介面，跑到三星S III上很可能就卡住不動了。所以我們經常可以發現一些富互動頁面上的操作無法達到令人滿意的流暢度，而流暢度也正是使用者評價一款App優劣的最直觀因素。

　誤區四：跨平臺

　　一次開發，跨平臺執行是Web的優勢，這也是很多App採用Hybrid模式的重要原因之一。相容性問題在Web開發過程中往往不被關注，但當下智慧手機的軟硬體版本眾多，相容性絕對是一個不容忽視的問題。

　　以Android手機為例，諸多主流品牌都有各自定製過的作業系統，瀏覽器核心對JS和CSS的解析，事件處理等方面都存在區別。以HTC One為例重疊在一起的層在某些情況下會對點選事件透傳，而其他多數平臺則不存在這個問題。並且目前移動平臺的開發框架還沒有完全成熟，可以很好的解決相容性問題。所以就要求開發者在開發過程中要對相容性做充分測試，對於某些特殊版本進行特殊處理。

　　即使在相對統一的iOS平臺，不同版本之間也存在較大差異。例如：在iOS 4.x版本中CSS甚至不支援position fix的屬性，4英寸螢幕的裝置無法很好的支援apple-mobile-web-app-capable屬性，等等。

　誤區五：互動一致性。

　　互動一致性是一個非常容易被誤讀的概念，“一致性”經常被理解為同一個應用在各種平臺和場景下要有一致性的體驗。我認為在移動平臺開發過程中，“一致性”應該是App視覺和互動習慣與其執行平臺的習慣保持一致。而Web開發“一次開發，跨平臺執行”的特性與此存在一定程度上的衝突。

　　以“返回上一頁面”的操作為例，在iOS平臺上在頁面頂部始終存在一個44畫素高的導航欄，左側有一個返回按鈕用於返回操作，而Android平臺則習慣使用裝置提供的返回鍵操作。這個返回按鈕在iOS平臺可以通過絕對地址的方式連線到任何其他頁面，而在Android平臺返回按鈕和裝置的返回鍵則可能指向不同的位置。

　　例如這樣的一個流程：首頁->列表->篩選->重新整理過的列表，此時的返回操作被期望是導向首頁，則頁面上的返回按鈕可以通過絕對連結的方式實現，而Android裝置的返回鍵則只能返回上一個篩選頁面，再次返回是篩選前的列表頁。

　　Hybrid App方案是一把雙刃劍，一方面它平衡了Native App和Web頁面的優缺點，一定程度上解決了Native App開發過程中迭代慢，版本依賴，Native開發資源不足的問題，但另一個方面過度依賴Hybrid方案會造成Web前端開發成本快速上升，甚至造成App整體體驗下降，甚至造成功能缺失。

　　不要為了Hybrid而Hybrid，控制好方案中Native與Web的邊界。

　擴充套件閱讀

　　較早Mobtest針對Facebook的iOS App專門做的一片評測文章，闡述了使用大量HTML頁面的App出現的問題：http://blog.mobtest.com/2012/05/heres-why-the-Facebook-ios-app-is-so-bad-uiwebviews-and-no-nitro/

　　相關文件：Hybrid App開發實戰