正當(dāng)大家興致勃勃地開始設(shè)計手機(jī)應(yīng)用程序時，可能會遇到每個 Developers 和策略者都感到爭議的問題：“我應(yīng)該利用原生語言(Native App)，還是混合模式 (Hybrid App)來開發(fā)我的手機(jī)程序呢?”

Native VS Hybrid

Native App：原生語言程序是為了特定的操作系統(tǒng)而編碼，用的也是特定操作系統(tǒng)的開發(fā)套件 (Platform SDK), 如 Apple iOS。因此它的性能和工具一向比 Hybrid App 優(yōu)越。

Hybrid App： 混合語言程序的部份代碼會以 Web 技術(shù)編寫，如 HTML5, CSS 和 JavaScript。這些程序都是被包裹在原生容器 (Native Container) 和透過手機(jī)上的瀏覽器引擎來呈現(xiàn) HTML 和執(zhí)行 JavaScript。 Hybrid App 的優(yōu)點(diǎn)是一個編碼程序能夠跨越不同的作業(yè)平臺，不需要為每個操作系統(tǒng)編寫特定的編碼。

該選哪種語言好?

Developers 也因此常徘徊于該選用擁有優(yōu)越性能和工具的 Native App，還是單碼跨平臺的 Hybrid App 的頭痛抉擇里。究竟有沒有明確的答案顯示哪一個開發(fā)語言程序才是最強(qiáng)最佳的代表呢?

其實(shí)，隨著手機(jī)操作系統(tǒng)不斷的更新，如近期的新版本的 iOS 和 Andriod, 都令手機(jī)的 Javascript 運(yùn)行速度改善了不少。

這種改進(jìn)令到 Hybrid App 的性能得到相當(dāng)?shù)奶嵘�，而它們的工具設(shè)備也日漸成熟了�，F(xiàn)在已經(jīng)有許多成熟又吸引的工具方案，如原生用戶界面 (Native UI) 和裝置應(yīng)用程序界面 (Device API)，甚至有模擬器 (Simulators)、開發(fā)套件管理 (SDK Management)、裝置調(diào)試 (on-device debugging) 等等。

看來，人們對 Hybrid App 的開發(fā)已認(rèn)真起來了。

當(dāng)然， Hybrid App 的方案并不是完美萬能的，Native App 還有些地方是不能被取代，但現(xiàn)在 Hybrid 開發(fā)已經(jīng)證明了它已經(jīng)不遜于 Native 開發(fā)了。

要建造優(yōu)良的 Hyrbrid App 是需要精心的策劃和考慮到裝置上的網(wǎng)絡(luò)平臺獨(dú)特功能。在你準(zhǔn)備向下個 Hybrid App 的大冒險前進(jìn)時，有幾點(diǎn)是值得留意的：

1 . 關(guān)鍵特性，如 App 的性能

2. 把 Native 當(dāng)做指引，從中學(xué)習(xí)

3. 選擇適當(dāng)?shù)拈_發(fā)工具，縮短與 Native App 的差距

當(dāng)然，你有選擇自由

Hybrid 和 Native 的爭論，就好像比較著蘋果和橙子哪樣較好，都是沒有贏家的。

就拿開發(fā) Apple iOS Native App 來打過比例，你毋須思索都會自動想到用 IDE (XCode)，一系列的程序庫和 Object-C 編碼程序設(shè)計工具 (CocoaTouch, CoreGraphics, CoreData 等) 的開發(fā)工具來編寫 iOS Native App。

如果我們把這些豐富的資源去和 Hybrid 用的 HTML, JavaScript 和 CSS 來作比較，這根本就是一件不公道的事!你還沒有把 Hybrid 的跨平臺這種優(yōu)點(diǎn)包括在內(nèi)呢!

Hybrid 除了能夠單碼跨平臺外，還能夠讓你自由地選擇你喜歡的應(yīng)用程序組合，如整合開發(fā)環(huán)境 (IDEs), 程序框架 (Frameworks), 程序工具 (tools) 和應(yīng)用程序服務(wù) (Services)。比起只支援單一平臺 Native App，Hybrid App 無疑是更自由和更有彈性的首選。

性能是其中的一個設(shè)計重點(diǎn)

程序的性能對所有的 Apps 來說是非常重要的一環(huán)，可是 Developers 常常把這部份留到最后。就是先把整個應(yīng)用程序做好再慢慢調(diào)整它的性能。對一般的桌上計算機(jī)還可以接受，可是在資源和電能都有限的移動裝置上調(diào)整性能就會非常困難了。

如何解決這問題呢?答案就是將性能引入初步設(shè)計策劃里，而不是留到最后才開始慢慢調(diào)整。

例如你在編碼前已預(yù)先計劃了你的 App 將會以 60fps (Frames per second) 運(yùn)行，那么你大概需要 17 milliseconds per frame 去執(zhí)行程序碼和更新用戶界面 (UI)。這樣的時間根本不能提供流暢的運(yùn)行，還很可能會令你的幀 (Frame) 出現(xiàn)問題呢。為求 Hybrid App 有更好的穩(wěn)定性，建議采用 30 或 40fps 比較自然的運(yùn)行速度。

另一個影響 Apps 性能的因素就是用戶界面設(shè)計。

影子效果，漸變色層，仿真的修飾設(shè)計是可以提高用戶界面仿真度，但也會同時消耗了很多裝置的資源啊。所以在設(shè)計用戶界面前先問問自己，這些資源消耗量大的仿真設(shè)計是必要的嗎?或是可以用消耗量較少的平面設(shè)計呢?

從 Native 中學(xué)習(xí)

想拉近和你對手的距離，就要向他學(xué)習(xí)和熟悉他的招數(shù)。

設(shè)計 Hybrid Apps 也應(yīng)如此的向 Native Apps 學(xué)習(xí)，嘗試熟悉 Native SDK 的環(huán)境反應(yīng)和模擬它的設(shè)定。就拿 Apple iPhone 的滾動屏幕做例子，當(dāng)你用手指頭在屏幕上下滾動，屏幕上的東西也隨著手指滾動的方向快速地移動。這樣的高性能和反應(yīng)速度是怎樣做到的呢?就是用 iOS 的 UITableView, 它能夠重復(fù)地使用被移出屏幕的單元格 (Table cell)，載入新的資料，然后再次在屏幕的另一邊出現(xiàn)。

這種不斷重復(fù)利用單元格的技術(shù)叫做 『用戶界面虛擬化』。這種技術(shù)給使用者在一個在龐大的數(shù)據(jù)庫中滾動的假象，其實(shí)真正用到資料單元格是很少的。因?yàn)橛玫降膯卧�格不多，所以這種技術(shù)能令 App 的運(yùn)行速度更快速和更節(jié)省電力。

你能從上面學(xué)到什么關(guān)鍵能用在 Hybrid 上嗎?很多呢!當(dāng)中就是 UITableView 的單元格滾動技術(shù)。把 UITableView 變成 HTML DOM 的元素，用這方法去仿效 UITableView 來用在 Hybrid App 上，那么 Developers 就能以類似的方式來重復(fù)使用或把 DOM 虛擬化來改進(jìn) Hybrid App 的滾動體驗(yàn)了。

Hybrid 的開發(fā)是非常吸引的，因?yàn)槟軌虿捎媚闶煜さ木W(wǎng)頁技術(shù)來建造你的 App�？墒沁@同時也是一個陷阱呢!記住不要把 Hybrid App 當(dāng)成一個迷你和獨(dú)立的網(wǎng)頁來設(shè)計啊。建造理想 Hybrid App 的最佳守則就是細(xì)心研究和觀察 Native 平臺和 SDK 的設(shè)計，學(xué)以致用再 Hybrid Apps 的開發(fā)上。

你需要適當(dāng)?shù)?Hybrid 開發(fā)工具

雖然開發(fā) Hybrid Apps 的程序設(shè)計工具有很多，但一個優(yōu)良的工具是會把網(wǎng)頁平臺和 Native SDK 之間的的功能差距拉近。這樣子你就不需要擔(dān)心性能的問題了，因?yàn)檫@類的工具會在建設(shè) Hybrid App 時把程序的性能元素包括在內(nèi)。所以利用優(yōu)良的工具能夠得到與 Native 模式相同的好處。

當(dāng)然，你也可以自由地選擇適合你的開發(fā)工具并成功地建造你的 Hybrid App, 但當(dāng)跨平臺式和 App 的出品時間為你的首要條件時，你就應(yīng)該選擇更優(yōu)良開發(fā)工具來建造你的 Apps。

一個好的 Hybrid App 是不會在無意間產(chǎn)生的。就如同 Native App 一樣，建造優(yōu)良的 Hybrid Apps 是需要把設(shè)計焦點(diǎn)放在性能和手機(jī)獨(dú)特的設(shè)計模式上。隨著手機(jī)網(wǎng)頁技術(shù)在近期不斷的提升，現(xiàn)已有很多很棒的跨平臺開發(fā)工具。只要有稍微的性能設(shè)計和有合適的工具，要打造一個華麗的跨平臺式 Hybrid App 已是一件輕而易舉的事了。

如果你還在做 Native App 的開發(fā)，何不試試跳槽到 Hybrid 來個全新的開發(fā)體驗(yàn)?zāi)?