近日，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