假期在家里玩腾讯斗地主小游戏，发现了分享逻辑里的一个细节，之前没考虑过这个角度，觉得方案取巧而且可行。

除了少数微信官方提供的入口流量，大多数小程序主要以分享的方式获取用户，以奖励方式激励用户分享，分享页面拉新，分享出去还能再回来，多种分享形式。

小游戏出来后，微信聊天群被各种小游戏分享攻占，分享续命、续命得金币等等，导致聊天过程充斥着大量垃圾信息，逼的微信立马阉割了 onShareAppMessage 接口，用户仍可以分享，但开发者无法判断分享结果的成功失败。如此一来，微信自己的问题解决了，留下开发者们黯然神伤。没有分享状态，从开发角度该如何应对？除了分享，其他场景呢？这里可以给几个例子做参考。

案例

首先是腾讯自家的小游戏，腾讯斗地主，利用用户进入小程序的 scene 进行场景识别并进行奖励，产品提示用户将小程序添加到“我的小程序中”，并从我的小程序中进入，即可领取奖励豆子。通过进入小程序场景值判断用户是否通过 “我的小程序” 进入小程序，以此进行奖励。

另一种方案是，用户分享时，在分享链接中带上用户专属 key，其他用户通过分享的链接进入小程序时，请求将链接中的 key 带回后端，这种做法也是拉新场景常用的方案。

第三种，大家在日常生活中应该都体验过，帮微信好友加速抢火车票，这种方案是比较高级的做法，产品的逻辑进了朋友圈，好友的参与度更高，除了点赞之交，还可以升级成抢票加速之交。尤其是春运期间，这种分享方式带来海量的新用户数据。这种方式被发扬光大后，雨后春笋般地出现了邀请好友帮砍价，邀请好友帮砍房租等等。

当然，除了转发到聊天，朋友圈也是非常重要的场景，但目前小程序并没有开通朋友圈的小程序入口，不过，分享到朋友圈仍然可以做，只是改成以小程序码形式展现，用户通过扫描小程序码进入。以租房场景为例，假如二狗在发布房源后，可以生成一张房源卡片，房源卡片内容包括房源的基本信息，以及最重要的小程序码。二狗可以将这种卡片分享到朋友圈进行传播。

小程序码的限制

这里想把小程序码独拎出来单说一下，小程序通过接口生成二维码和小程序码，相应接口对比如下：

接口 参数限制 码类型 生成码数量限制
getWXACode 128 字节 小程序码 getWXACode + createWXAQRCode总量上限 10w
getWXACode 128 字节 二维码 getWXACode + createWXAQRCode总量上限 10w
getWXACodeUnlimit 32 个可见字符 小程序码 无上限

日常开发中大家用 getWXACodeUnlimit 接口生成码的次数应该较多，毕竟无上限，没有心理负担，但有得必有失，参数限制 32 个可见字符导致分享的链接无法携带过多参数。我之前用过缩短参数 key、value 值的方法，但对日益增长的参数而言，不是长久之计。目前的方案是在服务端维护一套映射数据库，生成码时，通过原参数生成长度小于 32 位的长串，并存库，用户扫码后，首先将小程序码上链接传至服务端进行解码，获取正确参数，小程序拿到正确参数后再进行正常条状、渲染等。这个方案虽然需要在进入时处理异步问题，但从收益角度而言，是非常具有性价比的方案。

分享出去，还要回来

首先注明下，下面提到的分享页，都不属于 tab 页面，tab 页也不会出现这个需求了

仍用一下租房的案例，铁蛋在朋友圈看到二狗分享的房源，比较感兴趣，于是从分享的链接或者卡片进入小程序查看房源的详细信息，看完觉得不是很满意，就退出了小程序，这肯定不是我们愿意看到的，我们希望用户除了被分享的内容外，还能去体验下小程序的整体流程，虽然是从某一个点分享出去，但用户进来后可以看到整个面。这就涉及到分享方案的具体实施，从分享页面回到其他页面目前有两种通用的方案。

先说下出现两种方案的原因，首先假设首页的路径是 /index，列表页的路径是 /list，详情页的路径是 /detail，正常用户从首页进入小程序房源详情页的页面栈顺序是 index -> list -> detail，因为有前一级页面栈存在，用户访问详情页时，可以返回上一级，但分享链接时，通常仅分享当前页面的路径，例如我现在分享某详情页时，分享的链接则是 /detail?code=XXX，用户通过我的小程序链接直接进入了 detail，没有前置页面栈，这就导致页面无法返回到首页或其他页面。

而微信官方不建议开发者直接操作页面栈，会导致未知问题，日常开发中遇到这个问题，下面是两种常用的方案。

首页跳板

既然不能直接操作页面栈，我们可以换种思路，每次都从首页进入小程序，那么每次小程序分享的链接就变成了 index?redirect=detail?code=XXX，encode 后就是 index?redirect=detail%3Fcode%3DXXX，用户点击链接进入时，首页拿到 redirect 参数，再 redirectTo 到 detail?code=XXX。访问的页面栈就成了 index -> detail。这种方案成本很低，对项目的改动也最少，适用较小的项目，当页面层级加深，这种方案就不再合适。这时候就可以试试自定义导航栏的方式，给产品增加新的交互逻辑。

增加自定义导航

自定义导航栏

小程序支持自定义导航栏，适用于全局配置和页面配置，下面是对应的开始支持的客户端版本

范围 参数 支持版本
全局配置(app.js) default(默认样式)/custom(自定义导航栏，只保留右上角胶囊按钮。) 微信客户端 6.6.0
页面配置(page) default(默认样式)/custom(自定义导航栏，只保留右上角胶囊按钮。) 微信客户端 7.0.0

备注：
客户端 7.0.0 以下版本，navigationStyle 只在 app.json 中生效。
客户端 6.7.2 版本开始，navigationStyle: custom 对 组件无效

通过在自定义导航栏中增加返回入口或者首页入口，用户从分享页面进入时，可以改变对应文案，提醒用户点击回到首页。相较于在 app.js 里配置全局自定义导航栏，我推荐使用页面级配置，这就需要明确客户端版本导致的兼容性问题影响面。下面是微信官方的数据（更新时间：2019年3月20日，参考资料在文末）

端 客户端版本 基础库版本 >= 该版本的用户比例
iOS 7.0.0 2.5.2 60.01%
iOS 7.0.3 2.6.2 56.37%
Android 7.0.0 2.5.2 74.01%
Android 7.0.3 2.6.2 70.51%

这个数据能作为决定是否进行兼容的参考，另一个更具有参考价值的数据可以在小程序管理后台看到，进入后台在 设置 -> 基础库最低版本设置 中可以看到近30天内访问小程序的用户的公共库版是否会被影响的比例。这个比例可以最终设置线上基础库的参考。

当然，你可以做的更激进一些，把更多的功能性入口放在导航栏中，比如搜索……

其他自定义导航

除了自定义导航栏的方式，还可以在页面中增加返回首页 fixed 按钮，辅助用户回到首页，这个方案再进一步，则可以做成 iPhone 辅助功能快捷键的方式，除了返回首页，还提供其他导航快捷功能，这也是目前 Airbnb 的方案，这种方案的优势是完全不需要考虑兼容性。但在开发角度，对于全局组件的管理则需要花费更多的心思。

以上，就是所有内容。

参考资料