Somya Jain 谈从 C#到 Object-C

阅读数:6740 2012 年 8 月 8 日 00:00

几年前掌上电脑很大程度上就是一新奇事物和玩具。但如今,商业界正发生着一场重大变化。许多传统上在 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#中我怀念的:

  1. 泛型
  2. LINQ
  3. 不用创建头文件,将代码置于同一文件中。

给 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 定义就比较相似,比如:

  • 依然有视图结构
  • 当往后台进程导入数据时,依然要小心;并将其整合到主进程中去。
  • 需了解视图生命周期等。

其实我最怀念的是对数据绑定的支持。

关于受访者

Somya Jain谈从C#到Object-CSomya Jain 有着 11 年的企业级软件开发员、技术领导及架构师的经验,他现在住在纽约,是一位移动自由开发者(包括 iOS, Android 以及 Windows Phone)。他主要关注于跨平台移动应用


感谢侯伯薇对本文的审校。

给 InfoQ 中文站投稿或者参与内容翻译工作,请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博( @InfoQ )或者腾讯微博( @InfoQ )关注我们,并与我们的编辑和其他读者朋友交流。

查看英文原文: From C# to Objective-C with Somya Jain

评论

发布