本文是 本系列的 最重要的 一篇，因为本文尝试着去揭示SDK本身的 工作内容，为什么要理解 SDK 的工作内容呢？因为SDK提供给开发者的是API接口函数，我们只是会简单的使用 这些API接口， 但是这些API接口的相关资料只有寥寥几句话， 相关的技术文档也非常少，作者的出发点可能是开发者快速的进行应用开发，不需要了解SDK本身的任何 实现机制，但是个人觉得，如果完全不了解 SDK的工作原理，想要写出很 稳定、靠谱的应用程序也是很难的，要么需要多次试错、出现问题了，进行黑盒测试，瞎猜，而如果我们了解了 源码的 基本功能，我们就能对 这些API接口理解的更加深刻，对于SDK的工作机制也能理解的更加深刻，毕竟SDK 是我们的应用程序的一部分，他是一个外来者，我们不了解这个外来者，我们的程序整体的稳定也是很难保证的，举一个最简单的例子，有可能我们费了很大的心思 为了实现 程序挂掉 重新连接的功能，SDK本身就已经具备了。
在前面的文章 IOT_Linkkit_Connect 分析中，该函数除了做 各种资源初始化、底层HAL接口绑定、向服务器 发起 连接外， 还有一项特别重要的功能，就是 创建用于SDK 本身守护、 功能调度的 线程。具体代码如下：
int iotx_cm_connect(int fd, uint32_t timeout)
{
.......
.......
.......
/* 连接服务器初始化、连接服务器 */
ret = connect_func(timeout);
.......
.......
.......
/* 创建 SDK 的功能 守护、调度线程 */
ret = HAL_ThreadCreate(&yield_thread, _iotx_cm_yield_thread_func, NULL,
&task_parms, &stack_used);
......
......
......
return ret;
}
这里我 把 _iotx_cm_yield_thread_func 理解成 SDK 本身的 功能守护、调度线程。
所谓“守护”就是 该线程 监控SDK本身，尤其是 云服务器连接状态守护，循环监测云服务器连接状态，一旦监测到 与服务器断开，则重新发起连接，重新连接成功后，再发起 设备的注册、连接、登录。还有就是SDK的功能模块守护，保证各功能模块工作异常时能恢复。
所谓“功能调度”就是 该线程 还会进行 所有功能的 调度，比如属性、异常的上报，有各种“事件”发生，触发 事件回调函数。
接下来，我们还是看一下该 守护线程的 源码逻辑，如下图所示：
这里跟 开发者相关的可能就是 SDK的 断开重连机制了，我们知道 SDK 支持
- ITE_DISCONNECTED 事件，该事件为 “服务器断开”事件，当与服务器断开时，SDK会自动的 调度，触发 该事件，那么是不是需要我们在 服务器断开事件 回调函数中再重新 调用 IOT_Linkkit_Connect 函数，发起服务器连接，然后 添加 子设备呢？答案是：否。
因为SDK本身会立刻会 向 服务器 发起重新连接， 如果这个时候断网了，SDK 会一直不停的 尝试重新连接服务器，直至网络 恢复，这就使得 SDK 能够一直稳定的 联网运行。而且 网络恢复，连接成功后，SDK还会重新 启动 网关主设备和 子设备的登录，我们不需要再添加子设备了。
那么 “服务器断开”事件 回调函数 中要做什么呢？ 这个就要从整个 程序考虑了，最基本的就是，当我们已经发现服务器已经断开了，我们就不要再犯二的 进行各种 与云服务器的交互了，比如上报属性到云服务器，因为这个时候，SDK会自动发起服务器连接，我们再与服务器进行 交互，只能添乱。所以，SDK提供的案例中，做了一个很好的示范，服务器断开事件 会触发 一个 断开标志，我们所有的与云服务器的交互 的前提都是 与 这个断开标志位0，也就是 在线状态。
最后，再说一句，我们在编写 HAL接口函数时，尤其TCP的连接、断开、读、写， 一定严格的按照 规定的返回类型值进行编写，因为SDK就是根据这些函数的 返回值来判断 联网、读、写等状态的，千万不要图简单，全都回复一样的返回值，那样就会使程序及其的不稳定，因为SDK 也会蒙圈的。
