这是SDK系列的倒数第二篇,其实应该是第一篇来着。最近发现写了两个月还没写完,进度有点慢,这几天抓紧时间写完。不过随即发现当时完全没想错,这部分还是最难写。先写一个成稿,后续想到更多的内容逐步补充和更新吧。
SDK即软件开发工具包(外语首字母缩写:SDK、外语全称:Software Development Kit)一般都是一些被软件工程师用于为特定的软件包、软件框架、硬件平台、操作系统等建立应用软件的开发工具的集合。
上面这是百度百科对SDK的定义。但是现实中我们开发的SDK更多的是Second Development Kit,我认为这类SDK其实就是把每个应用接入相同功能都要做一遍的工作抽离出来,然后提供给别人使用的公共组件。他最大的价值都是代码复用和降低工作的复杂度、理解成本。
上面的四个原因是个人总结的比较重要的原因吧,当上面的几个或者条件具备了,一般开发者或者团队就会不自觉的把一些公共的模块慢慢抽离出来,时间久了,就变成了SDK。来源于开发并最终服务于开发。
SDK跟一般的程序或者软件相比,还是有一些不同点,个人总结了几个开发过程中体会比较深刻的:
这里的文档包括商业接入流程、接入指引、架构介绍、更新方法、API说明、测试报告、常见问题、版本历史、接入验证方法或验证工具等。这些,具体的可以参考之前专门写的文章:SDK开发经验之文档,这里会有很具体详细的说明。
SDK的核心内容,提供给开发者的API包。
关于Demo我也专门有写文档来说明。仅仅通过他人的口述、视频、文档往往无法完整的了解到SDK的接口的所有的作用,好比盲人摸象,你对它的认知、印象、经验将完完全全从他人所提供的教程中继承而来。而Demo能够全面地介绍出它所包含的所有内容,能够辅助你学习如何“使用”它。具体的关于Demo可以参考之前的文档:SDK开发经验之Demo。
任何SDK都是一个持续的存在,是一个接一个的迭代的,因此从一开始就应该有版本来对每个对外发布的内容作标示。还别不信,现实开发中还真的有遇到没有版本概念的SDK,当时的震惊无法用语言形容啊。关于版本之前也专门写文档说过,具体的可以参考:SDK开发经验之版本和SDK设计心得之版本号。里面对于版本和版本号都有比较深入的分析。
SDK的开发者和使用者之间的信息其实是不对称的,开发者无法得到使用者关于使用方法的反馈。使用者无法及时知道SDK的变化,包括文档、版本等。如果SDK自身有一套面向开发者的公告系统。例如邮箱(其实不是好办法)、微信公共号、wiki上的公告等可以及时告知开发者版本发布、最新bug、通用问题解决方案等问题,都是一种很不错的选择。
当然如果只有客户端的话,其实沙箱的存在没那么重要,如果有后台的话沙箱就很重要了。可以方便开发者模拟请求,验证参数等。
技术支持主要用于接入的联调。有时候开发者会遇到一些无法通过文档、demo等解决的问题,技术支持将是一条很有效的方式,一般通过QQ群、企业QQ等对接会比较好。但是切记,如果文档、demo、公告等这些基础设备都不完善的话,技术支持的人迎来的只有噩梦。
监控和告警主要是为SDK开发者自身服务的,一方面通过监控和告警可以了解游戏的版本、接口调用量、接口失败率等数据,另一方面可以尽早的发现问题,比业务更快的响应。想想你通过监控了解到开发者的版本存在什么问题,然后在他还没有发现问题的时候就找到他告诉他你哪里有问题,要怎么改,他将是一种怎样的赶脚也表情。
这部分其实偏向于数据分析了,主要两个功能吧,一个是做大数据,做进一步的数据分析和挖掘。另一个就是做SDK的品牌数据,逢人就吹你怎么怎么牛逼,怎么吹,就靠这个。
关于SDK开发中遇到的问题,说实话实在太多了,多的无法说完!!!!所以最终下定决心汇总这整整一个系列来总结。这里就对一些共性的说明一下: