近日，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%。下表展示了总体的开发统计：

工具

虽然从个人角度来说更喜欢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共同来