近日，GQueues（集成了數(shù)個Google服務(wù)的在線任務(wù)管理器）的創(chuàng)始人與開發(fā)者Cameron Henneke將其應(yīng)用的HTML5移動版本移植到了iOS與Android上，他記錄了在這兩個平臺上的開發(fā)工作量并在博客上對結(jié)果進行了比較。下面的內(nèi)容摘取自Henneke的調(diào)查結(jié)果，并從InfoQ的訪談中摘錄了部分內(nèi)容。
之前的經(jīng)驗
雖然在軟件開發(fā)方面已經(jīng)有超過12年的經(jīng)驗，不過Henneke說他對iOS與Android卻沒什么經(jīng)驗，從他的角度來看，這兩個平臺對他來說處于同一個水平之上：
在開始開發(fā)這個應(yīng)用時，我完全是個Android新手，甚至在這個項目之前我都沒有在電腦上安裝過SDK。同樣，我在iOS上也是個十足的新手。我在2010年那陣兒曾創(chuàng)建過兩個簡單的iPhone游戲，不過他們的復(fù)雜性無法與GQueues應(yīng)用相提并論，并且使用的APIs也完全不同。從那之后我就再沒碰過iOS開發(fā)，直到今年3月開始GQueues項目為止。
開發(fā)
Android
- 一周的時間用來看書、學(xué)習(xí)教程以及創(chuàng)建測試應(yīng)用。
- 一周的時間用來完成最初的設(shè)計階段。
- 開始實際的編碼工作，這花費了大約870小時。
iOS
- 大約花費了兩周時間用來熟悉Core Data APIs，使用PersistentStoreCoordinators與ManagedObjectContexts，并且為“FetchedResultsControllers開發(fā)了一個可伸縮的架構(gòu)”。
- 又花了兩周時間，他“熟悉了iOS開發(fā)”。
總的來看，Henneke在iOS上的學(xué)習(xí)時間是Android上的兩倍。
關(guān)于學(xué)習(xí)資料，Henneke覺得Android文檔的質(zhì)量要高于iOS的。Android的開源特性也有很大的好處，他可以閱讀代碼并從中學(xué)習(xí)。關(guān)于iOS文檔，他說到：
雖然iOS文檔的擴散速度很快，不過由于iOS 5到iOS 6有很多重大的變化（比如說自動引用計數(shù)的引入），因此不少內(nèi)容都過時了。很多代碼示例（包括Apple官方示例）以及解決問題的方式都不太準(zhǔn)確，我們應(yīng)該使用更新的方法進行處理。這種篩選花費了我不少時間。
雖然Android開發(fā)要對“之前HTML 5移動Web應(yīng)用所用的后端服務(wù)器同步代碼”進行完全的重寫，但是相比于iOS，Henneke為Android編寫同樣應(yīng)用所需的時間減少了10%。下表展示了總體的開發(fā)統(tǒng)計：
Android
iOS
開始時間
2012.9.21
2013.3.2
Beta版測試時間
2012.12.22
2013.6.10
應(yīng)用發(fā)布時間
2013.1.31
2013.7.18
項目總時間
4.25個月
4.5個月
等待時間
1周
2周
開發(fā)時間
870小時（近似值）
960小時（近似值）
Beta測試與修復(fù)時間
34天
38天
Beta測試者數(shù)量
92人
48人
代碼行數(shù)
26,981行
23,872行
應(yīng)用下載大小
1.1 MB
3.5 MB
工具
雖然從個人角度來說更喜歡Vim，不過Henneke還是記錄了項目中所使用的如下一些工具的情況：
- 在Eclipse中的搜索速度相當(dāng)慢且繁瑣。
- Xcode Organizer中的文檔搜索速度讓人無法忍受。后來他發(fā)現(xiàn)了提升搜索速度的方法。
- Eclipse中根據(jù)日志標(biāo)簽進行過濾（集成Android插件中的logcat）的特性非常棒。
- 兩個IDE中的代碼完成功能都很不錯。
- Xcode中的Interface Builder沒什么用。
- Xcode Instruments在“分析、度量與調(diào)試”方面的用處非常大。
- Android模擬器用起來非常浪費時間（這么慢的速度簡直就是個笑話）。在開發(fā)期間，我總是將應(yīng)用部署到真實的Android設(shè)備上進行測試，速度會快不少。
- iOS模擬器“速度非常快，使開發(fā)更具效率。對于新代碼來說，我會在模擬器上進行測試，只在代碼成型后才會在真實設(shè)備上進行測試”。
- 對于Android來說，我會對應(yīng)用所支持的每個Android版本進行測試（除了Gingerbread），然后根據(jù)Beta版測試者的反饋來了解設(shè)備覆蓋率。
- 對于iOS來說，他使用了應(yīng)用“所支持的最老與最新的設(shè)備進行測試”。
應(yīng)用設(shè)計
Henneke計劃能讓其應(yīng)用在各種屏幕尺寸上都能夠很容易地進行布局，他發(fā)現(xiàn)Android平臺有“成熟的組件可以幫助開發(fā)者支持各種大小”。他使用了RelativeLayouts，發(fā)現(xiàn)“所有的布局都可以通過XML指定，這是設(shè)計界面的一種整潔、簡單且高效的方式，也是在iOS中創(chuàng)建布局后他所發(fā)現(xiàn)的Android勝于iOS的唯一一個特性”。
我們希望Henneke談?wù)勊麑ndroid碎片化的看法：
我認為Android碎片化有點兒被人們說得過頭了？當(dāng)然了，這是事實。這是Android開發(fā)的很差的一個方面么？不見得吧。Google與Android社區(qū)已經(jīng)采取了很多手段來面對這個挑戰(zhàn)，并且取得了成效。官方的支持庫覆蓋廣泛并且還在持續(xù)發(fā)展。ActionBarSherlock是個強大的第三方庫，可以將新的特性帶到舊設(shè)備上。此外，Google最近發(fā)布的Google Play Services將廠商在碎片化中的作用降低了。用戶不必依賴廠商推送最新版的Android就可以獲得最新的特性。這對于Android用戶與開發(fā)者來說都是一個巨大的進步。
有趣的是，Henneke對于iOS布局的體驗卻不是那么好：
Auto Layout（相當(dāng)于RelativeLayouts）特性很新（iOS 6才引入），它與Interface Builder（IB）的集成太可怕了。我花了好幾天的時間在IB中與Auto Layout戰(zhàn)斗，就像每個iOS 6 開發(fā)者一樣，為視圖構(gòu)建精確的約束，只是為了讓IB能夠完全修改我的規(guī)格，因為它有“智能”系統(tǒng)，可以時時確保準(zhǔn)確的布局。我查閱了很多提示與技巧來處理IB這個問題，但卻無功而返。最后，我干脆不在IB中布局了，而是通過大量樣板代碼來手寫布局。如果不使用IB和Apple的ASCII藝術(shù)風(fēng)格布局編碼，那么Auto Layout實現(xiàn)確實非常強大和直接。推測Apple會在iOS 7中對此進行改進，不過我還是要自己測試一下才行。
使用Auto Layout限制我只能在iOS 6（iPhone 4與5）上進行開發(fā)，之前的版本就不行了，關(guān)于這一點Henneke說到：
GQueues應(yīng)用實際上不能安裝和運行在更老的設(shè)備上，這也是我沒有在這些老設(shè)備上測試的原因所在。在開發(fā)移動應(yīng)用時，第一步就是確定要支持哪些OS版本。iOS 6引入了名為Auto Layout的新特性，這是對老式布局技術(shù)的一個巨大改進，當(dāng)然了，它只能用在運行最新版OS的設(shè)備上。我決定不再使用老式的結(jié)構(gòu)方法和Auto Layout共同來創(chuàng)建布局，而只使用Auto Layout，這能夠極大地降低開發(fā)時間。當(dāng)然了，這意味著GQueues應(yīng)用將只能運行在使用iOS 6的設(shè)備上，不過這已經(jīng)涵蓋了最近兩年的所有設(shè)備。我覺得一個人的電話如果使用了兩年多，那他肯定就會換了，因此應(yīng)用的市場并不會受到太大的影響。
其他的設(shè)計結(jié)論還有：
- 在Android上支持設(shè)備旋轉(zhuǎn)需要很大的工作量，而這也是很多Bug的根源。
- 在Android上，當(dāng)旋轉(zhuǎn)設(shè)備時，本質(zhì)上系統(tǒng)會終止整個視圖棧，當(dāng)旋轉(zhuǎn)完成時又會重新創(chuàng)建每個視圖。因此，為了讓GQueues支持旋轉(zhuǎn)，我需要確保當(dāng)前的一切狀態(tài)能夠在任意時刻被恰當(dāng)?shù)乇４嫦聛�，旋轉(zhuǎn)完成后再恢復(fù)狀態(tài)。
- iOS上的旋轉(zhuǎn)只需很少的工作量，其他的都由平臺幫助我們完成了。
- 在iOS上，平臺幫助你管理了幾乎所有與旋轉(zhuǎn)相關(guān)的事情。
- Android與iOS都需要編寫額外的代碼來模擬Flow Layout。
關(guān)于Beta測試與發(fā)布，Henneke說到；
- Android測試很簡單，你只需發(fā)布一個APK的鏈接即可，用戶可以將其下載到設(shè)備上。
- Google現(xiàn)在將真實用戶的測試變得更加簡單了，支持在開發(fā)者控制臺上發(fā)布Alpha與Beta版及階段性發(fā)布。
- iOS的Beta測試則要困難一些，雖然可以使用服務(wù)TestFlight，它能夠簡化這個過程。為了保證Apple的控制權(quán)，用于測試的每個設(shè)備的UDID必須要添加到證書中，而證書則用來為應(yīng)用的Beta版簽名。這樣，每次需要添加Beta測試者時，無論是一個人還是幾個人，我都需要創(chuàng)建并分發(fā)一個新的應(yīng)用構(gòu)建。另外，Apple每年將注冊的測試設(shè)備數(shù)限定為100個，因此我需要小心謹慎地分配資源，這也是我的應(yīng)用的iOS測試數(shù)只有Android一半的原因所在。
- 在Google Play上發(fā)布GQueues的過程很愉快。我可以在準(zhǔn)備好之后就發(fā)布應(yīng)用，單擊按鈕，30分鐘后，應(yīng)用就可以在全世界的Google Play上出現(xiàn)了，用戶可以將其安裝到自己的設(shè)備上。
- 幾乎就像每個iOS開發(fā)者一樣，在App Store上發(fā)布的體驗令人沮喪。經(jīng)過了幾個月緊張、嚴(yán)格的編碼之后，我開始將應(yīng)用提交給Apple，等待了7天，然后審核者只花了兩分鐘時間審查我的應(yīng)用，最后就像例行公事一樣將我拒絕。接下來，我花了一天時間對他們所要求的進行修改，然后再次提交，在最后審批通過前我又等待了8天時間。
Henneke還對兩個平臺上的數(shù)據(jù)存儲與管理、搜索、正則表達式、分頁、語音輸入、共享與小部件等內(nèi)容進行了一系列的分析，感興趣的讀者可以在他的博客上閱讀這些內(nèi)容。
最后，Henneke并不認為這兩個平臺有好壞之分，每個平臺都有“自己擅長且成熟的領(lǐng)域，也有一些需要改進的方面”。
我們還向Henneke問到他希望iOS與Android平臺上再出現(xiàn)哪些特性：
在iOS上，我希望能有siri的API出現(xiàn)，或者至少是語音識別的API。在Android上，我希望能與Google Now進行更深度的集成，這樣真的會很酷。
最后，我們問Henneke為何一開始就從HTML5遷移了過來。根據(jù)他的經(jīng)驗，HTML5尚不成熟：
我之前是個HTML5的堅定擁護者，實際上我撰寫了一篇博文談到了要構(gòu)建原生應(yīng)用的想法。簡而言之，HTML5需要提供必要的特性與速度才能與原生應(yīng)用抗衡。此外，不管怎樣，人們還是喜歡從應(yīng)用市場下載應(yīng)用。GQueues的用戶需要原生應(yīng)用，因此我就滿足了他們的要求。
由于這篇文章只是一個既為Android又為iOS開發(fā)應(yīng)用的個人經(jīng)歷，因此它并不是為這兩個平臺下的最終結(jié)論，特別是沒有說哪個平臺好，哪個平臺不好。盡管如此，Henneke的很多觀點都是恰當(dāng)?shù)�，并且表達出了在這兩個最流行的移動平臺上進行開發(fā)的喜怒哀樂。
查看英文原文：iOS vs. Android Development