微信封锁
2014年（时间无从考证），微信开始封锁淘宝链接，淘宝商品的链接无法在微信内打开，不管是分享还是朋友圈，使得淘宝的商品信息无法在微信内流转，或者流转成本极高。
淘口令
2015年，为了打破微信的封锁，淘口令横空出世，可谓轰动一时，其主要的解决思路就是：让用户可以将手机淘宝的商品链接以“淘口令”的形式分享给微信好友，后者复制口令，打开手淘后，即可直达手机淘宝的商品详情页，解决了淘宝商品链接无法在微信内流转的尴尬局面。
后续
依托着微信的良好用户体量，至今为止，淘口令不仅有文字的分享，还有图片口令的分享，而且依然保持着良好的数据体量，每天约800W级别的分享使用量，成为手淘引导成交中重要的一环。
产生影响
淘口令每天如此多的数据体量，看起来应该是非常好的事情，但是其隐含的问题也是不容小觑；每天800W的分享，带来的是，每天手机淘宝，800W在线用户的流失，或者至少是用户使用链路的打断，因为每次分享，用户都会被引导主动打开微信去做消息分享或者朋友圈分享，以下场景中，用户只要点击黏贴或者微信图标，就会自动拉起微信。
一点思考
淘口令分享来说，当前肯定会有回流，具体数据未知，但是这里总归是打断了用户使用的常规链路；那么有没有好的办法，既可以让用户完成分享链路，又不打断其浏览商品的链路呢？
这里针对iOS端，发现了一个小点子，请看以下视频（如果看不到视频，检查浏览器的脚本安全检查，放开即可）
上面其实是iOS的一个社交组件完成的功能，Social组件，当然，这个是肯定是微信开发注册给系统的一个extension;
简单说明
如果淘口令的分享使用这种模式，即不需要用户打开微信操作，又可以不打断用户在手淘的操作链路，一举两得；但此组件有个缺点，发送消息的场景下，无法输入文字，只能是链接和图片；但是能覆盖部分淘口令的使用场景；
优化后链路
链路优势：
- 分享发送端，链路不打断
- 分享接收端，用户体验提升，看到的是图片，不再是奇怪的文字
优化效果
按照iOS端每天400W的淘口令的量预估，如果有一半的淘口令场景使用以上模式，那每天可以留存200W左右的用户操作链路。
实现DEMO
demo非常简单，主要是使用了以下这个组件VC实现，demo中未实现手淘中解析功能
#import "Social/SLComposeViewController.h"
-(SLComposeViewController* )test{
SLComposeViewController *mySLComposerSheet;
NSString *serviceType = SERVICE_TYPE_WX;
if ([SLComposeViewController isAvailableForServiceType:serviceType]) {
mySLComposerSheet = [SLComposeViewController composeViewControllerForServiceType:serviceType];
if (!mySLComposerSheet) {
return nil;
}
UIImage *image = [UIImage imageNamed:@"test.png"];
[mySLComposerSheet addURL:[NSURL URLWithString:@"www.baidu.com"]];
if (![mySLComposerSheet addImage:image]) {
return nil;
}
[mySLComposerSheet setInitialText:@"我是聂云"];
mySLComposerSheet.completionHandler = ^(SLComposeViewControllerResult result){
NSLog(@"share complete");
};
} else {
//可能是未安装微信
return nil;
}
return mySLComposerSheet;
}简单的demo作为参考（见附件工程）；
感谢龙兮的指导
