SDK之关于SDK的一些想法

先废话上几句吧。

终于开始写这一篇了。这篇是规划的SDK总结系列的最后一篇，也是比较难写的一篇了。之前以为经过了这么多的坑，再来写这个系列没那么难，规划的就比较多。真的开始写的时候发现问题还是很多，加上中间一些个人的事情耽误，陆陆续续就写了两个月了（最近有点碎碎念，发现时间过的太快了）。希望这个周可以第一次完结！

和之前规划一致，这篇文章主要是对SDK的前路的一些思考。也是自己一直在思考，感觉团队也在思考的事情。从去年开始，我们的SDK就开始进入了稳定期，不会再有太多的新功能，很大的版本。这个时候SDK的主要功能，或者所有功能都已经完成以后，基于这个SDK我们还可以做什么？这里就说一说我们现在在做和自己认为还可以做的东西吧。

技术优化

除非一开始有一个比较牛逼或者有经验的开发来设计一套有效的成熟的架构（很可惜，我觉得我们当时设计的架构并不是很好），一般SDK前期的开发时间都很紧张，而且更多的精力聚焦在功能的实现上，因此很多时候采用的都是最快的解决方案，紧工难出细活，因此时间久了就会积累一些问题。而当SDK的功能开始稳定的时候，就该是划出时间和精力来通过重构优化代码模块和一些具体的实现了。

代码重构

这部分主要是针对SDK的一些技术上的改善和优化。通过模块化和插件化，SDK的开发者和使用者都可以很大的提高开发效率。

• 模块化 将SDK代码进行重构，让SDK可以更加容易扩展，尽量减少模块之间的耦合。让各个功能模块更加独立，甚至可以做到轻松的添加和删除模块而不会对别的模块有任何影响。这种做法可以轻松应对下面两种很常见的需求：
  • 时间久了以后，SDK就会出现功能模块的上线和下线，彻底的模块化可以轻松的移除下线的模块，很方便的处理这种变化。
  • 模块的彻底独立，可以最大的程度降低多人协同开发的沟通成本。
• 插件化 模块化主要是为了方便SDK的开发者适应各种需求的变化。而插件化则更主要的是为了方便SDK的使用者。当SDK的功能越来越多带来的最直接的问题就是SDK的包也会越来越大。对于有些开发者他只接入部分SDK功能却要集成整个包其实是不合理的。 插件化就是指SDK开发者可以根据使用者需求提供接入相对应功能的差异化的SDK包，开发者可以自由动态生成SDK包来适应不同的需求。

业务配置

这部分主要是针对SDK的云端控制、业务隔离等的一些思考。通过全局限频、配置管理等模块一方面可以降低业务之间的相互影响，也更有利于SDK一些简单问题的修复。

• 后台控制 这部分主要是对于后台接口的调用的控制。包括权限控制、和全局限频等。权限控制用于控制应用对于接口访问的合法性，全局限频主要是针对每个APP，对于调用量应该给出限制。防止单个业务被攻击或者流量突然升高引起其余业务接口调用的不稳定。 这里额外补充两点点关于全局限频的。
  • 全局限频怎么做： 最简单的就是有一个地方记录调用额度，定时刷新额度，在接口调用时，每调用一次去减一。这种对于单台服务器比较容易，当分布部署以后就比较复杂，需要考虑更多的细节。 因此一般的分布部署都是通过另一种方法：分布部署必然会有负载均衡，因此根据机器的数量将应用调用总量均分到每台机器上，当对应机器的限额用完，就提示超频。
  • 全局限频怎么限 首先所有的应用会有一个预先的配额，作为预警配额，这个配额是根据应用情况预估的；其次除了预警配额还会有一个阈值的配合
• 客户端配置 云端配置是指客户端的一些开关、关键是配置值可以通过后台来修改。这样做可以：
  1. 当有业务配置错误的时候，我们可以通过云端控制修改配置，而无需业务修改版本。
     • 当某写功能出现异常的时候，可以通过云端修改配置，临时关闭相关功能。

数据上报

• 关键日志 关键日志上报同样是为了SDK的开发方便问题定位。主要用在以下场景：
  • 当游戏客户端遇到问题的时候，打开指定用户的日志控制开关，他就可以把本地日志远程上传。协助开发者分析错误，定位问题。
  • 对于业务逻辑下的某些异常逻辑增加关键日志自动上报，就可以协助开发者提前发现和定位解决问题，不再被动。
• 数据上报 数据上报的意义更加重大了，尤其是当数据上报和关键日志、云端配置配合，就是客户端问题定位的神器。这个地方的数据上报不包括一些接口调用数据等正常数据的上报。 通过异常数据的实时上报，我们可以：
  • 建立一套客户端的监控和告警机制，实时了解客户端版本情况。当某一接口异常的时候，提前开启关键日志分析问题。
  • 除了解决问题，客户端的异常上报如果包含了后台接口的返回异常，就可以同时监控后台接口的稳定性，尤其是当后台接口的监控和告警不可信的时候，可以及时通知后台。（别不信，现实中这种情况太多太多）

安全性

网络请求、配置、DB数据存储等，采用更高效、更安全的处理措施。具体的例如：

1. 网络请求 可以使用https，既可以提高安全性，还可以防止国内运营商常见的DNS劫持等问题。
2. 配置、DB数据存储
   • SDK的配置、SDK相关的数据以及用户数据都是SDK的核心内容，一定要使用有效的加密方案来保存。对于加密以后带来的性能问题可以通过尽可能少的加解密次数以及不同级别的加密算法等来解决。
   • 加解密的密钥以及加解密的算法的本身的安全性也要保证，建议是直接放在SO，然后再通过SO的加固增强安全性。
   • 所有的加密行为最终使用的加密密钥最好时和设备相关，防止因为用户手机被恶意程序攻击远程拷走应用私有目录的信息以后带来问题。而因为imei和mac地址的不唯一，建议加密时不要简单的使用imei或者mac地址。

稳定性

这部分主要包括：

1. SDK的质量保证
2. SDK遇到问题时候如何快速解决问题。

具体的做法可以有：

• SDK的各种测试：这部分主要是针对SDK的版本，除了常规的SDK的功能测试，兼容性测试以外，建议可以通过自动化测试、性能测试、以及后台配合的异常测试对SDK的版本进行更加全面完备的测试。
• 使用Coverity或者FindBugs之类的代码静态扫描工具每日或者每次提交都进行代码扫描，尽可能降低一些可以遇见的编码错误。
• SDK自身的热更新：SDK的热更新主要是为了解决SDK遇到问题时自身的bug修复，因为如果通过正常的版本发布，SDK的线上紧急bug的修复成本就会很高。SDK的热更新包括Java代码和Native的代码的热更新，通过后台的下发策略，保证当线上的SDK版本遇到问题的时候，可以通过后台直接下发更新包，尽可能的减小影响范围以及问题的修复成本。

增值服务

上面讲的都是当SDK的基础功能开发结束以后，技术侧还能做什么。当技术相关的优化工作都做完的时候，还能继续做什么呢？下面主要是从非技术的角度进一步分析一下：

分级服务

分级服务是指对与接入SDK的业务进行分级支持（当然如果你的人力充足，完全不用分级）。分级服务的原因就是给开发者提供更多有利于他开发的支持。比如：

• SDK详细介绍
• SDK的接入教程，甚至是视频的，图文的等。
• 面对面的联调支持
• 一般的游戏开发者都只熟悉引擎，不熟悉Android系统，所以协助游戏解决一些他们遇到的系统相关的问题等
• 熟悉开发者常用的框架或者工具，了解SDK与这些框架和工具结合的时候会有哪些问题，怎么解决

对于这部分工作，个人其实是比较有争议的，虽然我也认同SDK发展到最后就是提供服务，就是做服务。但是应该有一个红线或者一个度在里面。我们应该是尽最大的努力做好份内的事，而不死越俎代庖去协助开发者解决开发者开发中遇到的问题。

数据运营

这部分内容主要说一下SDK相关的数据分析和数据挖掘相关的内容。这部分内容本来计划用一篇文章来规划说明的，竟然忘了。那就简单汇总一下添加到这里吧。

SDK的数据有哪些

1. 接口调用数据 接口调用数据，包括接口调用的成功率，失败率，调用次数等。这部分主要用来监控接口的稳定性，及时的发现问题。另一方面这些数据也是SDK的品牌数据，用于进行数据推广等。

• 开发者、接入应用相关数据。 开发者和应用相关的数据包括，开发者的地域分布、接入应用的类型、单开发者接入应用的数量等等。这部分数据有助于了解当前开发者的活跃地带，为商务提供支持，了解目前的接入应用的分布，可以了解应用市场的走向。
• SDK的使用习惯数据。 SDK的使用习惯数据包括某个功能开发者一般用来做什么等，例如SDK面向用户的公告，开发者一般用来发公告还是活动，一般同一时间内有效的会有几条，发送的频率一般是多久等。这部分数据可以协助新的开发者更有经验的使用SDK的相关功能，同时将SDK的功能最大化。
• SDK的用户数据。 用户数据内容比较多，再细分一下，包括用户个人数据，用户设备数据，用户使用习惯数据、用户和应用的相关性数据。
  • 用户个人数据，包括用户的地域分布、性别、职业等。这部分数据用于制作用户画像，让运营更加了解用户的实际情况。
  • 用户设备数据，包括用户设备的机型、系统、系统版本、内存、CPU、网络、分辨率、DPI、传感器等数据。这部分可以让开发者们更了解当前使用者的设备情况，更好的做兼容和后续方向的规划。
  • 用户的使用习惯数据，包括使用时段、使用时长、打开次数、打开频率、留存、活跃等数据。通过这部分数据，可以让运营更加了解用户的使用习惯，更容易掌握推广的时机。
  • 用户应用的相关性数据。包括单一用户手机上同类型APP的安装数量，每天的使用APP的数量等数据。这部分数据对于市场的开拓会有很大的效果。

在大数据的时候，数据的拥有者是大有可为的，基于SDK的数据分析，可以为SDK的开发者，SDK的使用者提供更多的基于数据分析的运营、开发、决策等建议。然而这部分缺又是最容易忽略的。

另外做大数据的前提是，SDK的接入量要足够多，使用用户要足够大，这是一个持续而且旷日持久、前人栽树，后人乘凉的过程。