那座都市里，是几代中国先生的痛点

不爱逛街是男人的个性。

前言

• 本文会用实例的不二法门，将iOS种种IM的方案都简短的贯彻三回。并且提供部分选型、达成细节以及优化的提出。

• 注：文中的装有的代码示例，在github中都有demo：
  iOS即时通讯，从入门到“遗弃”？(demo)
  可以打开项目先预览效果，对照着开展阅读。

活到一定的年龄、逐步的就会精晓，有些路，只能够一个人走。这么些早已的天长地久，邀约执手同行的人，相伴花季，走过了似水年华，然则终有一天，会在某个伶仃的渡口，悄然离散。红尘陌上，独自行动，清风拂过发梢，在耳畔窃窃私语，露水打湿了诺言。青山和绿水可以两两相望，日与月却是此起彼伏，毫无瓜葛，所谓的日月同辉，只是在某一个时光肉眼所及的浮象奇观，传说一块看到日月同辉的朋友，都会毕生相守。但是，当心思走到了无尽的时候，却只落得一个人的浮世清欢，一个人的落寞孤寂。

找不到一套合身半袖，是几代中国先生的痛点，却无计可施。

言归正传，首先大家来总计一下我们去贯彻IM的章程

都说人生苦短，世事难料。我们常常在如水的光景里迷失了投机，庸庸碌碌的起居，不知所以，在逝去的生活里若隐若现着，而凡尘缭绕的烟火，又三番两回让您自我对世俗的眼神心有余悸，不敢自由的深呼吸，以至于到终极变得蓦然无语，逐步的疏离，各奔东西，再无交集。千帆过尽，烟雨浮生，回首往昔若梦，那一份纯净的大费周章，早已南辕北辙，近来光阴留下的，只是满目荒凉，落寞成殇。

可就有那样多少个老公，在O2O概念如火如荼的二〇一四年，各自辞去原本优渥的营业所中高层职位，创立了一家羽绒服私人定制公司，发誓要化解那一个不爱逛街的中华先生的洋装梦想。他们中有做咨询的，有做媒体的，有做资本运作的，有做市场营销的，甚至有做航天的，可就算从未一个是衣物那么些行当出身的。

首先种方法，使用第三方IM服务

对于连忙的营业所，完全能够应用第三方SDK来兑现。国内IM的第三方服务商有很多，类似云信、环信、融云、LeanCloud，当然还有任何的很多，那里就不一一举例了，感兴趣的伴儿可以自行查阅下。

• 其三方服务商IM底层协议基本上都是TCP。他们的IM方案很成熟，有了它们，我们仍然不必要协调去搭建IM后台，什么都不须求去考虑。
  假设你丰裕懒，甚至连UI都不须要自己做，这几个第三方有各自一套IM的UI，拿来就足以从来用。真可谓3分钟集成…
• 唯独缺点也很明朗，定制化程度太高，很多东西大家不可控。自然还有一个最最要害的一些，就是太贵了…用作真正社交为主打的APP，仅此一点，就可以让大家害怕。当然，即使IM对于APP只是一个辅助功效，那么用第三方服务也无可厚非。

有人说，爱上一座城，是因为城中住着某个喜欢的人。或许有些道理，我爱不释手在这座城里徘徊，久久的可怜离开，我这么的执着，也许就是为了城里住着老大曾经让自己慕名的你，我想留住那一块靓丽的景象。为了那一段青梅往事，我祈盼你那熟稔的人影，再一回从我的窗前走过。或许，我留守在那座孤城里，不为卿卿我自家，不为相伴终老，仅仅为的只是可以多看你一眼。爱上一个人，有时候不必要任何理由，没有前因，毫无干系风月，只是爱上了就够用了。

依照常规的O2O打法，接下去该起来忙着各路路演，讲故事，玩概念，画大饼，寻求天使投资人的珍惜。

别的一种办法，大家和好去贯彻

咱俩自己去已毕也有比比皆是挑选：
1）首先面临的就是传输协议的挑选，TCP还是UDP？
2）其次是大家须求去挑选采纳哪个种类聊天协议：

• 基于Scoket或者WebScoket仍旧其它的民用协议、
• MQTT
• 或者广为人诟病的XMPP?

3）大家是祥和去基于OS底层Socket拓展包装依旧在第三方框架的功底上举办打包？
4）传输数据的格式，我们是用Json、还是XML、如故谷歌（谷歌）生产的ProtocolBuffer？
5）大家还有一部分细节问题需要考虑，例如TCP的长连接如何保证，心跳机制，Qos机制，重连机制等等…当然，除此之外，大家还有部分三门峡题材亟待考虑。

都说“择一座城终老，遇一个人白首”。每个人都是带着和谐的希望，来到一座都市。无论她多么的平庸渺小，多么的无所谓，那座城市里，总会有一个角落将他容纳，搁置，总有一个人与她萍水相逢，相知相恋。在属于自己的狭窄世界里生活着，守着不难的安稳与甜蜜，不惊不扰地渡过毕生。每个人都想在混乱的猥琐中，以昂扬的神态示人，尽情地演绎一段自己的悲喜人生。可是，那只是说话的美观，华丽转身不是错事，不难的活着也绝不不是无微不至。碰着总是留给有预备的人，大家真正是一无所求。

这个老公不这么玩。他们花了整整一年岁月修炼内功，淌过O2O大饼里的那一个坑，在二零一五年终得到了数千万融资。其中的一位投资人叫刘薇，是中国职业装设计大拿，曾问鼎中国衣裳设计最高奖“金顶奖”。

一、传输协议的选用

接下去我们恐怕须要自己考虑去得以完成IM，首先从传输层协议以来，大家有二种拔取：TCP
or UDP？

其一题材早已被谈论过很数十次了，对深层次的细节感兴趣的爱人可以看看那篇作品：

• 运动端IM/推送系统的协议选型：UDP依然TCP？

那里大家直接说结论吧：对于小集团照旧技术不那么成熟的商号，IM一定要用TCP来促成，因为假使你要用UDP的话，需求做的事太多。当然QQ就是用的UDP磋商，当然不仅仅是UDP，腾讯还用了和谐的个体协议，来保管了传输的可相信性，杜绝了UDP下种种数据丢包，乱序等等一体系题材。
总的说来一句话，假如您认为团队技术很成熟，那么你用UDP也行，否则依然用TCP为好。

各类人都清楚大地没有不散的酒宴，可依然言辞凿凿地应承相伴永远。我不知道，永远到底有多少距离，有微微人说过那句话，又有些许人问过那句话。或许，那人间原本就是一个无解的问题，根本未曾什么样是永久。我早已天各一方来到那座都市，只为了赶赴一场无字天书般的城下盟约，在古老的巷陌里，聆听着时令的天气，我对着历史斑驳的城墙，许下毕生的誓词，与你同行，共度今天，一辈子不离不弃，永生永世。或许她们都说对了，也可能都说错了，终有一天你也会冷不丁离去，再遇上已成隔世。

她俩在这一年里到底做了何等，可以让他们同时取得资本与专业人员的再次垂青？

二、大家来看看种种聊天协议

率先大家以落到实处形式来切入，基本上有以下四种达成形式：

1. 基于Scoket原生：代表框架 CocoaAsyncSocket。
2. 基于WebScoket：代表框架 SocketRocket。
3. 基于MQTT：代表框架 MQTTKit。
4. 基于XMPP：代表框架 XMPPFramework。

自然，以上四种艺术大家都足以不利用第三方框架，直接基于OS底层Scoket去落到实处我们的自定义封装。上面我会交到一个依照Scoket原生而不利用框架的例证，供大家参考一下。

率先须求搞掌握的是，其中MQTT和XMPP为聊天协议，它们是最上层的情商，而WebScoket是传输通讯协议，它是依照Socket打包的一个探究。而普通我们所说的腾讯IM的私房协议，就是基于WebScoket或者Scoket原生举行打包的一个闲话协议。

具体这3种聊天协议的比较优劣如下：

情商优劣相比较.png

故而究竟，iOS要做一个的确的IM产品，一般都是基于Scoket或者WebScoket等，再之上加上有些私有协议来有限支持的。

诸多个人在岁月的蹉跎里走散了，我快速地跟在时刻背后，追逐着您的阴影。执着的念着来往的光景，很多时候自己都在想，就那样坚定不移的要追求，为的是什么，等待的又是哪些。或许，是为着圆那一场早已的梦，又可能我在等候一场姹紫嫣红的花事。我做梦都想在那座旧城里，和欣赏的人一起，守着一段冷暖交织的生活，逐步地变老。或许，你在自我的社会风气里只是停留了一阵子，转身即是天涯。有缘的人，无论相隔千万之遥，终汇集在一起，携手红尘。无缘的人，纵是朝发夕至，也类似陌路，无份相逢。大运似水，时光太过匆匆，一些事来不及真正开首，就早已被写成了前几天，一些人还一贯不良好的对视，转眸间就成了过客。

1.大家先不利用其他框架，直接用OS底层Socket来促成一个简便的IM。

大家客户端的完结思路也是很不难，成立Socket，和服务器的Socket对接上，然后开首传输数据就可以了。

• 俺们学过c/c++或者java这么些语言，我们就知晓，往往任何学科，最后一章都是讲Socket编程，而Socket是怎么吧，不难的来说，就是我们采纳TCP/IP
  或者UDP/IP协商的一组编程接口。如下图所示：

俺们在应用层，使用socket，轻易的兑现了经过之间的通信（跨网络的）。想想，假诺没有socket，我们要面对TCP/IP商事，大家须要去写多少繁琐而又再度的代码。

借使有对socket概念依旧具有质疑的，能够看看那篇小说：
从问题看本质，socket到底是怎样？。
不过那篇小说关于并发连接数的认识是漏洞百出的，正确的认识可以看看那篇文章:
单台服务器并发TCP连接数到底可以有稍许

俺们随后可以开头出手去得以已毕IM了，首先大家不依照其余框架，直接去调用OS底层-基于C的BSD Socket去落到实处，它提供了如此一组接口：

//socket 创建并初始化 socket，返回该 socket 的文件描述符，如果描述符为 -1 表示创建失败。
int socket(int addressFamily, int type,int protocol)
//关闭socket连接
int close(int socketFileDescriptor)
//将 socket 与特定主机地址与端口号绑定，成功绑定返回0，失败返回 -1。
int bind(int socketFileDescriptor,sockaddr *addressToBind,int addressStructLength)
//接受客户端连接请求并将客户端的网络地址信息保存到 clientAddress 中。
int accept(int socketFileDescriptor,sockaddr *clientAddress, int clientAddressStructLength)
//客户端向特定网络地址的服务器发送连接请求，连接成功返回0，失败返回 -1。
int connect(int socketFileDescriptor,sockaddr *serverAddress, int serverAddressLength)
//使用 DNS 查找特定主机名字对应的 IP 地址。如果找不到对应的 IP 地址则返回 NULL。
hostent* gethostbyname(char *hostname)
//通过 socket 发送数据，发送成功返回成功发送的字节数，否则返回 -1。
int send(int socketFileDescriptor, char *buffer, int bufferLength, int flags)
//从 socket 中读取数据，读取成功返回成功读取的字节数，否则返回 -1。
int receive(int socketFileDescriptor,char *buffer, int bufferLength, int flags)
//通过UDP socket 发送数据到特定的网络地址，发送成功返回成功发送的字节数，否则返回 -1。
int sendto(int socketFileDescriptor,char *buffer, int bufferLength, int flags, sockaddr *destinationAddress, int destinationAddressLength)
//从UDP socket 中读取数据，并保存发送者的网络地址信息，读取成功返回成功读取的字节数，否则返回 -1 。
int recvfrom(int socketFileDescriptor,char *buffer, int bufferLength, int flags, sockaddr *fromAddress, int *fromAddressLength)

让我们得以对socket实行种种操作，首先大家来用它写个客户端。统计一下，简单的IM客户端须求做如下4件事：

1. 客户端调用 socket(…) 成立socket；
2. 客户端调用 connect(…) 向服务器发起连接请求以创建连接；
3. 客户端与服务器建立连接之后，就可以通过send(…)/receive(…)向客户端发送或从客户端接收数据；
4. 客户端调用 close 关闭 socket；

依据下面4条大纲，大家封装了一个名为TYHSocketManager的单例，来对socket连带措施开展调用:

TYHSocketManager.h

#import <Foundation/Foundation.h>

@interface TYHSocketManager : NSObject
+ (instancetype)share;
- (void)connect;
- (void)disConnect;
- (void)sendMsg:(NSString *)msg;
@end

TYHSocketManager.m

#import "TYHSocketManager.h"

#import <sys/types.h>
#import <sys/socket.h>
#import <netinet/in.h>
#import <arpa/inet.h>

@interface TYHSocketManager()

@property (nonatomic,assign)int clientScoket;

@end

@implementation TYHSocketManager

+ (instancetype)share
{
    static dispatch_once_t onceToken;
    static TYHSocketManager *instance = nil;
    dispatch_once(&onceToken, ^{
        instance = [[self alloc]init];
        [instance initScoket];
        [instance pullMsg];
    });
    return instance;
}

- (void)initScoket
{
    //每次连接前，先断开连接
    if (_clientScoket != 0) {
        [self disConnect];
        _clientScoket = 0;
    }

    //创建客户端socket
    _clientScoket = CreateClinetSocket();

    //服务器Ip
    const char * server_ip="127.0.0.1";
    //服务器端口
    short server_port=6969;
    //等于0说明连接失败
    if (ConnectionToServer(_clientScoket,server_ip, server_port)==0) {
        printf("Connect to server error\n");
        return ;
    }
    //走到这说明连接成功
    printf("Connect to server ok\n");
}

static int CreateClinetSocket()
{
    int ClinetSocket = 0;
    //创建一个socket,返回值为Int。（注scoket其实就是Int类型）
    //第一个参数addressFamily IPv4(AF_INET) 或 IPv6(AF_INET6)。
    //第二个参数 type 表示 socket 的类型，通常是流stream(SOCK_STREAM) 或数据报文datagram(SOCK_DGRAM)
    //第三个参数 protocol 参数通常设置为0，以便让系统自动为选择我们合适的协议，对于 stream socket 来说会是 TCP 协议(IPPROTO_TCP)，而对于 datagram来说会是 UDP 协议(IPPROTO_UDP)。
    ClinetSocket = socket(AF_INET, SOCK_STREAM, 0);
    return ClinetSocket;
}
static int ConnectionToServer(int client_socket,const char * server_ip,unsigned short port)
{

    //生成一个sockaddr_in类型结构体
    struct sockaddr_in sAddr={0};
    sAddr.sin_len=sizeof(sAddr);
    //设置IPv4
    sAddr.sin_family=AF_INET;

    //inet_aton是一个改进的方法来将一个字符串IP地址转换为一个32位的网络序列IP地址
    //如果这个函数成功，函数的返回值非零，如果输入地址不正确则会返回零。
    inet_aton(server_ip, &sAddr.sin_addr);

    //htons是将整型变量从主机字节顺序转变成网络字节顺序，赋值端口号
    sAddr.sin_port=htons(port);

    //用scoket和服务端地址，发起连接。
    //客户端向特定网络地址的服务器发送连接请求，连接成功返回0，失败返回 -1。
    //注意：该接口调用会阻塞当前线程，直到服务器返回。
    if (connect(client_socket, (struct sockaddr *)&sAddr, sizeof(sAddr))==0) {
        return client_socket;
    }
    return 0;
}

#pragma mark - 新线程来接收消息

- (void)pullMsg
{
    NSThread *thread = [[NSThread alloc]initWithTarget:self selector:@selector(recieveAction) object:nil];
    [thread start];
}

#pragma mark - 对外逻辑

- (void)connect
{
    [self initScoket];
}
- (void)disConnect
{
    //关闭连接
    close(self.clientScoket);
}

//发送消息
- (void)sendMsg:(NSString *)msg
{

    const char *send_Message = [msg UTF8String];
    send(self.clientScoket,send_Message,strlen(send_Message)+1,0);

}

//收取服务端发送的消息
- (void)recieveAction{
    while (1) {
        char recv_Message[1024] = {0};
        recv(self.clientScoket, recv_Message, sizeof(recv_Message), 0);
        printf("%s\n",recv_Message);
    }
}

如上所示:

• 我们调用了initScoket方法，利用CreateClinetSocket方法了一个scoket，就是就是调用了socket函数：

ClinetSocket = socket(AF_INET, SOCK_STREAM, 0);

• 下一场调用了ConnectionToServer函数与服务器连接，IP地址为127.0.0.1也就是本机localhost和端口6969接踵而来。在该函数中，大家绑定了一个sockaddr_in项目标结构体，该结构体内容如下：

struct sockaddr_in {
    __uint8_t   sin_len;
    sa_family_t sin_family;
    in_port_t   sin_port;
    struct  in_addr sin_addr;
    char        sin_zero[8];
};

其中包蕴了一些，我们需求一而再的服务端的scoket的部分基本参数，具体赋值细节可以见注释。

• 连日来成功之后，咱们就足以调用send函数和recv函数进行消息收发了，在此地，我新开发了一个常驻线程，在那个线程中一个死循环里去不停的调用recv函数，这样服务端有音信发送过来，第一时间便能被接到到。

就那样客户端便简单的可以用了，接着大家来探视服务端的得以完毕。

人人屡次三番感慨人生如戏，戏如人生，其实各种人的一世，都在演绎一幕又一幕的独角戏，每个人都在人生的舞台上扮演着自己的角色。或真或假、或长或短、或喜或悲。你想在本场戏中扮演不一致的角色，演绎炫彩的人生，就要提交高昂的代价，没有人去关怀你的台词，人们都沉浸在祥和的角色里，各自微笑，各自流泪。一场戏的为止，意味着另一场戏的发轫，所以我们无需过度沉浸在今天的回忆里。你记住了同意，你忘掉了也罢，生命本是一场巡回，来来去去，何曾有过丝毫的告一段落。在时光面前，大家都是何足挂齿的。当您觉得无能为力的时候，莫如将全部交付给时间，把该忘记的都遗忘了，心神不定地从一个故事走进另一个故事里。

拉链互动，官网定位为“专注于男士个性化消费的O2O互联网平台”，主要产品是西服定制。

一如既往，大家第一对服务端必要做的干活大概的下结论下：

1. 服务器调用 socket(…) 创立socket；
2. 服务器调用 listen(…) 设置缓冲区；
3. 服务器通过 accept(…)接受客户端请求建立连接；
4. 服务器与客户端建立连接之后，就可以通过
   send(…)/receive(…)向客户端发送或从客户端接收数据；
5. 服务器调用 close 关闭 socket；

人们总是在一身伤心的时候，会无法抑制地想念那几个逝去的时段。或许因为我们都太过凡庸了，经不起平淡小运日复一日的熬煮。站在离其余渡口，想着那么些决然离开，再不回头的人。将泛黄了的年轻书册，翻出来一次又两遍阅读。我不想祈求生命的宏观，或许缺憾的人生也是一种赏心悦目，太过完满人生反而会变得没意思。人的毕生总会有举不胜举次偶遇相逢，总是要经历生离死别，转身即是永远，从此后会无期，永不相见。

拉链互动老总吴巍对健一会说，取名“拉链互动”，是在向“拉链”这些当代衣裳产业发展史的里程碑式发明致敬，他盼望用运动互联技术和新的商业情势，去救助所有行业落成转型升级，犹如当年的拉链发明一样。

紧接着大家就可以切实去贯彻了

OS底层的函数是永葆大家去落实服务端的，可是大家一般不会用iOS去那样做（试问真正的选用场景，有什么人用iOS做scoket服务器么…），即便依旧想用这个函数去得以完结服务端，可以参考下这篇作品：
长远浅出Cocoa-iOS网络编程之Socket。

在此间自己用node.js去搭了一个简单的scoket服务器。源码如下：

var net = require('net');  
var HOST = '127.0.0.1';  
var PORT = 6969;  

// 创建一个TCP服务器实例，调用listen函数开始监听指定端口  
// 传入net.createServer()的回调函数将作为”connection“事件的处理函数  
// 在每一个“connection”事件中，该回调函数接收到的socket对象是唯一的  
net.createServer(function(sock) {  

    // 我们获得一个连接 - 该连接自动关联一个socket对象  
    console.log('CONNECTED: ' +  
        sock.remoteAddress + ':' + sock.remotePort);  
        sock.write('服务端发出：连接成功');  

    // 为这个socket实例添加一个"data"事件处理函数  
    sock.on('data', function(data) {  
        console.log('DATA ' + sock.remoteAddress + ': ' + data);  
        // 回发该数据，客户端将收到来自服务端的数据  
        sock.write('You said "' + data + '"');  
    });  
    // 为这个socket实例添加一个"close"事件处理函数  
    sock.on('close', function(data) {  
        console.log('CLOSED: ' +  
        sock.remoteAddress + ' ' + sock.remotePort);  
    });  

}).listen(PORT, HOST);  

console.log('Server listening on ' + HOST +':'+ PORT);  

看到那不懂node.js的意中人也不用着急，在这边你可以接纳任意语言c/c++/java/oc等等去贯彻后台，那里node.js但是是楼主的一个拔取，为了让大家来说明以前写的客户端scoket的意义。如若您不懂node.js也没提到，你只需要把上述楼主写的相干代码复制粘贴，若是您本机有node的解释器，那么直接在顶峰进入该源代码文件目录中输入：

node fileName

即可运行该脚本（fileName为保存源代码的文书名）。

咱俩来看看运行效果：

handle2.gif

服务器运行起来了，并且监听着6969端口。
随之大家用事先写的iOS端的例子。客户端打印显示一连成功，而我辈运行的服务器也打印了连年成功。接着我们发了一条新闻，服务端成功的接收到了音讯后，把该音信再发送回客户端，绕了一圈客户端又收取了那条信息。至此咱们用OS底层scoket得以完结了简要的IM。

世家收看那是不是认为太过简短了？
当然简单，大家一味是已毕了Scoket的总是，新闻的出殡与接受，除此之外我们怎么着都未曾做，现实中，大家须求做的处理远不止于此，大家先跟着往下看。接下来，大家就伙同探访第三方框架是哪些促成IM的。

分割图.png

稍许人只一眼，就会过目不忘，在你的心尖生根发芽，那是一种无法诠释，没有根由的感觉到。任时光荏苒，岁月沧桑，也无法改变你在我心中初时的形容。遇见你，是本人平生中最奢侈的事，离开你是我终身中最大的遗憾，由不得你我去舍弃安心乐意。人常说，带走了行囊，就是过客，你带入了有着的整套，也带走了自家的心。其实各类人都明白，人生没有相对的一世情缘，携一颗从容淡泊的心，笑看缘聚缘散，风起尘落的人间。

花一年投入数百万改造供应链，破解衣裳库存老大难

2.我们跟着来探望基于Socket原生的CocoaAsyncSocket:

其一框架完结了三种传输协议TCP和UDP，分别对应GCDAsyncSocket类和GCDAsyncUdpSocket，那里我们器重讲GCDAsyncSocket。

此间Socket服务器两次三番上一个例证，因为同一是根据原生Scoket的框架，所以在此之前的Node.js的服务端，该例如故试用。那里大家就只须要去封装客户端的实例，大家依旧创造一个TYHSocketManager单例。

TYHSocketManager.h

#import <Foundation/Foundation.h>

@interface TYHSocketManager : NSObject

+ (instancetype)share;

- (BOOL)connect;
- (void)disConnect;

- (void)sendMsg:(NSString *)msg;
- (void)pullTheMsg;
@end

TYHSocketManager.m

#import "TYHSocketManager.h"
#import "GCDAsyncSocket.h" // for TCP

static  NSString * Khost = @"127.0.0.1";
static const uint16_t Kport = 6969;

@interface TYHSocketManager()<GCDAsyncSocketDelegate>
{
    GCDAsyncSocket *gcdSocket;
}

@end

@implementation TYHSocketManager

+ (instancetype)share
{
    static dispatch_once_t onceToken;
    static TYHSocketManager *instance = nil;
    dispatch_once(&onceToken, ^{
        instance = [[self alloc]init];
        [instance initSocket];
    });
    return instance;
}

- (void)initSocket
{
    gcdSocket = [[GCDAsyncSocket alloc] initWithDelegate:self delegateQueue:dispatch_get_main_queue()];

}

#pragma mark - 对外的一些接口

//建立连接
- (BOOL)connect
{
    return  [gcdSocket connectToHost:Khost onPort:Kport error:nil];
}

//断开连接
- (void)disConnect
{
    [gcdSocket disconnect];
}


//发送消息
- (void)sendMsg:(NSString *)msg

{
    NSData *data  = [msg dataUsingEncoding:NSUTF8StringEncoding];
    //第二个参数，请求超时时间
    [gcdSocket writeData:data withTimeout:-1 tag:110];

}

//监听最新的消息
- (void)pullTheMsg
{
    //监听读数据的代理  -1永远监听，不超时，但是只收一次消息，
    //所以每次接受到消息还得调用一次
    [gcdSocket readDataWithTimeout:-1 tag:110];

}

#pragma mark - GCDAsyncSocketDelegate
//连接成功调用
- (void)socket:(GCDAsyncSocket *)sock didConnectToHost:(NSString *)host port:(uint16_t)port
{
    NSLog(@"连接成功,host:%@,port:%d",host,port);

    [self pullTheMsg];

    //心跳写在这...
}

//断开连接的时候调用
- (void)socketDidDisconnect:(GCDAsyncSocket *)sock withError:(nullable NSError *)err
{
    NSLog(@"断开连接,host:%@,port:%d",sock.localHost,sock.localPort);

    //断线重连写在这...

}

//写成功的回调
- (void)socket:(GCDAsyncSocket*)sock didWriteDataWithTag:(long)tag
{
//    NSLog(@"写的回调,tag:%ld",tag);
}

//收到消息的回调
- (void)socket:(GCDAsyncSocket *)sock didReadData:(NSData *)data withTag:(long)tag
{

    NSString *msg = [[NSString alloc]initWithData:data encoding:NSUTF8StringEncoding];
    NSLog(@"收到消息：%@",msg);

    [self pullTheMsg];
}

//分段去获取消息的回调
//- (void)socket:(GCDAsyncSocket *)sock didReadPartialDataOfLength:(NSUInteger)partialLength tag:(long)tag
//{
//    
//    NSLog(@"读的回调,length:%ld,tag:%ld",partialLength,tag);
//
//}

//为上一次设置的读取数据代理续时 (如果设置超时为-1，则永远不会调用到)
//-(NSTimeInterval)socket:(GCDAsyncSocket *)sock shouldTimeoutReadWithTag:(long)tag elapsed:(NSTimeInterval)elapsed bytesDone:(NSUInteger)length
//{
//    NSLog(@"来延时，tag:%ld,elapsed:%f,length:%ld",tag,elapsed,length);
//    return 10;
//}

@end

那几个框架使用起来也很是简练，它依照Scoket往上展开了一层封装，提供了OC的接口给大家运用。至于使用办法，我们看看注释应该就能领略，这里唯一须要说的一些就是其一格局：

[gcdSocket readDataWithTimeout:-1 tag:110];

以此办法的作用就是去读取当前新闻队列中的未读音信。牢记，那里不调用这么些格局，信息回调的代理是永恒不会被触发的。同时必须是tag相同，即便tag分歧，这么些收到音讯的代办也不会被处分。
我们调用几回那一个办法，只好触发一遍读取音讯的代理，如果大家调用的时候没有未读信息，它就会等在那，直到信息来了被触发。一旦被触发两遍代理后，大家不可能不再度调用那个格局，否则，之后的音信到了照旧不能够接触大家读取新闻的代办。就好像我们在例子中应用的那么，在每一次读取到新闻之后大家都去调用:

//收到消息的回调
- (void)socket:(GCDAsyncSocket *)sock didReadData:(NSData *)data withTag:(long)tag
{
    NSString *msg = [[NSString alloc]initWithData:data encoding:NSUTF8StringEncoding];
    NSLog(@"收到消息：%@",msg);
    [self pullTheMsg];
}
//监听最新的消息
- (void)pullTheMsg
{
    //监听读数据的代理，只能监听10秒，10秒过后调用代理方法  -1永远监听，不超时，但是只收一次消息，
    //所以每次接受到消息还得调用一次
    [gcdSocket readDataWithTimeout:-1 tag:110];

}

除此之外，大家还需求说的是那几个超时timeout
此间倘诺设置10秒，那么就只可以监听10秒，10秒未来调用是否续时的代办方法:

-(NSTimeInterval)socket:(GCDAsyncSocket *)sock shouldTimeoutReadWithTag:(long)tag elapsed:(NSTimeInterval)elapsed bytesDone:(NSUInteger)length

要是大家选拔不续时，那么10秒到了还没接过音信，那么Scoket会自行断开连接。看到此间有些小伙伴要吐槽了，怎么一个艺术设计的这么麻烦，当然那里如此设计是有它的运用场景的，我们前边再来细讲。

在自身的心头，有一道难以收拾的内伤，不擅自对人发泄，而协调也不敢轻易碰触。我把它掩藏在心尖最深的犄角，用时间的尘埃覆盖起来，以为那样，有一天伤口会趁着时光一去不返。也许的确这么，时间是全世界最好的良药，它可以痊愈你的伤口，让曾经深入的恋爱也变得模糊不清。人生最大的伤痛，莫过于那一个凿凿有据，伴你百年的人，毫无征兆，悄无声息的离去了。留下了一段美好记念，只在片刻间。留存的一生痛心回忆，却是永远。小运似水，看过的景点或者还能重来，而逝去的人却再也不会回头。任由你千思万想，除了偶尔在你梦中徘徊，其他的时日，都只是接近隔世的记念。

普惠整个行业前边，首先要保险自己在衣物制作这么些水极深的本行里活下来，尤其是在民众的行头定制化必要正在萌芽又尚未大面积养成的时期里。

俺们一致来运转看看效果：

handle3.gif

迄今大家也用CocoaAsyncSocket以此框架完毕了一个概括的IM。

分割图.png

实质上世间本无事，所有的心思，都只是时光撒下的弥天大谎，而我辈却愿意去相信，为一个谎言执迷不悔，甚至追忆生平。固然是将寂寞的栏杆坐断，把殷殷的心思过尽，也误入歧途。的确，你在自家的心底中，是一道不能复制的靓丽风景，许多你自我过去的美好回想，连同方今深远的失痛，平昔交织着绞痛我的心，让自身无能为力释怀。或许，这就是失去你的代价，也是本身不可以不付出的代价，你早已离开了，终究会不再属于本人。我割舍不下那一段心境，万念俱灰。人生往往就是这么，许多事物，失去了才掌握爱戴。

拉链互动首先把手术刀挥向供应链。

3.接着大家继续来看望基于webScoket的IM：

其一例子大家会把心跳，断线重连，以及PingPong机制举行简要的包裹，所以大家先来研商那两个概念：

人生总是聚散无常，逝去的生活不能重来。曾经执著的事，都成了过眼云烟，曾经深爱的人，早已经形同陌生人。很多事亲历过才能深悟，姹紫嫣红的花朵，即便赏心悦目，却也抵不过风霜雪雨，但我们心灵里种植的一株菩提，却是四季常青。或许，人生必要留白，残荷弯月也是一种缺憾的美，心绪原本就不是乞讨可以得来的，所以随便春事荼靡的心理，彼岸花开的相惜，寂寞向晚纪念，都要从容地面对，超脱自己。

观念衣裳业的供应链玩法，是消费者进店，商家帮其量体，随后把消费者的身躯多少以邮件或是快递方式发至工厂，工厂依葫芦画瓢，做出衣裳后再快递给门店，由门店交给顾客。

第一大家来琢磨如何是心跳

简易的来说，心跳就是用来检测TCP连接的两头是不是可用。那又会有人要问了，TCP不是我就自带一个KeepAlive机制吗？
此处大家必要表达的是TCP的KeepAlive机制只可以保障连接的存在，然而并不能够确保客户端以及服务端的可用性.譬如说会有以下一种情形：

某台服务器因为一些原因促成负载超高，CPU
100%，不能响应任何事情请求，但是使用 TCP
探针则照旧可以规定连接情形，那就是第顶尖的一而再活着但工作提供方已死的情事。

本条时候心跳机制就起到作用了：

• 俺们客户端发起心跳Ping（一般都是客户端），若是设置在10秒后假使没有收取回调，那么注解服务器或者客户端某一方出现问题，那时候我们需要积极断开连接。
• 服务端也是平等，会维护一个socket的心跳间隔，当约定小时内，没有收到客户端发来的心跳，大家会清楚该连接已经失效，然后主动断开连接。

参考小说：何以说按照TCP的活动端IM照旧必要心跳保活？

骨子里做过IM的同伴们都了然，我们实在须求心跳机制的来由其实根本是介于国内运营商NAT超时。

固然我自命忘情，也不免会为逝去的生活流泪。即便愿望的最深处，并不奢望你能悔过自新，也不期望您看看自身痛心的规范，我只想祈福籍着你的手，把自己心灵扉页上的执念撕的挫败。我祈祷有朝一日，该忘记的都要忘记。岁月乱云飞渡，或许应当换过另一种形式，另一份心理活着。人生不是拥有的来回都是光明，还有好多大家想要擦去却擦不去的残痕。疼痛的旧闻可以选拔忘记，可纵算忘记了，并不意味着就真的不设有。既是大致不去的进度，就只好默默忍受，只当是年少不经世事所犯下的拙劣错误罢了。

那种玩法有七个紧要问题。

那么到底什么样是NAT超时呢?

原来那是因为IPV4引起的，大家上网很可能会处于一个NAT设备（有线路由器之类）之后。
NAT设备会在IP封包通过配备时修改源/目标IP地址. 对于家用路由器来说,
使用的是网络地址端口转换(NAPT), 它不只改IP, 还修改TCP和UDP探究的端口号,
那样就能让内网中的设备共用同一个外网IP. 举个例证,
NAPT维护一个类似下表的NAT表：

NAT映射

NAT设备会根据NAT表对出去和进入的数量做修改,
比如将192.168.0.3:8888发出去的封包改成120.132.92.21:9202,
外部就觉着她们是在和120.132.92.21:9202通信.
同时NAT设备会将120.132.92.21:9202收下的封包的IP和端口改成192.168.0.3:8888,
再发给内网的主机, 那样内部和表面就能双向通信了,
但借使中间192.168.0.3:8888 ==
120.132.92.21:9202这一炫耀因为一些原因被NAT设备淘汰了,
那么外部设备就不可能直接与192.168.0.3:8888通信了。

我们的装备常常是地处NAT设备的末端, 比如在大学里的校园网,
查一下谈得来分配到的IP, 其实是内网IP, 申明大家在NAT设备前面,
如若我们在寝室再接个路由器, 那么我们发出的数目包会多通过几回NAT.

国内移动无线网络运营商在链路上一段时间内没有数据通讯后,
会淘汰NAT表中的对应项, 造成链路中断。

而国内的运营商一般NAT超时的时光为5分钟，所以平常大家心跳设置的年华距离为3-5秒钟。

尘烟过，知多少，花开花谢。没有何缘分可以维持平生，再感人的歌舞剧也会有散场的那一刻。既知那样，又何须在乎聚散离合。大家都是人生气象中的过客，既然守不住约定，就毫无轻许诺言，誓言今生。韶华胜极便是衰，寂寞最恨晚，一程山水，一段心思，纵算年华老去，离人已去，什么人也无须给何人交代。既是决定要分开，那么天涯的你自我，各自安好，是否晴天，已不首要。聚散友情，然则是一年花季的停止。

一个是周期长。品牌商给面料商下订单，交订金，面料商不会把面料快递给您，而是径直发放厂家。

继之大家来讲讲PingPong机制:

众多小伙伴可能又会感觉到到疑惑了，那么大家在这心跳间隔的3-5分钟假使屡次三番假在线（例如在地铁电梯那种环境下）。那么大家岂不是不可能确保新闻的即时性么？那明明是大家鞭长莫及经受的，所以业内的解决方案是利用双向的PingPong机制。

当服务端发出一个Ping，客户端从未在预订的时辰内重返响应的ack，则认为客户端已经不在线，那时我们Server端会主动断开Scoket连天，并且改由APNS推送的法门发送新闻。
一如既往的是，当客户端去发送一个音讯，因为我们迟迟不可能接收服务端的响应ack包，则讲明客户端如故服务端已不在线，我们也会显得音讯发送失利，并且断开Scoket连接。

还记得大家事先CocoaSyncSockt的事例所讲的取得音讯超时就断开吗？其实它就是一个PingPong建制的客户端已毕。我们每一次可以在殡葬音信成功后，调用那一个超时读取的情势，若是一段时间没接受服务器的响应，那么注解连接不可用，则断开Scoket连接

那就出现了第四个问题。面料的真伪与上下是品牌商不能掌控的。

末尾就是重连机制:

辩驳上，大家和好积极去断开的Scoket延续（例如退出账号，APP退出到后台等等），不必要重连。其他的总是断开，我们都亟需开展断线重连。
诚如解决方案是尝试重连四次，假如仍旧无法重连成功，那么不再举行重连。
接下去的WebScoket的例证，我会封装一个重连时间指数级拉长的一个重连方式，可以用作一个参照。

其多少个问题，顾客选定面料，品牌商也下订金了，结果面料商告知没库存，等他把音讯举报给品牌商再反馈给买主，极大影响消费体验。

言归正传，我们看完上述多少个概念之后，大家来讲一个WebScoket最具代表性的一个第三方框架SocketRocket。

咱俩先是来看看它对外封装的片段方法：

@interface SRWebSocket : NSObject <NSStreamDelegate>

@property (nonatomic, weak) id <SRWebSocketDelegate> delegate;

@property (nonatomic, readonly) SRReadyState readyState;
@property (nonatomic, readonly, retain) NSURL *url;


@property (nonatomic, readonly) CFHTTPMessageRef receivedHTTPHeaders;

// Optional array of cookies (NSHTTPCookie objects) to apply to the connections
@property (nonatomic, readwrite) NSArray * requestCookies;

// This returns the negotiated protocol.
// It will be nil until after the handshake completes.
@property (nonatomic, readonly, copy) NSString *protocol;

// Protocols should be an array of strings that turn into Sec-WebSocket-Protocol.
- (id)initWithURLRequest:(NSURLRequest *)request protocols:(NSArray *)protocols allowsUntrustedSSLCertificates:(BOOL)allowsUntrustedSSLCertificates;
- (id)initWithURLRequest:(NSURLRequest *)request protocols:(NSArray *)protocols;
- (id)initWithURLRequest:(NSURLRequest *)request;

// Some helper constructors.
- (id)initWithURL:(NSURL *)url protocols:(NSArray *)protocols allowsUntrustedSSLCertificates:(BOOL)allowsUntrustedSSLCertificates;
- (id)initWithURL:(NSURL *)url protocols:(NSArray *)protocols;
- (id)initWithURL:(NSURL *)url;

// Delegate queue will be dispatch_main_queue by default.
// You cannot set both OperationQueue and dispatch_queue.
- (void)setDelegateOperationQueue:(NSOperationQueue*) queue;
- (void)setDelegateDispatchQueue:(dispatch_queue_t) queue;

// By default, it will schedule itself on +[NSRunLoop SR_networkRunLoop] using defaultModes.
- (void)scheduleInRunLoop:(NSRunLoop *)aRunLoop forMode:(NSString *)mode;
- (void)unscheduleFromRunLoop:(NSRunLoop *)aRunLoop forMode:(NSString *)mode;

// SRWebSockets are intended for one-time-use only.  Open should be called once and only once.
- (void)open;

- (void)close;
- (void)closeWithCode:(NSInteger)code reason:(NSString *)reason;

// Send a UTF8 String or Data.
- (void)send:(id)data;

// Send Data (can be nil) in a ping message.
- (void)sendPing:(NSData *)data;

@end

#pragma mark - SRWebSocketDelegate

@protocol SRWebSocketDelegate <NSObject>

// message will either be an NSString if the server is using text
// or NSData if the server is using binary.
- (void)webSocket:(SRWebSocket *)webSocket didReceiveMessage:(id)message;

@optional

- (void)webSocketDidOpen:(SRWebSocket *)webSocket;
- (void)webSocket:(SRWebSocket *)webSocket didFailWithError:(NSError *)error;
- (void)webSocket:(SRWebSocket *)webSocket didCloseWithCode:(NSInteger)code reason:(NSString *)reason wasClean:(BOOL)wasClean;
- (void)webSocket:(SRWebSocket *)webSocket didReceivePong:(NSData *)pongPayload;

// Return YES to convert messages sent as Text to an NSString. Return NO to skip NSData -> NSString conversion for Text messages. Defaults to YES.
- (BOOL)webSocketShouldConvertTextFrameToString:(SRWebSocket *)webSocket;

@end

办法也很粗略，分为多少个部分：

• 一对为SRWebSocket的开始化，以及总是，关闭连接，发送音信等格局。
• 另一部分为SRWebSocketDelegate，其中囊括一些回调：
  接过新闻的回调，连接战败的回调，关闭连接的回调，收到pong的回调，是否必要把data音讯转换成string的代理方法。

拉链互动通过投入数百万元，搭建全新供应链数据跟踪系统，将地点多个问题逐一化解。

随着我们照旧举个例子来得以完毕以下，首先来封装一个TYHSocketManager单例：

TYHSocketManager.h

#import <Foundation/Foundation.h>

typedef enum : NSUInteger {
    disConnectByUser ,
    disConnectByServer,
} DisConnectType;


@interface TYHSocketManager : NSObject

+ (instancetype)share;

- (void)connect;
- (void)disConnect;

- (void)sendMsg:(NSString *)msg;

- (void)ping;

@end

TYHSocketManager.m

#import "TYHSocketManager.h"
#import "SocketRocket.h"

#define dispatch_main_async_safe(block)\
    if ([NSThread isMainThread]) {\
        block();\
    } else {\
        dispatch_async(dispatch_get_main_queue(), block);\
    }

static  NSString * Khost = @"127.0.0.1";
static const uint16_t Kport = 6969;


@interface TYHSocketManager()<SRWebSocketDelegate>
{
    SRWebSocket *webSocket;
    NSTimer *heartBeat;
    NSTimeInterval reConnectTime;

}

@end

@implementation TYHSocketManager

+ (instancetype)share
{
    static dispatch_once_t onceToken;
    static TYHSocketManager *instance = nil;
    dispatch_once(&onceToken, ^{
        instance = [[self alloc]init];
        [instance initSocket];
    });
    return instance;
}

//初始化连接
- (void)initSocket
{
    if (webSocket) {
        return;
    }


    webSocket = [[SRWebSocket alloc]initWithURL:[NSURL URLWithString:[NSString stringWithFormat:@"ws://%@:%d", Khost, Kport]]];

    webSocket.delegate = self;

    //设置代理线程queue
    NSOperationQueue *queue = [[NSOperationQueue alloc]init];
    queue.maxConcurrentOperationCount = 1;

    [webSocket setDelegateOperationQueue:queue];

    //连接
    [webSocket open];


}

//初始化心跳
- (void)initHeartBeat
{

    dispatch_main_async_safe(^{

        [self destoryHeartBeat];

        __weak typeof(self) weakSelf = self;
        //心跳设置为3分钟，NAT超时一般为5分钟
        heartBeat = [NSTimer scheduledTimerWithTimeInterval:3*60 repeats:YES block:^(NSTimer * _Nonnull timer) {
            NSLog(@"heart");
            //和服务端约定好发送什么作为心跳标识，尽可能的减小心跳包大小
            [weakSelf sendMsg:@"heart"];
        }];
        [[NSRunLoop currentRunLoop]addTimer:heartBeat forMode:NSRunLoopCommonModes];
    })

}

//取消心跳
- (void)destoryHeartBeat
{
    dispatch_main_async_safe(^{
        if (heartBeat) {
            [heartBeat invalidate];
            heartBeat = nil;
        }
    })

}


#pragma mark - 对外的一些接口

//建立连接
- (void)connect
{
    [self initSocket];

    //每次正常连接的时候清零重连时间
    reConnectTime = 0;
}

//断开连接
- (void)disConnect
{

    if (webSocket) {
        [webSocket close];
        webSocket = nil;
    }
}


//发送消息
- (void)sendMsg:(NSString *)msg
{
    [webSocket send:msg];

}

//重连机制
- (void)reConnect
{
    [self disConnect];

    //超过一分钟就不再重连 所以只会重连5次 2^5 = 64
    if (reConnectTime > 64) {
        return;
    }

    dispatch_after(dispatch_time(DISPATCH_TIME_NOW, (int64_t)(reConnectTime * NSEC_PER_SEC)), dispatch_get_main_queue(), ^{
        webSocket = nil;
        [self initSocket];
    });


    //重连时间2的指数级增长
    if (reConnectTime == 0) {
        reConnectTime = 2;
    }else{
        reConnectTime *= 2;
    }

}


//pingPong
- (void)ping{

    [webSocket sendPing:nil];
}



#pragma mark - SRWebSocketDelegate

- (void)webSocket:(SRWebSocket *)webSocket didReceiveMessage:(id)message
{
    NSLog(@"服务器返回收到消息:%@",message);
}


- (void)webSocketDidOpen:(SRWebSocket *)webSocket
{
    NSLog(@"连接成功");

    //连接成功了开始发送心跳
    [self initHeartBeat];
}

//open失败的时候调用
- (void)webSocket:(SRWebSocket *)webSocket didFailWithError:(NSError *)error
{
    NSLog(@"连接失败.....\n%@",error);

    //失败了就去重连
    [self reConnect];
}

//网络连接中断被调用
- (void)webSocket:(SRWebSocket *)webSocket didCloseWithCode:(NSInteger)code reason:(NSString *)reason wasClean:(BOOL)wasClean
{

    NSLog(@"被关闭连接，code:%ld,reason:%@,wasClean:%d",code,reason,wasClean);

    //如果是被用户自己中断的那么直接断开连接，否则开始重连
    if (code == disConnectByUser) {
        [self disConnect];
    }else{

        [self reConnect];
    }
    //断开连接时销毁心跳
    [self destoryHeartBeat];

}

//sendPing的时候，如果网络通的话，则会收到回调，但是必须保证ScoketOpen，否则会crash
- (void)webSocket:(SRWebSocket *)webSocket didReceivePong:(NSData *)pongPayload
{
    NSLog(@"收到pong回调");

}


//将收到的消息，是否需要把data转换为NSString，每次收到消息都会被调用，默认YES
//- (BOOL)webSocketShouldConvertTextFrameToString:(SRWebSocket *)webSocket
//{
//    NSLog(@"webSocketShouldConvertTextFrameToString");
//
//    return NO;
//}

.m文件有点长，我们能够参见github中的demo举办阅读，这回大家添加了一部分细节的事物了，包罗一个简便的心跳，重连机制，还有webScoket包装好的一个pingpong机制。
代码非常不难，大家能够同盟着注释读一读，应该很简单领会。
亟待说一下的是这几个心跳机制是一个定时的间隔，往往我们也许会有更扑朔迷离已毕，比如大家正在发送新闻的时候，可能就不需求心跳。当不在发送的时候在开启心跳之类的。微信有一种更高端的完结形式，有趣味的小伙伴可以看看：
微信的智能心跳完毕格局

再有少数必要说的就是那一个重连机制，demo中自我利用的是2的指数级别提升，第四回眼珍爱连，第二次2秒，第一次4秒，第三次8秒…直到过量64秒就不再重连。而轻易的两遍得逞的连年，都会重置这一个重连时间。

最终一点亟需说的是，这几个框架给大家封装的webscoket在调用它的sendPing形式以前，一定要一口咬住不放当前scoket是否连接，假设不是接连景况，程序则会crash。

客户端的完结就大约如此，接着同样大家要求贯彻一个服务端，来探视实际通讯作用。

率先，绕过小代理商，直接和面料厂家或者市面上最主流的总代理商同盟，从源头上最大程度确保货源质地。

webScoket服务端完毕

在此地我们鞭长莫及沿用以前的node.js例子了，因为那并不是一个原生的scoket，这是webScoket，所以大家服务端同样须求坚守webScoket探讨，两者才能已毕通信。
实质上那里已毕也很简短，我利用了node.js的ws模块，只须求用npm去安装ws即可。
什么是npm啊？举个例证，npm之于Node.js相当于cocospod至于iOS，它就是一个进行模块的一个管理工具。如若不明白怎么用的可以看看那篇文章：npm的使用

俺们进来当前剧本目录，输入终端命令，即可安装ws模块：

$ npm install ws

我们假使懒得去看npm的伙伴也没涉及，直接下载github中的
WSServer.js这几个文件运行即可。
该源文件代码如下：

var WebSocketServer = require('ws').Server,

wss = new WebSocketServer({ port: 6969 });
wss.on('connection', function (ws) {
    console.log('client connected');

    ws.send('你是第' + wss.clients.length + '位');  
    //收到消息回调
    ws.on('message', function (message) {
        console.log(message);
        ws.send('收到:'+message);  
    });

     // 退出聊天  
    ws.on('close', function(close) {  

        console.log('退出连接了');  
    });  
});
console.log('开始监听6969端口');

代码没几行，领悟起来很简短。
固然监听了本机6969端口，如若客户端连接了，打印lient
connected，并且向客户端发送：你是第几位。
若果收到客户端新闻后，打印音信，并且向客户端发送那条吸收的新闻。

说不上，在门店里供消费者选取的面料，全是过去销售数量彰显最畅销的面料。哪些项目标面料卖的最多，就加大那几个布料的库存量。低库存面料不在顾客的接纳之列，以此保障货源的丰富性。

继之大家一样来运行一下看望效果：

运行大家得以看来，主动去断开的连年，没有去重连，而server端断开的，大家打开了重连。感兴趣的情侣可以下载demo实际运行一下。

分割图.png

其三，通过该体系下单后，系统会活动给面料商短信提醒相关音讯，指示其及时处理。

4.我们随后来探视MQTT：

MQTT是一个拉扯协议，它比webScoket更上层，属于应用层。
它的基本情势是大概的发布订阅，也就是说当一条新闻发出去的时候，何人订阅了什么人就会境遇。其实它并不符合IM的场馆，例如用来得以完结多少简单IM场景，却必要很大气的、复杂的处理。
正如相符它的情景为订阅公布那种格局的，例如微信的实时共享地方，滴滴的地形图上小车的移动、客户端推送等成效。

首先大家来探望基于MQTT探讨的框架-MQTTKit:
那一个框架是c来写的，把一部分办法公开在MQTTKit类中，对外用OC来调用，大家来看望那么些类：

@interface MQTTClient : NSObject {
    struct mosquitto *mosq;
}

@property (readwrite, copy) NSString *clientID;
@property (readwrite, copy) NSString *host;
@property (readwrite, assign) unsigned short port;
@property (readwrite, copy) NSString *username;
@property (readwrite, copy) NSString *password;
@property (readwrite, assign) unsigned short keepAlive;
@property (readwrite, assign) BOOL cleanSession;
@property (nonatomic, copy) MQTTMessageHandler messageHandler;

+ (void) initialize;
+ (NSString*) version;

- (MQTTClient*) initWithClientId: (NSString *)clientId;
- (void) setMessageRetry: (NSUInteger)seconds;

#pragma mark - Connection

- (void) connectWithCompletionHandler:(void (^)(MQTTConnectionReturnCode code))completionHandler;
- (void) connectToHost: (NSString*)host
     completionHandler:(void (^)(MQTTConnectionReturnCode code))completionHandler;
- (void) disconnectWithCompletionHandler:(void (^)(NSUInteger code))completionHandler;
- (void) reconnect;
- (void)setWillData:(NSData *)payload
            toTopic:(NSString *)willTopic
            withQos:(MQTTQualityOfService)willQos
             retain:(BOOL)retain;
- (void)setWill:(NSString *)payload
        toTopic:(NSString *)willTopic
        withQos:(MQTTQualityOfService)willQos
         retain:(BOOL)retain;
- (void)clearWill;

#pragma mark - Publish

- (void)publishData:(NSData *)payload
            toTopic:(NSString *)topic
            withQos:(MQTTQualityOfService)qos
             retain:(BOOL)retain
  completionHandler:(void (^)(int mid))completionHandler;
- (void)publishString:(NSString *)payload
              toTopic:(NSString *)topic
              withQos:(MQTTQualityOfService)qos
               retain:(BOOL)retain
    completionHandler:(void (^)(int mid))completionHandler;

#pragma mark - Subscribe

- (void)subscribe:(NSString *)topic
withCompletionHandler:(MQTTSubscriptionCompletionHandler)completionHandler;
- (void)subscribe:(NSString *)topic
          withQos:(MQTTQualityOfService)qos
completionHandler:(MQTTSubscriptionCompletionHandler)completionHandler;
- (void)unsubscribe: (NSString *)topic
withCompletionHandler:(void (^)(void))completionHandler;

以此类一起分为4个部分：初阶化、连接、发布、订阅，具体方法的成效可以先看看方法名通晓下，大家跟着来用那个框架封装一个实例。

一如既往，大家封装了一个单例MQTTManager。
MQTTManager.h

#import <Foundation/Foundation.h>

@interface MQTTManager : NSObject

+ (instancetype)share;

- (void)connect;
- (void)disConnect;

- (void)sendMsg:(NSString *)msg;

@end

MQTTManager.m

#import "MQTTManager.h"
#import "MQTTKit.h"

static  NSString * Khost = @"127.0.0.1";
static const uint16_t Kport = 6969;
static  NSString * KClientID = @"tuyaohui";


@interface MQTTManager()
{
    MQTTClient *client;

}

@end

@implementation MQTTManager

+ (instancetype)share
{
    static dispatch_once_t onceToken;
    static MQTTManager *instance = nil;
    dispatch_once(&onceToken, ^{
        instance = [[self alloc]init];
    });
    return instance;
}

//初始化连接
- (void)initSocket
{
    if (client) {
        [self disConnect];
    }


    client = [[MQTTClient alloc] initWithClientId:KClientID];
    client.port = Kport;

    [client setMessageHandler:^(MQTTMessage *message)
     {
         //收到消息的回调，前提是得先订阅

         NSString *msg = [[NSString alloc]initWithData:message.payload encoding:NSUTF8StringEncoding];

         NSLog(@"收到服务端消息：%@",msg);

     }];

    [client connectToHost:Khost completionHandler:^(MQTTConnectionReturnCode code) {

        switch (code) {
            case ConnectionAccepted:
                NSLog(@"MQTT连接成功");
                //订阅自己ID的消息，这样收到消息就能回调
                [client subscribe:client.clientID withCompletionHandler:^(NSArray *grantedQos) {

                    NSLog(@"订阅tuyaohui成功");
                }];

                break;

            case ConnectionRefusedBadUserNameOrPassword:

                NSLog(@"错误的用户名密码");

            //....
            default:
                NSLog(@"MQTT连接失败");

                break;
        }

    }];
}

#pragma mark - 对外的一些接口

//建立连接
- (void)connect
{
    [self initSocket];
}

//断开连接
- (void)disConnect
{
    if (client) {
        //取消订阅
        [client unsubscribe:client.clientID withCompletionHandler:^{
            NSLog(@"取消订阅tuyaohui成功");

        }];
        //断开连接
        [client disconnectWithCompletionHandler:^(NSUInteger code) {

            NSLog(@"断开MQTT成功");

        }];

        client = nil;
    }
}

//发送消息
- (void)sendMsg:(NSString *)msg
{
    //发送一条消息，发送给自己订阅的主题
    [client publishString:msg toTopic:KClientID withQos:ExactlyOnce retain:YES completionHandler:^(int mid) {

    }];
}
@end

心想事成代码很粗略，须要说一下的是：
1）当大家总是成功了，大家须要去订阅自己clientID公海赌船网站，的音信，这样才能吸纳发给自己的信息。
2）其次是那几个框架为大家兑现了一个QOS机制，那么哪些是QOS呢？

QoS（Quality of
Service，劳动质料）指一个网络可以运用各个基础技术，为指定的网络通信提供更好的服务力量,
是网络的一种安全体制， 是用来缓解网络延迟和隔阂等问题的一种技术。

在此地，它提供了多个挑选：

typedef enum MQTTQualityOfService : NSUInteger {
    AtMostOnce,
    AtLeastOnce,
    ExactlyOnce
} MQTTQualityOfService;

分别对应最多发送一回，至少发送一遍，精确只发送三遍。

• QOS(0),最多发送一回：即使信息尚未发送过去，那么就一贯丢掉。
• QOS(1),至少发送一遍：有限支持音信一定发送过去，不过发三次不确定。
• QOS(2),精确只发送一遍：它其中会有一个很复杂的殡葬机制，确保消息送到，而且只发送一回。

更详实的关于该机制得以看看那篇小说：MQTT协议笔记之信息流QOS。

相同的大家需求一个用MQTT协议得以完结的服务端，大家仍然node.js来促成，本次我们依旧要求用npm来新增一个模块mosca。
俺们来探视服务端代码：
MQTTServer.js

var mosca = require('mosca');  

var MqttServer = new mosca.Server({  
    port: 6969  
});  

MqttServer.on('clientConnected', function(client){  
    console.log('收到客户端连接，连接ID：', client.id);  
});  

/** 
 * 监听MQTT主题消息 
 **/  
MqttServer.on('published', function(packet, client) {  
    var topic = packet.topic;  
    console.log('有消息来了','topic为：'+topic+',message为：'+ packet.payload.toString());  

});  

MqttServer.on('ready', function(){  
    console.log('mqtt服务器开启，监听6969端口');  
});  

服务端代码没几行，开启了一个服务，并且监听本机6969端口。并且监听了客户端连接、发表音信等景色。

第四，支持面料商管理库存。将条形码嵌入面料商库房，面料商裁四回面料扫一下码，拉链互动和面料商双方均可实时监督库存情状。

接着大家一致来运转一下探访效果：

从这之后，大家得以已毕了一个粗略的MQTT封装。

吴巍说，这个动作看似简单，但在现阶段华夏衣服行业里能做到的没有几家，他们梳理那套供应链整整花了一年，超越定制行业同行三到五步。

5.XMPP：XMPPFramework框架

结果就是并从未XMPP…因为个人感觉XMPP对于IM来说其实是不堪重用。仅仅只可以当做一个玩具demo，给我们练练手。网上有太多XMPP的始最终，相当一些用openfire来做服务端，这一套东西实在是太老了。还记得多年前，楼主初识IM就是用的这一套东西…
只要大家一如既往感兴趣的能够看看那篇小说：iOS 的 XMPPFramework
简介。那里就不举例赘述了。

设计师管模块，消费者来构成，众口不再难调

三、关于IM传输格式的挑选：

引用陈宜龙大神文章（iOS程序犭袁）中一段：
使用 ProtocolBuffer 减少 Payload
滴滴打车40%；
携程从前分享过，说是选用新的Protocol
Buffer数据格式+Gzip压缩后的Payload大小下降了15%-45%。数据体系化耗时下落了80%-90%。

利用高效安全的个体协议，接济长连接的复用，稳定省电省流量
【高效】提升网络请求成功率，新闻体越大，退步几率随之扩充。
【省流量】流量消耗极少，省流量。一条新闻数据用Protobuf连串化后的大小是
JSON 的1/10、XML格式的1/20、是二进制系列化的1/10。同 XML 比较， Protobuf
性能优势有目共睹。它以便捷的二进制格局存储，比 XML 小 3 到 10 倍，快 20 到
100 倍。
【省电】省电
【高效心跳包】同时心跳包协议对IM的电量和流量影响很大，对心跳包协议上拓展了极简设计：仅
1 Byte 。
【易于使用】开发人士通过根据一定的语法定义结构化的音信格式，然后送给命令行工具，工具将自动生成相关的类，可以帮衬java、c++、python、Objective-C等语言环境。通过将那一个类富含在项目中，可以很轻松的调用相关办法来成功业务新闻的连串化与反体系化工作。语言帮衬：原生帮助c++、java、python、Objective-C等多达10余种语言。
2015-08-27 Protocol Buffers
v3.0.0-beta-1中揭晓了Objective-C(Alpha)版本， 2016-07-28 3.0 Protocol
Buffers v3.0.0专业版公布，正式协理 Objective-C。
【可信】微信和手机 QQ 那样的主流 IM
应用也早已在行使它（拔取的是改造过的Protobuf协议）

什么样测试注解 Protobuf 的高性能？
对数码分别操作100次，1000次，10000次和100000次开展了测试，
纵坐标是做到时间，单位是皮秒，
反种类化
序列化
字节长度

数量来源。

数码来自：项目
thrift-protobuf-compare，测试项为
Total Time，也就是
指一个目的操作的凡事时间，包罗创建对象，将对象连串化为内存中的字节体系，然后再反系列化的满贯经过。从测试结果可以看出
Protobuf 的成就很好.
缺点：
也许会导致 APP 的包体积增大，通过 谷歌 提供的台本生成的
Model，会那些“庞大”，Model 一多，包体积也就会随之变大。
假若 Model 过多，可能引致 APP 打包后的体积骤增，但 IM 服务所使用的 Model
卓殊少，比如在 ChatKit-OC 中只用到了一个 Protobuf 的
Model：Message对象，对包体积的影响微乎其微。
在利用进度中要客观地权衡包体积以及传输成效的问题，据说去啥地方网，就已经为了缩短包体积，进而裁减了
Protobuf 的运用。

综上所述，大家挑选传输格式的时候：ProtocolBuffer > Json >
XML

设若大家对ProtocolBuffer用法感兴趣可以参照下这两篇小说：
ProtocolBuffer for Objective-C 运行条件布署及使用
iOS之ProtocolBuffer搭建和演示demo

传统衣裳产业链周期极长，品牌商按照流行时髦确定衣服样式，选定面料与辅料，生产成衣，随后加入各样订货会收取订单，批量生产，然后再铺货，运气好的畅销一阵，促销下架，运气不佳的干脆就砸在手里。这一个周期短则数月，长则半年，有些风格，设计时挺流行，等周边扑向市场，市场又变口味了。

三、IM一些别样问题

从上个世纪的赤子蓝蚂蚁工装，再到今年巴西奥运开幕式上中国队“西红柿炒鸡蛋”队服遇到网友吐槽，中国的现世衣裳经历了“穿得暖->穿得美观->穿出品味和个性”七个级次。

1.IM的可依赖性：

我们事先穿插在例子中涉嫌过：
心跳机制、PingPong机制、断线重连机制、还有大家前边所说的QOS机制。那么些被用来担保连接的可用，音讯的即时与纯粹的送达等等。
上述内容保险了我们IM服务时的可信赖性，其实大家能做的还有好多：比如咱们在大文件传输的时候使用分片上传、断点续传、秒传技能等来担保文件的传导。

C2B形式成全了尝试与个性，更加适合衣服行业，拉链互动废弃订货制主打定制牌，方向毫无问题，不过问题又来了：

2.安全性：

我们家常便饭还须求部分平安机制来保险我们IM通信安全。
例如：防止 DNS
污染、帐号安全、第三方服务器鉴权、单点登录等等

哪些在千人千面的消费者口味与设计师风格之间达到平衡？

3.部分别样的优化：

就好像微信，服务器不做聊天记录的仓储，只在本机举行缓存，那样可以收缩对服务端数据的伏乞，一方面减轻了服务器的下压力，另一方面收缩客户端流量的损耗。
咱俩开展http连接的时候尽量使用上层API，类似NSUrlSession。而网络框架尽量采纳AFNetWorking3。因为这个上层网络请求都用的是HTTP/2
，大家恳请的时候可以复用那些连接。

更加多优化相关内容可以参照参考那篇作品：
IM
即时通讯技术在多利(多利)用场景下的技艺已毕，以及性能调优

四、音视频通话

IM应用中的实时音视频技术，几乎是IM开发中的最终一道高墙。原因在于：实时音视频技术
= 音录像处理技术 + 网络传输技术
的横向技术运用集合体，而集体互联网不是为着实时通信设计的。
实时音录像技术上的兑现内容重点概括：音视频的募集、编码、网络传输、解码、播放等环节。这么多项并不简单的技术使用，即便把握不当，将会在在实际支付进度中蒙受一个又一个的坑。

因为楼主自己对那块的技巧精晓很浅，所以引用了一个一日千里的篇章来给我们一个参考，感兴趣的仇人可以看看：
《即时通讯音视频开发（一）：视频编解码之辩护概述》
《即时通讯音视频开发（二）：录像编解码之数字视频介绍》
《即时通讯音视频开发（三）：录像编解码之编码基础》
《即时通讯音视频开发（四）：视频编解码之预测技术介绍》
《即时通讯音录像开发（五）：认识主流摄像编码技术H.264》
《即时通讯音视频开发（六）：咋样开首音频编解码技术的求学》
《即时通讯音录像开发（七）：音频基础及编码原理入门》
《即时通讯音视频开发（八）：常见的实时语音通讯编码标准》
《即时通讯音录像开发（九）：实时语音通讯的回信及回音消除�概述》
《即时通讯音视频开发（十）：实时语音通讯的复信消除�技术详解》
《即时通讯音录像开发（十一）：实时语音通讯丢包补偿技术详解》
《即时通讯音视频开发（十二）：四人实时音视频聊天架构探究》
《即时通讯音视频开发（十三）：实时视频编码H.264的特征与优势》
《即时通讯音视频开发（十四）：实时音视频数据传输协议介绍》
《即时通讯音视频开发（十五）：聊聊P2P与实时音视频的采取情况》
《即时通讯音视频开发（十六）：移动端实时音视频开发的多少个提议》
《即时通讯音视频开发（十七）：视频编码H.264、V8的前生今生》

拉链互动一流设计师团队

写在终极：

正文内容为原创，且仅表示楼主现阶段的一对盘算，借使有何错误，欢迎指正~

她俩利用了抓大放小的方针。一流设计师团队担当版型等正规模块的搭建，顾客可以经过整合模块形成自己的个性化定制，至于脖口加宽、在袖口上绣个性化名字等急需，普通设计师就足以满足，开销也不高。

假诺有人转发，麻烦请评释出处。

衬衣定制，量体是决定成衣是否合身的关键因素，怎么着保管量体成功率最高，下降成衣返修率，是业界公认难点。曾经有品牌商喊出“净尺寸量体转化成衣”的概念，结果造成返修率高时可达50%，从而消耗来回物流、人工及时间成本。吴巍告诉健一会，拉链互动的返修率可以形成5%，与此对应的，是客户的高满足度。

拉链互动部分供销社客户名单

拉链互动团队已经排斥ToB方式，担心它会损坏团结ToC定位的纯粹性。不过她们越做尤其现，做ToB业务与做ToC业务难度同样，在设计端与民用须要远非分歧，产能更不成问题，单位时间内的联络开销更低。于是他们在二零一六年上半年应运创造大客户部，中信银行、华佗教育等均成为其客户，再有功夫深厚的华夏职业装设计大师刘薇的精品设计助力，短短半年，ToB业务营业额已经占整个营业额的三分之一。

门店变脸做经验：加盟不要钱，上市齐发财

在二〇一五年的时候，拉链互动在亲见大批量上门服务项目纷纭死掉之后，团队内部已经有过三回大商讨，反思O2O那条路线是跑偏了？仍然应当锲而不舍下去？

她俩发觉，对于衣裳类消费者来说，很少人会经过互联网上的几张图纸就草率地做出购买上千元一件的洋装的决定，他们迟早要到店里亲眼看一下钱物，看看衣服是否赏心悦目，面料质地怎么样，才会最终做出购买控制。通过线上连片上门量体是伪须求，线下体验才是真必要。

在这一次座谈之后，拉链互动团队内部达成了举行线下门店的共识。

唯独，门店在此外传统连锁行业里都是重资金，所需投入的运营资本极高，风险却不小，选址、运营协会、库存等都是变数。

传统衣裳行业品牌商要想建立一个地级市代理，代理商一年资金体量是500万至600万流动资金。

拉链互动干脆来了个“三零”格局，加盟商投资后所能获得的报恩是零加盟费、零库存、零中介费。

鲁人持竿那些格局，投资者以尤其小的老本就可以进去一个传统刚性要求市场，所需资金在30万左右即可，其中的绝一大半都用于装饰及样衣等工具采购支出，以后的花费部分只囊括房租，而由于没有库存，品牌商不收中介费，确保每个月有丰裕营收，压力万分小。吴巍介绍，拉链互动共处18家门店，投资回报率在一年半之内均可收回。

除开及时的收益，拉链互动还确立了事业共同人机制，所有门店同盟伙伴的销售额在拉链互动B轮融资时举办并表，以后走向IPO时，销售体量会兑现爆炸性增进。作为协商的一片段，门店拥有成品连串、销售系列，价格体系及拥有政策体制均需由拉链互动决定，其一般性管理、考勤、签到全部用拉链互动提供的位移管理软件达成。门店的同盟伙伴只需成功搜索客户和搞好劳务（量体）两项工作。

拉链互动通过供应链及音讯连串同步，输出标准，拉链互动没有在门店建设里投入一分钱，就获取了门店控制权，并促成了品牌商和加盟商的联手互赢。

拉链互动门店布局

在门店的选址上，拉链互动将三线城市、西边省会城市及中北边地级市作为最主要发力对象。在门店合营伙伴的选料上，重点关怀在该地所有极强社交人脉资源的行业人员，拔取当地人运营门店，有助于下落品牌打入当地市场的障碍。每个城市只建一家店，以落到实处区域珍视。而门店与历史观门店有本质分歧，它实在是区域内运营中央的定义，不必然设在热闹商圈，可以设在商旅里，甚至建在办公楼里，消费者可以到店定制，也足以大饱眼福基于地理地方的上门定制服务。

从供应链监控到创新型门店的开办，拉链互动的施行足够突显，他们的野心不止于O2O，而是在做一件颠覆传统的事，目的在于优化进步传统衣服行业不难、凶狠、多层级、陈旧的商业情势。

找国脚代言，背心联姻足球

生产销售端的题目化解了，怎样建立客户规模？

拉链互动没忘了应用创业团队自身优势，加大品牌营销力度，钱没多花，效果不降价。

拉链互动的强大代言队伍容貌

背心是老公的专利，而最能表示男人的活动则是足球，中国男足的终点时期无疑是打进世界杯（FIFA World Cup）决赛圈的那支阵容。经过一番梳理，拉链互动创始团队里唯一的一位女将动用自己此前在体育传媒的转业人脉，找来了杨晨、李金羽、高峰、杨璞、曹限东等数十位前国脚为品牌背书，因为他们的目的用户是70后、80后男生那拨中产阶级主力军，那类群体都对华夏足球难得的清爽历史铭记。

除外有指向地发掘机要目标客户，拉链互动还足够挖掘线上社群的口碑功用，在一个30人的老客户群里，不到一个钟头就卖出去20多件外套。新产品还不曾生产，就有不少个客户付款订购。

从那之后，拉链互动的所有线下门店均不设收银出纳种类，所有消费者如有中意款式，均需经过拉链互动总部的线上超市下单落成订购，通过微信打款，既减弱了人工开支，又能对门店销售情况实时掌控，仍可以收集用户的量体数据，可谓一举三得。

攻占衣食住行领域的末尾一块堡垒

人类常常生活的四大一部分：衣、食、住、行，后边三类领域在活动互联时代都获得了突破性的消费格局变革，只有衣服行业的变革极其缓慢。吴巍在到场衣裳业之后，对于变革缓慢的来由有了一发深入的咀嚼。

首先是技术门槛高。衣裳属于人体工程学，从筹划到版型均有越发高校传授技术，本身技术含量。大家穿衣物久了，不认为它是个高科技，实际上现代衣服行业对中华来讲也就是二三十年的前进历程，从前都是手工裁缝在做，是门手艺活儿。

附带是人肉体型差别大。西南和东北人的体型完全不等同，很多衣服品牌地域特征显明。而吃住行在地区方面就是有差别，也不影响互相体验，衣服更加，穿不上，设计得再好也没用。

最丰硕的则属主观审美的距离。汽车出行，首要诉求是从A点抵达B点，至于车的优劣和清爽程度都不是非同通常的。衣裳跟一个人的主观审美有卓殊大关系，没有老公会穿一件自己认为不帅的衣物出来，而如对于“帅”这些概念，每个人都有和好的领悟。用标准工具技术去化解非标层面问题，是一件很让人头痛的事。

拉链互动创办者吴巍

吴巍以前做过投资，在进入实体后，他发现实业尤其是创制业可以把人的秉性磨得更好一些。但他又充满信心，信心的来源来自于中华的宏大市场与越来越优化的广泛配套条件，以及拉链互动自身的正常造血能力。

拉链互动共处现金流分外动感，今年销售业绩臆度有500%的进步，毛利率高达70%。与二零一五年比较，为止二零一六年8月，拉链互动的年销售额已经提升了5倍。

妇孺皆知，在变革缓慢的本行里厮杀，拉链互动早已做好了打持久战的预备。

小西服，大愿景

吴巍对于拉链互动的进化具备显明规划。

首先等级，用五年左右，要把拉链互动打造成为中华超过的C2B衣服品牌。

第二品级，做聪明供应链协同，把拉链互动音讯连串、供应链整合能力开放出来，供所有成长型C2B品牌免费应用。

其三品级，当行业里上百个品牌都在用这么些免费系统开展客户消息与供应链管理的时候，系统就会使用数十万客户的肢体个性大数量，举行健康后延服务，而供应链协同形成的家产互联网社群，则会大规模下降品牌商的采购资金。那几个免费系统通过智能分发海量订单，将成为真正的秉性产业成立驱动器，协同中国智能成立产业发展，最后推动所有中华工业4.0提高。

不无的愿景，从一套西装初步萌芽。