不簡單的iOS應用開發

就是這個最常見的問題，我的很多朋友(大多是些西裝革履的商務人士)，還有我那些個對技術一知半解的客戶們，他們都問過我這個的問題。通常，我會先給出一個大致的報價，這個報價並沒有細緻到需要簽合同確認每一個功能點的地步。即便是這樣，每當的我報價一出口，對方都毫無例外的給驚著了(當然不是因為便宜)。

說實話，我沒有獅子大開口。看看StackOverflow上這個著名的帖子吧，討論的是開發Twitterific這樣一款應用需要多少錢，後來討論範圍擴展到開發一個iOS應用的合理費用範圍。雖然這個帖子是在2008年發布的，而帖子的最佳答案是由一名來自Twitteriffic的開發人員於2010年回答的，但是時至今日，帖子裡面討論的數字仍然是很靠譜的，而且我預計到2012年底依然有效。而我的報價和這個帖子裡面的數字比起來，簡直是小巫見大巫了。

現在的趨勢是，什麼公司什麼業務都想搞個iOS客戶端，並且這種趨勢在2012年看似依然火爆。所以我想起來寫這篇博文，我想說一下開發一個iOS應用會碰到的各種細節問題和橫生的變數，藉此解釋為什麼iOS應用開發成本這麼貴。如果你在考慮搞一個iOS應用，而你本身是搞業務而不是做技術的，如果你目前正在招標或者僅僅是想了解一下，那我這篇博會對你有幫助。當然，我說的東西並不局限於iOS應用開發，對Android、Windows Phone或者是Blackberry(如果RIM還能活的話)等移動應用平台基本上也是適用的。

開發之前需要仔細考慮的

別做拍腦瓜的決策，在開工之前你需要考慮的比你想像的要多。我通常會幫助或者指導客戶把以下幾個要素都過一遍：

一：和客戶談他們的移動應用，最讓我吃驚的是他們從來沒有想過支撐一個iPhone應用運行，背後需要涉及到的方方面面。他們想像中的iPhone是獨立存在於這個宇宙的，是如此的簡單，以至於他們要我很快就給出一個項目預算報價，而不用討論諸多細節。

我問他們：“你們是否考慮過後台服務器的事情?你們的應用需要和後端服務器做數據通訊?” 什麼，聽不懂?好吧，我用地球人的語言再把這個問題講一遍：“你們的應用不是需要用戶註冊嘛，你們考慮過把用戶的數據存放在哪裡了嗎?我們需要一個地方去保存這些以後會用到的數據。” 第一次碰到這樣的客戶時，哥簡直就怒了。後來我發現這不是客戶的錯：我是搞編程的，CS架構對我來說就像吃飯睡覺一樣是不假思索的東西，而我的客戶盡是些高富帥，他們懂個毛CS架構!

所以，如果你不大懂技術，那請仔細聽我說：如果你想做的移動應用需要用戶註冊和登錄，或者你想隨時控制移動應用的一些輸出，甚至是你僅僅是需要一個用戶反饋意見調查表這麼簡單的功能，那麼，你得搞一台後端服務器。

二：好了，現在你知道你需要一台後端服務器。同時你還需要想辦法讓你的iOS應用和你的服務器能夠對話，就是相互間接收數據什麼的。不，這個問題不是簡答靠什麼標準的即插即用的東東就能解決的，不是你們想像的那樣!所有的東西都需要定制化開發，這就好比發明一門語言：你希望你的服務器和你的應用之間能夠通過一種語言溝通，但是你不希望其他人聽得懂這門語言。

用行話說這就是製定服務器端API接口，或簡稱API。這些API應該在開發iPhone客戶端之前就到位了。為什麼?因為你必須先規定好一門語言的單詞和語法，然後才能用這門語言說話吧!?好了，這就帶出了第三點—如何開發這些API。

三：API的成功定制是項目成功的一半(反之亦然)，所以千萬不要掉以輕心。你要考慮你的業務數據模型、業務流程、調用業務需要提供的參數、特定事件發生時數據間該如何互動等等。簡單來說，我們要做的就是開發一個網站，上門跑著你的業務流程，只不過這個網站的所有運行結果都不是通過網頁形式展現出來，而是呈現在一行行的文本和數字中。舉個例子：一個登錄成功的反饋頁面僅僅包含YES一個單詞。

iPhone應用需要訪問這些預先定義好的接口，並且按預定義格式提供必要的輸入(比如用戶名和密碼)，然後要對服務器端的反饋(YES或者NO)做出解析處理。所以，沒有什麼移動應用能夠自動的含有用戶註冊和登錄功能。

服務器端開發需要考慮的問題太多了：選擇服務器，選擇用什麼語言開發，主機放在哪裡才能增加訪問速度，等等，這裡我就不展開了。如果這一切對你來說很陌生，那麼你最好去問問團隊裡的技術負責人，或者乾脆讓開發人員做決策。

四: 所以，關於服務器端API，你或者讓自己的技術團隊把它開發好，再將完善的API文檔交給iPhone應用開發人員;或者你支付iPhone應用開發人員額外的報酬來搞定這些。你找的iPhone應用開發人員可能會服務器端開發也可能不會。如果他會的話，我建議最好讓他也同時負責服務器端開發，因為他最清楚iPhone應用中需要哪些服務器端API。

如果你的服務器端API已經存在了，那麼除了向iPhone應用開發人員提供相關文檔之外，你還要考慮讓他能夠便捷的同服務器開發團隊溝通，因為大多數情況下，iPhone應用需要在已有API基礎上增加一些新的接口。

現在我們來看看iPhone應用開發本身

扯了大半天，我們終於開始談iPhone應用開發本身了。一般來說，iOS平台上做所有事情都不能隨心所欲。你最好在開發人員寫代碼之前把所有的需求都確認好好。這和開發網站不一樣，按照實現簽訂的合同開發iOS應用，開發過程中對需求變更的容納度可能很低：

用戶界面：無論你打算採用iOS標準界面還是自定義元素，在開發開始前一定要確認清楚，因為應用的程序架構是根據界面和用戶使用流程來設計的。一個很好的例子就是在界面底部使用了iOS標準的標籤欄(Tab Bar)，此後如果你想讓標籤欄裡面的圖標變成彩色的，這個代碼改動量可沒你想像的那麼小!

代碼之間的耦合：如果是開發網站，你可以隨意的添加一個頁面或者一處鏈接。做iOS應用就沒有那麼簡單了，很多東西一開始都要設計好，後期的一處改動會牽連很多東西，具體原因是你無法理解的。 iOS應用的代碼寫好之後，再改動行不行?行!但必須小心。這就像設計電路板一樣，如果你不小心把那根線搭錯了，整塊電路板就會不工作。

有人說架構優良的程序可以有很高的延展性，那純屬紙上談兵。在About屏幕上添加一個電子郵件按鈕可能只需要幾行代碼的工作量，而添加一個轉發到新浪微薄的按鈕(譯者註：原文是添加一個Facebook Like)就完全不是那麼簡單的事兒了!

讓一個iPhone應用同時也支持iPad：如果要評選最坑爹“需求變更”，那麼這個絕對是當之無愧的。理由很簡單：支持iPad根本不是TMD什麼附加功能!iPad應用基本上都比iPhone應用來得要復雜，界面設計和用戶體驗也大不一樣。我問你，製造一輛電動自行車，然後把它改裝成一部燒汽油的摩托車，這能是一回事兒嗎!?電動自行車跟摩托車看起來是很像，但是製造它們完全是兩碼事。

拿廣受歡迎的Facebook官方應用來說，它的iPhone和iPad版本看似相似，實際用戶操作流程完全不同。不僅僅是界面上的不同會帶來額外的工作，對後台服務器API的需求也可能不一樣。拿我熟悉的一個應用Denso來說(我熟悉它因為這是我開發的)，它的iPad版本比iPhone多了幾個功能，這些都需要額外的服務器端API來支持。記住，iPhone和iPad應用的用戶體驗需求是完全不一樣的。

準備好開始了嗎？

希望此文能夠幫助你和你的團隊了解移動應用開發幕後的方方面面。除非你們要做一個像計算器那麼簡單的單機應用，否則你們很難用極低的成本搞定。綜上所述，如果你覺得外包成本太高，那你只好招人自己開發。

當然，如果你決定了要外包移動應用開發，那麼我還要提醒一點：公司政治。如果你是在一家大公司或者有著嚴格製度的機構裡面乾活，那麼幫助合同開發者搞定那些個規章制度上的繁文縟節，對你來說是非常重要的一項工作，必要的時候甚至可以做一些政策上的變通。

我同幾個大型企業客戶接觸過，當我要求看他們的服務器端數據接口的時候，他們流露出很不安的表情。我想這或許是因為他們受制於公司規定而不能透露信息，這無可厚非;或者他們還沒有想好這種情況下該如何操作;或者他們的品牌制度蛋疼到需要在移動應用的每個屏幕上都擺著公司logo!最終我沒有和這樣的企業客戶合作，因為我無法想像如果有一天我需要增加一些服務器端API接口的話，和他們的規章和流程折騰，那將會是多麼悲劇的事情。