微信***

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作为参考（见附件工程）；
感谢龙兮的指导