背景 俗话说，产品有三宝：弹窗、浮层加引导，足以见弹窗在产品同学心目中的地位。对任意一个刚入门的前端同学来说，实现一个模态框基本都可以达到信手拈来的地步，但是，当模态框里边的内容滚动起来以后，就会出现各种各样的让人摸不着头脑的问题，其中，最出名的想必就是滚动穿透。 什么是滚动穿透？ 滚动穿透的定义：指我们滑动顶层的弹窗，但效果上却滑动了底层的内容。 具体解决方案分析如下： 改变顶层：从穿透的思路考虑，如果顶层不会穿透过去，那么问题就解决了，所以我们尝试给蒙层加catchtouchmove，但是发现部分场景无效果，那么就不再赘述了。 改变底层：既然是顶层影响了底层，要是底层不会滚动，那就没这个问题了。 如何改变底层解决该问题呢？ 不成熟方案： 底部页面最外层view设置position: fixed;页面不可滚动，但是这个时候会导致页面回到顶部。 滚动时监听滚动距离，弹窗时记录滚动位置，关闭弹窗后使用wx.pageScrollTo回滚到记录的位置。 成熟方案 使用page-meta组件，通过该组件我们可以操作Page的style样式，类似于h5里body设置overflow: hidden; 控制页面不可滚动。文档地址：https://developers.weixin.qq.com/miniprogram/dev/component/page-meta.html 使用wx.setPageStyle设置overflow: hidden， 也可以实现给Page组件设置样式。） page-meta组件： 通过该组件我们可以直接操作[代码]Page[代码]组件 ，我们给它的wxss样式overflow动态设置[代码]hidden[代码]or[代码]visible[代码]or[代码]auto[代码] 就可以控制整个页面是否可以滚动。 [图片] wx.setPageStyle方法： 调用这个api，动态设置它为hidden/auto，用于控制页面是否可滚动，主要用于页面组件内使用，比如封装好的弹窗组件，就不用单独写page-meta组件了。。 [代码]wx.setPageStyle({ style: { overflow: 'hidden' // ‘auto’ } }) [代码] 老规矩，结尾放代码片段： https://developers.weixin.qq.com/s/U6ItgQmP7upQ 拓展 支付宝小程序虽然存在page-meta组件，但是由于内核为69版本，给page设置overflow: hidden 也无法控制底部元素不可滚动，目前已联系支付宝的底层开发同学提供API控制页面disableScroll，目前正在封装Appx，近期开放。

开发者在开发小程序的时候可能会碰到一些这样的问题： 问题1  开发者工具上看效果没问题，但是在真机上测试不行？ 问题2  有用户遇到小程序功能无法使用的问题，但无法快速定位解决？ 今天我们的小故事与大家分享一些真机定位的技巧，可以解决上面两个问题。 1 vConsole开发利器和远程调试功能 针对问题1，我们提供了 vConsole 开发利器和远程调试功能，可以协助开发者在定位真机上的问题。 vConsole 的有四个Tab面板，可以先看下 Log 面板，看是否有异常信息，异常类型 thirdScriptError 是框架捕捉到的开发者的代码执行的异常，可以优先处理异常信息看是否可以解决问题。Log 面板可以看到异常出现的文件和行数。 [图片] 除了异常日志，开发者还可以通过 console.log 接口在一些关键执行路径上打日志来定位问题，这些日志会呈现在 Log 面板上。 vConsole 默认是不开启的，可以通过下面2个方法来开启： 1 开发版和体验版可以点击小程序页面右上角的...按钮打开的菜单项“打开调试”来开启 vConsole。 2 正式版没有“打开调试”的菜单项，可以先通过开发版和体验版来开启 vConsole，然后再打开正式版。或者可以预埋一个隐藏操作，比如连续点击某个 Button 多次，然后调用 API 接口 wx.setEnableDebug 来打开。 vConsole 虽然强大，但在手机上查看大量的日志信息不方便，此外，vConsole 没有断点调试、无法修改样式，定位复杂问题需要花费比较多的时间。 小程序的业务逻辑运行在 AppService 层，页面渲染在 WebView 运行，并通过微信客户端通信，因此，我们想到了可以让 AppService 运行在开发者工具，页面渲染还是在手机 WebView，两者通过网络来通信，这样借助开发者工具的调试能力，就可以实现远程调试功能。 远程调试窗口通过手机客户端扫描开发者工具上生成的二维码来打开，无需像普通手机 H5 页面调试一样，需要在手机端进行一些设置。 [图片] 打开的远程调试界面和开发者工具的模拟器的调试界面很像，需要注意的是，要在 Console 里对小程序进行调试，需要将调试的上下文切换到 VM Context 1 。 [图片] 更多的远程调试的使用方法请参考使用文档。 2 意见反馈能力 对于问题2，小程序的使用反馈来自用户投诉，这种情况用户无法联系到开发者。我们遇见过有小程序功能出现问题，用户无法使用，但投诉无门的情况，而这些问题，开发者也没有途径去收集以及处理，这就导致了小程序服务质量下降，用户流失。 为此，我们开发了“意见反馈”功能，当出现问题时，开发者可以引导用户使用“意见反馈”进行反馈，并上传日志来辅助开发者定位问题。操作过程如下： 引导用户进入小程序帐号详情页面，具体可以在小程序界面点击右上角...按钮，选择关于菜单。接着在帐号详情页面点击右上角...按钮，选择意见反馈菜单进入页面。页面可以上传图片和日志，建议用户上传异常情况的截图，以及勾选允许开发者使用小程序日志选项上传日志，反馈信息越详细，越有助于定位问题。 [图片] [图片] 如果觉得上面的操作步骤太麻烦，开发者可以通过在页面 WXML 添加下面的按钮，用户点击按钮可以直接打开“意见反馈”页面。 [图片] 开发者需要定时处理用户的反馈，这样才能保证小程序的质量。开发者可以登录小程序管理后台，进入左侧菜单客服反馈，就可以看到用户的反馈内容以及下载日志来辅助定位问题。 [图片] 为了保证日志信息足够详细，开发者需要用下面的接口在代码的关键执行路径上写日志。 [图片] wx.getLogManager 接口的更详细使用请参考文档。 希望通过这些小技巧，可以帮助大家顺畅地开发小程序。

自定义组件 why 代码的复用 在起初小程序只支持 Page 的时候，就会有这样蛋疼的问题：多个页面有相同的组件，每个页面都要复制粘贴一遍，每次改动都要全局搜索一遍，还说不准哪里改漏了就出翔了。 组件化设计 在前端项目中，组件化是很常见的方式，某块通用能力的抽象和设计，是一个必备的技能。组件的管理、数据的管理、应用状态的管理，这些在我们设计的过程中都是需要去思考的。当然你也可以说我就堆代码就好了，不过一个真正的码农是不允许自己这么随便的！ 所以，组件化是现代前端必须掌握的生存技能！ 自定义组件的实现 一切都从 Virtual DOM 说起 前面《解剖小程序的 setData》有讲过，基于小程序的双线程设计，视图层（Webview 线程）和逻辑层（JS 线程）之间通信（表现为 setData），是基于虚拟 DOM 来实现数据通信和模版更新的。 自定义组件一样的双线程，所以一样滴基于 Virtual DOM 来实现通信。那在这里，Virtual DOM 的一些基本知识（包括生成 VD 对象、Diff 更新等），就不过多介绍啦~ Shadow DOM 模型 基于 Virtual DOM，我们知道在这样的设计里，需要一个框架来支撑维护整个页面的节点树相关信息，包括节点的属性、事件绑定等。在小程序里，Exparser 承担了这个角色。 前面《关于小程序的基础库》也讲过，Exparser 的主要特点包括： 基于 Shadow DOM 模型 可在纯 JS 环境中运行 Shadow DOM 是什么呢，它就是我们在写代码时候写的自定义组件、内置组件、原生组件等。Shadow DOM 为 Web 组件中的 DOM 和 CSS 提供了封装。Shadow DOM 使得这些东西与主文档的 DOM 保持分离。 简而言之，Shadow DOM 是一个 HTML 的新规范，其允许开发者封装 HTML 组件（类似 vue 组件，将 html，css，js 独立部分提取）。 例如我们定义了一个自定义组件叫[代码]<my-component>[代码]，你在开发者工具可以见到： [图片] [代码]#shadow-root[代码]称为影子根，DOM 子树的根节点，和文档的主要 DOM 树分开渲染。可以看到它在[代码]<my-component>[代码]里面，换句话说，[代码]#shadow-root[代码]寄生在[代码]<my-component>[代码]上。[代码]#shadow-root[代码]可以嵌套，形成节点树，即称为影子树（Shadow Tree）。 像这样： [图片] Shadow Tree 拼接 既然组件是基于 Shadow DOM，那组件的嵌套关系，其实也就是 Shadow DOM 的嵌套，也可称为 Shadow Tree 的拼接。 Shadow Tree 拼接是怎么做的呢？一切又得从模版引擎讲起。 我们知道，Virtual DOM 机制会将节点解析成一个对象，那这个对象要怎么生成真正的 DOM 节点呢？数据变更又是怎么更新到界面的呢？这大概就是模版引擎做的事情了。 《前端模板引擎》里有详细描述模版引擎的机制，通常来说主要有这些： DOM 节点的创建和管理：[代码]appendChild[代码]/[代码]insertBefore[代码]/[代码]removeChild[代码]/[代码]replaceChild[代码]等 DOM 节点的关系（嵌套的处理）：[代码]parentNode[代码]/[代码]childNodes[代码] 通常创建后的 DOM 节点会保存一个映射，在更新的时候取到映射，然后进行处理（通常包括替换节点、改变内容[代码]innerHTML[代码]、移动删除新增节点、修改节点属性[代码]setAttribute[代码]） 在上面的图我们也可以看到，在 Shadow Tree 拼接的过程中，有些节点并不会最终生成 DOM 节点，例如[代码]<slot>[代码]这种。 但是，常用的前端模版引擎，能直接用在小程序里吗？ 双线程的难题 自定义组件渲染流程 双线程的设计，给小程序带来了很多便利，安全性管控力都拥有了，当然什么鬼东西都可以比作一把双刃剑，双线程也不例外。 我们知道，小程序分为 Webview 和 JS 双线程，逻辑层里是没法拿到真正的 DOM 节点，也没法随便动态变更页面的。那在这种情况下，我们要怎么去使用映射来更新模版呢（因为我们压根拿不到 Webview 节点的映射）？ 所以在双线程下，其实两个线程都需要保存一份节点信息。这份节点信息怎么来的呢？其实就是我们需要在创建组件的时候，通过事件通知的方式，分别在逻辑层和视图层创建一份节点信息。 同时，视图层里的组件是有层级关系的，但是 JS 里没有怎么办？为了维护好父子嵌套等节点关系，所以我们在 逻辑层也需要维护一棵 Shadow Tree。 那么我们自定义组件的渲染流程大概是： 组件创建。 逻辑层：先是 wxml + js 生成一个 JS 对象（因为需要访问组件实例 this 呀），然后是 JS 其中节点部分生成 Virtual DOM，拼接 Shadow Tree 什么的，最后通过底层通信通知到 视图层 视图层：拿到节点信息，然后吭哧吭哧开始创建 Shadow DOM，拼接 Shadow Tree 什么的,最后生成真实 DOM，并保留下映射关系 组件更新。 这时候我们知道，不管是逻辑层，还是视图层，都维护了一份 Shadow Tree，要怎么保证他们之间保持一致呢？ 让 JS 和 Webview 的组件保持一致 为了让两边的 Shadow Tree 保持一致，可以使用同步队列来传递信息。（这样就不会漏掉啦） 同步队列可以，每次变动我们就往队列里塞东西就好了。不过这样还会有个问题，我们也知道 setData 其实在实际项目里是使用比较频繁的，要是像 Component 的 observer 里做了 setData 这类型的操作，那不是每次变动会导致一大堆的 setDate？这样通信效率会很低吧？ 所以，其实可以把一次操作里的所有 setData 都整到一次通信里，通过排序保证好顺序就好啦。 Page 和 Component Component 是 Page 的超集 事实上，小程序的页面也可以视为自定义组件。因而，页面也可以使用[代码]Component[代码]构造器构造，拥有与普通组件一样的定义段与实例方法。但此时要求对应 json 文件中包含[代码]usingComponents[代码]定义段。 来自官方文档-Component 所以，基于 Component 是 Page 的超集，那么其实组件的渲染流程、方式，其实跟页面没多大区别，应该可以一个方式去理解就差不多啦。 页面渲染 既然页面就是组件，那其实页面的渲染流程跟组件的渲染流程基本保持一致。 视图层渲染，可以参考7.4 视图层渲染说明。 结束语 其实很多新框架新工具出来的时候，经常会让人眼前一亮，觉得哇好厉害，哇好高大上。 但其实更多时候，我们需要挖掘新事物的核心，其实大多数都是在原有的事物上增加了个新视角，从不一样的视角看，看到的就不一样了呢。作为一名码农，我们要看到不变的共性，变化的趋势。

一切始于双线程 技术选型 上一节《小程序的诞生》中，我们也提到了小程序的双线程设计。 目前来说，页面渲染的方式主要有三种： Web 渲染。 Native 原生渲染。 Web 与 Native 两者掺杂，也即我们常说的 Hybrid 渲染。 前面也说过，小程序最终的呈现形式，是 WebView + 原生组件，Hybrid 方式。我们结合之前对小程序的期望来看： 开发门槛：Web 门槛低，不过 Native 也有像 RN 这样的框架支持 体验：Native 体验比 Web 不要好太多，Hybrid 在一定程度上比 Web 接近原生体验 版本更新：Web 支持在线更新，Native 则需要打包到微信一起审核发布 管控和安全：Web 可跳转或是改变页面内容，存在一些不可控因素和安全风险 由于小程序的宿主是微信，如果用纯客户端原生技术来编写小程序 ，那小程序代码需要与微信代码一起编包，跟随微信发版本，这种方式跟开发节奏必然都是不对的。 所以方向应该是需要像 Web 技术那样，有一份随时可更新的资源包放在云端，通过下载到本地，动态执行后即可渲染出界面。 如果用纯 Web 技术来渲染小程序，在一些有复杂交互的页面上可能会面临一些性能问题。 这是因为在 Web 技术中，UI渲染跟 JavaScript 的脚本执行都在一个单线程中执行，这就容易导致一些逻辑任务抢占UI渲染的资源。 总地看来，小程序选择了 Hybrid 的渲染方式，可以用一种近似 Web 的方式来开发，并且还可以实现在线更新代码。 同时，引入原生组件有以下好处： 扩展 Web 的能力。比如像输入框组件（input, textarea）有更好地控制键盘的能力 体验更好，同时也减轻 WebView 的渲染工作 绕过 setData、数据通信和重渲染流程，使渲染性能更好 现在，我们还剩下一个很重要的问题：管控性和安全性。于是，双线程的设计被提出来了。 双线程的小程序 也不知道是哪位大佬，能想出双线程这样的模型，反正我是佩服得666的。 双线程是什么？我们先来看个官方的图： [图片] 小程序的渲染层和逻辑层分别由 2 个线程管理：渲染层的界面使用了 WebView 进行渲染，逻辑层采用 JsCore 线程运行 JS 脚本。 为什么要这么设计呢？前面提到的管控和安全，为了解决这些问题，我们需要阻止开发者使用一些浏览器提供的，诸如跳转页面、操作 DOM、动态执行脚本的开放性接口。 我们可以使用客户端系统的 JavaScript 引擎，iOS下的 JavaScriptCore 框架，安卓下腾讯 x5 内核提供的 JsCore 环境。通过提供一个沙箱环境来运行开发者的 JavaScript 代码来解决。这个沙箱环境只提供纯 JavaScript 的解释执行环境，没有任何浏览器相关接口。 这就是小程序双线程模型的由来： 逻辑层：创建一个单独的线程去执行 JavaScript，在这个环境下执行的都是有关小程序业务逻辑的代码 渲染层：界面渲染相关的任务全都在 WebView 线程里执行，通过逻辑层代码去控制渲染哪些界面。一个小程序存在多个界面，所以渲染层存在多个 WebView 线程 双线程通信 把开发者的 JS 逻辑代码放到单独的线程去运行，但在 Webview 线程里，开发者就没法直接操作 DOM。那要怎么去实现动态更改界面呢？ 前面我们知道，逻辑层和渲染层的通信会由 Native （微信客户端）做中转，逻辑层发送网络请求也经由 Native 转发。 这是不是意味着，我们可以把 DOM 的更新通过简单的数据通信来实现呢？ Virtual DOM 相信大家都已有了解，大概是这么个过程：用JS对象模拟DOM树 -> 比较两棵虚拟DOM树的差异 -> 把差异应用到真正的DOM树上。 在这里我们可以用上，如图： [图片] 在渲染层把 WXML 转化成对应的 JS 对象。 在逻辑层发生数据变更的时候，通过宿主环境提供的 setData 方法把数据从逻辑层传递到 Native，再转发到渲染层。 经过对比前后差异，把差异应用在原来的 DOM 树上，更新界面。 我们通过把 WXML 转化为数据，通过 Native 进行转发，来实现逻辑层和渲染层的交互和通信。而这样完整的一套框架，基本上都是通过小程序的基础库来完成的。 小程序的基础库 小程序的基础库是 JavaScript 编写的，它可以被注入到渲染层和逻辑层运行。主要用于： 在渲染层，提供各类组件来组建界面的元素 在逻辑层，提供各类 API 来处理各种逻辑 处理数据绑定、组件系统、事件系统、通信系统等一系列框架逻辑 由于小程序的渲染层和逻辑层是两个线程管理，两个线程各自注入了基础库。小程序的基础库不会被打包在某个小程序的代码包里边，它会被提前内置在微信客户端。 这样可以： 降低业务小程序的代码包大小 可以单独修复基础库中的 Bug，无需修改到业务小程序的代码包 Exparser 框架 Exparser 是微信小程序的组件组织框架，内置在小程序基础库中，为小程序的各种组件提供基础的支持。小程序内的所有组件，包括内置组件和自定义组件，都由 Exparser 组织管理。Exparser 特点包括： 基于 Shadow DOM 模型：模型上与 WebComponents 的 ShadowDOM 高度相似，但不依赖浏览器的原生支持，也没有其他依赖库；实现时，还针对性地增加了其他API以支持小程序组件编程。 可在纯JS环境中运行：这意味着逻辑层也具有一定的组件树组织能力。 高效轻量：性能表现好，在组件实例极多的环境下表现尤其优异，同时代码尺寸也较小。 关于基础库和 Exparser 框架，更多的也可以参考：《小程序开发指南》 结束语 这节里大概讲了小程序设计中比较重要的一个模型——双线程，关于双线程的出现、设计、数据通信，到基础库、Exparser 框架，都是一个个相关而又相互影响的选择。 关于小程序的底层框架设计，其实还涉及更多更多我们未能一时半会掌握完的内容，自定义组件、原生组件，还有他们做了很多的性能优化工作，都不是只言片语能讲完的。我们能做的，就是多去思考。