近日，GQueues（集成了數個Google服務的在線任務管理器）的創始人與開發者Cameron Henneke將其應用的HTML5移動版本移植到了iOS與Android上，他記錄了在這兩個平臺上的開發工作量并在博客上對結果進行了比較。下面的內容摘取自Henneke的調查結果，并從InfoQ的訪談中摘錄了部分內容。

之前的經驗

雖然在軟件開發方面已經有超過12年的經驗，不過Henneke說他對iOS與Android卻沒什么經驗，從他的角度來看，這兩個平臺對他來說處于同一個水平之上：

在開始開發這個應用時，我完全是個Android新手，甚至在這個項目之前我都沒有在電腦上安裝過SDK。同樣，我在iOS上也是個十足的新手。我在2010年那陣兒曾創建過兩個簡單的iPhone游戲，不過他們的復雜性無法與GQueues應用相提并論，并且使用的APIs也完全不同。從那之后我就再沒碰過iOS開發，直到今年3月開始GQueues項目為止。

開發

Android

• 一周的時間用來看書、學習教程以及創建測試應用。
• 一周的時間用來完成最初的設計階段。
• 開始實際的編碼工作，這花費了大約870小時。

iOS

• 大約花費了兩周時間用來熟悉Core Data APIs，使用PersistentStoreCoordinators與ManagedObjectContexts，并且為“FetchedResultsControllers開發了一個可伸縮的架構”。
• 又花了兩周時間，他“熟悉了iOS開發”。

總的來看，Henneke在iOS上的學習時間是Android上的兩倍。

關于學習資料，Henneke覺得Android文檔的質量要高于iOS的。Android的開源特性也有很大的好處，他可以閱讀代碼并從中學習。關于iOS文檔，他說到：

雖然iOS文檔的擴散速度很快，不過由于iOS 5到iOS 6有很多重大的變化（比如說自動引用計數的引入），因此不少內容都過時了。很多代碼示例（包括Apple官方示例）以及解決問題的方式都不太準確，我們應該使用更新的方法進行處理。這種篩選花費了我不少時間。

雖然Android開發要對“之前HTML 5移動Web應用所用的后端服務器同步代碼”進行完全的重寫，但是相比于iOS，Henneke為Android編寫同樣應用所需的時間減少了10%。下表展示了總體的開發統計：

	Android	iOS
開始時間	2012.9.21	2013.3.2
Beta版測試時間	2012.12.22	2013.6.10
應用發布時間	2013.1.31	2013.7.18
項目總時間	4.25個月	4.5個月
等待時間	1周	2周
開發時間	870小時（近似值）	960小時（近似值）
Beta測試與修復時間	34天	38天
Beta測試者數量	92人	48人
代碼行數	26,981行	23,872行
應用下載大小	1.1 MB	3.5 MB

工具

雖然從個人角度來說更喜歡Vim，不過Henneke還是記錄了項目中所使用的如下一些工具的情況：

• 在Eclipse中的搜索速度相當慢且繁瑣。
• Xcode Organizer中的文檔搜索速度讓人無法忍受。后來他發現了提升搜索速度的方法。
• Eclipse中根據日志標簽進行過濾（集成Android插件中的logcat）的特性非常棒。
• 兩個IDE中的代碼完成功能都很不錯。
• Xcode中的Interface Builder沒什么用。
• Xcode Instruments在“分析、度量與調試”方面的用處非常大。
• Android模擬器用起來非常浪費時間（這么慢的速度簡直就是個笑話）。在開發期間，我總是將應用部署到真實的Android設備上進行測試，速度會快不少。
• iOS模擬器“速度非�？欤�使開發更具效率。對于新代碼來說，我會在模擬器上進行測試，只在代碼成型后才會在真實設備上進行測試”。
• 對于Android來說，我會對應用所支持的每個Android版本進行測試（除了Gingerbread），然后根據Beta版測試者的反饋來了解設備覆蓋率。
• 對于iOS來說，他使用了應用“所支持的最老與最新的設備進行測試”。

應用設計

Henneke計劃能讓其應用在各種屏幕尺寸上都能夠很容易地進行布局，他發現Android平臺有“成熟的組件可以幫助開發者支持各種大小”。他使用了RelativeLayouts，發現“所有的布局都可以通過XML指定，這是設計界面的一種整潔、簡單且高效的方式，也是在iOS中創建布局后他所發現的Android勝于iOS的唯一一個特性”。

我們希望Henneke談談他對Android碎片化的看法：

我認為Android碎片化有點兒被人們說得過頭了？當然了，這是事實。這是Android開發的很差的一個方面么？不見得吧。Google與Android社區已經采取了很多手段來面對這個挑戰，并且取得了成效。官方的支持庫覆蓋廣泛并且還在持續發展。ActionBarSherlock是個強大的第三方庫，可以將新的特性帶到舊設備上。此外，Google最近發布的Google Play Services將廠商在碎片化中的作用降低了。用戶不必依賴廠商推送最新版的Android就可以獲得最新的特性。這對于Android用戶與開發者來說都是一個巨大的進步。

有趣的是，Henneke對于iOS布局的體驗卻不是那么好：

Auto Layout（相當于RelativeLayouts）特性很新（iOS 6才引入），它與Interface Builder（IB）的集成太可怕了。我花了好幾天的時間在IB中與Auto Layout戰斗，就像每個iOS 6 開發者一樣，為視圖構建精確的約束，只是為了讓IB能夠完全修改我的規格，因為它有“智能”系統，可以時時確保準確的布局。我查閱了很多提示與技巧來處理IB這個問題，但卻無功而返。最后，我干脆不在IB中布局了，而是通過大量樣板代碼來手寫布局。如果不使用IB和Apple的ASCII藝術風格布局編碼，那么Auto Layout實現確實非常強大和直接。推測Apple會在iOS 7中對此進行改進，不過我還是要自己測試一下才行。

使用Auto Layout限制我只能在iOS 6（iPhone 4與5）上進行開發，之前的版本就不行了，關于這一點Henneke說到：

GQueues應用實際上不能安裝和運行在更老的設備上，這也是我沒有在這些老設備上測試的原因所在。在開發移動應用時，第一步就是確定要支持哪些OS版本。iOS 6引入了名為Auto Layout的新特性，這是對老式布局技術的一個巨大改進，當然了，它只能用在運行最新版OS的設備上。我決定不再使用老式的結構方法和Auto Layout共同來創建布局，而只使用Auto Layout，這能夠極大地降低開發時間。當然了，這意味著GQueues應用將只能運行在使用iOS 6的設備上，不過這已經涵蓋了最近兩年的所有設備。我覺得一個人的電話如果使用了兩年多，那他肯定就會換了，因此應用的市場并不會受到太大的影響。

其他的設計結論還有：

• 在Android上支持設備旋轉需要很大的工作量，而這也是很多Bug的根源。
• 在Android上，當旋轉設備時，本質上系統會終止整個視圖棧，當旋轉完成時又會重新創建每個視圖。因此，為了讓GQueues支持旋轉，我需要確保當前的一切狀態能夠在任意時刻被恰當地保存下來，旋轉完成后再恢復狀態。
• iOS上的旋轉只需很少的工作量，其他的都由平臺幫助我們完成了。
• 在iOS上，平臺幫助你管理了幾乎所有與旋轉相關的事情。
• Android與iOS都需要編寫額外的代碼來模擬Flow Layout。

關于Beta測試與發布，Henneke說到；

• Android測試很簡單，你只需發布一個APK的鏈接即可，用戶可以將其下載到設備上。
• Google現在將真實用戶的測試變得更加簡單了，支持在開發者控制臺上發布Alpha與Beta版及階段性發布。
• iOS的Beta測試則要困難一些，雖然可以使用服務TestFlight，它能夠簡化這個過程。為了保證Apple的控制權，用于測試的每個設備的UDID必須要添加到證書中，而證書則用來為應用的Beta版簽名。這樣，每次需要添加Beta測試者時，無論是一個人還是幾個人，我都需要創建并分發一個新的應用構建。另外，Apple每年將注冊的測試設備數限定為100個，因此我需要小心謹慎地分配資源，這也是我的應用的iOS測試數只有Android一半的原因所在。
• 在Google Play上發布GQueues的過程很愉快。我可以在準備好之后就發布應用，單擊按鈕，30分鐘后，應用就可以在全世界的Google Play上出現了，用戶可以將其安裝到自己的設備上。
• 幾乎就像每個iOS開發者一樣，在App Store上發布的體驗令人沮喪。經過了幾個月緊張、嚴格的編碼之后，我開始將應用提交給Apple，等待了7天，然后審核者只花了兩分鐘時間審查我的應用，最后就像例行公事一樣將我拒絕。接下來，我花了一天時間對他們所要求的進行修改，然后再次提交，在最后審批通過前我又等待了8天時間。

Henneke還對兩個平臺上的數據存儲與管理、搜索、正則表達式、分頁、語音輸入、共享與小部件等內容進行了一系列的分析，感興趣的讀者可以在他的博客上閱讀這些內容。

最后，Henneke并不認為這兩個平臺有好壞之分，每個平臺都有“自己擅長且成熟的領域，也有一些需要改進的方面”。

我們還向Henneke問到他希望iOS與Android平臺上再出現哪些特性：

在iOS上，我希望能有siri的API出現，或者至少是語音識別的API。在Android上，我希望能與Google Now進行更深度的集成，這樣真的會很酷。

最后，我們問Henneke為何一開始就從HTML5遷移了過來。根據他的經驗，HTML5尚不成熟：

我之前是個HTML5的堅定擁護者，實際上我撰寫了一篇博文談到了要構建原生應用的想法。簡而言之，HTML5需要提供必要的特性與速度才能與原生應用抗衡。此外，不管怎樣，人們還是喜歡從應用市場下載應用。GQueues的用戶需要原生應用，因此我就滿足了他們的要求。

由于這篇文章只是一個既為Android又為iOS開發應用的個人經歷，因此它并不是為這兩個平臺下的最終結論，特別是沒有說哪個平臺好，哪個平臺不好。盡管如此，Henneke的很多觀點都是恰當的，并且表達出了在這兩個最流行的移動平臺上進行開發的喜怒哀樂。

查看英文原文：iOS vs. Android Development