2023年12月24日更新 经过测试发现，官方提供的onSaveExitState有一些问题，不太符合官方文档提出的预期，大家暂时慎重使用onSaveExitState功能，用其他方案吧。 ======================================================================== 假设用户在小程序内进行一个答题的活动，或者进行一个测试，这个活动或测试的时间比较长，大概需要10分钟的时间。当用户答题进行到一半的时候，来了一个重要的电话，电话打了十几分钟，回来之后想着继续进行操作，发现小程序是重新打开的状态。之前答题答了5分钟，白费了。这样，用户需要重新进行答题。 问题场景分析 用户离开小程序时间太久（官方说30分钟以上，但测试十几分钟分钟以上）或者手机内存不够用的时候，小程序会被销毁，也就是完全终止运行了。此时用户再想进入小程序进行之前的操作，只能重新操作一遍。 解决方案 以本场景为例，如果用户正在答题，在用户退出小程序的时候，将当前页面的答题进度数据进行一个保存，当用户再重新进入小程序的时候，检查是否有答题进行一半的数据。如果有，自动跳转到答题的页面，并且在onload中恢复退出之前状态的数据，让用户继续进行答题的操作。 微信小程序有一个非常好用的回调函数onSaveExitState。 退出状态onSaveExitState 每当小程序可能被销毁之前，页面回调函数 [代码]onSaveExitState[代码] 会被调用。如果想保留页面中的状态，可以在这个回调函数中“保存”一些数据，下次启动时可以通过 [代码]exitState[代码] 获得这些已保存数据。 代码示例： { "restartStrategy": "homePageAndLatestPage" } Page({ onLoad: function() { var prevExitState = this.exitState // 尝试获得上一次退出前 onSaveExitState 保存的数据 if (prevExitState !== undefined) { // 如果是根据 restartStrategy 配置进行的冷启动，就可以获取到 prevExitState.myDataField === 'myData' } }, onSaveExitState: function() { var exitState = { myDataField: 'myData' } // 需要保存的数据 return { data: exitState, expireTimeStamp: Date.now() + 24 * 60 * 60 * 1000 // 超时时刻 } } }) onSaveExitState 返回值可以包含两项： 字段名 类型 含义 data Any 需要保存的数据（只能是 JSON 兼容的数据） expireTimeStamp Number 超时时刻，在这个时刻后，保存的数据保证一定被丢弃，默认为 (当前时刻 + 1 天) 一个更完整的示例：在开发者工具中预览效果 注意事项如果超过 [代码]expireTimeStamp[代码] ，保存的数据将被丢弃，且冷启动时不遵循 [代码]restartStrategy[代码] 的配置，而是直接从首页冷启动。[代码]expireTimeStamp[代码] 有可能被自动提前，如微信客户端需要清理数据的时候。在小程序存活期间， [代码]onSaveExitState[代码] 可能会被多次调用，此时以最后一次的调用结果作为最终结果。在某些特殊情况下（如微信客户端直接被系统杀死），这个方法将不会被调用，下次冷启动也不遵循 [代码]restartStrategy[代码] 的配置，而是直接从首页冷启动。

appid:wx068593359718b10d 我们是一个农民合作社辅导员，要实地对合作社进行指导，签到打卡的小程序，辅导员在实地去往合作社的过程中，需要持续实时的获取位置，以便他安排去哪家，且在到达后，要在目的地范围打卡，为何申请不通过？

接口：https://api.weixin.qq.com/wxaapi/broadcast/room/getsharedcode?access_token 接口文档：https://developers.weixin.qq.com/miniprogram/dev/framework/liveplayer/studio-api.html#8 需求：像直播间的分享卡片一样，当用户通过扫描自定义海报进入该直播间后，点击商品进入商品详情页，在onload的参数中获取到share_openid。  目前进度：生成海报，可以扫码进入直播间，但获取不到share_openid。 对了，自定义参数params怎么用？

产品简介：通过生成小程序二维码（又称太阳码或葵花码，后文简称小程序码），并将印有小程序码的物料铺设在线下场景，或通过线上分享等方式，引导用户扫码或长按识别二维码进入小程序，实现小程序引流；并可通过配置带参数的小程序码，监控各来源渠道的转化效果。 优势：低成本，易生成，易推广；用户习惯养成，扫码、识别码易用。 接入方式：普通小程序二维码无须开发，可在后台直接生成；带参数小程序码须开发。 关键词：小程序引流，数据跟踪与分析。 01　应用场景 在时尚零售行业，品牌可基于不同的业务场景，将小程序码印在商品、包装、宣传物料、门店展架等等，引导用户通过扫码快速进入小程序。 1）线下场景如： 将小程序码印在宣传物料上，引导用户扫码进入小程序； 将小程序码印到商品瓶身、包装、货架上，引导用户扫描进入小程序，享受扫码购服务； 将小程序码印在亚克力牌上，放置在店内如收银台等位置，引导用户扫描进入小程序，快速创建会员、填写服务问卷等。 2）线上场景如： 在小程序内提供个性化分享卡片的生成功能，用户可将卡片自主转发给好友，好友可长按识别卡片进入小程序，体验小程序内的商品购买、预约等服务。 02　生成方式 小程序码的生成有两种方式，分别为通过小程序后台生成链接统一的普通小程序码，以及通过开发生成带参数的小程序码。 1）普通小程序码： 我们推荐你通过小程序后台（mp.weixin.com）-设置-基本设置-小程序码及线下物料下载，完成小程序码的下载。 下载完成后，你可以将其打印并铺设到线下场景，或者直接附于海报中用于线上传播。 2）带参小程序码： 如须生成带参数的小程序码，为每个宣传物料配上独一无二的小程序码，智能跟踪来源于不同渠道的明细数据，可通过后台接口生成不限数量且永久有效的带参数小程序码。 开发指引内容较长，建议使用电脑详细查阅。点击打开文档 3）兼容普通二维码： 我们还提供了扫描普通二维码跳转小程序的能力。如线下已铺设有二维码，无须更换二维码，即可通过该能力在线下推广小程序。 开发指引内容较长，建议使用电脑详细查阅。点击打开文档 03　进阶应用-带参数码详细介绍 通过带参数二维码的灵活应用，可以监控各个渠道的用户来源、活动转化，调配资源提升营销运营效果，它的应用场景有： 1） 大数据营销： 在不同渠道投放不同参数的小程序码，可以精准记录客户来源，为营销决策提供依据。 2）线下助销： 通过给每个销售人员、每个店铺分配带有参数的小程序码进行佣金统计、计算销售奖励等。 3）一物一码： 让每个产品都拥有一个独一无二的小程序码，实现产品的差异化控制。

有时候我们使用一个小程序会遇到以下情形： 我们打开一个小程序，就看见提示“分享到5个群，可以获得一张20元的优惠券”，吸引我们去无脑分享到不同的群里； 打开某个小游戏，提示我“一定要分享到xx个群，才能继续玩游戏”； …… 而我们在群里打开这类小程序，仍然是提示我分享的信息，这类功能无疑打断了我们对小程序/小游戏正常的功能使用。 我们收到了很多用户对这类小程序/小游戏的抱怨。这类分享并非是用户主动自发的，而是受到了某类利益的诱惑，或是被迫分享。这样的内容充斥在群里、小程序里，对用户造成了骚扰，是对分享功能的滥用。 在原来的分享接口中，用户发起分享动作之后，可以通过 success 、fail、complete等回调来判断用户是否完成了最后的分享动作。通过这个能力，开发者是可以将产品交互在分享这个能力上做得比较自然和顺畅。但却被上述情形的小程序滥用。在我们权衡了分享功能带来的利弊后，我们打算回收这个能力。调整为：我们将不再支持分享回调参数 success 、fail 、complete 。即开发者无法判断用户最终是否完成了分享动作，也无法获取到分享成功后的回调参数shareTicket 。 接下来将与大家介绍此次分享功能调整后，小程序的调整建议。 对应小程序调整建议 此次调整可能影响到两种分享功能的用法。 第一种：通过判断用户最终是否有分享来做分支逻辑的小程序。 例如，通过判断 success 回调触发，来判断用户是否分享出去了，进而给奖励，如果用户没有分享出去则不给奖励。这类功能是我们平台不倡导的，后续将没有办法实现。 如果是需要在分享完成后变更当前页面的状态，可以适当调整交互方案。例如过去赠送代金券后显示“等待领取”等应用场景，可以改成在分享后继续保留“赠送”按钮，但提示用户一个代金券只能被一人领取，重复赠送无效。 第二种：获取用户分享之后的 shareTicket ，换取群唯一标识 openGId ，进而显示对应群的相关信息的小程序。 例如，部分小程序实现了群内的排行信息，通过分享小程序到某个群里，可以查看该群内成员的排行榜。 此次调整后，用户分享完成后无法立刻显示该群的排行榜信息，但仍可在用户从群消息点击进入小程序时显示该群的排行榜信息。 因此建议适当修改产品流程，在用户分享小程序之时，提示用户可进入群内查看群排行等信息。避免调整策略生效之后带来的交互不完整影响。 调整覆盖范围提示 近期新提交的版本中将会受到此策略的影响。 除此之外，调整策略在即将发布的基础库版本 2.3.0 生效，该基础库版本对应本月即将发布的微信客户端版本（暂定版本号 6.7.2）。即：近期提交审核的小程序版本，在基础库版本 2.3.0 以下的环境中仍不受此策略影响，仅在基础库版本 2.3.0 以上的环境受影响。 开发者需要注意，近期提交审核的版本都需要考虑兼容上述调整带来的影响，请各位开发者及时调整分享能力。