SDK之我理解的SDK
这是SDK系列的倒数第二篇，其实应该是第一篇来着。最近发现写了两个月还没写完，进度有点慢，这几天抓紧时间写完。不过随即发现当时完全没想错，这部分还是最难写。先写一个成稿，后续想到更多的内容逐步补充和更新吧。
什么是SDK
SDK即软件开发工具包（外语首字母缩写：SDK、外语全称：Software Development Kit）一般都是一些被软件工程师用于为特定的软件包、软件框架、硬件平台、操作系统等建立应用软件的开发工具的集合。
?上面这是百度百科对SDK的定义。但是现实中我们开发的SDK更多的是Second Development Kit，我认为这类SDK其实就是把每个应用接入相同功能都要做一遍的工作抽离出来，然后提供给别人使用的公共组件。他最大的价值都是代码复用和降低工作的复杂度、理解成本。
为什么要做SDK
- 批量开发 原谅我用一个这么low的词。如果没有批量开发，就不会有大量的重复性的工作。就是因为批量开发一批类似的东西，所以才会有相同的功能要重复开发。
- 程序猿懒 首先，这里的懒不是贬义词哈。换我也是一样，开发中如果遇到以前开发过并且一样的功能，我也不会傻傻的再去研究一边，再去分析一遍，效率太低了，肯定是用现成的。这里某种程度上也不是因为懒，是为了提高效率。
- 代码复用 既然已经有成熟的方案，为什么还要重复的造轮子。尤其是有些轮子早起来还没那么容易。代码复用这是软件开发和设计中一个很重要的原则。尤其是像SDK这种很多地方都是完全一致的逻辑。
- 提高效率 通过SDK的各种封装，可以有效的屏蔽第三方或者具体的功能实现，降低开发者对功能理解的成本，提高接入效率。
上面的四个原因是个人总结的比较重要的原因吧，当上面的几个或者条件具备了，一般开发者或者团队就会不自觉的把一些公共的模块慢慢抽离出来，时间久了，就变成了SDK。来源于开发并最终服务于开发。
SDK的一些特性
SDK跟一般的程序或者软件相比，还是有一些不同点，个人总结了几个开发过程中体会比较深刻的：
- 使用对象：开发者，程序员。这是一群充满奇特思想，充满创造力的人群，你永远不知道他们怎么用你提供的sdk。
- 使用时间：一旦发布，只要在这个发布包里，任何东西都会影响到别人。而且鬼知道什么人会在什么时候用，你至少要维护比较长的时间。
- 发布节奏：虽然现在提倡敏捷开发，但是版本迭代的节奏还是不要太快。让开发者升级SDK是一件很痛苦的事，虽然很多时候成本并不高。
SDK应该有哪些内容
文档
这里的文档包括商业接入流程、接入指引、架构介绍、更新方法、API说明、测试报告、常见问题、版本历史、接入验证方法或验证工具等。这些，具体的可以参考之前专门写的文章：SDK开发经验之文档，这里会有很具体详细的说明。
api
SDK的核心内容，提供给开发者的API包。
Demo
关于Demo我也专门有写文档来说明。仅仅通过他人的口述、视频、文档往往无法完整的了解到SDK的接口的所有的作用，好比盲人摸象，你对它的认知、印象、经验将完完全全从他人所提供的教程中继承而来。而Demo能够全面地介绍出它所包含的所有内容，能够辅助你学习如何“使用”它。具体的关于Demo可以参考之前的文档：SDK开发经验之Demo。
版本
任何SDK都是一个持续的存在，是一个接一个的迭代的，因此从一开始就应该有版本来对每个对外发布的内容作标示。还别不信，现实开发中还真的有遇到没有版本概念的SDK，当时的震惊无法用语言形容啊。关于版本之前也专门写文档说过，具体的可以参考：SDK开发经验之版本和SDK设计心得之版本号。里面对于版本和版本号都有比较深入的分析。
公告
SDK的开发者和使用者之间的信息其实是不对称的，开发者无法得到使用者关于使用方法的反馈。使用者无法及时知道SDK的变化，包括文档、版本等。如果SDK自身有一套面向开发者的公告系统。例如邮箱（其实不是好办法）、微信公共号、wiki上的公告等可以及时告知开发者版本发布、最新bug、通用问题解决方案等问题，都是一种很不错的选择。
沙箱
当然如果只有客户端的话，其实沙箱的存在没那么重要，如果有后台的话沙箱就很重要了。可以方便开发者模拟请求，验证参数等。
技术支持
技术支持主要用于接入的联调。有时候开发者会遇到一些无法通过文档、demo等解决的问题，技术支持将是一条很有效的方式，一般通过QQ群、企业QQ等对接会比较好。但是切记，如果文档、demo、公告等这些基础设备都不完善的话，技术支持的人迎来的只有噩梦。
监控、告警
监控和告警主要是为SDK开发者自身服务的，一方面通过监控和告警可以了解游戏的版本、接口调用量、接口失败率等数据，另一方面可以尽早的发现问题，比业务更快的响应。想想你通过监控了解到开发者的版本存在什么问题，然后在他还没有发现问题的时候就找到他告诉他你哪里有问题，要怎么改，他将是一种怎样的赶脚也表情。
数据视图
这部分其实偏向于数据分析了，主要两个功能吧，一个是做大数据，做进一步的数据分析和挖掘。另一个就是做SDK的品牌数据，逢人就吹你怎么怎么牛逼，怎么吹，就靠这个。
SDK开发遇到的一些问题
关于SDK开发中遇到的问题，说实话实在太多了，多的无法说完！！！！所以最终下定决心汇总这整整一个系列来总结。这里就对一些共性的说明一下：
- SDK的开发者和使用者之间的信息同步和沟通。 这是我认为开发过程中遇到比较多的问题，我们经常做一个东西有多个方案，但是不知道那种方法对使用者更方便，结果经常用了我们并不方便不过以为使用者很方便但是最后证明对他们反而更麻烦的方案。建立开发者和使用者之间的沟通机制真的很有必要。
- SDK使用者之间的相互交流 SDK的开发者更多的关注于SDK的开发，使用者更多的关注于SDK的使用。尤其是对于游戏开发，使用相同的引擎的游戏开发肯定比SDK的开发更了解一些开发中的问题怎么解决。很多时候联调中会遇到有些之前已经有游戏开发者遇到并且已经解决的问题，又有开发者来问，但是我们因为可能涉及游戏引擎等我们并不熟悉的问题解决会比较吃力。如果开发者之间可以交流就可以很简单的解决这个问题。 当时初衷想建立一个开发者的社区，后来考虑到别最后变成猎头的天堂而引来合作伙伴的不满而最终没有实现。说实话如果有个社区，会好很多。不管是开发者之间还是SDK的开发和使用者之间的交流都会很顺畅。
- 不用数据说话，拍脑袋订标准。 这个是属于内部问题了。经常增加功能或者添加一些限制条件的时候大家不是根据数据统计去分析一个合理的值，而是直接根据自己的经验拍脑袋订一个。说实话个人觉得虽然我们也是用户，但是我们和真正的用户的差距还是挺大的，通过拍脑袋订的很多方案或者数据并不一定合适。 开发中完全可以先发一个版本出去，增加一个数据上报点，收集一些数据回来通过数据分析给出一个合理的，有意义的参考值。这个过程的工作量不会大很多，但是会科学很多。