标签：并发 如何 生效 开始 href nstat https 开源 自动
小程序原生页面存在层级限制，超过一定层数就会无法打开新页面。一开始这个限制为不超过5层，目前是不超过10层。
这个限制对于体量较大的小程序来说，挺难受的。特别是只能打开5层那会儿，业务流程很容易一不小心就超了，比如：首页-搜索结果页-商品详情页-聊天页-下单页-地址选择页-...；更有访问回路防不胜防，比如：商品详情页-查看更多页-商品详情页-查看更多页-...、商品详情页-聊天页-个人主页-商品详情页-聊天页-个人主页-商品详情页-...、诸如此类。即使后来放宽至了10层，还是很容易遭遇层级溢出。
一种处理思路是调整交互路径，严格控制层级数量。但是这种处理方案，一则很多时候会牺牲用户体验，比如为避免个人主页和商品详情页的访问回路，要么不能在个人主页中访问用户商品，要么不能在商品详情页中访问卖家主页，要么访问时需要替换当前不能返回继续浏览，不管怎么取舍都会牺牲某些用户的浏览诉求；二则维护成本特别高，业务逻辑越来越复杂，交互路径越来越发散，路径的统一梳理和规划就会越来越困难，而且管理过程对业务不透明，业务方在设计需求时要受到交互路径的种种限制，甚至一个需求的交互调整很可能无意中造成另一个需求层级溢出，维护成本高且不断膨胀。
因而本文考虑并实现了另一种处理思路：在小程序中支持不限层级的路由过程。
逻辑层级 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，欢迎使用或参阅。
主要难点及实现方案：
无限层级路由方案已在 转转二手交易网 小程序中应用了很长一段时间，欢迎体验：
无限层级路由方案已被抽离封装成独立开源模块，欢迎直接使用：https://github.com/zhuanzhuanfe/fancy-mini
update:
这是不是与小程序政策相背离呢？
其实，个人感觉小程序不是不想支持无限层级，而是不方便支持。
实践发现，打开一个新的空页面，内存消耗会增加30M左右，复杂页面甚至可能消耗几百M内存，层级一多，很容易黑屏。所以官方不方便支持无限层级。
相比之下，转转这个策略内存开销基本可以忽略不计，是一个比较合适的折中/保底方案。
交互设计上还是应该尽量简化，尽量扁平，层级不宜过深；但是也不宜过分掣肘。本方案主要还是作为一个基础保障，并不能因此就不注重交互设计。
为啥还要保留1-9层，直接所有交互都在第一层或第二层处理会有啥问题？
因为原生层级的返回体验会比较好。
原生页面返回时数据、交互状态、页面元素等都还是驻留在内存的，返回过程很流畅；
无限层级模拟返回则是在最后一层重新载入目标页面，元素需要重新渲染，数据需要重新设置，返回体验相对有所牺牲。
所以无限层级主要还是作为功能保障，并不宜直接取代原生层级。
“对于这种多页面来回跳转，建议优化设计，就单单用户需要返回这个操作，会返回到死”
页面访问回路是很难完全避免的，无限层级方案可以起到基础保障的作用。
“返回到死”问题，我们另有策略：当层级>=8时，页面右下角会出现一个快捷导航条，可以立刻reLaunch到首页等高频页面。
标签：并发 如何 生效 开始 href nstat https 开源 自动
原文地址：https://www.cnblogs.com/zhuanzhuanfe/p/9702656.html
