小程序无限层级路由方案

小程序无限层级路由方案

小程序原生页面存在层级限制，超过一定层数就会无法打开新页面。一开始这个限制为不超过5层，目前是不超过10层。

这个限制对于体量较大的小程序来说，挺难受的。特别是只能打开5层那会儿，业务流程很容易一不小心就超了，比如：首页-搜索结果页-商品详情页-聊天页-下单页-地址选择页-...；更有访问回路防不胜防，比如：商品详情页-查看更多页-商品详情页-查看更多页-...、商品详情页-聊天页-个人主页-商品详情页-聊天页-个人主页-商品详情页-...、诸如此类。即使后来放宽至了10层，还是很容易遭遇层级溢出。

一种处理思路是调整交互路径，严格控制层级数量。但是这种处理方案，一则很多时候会牺牲用户体验，比如为避免个人主页和商品详情页的访问回路，要么不能在个人主页中访问用户商品，要么不能在商品详情页中访问卖家主页，要么访问时需要替换当前不能返回继续浏览，不管怎么取舍都会牺牲某些用户的浏览诉求；二则维护成本特别高，业务逻辑越来越复杂，交互路径越来越发散，路径的统一梳理和规划就会越来越困难，而且管理过程对业务不透明，业务方在设计需求时要受到交互路径的种种限制，甚至一个需求的交互调整很可能无意中造成另一个需求层级溢出，维护成本高且不断膨胀。

因而本文考虑并实现了另一种处理思路：在小程序中支持不限层级的路由过程。

策略

• 修改小程序默认导航行为，自行维护完整历史记录
• 页面层级小于等于10时，导航行为与原生导航行为一致
• 请求打开第11层及以上时，逻辑层级记录完整历史，实际层级每次都是直接将第10层替换为目标页面
• 返回时，逻辑层级相应回退；若回退后逻辑层级大于等于10，则实际层级将第10层替换为目标页面，否则实际层级回退到相应页面
• demo:

  逻辑层级 1 - 2 - ... - 8 - 9 - 10
  实际层级 1 - 2 - ... - 8 - 9 - 10
  
  打开
  
  逻辑层级 1 - 2 - ... - 8 - 9 - 10 - 11
  实际层级 1 - 2 - ... - 8 - 9 - 11
  
  打开，打开，打开
  
  逻辑层级 1 - 2 - ... - 8 - 9 - 10 - 11 - 12 - 13 - 14
  实际层级 1 - 2 - ... - 8 - 9 - 14
  
  返回
  
  逻辑层级 1 - 2 - ... - 8 - 9 - 10 - 11 - 12 - 13
  实际层级 1 - 2 - ... - 8 - 9 - 13
  
  返回，返回，返回
  
  逻辑层级 1 - 2 - ... - 8 - 9 - 10
  实际层级 1 - 2 - ... - 8 - 9 - 10
  
  返回
  
  逻辑层级 1 - 2 - ... - 8 - 9
  实际层级 1 - 2 - ... - 8 - 9

实现

转转 实现了上述策略，并提供开源使用，地址：https://github.com/zhuanzhuanfe/fancy-mini，欢迎使用或参阅。

主要难点及实现方案：

• 如何接管路由过程
  • 要求所有页面不使用<navigator>元素，统一使用js触发跳转
  • 要求所有页面不直接调用wx.navigateTo、wx.redirectTo等路由相关接口，统一改用模块封装的相应接口
• 如何监听返回行为
  • 统一监听页面的onUnload函数，结合路由过程判断是否用户返回
• 如何兼容系统交互
  • 问题：系统交互会跳出正常路由流程，并且难以接管或监控，如：用户点击右上角返回主页按钮、用户切后台后又从其它入口进入、用户强制关闭小程序进程等
  • 处理：引入校正机制，在合适的时机根据系统路由栈对自行维护的路由栈进行校正。这样可以保证10层以内路由正确性。系统交互多是回到第1层，会被成功校正。
• 如何避免/兼容代码疏漏
  • 问题：接管&监听过程要求所有页面遵循一些编码约束，如何保证这些约束切实全面生效；万一有页面未遵循约束，能否依然保证健壮性
  • 处理1：编写并配置相应eslint规则，保证约束被切实遵循
  • 处理2：上一条中的校正机制，保证即使有代码疏漏，在10层内也会被校正；10层外可能会影响返回逻辑正确性，但一般不会造成页面功能问题。
• 如何进行状态恢复
  • 问题：返回后逻辑层级大于等于10时，实际是在第10层重新载入目标页面；用户在前一页面的表单输入等状态信息并不会像系统返回一样正常保留
  • 处理：在合适的时机存储页面的data，返回时予以恢复

成本

• 接入成本
  • 需要引入并配置路由模块
  • 需要检查并修改项目中所有页面跳转过程，统一使用模块封装的接口
  • 需要统一监听所有页面的onUnload函数
• 维护成本
  • 新增页面跳转过程，需统一使用模块封装的接口
  • 新增页面onUnload函数需接入统一监听
• 性能成本
  • 模块执行逻辑相对简单，内存开销相对较小，页面性能暂未发现明显损耗

收益

• 无限层级
  • 避免复杂/循环访问导致页面无法打开
  • 可以放心地向用户提供适合的访问入口，不必过分担心路径限制
• 完全的路由管控能力
  • 可以完全监控路由过程并实现或引入一些附加功能
  • 附加功能：实例覆盖自动恢复
    • 问题：wepy框架存在单实例问题，同一路径页面被打开两次时，其数据会相互影响，如：详情页A - 详情页B - 返回A，点击查看大图 - B的图片（而不是A的图片）
      详见issue：两级页面为同一路由时，后者数据覆盖前者
    • 策略：返回时，若判断目标页面数据已被覆盖，则自动予以恢复
    • 引入：参见模块使用说明
  • 附加功能： 免并发
    • 问题：用户连续快速点击多个/多次按钮时，会一次性打开多个窗口，一则造成层级膨胀，二则影响浏览体验
    • 策略：第一次点击造成的跳转完成之前无视后续点击产生的跳转请求
    • 引入：参见模块使用说明
  • 附加功能：数据预先加载
    • 问题：小程序的page1跳转到page2，到page2的onLoad是存在一个300ms ~ 400ms的延时的，在page2的onLoad中才开始获取数据会浪费这个延时
    • 策略：在 page1 中预先拿取数据，然后在 page2 中直接使用数据；wepy框架对此有良好的实现，参见WePY 在小程序性能调优上做出的探究
    • 引入：参见模块使用说明

效果

无限层级路由方案已在 转转二手交易网 小程序中应用了很长一段时间，欢迎体验：

无限层级路由方案已被抽离封装成独立开源模块，欢迎直接使用：https://github.com/zhuanzhuanfe/fancy-mini

---

update:

• 这是不是与小程序政策相背离呢？
  其实，个人感觉小程序不是不想支持无限层级，而是不方便支持。
  实践发现，打开一个新的空页面，内存消耗会增加30M左右，复杂页面甚至可能消耗几百M内存，层级一多，很容易黑屏。所以官方不方便支持无限层级。
  相比之下，转转这个策略内存开销基本可以忽略不计，是一个比较合适的折中/保底方案。
  交互设计上还是应该尽量简化，尽量扁平，层级不宜过深；但是也不宜过分掣肘。本方案主要还是作为一个基础保障，并不能因此就不注重交互设计。

• 为啥还要保留1-9层，直接所有交互都在第一层或第二层处理会有啥问题？
  因为原生层级的返回体验会比较好。
  原生页面返回时数据、交互状态、页面元素等都还是驻留在内存的，返回过程很流畅；
  无限层级模拟返回则是在最后一层重新载入目标页面，元素需要重新渲染，数据需要重新设置，返回体验相对有所牺牲。
  所以无限层级主要还是作为功能保障，并不宜直接取代原生层级。

• “对于这种多页面来回跳转，建议优化设计，就单单用户需要返回这个操作，会返回到死”
  页面访问回路是很难完全避免的，无限层级方案可以起到基础保障的作用。
  “返回到死”问题，我们另有策略：当层级>=8时，页面右下角会出现一个快捷导航条，可以立刻reLaunch到首页等高频页面。