本篇文章重點討論了日新月異的移動技術。在過去幾年間，移動應用以雷霆之勢席卷全球。我們在工作和休閑時間中使用互聯網的方式，已經隨著移動應用的前進腳步發生了變革。在此期間，許多創建移動應用的技術浮現在世間；而在開發應用的時候，人們也開始考慮“移動優先”的做法。然而，哪怕現在移動設備似乎早已無處不在，未來的時代卻只不過剛剛揭開帷幕。我們正在面對全新一代的移動設備，諸如可穿戴設備或眾多移動配件——正是它們構成了“萬物互聯”的世界。我們將面對全新的用戶界面，通過它們數據展示及指令接收處理。同時，我們還將看到，越來越多的公司將真正地踐行“移動優先”的思路。而在未來數年中，這一切都將影響我們設計、開發和測試軟件的方式。

[[127383]]

移動應用幾乎已經無處不在，因此我們不應該忽視，它們作為提供服務的輔助甚至是主要渠道的價值。不過，盡管大家都很清楚，為了獲得***的用戶量，我們的應用應該同時支持Android和iOS系統，但對于具體使用什么技術和工具開發適用于這些系統的應用，卻還存在著許多爭執。

在這一領域中，眾多圍繞著“原生應用”、“混合應用”和“HTML/JavaScript應用”的討論仍未平息。因此我們邀請了一些業界人士，針對應用開發分享他們各自的觀點。在這次討論邀請對象的名單中，包括了工具棧提供商和開發者：

• Chris Eidhof——iOS開發者、作家
• Daniel Gallo——Sencha的工程師
• Brian LeRoux——PhoneGap創作者
• Maxim Zaks——Wooga的游戲開發者
• Miguel de Icaza——Xamarin的CTO

記者：現在有著數量龐大、類型多樣的移動應用開發技術，用于構建基于交叉編譯器的原生應用、混合應用或是基于HTML5/JavaScript的應用。那么，請為我們講一講，你們各自青睞哪些技術，以及為何會對它們感興趣。

Chris：我們希望能夠為應用的最終用戶提供***體驗。基本上，這意味著 幾乎在應用的各個方面，我們都需要與蘋果提供的原生類庫非常緊密地結合。我們非常重視流暢的動畫，以及讓用戶能夠感覺輕松自在的界面。然而在許多非原生應 用中，用戶界面都讓人覺得還缺點什么。在我看來，只有當開發者正在構建一個圖形圖像工作負荷較低的游戲時，非原生應用才可能成為一個好的選擇。多年以來， 我為許多客戶重寫了應用，他們最初都從HTML5應用入手（大部分是因為他們認為這樣能夠節省資金），但最終的結果都非常令人失望——他們不得不從頭開發 原生版應用。

Daniel：我下面要說的內容，將會非常具有傾向性，因為我在Sencha工作，我們開發針對移動和桌面環境的Web應用框架，因此我的答案必然是：HTML5和JavaScript。

我相信，這條特別的技術路線能夠帶來許多便利，例如這里有著非常巨大的開發者人才市場，這些開發者都擁有Web技術（JS、HTML、CSS）經驗。

此外，在開發過程中，開發者可以非常輕松地在瀏覽器中，調試和測試編寫好的代碼，因為在此期間并不需要使用任何交叉編譯器，將 HTML/JavaScript代碼轉化為對應的原生版本。大部分基于HTML5和JavaScript的框架還提供了這樣的便利：開發者編寫一遍應用， 就能夠讓它在各個不同平臺上運行——與針對每種設備編寫原生應用相比，這將幫助開發者節省時間和金錢。

另外值得指出的一點是，現如今所有的設備都宣稱能夠支持HTML5，因此使用HTML5開發應用，是能夠使應用立即覆蓋到所有設備上的唯一途徑。

Brian：在我的職業生涯早期，先是為企業編寫原生APP，接下來又重寫它們。隨之而來的是我對這種類型的環 境的厭惡情緒不斷積累。我認為，這正是我創造PhoneGap的動機，至少是部分動機。不過，頗具諷刺意味的是，我們今天投入了大量的時間編寫原生代碼， 正是為了實現我們的目標：致力于推動Web成為開發者的***平臺。

有些時候人們會為此感到吃驚：Web瀏覽器以及其中嵌入的插件，都是采用原生代碼編寫的——與我們編寫操作系統時所采用的開發語言相同（一般都是C 和C++）。實際上，如果某種Web技術沒有實現某些東西，那并不是因為它不能，而是我們沒有在平臺中增加這部分的支持。因此，對Web成為“原生”來 說，并不存在技術壁壘。

在理解這些東西是如何構建起來方面，我們應該意識到將之視為對立的兩面，是一種被誤導的觀點。此外，想象一下某個外來者闖入到特定某一組利益干系人 的利益壁壘中，只是為了看到這種技術在五到十年的時間窗里被拋棄，這并不是我們技術投資的***商業戰略。更好的方式是基于Web的通行守則（web commons）進行構建，或許甚至做出一些貢獻，從而讓大家都能夠獲益。

封閉的GUI技術一般會表現出阻止、抗拒的態度，但接下來就會隨著Web技術悄然無聲卻又持續不斷地演進而逐漸淡出舞臺。科學技術的***進展與十年 前相比，其間遙遠的差距甚至可以用光年來形容。借助于WebRTC、WebGL，不同的設備API、WebAudio API，以及JavaScript虛擬機方面的進步，Web目前又一次站在了變革的邊緣。這些技術進步將為新興企業帶來重大的機遇，去顛覆舊有的企業。不 過從整體來看，移動Web尚處于新生兒時期，而這些新能力目前幾乎尚未得以利用。

Maxim：我個人更青睞原生應用開發方式，因為它使我們能夠聚焦并專注于用戶體驗，并且在這樣的模式下，我們可以輕易地利用平臺提供的精華能力。

在構建應用的過程中，開發者如果在心里想著要針對許多平臺，將會使得開發變得更脆弱。特別是在開始開發應用的時候，我喜歡專注于針對某一個平臺，創建出***的應用，而不去關心其他若干平臺的特性集或特殊范式。

Miguel：毫無疑問，我喜歡的是我們現在為人們提供的方式。

我們所做的，是將.NET和C#的核心部分帶到了Android、iOS、Mac和PlayStation上，讓這一語言變得盡可能通用。這意味 著，我們并沒有移植以往與.NET相關的那些用戶界面元素。相反，我們針對各個平臺，分別創建了C#類庫，讓開發者能夠充分利用每個平臺上的全部特性，讓 他們創建的應用能夠利用蘋果和Google帶來的每一個微小細節。這意味著這些原生平臺上出現的所有創新和改進，都將被我們轉化并提供給我們的用戶。

這樣的做法對于開發者很有價值，能夠幫助他們精細化調節每個最終細節，并使用平臺上的每一個特性。但還有其他很多開發者，他們只是想要讓應用經過一 次開發就能夠運行在所有平臺上，或是認為在其應用的用戶界面以及與平臺的整合中，并非每個部分都需要原生平臺的能力。對這些人來說，我們創建了一系列跨平 臺類庫（都在前面所提到的技術之上構建），為他們提供一次編寫、四處運行的庫。這其中包括我們的Xamarin.Forms API，它聚焦于構建跨平臺用戶界面；Xamarin.Mobile，用于訪問一個設備上的不同特性（例如相機、加速度計、陀螺儀等 等）；CososSharp，用于跨平臺2D游戲。我們還開發了跨平臺的SQLite，另外我們向Couchbase提交了一些貢獻，使得同一套API能 夠使用存儲、離線和同步存儲。

記者：現在有許多討論，圍繞著原生應用與HTML5/JavaScript應用的性能差異。即使移動設備和移動瀏覽器正在變得越來越強大，人們依舊認為原生的速度會更快。那么真實情況是否如此？或者這只不過取決于是否按正確的方式使用了正確的框架？

Chris：從理論上講，沒有任何理由能夠證明JavaScript就應該更加緩慢。然而，在實踐中，我們“總 是會”發現這樣的現象。JavaScript是一門解釋性語言，運行速度比Objective-C慢許多。使用HTML進行渲染，無論怎樣優化，其性能與 原生UI相比都有較大差距。我相信，確實能夠打造一個足夠快的非原生應用，然而現實中幾乎沒人知道如何實現這一目標。

Daniel：這類討論已經持續有一陣了。但是性能的問題，其實完全取決于使用某個特定框架構建應用的過程中， 開發者是否良好地完成了自己的工作。很多時候，他們只是完成了Web應用的構建，而完全沒有仔細考慮應該如何組織它，以優化其性能。例如，在屏幕上一次性 渲染過多的組件，或是展現過多的數據——它們原本可以打包成較小的分組——都將嚴重影響性能。

如果能夠巧妙地設計應用，基于HTML5/JavaScript的方式完全沒有道理不能夠與對應的原生應用競爭。已經有一些現實世界中的例子證實了這個理論，例如Sencha的Fastbook Demo， 這是一個基于HTML5的Facebook“概念驗證”（proof-of-concept）應用，在許多方面它的表現都超過了Facebook的原生應 用。它展示了人們能夠讓Web應用獲得很棒的性能，同時也證明了要實現這一點，需要經過深思熟慮的設計——按照應用而不是網站的思路來設計它。

原生應用同樣可能由于采用了糟糕的架構，而出現性能欠佳的問題。例如Facebook應用在iPhone 4上非常糟糕——因此，我們不應該簡單地說“原生應用的速度總是更快”。

毫無疑問，原生應用中的一些特定方面會更快，例如我們知道當前WebView的一些性能限制。但除了這些為數不多的特定領域外，大部分商業應用都可 以使用HTML5混合模式獲得理想的性能。此外，針對WebView性能的問題，iOS和Android都在新版本中做出了重大改進，而且預計在不遠的將 來，這一切將得到進一步改善。因此，許多與WebView相關的性能問題都將得到解決。

Brian：直接向CPU下達指令，是硬件能夠提供的速度最快的執行方式。然而這意味著我們應該使用編譯語言來編寫一切，除非追求執行速度并不總是我們達成軟件目標的***途徑！

有時，我們需要考慮開發者的技能、快樂情緒以及API的人機工程學。增加一名新的開發者，或者甚至只是加入已有的技術或內容投資，都可能會引發這一 選擇問題。當我們考慮某種技術的性能時，這些方面的權衡會變得更加復雜。專利軟件類的GUI工具在持久性方面的過往記錄欠佳，而開源的 JavaScript框架則似乎逐漸進入（又淡出了）流行趨勢。

今天，我們可以使用Web技術構建一個應用，橫跨所有主流平臺，并獲得與原生應用相比非常接近的體驗。有些時候我們則需要混合方法，例如像 Instagram所做的那樣，結合WebView和原生菜單。這些問題的答案，正如同現實生活一樣，并非那么明確的非黑即白，而是有許多處于灰度區域的 情況。如果我們恰巧擁有一支Swift開發者組成的***團隊，那么無論出于何種考慮，我們都應該只針對iOS8開發應用。如果我們認為Java的生態系統 在美學上充滿吸引力，那么在這種情況下，Android就是我們及我們的應用應該置身的***環境。而如果我們在.NET技術方面有著巨大的投入，那么我將 會推薦Xamarin。“具體問題具體分析”是開發者們熟知的一個理由。

最終，如果我們想要接觸到最廣闊范圍的設備及其用戶，那么建議的選擇便是Web技術。如果我們想要獲得蘋果軟件商店的曝光度，又或是想要早點去接觸新的Web API，那么基于Apache Cordova的項目（例如Adobe PhoneGap）則正是我們興趣所在。

Maxim：我認為，編寫原生應用并且無需應對性能問題，對開發者來說是更加便捷和簡單的道路。而當我們在開發過程中遇到了性能的時候，原生應用的調優也更容易處理。好的平臺生態系統提供了剖析調試的工具，以及解決這些問題的疑難解答。

現在也有一些技術性程序實例，展現了如何使用JavaScript開發對性能有重度要求的應用。這些示例令人矚目，但我懷疑是否有必要。當我們開發 應用時，需要面對許多問題，而性能調優是我們最不愿意處理的方面。在我看來，對任何軟件開發項目來說，簡單性都應該放在***位。如果我們當前需要開發一個 性能要求很高的應用，那么我們應該評估這樣的技術：它們證明了自身能夠以用戶（注：指使用這些技術的開發者）友好的方式，來應對這樣的工作需求。

Miguel：毫無疑問，使用原生編譯器和原生應用的形式，速度會更快。畢竟，HTML5和JavaScript引擎是在原生的基礎資源之上構建的。不過，并不是每個應用都需要系統中大部分底層基礎資源的全部能力，而且在很多情況下，利用與否甚至根本無足輕重。

總體來說，HTML和JavaScript在移動設備上的主要問題，并不在于其速度較慢，而是給人的感覺不對。它們沒有使用原生特性，行為表征也不 同于原生應用，而且有著奇怪的表現。正是這樣，才導致一些用戶在直觀感覺上認為其速度緩慢——他們并不是真的察覺到JavaScript代碼或HTML渲 染速度的快慢。Web應用給他們的感受，就像是一系列相互關聯在一起的碎片，每個碎片都必須進行調優。

因此，問題其實在于性能、行為表征、交互，以及能否使用數量龐大的移動API——要想模擬這些API是非常繁瑣的事情。

#p#

記者：原生開發的一個主要優勢，在于最終產出的應用能夠為用戶提供更好的視覺和感覺效 果。蘋果通過提供通俗易懂的“iOS人機界面指南”，來確保大部分應用的視覺和表現比較一致。如果開發者不使用原生UI插件，應用或許將無法滿足用戶的期 望。那么你們是否認為這是一個嚴重的問題？

Chris：這主要取決于應用本身。對大部分應用來說，這確實是個問題。所有的非原生UI插件，對用戶來說都是 需要學習的新鮮事物。例如，如果我們構建一個待辦事項清單（todo list），那么我們并不希望用戶不得不學習全新的UI范式，并因此感受到過于沉重的負擔。不過對游戲來說，我們則總是希望能夠創造定制化的UI。此外， 一些非常盛行的網站（例如Facebook），可能也會加入少量定制插件，因為其應用的用戶粘性非常高。

Daniel：這與應用的類型密切相關——例如，是傳統的B2C應用，還是某些休閑類應用，二者差異很大。Web應用框架可以通過精巧地運用CSS，來復現原生組件的視覺和使用效果，因此一般來說這不是個問題。

Sencha的移動框架Sencha Touch，針對每個設備和平臺都提供了一些開箱即用的主題。開發者可以使用它們，將其運用到所有的UI組件和交互中，為用戶帶來能夠與原生應用相媲美的 視覺和使用效果。這些主題，可以根據用戶運行Web應用所使用的設備動態設定，而且還可以針對特定的顏色主題或品牌進行定制。

Brian：如果開發者將自身產品鎖定在蘋果人機交互指南（Apple HIG）的特定版本上，那么他們將發現自己需要針對后續版本重寫其應用。而那些構建起“自己的”品牌(注：指有著自己獨特的用戶體驗設計，而不是緊密跟隨 蘋果人機交互指南)的開發者們，他們不僅擁有跨平臺的應用設計，而且甚至無需操心新平臺的發布。Uber的應用是一個將用戶體驗擴展至不同設備和平臺的***例子。

用戶體驗是一個重要的問題。軟件的成功，毫無疑問與其能否提供良好的最終用戶體驗密切相關。開發GUI時所作的技術選擇，將影響許多方面。不過，技 術本身顯然不會“完成”或“破壞”為提供良好用戶體驗所進行的工作。在這一點上我們不能偷工減料。要想獲得偉大的用戶體驗，就意味著我們必須雇傭優秀的用 戶體驗專家，并持續不斷地進行定性和定量分析。無論進行何種技術選擇，要想制作偉大的應用，都不存在任何捷徑。

話雖如此，現在已經證實了Web技術能夠擴展到多種屏幕尺寸、設備方向（橫縱屏幕），以及平臺的未來實現。

Maxim：任何時候，如果應用不能夠滿足用戶的期望，都將是一個嚴重的問題。然而，這并不意味著我們如果在應 用中引入定制化的UI，就必定無法滿足用戶期望。我們只需要讓自己的應用中定制的UI，能夠像原生用戶體驗那樣符合用戶直覺并使其感到愉悅即可。不過，這 永遠是個高難度的問題，特別是當我們的應用瞄準了跨平臺發行的時候。

而我想要再次質疑這種毫無意義的增加工作量的做法——創建定制化UI，且使其能夠為iOS、Android和Windows Phone用戶提供自然的、直觀的體驗。不要誤解我的意思，確實有一些有意義的例子。比如游戲往往伴隨著定制化UI。另外網站也是運行在不同的操作系統和 瀏覽器之上的定制UI的良好例子。

但消費者會做出自己的選擇，他們寧愿安裝應用而不是訪問網站。他們這樣做的目的，是為了追尋更好的用戶體驗。而影響用戶體驗的最重要因素之一就是 UI。人們希望在熟悉的環境中完成操作。不過當我們設計網站的時候，則略有不同。Web上沒有熟悉的環境，因此參考的樣本基本上就是另一個網站。而當構建 一個應該解決某問題的應用時，我們應該問自己：定制化UI是否能夠幫助用戶理解并解決這個問題，或是反而增加用戶的疑惑。畢竟，別人可能基于原生UI開發 一個解決該問題的應用，并把我們踢出局。

Miguel：只有當它成為我們業務上的問題，或是阻礙了我們前進的腳步時，才成其為問題。

許多垂直應用永遠不會面臨任何競爭，因此它們沒有動力去解決這些問題。這也正是為何企業級軟件如此糟糕，因為它們所處的環境缺乏競爭，或是具有高昂 的遷移成本。當我們的軟件鎖定了用戶的時候，我們就不會有動力去改變應用，對其進行進一步的潤色加工。在某些情況下，業務成本核算將促使我們打算只提供恰 到好處的解決方案，而所謂的“潤色加工”則是一些我們明明可以提供但卻將要忽略的東西。

只有當面臨競爭或業務需求發揮影響力的時候，開發者才會傾向于尋找最簡單交付路徑之外的解決方案。

記者：應用開發過程中涉及的工作，不僅僅在于編寫代碼，還包括對功能、性能及用戶行為進行測試。你們使用或提供了哪些工具，用于支持這些不同領域的測試？

Chris：我們很少遇到不得不測試性能的情況，因為我們開發的是原生應用，而對原生應用來說，性能一般都不是 個問題。站在功能的角度，我們的開發團隊與設計師一起，花費了大量的時間去嘗試那些感覺很給力的東西。另外，我們非常樂于通過Twitter和電子郵件收 集客戶的反饋，并與許多客戶保持聯系。因為我們團隊規模不大，所以每個人都加入了這個流程中。此外，我們還使用自動化回歸測試，以確保我們的產品質量。

Daniel：Sencha開發者們可以選擇使用多種測試工具，其中比較流行的一套工具是由Bryntum開發的Siesta。Siesta是一個JavaScript單元測試工具，而且它支持對DOM進行測試并模擬用戶交互。這意味著它能夠測試應用中的大部分功能。

Appurify則提供了另一種測試功能（最近Google收購了它），它能夠在云端運行的物理設備上，自動化測試應用的UI和性能表現。這是一項 非常有幫助的工作，因為它意味著其用戶（開發者們）將無需購入多種型號的設備，或是管理與這些設備對應的數量龐大的各種配置（例如不同的操作系統版本）。

當需要調試特定的故障或是分析特定的性能問題時，現代瀏覽器中的開發者工具提供了大量的功能支持，例如記錄和分析瀏覽器窗口內發生的所有活動——包括布局、數據請求、內存使用和事件等。瀏覽器的開發者工具可以通過插件得到進一步的擴展，例如Firefox的Illuminations或用于Google Chrome的Sencha App Instpector。與原生瀏覽器工具提供的更通用的HTML5調試工具相比，它們都針對Sencha框架提供了更深入和更智能的分析。這讓開發者在使用昂貴的框架（例如Sencha Ext JS或Sencha Touch）的時候，能夠快速查看他們的應用中正在發生什么。

Brian：目前我們正在針對Apache Cordova和Adobe PhoneGap進行大量的手工單元測試。我們的目標是將這套架構整理成可安裝的插件。另一方面，用戶空間將與Saucelabs Appium結合，以便進行自動化測試。另外，我還想要推薦大家看一下。

Maxim：作為測試驅動開發的鐵桿粉絲，我編寫單元測試以確保應用邏輯的正確性。性能缺陷方面的最主要指征是 FPS速率的下跌。無論何時，只要性能問題出現，我就會使用平臺提供的分析工具，來找出性能關鍵代碼并對其進行重構。單元測試令重構過程變得非常便捷，因 為它們能夠告訴我，在性能優化之后應用邏輯并未被改變。

現在有許多跟蹤服務，讓我們能夠獲得關于用戶行為的匿名數據。這些服務一般提供針對特定平臺和開發語言的SDK。

Miguel：Xamarin提供了一系列為數眾多的測試服務，涵蓋了從非常簡單到非常復雜的測試情景。

測試云是我們的拳頭產品。它是一套由約700部設備組成的集群——這些設備規格豐富，并搭載著各個版本的Android和iOS——我們將測試云提 供給開發者，以便其進行自動化測試。開發者在構建自己的應用時，可以將其上傳到我們的測試云，由我們針對開發者希望支持的各個平臺運行測試套件，并將測試 過程中出現的問題生成一份詳細的報告。我們的常規工作，還包括幫助開發者找出不同平臺上的差別和問題。例如，最近我們幫助一個客戶測試的時候發現，目前流 行的OpenGL優化中的某個特定類，在使用某款CPU的所有設備上均未得到支持。

另一方面，我們還提供了Calabash系統，它讓開發者能夠為其移動應用編寫測試套件——就像普通的單元測試框架那樣，開發者能夠在每次構建自己的應用時，持續地運行它。

Daniel：我認為，為多個平臺開發Web應用和編寫業務邏輯的難易程度，很大程度上取決于 JavaScript應用的結構以及所使用的框架。例如，Sencha同時為桌面和移動應用開發提供了JavaScript框架（Sencha Ext JS和Sencha Touch）。這兩種框架基于相同的機制，而Ext JS甚至除了桌面外還支持平板電腦，因此代碼可以輕易在桌面、平板和移動應用之間共享。

Sencha Touch和Ext JS都具有MVC架構的特性，將應用的代碼分離在不同的區域中：模型（對數據進行定義）、視圖（用戶界面）和控制器（業務邏輯）。業務邏輯永遠包含在應用 的控制器中，這意味著這些代碼始終處于這樣一個區域里。同時，與在視圖中零散地直接編寫業務邏輯片段的方式相比，這也會促進代碼的復用。Sencha對 MVC的支持與原生Objective-C或Java開發模式非常相似。因此，在JavaScript中編寫業務邏輯同樣可以是一件非常便捷的工作——只 要為它設計合適的結構。

在開發人員求職市場上，就編程語言方面來說，JavaScript擁有較大的技術人才基礎。IT Jobs Watch跟 蹤了英國的IT就職市場，統計了固定工作職位（非臨時性工作）要求的編程語言經驗排行。在為期三個月的統計樣本時間段中（2014年6月至8月），要求 Objective-C的職位數量約在1000個上下；要求Java的數量在16000個左右；而對JavaScript有需求的則超過17000個。

（來源：Objective-C Jobs、Java Jobs、和JavaScript Jobs）

Brian：使用動態語言表達業務邏輯更加容易，但是這需要更加嚴苛的測試，并將功能封裝在不連續的（理想情況 下應該是分離的）模塊中。原生環境中的工具為開發者提供了許多支持，例如代碼生成和編譯器警告——編譯器廠家宣稱，后者能夠帶來更好的軟件。然而實際上并 非如此，它只是造就了更加懶惰的開發者。他們并不測試自己的工作，而是將它拋給與開發部門平行的獨立QA部門，由其在完全不同的環境中進行測試。動態語言 環境則會強制性推動創建和維護更好的測試套件，從而促使自身演進為更高質量的解決方案。世界上那些業務量***的網站都是用這種方式構建的。

在打造絕妙軟件用戶體驗的道路上沒有捷徑。我們需要在編寫代碼過程中保持嚴謹和自律的路線，以獲得良好的結果。但是這與原生還是Web編碼方式無關。兩種方式都能夠從全面測試、持續集成和持續交付中獲益。

Maxim：我上一次涉足Web開發，使用HTML和JavaScript是在2012年。彼時我置身于一支技術團隊，為移動和桌面端的家居自動化平臺開發富互聯網客戶端。在那段時間里，我注意到了以下現象。對桌面環境的Web前端開發者來說，主要需要完成兩項任務：

1. 開發應用；
2. 使其能夠適配老版本的IE瀏覽器（大部分通過按需引入修補性的代碼片段來實現）。

而移動環境的Web前端開發者同樣也有兩項任務：

1. 開發應用；
2. 精簡掉應用中的所有非必要功能，以便它能夠在糟糕的網絡連接和低端Android設備上運行。

或許在最近兩年里，世界的面貌發生了翻天覆地的變革。然而如果沒有的話，那種“這么多年以來，我們已經很了解應該如何做Web應用了” 的論調就依舊不適用。在桌面或移動環境下開發、構建HTML和原生應用，都應該被視作互相間完全不同的工作。在學習了如何構建桌面HTML應用后，我們依 舊需要學習如何構建移動版的HTML應用。即使我擁有構建原生移動應用方面的經驗，在進行HTML應用開發時，依舊需要學習一些東西。

Miguel：我不認同這個問題里的前提條件。

一些管理者更熟悉伴隨JavaScript而來的那些微妙的問題，并且傾向于每次都選擇更好的語言和IDE，以便在應用的整個生命周期幫助開發者： 從代碼完成到智能感知、自動測試、重構工具、長期維護代碼庫，乃至到能夠讓團隊輕松地成長，而不會讓他們自己迷失在意大利面式代碼（spaghetti code，指混雜難懂的糟糕代碼）的海洋中。

JavaScript的主要優勢在于其普適性，但是Google和微軟早就認識到，在面對構建復雜系統，并且需要使用很多我剛剛列出的特性 時，JavaScript語言就顯得蒼白無力了。因此它們分別在JavaScript的基礎上開發了新的語言以解決這些問題（Google的Dart和微 軟的Typescript）。

從目前來看，JavaScript***的優點在于，許多人都可以把它與其他一些東西整合在一起。

記者：移動開發不再只局限于智能手機和平板電腦，許多新的設備和界面形式正在浮現。讓我 們考慮一下那些可穿戴設備，比如Pebble、Google Glass或Gear Fit，在這些設備上，我們將同時面對數據呈現以及全新的設備交互方式這兩方面的挑戰。原生SDK讓開發者能夠訪問那些設備相關的特定功能。但是，考慮一 下不遠的將來市場上，可能會出現的非常廣泛、多樣化的設備類型和界面，HTML和JavaScript是否能夠覆蓋它們并提供支持？

Chris：長遠來看，HTML和JavaScript或許最終能夠做到。這完全取決于制造商以及他們打算開放出來什么東西。在可以預見的未來，毫無疑問原生開發將比HTML有著更多的可能性。

Daniel：原生SDK的問題在于，我們只能針對特定平臺開發特定的東西。而對HTML和JavaScript來說，世界上數量龐大的個人設備，都能夠渲染基于Web的內容。

在Sencha，我們總是努力支持新出現并逐漸流行起來的設備和平臺，而我們的一位工程師完成了一項概念驗證，確認了傳統的結合Cordova打包的Sencha移動應用能夠在Google Glass上運行。

這表明，只要對已有的基于Web的應用做一些微小的調整，就能夠使其能夠適配到更小的設備上。顯然，對于Pebble或Gear 2這樣的設備來說，我們都被限制在更小的屏幕空間中，因此設計師或開發者需要更加審慎地思考，需要在屏幕上一次性呈現多少組件，而不是讓太多內容淹沒設備 和用戶，以至于令其無所適從！

Brian：恩，毫無疑問，Android Wear和Google Glass都使用了嵌入式WebView（但不支持JS）以渲染其界面。這證明了WebView確實非常適合橫跨不同屏幕尺寸進行渲染，而且尤其擅長以文 本為核心的展現任務。Pebble擁有一套JavaScript SDK。可穿戴設備的未來將與Web結合非常緊密，而界面也將追隨這一趨勢。

Maxim：當出現新設備，且制造商決定面向第三方開發者開放和提供原生SDK的時候，制造商應該表現出自己的 某些愿景。我認為，硬件/操作系統制造商所展露出的清晰明確的愿景，將為第三方開發者帶來巨大幫助。如果在制造商的規劃中，第三方開發者將針對其平臺開發 Web應用，那么一切都沒問題。如果制造商不這么打算，但第三方開發者卻使用瀏覽器作為后門進入這個平臺，那么對應用開發者和用戶來說，這都將變得十分痛 苦。

記者：移動應用針對的往往是個人用戶，對這個群體來說，應用能夠快速、定期地提供涵蓋新 功能和Bug修訂的升級版非常重要。一般來說，開發者運用敏捷過程以實現這一目標，并力爭進行持續交付。從敏捷的角度看，HTML和JavaScript 似乎具有顯而易見的優勢——在原生應用開發的世界里，是否也有能夠與之媲美的東西？

Chris：如果將移動應用與移動網站進行對比，那么我們會發現明顯的差別：對移動網站進行變更總是更容易。而 如果我們將原生應用與HTML5應用（例如使用PhoneGap或類似技術創建），則沒有區別，至少在蘋果平臺上，無論使用二者之中那種方式，蘋果官方均 不允許已安裝應用下載新的代碼。盡管站在技術上看，HTML應用本身具有持續更新的能力，但這卻是被禁止的。

Daniel：在開發原生應用的過程中，我們可以使用諸如TestFlight等服務向β用戶推送更新。在企業環境中，還可以面向企業內部用戶，使用TestFlight進行應用的大規模部署，從而繞過蘋果軟件商店。這意味著用戶無需等待應用審核周期，就能夠獲得新的版本。

Brian：如果嘗試使用混合開發，那么我們就能夠利用持續交付的優勢，而不必受限于蘋果軟件商店的審核。蘋果最近放松了在這方面的姿態。在這個問題上我顯然是有立場偏頗的，但是說實在的，混合方式結合了兩種模型中各自***的部分。我們能夠享受通過蘋果軟件商店分發獲得的曝光度，享受原生平臺結合插件的能力，并且還能夠按自己的意愿將代碼推送到產品中。

Maxim：這完全取決于我們正在構建的應用。對于個人用戶非常關注頻繁升級這個話題，我持有不同意見。他們需 要的是應用能夠工作。如果我們在***個版本就能夠提供良好的用戶體驗，那非常好！而且這對于軟件商店中的應用評分也更有利，因為每個版本的用戶評分都是從 零開始的（注：這意味著，每次升級后，顯示的應用評分都會被歸0，這可能會影響新用戶對應用的選擇）。

不過，發布用來解決Bug的更新是非常重要的，而提供新特性或許也會有所幫助：）。從這個角度看，Web擁有***的交付機制。如果我們構建一個 Web應用，那么我們想要多么頻繁地發布都可以，而且我們可以進行局部回滾、A/B測試等等。不過，請注意我說的是Web，而HTML和 JavaScript并不等同于Web。通過蘋果軟件商店分發應用時，蘋果不允許在審核通過后，應用內部再下載任何代碼。這意味著，如果我們將HTML應 用打包成原生應用并在蘋果軟件商店中發行，幾乎就失去了我剛才提到的便利。我們依舊可以使用Web來加載配置，并進行諸如A/B測試等工作，但是在應對緊 急發現的Bug時，這種方式并不會為我們提供幫助。

Miguel： 原生開發者最多只能夠在發現重大缺陷的時候，提示用戶進行升級。

這意味著，當我們遇到類似IBM最近發現的那個漏洞（惡意用戶可以劫持展現的銀行信息）一樣，盡管對于使用HTML和JavaScript開發并通 過原生容器封裝的應用來說，可以將HTML和JS代碼完全托管在服務器側并進行更新，但數量龐大的此類應用，仍舊需要對容器本身進行升級。

不過，這里也有其他一些替代方案，我們可以讓服務器來控制那些呈現在用戶面前的內容——通過傳輸HTML和JavaScript或通過傳輸其他形式的結構化數據。

#p#

記者：“JavaScript無處不在”——這往往被認為是在服務器端使用JavaScript的一項優勢。如果服務器端和客戶端使用相同的技術棧，開發者可以復用代碼和工具。那么在移動應用領域是否也有類似的可能？在原生世界中，是否同樣能夠復用代碼和工具？

Chris：在進行Mac桌面編程的時候，我的很多技能和代碼都得以復用。而且我還使用Objective-C編寫了服務器端代碼，并且正在嘗試使用Swift來進行服務器端開發。

Daniel：代碼復用是有可能的，因為諸如Cordova等工具可以被用來創建混合應用，因此開發過程與普通Web應用幾乎一致。

但是這里（混合開發）的主要優勢是，應用開發者不必學習不同平臺上的原生語言。對服務器端/Web而言，只有一種變體（服務器端），但卻能覆蓋3種或更多的原生平臺。在跨平臺交付時，HTML5顯然是更便捷的途徑。

Brian：我們再次享受到了混合開發帶來的潛在便利。我們在客戶側制作了大量的模板，接下來還會在服務器側復 用它們。其它不這么明顯但同樣令人振奮的是，我們可以同時在客戶側和服務器側運行我們的測試套件。總的來說，讓JS無處不在是一個重大的勝利，特別是這門 語言正隨著ES6標準逐步成熟。

Maxim：在代碼復用的時候會遇到一個問題——耦合。當我們在服務器端和客戶端使用相同的代碼時，我們必須先檢查一下是否會對服務器端的實現造成影響，而后才可以變更客戶端。當我們擁有一個長生命周期的產品時，這會顯得尤為麻煩。

在移動應用領域也存在相同的問題。如果我為若干平臺編寫一款移動應用，并復用其中大部分代碼，那么我實際上創建了一個一體化的核心。在這種情況下， 每當我將要對它做一些變更，都會影響到所有的平臺。在前一個話題中，討論了交付機制的問題，它因我們選擇發布的不同平臺而異。Web是最快速的交付機制， 而蘋果軟件商店則是最慢的。有一句老話說：“鏈條的強度取決于其最薄弱一環”。在進行跨平臺開發時，我必須聚焦于各個平臺中的最薄弱環節。這意味著，當我 改變了業務邏輯中的某個關鍵點的時候，我需要等到蘋果應用商店的發布完成后，才能夠改變我的Web應用。而如果我要做一些復雜的視覺展現（UI），則必須 考慮我希望支持的性能***的Android設備。

我并不是說代碼復用不好，只是想指出，任何事情都有其代價。

Miguel：是的，我們在客戶端和服務器端兩側同時使用C#或C。

記者：在最近幾個月里，應用內建插件進行分析的做法逐步興盛流行。你們是否使用了一些類似于Splitforce的工具，另外對于產出***的產品，分析到底有多重要？

Chris：我們有自己的分析系統。我們相信，分析有助于獲得用戶行為方面的洞見。我們還通過郵件、Twitter和線下方式與用戶進行大量溝通。這一點甚至更為重要，因為它促使我們站在大局角度，獲得更好的視野。而且它有助于我們理解，我們的應用如何與用戶的日常工作流相互契合。

Daniel：取決于正在開發的應用的類型。在理解最終用戶如何使用我們的應用方面，分析工具能夠提供有力的幫助；對于找出應用中哪些部分相比其他更受用戶青睞方面也是如此。這樣我們就能夠將未來的開發精力聚焦在應用中的流行部分，而不是揮霍在那些用戶較少使用的部分。

Brian：既然問到了這個問題，我想介紹一下我們的Adobe PhoneGap Enterprise產品，它與Adboe Marketing Cloud相互結合。它能夠針對內容優化及內容發布到產品應用中的工作流程，進行深入分析和A/B測試。基本上這項工具非常貼心。：）

Maxim：如果應用想要取得成功，A/B測試和商業分析非常關鍵，而在我最近兩年投身的移動游戲開發領域里尤其如此。

人類其實并不是一定要玩游戲，游戲并非生存的關鍵要素。我們玩游戲是因為喜歡——我們喜歡這種體驗。A/B測試和商業分析幫助我們針對目標用戶群 體，找出***用戶體驗。離開這些工具，我們只能夠對不同的功能特性是否能取得成功進行押寶。而對于一家謀求可持續發展的企業來說，這是無法接受的。

Miguel：這塊領域現在擁有來自諸如Twitter、Amazon、Google、Microsoft等眾多公司的產品，有助于了解用戶如何使用自己的軟件。現在，這已經是一塊非常成熟的領域，而且這么做已經成為標準做法而不是個例。

參與討論的成員

[[127384]]Chris Eidhof是一位來自德國的軟件開發者，目前定居于柏林。他的大部分精力投入在iOS和Mac應用開發方面，例如Deckset。此外，他還創立了UIKonf和objc.io，并撰圍繞著使用Swift進行函數式編程寫了一本書。

[[127385]]Daniel Gallo擁有9年以上的開發經驗，曾經使用多種不同技術開發基于Web的創新型應用，并且尤其精通ASP.NET、C#和JavaScript。在2012年初，Dan加入Sencha成為其歐洲銷售工程師之一，從事Sencha產品線的售前技術支持工作。

[[127386]]Maxim Zaks曾在若干Java Enterprise和Web的項目中擔任開發和咨詢的角色，并曾出任某個基于Eclipse的IDE開發項目的***開發人員。現在，他正在為Wooga開發iOS平臺上的休閑游戲。

[[127387]]Brian LeRoux是Adboe PhoneGap的***產品經理及對外代表，同時也是Apache Cordova的VP。他是Node Firm的會員，也是一位移動Web黑客和啤酒愛好者，并且曾針對一個JavaScript問題與其他許多人一起在wtfjs上撰文。讀者可以在他的個人網頁上了解更多信息。

[[127387]]Miguel de Icaza是 Xamarin的聯合創始人，Xamarin創作了MonoTOuch和Mono(針對Android類庫)，讓開發者能夠使用C#，為iPhone、 iPad和Android開發移動應用。在創立Xamarin之前，Miguel締造了Gnome和Mono，并與他人共同創建了Ximian。

在過去幾年間，移動應用以雷霆之勢席卷全球。我們在工作和休閑時間中使用互聯網的方式，已經隨著移動應用的前進腳步發生了變革。在此期間，許多創建移動應用的技術浮現在世間；而在開發應用的時候，人們也開始考慮“移動優先”的做法。然而，哪怕現在移動設備似乎早已無處不在，未來的時代卻只不過 剛剛揭開帷幕。我們正在面對全新一代的移動設備，諸如可穿戴設備或眾多移動配件——正是它們構成了“萬物互聯”的世界。我們將面對全新的用戶界面，通過它們數據展示及指令接收處理。同時，我們還將看到，越來越多的公司將真正地踐行“移動優先”的思路。而在未來數年中，這一切都將影響我們設計、開發和測試軟件的方式。

英文原文：Virtual Panel on App Development

譯文出處：InfoQ