现在很多app和服务器交互，双方收到对方收据，怎么才能完整解析消息，是大家都会遇到的问题。现在来看以下他们的字节长度差异。
iOS
64位编译器，对应64位系统,包含机型（iphone5s—同时运行32位应用和64位应用，iphone6, iphone6 plus, iphone6s, iphone6s plus, iphone7, iphone7 plus）
char ：1个字节（32位的寻址空间是2^32, 即32个bit，也就是4个字节。同理其它编译器）
char*(即指针变量): 8个字节
short int : 2个字节
int： 4个字节
unsigned int : 4个字节
float: 4个字节
double: 8个字节
long: 8个字节
long long: 8个字节
unsigned long: 8个字节
32位编译器，对应32位系统,包含主要机型（iphone4，iphone4s, iphone5），iphone4以下机型苹果商店不需要适配，所以忽略。
char ：1个字节
char*（即指针变量）: 4个字节
short int : 2个字节
int： 4个字节
unsigned int : 4个字节
float: 4个字节
double: 8个字节
long: 4个字节
long long: 8个字节
unsigned long: 4个字节
java编译器。
Byte: 1字节
Short: 2字节
Int: 4 字节
Long: 8字节
Character: 2字节
Float: 4字节
Double: 8字节
c/c++ win32、win64、linux32、linux64中各数据类型占字节数
以前遇到消息id，app定义的为int类型，服务器（java）定义为long类型，结果导致消息解析不一致,修改long long类型才解决。
我遇到过订单id，app定义的为long类型，服务器（java）定义的为long类型，当应用运行在iphone5s（64位系统）手机上正常，当运行在iphone4s（32位系统）时，发现订单不识别，接不了单，后来app修改为long long类型才解决。
遇到过[_orderInfo[@”ID”] longValue] 崩溃后修改为 [_orderInfo[@”ID”] longLongValue]才正常，发现app只要是long,int，bool类型都可以用longLongValue来解析，反过来就不一定行。
国内绝大多少企业为了服务器开发快和具有web前端，都是基于java语言的开发，并且有web展示前端，服务器大多数部署在阿里云上。所以了解下各个编译器在各个操作系统平台上的字节定义很有必要。
基于Java服务器的优点：跨平台容易，基于web开发快，java开发人员多。
基于c++服务器的有限：运行速度比基于java语言开发的服务器快20%（从视频处理上显然的看出），便于底层协议开发，对web的兼容性很差（一般需要中间件嵌入基于java的web页面，c#,.net语言我不了解）。
