一、定义

SDK：软件开发工具包（外语首字母缩写：SDK、外语全称：SoftwareDevelopmentKit）一般都是一些软件工程师为特定的软件包、软件框架、硬件平台、操作系统等建立应用软件时的开发工具的集合，又称api。

我常在想什么样的SDK才是一个好的SDK呢？

_框架独立性

_可扩展性

_可复用性

_可测试

_UI独立性

_代码清晰简洁

_清晰可用的文档

_清晰可用的示例代码

_一个调用完整的Demo

我想一个SDK 应具备以上9个基本的设计原则。

二、设计

为了达到上述的设计原则，初步构思后：

2-1 框架独立性

    首先想要sdk的低耦合，那么最直接的就是框架的独立性。框架的独立性可以根据自身的业务进行分析拆分，这里我做了简单的拆分：

  · 基础工具组件化

        这里一般包括所有业务模块的公共类库，比如网络层、工具层、组件路由通信层等等。（需要特别说明组件路由通信层 本文只是为了解决有特殊需求需要两个独立组件通信的问题，具体组件化可以参照  阿里组件化、得到组件化、总李写代码组件化等方案）对应代码库就是NetLib、ToolsLib、RouterLib三个独立的库，三个类库可以有关联，此基础公共库定位核心基础包，当然你也可以有自己的UI逻辑库等等。

    ·业务功能组件化

        根据业务功能规划对应的组件，具体拆分为：支付、充值、提现、转账、红包等。他们分别对用独立支付、独立提现、独立转账、充值提现组合（银行卡充值账户余额后可购买增值服务、理财等等、属于单独通道与对外支付不同）、支付提现红包组合等，可根据需求组合。

    ·主壳工程

        这里一般就是主页面，功能入口、调用发起者，SDK 一般作为Demo App。   

2-2 代码结构

    确定完最外层的架构思想后，那么就轮到设计每一个模块该如何设计分层逻辑，如MVC，MVVM，MVP 等等这些大家耳熟能详的分层思想，这些都可以，分析团队、项目、周期确定一个符合的模式后开始对每一个组件进行编写，但无论是哪种方式sdk都应该拥有对应的功能入口、出口，且想达到可扩展性、可复用性、可测试性的代码就必须面向接口编程。

    ·入口&出口

        1.单一的入口包／类，便于代码后期的混淆～原则上，只有此包（此包下的子包、类）是对外开放的

        2.Builder模式的使用，它可以更自由的扩展你的项目（入口类）

        3.设计统一的回调接口，做模块、页面、功能等回调处理～（一般可以使用eventbus）

    ·面向接口编程

        1.功能的诞生不论未来是否一定会扩展，但是一定要做好要扩展的可能，所以定义接口和抽象类是必须的

        2.善于利用设计模式，比如SDK的 Builder模式、工厂方法模式、观察者模式、外观模式等等

    ·面向业务功能编程

       什么面向业务功能编程呢？记得刚写代码那会，总是会把代码功能放到一起，比如UI、Net、Tools、DB，常见的就是一个activity包下边包含了所有UI的页面，随着项目的迭代你会发现乱七八糟，可读性差，分离业务困难，后来寅生到了模块化、组件化。所以我建议无论是模块化的开发还是组件化的开发都应该针对业务进行，有多少业务就有多少模块（或组件），这样不论是以后的扩展、删除都比较容易，当然如果是模块化你的模块资源也需要模块化，组件化本身就是独立的module所以只需要解决通信问题就可以了。

    ·面向组件化编程（部分Router跳转通信，注意导出风险需添加权限）

       这里提议使用组件化编程，这样大大降低了团队开发规范不严格的问题，把每一个业务都当作一个独立的项目编写，这样从根源上就做到业务分离，哪怕内部代码写的很烂，但是上层业务依旧是分离的，这样我们可以把各个组件组合成不同的SDK给你用户。涉及到组件之间通信的问题大家可以看看AutoRegister、ARouter。

    ·注释文档简单清晰

        作为一个SDK，文档非常重要，非常重要，非常重要～不然客户会觉得你们的服务很垃圾！！！       

        简单清晰是第一要素，越简单越好，如果可以不需要代码最好。

        前文说的入口包/类 就是你写文档的参照，有多少个外部调用功能就有多少个文档类/方法说明