首页 > 代码库 > iOS 关于微信检测SDK应用的原理浅析

iOS 关于微信检测SDK应用的原理浅析

微信作为一个开放平台,各方面都是做得比较好的,推出了SDK之后,微信与使用了SDK的应用便能进行更多交互。但在iOS平台上,应用间交换数据还是相对麻烦的,那么微信为什么能直接在应用检测到其他使用了SDK的应用呢?基于这个疑问,我用了一个下午研究其原理。

一、SDK的方法

我之前也没使用过微信的SDK,不过下载后,查看发现SDK接口有这么一段

1 /*! @brief WXApi的成员函数,在微信终端程序中注册第三方应用。2  *3  * 需要在每次启动第三方应用程序时调用。第一次调用后,会在微信的可用应用列表中出现。4  * @param appid 微信开发者ID5  * @return 成功返回YES,失败返回NO。6  */7 +(BOOL) registerApp:(NSString *) appid;

换句话来说,如果下载包含SDK的应用后,不打开应用或应用不调用注册方法,微信是无法检测应用的。但事实上,这段注释还不完整(原理会在下文解释),第一次在本机安装的应用,不打开确实无法让微信检测。同时,如果应用删除了,微信也会及时在可添加的列表中删除这个应用。但是,如果在本机安装过一次并打开过这个应用,无论以后删除后再安装,不重新打开,微信一样可以检测到这个应用。

 

二、交互的方法

其实,现时在微信中添加应用这个功能还是略无聊,只是增加了一个类似快捷方式的东西而已。当然以后发展了,这个功能肯定大有作为,包括类似新浪微博SDK的SSO也是使用了URLScheme。在应用中跳转到其他应用,方法很简单,被打开的应用先设置后自己的URLScheme,例如

然后只要用类似

1 [[UIApplication sharedApplication] openURL:[NSURL URLWithString:@"wxd930ea5d5a258f4f://test"]];

“wxd930ea5d5a258f4f”为上面URLScheme,“test”改为参数,当然没有参数都是可以正常打开的。还有拨号、邮件等系统默认的URLScheme,可以自己搜索。至于第三方应用的URLScheme,则可以在应用目录下的“XXX.app”的“Info.plist”的“CFBundleURLTypes”中找到。

 

三、检测应用的方法

查了一下检测已安装应用的方法(可参考http://tangqiaoboy.blog.163.com/blog/static/116114258201172975359440),不外乎就这几种方法,显然最可靠的就是UIApplication的方法

1 - (BOOL)canOpenURL:(NSURL *)url

这也是网上大多数人认为微信检测应用所采用的方案,但显然这还不完整。首先,检测时需要知道检测对象的URLScheme,难道微信要遍历每一个可能的URLScheme来进行检测??这效率肯定相当低下,越来越多人使用微信平台的SDK,那么将来遍历URLScheme的成本也太大了吧。于是我有一种猜想,微信SDK都能像OpenUDID一样生成一个UDID,然后打开包含SDK的应用时,就同时将UDID和应用的信息上传到服务器,然后每次登陆微信都利用UDID查询已安装的应用信息。

似乎也可以实现,但是我测试后发现,即使不联网,微信依然能检测到已安装的应用。上面的猜想直接被推翻了。

后来我想起了OpenUDID的原理(可参考http://blog.csdn.net/lusonglin121/article/details/9466495),其中有利用到UIPasteboard的地方

1 UIPasteboard* slotPB = [UIPasteboard pasteboardWithName:availableSlotPBid create:YES]; 

UIPasteboard是创建自定义的设备剪贴板,可以用于应用间的数据交换,而且支持文字、图片、URL和颜色。最重要的是,剪贴板的数据大小似乎不限制大小(我查到的资料没有提及数据大小的问题,具体的原理我以后会继续研究,如有错漏请包涵),还有能使用数组储存和重启后的持久化。

 

说了这么久,思路其实已经很清晰了,我现在就来总结一下微信实现检测的整个流程:

1、安装微信,打开微信,这很重要因为需要微信来创建剪贴板

1 UIPasteboard *paste = [UIPasteboard pasteboardWithName:@"hello" create:YES];2 paste.persistent = YES;

如类似代码,persistent的属性一定要设置为YES,否则应用一退出,剪贴板就被清空了。这个文档说得很清楚的,系统的剪贴板是默认YES,自行创建的默认NO。还有剪贴板的内容如果被持久化,则应用退出后、重启后,内容一直都在,除非应用被删除。事实上,一旦微信被删除,重新安装后,打开微信也无法检测已安装应用了。因为剪贴板被清空了,除非再次打开那些使用SDK的应用。这也证明了,微信确实是使用了剪贴板的方法。

2、使用SDK的应用打开后,将自己的Key、URLScheme和图标等,图标就在mainBundle那里,添加到微信的剪贴板。

3、再次打开微信,微信通过遍历剪贴板的内容,就能轻松列出用户本机上使用了SDK的应用名字和图标,点击添加也是可以立即打开。不过此处有一些地方需要注意,应用的描述介绍是需要在线加载的,所以不连接网络,第一次列出的应用介绍会变成空白。同时,图标也会在线加载,替换原来从剪贴板中拿来的图标。

4、基本所有步骤都完成了,剩下只是每次添加应用前再检查一下是否有效即可。

 

总结:

这样就能完整解释了微信检查应用功能的种种现象了,不过,其实有需要改进的地方:

1、应用删除后,下次打开微信遍历完成后,并未将剪贴板中的对应记录删除。其实这种做法会有出现一种情况,就是用户安装了大量包含SDK的应用后,都打开了几次后就删除。但冗余的记录仍在剪贴板,那么遍历的速度会受到很大的影响。这里需要一些优化的策略,如定期清理、达到一定数量就清理等(或者微信已经做了我不知道,但是,我发现每次点击“+”的按钮,确实有轻微卡顿)。

 2、就是一旦被知道Pasteboard的name,就能够知道用户曾经安装过哪些应用,同时再通过遍历URLScheme知道现时还存在的应用。当然name确实存在被反汇编泄露出来的可能(下一步可以研究一下这个),利用微信这个特性或许能获知用户更多的私隐。当然遍历测试URLScheme的方法其实每一个厂商都能做,只要积累一个足够大的“URLScheme库”也就可以了,但效率不及直接利用微信要快。同时,有一些应用确实不使用URLScheme的,就无法通过这种方法获取了。显然,微信利用这种方法着实能统计用户的安装应用行为,手法相当高明,要是未来很多应用都使用了微信SDK的话,它统计的数据就会更为准确。所以微信SDK有意封装了这些方法,仅希望自己能获知这些信息。

 

 

通过分析微信的这种实现方法,希望也能为大家拓展一下编程的思路,欢迎交流,转载请注明Pinka-cnblogs。