sdk开发、sdk与插件的区别
SDK全称 Software Development Kit，⼴义上的 SDK 是为特定的软件包、软件框架、硬件平台、操作系统等建⽴应⽤程序时所使⽤的开发⼯具的集合，狭义上的 SDK 则是基于系统 SDK 进⾏开发包装的、新的、独⽴的、能够完成特定功能并返回相关数据的⼀组⼯具的集合。
插件(Plug-in,⼜称addin、add-in、addon或add-on,⼜译外挂)是⼀种遵循⼀定规范的编写出来的程序。其只能在程序规定的系统平台下（可能同时⽀持多个平台），⽽不能脱离指定的平台单独运⾏。因为插件需要调⽤原纯净系统提供的函数库或者数据。很多都有插件，插件有⽆数种。
sdk可以看做插件的集合；
推荐⼀个BLE蓝⽛研究的库，正在做该⽅⾯的或者有兴趣的可以看下。
Android BLE蓝⽛框架，包括扫描、连接、设置通知、发送数据、读取和接收数据以及各种直观的回调，近乎⼀⾏代码植⼊项⽬，可扩展配置蓝⽛相关操作。
本⽂作者
作者：brucevanfdm
链接：
本⽂由作者授权发布。
1
前⾔
最近由于⼯作需要，将应⽤⾥的部分功能独⽴了出来，封装成 SDK 提供给合作伙伴使⽤。由于经验不⾜，⽹上也没多少写这⽅⾯内容的⽂章，遇到了不少的坑，决定记录下来。
其实，刚说到要写SDK也有点慌，印象中SDK⼀直是个复杂的东西，脑海中浮现的是Java SDK ,Android SDK这类庞然⼤物。
SDK全称 Software Development Kit，⼴义上的 SDK 是为特定的软件包、软件框架、硬件平台、操作系统等建⽴应⽤程序时所使⽤的开发⼯具的集合，狭义上的 SDK 则是基于系统 SDK 进⾏开发包装的、新的、独⽴的、能够完成特定功能并返回相关数据的⼀组⼯具的集合。
听起来⼀愣⼀愣的，其实，将⼀些业务逻辑独⽴出来，打包成jar、so、aar，暴露⼀些APIs给外部调⽤，也可以称为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实⽤指南
还是期待⾕歌能给出⼀个傻⽠式的⼀键合并⽅案吧！
3
SDK中Application对象的初始化
有次SDK接⼊⽅反馈说某个地⽅崩溃了，⼀看Log，是调⽤Application对象中的⽅法空指针了。我⼀想，混淆？不是。导⼊姿势不对？不是。⽂档没认真看？也不是？Demo可以正常运⾏啊......随即想到是接⼊⽅⾃定义Application对象的问题。
如果aar中定义了Application，theme，icon，那么编译时就要抛出如下异常：
-编译错误AndroidManifest合并异常-
由于项⽬与aar都定义了⾃⼰的Application，编译器不知道⽤谁的，这就产⽣了上图的异常，按照提⽰，在Application标签下添加如下代
码：
tools:replace="android:name"
合并⽅案可以参考官⽅⽂档：合并多个清单⽂件| Android Studio - Android Developers
理虽如此，但是你很⼤概率就掉坑了，这个⽅案直接将SDK中的Application对象替换为你的，换句话说就是SDK中的Application对象根本没有初始化，这就是上⽂说的空指针的罪魁祸⾸了！
确实之前在写⽂档的时候没有考虑到⾃定义Application的情况，还是经验不⾜啊！甚⾄⼀度将Application⾥初始化的⽅法全部移出来，后来转念⼀想，让接⼊⽅继承我的Application不就OK了吗！！测试⼀波，赶紧更新下⽂档，不然⼜被吐槽了...这下理解为什么接⼊某些第三⽅SDK时，有的会要求继承SDK⾥定义的Application对象。
4
Application多继承
作为⼀个SDK提供⽅，假如你的SDK需要⽤户继承你的Application，我觉得应当提供⼀个Application多继承的解决⽅案，毕竟⽤户可能不仅仅只⽤你⼀个SDK，当有多个SDK有这个需求时就尴尬了。
java 多继承，这⾥的需求是继承两个类，并不是通过实现接⼝的⽅式“继承”多个接⼝上的⽅法声明。语⾔原⽣不⽀持，这样就⽐较⿇烦了。解决办法如下：
通过接⼝实现 + 反射的⽅式来创建代理Application对象，曲线实现Application的多继承，由于代码较多，这⾥就不贴源码了，解决⽅案：ApplicationProxyDemo 源码配合注释⾷⽤，风味更佳！
5
导⼊aar的两种⽅法
解决⼀：采⽤Android Studio新建module的⽅法，选择jar/aar即可。
导⼊.AAR
解决⼆：使⽤gradle脚本直接导⼊：
1. 在项⽬adle⽂件内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开发与对接中遇到了不少问题，但是也学到了不少东西，由于缺少相关经验，也在不断的摸索之中。正所谓实战出真知，纸上谈兵容易，真⼑真时就会暴露出⼀些问题，还是要多动⼿。当然了，技术都是业务驱动的。
1. 修改类别⽂件名及类别⽅法。
开发ＳＤＫ时通常会⽤到⽐较多的第三⽅的类别⽅法，这样的话，开发者在使⽤你的ＳＤＫ时，因为他可能也会加⼀些第三⽅的开源库，⽐如都使⽤了NSString的md5类别⽂件。由于这两个⽂件都是从⽹上下载来下的，所以⽂件名是⼀样的。这样在编译时就会报错。然后就想到要去修改这个类别⽂件名，等修改类别⽂件名后。发现类别中的⽅法名是⼀样的，⽽ios在调⽤两个相同⽅法的类别⽅法时，不能确定其调⽤的哪个⽅法，但可以肯定地是只会调⽤⼀个类别⽅法，如果恰好开发者⾃⼰⼜修改了这个类别⽅法，那就有问题了。
所以在ＳＤＫ开发过程中，需要修改引⼊进来的类名，及⽅法名，建议添加项⽬前缀，最好是三个字母的，如ＮＡＢ，（两个字母为苹果⾃⼰保留使⽤）
2. 在开发ＳＤＫ时，如果发现某个⽅法命名时⽐较困难，那么⼏乎可以肯定的是，这个⽅法藕合度太⾼，需要再次进⾏分解。
3. 开发ＳＤＫ时，需要考虑到升级的问题，并且可以指定某些版本必须强制升级。（以防某些版本到后期发现有明显问题，需要及时替换）
4. 开发ＳＤＫ时，需要留出⼀个接⼝，能通过后台服务器强制关闭掉某个接⼊应⽤的调⽤。（这可能会发⽣在恶意地攻击⾏为，以及⾮恶意地使⽤⾏为，如某应⽤频繁⾃动重启事故，每次重启都会调⽤咱们的ＳＤＫ，然后就会使得咱们的ＳＤＫ服务器压⼒陡增），这个时候，如果后台能根据这个应⽤的ＡＰＰＩＤ啥的，强制关闭它发的请求，或者屏掉他的请求，你会发现世界如此美好。
sdk
5. 统计⽅⾯，ＳＤＫ存储每个接⼝调⽤的次数，以在⼀定的情况下发送给服务器，便于后期分析某些接⼝是否有问题，或者是根本就没有⽤户使⽤的情况。
6. 有些ＳＤＫ使⽤的前提条件，最好是在编译期就提⽰给⽤户，⽽不是在运⾏期，可以使⽤类似下⾯代码来进⾏提⽰
#warning - Release scheme, this is not work.
#if !__has_feature(objc_arc)
#error iBeaconSDK requires automatic reference counting
#endif

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。