SDK全称 Software Development Kit，广义上的 SDK 是为特定的软件包、软件框架、硬件平台、操作系统等建立应用程序时所使用的开发工具的集合，狭义上的 SDK 则是基于系统 SDK 进行开发包装的、新的、独立的、能够完成特定功能并返回相关数据的一组工具的集合。
插件(Plug-in,又称addin、add-in、addon或add-on,又译外挂)是一种遵循一定规范的应用程序接口编写出来的程序。其只能运行在程序规定的系统平台下（可能同时支持多个平台），而不能脱离指定的平台单独运行。因为插件需要调用原纯净系统提供的函数库或者数据。很多软件都有插件，插件有无数种。
sdk可以看做插件的集合；
推荐一个BLE蓝牙研究的库，正在做该方面的或者有兴趣的可以看下。
Android BLE蓝牙框架，包括扫描、连接、设置通知、发送数据、读取和接收数据以及各种直观的回调，近乎一行代码植入项目，可扩展配置蓝牙相关操作。
https://github.com/Alex-Jerry/BleDemo
http://www.jianshu.com/p/d70e22ce61bc
本文作者
作者：brucevanfdm
链接：
http://www.jianshu.com/p/8f39919cd4e5
本文由作者授权发布。
1
前言
最近由于工作需要，将应用里的部分功能独立了出来，封装成 SDK 提供给合作伙伴使用。由于经验不足，网上也没多少写这方面内容的文章，遇到了不少的坑，决定记录下来。
其实，刚说到要写SDK也有点慌，印象中SDK一直是个复杂的东西，脑海中浮现的是Java SDK ,Android SDK这类庞然大物。
SDK全称 Software Development Kit，广义上的 SDK 是为特定的软件包、软件框架、硬件平台、操作系统等建立应用程序时所使用的开发工具的集合，狭义上的 SDK 则是基于系统 SDK 进行开发包装的、新的、独立的、能够完成特定功能并返回相关数据的一组工具的集合。
听起来一愣一愣的，其实，将一些业务逻辑独立出来，打包成jar、so、aar，暴露一些APIs给外部调用，也可以称为SDK。如推送SDK，支付SDK，地图SDK...既然是所谓的集合，那么自然有大有小。
下面说说我在封装SDK与使用的时候遇到的那些事，希望对大家有些帮助吧！
2
二次打包aar
大多时候，我们的业务依赖于第三方库，载体可能为jar、so、aar，如果是jar包那好办，直接丢进libs目录下就可以了；so库就不简单了，不少开发商只提供少数abi的so库，这时就需要根据需求选择了，要么全部一份，要么只保留一个目录，否则就会报错；aar则是包含了代码、资源（图片、布局等）、so库等的集合。
那么需求来了，如何将第三方aar包二次封装，加入自己的业务逻辑再打包成一个aar呢？其实这个问题我也没有找到直接的解决方案，如果你有，请联系我，感激不尽！但是这个问题又是可以曲线解决的，aar其实就是个压缩包而已，如下图所示：
Android Studio导入aar时也是将其视为一个module(library)，使用其中的classes以及其他资源文件，那我们可不可以直接将其解压，直接导入？
这样就避免了在aar的基础上封装成aar！跳过这个坑？实践证明确实是可以的。如果你要封装的aar只包含了jar包和so库，那就简单了，解压出来分别导入项目相关目录即可！不然可能就要手动合并某些资源了...更新：详情请看 二次打包（封装）AAR实用指南
http://www.jianshu.com/p/3bad128bd106
还是期待谷歌能给出一个傻瓜式的一键合并方案吧！
3
SDK中Application对象的初始化
有次SDK接入方反馈说某个地方崩溃了，一看Log，是调用Application对象中的方法空指针了。我一想，混淆？不是。导入姿势不对？不是。文档没认真看？也不是？Demo可以正常运行啊......随即想到是接入方自定义Application对象的问题。
如果aar中定义了Application，theme，icon，那么编译时就要抛出如下异常：
-编译错误AndroidManifest合并异常-
由于项目与aar都定义了自己的Application，编译器不知道用谁的，这就产生了上图的异常，按照提示，在Application标签下添加如下代码：
tools:replace="android:name"
合并方案可以参考官方文档:合并多个清单文件| Android Studio - Android Developers
https://developer.android.com/studio/build/manifest-merge.html?hl=zh-cn
理虽如此，但是你很大概率就掉坑了，这个方案直接将SDK中的Application对象替换为你的，换句话说就是SDK中的Application对象根本没有初始化，这就是上文说的空指针的罪魁祸首了！
确实之前在写文档的时候没有考虑到自定义Application的情况，还是经验不足啊！甚至一度将Application里初始化的方法全部移出来，后来转念一想，让接入方继承我的Application不就OK了吗！！测试一波，赶紧更新下文档，不然又被吐槽了...这下理解为什么接入某些第三方SDK时，有的会要求继承SDK里定义的Application对象。
4
Application多继承
作为一个SDK提供方，假如你的SDK需要用户继承你的Application，我觉得应当提供一个Application多继承的解决方案，毕竟用户可能不仅仅只用你一个SDK，当有多个SDK有这个需求时就尴尬了。
java 多继承，这里的需求是继承两个类，并不是通过实现接口的方式“继承”多个接口上的方法声明。语言原生不支持，这样就比较麻烦了。
解决办法如下：
通过接口实现 + 反射 的方式来创建代理Application对象，曲线实现Application的多继承，由于代码较多，这里就不贴源码了，解决方案：ApplicationProxyDemo 源码配合注释食用，风味更佳！
https://github.com/brucevanfdm/ApplicationProxyDemo
5
导入aar的两种方法
解决一：采用Android Studio新建module的方法，选择jar/aar即可。
导入.AAR
解决二：使用gradle脚本直接导入：
1. 在项目build.gradle文件内android{}标签中加入如下代码申明本地仓库：
repositories{
flatDir{
dirs'libs'
}
}
}
2. 然后将aar包放入libs目录（没有就在app目录下创建一个），随后加入dependencies ：
dependencies{
compilefileTree(dir: 'libs', include: [ '*.jar'])
...
compile(name: 'xxxxxx-xxxx', ext: 'aar') //name为aar文件全名
}
6
SDK中不可忽视的混淆问题
1. 常规的避免混淆，比如一些第三方类库中的要求
2. 避免混淆对外提供方法与数据实体的类，并且添加到接入方的proguard-rules.pro中。
最后
其实在最近的SDK开发与对接中遇到了不少问题，但是也学到了不少东西，由于缺少相关经验，也在不断的摸索之中。正所谓实战出真知，纸上谈兵容易，真刀真枪时就会暴露出一些问题，还是要多动手。当然了，技术都是业务驱动的。
开发SDK注意事项
1. 修改类别文件名及类别方法。
开发ＳＤＫ时通常会用到比较多的第三方的类别方法， 这样的话， 开发者在使用你的ＳＤＫ时， 因为他可能也会加一些第三方的开源库， 比如都使用了NSString的md5类别文件。 由于这两个文件都是从网上下载来下的， 所以文件名是一样的。 这样在编译时就会报错。 然后就想到要去修改这个类别文件名， 等修改类别文件名后。 发现类别中的方法名是一样的， 而ios在调用两个相同方法的类别方法时， 不能确定其调用的哪个方法， 但可以肯定地是只会调用一个类别方法， 如果恰好开发者自己又修改了这个类别方法， 那就有问题了。
所以在ＳＤＫ开发过程中， 需要修改引入进来的类名， 及方法名， 建议添加项目前缀， 最好是三个字母的， 如ＮＡＢ， （两个字母为苹果自己保留使用）
2. 在开发ＳＤＫ时， 如果发现某个方法命名时比较困难， 那么几乎可以肯定的是， 这个方法藕合度太高，需要再次进行分解。
3. 开发ＳＤＫ时， 需要考虑到升级的问题， 并且可以指定某些版本必须强制升级。 （以防某些版本到后期发现有明显问题， 需要及时替换）
4. 开发ＳＤＫ时， 需要留出一个接口， 能通过后台服务器强制关闭掉某个接入应用的调用。 （这可能会发生在恶意地攻击行为， 以及非恶意地使用行为，如某应用频繁自动重启事故，每次重启都会调用咱们的ＳＤＫ，然后就会使得咱们的ＳＤＫ服务器压力陡增）， 这个时候， 如果后台能根据这个应用的ＡＰＰ ＩＤ啥的， 强制关闭它发的请求，或者屏掉他的请求， 你会发现世界如此美好。
5. 统计方面， ＳＤＫ存储每个接口调用的次数，以在一定的情况下发送给服务器， 便于后期分析某些接口是否有问题，或者是根本就没有用户使用的情况。
6. 有些ＳＤＫ使用的前提条件，最好是在编译期就提示给用户，而不是在运行期， 可以使用类似下面代码来进行提示
#warning - Release scheme, this is not work.
#if !__has_feature(objc_arc)
#error iBeaconSDK requires automatic reference counting
#endif