iOS 与 Android 开发之比较

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