C语言中的整型有很多种，到了 Objective-C 中，除了这些类型外，又加入了 NSIntenger 等。
- short
- int
- long
- long long
- NSIntenger
- int8_t
- int16_t
- int32_t
- int64_t
Long
在C语言中有时候我们需要比 int（32bit）范围更大的整型。而 long 的位数是由编译器决定的，大部分C语言的编译器会根据系统的位数来决定 long 的位数，在32位中 long 是32位（LONG_MAX=2147483647），在64位中 long 是64位（LONG_MAX=9223372036854775807）。这种情况下，在32位系统中我们就需要使用 long long int（64bit），而在64位系统中则应该使用 long int（64bit）。这对程序员来说是个很棘手的问题，我们不可能根据系统位数来决定使用哪种类型。这时就应该使用固定位数的 int8_t、int16_t、int32_t、int64_t。他们的范围分别对应8bit、16bit、32bit、64bit。所以，如果想要在多种平台上都获得较大的位数，则应该使用 int64_t。
NSIntenger
NSIntenger 是 Objective-C 中新的整型数，在 iOS 开发中我们也习惯使用 NSIntenger。他的源代码如下。
#if __LP64__ || (TARGET_OS_EMBEDDED && !TARGET_OS_IPHONE) || TARGET_OS_WIN32 || NS_BUILD_32_LIKE_64
typedef long NSInteger;
typedef unsigned long NSUInteger;
#else
typedef int NSInteger;
typedef unsigned int NSUInteger;
#endif
可以发现，NSIntenger 与 long 的特性相似，位数都是根据系统位数来确定。但是唯一的差距是，NSIntenger 是通过预编译来确定 NSIntenger 是重定义 int 还是 long，这在 Cocoa 的控制之下。NSInteger 的存在的原因是因为许多遗留的 API 使用不当。在 iOS 没有64位系统之前，如果 API 用 int 来持有有效的指针，由于指针的位数是与系统位数保持一致的。这意味在64位系统中该 API 的不得不从 int 改为 long 才能正确记录所有有效指针（如下代码）。如果使用 NSInteger 则无需考虑这样的问题。根据我谨慎的猜测，long 的位数与系统位数保持一致，也应该是由于这样的原因。但是相对于 NSIntenger 这种通过预编译来控制的方式，long 对于苹果来说明显更加不可控。
隐患
知道了上述这些差异后，就来举两个例子说明不了解这些差异可能带来的隐患。
用 int 储存指针地址
- (NSUInteger)hash {
long v1 = (long)((void *)_selector);
long v2 = (long)_target;
return v1 ^ v2;
}
这是 YYKit 中的一段代码。这里如果使用 int 去储存函数指针地址，在64位的系统中则会有一半的地址因为越界变成 INT_MAX。
格式化 NSInteger
当我们打印或格式化 NSInteger 时可能会时而遇到这样的警告，时而又不会。
NSInteger test;
NSLog(@"%d", test);
这是因为，当我们用32位的手机（iPhone5s 以下）调试的时候，NSIntenger 其实就是int，所以没有警告。当我们拔掉数据线时，Xcode 会默认选中“Generic iOS Device”，而“Generic iOS Device”模拟的是64位的真机，这时 NSIntenger 就是 long，所以才会出现警告。当我们切换模拟器时也会出现这样的情况。这就是为什么这样的警告时而出现时而消失的原因。
占用空间
通过如下代码对各种整型的占用的大小进行打印。
short _short = 0;
int _int = 0;
long _long = 0;
long long _long_long = 0;
NSInteger _NSIntenger = 0;
int8_t _int8_t = 0;
int16_t _int16_t = 0;
int32_t _int32_t = 0;
int64_t _int64_t = 0;
NSLog(@"\nshort:%lu\n"
"int:%lu\n"
"long:%lu\n"
"long long:%lu\n"
"NSInteger:%lu\n"
"int8_t:%lu\n"
"int16_t:%lu\n"
"int32_t:%lu\n"
"int64_t:%lu\n",
sizeof(_short),
sizeof(_int),
sizeof(_long),
sizeof(_long_long),
sizeof(_NSIntenger),
sizeof(_int8_t),
sizeof(_int16_t),
sizeof(_int32_t),
sizeof(_int64_t));
打印出来的结果如下：
64bit
short:2
int:4
long:8
long long:8
NSInteger:8
int8_t:1
int16_t:2
int32_t:4
int64_t:8
32bit
short:2
int:4
long:4
long long:8
NSInteger:4
int8_t:1
int16_t:2
int32_t:4
int64_t:8
根据打印信息我们发现 short、int 和 long long 不管在32位还是64位系统中他们的大小都是固定的。查看代码发现，其实 int16_t、int32_t、int64_t 就是简单的重定义了 short、int、long long 而已。
更多
除了这些之外，Objective-C 中还重定义了大量类似的整数类型。
typedef unsigned char UInt8;
typedef signed char SInt8;
typedef unsigned short UInt16;
typedef signed short SInt16;
#if __LP64__
typedef unsigned int UInt32;
typedef signed int SInt32;
#else
typedef unsigned long UInt32;
typedef signed long SInt32;
#endif
UInt8、SInt8、UInt16、SInt16、UInt32、SInt32 分别对应 uint8_t、int8_t、uint16_t、int16_t、NSInteger、NSUInteger。前四种相对后四种来说使用驼峰命名法，更符合Objective-C的风格。他们均在 Core Framework 中大量使用。
使用
在 iOS 开发中我们习惯使用 NSIntenger，因为 Cocoa 的 API 返回的数据类型大多是 NSIntenger。而且，如果将来 iPhone 推出了新的系统架构，NSIntenger 也可以保证你老项目中任何奇怪的代码都不会出现隐患。对于几种简单的场景，可以按照如下这样使用。
- 在简单的循环中建议使用int。
- 成员/静态/全局变量建议使用NSIntenger。
- 对较大范围有强制要求时可以使用int64_t。
- 储存颜色可以使用uint8_t。
除此之外，整型数还有很多种类型，他们都是根据C语言的基础数据类型进行重定义。使用时可以根据代码找到最终的数据类型和可能存在宏判断结合 short、int、long、long long 在32位和64位系统下大小的区别来推断他们等价的类型。
博客：xuyafei.cn
简书：jianshu.com/users/2555924d8c6e
微博：weibo.com/xuyafei86
Github：github.com/xiaofei86
参考资料
- [StackOverflow] Definition of int64_t
- [StackOverflow] How should I declare a long in Objective-C? Is NSInteger appropriate?
- [StackOverflow] What is Generic iOS Device in Xcode 7.1 run destinations list?
- [StackOverflow] In Cocoa do you prefer NSInteger or int, and why?
- [StackOverflow] When to use NSInteger vs. int
