說到有些團隊選擇使用PhoneGap之類的技術，原因多半是認為學原生程式太花時間，雖然以下見解可能許多人不以為然，不過我還是認為想要營運的話，還是要以原生的為主。
策略因素
這觀點要從商業的角度切入，各平台都有其市場，而平台的發展都會根據公司自身策略去調整，而近似平台彼此就是競爭關係，必然會努力做差異化，因此其交集處，就是平台間最平庸的部分。使用跨平台技術，有機會在單一平台競爭下，喪失競爭力，因為跟同平台的競爭對手競爭時，服務在該平台的整合度上先天就會慢於對手，使得敏捷的對手有更好的機會對付你。
另外，正因為平台發展的策略不同，各公司基於自身盈利，政策說轉就轉，不會徵詢跨平台服務的意見，最明顯的案例就是，當IOS宣佈不支援Flash的時候，Flash即使擁有大量的使用者，仍然無法給Apple足夠的壓力，反而是透過Native遊戲有效發揮平台特性，創造了更明顯的差異化，及更好的運作效能，連帶的引發效應，各平台紛起效尤，讓Flash進入歷史。
經過Flash這件事之後，你會發現一個馳騁網路多年的Flash技術，居然另一家公司因為一個人的決策，就讓他重創身亡。Flash不好開發嗎？ActionScript的發展不好嗎？Flex不夠彈性嗎？都不盡然，到頭來只是商業遊戲下的犧牲者。
以App來講，選用PhoneGap或其他跨平台技術，除了營運期間，所有平台特色都會慢人家一步以外，最重要的是如果PhoneGap活不下去，或者Apple或Android哪根筋不對抵制它，甚至只是OS韌體大改版，都是很傷的。仔細思考這些跨平台技術究竟怎樣營運，怎樣獲利，他的獲利足不足以對各種變化做出足夠的反應？如果規模大如Adobe都無法阻止Flash死亡，那又遑論其他新創跨平台服務呢？
成本因素
使用跨平台技術服務，這些業者總要從某些地方獲利才能維持營運，而這些獲利當然是從使用該技術的人身上截取，所以不管是要你少賺一點，還是先付一筆費用給他們，這都是額外的成本。當他們缺錢的時候，大家就可能要面對一些價格波動。這些都是當你跟Native對手競爭時，多出來的成本。想想當你成本高於對手，對平台特性的反應時間又慢於對手時，要建構多高的門檻才能在競爭中獲勝？
而從學習成本來講，儘管初期投入一個新平台會耗用較多的時間，但是後期的維護省下的成本跟跨平台技術相比是不成比例的。以目前的情況來看，原生開發環境遇到的問題，能夠得到的技術支援是較多且充裕的，而使用某特定跨平台技術的開發社群，則是相對小眾，因此，該社群能產出的資源也就相對有限。相信這可以從Stack Overflow這樣的網站上的問答比例清楚地看出來。而且，當跨平台技術在某特定平台有問題時，該問題不是無法解決，就是解法相當複雜或奇怪，可能要動用一些Hack的方式來處理，但是這種做法多半只能撐一陣子，很快地就又會需要修改，而且很可能影響其他機制的運作。這些被拉長解決時間的問題，帶來的不只是時間上的成本消耗，更是消費者體驗上的價值流失，對於已經上線的服務而言，是有很大的傷害的。
有些人可能會認為至少第一版成本是較低的，但是實際上當要進行上線時，那些看似省掉的成本就會大量的回來了，因此成本的消耗是發生在東西完成前，而不是完成後，這一點要注意。
技術不是問題，效能也不是問題
許多人可能會比較一些效能問題，在這上面有爭論，其實只要給予充分的時間，兩者都能開發出兼具效能的應用程式，只要管理得當，都可以有效地控制成本。到頭來影響最深的，還是關鍵的商業跟策略問題。而且這些問題，往往是致命的。
跨平台的服務策略
其實，在跨平台服務上Evernote給了我們一個相當好的示範，Evernote的服務本身包涵一系列的API，這些API決定了其服務的主體，也就是做Note這件事情上，同時，他讓API的結構有很大的彈性，可以發展成各種不同的運用。所以你會看到Evernote主程式，在Android、IOS、BlackBerry、Mac OS X、Windows Phone、Windows 8等各平台都有不同的應用程式（相信這應該不是用跨平台技術做的），而當你分別去試用過後，你會發現他在不同的平台上，都會針對該平台用戶設計合適的使用環境，除此之外，除了通用的Note以外，他還為了不同的應用環境，發展了Evernote Food，Evernote Hello等應用，使用相同的API，但是不同的App實作來優化不同的使用情結。因此，並不是跨平台服務不好，而是達到跨平台的方法要慎重規劃。這幾年觀察Evernote及Google等服務後，我自己整理出以下的規劃方針，給大家參考：
- 將服務區分為內容跟互動介面兩個層次。
任何平台都有MVC的相關應用，View跟Controller都是跟平台提供的函式庫有很大關係的，但是你會發現，MVC的討論中，很少提及如何規劃好Model，那是因為，VC是平台該提供給你的工具，而Model就是你服務的核心價值。
而當資料放到不同平台，就會使用該平台提供的機制來表現，並透過平台提供的操作機制來與使用者互動。透過良好的使用體驗規劃，以及有效地限定App的應用環境，就能做出實用的App。而過程中勢必會發現抽象的Model在平台內直接使用上會有些許的困難，因此免不了要有轉換機制，把API提供的資料結構，轉換成適合該平台使用的結構，或是轉換成適合某些特定UI使用的結構等，而在使用者操作的過程，把資料的變更，在轉換回API接受的格式，更新內容。這些都是必要的過程。 - 使用抽象且彈性的資料結構，定義內容存取API，以便各平台存取。
服務的資料部分，多半可以用很單純的Key-Value概念來表現（還得加些Relation的連結），目前在描述資料上，已經有不少跨平台的標準，像是XML或JSON，這會是制定通訊協定上一個相當實用的工具。但是對於資料的Schema，仍舊得要有一個統一並且抽象的定義，該定義要能容易被實作在不同平台，但他不一定要是XSD或SQL Data Schema，正確來講，他更像一份描述資料如何使用的文件。在定義內容資料結構的時候，最好先忘掉所有的資料型別跟平台特性。而落實在Storage上時，只是該抽象概念的一種實現。這個定義會在不同的使用環境內，被轉換成不同的形式存在。例如，資料傳輸時是JSON格式，儲存時可能是關聯式資料庫的形式（如果不是用NO SQL的話）。 - 將服務的基礎流程或共用資源放到伺服端。
基礎流程多半是對資料的處理，例如將使用者提供的兩個座標，拿去找出最短的道路路由，或是把使用者拍的照片，跟某個記事關聯在一起等等，這些有關資料的基本操作，或是需要參考使用到其他相關內容的服務，多半會在伺服端完成，客戶端的操作界面，只是用來擷取使用者需求的機制。另外，有些運算有較大的複雜度，或者需要較多的運算資源，也會被安排在伺服端。例如像Siri或Google語音查詢等，是先將聲音在App中轉換成標準的辨識用資料結構，再送到伺服端分析，最後再把結果回傳給使用者。像Evernote內對圖片內的文字辨識，也是由伺服端完成。
至於哪些資源應該放在伺服端，端看他的管理成本，例如要在各平台提供支援自然語義的語音辨識，需要有相當程度的資料樣本跟運算效能，這不是可以很輕易實作在各平台的，就先被放在雲端，同時也可以藉由多人的使用，累積更多的樣本。但是，假若哪天有人發展了一個語義辨識晶片，直接Boundle在手機硬體內，光靠它就可以因應所有情況的需求，那麼到時候就很可能有不同的規劃。如何安排，都是得看資源，看成本，看效益的。 - 根據平台特性在各平台分別提供合適的互動界面。
不同的平台有個平台習慣的用法，像IOS的Table就有Swipe刪除的規劃，這在Android平台就沒有，但Android平台有Back跟Menu按鈕的規劃，這在IOS平台就沒有。個平台的使用者自然會習慣該平台預設提供的機制，如過硬要把兩個平台作一樣，除了累死自己以外，還不見得能提升使用者的操作體驗。最經典的案例就是Windows 8的Metro Style，在觸控螢幕直覺又方便，但是換到鍵盤滑鼠的操作環境，就完全是個困擾，根據不同的平台特性，提供合適的互動界面，對使用者體驗有很大的影響。 - 分析市場後，做出選擇，不要以跨平台為出發點。
發展服務不是為了證明技術，不同平台用戶有不同特性，仔細去瞭解之後，先鎖定一個平台，讓你能夠在最低資源消耗內取得成功。例如使用IOS的使用者，多半習慣花小錢買App， 因此如果你的服務是以賣軟體License為主，那就適合從IOS開始。而Android平台，消費者最主要的投資都是在硬體本身，而且樂於嘗試各種新技術，如果你的服務是發展週邊硬體，或是延伸免費服務，使用Android可以獲得較多的彈性及較快的市場回應。 - 在單一市場取得成功後，開始思考開放與共生。
不只政府要OpenData，其實你會發現，同樣的需求，許多人都會有不同的想法，也會有不同的創意可以運用，如果你已經成功累積了用戶，不妨開放Data對同領域有興趣的開發者可以站在你的基礎上延伸服務。這樣一來，你少了一個對手，如果他能藉此另外獲利的話，那麼他會是你服務的好推手，到那時候，你自己就是平台了。看看Evernote，他不就是個「記東西」的平台嗎？
留言列表
