在之前的文章中，我们知道了新 scroll-view 可以让小程序的长列表做到丝滑滚动～ 也提到了新 scroll-view 提供了很多新能力 sticky、网格布局、瀑布流布局等，这一篇，我们就来看看这些新能力是怎么使用的～ 新 scroll-view 在原来列表模式（type="list"）的基础上，新增了自定义模式（type="custom"） 在自定义模式下，新增了以下新组件供开发者调用 list-view：列表布局容器sticky-section / sticky-header：吸顶布局容器grid-view：网格布局容器，可实现网格布局、瀑布流布局等sticky布局sticky 布局即在应用中常见的吸顶布局，与 CSS 中的 position: sticky 实现的效果一致，当组件在屏幕范围内时，会按照正常的布局排列，当组件滚出屏幕范围时，始终会固定在屏幕顶部。 常见的使用场景有：通讯录、账单列表、菜单列表等等。 与 position: sticky 不同的是，position: sticky 很难实现列表滚动需要的交错吸顶效果，而 sticky 组件则可以帮忙开发者轻松实现交错吸顶的效果。 sticky 的使用非常简单： 将 scroll-view 切换到 custom 模式采用 sticky-section 作为 scroll-view 的子元素sticky-header 放置吸顶内容list-view 放置列表内容             {{item.name}}               ...       我们来看下采用 sticky 布局做出来的通讯录效果～ [视频] sticky 布局也可以通过给 sticky-section 配置 push-pinned-header 来声明吸顶元素重叠时是否继续上推 像下图输入框和标签列表这种类型，标签列表吸顶时还是希望保留输入框吸顶。 [视频] 网格布局网格布局即将列表切割成格子，每一行的高度固定，常见的视频列表、照片列表等通常都采用网格布局。 在此之前，实现网格布局需要开发者自行实现网格切割，再嵌入到 scroll-view 中。 新 scroll-view 直接提供了 grid-view 组件供开发者使用～ 将 scroll-view 切换到 custom 模式采用 grid-view 类型为 aligned 做为直接子节点grid-view 中直接编写列表                   ...       下面是使用网格布局实现的图片列表效果～ [视频] 瀑布流布局瀑布流布局与网格布局类似，不同的是瀑布流布局中每个格子的高度都可以是不一致的，所以在小程序中实现瀑布流布局就比较复杂了。 开发者需要通过计算格子高度，然后再进行瀑布流拼接，当滚动内容过多时还需要处理节点过多导致内存不足等问题。 grid-view 组件直接支持了瀑布流模式供开发者直接使用，grid-view 组件会根据子元素高度自动布局： 将 scroll-view 切换到 custom 模式采用 grid-view 类型为 masonry 做为直接子节点grid-view 中直接编写列表                   ...       下面是使用瀑布流布局实现的图片列表效果～ [视频] 想要立即体验？现在通过微信开发者工具导入 代码片段，即可体验新版 scroll-view 组件能力～

基本介绍onShow、onLoad与onReady都是小程序页面生命周期函数。 onLoad 在页面加载时调用，仅一次； onShow页面显示/切入前台时触发，两个生命周期非阻塞式调用。 onReady 是页面初始化数据已经完成后调用的，并不意味着onLoad和onShow执行完毕。 调用顺序是onLoad > onShow > onReady 根据对应的执行机制，我们预期有三种执行的逻辑 A. 页面每次出现都会执行 从其他页面返回手机锁屏唤醒，重新看到小程序页面把当前小程序页面重写切换到前台（多任务）B. 页面加载后只需执行一次（页面第一次载入） C. 只在页面非第一次执行时才执行（A情况的子集，页面非第一次展示时） 需求与问题逻辑1： 因为onLoad和onShow是非阻塞执行的，当我们有一个这样的需求：页面载入执行A方法，页面展示执行B、C、D方法时，A需要在BCD之前执行，此时把A放在onLoad中，BCD放在onShow中就无法实现需求 逻辑2： 还有一种需求是：页面第一次执行A，非第一次执行R-A，这里onLoad和onShow并没有非第一次的逻辑，需要手动判断。 一种实践方法下面是纯粹使用onShow代替onLoad，完成所有逻辑的示例，保证了业务逻辑的执行顺序可控。 options获取使用其他方式代替。 为了保持onShow中逻辑的清晰性，尽量使用EventChannel去替代原本onShow+globalData的逻辑。 data:{   first: true }, async onShow(){ //代替onLoad中的options的获取 const pages = getCurrentPages();   const currentPage = pages[pages.length - 1];   const options = currentPage.options;   this.funD() // C2 页面每次都调用的逻辑 if(this.data.first){     this.data.first = false;     await this.funA(); //A 仅在页面初次调用的逻辑（按需是否阻塞调用）   }else{     await this.funB(); //B 仅在页面非初次时调用的逻辑   }   await this.funC(); //C1 页面每次都调用的逻辑 } 另外一种使用实践data:{   first: true } onShow(){   this.funD() //页面每次都调用的逻辑(仅非阻塞)   if(!this.data.first){     this.funC() //仅在页面非初次时调用的逻辑   }   await this.funE() //页面每次都调用的逻辑（可阻塞，可非阻塞） }, onLoad(){   //仅在页面初次调用的逻辑 this.funA();   await this.funB(); } onReady(){   this.data.first = false; } 如有错误，恳请指出。

具体表现： [图片] 原因及影响： 多次成对回调属于Android系统行为，app层面没法规避，对开发者的逻辑没有太大影响。