Xamarin 到 64 位 iOS/OSX 平台的粗野过渡

当 Xamarin 开始自己的 iOS 项目的时候，设备仅能够在 32 位模式下使用，也就是 32 位版本的 NSInteger 和 CGFloat。当他们开始调查 64 位 OSX 的时候，他们意识到自己对那些数据类型的假设是错误的。 Miguel 继续说：

我们将需要审计我们的所有 API 从而实现合适的类型映射，同时我们将破坏源码的兼容性，使用类似于下面的代码：

复制代码

 
var foo = new Xxx ();
int count = foo.GetRowCount ();
// oops, can not cast a long into an int.

当我们把源码的破坏和 Apple 拥有一个 32 位兼容性故事，同时我们仅有一些遗留类库依赖于 32 位 API 的事实结合起来的时候，我们意识到我们并不急于转移到 64 位的世界。

随着仅能引入 64 位类库的 Mountain Lion 的出现，他们看到了改变这种设计的需要。而 Apple 提供 32 位和 64 位版本的 iPhone 5 的决定进一步加剧了这种局面。为了处理这些新的挑战，Xamarin 已经创建了三个新的数据类型：

• nint
• nuint
• nfloat

这些新的结构被定义为 32 位或者 64 位，依赖于代码编译的目标平台。但是故事的内容远不止如此。原始的数学运算使用特殊的 IL 指令进行操作（例如加法），而用户定义的结构需要调用 op_Addition 方法。

对于性能敏感的代码而言这可能会引发一些小的但是值得注意的影响。因为在使用本地类库的时候这些类型是非常基础的，AOT 编译器会被修改为重新解释使用这些类型的操作。Miguel 继续说：

op_Addition 调用最终会和本地 ECMA CIL add 指令一样。IL 可能看起来很恐怖，但是本地代码也是如此。

一些人可能会想知道为什么 Xamarin 不使用 IntPtr——支持平台特定整数的 CLR 数据类型。Miguel 写道：

我们选择了 nint 和 nuint 而不是内置的 IntPtr 和 UIntPtr，因为前者让人感觉是自然的“原生整型”，而 IntPtr 则是文化相关的，它已经有指针或者一个本地符号。另外，我们并没有等价的本地浮点类型。

我们选择避免使用名称 NSInteger 和 CGFloat 有几个方面的原因：一般情况下功能已经足够，它们可能值得在 Mono 中用于除了 Mac 和 iOS 之外的地方；同时感觉这些是真正的 VM 支持的类型，而不是一些类型定义或者别名。在理想的情况下，这些最终会成为 C#标准的一部分。

查看英文原文： Xamarin’s Rough Transition to 64-bit iOS/OSX