Somya Jain谈从C#到Object-C-InfoQ

几年前掌上电脑很大程度上就是一新奇事物和玩具。但如今，商业界正发生着一场重大变化。许多传统上在 XAML，Flex 或 HTML 上编写应用的商业公司突然发现，iPad 应用有着数目巨大的需求。这些需求不止来自游戏，同时也存在很多标价为几十万甚至上百万的项目。尽管.Net 和 Java 在未来几年依然会活跃于后端平台。但是对于那些愿意尝试的团队，iOS 市场还是有很多机会。

我们与 Somya Jain ，一个致力于此的开发人员，谈论了如何从 C#过度到 Objective-C。

Somya Jain：关于移动编程我学到的第一点是（通过不断实践总结出来的），它与服务器或桌面开发有着很大的不同。移动设备 RAM 空间小，网速慢，屏幕小；尤其 CPU，相对慢。尽管如此，人们却期待移动设备提供更高的用户体验。人们可以很容易地在应用商店将你的应用与其它应用进行对比。如果你的应用还是停留在作坊级，那就很难具有竞争力。

我学习 Objective-C 就是为了编写 iPhone 及 iPad 应用。因为拥有 C++/Java/C#背景，其学习并非那么困难。大部分概念都能简单互通。一开始，我尝试通过遵循书籍和阅读文档来学习，但是，我发现更快的学习方法是真正投入到项目中。

以下几点是理解 Objective-C 的关键。尽管它与 C#有很多相同之处，但依然有细微的差别。

内存管理

首先需要提的就是内存管理。对于 iOS 开发，理解 alloc，release 和 autorelease 是至关重要的。但是随着 ARC 的引进，它们可能会变得不那么重要。尽管 ARC 会在某些地方误导你，但它将帮助你理解其内含的原理。

内存管理问题，比如过度释放内存，将造成令人厌烦的 BAD_ACCESS 崩溃；还有不释放内存，造成的难以解决的内存泄漏。此外，他们对应用的性能和可用性也有很大影响。学会如何快速定位和解决这些问题非常关键，我建议学会如何使用 NSZombies 对象及性能调试工具 Instruments 来调试这些问题。

另外，Objective-C 支持垃圾回收，但它仅支持 mac osx，而不支持 iOS。

InfoQ：添加和释放对象听起来非常像 COM 引用计数，但“自动释放”又是怎么回事呢？

Somya:从根本上，你会使用自动释放返回一个不是由创建对象管理的对象。通过调用自动释放，将该对象添加到自动释放池中，并在清空池时将对象释放。如果接受对象想要使用它，需要保留其值。以下是更多来自 apple 文档的信息：

每个循环的每次轮询开始，应用工具箱都会在主线程中创建一个自动释放池，在并最后将其释放，以释放执行事件时产生的自动释放对象。

InfoQ：什么是 NSZombies？

Somya：NSZombies 可以用来检测之前提到的内存过度释放问题。在自动释放对象上不平衡释放是常见现象。事实上，最终释放时，一切都工作正常，对象也被重新分配了；但是当清空自动释放池时（有的时候随后才发生），应用会因为尝试去自动释放一个已经被释放的对象而崩溃。正因对象本身不存在，所以很难定位出真正问题所在。正是对应上述问题，提出了 NSZombie 对象。通过设置 NSZombieEnabled 标志将任何已释放对象转化为 NSZombie，以取代原始释放操作。这样我们就可以在任意调用 NSZombie 对象释放或自动释放处设置断点，以定位到问题代码路径。

InfoQ：您能解释下什么是 ARC，为什么您觉得它可使内存管理更简单？

Somya：原则上，通过允许使用 ARC，编译器会自动为你保留或释放请求。这意味了我们不必再去担心内存管理了，但是经验告诉我：事实正与之相反。我还没使用过 ARC，所以无法做过多评论。

方法调用 VS 消息

两个语言间另外一个细微差别是：C#中方法调用是静态的，绑定发生在编译时 (暂时忽略动态编译）。Objective-C 消息则在运行时动态绑定对象，而非编译时。这意味着你可以发送任意定义好的消息给对象，编译器都不会报错。错误会在运行时抛出。

有意思的是，其中有一机制：就算消息没有被类执行，也会被截取。这通常发生在多继承，日志和往动态载入代码分配消息等高级方案中。

进程池 VS 中央调度

从高层来说，它们的定义是一样的：一个用于管理进程池的系统。对于该点，我认为 iOS 确实做得很出色。首先，它支持不同优先等级，甚至进程池也赋予我们更优的授权管理。比如我们可以在下载图片时操纵更高等级的进程，以使后台下载不影响我们的 UI。

另一优秀特征是分配组允许同时提交所有任务，但只在全部完成时才通知。

以下概念在 C#和 Objetive-C 中几乎一一对应：

扩展方式（C#）<==> 类别（iOS）
接口（C#）<==> 协议（iOS）
委托（C#）<==> 块（iOS）

C#中我怀念的：

泛型
LINQ
不用创建头文件，将代码置于同一文件中。

给 C#开发者的其它建议：

从 Resharper（C#）开发者那了解 AppCode（Objetive-C）
Xamarin 的 MonoTouch 团队将 C#引入到 iOS 设备中。

InfoQ：对 iOS 开发，您偏向哪种 IDE 呢？

Somya：当然是 AppCode 了，我非常熟悉它所带来的代码自动完成和重构支持，就如同 C# 中使用过的一样。我还喜欢它能够突出显示那些潜在的内存管理问题，对于 iOS 的初学者非常有帮助。一天下来，那大大提高了我的生产力，简直不费吹灰之力。

InfoQ：您说您想念泛型。那 Objective-C 提供类似工具吗，还是必须象.Net1.0 那样必须使用非类型化集合？

Somya：是的，我们使用类似 1.0 中非类型化集合。但是由于动态消息绑定，我们无需停止对象去发送消息。

InfoQ：Objective-C 是否有哪些特征您希望 C#能采纳呢？

Somya：在语言层上应该没什么。我还不曾发现有哪些显著特性让我觉得 C#也应该拥有。但是在 API 层上，我觉得 apple 确实在 iOS 上下了很好的功夫。尽管其 API 看上去有点严格，但是确实设计地很好。比如在 NavigationController 和 UITabBarController 里，通过简单标志就可在视图切换时实现动画效果。而在 android 和 WP7 中，这要消耗很大力气。

InfoQ：如何比较在 iOS 中，和在 WinForms 或 Silverlight 中创建用户界面呢？

Apple 有两个主要 UI 库：UIKit 和 GLKit。GLKit 主要关注基于 OpenGL 的应用和游戏。UIKit 更接近于 WinForms/WPF，它有类似 text boxes 文本框，labels 标签，drop downs 下拉列表等标准控件。这些 UIViews（.Net 中的控件）易拓展成或组合成试图，类似于.Net 中创建自定义控件和用户控件。但是，iOS 只支持固定的基于坐标的布局，所以我们必须明确具体大小及每个视图在其父试图中的位置。其他 UI 定义就比较相似，比如：