DHH 談混合移動應(yīng)用開發(fā)
David，Ruby on Rails 作者，37signals 合伙人
暢銷書作家、演說家、賽車手、業(yè)余攝影師、顧家好男人
37signals 在2013年2月發(fā)布了 Basecamp 的 iPhone app，在此之前我們就使用原生開發(fā)（native）還是混合開發(fā)（hybrid）做了許多嘗試。在2012年項目啟動的時候，大多數(shù)人都傾向于原生開發(fā)。
Facebook 在2012年發(fā)布了他們新的 iOS app，為了獲得更好的用戶體驗，他們放棄了原來的 HTML5 混合開發(fā)方式?？紤]到2010～2011年的時候，HTML 在移動端的性能確實不盡如人意，這個決定在當時看來也在情理之中。2010年的時候我們覺得 iPhone 3G/3GS 夠眩夠快，但按照現(xiàn)在的標準來看它們就太慢了。因此在為移動應(yīng)用開發(fā)做架構(gòu)設(shè)計時，我們需要考慮新的移動設(shè)備的計算能力，而不是那些老的過時的設(shè)備。
移動開發(fā)架構(gòu)設(shè)計不需要過多考慮設(shè)備的性能
我們從一些測試中得出的一個結(jié)論是：現(xiàn)在的移動設(shè)備計算能力都很強，運行原生應(yīng)用和 HTML 應(yīng)用的效果差別不大，而 HTML 開發(fā)的成本則要比原生開發(fā)小得多。
當然這個結(jié)論在某些領(lǐng)域并不太適用。如果你要開發(fā)一個 3D 游戲，原生開發(fā)方式能夠帶來更好的游戲體驗。但如果你的移動應(yīng)用象 Basecamp 一樣側(cè)重信息處理，為了降低開發(fā)成本，你就可以考慮混合開發(fā)方式。我們就是如此，下面是我們?nèi)苿赢a(chǎn)品的發(fā)展軌跡：
第一代產(chǎn)品：原生外殼(native shell)＋嵌套WebView
這個版本就是一個簡單的原生外殼負責界面導航，嵌套一個 WebView 來顯示 Basecamp Rail application，顯示的基本上都是我們移動網(wǎng)站頁面，再加上一些特殊的樣式。
在移動網(wǎng)站的頁面上嵌套一個原生的殼，聽起來還是 Web 頁面，但實際帶給用戶的體驗確是非常不同。用戶可以在 Apple App Store 找到我們的 app，他們一旦登錄 app 后可以再也不用重新登錄（移動版本的 Safari 似乎會經(jīng)常清空 cookie，讓你不得不重新登錄）。我們的 app 大受歡迎，用戶評分在4和5之間。
整個 app 由一名程序員和一名設(shè)計師開發(fā)，成本不高，因為我們可以在已有的移動網(wǎng)站的基礎(chǔ)上開發(fā)。
如果我們當初開發(fā)完全原生的 app，用10個人的團隊1年半的時間也未必能完成。
第二代產(chǎn)品：原生外殼＋原生導航界面
幾個月前發(fā)布的 Basecamp Android app 是我們的第二代產(chǎn)品，我們在其中做了大量的改進。
從第一代 iPhone app 中我們感受到了原生導航界面的威力，所以在 Android 版本中，我們由 HTML 頁面導航轉(zhuǎn)向了原生導航界面。我們從 HTML 頁面生成原生導航界面，用戶體驗更加流暢，原生界面和 HTML 頁面的體驗差別越來越小，甚至很難區(qū)分哪些是原生部分，哪些是 HTML 。
Android 版本是由一兩個程序員和一個設(shè)計師開發(fā)（50%投入）完成的。我們重用了移動站點和 iPhone app 中使用的所有 webview，大大提高了開發(fā)效率，同時用戶也很買賬，超過1000名用戶打了4.5~5的高分。
很多公司在抱怨他們的 iOS 移動項目進展緩慢，Android 項目似乎更是如此。或許他們已經(jīng)習慣了 iOS 項目的開發(fā)流程，也許是因為 Android 的屏幕碎片化問題，但是這些對我們來說那都不是事。我們推出的 Android app 表現(xiàn)良好，重用了95%的代碼，開發(fā)團隊也一直保持在小規(guī)模。
因地制宜地運用原生開發(fā)方式
目前我們正在開發(fā)第三代產(chǎn)品，發(fā)布的平臺暫時保密，不過你應(yīng)該也不難猜到。在前兩代產(chǎn)品中，我們增加了原生導航界面的使用，同時進一步確定了以 webview 為核心的整體架構(gòu)。在第三代產(chǎn)品中，我們將因地制宜地選擇需要使用原生開發(fā)的功能，好鋼要用在刀刃上。
從之前的100% HTML，到現(xiàn)在的90% HTML +10%原生，我們會選擇最值得做原生開發(fā)的那10%的部分，最終目的是讓 app 原生部分和 HTML 部分的體驗沒有太大區(qū)別。
混合開發(fā)模式使用的技術(shù)
混合開發(fā)模式在技術(shù)很簡單，主要是處理 webview 的集成、Web 頁面的加載，以及原生內(nèi)容和 HTML 內(nèi)容之間的交叉鏈接，其實可能比你想像的還要簡單得多。
HTML 方面，我們的 Rails Web 應(yīng)用支持 Web 和移動兩大平臺，其中 Rails 4.1 feature of variants 起了很大的作用。
這也很大程度上有助于我們發(fā)布新功能。設(shè)想一下如果我們每次需要更新這么多平臺：Rails desktop app, a Rails API app, a client-side MVC app, a mobile web wrapper app, an Android app, and an iPhone app，像我們這樣只有10個程序員和7個設(shè)計師的公司根本無力承擔如此巨大的工作量。
除了工作量的減輕，bug 修復(fù)效率也提高了，因為大部分的代碼邏輯是在 Web 服務(wù)器端，我們可以隨時修改代碼并發(fā)布，不用通過 Apple App Store 的審批流程。所以我們的移動 app 和 Web 應(yīng)用一樣，也是持續(xù)部署。
就如我之前提到的，混合模式開發(fā)并不適用于所有情況。在2010年以前，那時手機的處理能力都不強，所以 HTML/JS 的體驗并不好，用戶也不喜歡。但是時過境遷，現(xiàn)在手機的處理能力大大提高了，HTML/JS 的性能也不再是一個問題。
混合開發(fā)模式對原生開發(fā)模式的挑戰(zhàn)
混合開發(fā)模式在降低開發(fā)復(fù)雜度方面有它的優(yōu)勢，如果你的產(chǎn)品是以顯示和處理信息為主，我認為都可以不同程度地采用這個模式。
對于小型團隊和公司而言，并不一定需要采用 iOS 原生 app 先行的模式。使用混合模式，不需要你重頭開發(fā)一個 app，這樣可以降低維護成本，將來擴展到其他平臺也更為方便。
當然我知道會有很多人質(zhì)疑這個模式，或許因為他們的 app 中有很多地方需要原生開發(fā)（也許僅僅是他們自己這樣認為罷了）。又或許他們已經(jīng)花了很多時間讓 app 里的 UITableView 看起來非常漂亮，以致如果其他地方不這樣的話顯得不是太完美。再或許大公司就是喜歡耗時耗力的原生開發(fā)，有錢就是這么任性。
無論怎樣，混合開發(fā)當下應(yīng)該能夠成為我們移動開發(fā)策略的一個選擇。如果你認為這是一個好的選擇，那么恭喜你，盡情愉快地玩耍吧！
原文鏈接：Hybrid sweet spot: Native navigation, web content
下面補充一些 David 答讀者問：
Mike Waite @ 2014-05-08：我很好奇你是如何決定哪些功能要用原生開發(fā)？
David @ 2014-05-08：主要靠感覺，這畢竟不是一門科學。如果你感覺你app的某一部分如果用原生開發(fā)會更好些，可以嘗試做快速原型（spike）。很多 時候我們通過這種方式證明我們的想法其實是錯的。當然如果你需要使用到手機上的功能如：攝像和其他設(shè)備時，HTML目前還不太適用，不過永遠也不要把話說 死。
Mike Parsons @ 2014-05-08：好文。很好奇你們是否使用 PhoneGap 或者 Cordova 這樣的框架，或者你們自己開發(fā)了一個？
David @ 2014-05-08：我們沒有使用任何框架。（此處省去xxx字）
Derick @ 2014-05-08：你怎樣解決 Android 瀏覽器渲染速度慢的問題？這也是 Android 平臺上更多人傾向開發(fā)原生app得原因。
David @ 2014-05-08：不知道你這個結(jié)論是近期的還是以前的？Basecamp 的 Android app 在我的 Nexus 5 和 HTC One 上面運行得非常流暢。
Derick @ 2014-05-08：就是最近。我猜測可能和你使用JavaScript的多少有關(guān)系。因為以我個人的經(jīng)驗，Android 上 JavaScript 的運行速度非常慢。如果你感興趣可以看看下面的文章：https://www.timroes.de/2013/11/23/old-webview-vs-chromium-webview/
David @ 2014-05-08：我們使用了很多JavaScript，當然沒有 Web MVC 客戶端用得那樣多。另外我們使用了 Turbolinks ：）
