项目的背景
一群做杀毒的韩国人来到公司找老板喝茶，喝着喝着吹嘘起自己公司的技术有多么多么的牛逼：“我们的SDK完全不需要开发者埋点，他们需要做的就是将要发布的APK包提交到我们服务器上来。然后我们就会自动的将SDK植入到它的APK中去，然后再将这个APK给到开发者就OK了”。BOSS被唬住了，“这么牛逼啊，要不我们两家公司合作下，融合下两家公司的业务，共同发财吧”。于是，将公司现有SDK尝试这种一键打包的方案探索也就落到了我们部门，而IOS平台的方案探索与实现就落到我头上了。
项目愿景
如上面所说，该方案的主要目标是减少开发者接入SDK的时间成本。如何减少呢，SDK接入步骤越少越好，接入的接口越少越好。极端情况下，开发者完全不需要理会SDK的任何接口，直接将SDK扔进项目中就OK。
实际上，将SDK加到工程中也有不少的坑。开发者使用的IDE各种各样，Android这边最常用的IDE是eclipse或者Android Studio，iOS使用xcode。这三种IDE都有着自己独特的加入文件到工程的方法。也就是说接入文档需要分别针对这三种IDE来撰写。有同学可能会说，这完全没必要吗，这是开发者的最基本素养，不会加文件做个屁开发啊。呵呵，实际上呢，现在的开发者的职业技能还真没有想像中的高，一个简单的文件找不到的问题都得找客服反馈。
简单的说就是，项目要达到的目标是埋点的接口尽量少，少到一个都没有，操作简单到傻子都会做。这样该项目的适用范围就是那种只需要接入初始化就可以正常工作的SDK了。这也是为什么上面那个韩国人能吹的原因，他一个杀毒的SDK基本不需要埋点，运行起来后就可以自动防护应用，与应用基本没有相互交流的机会。
项目方案
Android平台是将我们自己的smali文件植入到APK中，并修改APK中原有的smali文件，使其在合适的地方调用我们自己的接口，完成SDK的正常运行。
IOS平台最终运行的是IPA中的二进制文件，基本不可能参考Android平台在代码层次上进行修改，我们只能另寻它途。二进制的可运行文件除了IPA中的外，还存在于Framework中，而苹果已经在IOS7上开放使用framework了。想到这，一个方案的雏形浮现出来：
将开发者提交的IPA包解压，将SDK做成framework形式放入到解压包里，然后将解压包重签名后重新打包成IPA包就是了。但最为关键的是SDK如何运行起来呢？当然是自动运行了，让SDK在类加载完成后调用自己的初始化接口就是了。
如果有少量的业务接口需要埋点怎么办呢？提供一个源码文件，与SDK接口一致，实现只做简单的参数打印，开发者使用该文件进行埋点。SDK在运行时，使用runtime将其实现修改为SDK接口本身的实现，这样就间接的实现了接口埋点功能。
项目实践
Github上有一个Resign的开源项目，该项目中已经将上述方案中的大部分实现了，除了注入framework形式的SDK。基于拿来主义的原则，我们直接在这个项目的基础上实现了一键打包的功能。项目成果界面如下图：
这个工具会自动的从后台配置获取最新版本的SDK，当开发者将IPA路径、开发者账号、provisioning profile、应用appId与channelId配置完毕，点击重签名，工具会自动生成一个植入SDK的IPA文件。如果像appstore提交的话，开发者可以使用xcode提供的application loader。
项目应用前景
个人不看好这种拍脑袋想出来的只为凸显自己逼格的项目。该项目的适用范围非常窄，试想下，没有自己独有业务接口的SDK在市场上能有多少竞争力来保证自己活下来呢！
即使项目也有着自己的埋点方案，但这样它与传统的SDK接入方案有什么区别了呢？同样需要将额外的文件引入到工程中，可能引用的文件会简单点，但依然是引用。
网友评论