SDK开发心得

入职新公司后，处于公司需要，从原来一个Android应用开发人员，转变为一个SDK开发人员，个人看来两者的差别并不大，一个有界面，一个没有。但到了实际开发中，磕磕绊绊的，好的是折腾了过来，总结一点修改过的和想去修改的经验。

一、SDK初次开发的磕磕绊绊

第一个是开发一个类似QQ、微博那样的第三方登录系统，以OAuth2.0原理进行开发，等二个是支付类型的（游戏币），第三个应用数据统计类型的。都是独立开发。下面是自己碰到的一些问题。

1.支付接口的全面更改

发生在要测试的前两天，负责SDK审核的同事提出意见，现有的支付接口过于复杂，必须简化，以便开发者使用能有更好的体验。看接口：
一期接口使用：

//1.初始化，并设置回调接口.setCallBack(new MyPaySdkCallBack());//2.进行商户验证.merchantVerification(this);//3.获取余额，就是查询余额是否足够支付.getBalance(num);//4.进行下单.payOrder(order);//5.获取上面下单接口中的一个关键参数，然后调用支付接口.pay(key);

从上面的接口可以看出，如果进行一个支付的话，需要做的工作是很多的，根据SDK审核同时的意见，进行了如下的修改：

正式的接口形式：

pay(mOrder,new MyPaySdkCallBack(){        @Override        public void callback(String code, String msg) {            //支付成功的回调        }        @Override        public void exceptionCallBack(String msg) {            //异常信息的回调        }    });

接口从多个整合为一个，把初始化，查询余额，下单到支付整合到一个接口中，提升了使用的便捷性，方便开发者快速集成并使用。这里可能有会有人问，把多个接口合并成一个接口，会损失稳定性么？ 个人认为，即便是多个接口分开，由开发者自己调用，其实他的稳定性和我的接口的稳定性是一样的，而从对接口的熟悉程度来说，由我统一进行调用反而稳定性更高，对多种情况进行统一处理反馈给开发者，规避了接口的复杂度对稳定性的影响。

2.单个接口多个同类型参数

开发中，有一个接口是需要传入用户的参数，比如手机号、昵称、性别等等，都是以字符串进行出入的，一开始开发的时候，使用单个接口传入，造成了一个问题：

bindUser(String phone,String userID,String age,...)

传输数据是没有什么问题，但是后台进行数据统计的时候，发现好多数据是错乱的，相对应的位置信息不对。之后才发现，一个接口中，多个同类型的参数传入，很可能造成填写的信息位置错误，导致信息统计出错。
之后，是在接口端进行修改，使用JavaBean进行存储大量的同类型数据：

//创建用户的信息类UserInfo user = new  UserInfo();user.setPhone(phoneNumber);user.setAge(18);...//将用户的bean传入接口bindUser(user);...

在这种方式使用后，减少了很大一部分数据错乱的问题。

3.输入参数的校验

初次开发中，碰到了这个问题，好多请求无效的流程，大概有百分之三十是因为没有进行初次校验，并不会引起Crash，但是如果当前参数是无效的，为什么还要让它继续走下面的流程，不管从程序的完整性还是性能上，都应该进行相应的处理。
自己碰到的常见问题：

1. 字符串为空或null
2. 对象为null
3. 数据格式错误，如日期类
4. 后台接口的数据格式和开发者传入的数据格式不符，如String转int等类型的转换
5. SDK本身自动获取参数的类型

4.异常信息的统一

支付的SDK因为要用到公司的账户体系，所以要和登陆授权的SDK进行关联，此时出现了一个小问题，就是两个SDK的后台开发是由两个人独立进行的，所以在返回的异常信息方面，存在部分差异。一个是code（如：10003）值加上对应的Message，一个是大写的字符串码（APPID_NOT_EXIST）加对应的Message。

如果直接把信息返回给开发者的话，会造成处理混乱，开发者不知道一场信息来源是那一块儿，所以SDK内部，对两部分的异常信息进行提前处理，给开发者返回统一的定义明确的信息。

5.部分参数是否透露给开发者

在开发登陆授权的SDK时，会有授权的token，openid（依据OAuth2.0）传回，供开发者后续调用OpenAPI。这样，开发者就必须在自己的业务逻辑范围外，进行以上数据的保存和使用，无形中增加了开发的难度，再加上token等值是有时效的，一旦过期就必须另行申请，这又需要开发者进行时间逻辑上的判断，无形中提高了本身业务的复杂度，稳定度也有所下降。
所以，在后续的修改中，把开发者不需要知道的且和业务逻辑无关的参数，都在SDK内部进行保存和处理，开发者只需关心自身的业务逻辑即可。

6.性能方面的问题

1.SDK在主线程只进行简单操作，除非必须，不适用主线程
2.SDK最好有一个专门的线程，处理SDK内部的业务逻辑
3.所有的耗时操作，如I/O、DB、网络请求等全部放到子线程
4.线程间通信使用Handler
主要目的是：尽量减少SDK对应用本身的影响，如Crash或者ANR等问题。

7.稳定性

对传入的数据进行校验，健全代码机制，容错判断，还有对可能的异常进行catch，较少Crash或其他异常问题对应用本身的影响。

8.回调的简和繁

简单来说：
1.同一个回调里面的接口进行可能的少，个人认为1~2个就好
2.不同模块之间最好是有单独的回调

二、总结

看了其他的博客，总结一下SDK设计开发的特点：

1.易用性

那么所谓的易用到底是什么呢？我们想创造一种最简单的方式，让人们在他们的应用中开始使用SDK. 如果它是易用的，它应该是不需要侵入太多你的代码或者你需要做很多繁琐的集成工作。

1.1 简单意义明确切易于拓展API
如下：

Login.login(callback)

让开发者一眼就看到这个接口的意义，是用来登陆的，省了去翻阅集成文档的时间，降低了开发者的开发成本。同时，API也应该是稳定的，因此奥在设计之初就想好后续的SDK拓展和更新，包括功能性拓展和接口性拓展。
同时，多个模块的接口调用方式应该是趋于一致的，或者尽量的做到一致，不要一个在接口中传入callback用于，而在另一个模块需要在其他地方进行监听。

1.2 接口参数意义明确
就不如上面例举的错误里，单个接口多个同类型的参数，这个很容易造成参数传递错误，所以要做好对应的处理方式，可以避免一些错误。

1.3 Callback
回调进行可能的根据模块进行区分，而且每个回调中的接口务必少。如：

  mLogin.login(new Callback() {    @Override    public void loginCallback(boolean isSuccess, String reason) {     //to do Someting...    } });

1.4 及时的文档更新
SDK的更新通常都通过网站更新信息和集成文档来体现，所以，集成文档的及时更新非常重要。

2.稳定性

从 SDK 使用者角度来说，在 SDK 使用过程中，我们假设 SDK 本身是可靠的，不会影响到程序本身的稳定性。那么，从 SDK 设计者的角度来说，SDK 作为第三方服务，其稳定性是尤为重要的。包括，API稳定，业务稳定，SDK运行时的稳定性，版本迭代的稳定性。

1.自己的代码不会出现Crash
2.SDK内部产生的问题，不能影响开发者应用的业务逻辑
3.对于开发者传入参数等问题，及早做出提示并终端SDK内部业务流程
4.SDK内部，尽量在子线程中进行操作，尤其是一些耗时操作（网络请求、DB读取等），UI线程中只进行少量操作
5.如果数据量大，减少网络请求的次数，数据多批次存储少批次发送，减少耗电量
6.对内存和CPU占用尽可能的低，避免内存抖动
7.注意对Activity的应用，避免内存泄露

3.轻量&拓展

这块引入别人的话：

1.用户不太可能下载大的应用程序，这意味着安装包的大小是一个关键内容
2.伟大的第三方库，可以真正给予贡献于你的应用程序，但当涉及到 size 规模和影响时，他们会显得不自由
3.作为一个 SDK 你应该努力平衡你的尺寸与功能。因此，要注意引入第三方库，以确保它们只满足所需的内容。
4.积极地监控每个 build，使我们能够衡量的真实影响开发者的 APK 大小情况。没有硬性和快速的规则来解决大小增加，但一直关注它显然是有帮助的。

我们在给予开发者轻量易用的API时，还应该给一定的可定制性，比如一些额外的设置，监听开始和结束等，满足不同的开发者需求。

5.其他

1，SDK的开发，尤其是初期，设计到客户的需求，开源还是闭源，需要和公司相关同事进行沟通协商
2.相关类是公共还是私有的，访问级别需要严格控制。
3.尽量少的权限

这篇博客引用了多个SDK设计的相关文章，参考如下：

1.如何站在使用者角度来设计SDK
1.Fabric SDK 的创建经验
3.SDK设计心得之接口设计
4.Android SDK 开发（第一部分）