问题模块 框架类型 问题类型 API/组件名称 终端类型 微信版本 基础库版本
API和组件 微信小程序 需求 wx.navigateToMiniApp 客户端 6.6.0 2.10.0

十一没捞着休息，基本都在针对微信小程序相互跳转的逻辑进行改造。这里也谈谈作为一个普通开发者对此规则的看法。


1. 废弃wx.navigateToMiniProgram
我方微信小程序有一个简单的广告组件，用来承接垂直行业内的特定广告主和对外商务合作需求，可以根据需求直接播放视频、展示图片、打开内置landing page和对方绑定的微信小程序。逻辑较为复杂，因此通过catchtap后判断广告落地形式进行跳转，还需要在跳转之前和服务器请求一次效果跟踪id做动态的拼接。使用组件之后，只能对跳转success fail complete 时间做后续的事件编程，无法在触发到跳转之间做任何动作，导致必须对整个前后端流程进行改造，并且影响了后续一些可能的功能实现。


事实上从我们看，本身两个微信小程序之间跳转extra data这件事，就很有可能是触发当时动态产生的。这样废弃API只能用组件的做法，基本腰斩了extra data的一半应用场景。


从体验上来说，这次规则调整可能是因为某些个别微信小程序自动跳转导致了体验不佳，但从实际效果上看，起码目前微信小程序到微信小程序的跳转和微信小程序内打开一个新页面体验基本一致。按照这个逻辑，是不是wx.navigateTo 也没必要存在了，直接用navigator来实现即可？ 要伤害体验，乱导页面的伤害和乱导微信小程序没任何实质区别，只不过微信小程序是一个外部的页面而已。这点个人觉得已经纠枉过正。为了个别违规微信小程序而局限了应用场景得不偿失。


2. 需要用户确认跳转
这一点持观望。app跳转app由于有完全不同的场景切换，操作系统层面是会有跳转提示，但微信小程序和微信小程序更像url链接url，确认跳转未必是一个好的体验。起码前面已经需要用户触发了，再次确认就没有太大必要。


建议
可以设置成toast，跳转微信小程序loading时展示一个提示跳转的浮层或者顶通，而不需用户点触。
如果必须确认跳转，那微信小程序A跳转B一旦确认，无需再次确认。但这个的授权列表估计会长的非常快。。。。。


3. 微信小程序不再需要绑定至同一个公众号
这个自然好，但后续会不会有一些微信小程序提出不想被其他微信小程序随意套壳变相成为空壳微信小程序跳转内容的需求呢？个人觉得共同绑定一个公众号还算是一个相对合理的“握手协议”。商务上并不是一个难事。当然这个握手协议如果成本太高，那微信团队应该去优化这个握手方式，取消了握手这个步骤，谁都可以跳转谁，后面谁知道会是什么乱象。


4. 每个微信小程序限制不超过10个，且必须提交代码更新
这可能是最不可理喻的限制吧。例如我方现在跳转主要为了商务合作和广告业务，难道要求开发者同时对外合作或者接纳自己的广告主还得有10个的天花板？目前和我们共同绑定的微信小程序已经在这个值之外了，所以还恳请微信团队手下留情，即使必须限制，也务必免审，最好能有api，不然怎么死的都不知道。
这点也会限制很多将来可能出现的接口型的应用，如
万能收藏夹
通用购物车
心愿清单（似乎腾讯官方已经有了一个。。）
....


这些都涉及到两个微信小程序之间的来回跳转和一对多的关联关系，设置这样的10个限制实在不可取。并且会发生A能跳到B，B却回不到A的情况。
--


之前理解微信小程序时，团队中大家也有比较一致的看法就是要围绕‘小’。功能单一不要紧，通过界限明确的多个微信小程序之间的配合和跳转来实现好的体验。而从这次十一规则调整看，最后无论对开发者和用户都未必有很好的结果。当然对于个别的一些乱象可能会减少，个中得失当然我们未必看到的是最客观的，但


希望微信团队相信优胜劣汰的市场选择
水至清则无鱼，规范的同时也要考虑扩大微信小程序潜在场景。
让用户看到太多选择未必是好体验，请参考之前剪贴板权的反面案例。


谢谢

微信小程序开发问题解答

微信小程序开发者回答：

大佬，借个楼，微信小程序相互关联了，为什么跳转了？

微信小程序开发者回答：

navigator组件数据异步获取，本身是一个弹层了，现在又增加一个确认弹层。。日了。。。，相当于又增加了一步用户操作体验上真不好

微信小程序开发者回答：

你的微信小程序属于【流量互导】？

本文网址：http://www.91bianli.com/kaifazhinan/74803.html

上一篇：[已解决]微信小程序切换到后台之后，websocket断线重连

下一篇：[已解决]微信小程序开发ios下createInnerAudioContext接口有