iOS与Android开发之比较

　　应用设计

　　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