如何做一套设计稿兼容Android和iOS双平台，IOS和安卓UI的区别
来源：视觉中国&&&作者：adminli&&&发布时间：&&&
浏览次数：8783
现在许多公司都需要设计可以同时运行于Android和 iPhones平台的App。在理想状态下，我们应该单独花数月时间分别设计两个app。然而在现实中，设计一个app的时间就已经很紧了。更通行的做法是设计一个app，然后把它交给两个不同的团队去开发。如果你也按这种方式开发app的，那么提前了解一下Android和 iPhones平台的差异是很有必要的。1.了解对手
通常的情况是每个人都有自己偏爱的系统。那我自己来说，我觉得iPhones给我的感觉更自然一些。但要了解另一个平台，最好的办法就是买一台支持该平台的设备。如果可以的话，最好一直坚持使用这个设备，直到这个app项目结束为止。如果你是个自由设计师，新设备的价格也许会让你心疼，但与它能带给你带来的长远收益相比，这是值得的。2.选择平台
因为设计app的日程通常非常紧张，而我们又只能选择其中一个平台的app，所以从开始我们应该根据市场需求，决定究竟以哪种app开始。诸如这款app将更多用于安卓手机吗？这款app是否需要付费？目标人群有哪些？研究一下这些问题有助于我们做出正确的选择。3.熟悉规则
在开始设计之前，首先要了解Android 和iOS平台的官方设计指南。在过去，一款app在进入苹果的应用商店之前，通常需要两周时间等待审核。相对而言进入谷歌Play的门槛要低一些。但随着谷歌Material Design设计指南的完善，这一情况也在逐渐改变。安卓和IOS系统的区别分为以下几点：1. 总体风格
从iOS7开始，苹果摒弃了尝试在早期的iPhone中使用的拟物化（skeuomorphic）设计风格，转向扁平化设计。而谷歌的情况却相反。谷歌新推出的Material Design指南倾向于营造更接近真实世界的效果。2. 真实按钮
安卓手机有一个&后退（back）&按钮，在app界面中，它可以让用户回到早先的界面。
iPhones上没有这个按钮，回到上个界面的操作一般是通过屏幕左上角的&返回上一级&图标实现的，但但使用时需要考虑app界面的不同路径。3.全局元素
有一些全局性图标（如状态和首标）会出现在所有界面中。如果想你的设计看起来很自然的话，就不要去改动这些条形的高度和风格。我建议在你设计第一个界面时就将这些元素定义好。在后续设计中，你可以在模拟文件中使用占位图形（或OS中的状态和首标）来代替它们，但一定要告诉开发人员，在所有页面中这些元素都应该保持一致。
两个平台在导航设计上略有不同。在安卓系统中，标题文字是左对齐的，而在iOS中，文字是居中的。在iOS中，很多公司都会将标题替换为公司图标，但在安卓系统中，这却并非是一个好的策略。因为状态条（包括信号，电池和时间等信息）是原生系统自带的，无需考虑它的设计。需要保证的是在制作模拟文件时，要使用正确的图标以免造成误解。4. 导航
或许安卓与iOS最大的不同之处体现在各自的导航上。安卓平台的主要导航方式是一个抽屉式目录。在用户使用app的整个过程中，他似乎始终出现在界面里。而苹果的导航使用的是标签栏的模式，它位于屏幕的下方，允许用户查看app中不同的一级活动区。所以在设计app的一级活动区时，应该分别针对两种平台设计不同的目录。
从整体上考虑，app的结构或许比导航目录更为重要。如果app的整体结构良好，那么导航条也会较为出色。正如我们刚才说过的，你要面对的导航模式有两种，Android中的抽屉式目录和iOS中的标签栏。在设计单独的页面时，有时把导航层直接隐藏也不失为一个办法。5. 是否使用卡牌界面
卡牌式界面（Cards）正在逐渐成为数字设计中重要的UI类型。他们用途灵活，便于用户快速理解界面中的内容。从视觉效果上讲，卡牌式界面也与安卓material design的理念非常一致。卡牌之间的阴影使它看起来感觉非常自然。
在iOS中，使用卡牌界面则需要审慎行事。即便是像Facebook 和Pinterest这样的大公司，当他们使用卡牌设计时，也给人以不太符合iOS设计指南的感觉。
iOS建议设计师使用幻灯片和层叠效果，但其基本试图则更为贴近扁平化设计风格。Instagram的app全部采用了扁平化风格的设计，虽然从总体结构上讲，它的每个帖子更应该被看成是卡牌界面。因此如果你想在iOS平台下使用卡牌式界面的话，一定要小心使用阴影效果，并尽可能使阴影看起来十分柔和。6. 排版
iOS系统使用的字体是Helvetica Neue，而安卓使用的是Roboto。虽然两种字体的风格各不相同，但它们的规格是接近的。如果想保证速度的话，也可以选择一种字体使用。但需要与开发者做好沟通，选择的字体大小要适用于平台中。在处理较为重要的布局或极端大小的字号时，建议对两种字体都进行测试。
如果想追求效果的话，则需要你根据两种平台的不同特点，做出进一步的优化。以下仅是一些需要注意的要点：
安卓的Material Design在布局中使用了大量的白空间
在 material design中，字体的使用更为大胆.。造型夸张的标题配合以大量的空间往往能起到分层的作用。
在iOS中, 缺少戏剧性的变化。但通过调节字号的大小。同样能起到分层的作用。
在典型情况下，两个平台使用的都是字体库中较小的字号。然而在下面的示例中我们也可以看到，安卓使用的是较小的规范字体，而iOS 使用的却是加粗的Helvetica Neue规范字体。这个简单的示例说明，即使是非常简单的排版，在安卓和iOS 中呈现出的效果也是截然不同的。7. 分层和触控目标
iOS (44px @1x)和 Android (48dp - 48px at 1:1 比例)对于触控目标的设计指南有所不同。Material Design建议将所有元素按8dp 方形基线网格（square baseline grid）对齐。
根据我从最新项目中获得的经验，我认为遵循安卓的设计指南更为可靠一些，因为(a) 48px的触控目标更大，因此在两个平台中的应用更为可靠(b) Material design的布局更符合当前的设计趋势。总之，你需要一个可靠的网格，但安卓的定义更为严格，我们发现在安卓平台下，8dp的网格效果良好。这意味着为了创建一个瓦片网格（tiled grid）布局，你需要将垂直面和水平面都设置为8dp变量（ increments）。8. 按钮风格
Material Design定义了几种不同的按钮风格： 1.浮动式活动按钮: 这是最传统的按钮样式。它投下的阴影很重，看起来就像浮在页面上。这类按钮应该仅仅应用于背景中，在卡牌式界面中使用时应该非常谨慎。不应在弹出式提示中使用这类按钮，因为会创造太多分层。主要活动按钮应使用强调色，而次级活动按钮使用稍弱一些的颜色。
2.扁平按钮: 关键文本使用强调色，没有任何界限清晰的元素。这类按钮使用边距和所有的大写字母来形成结构。
与Material Design设计相比，iOS app采用的是典型的扁平化风格，不使用分层或阴影效果。主活动按钮采用填充色，而次级活动按钮则采用同一色调的反白（reversed out）。为了将扁平化风格设置的恰到好处，一定要保证颜色的使用清晰，一致。iOS平台下也有简洁文字风格的按钮，但它并不具备安卓按钮的大写字母风格，字号相对也较小一些。9. 行动表单
行动表单允许用户从一个UI中选择不同的操作。例如，当我触控一张图片时，我可以进行分享，上传，复制或删除等不同操作。
iOS 和Android系统对这一情况采取的方法是不同的。尽管两个平台都使用了近似的行动表单，这种表单一般在屏幕下方，并会部分地覆盖当前页面。
但安卓和iOS使用了不同的细节来显示分层。
Android的分层使用单色，并略带阴影， 为的是提示用户当前界面被一层&纸&覆盖住了。
iOS的分层没有阴影，但带有透明度很低的背景。10、下拉按钮
下拉按钮只存在于安卓系统中，它的作用是让用户快速做出选择。要注意的是，原生的iOS系统中没有与之对应的按钮。在下面的截图中，如果用户按住步骤1中的&资料&（ profile）按钮，那么该位置就会显示出一个简单的目录，供用户选择一份可以查看的个人资料。这些目录也常被用于行动条区域叠加层的按钮中，三个垂直排列的黑点显示了它们的存在。11、特殊数据输入
对于像事件和日期这样的特殊数据，目前安卓已经开发出内置的对话系统。它在形式上很像弹出式提示框，但UI是专门针对此类型的数据输入开发的。例如日期的输入，安卓有专门针对日期输入的优化界面。而iOS的方法是一个从底部显示的圆盘。这是在设计之初就需要注意的。12、.分段控件
分段控件的作用是在同一个视图下切换不同的内容。它们的作用是相同的，但在视觉上又各不相同，所以我们在针对不同的平台设计时要注意到这一点。在iOS系统下有三个标签，样式大致相同，并排排列在我们前面提到过的按钮上。在安卓系统下，则是用一条简单的下划线标出了他们的位置，其余充足的负空间是为了提示用户它们之间存在互动。13. 提示消息
提示消息在整个设计中占有重要的位置，因为它们控制着一些关键的操作，如注册，接受协议甚至是确认付款，所以务必要确保它们的样式是合适的。
安卓系统下的提示消息采用的是我们前面讨论过的扁平风格按钮。material design的设计指南中规定了他们的尺寸。操作按钮一般是位于提示信息的正下方。这里的&按钮&其实全部是文本。它们一般都是大写字母，以营造一种均衡感，它们的颜色一般是与app主要操作按钮的颜色一致。
在iOS系统中，操作按钮之间有分隔线。它们在形式上通常是一句话或大写标题，分隔开的区域同样给人一种稳定之感。它们一般位于屏幕正中央，在颜色上也与主操作按钮颜色一致。14. 图标
图标是UI中需要专业人士设计的部分之一。无论打算采用免费图标，还是请专业的设计师来设计，都要注意安卓平台和iOS下图标的不同特点。iOS中的图标是简洁的线条，笔触较为轻盈。而安卓系统的图标笔触较为浓重，有时甚至是完全实心的图标。在过去，安卓曾使用特殊视角和三维的图标，但现在改用二维图标了。以下就是这两个平台中一些图标的对比。13. 小图标和加载图像
在设计中，我们可能会忽视一些微小的UI细节。有一些图标，如提示和加载图标通常是由开发者自己解决的。你可能就遇到过与当前的app风格截然不同的奇怪提示。它们可是源于原生系统的默认提示，但同样是可以通过改动，使之与app风格一致的。在处理这种情况时，需要开发者与设计师密切合作。14.通用UI控件
单选按钮，复选框，切换按钮等实用的元素也应该被赋予自然的风格。正如提示消息和对话框一样，这些元素控制的一些在用户看来代表着信任和友好的区域。这些元素应该尽量实用原生系统的元素，这样至少有两个好处：(a)用户知道如何使用它们 (b)让用户处理敏感数据或确认支付时感到放心。
从下面的示例图中我们可以看到，开关和单选按钮在Android和iOS中几乎是一样的。在这里，设计师可以先做出一个设计，然后根据不同的平台进行微调。但即便是外观上的细微差异，也能体现出这些元素是否符合各自平台的风格。因此在设计这些元素时应该多使用你的UI工具包，并且在设计的早期阶段就与开发人员做好沟通。
Android (左) 和 iOS (右)结语
设计出在两种平台下都与原生系统在风格上协调一致的app并非不可能。并且现在的app设计风格基本上是你中有我，我中有你的情况，安卓的app中也有借鉴IOS的设计。我们需要做的就是从设计开始就密切留意两种平台在设计元素上的差异，为以后的微调留出余地，还要注意与开发者密切沟通，这样才能做出一款不错的app。
感觉还不错，那就赞助一下吧！您的鼓励就是我们坚持的动力！
打赏说明：您的赞助我们将用于购买网络带宽和优质设计资源，提升用户体验！
http://www.17xsj.com/UIsheji/lilunjiqiao/2221.html
一键快速登录后才能下载本站资源
新会员登录即可获取10学币奖励，超爽下载！94被浏览32,242分享邀请回答31 条评论分享收藏感谢收起23 条评论分享收藏感谢收起51CTO旗下网站
Android和iOS孰优孰劣：真实应用开发过程告诉你答案
从上面的分析来看，做GQueues的过程中，并没有出现平台A完胜平台B的情况。Android和iOS在某些领域各有千秋，也都有需要改进的地方。
作者：佚名来源：blog.jobbole| 14:26
随便搜索一下&Android&vs.&iOS&，都会出现很多关于哪个平台更好的争论，大多数的争论点都是关于市场占有率、易用性和设备分化等问 题。当然也有一些&以开发者的角度&去比较这两个平台的文章，但是很少有从技术上做深入的比较，通常也只是用一个简单的示例应用介绍一些基本的特性。缺少 这种深入的比较其实是有原因的：一个公司要做一个足够复杂的移动应用，通常需要一个人或团队做Android，另外一个人或团队做iOS。这两个平台使用 不同的编程语言（Java和Objective-C），提供不同的SDK，使用不同的开发工具，所以人力资源分配上各做各的平台也就不奇怪了。
GQueues是一个在线任务管理器，之前只有一个HTML5版本。最近我完成了GQueues&for&Android
和GQueues&for&iPhone&&&iPad
的开发。虽然这两个应用的复杂程度不能和第一人称射击游戏相提并论，但也绝不简单&&&为用户存储和管理数以千计的任务信息、支持多账户、提供到WEB端 的后台同步、复杂的过滤、排序和分组功能。通过这次的实践，我希望透过独特的视角，分析和比较为这两个平台开发GQueues应用的过程。
Android&App
Sept&21,&2012
Mar&2,&2013
第一个可测的Beta版本
Dec&22,&2012
June&10,&2013
应用发布日期
Jan&31,&2013
July&18,&2013
项目总耗时
4.25&months
4.5&months
Ramp&Up&Time
870&hours&(approx)
960&hours&(approx)
Beta测试&Bugfix
Beta测试人员人数
26,981&lines
23,872&lines
我已经写了12年的代码，但这是我写的第一个Android应用，也是我写的第一个偏向数据处理的iOS应用（2010年我做过两个iOS&3上的 游戏，但那两个游戏主要只涉及一些动画和蓝牙连接）。&我最后一次用Java是在研究生阶段，而我的Objective-C也仅限于那两个游戏。所以对于 这两个平台，我基本上可以算是从零开始。
简单讲，只需要花一半学习iOS的时间来学习Android，我就能开始Android开发。对于Android，我花了一周时间用来看书、跟着一 些教程做一些测试应用，这些测试应用包含了GQueues将会用到的一些核心功能。做完这些，我基本上算是打好了为GQueues设计架构的基础，同时也 可以开始为这个项目写代码了。在接下来的一周我可以很轻松自如地基于Android做开发，而不再需要依赖某个资源去实现新特性了。
对于iOS，我同样按照上面的流程，但我花了两周时间做各种测试/实验，才让自己觉得可以开始为这个项目写一些基础代码了。其中大部分的时间都花在研究CoreData各种复杂的API上面。搞清楚怎么设置、怎么在线程安全的前提下，为每个用户集中管理和也花了些功夫，最重要的是要支持多账户（这个话题可能需要另一篇博客来单独讲讲）。为开发一个可扩展的架构花了更多时间，用于支持可被用户查看以及操作的任务表单、队列和分类。最后又过了两周（总共花了一个月）自己才能比较轻松自如地基于iOS写代码。
总的来说，Android的文档（官方文档、第三方教程、图书、代码示例、StackOverflow）质量都非常高。我从一些著名的开源 Android应用中学到了很多架构上的最佳实践，如Google开放给开发者的2012&Google&I/O&app。此外，Android本身就是 开源的，必要时我可以自己查看Android的平台代码，弄清楚一些疑难问题。虽然iOS也有很多文档，但由于iOS5和iOS6相比之前的版本改动非常 大，大部分文档都已经过时，其中包括ARC入门一文（）。因此，大部分的示例代码（包括Apple官方示例）和一些问题的解决方法都是不正确的，需要使用新的方法取而代之。搞清楚这些肯定也需要花更多的时间。
从上面的统计表中也可以看出，开发GQueues&for&Android要比开发 iOS
版的快十分之一的时间，尽管在开发Android版的期间我重新实现了之前用于支持GQueues&HTML5版的整个后端服务器同步代码。而开发一个不 采用原始iOS6风格UI的应用也需要多花些时间，单单比较这个数据，Android开发就是比iOS开发快。
用到的资源
Android App
上面列出来的书其实用处很有限，因为跟大部分的技术类书籍一样，书的内容都有点过时了，而且大部分书只停留在入门级别的概念介绍。不过，在一开始的前几天看一下这些书，能够比较快地理解平台上的一些核心功能。就目前来讲，对于这两个平台，在线资源仍然是最有价值的。
接下来我只简单说一下这两个平台的开发工具，因为关于这个话题已经有很多的讨论。我不是Eclipse或者XCode的脑残粉，它们有各自的强项和 弱点（其实我最喜欢的还是Vim）。Eclipse的搜索暴慢而且很繁琐。XCode&Organizer的文档搜索也卡爆了。Eclipse中使用 log&tags（通过Android插件的logcat集成）过滤日志超级实用。两个IDE的代码补全都很不错，XCode的 Interface&Builder一点用处都没有（后面细讲）。不过XCode&Instruments就非常有用了，可以用它做优化分析、调试等等。 我开始做GQueues&for&Android的时候，Google还没发布Android&Studio，不过在GQueues的后续更新版本中我会 拿它来试试。
如果你一边写代码一边测试，用Android的模拟器简直就是浪费时间（真不敢相信它能慢成这个鸟样）。在开发过程中，我都是直接部署到真机上测试 的，用真机快很多。iOS的模拟器则很不同，跟Android相比简直就是火箭跟蜗牛赛跑，这也让整个开发过程更加高效。每写一小段代码我都会在模拟器上 跑一下，等到整个功能完成了我就会部署到真机上玩玩。
对于Android，我有各个版本的测试机器（除了Gingerbread，即Android&2.3），除此之外，就要倚靠beta测试过程中各种设备的覆盖了。对于iOS来讲就要简单很多了，我只需要拿GQueues需要支持的最旧的和最新的机器来测试就够了。
Android App
Samsung Infuse (Froyo 2.2)
Nexus S (ICS 4.0.3)
Galaxy Nexus (Jelly Bean 4.2)
Samsung Galaxy Tab 10.1 (Honeycomb 3.2)
Nexus 7 (Jelly Bean 4.2)
iPhone 4 (iOS 6)
iPhone 5 (iOS 6)
iPad 2 (iOS 6)
iPad 4th generation (iOS 6)
GQueues的其中一个需求就是必须同时支持任意尺寸的手机和平板，并且针对不同的表单元素进行优化布局。由于各种各样的设备都运行着 Android系统，Android也理所当然地有着成熟的UI组件帮助开发者支持各种尺寸。例如从Android第一个版本开 始，RelativeLayout提供了View之间相对布局的支持，可用于创建灵活、响应迅速的布局。另外，在Android中所有的布局都由XML定 义，这设计界面的方式非常简洁、简单并且高效，试过iOS中创建布局之后这种体会就更加深刻了。
相对于Android的RelativeLayout，iOS有Auto&Layout，这种布局方式比较新（iOS&6新引入的），集成到了 Interface&Builder(IB)中，但是太难用了。我花了好多天学习IB中怎么用Auto&Layout，跟任何iOS&6开发者一样，仅靠 IB为视图（View）设定各种精确的约束，完全改变了我自己的标准，这是因为IB所谓的&智能&系统时刻维持（纠正）着视图布局相对位置。我学了很多技 巧，想着弥补IB的短板，但是没啥作用。最后我只能放弃IB，转而用冗长的代码实现所有布局。如果你放弃IB和富有极客范的 ASCII&art&style来写布局，使用Auto&Layout来实现还是很强大、很直接的。希望苹果在iOS&7中已经改善这些，不过我还木有试 过。
如果一个应用需要同时针对小屏设备和大屏设备进行优化，最关键的就是基于屏幕的真实尺寸进行动态组合视图，这种方式被称作&适配性布局 (Adaptive&Layout)&，平板电脑可以在一屏中显示两个或三个视图，而手机上一屏则只显示一个视图。Android通过Fragments 支持这种设计，Fragment是一个独立的、自包含的的模块，能够在需要的时候直接丢到Activity中去用。通过使用Fragments，只需要调 整几行XML代码就可以让GQueues的布局适配不同分辨率的屏幕。对于我来讲，Fragments是一种非常自然的解决方案，因为它是基于面向对象里 面两个众所周知的准则设计的&-&高内聚和低耦合。
通过Custom&Container&View&Controller（你也可以用Master-Detail模板，当然这种方式宽度是固定的， 也不支持个性化定制），iOS支持一屏使用多个ViewController。对于这个不成熟的特性，我觉得Apple的文档显得很复杂和不完整，最好的 资源还要数Ray&s&iOS5&tutorials和WWDC视频。我花了比预计要多的时间，终于搞好了在iPad上同时显示多个View、在 iPhone上显示单个View的布局架构。
简单说，在Android上支持设备翻转需要做很多工作，这些工作也是最终导致很多bug的源头，而在iOS上，支持屏幕翻转只需要做一点点工作， 剩下就是系统帮我们搞定了。在Android上，屏幕翻转会直接销毁现有整个视图栈（Activity栈），屏幕翻转完成后再重建每个视图。所以在 GQueues中支持屏幕翻转，我需要无时无刻保存好所有当前状态，随时保证翻转后能正常恢复状态。而在iOS上，系统会帮你管理所有屏幕翻转相关的细 节，唯一需要我关心的就是翻转之后，我需要调整那些没有被Auto&Layout处理好的视图的位置。
&复杂&布局
网页开发上有一些常见的布局在GQueues上实现起来非常困难，不管是Android还是iOS。其中一个例子是在任务详细界面显示标签。每个标 签都是变长的，在必要时标签需要自动换行。在网页上实现这个只需要设置CSS的float值就可以了。但不管是Android还是iOS对这种&流式布 局&（Flow&Layout）都没有原生的支持，这也意味着我需要写很多代码自己去计算和摆放这些标签，以达到&流式布局&的效果。最后Android 的代码是基于的演讲内容和的flow&layout实现的。在iOS上也采用了类似的方法，基于容器的总宽度，计算每个标签的宽度，最后设置auto&layout的参数。对于这个布局的实现在两个平台上都耗了很大的工作量。
旧设备支持
关于Android的生态系统常被人吐槽的就是严重的系统分化。运营商推送更新的步伐总是很慢，所以现在仍有大量运行着旧系统的设备，这也就意味着 如果要保证应用足够大的设备覆盖率，开发者就不能使用新版系统带来的新特性。不过好在现在针对这个问题，Android社区做了很大的努力，提供了一些用 于在旧系统上支持新特性的库。通过使用Android官方的&和Jake&Wharton的&Library，我几乎可以在Android&2.2上使用Jelly&Bean（4.2）中所有的新特性。
对于iOS来说，支持旧系统一说几乎不存在，或者说根本就不是关键。在准备阶段我花了一些时间考虑从哪个iOS版本开始支持，而当时的统计数据显示使用iOS&6系统的设备已经达到， 而当时对于放弃支持iPad一代我也有一些疑虑，因为我老爸老妈老姐用的就是iPad一代，他们将是GQueues的铁杆支持者。最后我决定还是只支持 iOS&6+，这样我可以放开手使用Auto&Layout，而不需要浪费大量时间实现任何过时的布局技术。当然，我解决了iPad一代的问题（至少对我 家里人说来说已经解决），就是换掉他们的iPad一代，给他们每人买一个iPad四代（作者有钱银）。
数据存储和管理
对于GQueues来说，数据是核心&-&把数据保存到设备上然后同步到WEB端。Android和iOS有着完全不同的数据管理系统。 Android提供了ContentProvider，它是SQLite数据库上层的一个可被继承的应用接口，作为一个结构化框架被用于所有应用的数据处 理。ContentProvider学习起来比较难，搞定一个GQueues可用的实现，前期需要花很多工作。一旦搞定了第一步后面的扩展和个性化定制都 变得简单多了。
一些背景信息，GQueues的web&service是基于的， 这是一个高扩展性的分布式NoSQL存储系统，而SQLite则是一个标准的关系型数据库，扩展性明显也比较差，但这完全不需要考虑，因为这个应用只存储 一个用户的数据。（顺便说一下，架构上我采用了&一个用户对应一个数据库&的设计，这对于快速简单地实现多用户切换有重要意义，不过实现细节可能得再开一 博来聊了）。不管怎么说，Android的一个很大的优点就是可以创建来支持。为了支持，搞清楚各种复杂的表关联查询和子查询也花了写功夫，但是这也让Smart&Queues的加载更加高效和快速，因为过滤不是在代码里面实现的（在SQL里面）。
在iOS上，我用的是， 它是iOS上的&schema驱动数据图形管理和持久化框架&，基本上它可以被看做是一个NoSQL存储，不过有趣的是，Core&Data背后实际上是 SQLite数据库（呃&实际上SQLite也是几个可选项中最合理的选择）。iOS也允许用户直接创建SQLite数据库，但只支持通过纯C代码来操 作，对于其他iOS组件没有原生集成。Core&Data的学习起来也比较困难，但最后我还是选择Core&Data而不用SQLite，因为这样我可以 轻松实现很多功能，包括缓存、数据模型迁移支持，还有通过&NSFetchedResultsController，可以非常简单地为界面中的 table（列表）提供数据。
管理数据集的关键就是使用事务，尤其重要是做数据同步的时候&-&ACID，即：atomic（原子性）、consistent（一致性）、 isolated（隔离性）、durable（持久性）。Android上实现事务似很直观，跟大部分关系型数据库管理系统的实现方式是一样的，因此，保 证数据完整性并不困难。另外，用好SQLite中的UNIQUE&&REPLACE语句，在数据同步的过程中建表、对记录进行原子更新的时候几乎不需要做任何额外工作。
严格来讲，Core&Data并不完全支持事务。通过使用单独的子ManagedObjectContexts做后台线程处理，再加上@synchronized，能够处理好数据更新和同步，同时避免不正确的写操作覆盖(overwrite)。关于，iOS给的建议帮助很小，总的来说，CoreData给我的赶脚很笨重，并没有它声称的那么好用。另外，在Android上，SQLite可以轻松实现快速加载Smart&Queues，而在iOS上，所有的过滤都必须在代码中实现，就算用了大量的缓存，速度仍然很慢。
在GQueues&for&Android上增加强大的全文搜索功能很简单，我模仿Google&I/O应用里面的搜索实现，使用了SQLite的特性。首先创建一个虚拟表，然后在一个存储了用户任务的表上设置几个触发器，由这些触发器填充数据到虚拟表。做完了这些，剩下的就是设计一个搜索界面和为搜索历史添加存储。
iOS的Core&Data对于全文搜索并没有原生支持，所以我通过在谓词（Predicate）中使用LIKE语句，实现基本的任务描述和日记的搜索功能。这个实现当然没有全文搜索那么强大，但我认为它已经能够覆盖现实生活中大部分的使用场景了。
用于比较，我只会列举在GQueues中使用到的几个API。
快速添加（Quick&Add）
正则表达式在实现GQueues中解 析的时候扮演着一个非常重要的角色，幸运的是，Android和iOS对于正则表达式都有着原生的支持。Android中的Pattern和 Matcher从第一个版本起就开始支持，同时也包含了很多正则语法，其中包括前向断言（look-ahead&assertion）和后向断言 （look-behind&assertion）。iOS则从iOS&4开始引入类，令人高兴的是，我可以把我在Android上辛辛苦苦写好的正则表达式几乎原封不动地搬到了iOS上。
在设计界面的时候，我希望用户在查看任务详细的时候左右滑动切换。在Android上我用了&和新的类，FragmentStatePagerAdapter 还处于试验阶段，并且只能通过支持库（Support&Library）来使用。我花了几天的时间实现了一个绑定好数据的初级版本，同时解决了几个关于重 复菜单项的bug和在数据发生变化后的处理。这些比我预想的要困难很多，要不是因为左右滑动切换任务的用户体验那么好的话，我真不想实现这个功能。iOS 上的就简单很多了，虽然也有一些奇怪问题要解决，并且需要自己再加上缓存支持使滑动复杂视图的时候达到可用状态。
Android提供了了一个先进但很容易使用的speech-to-text&API，只用20行代码，我就把集成到GQueues，提供了一个。但很遗憾，iOS并没有提供支撑SIRI背后技术的API，开发者只能使用第三方库，依赖键盘上的麦克风提供语音输入的支持。我找了各种第三方库，包括&-&SIRI语音识别的提供商，但发现没有免费版本，收费版本价格不菲。所以最后GQueues只能靠用户自己使用键盘上内置的麦克风选项来进行语音输入，其实这也已经足够了，只要用户还记得有这么个功能。
分享/插件(小部件)
通过使用Intent，在Android上可以很容易就可以把我的应用集成到安装在用户手机上的其他应用。同样地，只需要很少的代码，通过支持&intent，我就能够让用户在其他应用中创建GQueues任务。Android同时也提供了一个小部件平台，于是我也做了几个小部件，以后还会增加一些。iOS对于跨应用集成和桌面小部件的支持度为零，完全不支持这两个功能。
测试和发布
在上面的统计概况表中已经指出，beta版面向真实用户测试了一个多月。两组测试人员都非常棒，帮我找到了数十计的bug，提出了增加一些特性的建 议，对一些UI上不合理的地方提出了反馈。我通过私有的Google&Group组织beta测试，这样的beta测试保证了最后发布的应用对人们是真正 有用的。在每次beta测试的最后，通过调查问卷我收集到了很多有建设性的反馈，也帮助进一步判断我的应用是否达到了可发布的状态。
让测试者开始测试只需要发个APK的链接，让他们下载到他们机器上（呃..他们还需要在设置界面中开启&允许安装Google&Play以外的应用&的选项）。Google很方便地支持用真实用户来进行alpha和beta测试，可在中进行设置。在未来的版本更新中我想用用这两个功能。
iOS中的beta测试困难得多，就算用了服 务，虽然TestFlight很大程度地简化了流程。为了满足Apple的控制欲，每部测试设备的UUID都要加到用于签名beta版应用的证书当中。因 此，每次要添加beta测试者的时候，不论是添加一个人还是一群人，我都需要重新build一遍我的app。除此之外，Apple还限制了你一年最多只能 注册100个测试设备。所以我要小心利用好这100个坑，这也是为什么GQueues的iOS测试者只有Android的一半。
当然，不谈谈发布流程，Android和iOS的比较都不算完，在Google&Play上发布GQueues是一件很好玩的事情，只要我认为已经 准备好了，我随时可以发布我的应用。点下按钮之后，30分钟内，我的应用就能在Google&Play上被全世界的用户找到并安装到他们的设备上。而在 App&Store上发布一款应用，相信每个iOS开发者都有同样的感受，那是一个令人感到郁闷的经历。经过了数月紧张严密的编码，我只能把我的创作提交 给Apple，然后等7天，7天之后审核人员花2分钟看看我的应用，最后拒绝了我的提交。我只能按要求做了修改之后再次提交，我又得等8天才在最后通过了 审核。当然还有很多关于提交应用到App&Store的恐怖故事，跟他们比起来，我就像是公园里逛了一圈。尽管如此，在自己的商业控制上要对这样一个&情 绪化的第三方平台&做出那么多的让步，仍然让我觉得很不爽。
获胜的平台
从上面的分析来看，做GQueues的过程中，并没有出现平台A完胜平台B的情况。Android和iOS在某些领域各有千秋，也都有需要改进的地 方。从这两个平台的历史来看，貌似目前Android势头更猛一些，不止体现在市场占有率上，而是看到了Android近两年在UI上的改进和开发平台的 稳步提升。而Apple则是封闭的王者，我也坚信他们在很努力地做着他们认为是下一代移动计算革命的事情。不管怎么说，当我想想这6年间所兴起的app生 态圈，我为自己在这个移动技术快速更新的时代，能在这两个平台上做开发感到荣幸。【编辑推荐】【责任编辑： TEL：（010）】
大家都在看猜你喜欢
聚焦热点头条头条热点
24H热文一周话题本月最赞
讲师：27128人学习过
讲师：14893人学习过
讲师：12981人学习过
精选博文论坛热帖下载排行
本书结合大量的典型实例，详细介绍了用Java来编写网络应用程序的技术。本书的范例都基于最新的JDK 1.5版本，书中内容包括：Java网络编程的...
订阅51CTO邮刊}