配置
正如我提到的，在Xcode和Objective-C漂亮、无缝的外表之下，隐藏着上世纪70年代编程的偏爱工匠手艺的恐怖。开玩笑的……但是宏和头文件；项目、target、scheme以及build配置；繁多的build设置列表；遭遇令人困惑的linker错误时的绝望；以及“噢，这个第三方代码居然不支持ARC？只需加上-fno-objc-arc标记！简单，不？”的发现。
Android的配置文件只有一个，每当开发者保存一次文件，Eclipse就会build一次应用。我希望在因配置授权不当而导致应用不工作时，错误消息能提供更多信息，但这只是小地方。总体来说，Android的应用配置简单且简洁。
优势：Android。
UX设计
你应该预料的到，苹果会拿走这一奖杯。Xcode的Interface Builder（界面搭建器）能非常迅速地将简单、漂亮的用户界面以一种非常赏心悦目地方式组织在一起。问题是，我用Interface Builder的次数越多，我就越不喜欢它。这又加了一层配置复杂度；对于简单应用而言，Interface Builder很好，但随着时间推移和应用发展，这些简单的东西会变得复杂、混乱；而且我也非常不喜欢苹果在大约一年前增加的多屏Storyboard。
理论上，Android要有一个可比肩的视觉工具，但还是少提为好。实际上，你需要编写提供布局指导的XML文件，以便让应用在多种设备的多种屏幕上渲染得很好（希望如此）。（苹果的自动布局也是朝相同的方向前进，肯定是着眼于未来会出现更多尺寸的iOS屏幕）同时，Android提供了一个图标包供开发者们使用，而iOS开发者们则必须使用Icons8等第三方服务或自己制作。
总的来说，这方面的竞争要比你想象的差距小，尽管我承认，这给人的感觉相当古怪。最终说来，两样东西让iOS占据优势。首先，Xcode要简单的多：只有三种屏幕尺寸（包括iPad）和两种屏幕密度，而不像Android一样复杂。其次，默认的iOS视觉元素——如弹出目录和消息——看起来要比Android的吸引人得多。
优势：iOS。
语言
Android应用使用Java编写；iOS应用使用Objective-C。也有例外，如Xamarin；还有其他小众原生应用案例；以及PhoneGap等原生/网络混合体，但总体而言，原生Android应用使用Java编写，原生iOS应用使用Objective-C编写。
我是从Java开始的，起初并没有想太多要用Objective-C，大部分原因是Objective-C非常啰嗦：比如语句
String s2 = s1.replace(“abc”,”xyz”);
在Objective-C中变成了
NSString *s2 = [s1 stringByReplacingOccurrencesOfString:@"abc" withString:@"xyz"];
但我变得越发喜欢起Objective-C来。Objective-C比Java更好、更整洁。Objective-C有代码块(block)，Java没有。Objective-C有类别(category)，Java没有。Objective-C不用你写很多try/catch，Java还要你处理空白。
Java也有其优势。比如更好的堆栈踪迹(stack trace)，这让追踪零星的错误变得更容易。两年前，Android还有垃圾收集的巨大优势，但现在iOS有了ARC，这一优势就消失无踪了（尽管老的第三方工具通常不支持ARC，开发者必须进行一些XCode配置，才能安文件关闭ARC）。这一区别消失，赢家就很明显了。
API
Android和iOS都向开发者们提供了庞大的软件库。宏观点说，这些库都很相似：有针对手机功能、网络访问功能、包括强大的WebView在内的View对象的API。绝大部分工作都是由控制器完成：iOS的ViewController差不多就相当于一个Android Activity。
iOS有而Android没有的是一套额外的框架和功能，比如Android就没有iOS强大的Core Data框架的对应物，也没有iOS更整洁、更好的设计系统。举个例子，将这两个做了应用大部分工作的相对简单的iOS类与这三个对应的Android类进行比较。最后我在Android类上花的时间要比在iOS类上花的时间多。
另一项指标（虽然有瑕疵）：代码行数。这两款应功能近乎一样，但iOS应用的自定义代码有1596行，包括头文件；而Android应用的Java代码和XML代码加起来有2109行，多了32%多。
网络
如今大部分应用都使用互联网API，而不是单独的程序；这点已经足够重要，值得拿出来单说。iOS和Android都为此提供了全套工具和API。它们都提供了非常相似的WebView（网络视图），即便上就是功能齐全的浏览器，开发者可以在应用中任何地方插入。
网络连接基本上都是在后台运行，以便不堵塞主线程，而多线程又很难。Android提供AsyncTask类来做这类事，虽然很啰嗦，但效果很好，而且判断是否联网也很方便。iOS也提供相应的功能，但它们的表现相当低级，不能让人满意。
不过，有一堆开源库让生活变得轻松多了。我用的是AFNetworking，使用起来感觉非常好。你只需在网络请求完成后将代码块传递给它就能运行，这在Android中根本不可能，因为Java并没有block。
优势：原生Android有优势，但考虑到第三方库时iOS有优势。
分享
从应用中分享东西到Facebook、Twitter、Evernote等服务上有多容易？我曾经以为这是Android的首次完胜。长期以来，Android就有一个名为Intents的强大的应用间通讯系统。大体上来说，Android在让应用间请求并分享数据上要好很多。
而在（有点遗憾）更广泛意义上的分享上，苹果的领先很多。不要光听我说，你可以自行判断。分享Scanvine故事的Android代码在此，iOS代码在此。iOS代码长一些的唯一原因是，我多加了一些Google Analytics追踪代码。
优势：两者都没有。
碎片化
这一问题根本不用花太多时间讨论，答案当然是iOS胜出。值得注意的是，Google正进行一项有趣的去碎片化战略，也许这一点很快就可以重新探讨了。
发布
发布一款Android应用非常容易。只需要用一个方便的Eclipse向导来签名应用，你就会得到一个可以在任何设备上运行的APK文件。用电子邮件发送它，放到网站上，上传到Google Play中，就能在一小时内（有可能）向全世界提供。不能再简单一些了。在空余时间检查安装数据和崩溃报告，包括识别出问题的代码行的堆栈踪迹，并能立即上传修复错误的版本。
发布一款苹果应用则是噩梦。我的一位聪明的朋友总是会建议别人留出至少一天的iOS开发时间来解决证书和发行档案问题。不管我做了多少次，不管最新版XCode试图让这一过程变得多容易，这一直都是个很大的困扰。如果没有TestFlight，测试甚至会更糟糕。苹果的“iTunes Connect”网站比起Google Play开发者终端就像福特之于特斯拉。祝你好运，基本上你收不到苹果应用的崩溃报告，收到了里面也不会有什么有用的信息。你最终也会为强大的苹果UX有多糟糕而感到惊叹。
优势：Android领先很多。
赢家是……
iOS要领先很多。Android有其优势，但总的来说，编写好的iOS应用要比编写好的Android应用容易得多。加上iOS用户要有钱和有影响力得多，大部分想要闯出名头的初创公司还是应该以iOS为先。新的Android Studio IDE也许会极大地缩短差距，但并不是全部。（说明一下，我的主要手机是Nexus 4，用起来很开心。）
|
收藏
淘帖
踩
