教学仓库： https://github.com/jinxuanzheng01/blog-xcx-ci-demo/tree/master，可以clone下来跟着教程一起尝试 CI流程搭建教学三部曲： 实现云构建如何接入CI（jenkins版）搭建一个版本发布管理后台 + 企业微信机器人群通知背景相信长期在做小程序的同学都有过以下经历： 只有固定的几台机器能发版，换台机器总担心出现点问题 （心力成本）多个小程序发版，切换多个仓库，甚至要用开发者工具去打开不同的项目（体力成本）频繁发版 + 发版流程琐碎 + 可能存在的多个小程序，一天的时间被机械劳动的事耗掉半天(时间成本)本文主要来分享一下我这边的一套解决，实现一键发布，统一管理，在读之前最好先看下上一篇文章，不然可能会有些阻碍 关于jenkins：https://www.jenkins.io/zh/ 案例 [图片] 这个是目前我们已经搭建好的一套服务，可以看到整个流程都做了那些事？ 拉取代码询问当前需要变更的版本号构建（gulp, webpack，npm）存储当前版本镜像到静态资源服务器版本信息插入数据库更改后的版本文件提交到git仓库 其中红色为必须项，黑色看情况添加，如果你想也可以加入你想要添加的任何环节，下图是我们的版本发布管理后台的界面，存储的mysql的版本信息大概是这个样子： [图片] 关于管理后台第三章再讲，本文先着重描述怎么接入jenkins Let’go首先你需要一台云服务器用来搭建jenkins环境，推荐2核4g，不过1核2g也能跑 安装javajenkins依赖于java环境，所以先安装java yum install -y java-1.8.0-openjdk.x86_64 安装jenkins包官方教程： https://www.jenkins.io/zh/doc/book/installing/ 仓库地址： http://pkg.jenkins-ci.org/redhat-stable/ sudo wget -O /etc/yum.repos.d/jenkins.repo https://pkg.jenkins.io/redhat-stable/jenkins.repo sudo rpm --import https://pkg.jenkins.io/redhat-stable/jenkins.io.key yum install jenkins # 运行 service jenkins start 运行成功后访服务器端口号8080 [图片] 如果想修改端口号 vim /etc/sysconfig/jenkins, 找到JENKINS_PORT，修改后执行 [代码]service jenkins restart[代码] 即可 [图片] 关于插件安装个人比较懒，点推荐快速过，后面有用到的一些插件慢慢会介绍 [图片] 插件装完，中间需要创建管理员账号，一路确定最终安装成功 [图片] 创建流水线pipeline首先创建一个任务， 这里选择流水线（有兴趣可以了解下其他项）， 点击确定 [图片] 点击流水线找到编辑script的地方 [图片] [图片] 这里可以选择在服务器上编写，还是从项目代码中读取jenkinsfile文件，我这里为了方便调试直接在jenkins机器上编写了 pipeline script流水线语法官方教程： https://www.jenkins.io/zh/doc/book/pipeline/，里面讲的比较详细，可以先按下面的代码运行，遇到问题再查教程 流水线结构写流水线之前，先想好我们整个发布流程需要做什么？ 以当前例的话，大致分为5个环节: 拉取代码 询问需要更改的版本号安装npm包执行发布提交修改的版本号信息到仓库 每一个环节都是一个stage，先把stage列好，接下来我们一个一个补充 pipeline { agent any stages { // 拉取git代码 stage('git pull') { steps { } } // 询问当前版本信息 stage('inquirer version') { steps { } } // 构建 stage('build') { steps { } } // 推送版本信息到git仓库 stage('push version2git') { steps { } } } } 流水线语法 很多插件的语法使用还是比较复杂和琐碎的，这里提供了一个自动生成pipieline语法的功能 [图片] 以git为例，会自动生成相应的语法，避免很多查文档的时间 [图片] 拉取git代码根据上文所述，我们需要生成流水线脚本，但是想要让仓库和jenkins建立ssh链接，需要配置git仓库的公钥和jenkins的私钥凭据 配置git仓库公钥jenkins拉取git仓库代码，为了方便需要配下ssh秘钥 # 生成秘钥（没有要求一路回车即可） ssh-keygen -t rsa -C "616347058@qq.com" # 查看生成的ssh文件 cd ~/.ssh && ls # 一般会有id_rsa id_rsa.pub两个文件, 一个私钥一个公钥 点击个人头像点击setting找到ssh，粘贴 [代码]id_rsa.pub[代码] 里的内容到输入框，点击add添加完成 [图片] [图片] 配置jenkins私钥除了在git上配置公钥外，还需要在jenkins上配置下凭据，点击添加 [图片] 选择类型为ssh username，其他input的可以自己定一下的，这里需要一下，关于private项填的是私钥，需要复制[代码]id_rsa[代码]的内容，填写完成后点击添加，并在 Credentials 一栏选择刚才添加的证书 [图片] 当前页面没有显示红字即为成功 [图片] pipeline code// 拉取git代码 stage('git pull') { steps { git branch: 'test', credentialsId: '1', url: 'git@github.com:jinxuanzheng01/blog-xcx-ci-demo.git' } } 添加到指定位置后，点击保存，尝试构建一次查看是否成功，点左下角#5可以查看当前构建进程 [图片] 点击console output可以查看当前log，workspaces可以查看当前工作空间 [图片] 可以看到当前工作空间为仓库代码 [图片] 询问当前版本信息jenkins是不支持交互式命令的，所以需要换一种实现，查了下文档jenkins是有api支持的，方法名为 [代码]input[代码]，不过在进行调用之前需要获取之前的版本信息，即读取version.config.json这个文件，整体代码如下： // 询问当前版本信息 stage('inquirer version') { steps { script { // 读取版本信息 def versionJson = readJSON file: './version.config.json', text: '' // 设置问题描述 def userInput = input( id: 'versionInput', message: '请设置版本信息', parameters: [ [defaultValue: versionJson.version, description: '设置版本号', name: 'VERSION', $class: 'TextParameterDefinition'], [defaultValue: 'jenkins CI is upload trial version as: ' + new Date().format('yyyy-MM-dd HH:mm:ss'), description: '设置版本描述(please use english)', name: 'VERSIONDESC', $class: 'TextParameterDefinition'] ]) // 设置全局变量 env.VERSION = userInput.VERSION; env.VERSIONDESC = userInput.VERSIONDESC; // 重写本地版本文件（为后续进行版本提交做准备） writeJSON file: './version.config.json', json: [version: env.VERSION, versionDesc: env.VERSIONDESC], pretty: 4; } } } 运行下, 会发现会提示等待，鼠标点击后弹出模态框，可以看到里面有从本地文件里提取出来的上个版本的信息，手动修改下即可 [图片] 注： readJSON和 writeJSON方法依赖 Pipeline Utility Steps 这个插件，没有的话会报错 执行构建这里实际都是构建流程，直接统一用一个“build stage” 即可， 这里步骤很简单，可以想一下从git clone下来一个项目应该干什么，这里实际就是在做这样一件事情 // 构建 stage('build') { steps { sh "npm install" sh "npm run build" } } 不过这里依赖node环境，需要先处理下，不然会报npm not found   安装nodejs环境这里的运行环境和本机没有关系，类似于一个沙盒，所以如果要安装node环境需要安装Config File Provider Plugin和NodeJS Plugin这两个插件 配置全局工具安装完成后添加全局工具，找到"系统管理 -> 全局工具配置 -> NodeJS" ，点击nodejs安装，默认项即可，点击保存，重启jenkins服务，回到服务器，输入命令 [代码]service jenkins restart[代码]  [图片] pipeline code // 构建 stage('build') { steps { nodejs('NodeJS 14.3.0') { sh "npm install" sh "npm run build" } } } 上传成功这时候如果没问题的话代码应该已经发布到体验版了，这里如果报ip错误记得去微信公众后台添加一下上传的ip白名单 [图片] [图片] 提交新的版本号信息到仓库pipeline code基本就是将之前手动输入的命令写到脚本里 // 推送版本信息到git仓库 stage('push version2git') { steps { sh "git config --local user.name ${GIT_USER_NAME} && git config --local user.email ${GIT_USER_EMAIL}" sh "git add version.config.json" sh "git commit -m 'docs: 更改版本号为${VERSION}'" sh "git push origin ${BRANCH_NAME}" } } 关于上面代码中的"${}"，其实是预设的环境变量，我们可以把一些固定的东西提出来，避免硬编码，例如： pipeline { agent any // 环境变量 environment { GIT_USER_NAME = 'jenkinsCI' GIT_USER_EMAIL = 'test@163.com' GIT_ADDRESS = 'git@github.com:jinxuanzheng01/blog-xcx-ci-demo.git' BRANCH_NAME = 'master' } } 更改jenkins账号权限直接进行push的话，git会报权限不足，这里倒不是因为ssh秘钥有问题，而是jenkins在执行的时候使用的不是linux机器的root权限，而是一个jenkins的账号 [图片] 所以最快速的做法是将jenkins运行环境修改为root权限 # 打开配置文件 vim /etc/sysconfig/jenkins # 修改jenkins_user为root, 默认为jenkins $JENKINS_USER="root" # 修改相关文件夹权限组 chown -R root:root /var/lib/jenkins chown -R root:root /var/cache/jenkins chown -R root:root /var/log/jenkins # 重启jenkins service jenkins restart 运行pipeline重新构建，jenkins无报错，查看git仓库，执行成功 [图片] Running success到此为止，整个pipeline已经work，你可以很轻松的尝试一键发布小程序 [图片] 尤其是有多个小程序项目的时候，可以单独建个分组，方便集中管理，再也不需要手动切入不同的仓库，甚至使用小程序开发者工具去打开各个小程序，大概如下 [图片] 项目集中管理不香么？ Tips: jenkins流水线代码已经放到仓库里了，地址 https://github.com/jinxuanzheng01/blog-xcx-ci-demo/blob/master/Jenkinsfile 额外补充权限管理jenkins有很多的功能插件，比如权限管理，这个还是个比较刚需的功能，可以自行Google下并不难 发送http请求在pipeline中有时候需要去请求一些我们的其他服务，可以使用HTTP Request Plugin这个插件，文档地址：https://plugins.jenkins.io/http_request/里面有一些demo npm切换私有仓库方法一:  npm可以直接用npm_token登录 方法二：项目内设置.npmrc，填写私有仓库 + 用户信息 jenkins使用docker报权限不足[图片]修改jenkins账号权限为root权限即可，上文有写，也可以直接修改docker.sock这个文件权限，如 [代码]chmod 777 /var/run/docker.sock[代码]  手动安装jenkins插件使用jenkins的插件管理安装插件很慢，有的时候还会失败，这里提供一个手动安装的方法 jenkins插件库： http://updates.jenkins-ci.org/download/plugins/config-file-provider/ 搜索需要的插件下载（一般是*.hpi格式的），打开jenkins "系统管理 -> 插件管理 -> 高级"，选择下载的文件上传即可 [图片]

众所周知，小程序当中有一类特殊的内置组件——原生组件，这类组件有别于 WebView 渲染的内置组件，他们是交由原生客户端渲染的。原生组件作为 Webview 的补充，为小程序带来了更丰富的特性和更高的性能，但同时由于脱离 Webview 渲染也给开发者带来了不小的困扰。在小程序引入「同层渲染」之前，原生组件的层级总是最高，不受 [代码]z-index[代码] 属性的控制，无法与 [代码]view[代码]、[代码]image[代码] 等内置组件相互覆盖， [代码]cover-view[代码] 和 [代码]cover-image[代码] 组件的出现一定程度上缓解了覆盖的问题，同时为了让原生组件能被嵌套在 [代码]swiper[代码]、[代码]scroll-view[代码] 等容器内，小程序在过去也推出了一些临时的解决方案。但随着小程序生态的发展，开发者对原生组件的使用场景不断扩大，原生组件的这些问题也日趋显现，为了彻底解决原生组件带来的种种限制，我们对小程序原生组件进行了一次重构，引入了「同层渲染」。 相信已经有不少开发者已经在日常的小程序开发中使用了「同层渲染」的原生组件，那么究竟什么是「同层渲染」？它背后的实现原理是怎样的？它是解决原生组件限制的银弹吗？本文将会为你一一解答这些问题。 什么是「同层渲染」? 首先我们先来了解一下小程序原生组件的渲染原理。我们知道，小程序的内容大多是渲染在 WebView 上的，如果把 WebView 看成单独的一层，那么由系统自带的这些原生组件则位于另一个更高的层级。两个层级是完全独立的，因此无法简单地通过使用 [代码]z-index[代码] 控制原生组件和非原生组件之间的相对层级。正如下图所示，非原生组件位于 WebView 层，而原生组件及 [代码]cover-view[代码] 与 [代码]cover-image[代码] 则位于另一个较高的层级： [图片] 那么「同层渲染」顾名思义则是指通过一定的技术手段把原生组件直接渲染到 WebView 层级上，此时「原生组件层」已经不存在，原生组件此时已被直接挂载到 WebView 节点上。你几乎可以像使用非原生组件一样去使用「同层渲染」的原生组件，比如使用 [代码]view[代码]、[代码]image[代码] 覆盖原生组件、使用 [代码]z-index[代码] 指定原生组件的层级、把原生组件放置在 [代码]scroll-view[代码]、[代码]swiper[代码]、[代码]movable-view[代码] 等容器内，通过 [代码]WXSS[代码] 设置原生组件的样式等等。启用「同层渲染」之后的界面层级如下图所示： [图片] 「同层渲染」原理 你一定也想知道「同层渲染」背后究竟采用了什么技术。只有真正理解了「同层渲染」背后的机制，才能更高效地使用好这项能力。实际上，小程序的同层渲染在 iOS 和 Android 平台下的实现不同，因此下面分成两部分来分别介绍两个平台的实现方案。 iOS 端 小程序在 iOS 端使用 WKWebView 进行渲染的，WKWebView 在内部采用的是分层的方式进行渲染，它会将 WebKit 内核生成的 Compositing Layer（合成层）渲染成 iOS 上的一个 WKCompositingView，这是一个客户端原生的 View，不过可惜的是，内核一般会将多个 DOM 节点渲染到一个 Compositing Layer 上，因此合成层与 DOM 节点之间不存在一对一的映射关系。不过我们发现，当把一个 DOM 节点的 CSS 属性设置为 [代码]overflow: scroll[代码] （低版本需同时设置 [代码]-webkit-overflow-scrolling: touch[代码]）之后，WKWebView 会为其生成一个 [代码]WKChildScrollView[代码]，与 DOM 节点存在映射关系，这是一个原生的 [代码]UIScrollView[代码] 的子类，也就是说 WebView 里的滚动实际上是由真正的原生滚动组件来承载的。WKWebView 这么做是为了可以让 iOS 上的 WebView 滚动有更流畅的体验。虽说 [代码]WKChildScrollView[代码] 也是原生组件，但 WebKit 内核已经处理了它与其他 DOM 节点之间的层级关系，因此你可以直接使用 WXSS 控制层级而不必担心遮挡的问题。 小程序 iOS 端的「同层渲染」也正是基于 [代码]WKChildScrollView[代码] 实现的，原生组件在 attached 之后会直接挂载到预先创建好的 [代码]WKChildScrollView[代码] 容器下，大致的流程如下： 创建一个 DOM 节点并设置其 CSS 属性为 [代码]overflow: scroll[代码] 且 [代码]-webkit-overflow-scrolling: touch[代码]； 通知客户端查找到该 DOM 节点对应的原生 [代码]WKChildScrollView[代码] 组件； 将原生组件挂载到该 [代码]WKChildScrollView[代码] 节点上作为其子 View。 [图片] 通过上述流程，小程序的原生组件就被插入到 [代码]WKChildScrollView[代码] 了，也即是在 [代码]步骤1[代码] 创建的那个 DOM 节点对应的原生 ScrollView 的子节点。此时，修改这个 DOM 节点的样式属性同样也会应用到原生组件上。因此，「同层渲染」的原生组件与普通的内置组件表现并无二致。 Android 端 小程序在 Android 端采用 chromium 作为 WebView 渲染层，与 iOS 不同的是，Android 端的 WebView 是单独进行渲染而不会在客户端生成类似 iOS 那样的 Compositing View (合成层)，经渲染后的 WebView 是一个完整的视图，因此需要采用其他的方案来实现「同层渲染」。经过我们的调研发现，chromium 支持 WebPlugin 机制，WebPlugin 是浏览器内核的一个插件机制，主要用来解析和描述embed 标签。Android 端的同层渲染就是基于 [代码]embed[代码] 标签结合 chromium 内核扩展来实现的。 [图片] Android 端「同层渲染」的大致流程如下: WebView 侧创建一个 [代码]embed[代码] DOM 节点并指定组件类型； chromium 内核会创建一个 [代码]WebPlugin[代码] 实例，并生成一个 [代码]RenderLayer[代码]； Android 客户端初始化一个对应的原生组件； Android 客户端将原生组件的画面绘制到步骤2创建的 [代码]RenderLayer[代码] 所绑定的 [代码]SurfaceTexture[代码] 上； 通知 chromium 内核渲染该 [代码]RenderLayer[代码]； chromium 渲染该 [代码]embed[代码] 节点并上屏。 [图片] 这样就实现了把一个原生组件渲染到 WebView 上，这个流程相当于给 WebView 添加了一个外置的插件，如果你有留意 Chrome 浏览器上的 pdf 预览，会发现实际上它也是基于 [代码]<embed />[代码] 标签实现的。 这种方式可以用于 map、video、canvas、camera 等原生组件的渲染，对于 input 和 textarea，采用的方案是直接对 chromium 的组件进行扩展，来支持一些 WebView 本身不具备的能力。 对比 iOS 端的实现，Android 端的「同层渲染」真正将原生组件视图加到了 WebView 的渲染流程中且 embed 节点是真正的 DOM 节点，理论上可以将任意 WXSS 属性作用在该节点上。Android 端相对来说是更加彻底的「同层渲染」，但相应的重构成本也会更高一些。 「同层渲染」 Tips 通过上文我们已经了解了「同层渲染」在 iOS 和 Android 端的实现原理。Android 端的「同层渲染」是基于 chromium 内核开发的扩展，可以看成是 webview 的一项能力，而 iOS 端则需要在使用过程中稍加注意。以下列出了若干注意事项，可以帮助你避免踩坑： Tips 1. 不是所有情况均会启用「同层渲染」 需要注意的是，原生组件的「同层渲染」能力可能会在特定情况下失效，一方面你需要在开发时稍加注意，另一方面同层渲染失败会触发 [代码]bindrendererror[代码] 事件，可在必要时根据该回调做好 UI 的 fallback。根据我们的统计，目前同层失败率很低，也不需要太过于担心。 对 Android 端来说，如果用户的设备没有微信自研的 [代码]chromium[代码] 内核，则会无法切换至「同层渲染」，此时会在组件初始化阶段触发 [代码]bindrendererror[代码]。而 iOS 端的情况会稍复杂一些：如果在基础库创建同层节点时，节点发生了 WXSS 变化从而引起 WebKit 内核重排，此时可能会出现同层失败的现象。解决方法：应尽量避免在原生组件上频繁修改节点的 WXSS 属性，尤其要尽量避免修改节点的 [代码]position[代码] 属性。如需对原生组件进行变换，强烈推荐使用 [代码]transform[代码] 而非修改节点的 [代码]position[代码] 属性。 Tips 2. iOS 「同层渲染」与 WebView 渲染稍有区别 上文我们已经了解了 iOS 端同层渲染的原理，实际上，WebKit 内核并不感知原生组件的存在，因此并非所有的 WXSS 属性都可以在原生组件上生效。一般来说，定位 (position / margin / padding) 、尺寸 (width / height) 、transform (scale / rotate / translate) 以及层级 (z-index) 相关的属性均可生效，在原生组件外部的属性 (如 shadow、border) 一般也会生效。但如需对组件做裁剪则可能会失败，例如：[代码]border-radius[代码] 属性应用在父节点不会产生圆角效果。 Tips 3. 「同层渲染」的事件机制 启用了「同层渲染」之后的原生组件相比于之前的区别是原生组件上的事件也会冒泡，意味着，一个原生组件或原生组件的子节点上的事件也会冒泡到其父节点上并触发父节点的事件监听，通常可以使用 [代码]catch[代码] 来阻止原生组件的事件冒泡。 Tips 4. 只有子节点才会进入全屏 有别于非同层渲染的原生组件，像 [代码]video[代码] 和 [代码]live-player[代码] 这类组件进入全屏时，只有其子节点会被显示。 [图片] 总结 阅读本文之后，相信你已经对小程序原生组件的「同层渲染」有了更深入的理解。同层渲染不仅解决了原生组件的层级问题，同时也让原生组件有了更丰富的展示和交互的能力。下表列出的原生组件都已经支持了「同层渲染」，其他组件（ textarea、camera、webgl 及 input）也会在近期逐步上线。现在你就可以试试用「同层渲染」来优化你的小程序了。 支持同层渲染的原生组件 最低版本 video v2.4.0 map v2.7.0 canvas 2d（新接口） v2.9.0 live-player v2.9.1 live-pusher v2.9.1

基于[代码]Taro[代码]与网易云音乐api开发，技术栈主要是：[代码]typescript+taro+taro-ui+react-hooks+redux[代码],目前主要是着重小程序端的展示，主要也是借此项目强化下上述几个技术栈的使用，通过这个项目也可以帮助你快速使用[代码]Taro[代码]开发一个属于你自己的小程序～ [图片] [图片] [图片] github地址：taro-music，感兴趣的话可以[代码]star[代码]关注下，功能会进行持续完善 快速开始 首先需要在src目录下创建一个config.ts,可以根据自己的需要将其替换成线上地址，接口服务是使用的NeteaseCloudMusicApi [代码]export const baseUrl: string = 'http://localhost:3000' // 这里的配置的这个url是后端服务的请求地址 [代码] 在运行本项目前，请先确保已经全局安装了Taro，安装可见官网指导 [代码]启动后端接口服务 git clone https://github.com/Binaryify/NeteaseCloudMusicApi.git cd NeteaseCloudMusicApi npm i npm run start 接下来启动前端项目 git clone https://github.com/lsqy/taro-music.git cd taro-music npm i npm run dev:weapp [代码] 功能列表 用户登陆 退出登陆 我的关注列表 我的粉丝列表 我的动态列表 最近播放列表 我的电台 我的收藏 推荐歌单 推荐电台 推荐电台 我创建的歌单列表 我收藏的歌单列表 共用的歌单详情列表 歌曲播放页面 歌词滚动 歌曲切换播放模式（随机播放/单曲循环/顺序播放） 切换上一首/下一首 喜欢/取消喜欢某首歌曲 评论列表 统一的播放组件，方便进行切换页面后可以随时进入到播放页面 目录结构简要介绍 这里主要介绍下[代码]src[代码]目录，因为开发主要是在这个目录下进行的 [代码]- src - actions // `redux`中的相关异步操作在这里进行 - assets // 静态资源目录，这里引入了所需的图片资源，以及`fontawesome`字体图标资源 - components // 封装的项目中可复用的组件，目前只是抽象了`CLoading`(加载效果组件)、`CLyric`(歌词组件)、`CMusic`(正在播放组件)、`CSlide`(滑块组件)、`CTitle`、`CUserListItem` - constants // 项目中的常量定义，目前定义了`typescript`的公共定义、`reducers`的名称定义、状态码的定义 - pages // 项目中的业务页面都在这个目录中 - reducers // `redux`中的相关同步操作在这里进行 - services // 可复用的服务可以放在这个目录中，目前只是封装了接口请求的公共服务，可以根据自己项目的需要进行其他服务的扩充 - store // redux的初始文件 - utils // 可以复用的工具方法可以放到这个目录当中，目前封装了格式化、歌词解析的相关方法 - decorators // 抽象的装饰器，主要为了解决在切换页面之后仍然可以继续保持播放状态，因为目前`taro`不支持全局组件 - app.scss // 全局样式 - app.tsx // 全局入口文件 - base.scss // 基础样式 - config.ts // 项目的全局配置，目前只是配置了`baseUrl`是后端服务的基准请求地址 [代码] todo 复用的评论列表 搜索功能 [代码]react-hooks[代码]重构部分功能 最近更新 加入搜索功能（有待进一步完善） 加入了视频播放（有待进一步完善） [图片] 效果图预览 下面简要列出几张效果图 [图片] [图片] [图片] 有待完善部分 还有一些功能点以及细节都还有待进一步完善，目前先把大致主要的功能进行了下实现，当然如果发现什么问题，欢迎能够提交[代码]issues[代码],发现之后我会及时进行更正,欢迎 [代码]star[代码] 和 [代码]fork[代码]，感谢大家支持🙏。 文章首发自个人博客基于Taro与typescript开发的网易云音乐小程序

正文从下面开始。 今天的小技巧是使用纯 CSS 生成火焰，逼真一点的火焰。 嗯，长什么样子？在 CodePen 上输入关键字 [代码]CSS Fire[代码]，能找到这样的： [图片] 或者这样的： [图片] 我们希望，仅仅使用 CSS ，效果能再更进一步吗？能不能是这样子： [图片] 如何实现 嗯，我们需要使用 [代码]filter[代码] + [代码]mix-blend-mode[代码] 的组合来完成。 很多 CSS 华而不实的效果都是 [代码]filter[代码] + [代码]mix-blend-mode[代码]，很有意思，但是业务中根本用不上，当然多了解了解总没坏处。 如上图，整个蜡烛的骨架， 除去火焰的部分很简单，掠过不讲。主要来看看火焰这一块如何生成，并且如何赋予动画效果。 Step 1: filter blur && filter contrast 模糊滤镜叠加对比度滤镜产生的融合效果。 单独将两个滤镜拿出来，它们的作用分别是： [代码]filter: blur()[代码]： 给图像设置高斯模糊效果。 [代码]filter: contrast()[代码]： 调整图像的对比度。 但是，当他们“合体”的时候，产生了奇妙的融合现象。 先来看一个简单的例子： [图片] 仔细看两圆相交的过程，在边与边接触的时候，会产生一种边界融合的效果，通过对比度滤镜把高斯模糊的模糊边缘给干掉，利用高斯模糊实现融合效果。 利用上述 [代码]filter blur & filter contrast[代码]，我们要先生成一个类似火焰形状的三角形。（略去过程） 这里类似火焰形状的三角形的具体实现过程，在这篇文章有详细的讲解：你所不知道的 CSS 滤镜技巧与细节 [图片] 父元素添加 [代码]filter: blur(5px) contrast(20)[代码]，会变成这样： [图片] Step 2: 火焰粒子动画 看着已经有点样子了，接下来是火焰动画，我们先去掉父元素的 [代码]filter: blur(5px) contrast(20)[代码] ，然后继续 。 这里也是利用了 [代码]filter[代码] 的融合效果，我们在上述火焰中，利用 SASS 随机均匀分布大量大小不一的圆形棕色 div ，隐匿在火焰三角内部，大概是这样： [图片] 接下来，我们再利用 SASS，给中间每个小圆赋予一个从下往上逐渐消失的动画，并且均匀赋予不同的 [代码]animation-delay[代码]，看起来会是这样： [图片] OK，最重要的一步，我们再把父元素的 [代码]filter: blur(5px) contrast(20)[代码] 打开，神奇的火焰效果就出来了： [图片] Step 3: mix-blend-mode 润色 当然，上述效果已经很不错了。经过各种尝试，调整参数，最后我发现加上 [代码]mix-blend-mode: screen[代码] 混合模式，效果更好，得到头图上面的最终效果如下： [图片] 完整源码在我的 CodePen 上：CodePen Demo – CSS Fire 另外一些效果 当然，掌握了这种方法后，这种生成火焰的技巧也可以迁移到其他效果去。下图是我鼓捣到另外一个小 Demo，当 hover 到元素的时候，产生火焰效果： [图片] CodePen Demo – Hover Fire 嗯，这些其实都是对滤镜及混合模式的一些搭配运用。按照惯例，肯定有人会留言喷了，整这些花里胡哨的有什么用，性能又不好，业务中敢上不把你的腿给打骨折。 [图片] 于我而言，虚心接受各种批评质疑及各种不同的观点，当然我是觉得搞技术一方面是实用，另一方面是兴趣使然，自娱自乐。希望喷子绕道~ 回到正题，了解了这种黏糊糊湿答答的技巧后，还可以折腾出其他很多有意思的效果，当然可能需要更多的去尝试，如下面使用一个标签实现的滴水效果： [图片] CodePen Demo – 单标签实现滴水效果 值得注意的细节点 动画虽然美好，但是具体使用的过程中，仍然有一些需要注意的地方： CSS 滤镜可以给同个元素同时定义多个，例如 [代码]filter: blur(5px) contrast(150%) brightness(1.5)[代码] ，但是滤镜的先后顺序不同产生的效果也是不一样的； 也就是说，使用 [代码]filter: blur(5px) contrast(150%) brightness(1.5)[代码] 和 [代码]filter: brightness(1.5) contrast(150%) blur(5px)[代码] 处理同一张图片，得到的效果是不一样的，原因在于滤镜的色值处理算法对图片处理的先后顺序。 滤镜动画需要大量的计算，不断的重绘页面，属于非常消耗性能的动画，使用时要注意使用场景。记得开启硬件加速及合理使用分层技术； [代码]blur()[代码] 混合 [代码]contrast()[代码] 滤镜效果，设置不同的颜色会产生不同的效果，这个颜色叠加的具体算法暂时没有找到很具体的规则细则，使用时比较好的方法是多尝试不同颜色，观察取最好的效果； 细心的读者会发现上述效果都是基于黑色底色进行的，动手尝试将底色改为白色，效果会大打折扣。 最后 本文只是简单的介绍了整个思路过程，许多 CSS 代码细节，调试过程没有展现出来。主要几个 CSS 属性默认大家已经掌握了大概，阅读后可以自行去了解补充更多细节： [代码]filter[代码] [代码]mix-blend-mode[代码] 更多精彩 CSS 技术文章汇总在我的 Github – iCSS ，持续更新，欢迎点个 star 订阅收藏。 好了，本文到此结束，希望对你有帮助 😃 如果还有什么疑问或者建议，可以多多交流，原创文章，文笔有限，才疏学浅，文中若有不正之处，万望告知。 最后，新开通的公众号求关注，形式希望是更短的篇幅，质量更高一些的技巧类文章，包括但不局限于 CSS： [图片]

点击查看：小打卡 | 如何基于微信原生构建应用级小程序底层架构（上）装饰模式[图片]                                            可能有朋友会好奇装饰器和我们接下来要做的原生函数扩展有什么关系？ 先看下装饰模式的定义：在不改变原函数的基础上，附加一些额外的功能 方便更好的理解 创建一个函数，然后将存在originF这个变量里，并对它重新赋值，最后执行，最后的执行直接结果是什么？ hello world!! 这样做的好处是什么，我们对函数f添加了一个新的功能，但是我们没有对原函数进行任何的修改 那么对于小程序的应用 照猫画虎一下，同样的将小程序原生的Page函数存起来，再重新赋值，看下结果，发现Page执行的时候每次都会console这句话，我这里有两个未分包的页面，就执行了2次 [图片]                                            回归到刚开始需要解决的问题，“多个页面pv，uv如何监控，不可能每个页面都要手动收集”， pv怎么算，pv的意思是页面浏览量，也就是需要页面生成时，对应到小程序生命周期就是onLoad 刚才我们做到了每个Page执行时添加功能，但是怎么在onLoad时进行数据统计呢？ 同样的可以用装饰函数修饰page里面的函数方法 [图1] 这个data就是我们实际在pages下写的业务逻辑对象，我们先拿到该页面的key名来进行遍历，首先排除掉非函数，拿到onLoad函数，这时候对它进行扩展，这时候每一个页面执行onLoad的时候都会console一次字符串，当然也可以替换为你想要的任何功能 [图2] 其实我们可以再优化一下，比如抽出一个对象，将你想要装饰的函数写入其中，如果原函数存在则进行装饰，如果不存在则直接赋值，这个抽出来的对象其实可以算是另一种继承方式的实现 它的意义在于[图片]                                            帮助我们开辟了一块公有空间，帮助我们扩展Page对象，并且可以劫持任意方法，在不修改原业务函数代码的情况下增加新的逻辑 其次也是最重要的是，我们完全不需要处理历史包袱 一个应用场景[图片]                                            左边是微信原生的分享方法 遇到的一些问题： 不便于扩展，多个分享策略时，代码块过大，并且分享的通用数据需要每个页面单独处理，例如统计回流信息需要的分享页面信息，事件信息 右边是依赖于我们刚刚开辟的公有空间里填写的公共方法，函数很简单，获得参数，获得页面分享策略，执行，顺便还做了obj转url的处理，避免了纯url书写长路径时的尴尬 思考[图片]                                            既然能扩展Page对象，那么App，Component甚至wx全局对象下的方法呢？ 有兴趣的朋友可以下来想一下 跨页面 / 多页面事件通知[图片]                                            我这边简单提一下跨页面通知的问题，这个应该算是很多小程序开发者遇到的通用问题，我问过的一些人，大部分是使用下面这两种方法，一种是getCurrentPages 页面栈队列，二种onShow upData global里的存储的数据，不管哪一种在业务复杂的情况下都会引起一定的问题，比如第一种的多级入口，第二种的话属于无效判断和及时性 小打卡这边用的简版的event Bus，一个只有80行代码的订阅方法， 左图是一个简单的示例，大致上就是分两种角色，订阅者和发布者，中间依靠任务队列联系，每次发布者推送消息，订阅者都会收到通知和相应的数据 [图片]                                            其实单纯的event bus也有很多的问题，比如：业务复杂情况下过于频繁，对业务代码侵入频繁，可以想像一下到处都是on，off, emit场景 解绑需要树立规范，但是人总是会犯错，容易绑定后忘记解绑或重复绑定的问题，比较浪费内存，对性能也有消耗 结合公共空间我们已知可以对生命周期进行扩展的时候怎么去解决这个问题 其实订阅必然是和页面结合，因为在页面不存在的情况下，发送通知也不会有反馈， 如何证明页面存在自然是onLoad 和 onUnload 按照这个逻辑我们只需要在onLoad和onShow做些处理即可 [图1] 先看右侧业务代码，按照策略注册了一个函数集合，在执行onLoad时，自动将业务内的onRss函数遍历，自定绑定订阅，并推到一个缓存数组内 onUnload时遍历缓存，自动解绑 这时订阅与页面的生命周期强绑定，我们不再需要处理解绑事件，也不需要在业务内插入订阅代码，只需要管理好当前页面的订阅策略即可 技术选型[图片]                                            没有哪一种一定正确的方案，在选型的时候可能需要考虑到上面大致6种元素, 总之选择最适合自己团队方案非常重要 一些小贴士：开发要尽量避免过度设计, 应根据实际需求, 比如之前在写现在这个简版的event bus库的时候设计了很多奇奇怪怪的 功能，现在2年过去还没用到  小程序和浏览器，node本质上是相通的，可以多借鉴和参考 The End今天我的分享就到此结束，算是这段时间对小程序开发上的一点心得体会，谢谢 [图片]                                           

最近前端届多端框架频出，相信很多有代码多端运行需求的开发者都会产生一些疑惑：这些框架都有什么优缺点？到底应该用哪个？ 作为 Taro 开发团队一员，笔者想在本文尽量站在一个客观公正的角度去评价各个框架的选型和优劣。但宥于利益相关，本文的观点很可能是带有偏向性的，大家可以带着批判的眼光去看待，权当抛砖引玉。 那么，当我们在讨论多端框架时，我们在谈论什么： 多端 笔者以为，现在流行的多端框架可以大致分为三类： 1. 全包型 这类框架最大的特点就是从底层的渲染引擎、布局引擎，到中层的 DSL，再到上层的框架全部由自己开发，代表框架是 Qt 和 Flutter。这类框架优点非常明显：性能（的上限）高；各平台渲染结果一致。缺点也非常明显：需要完全重新学习 DSL（QML/Dart），以及难以适配中国特色的端：小程序。 这类框架是最原始也是最纯正的的多端开发框架，由于底层到上层每个环节都掌握在自己手里，也能最大可能地去保证开发和跨端体验一致。但它们的框架研发成本巨大，渲染引擎、布局引擎、DSL、上层框架每个部分都需要大量人力开发维护。 2. Web 技术型 这类框架把 Web 技术（JavaScript，CSS）带到移动开发中，自研布局引擎处理 CSS，使用 JavaScript 写业务逻辑，使用流行的前端框架作为 DSL，各端分别使用各自的原生组件渲染。代表框架是 React Native 和 Weex，这样做的优点有： 开发迅速 复用前端生态 易于学习上手，不管前端后端移动端，多多少少都会一点 JS、CSS 缺点有： 交互复杂时难以写出高性能的代码，这类框架的设计就必然导致 [代码]JS[代码] 和 [代码]Native[代码] 之间需要通信，类似于手势操作这样频繁地触发通信就很可能使得 UI 无法在 16ms 内及时绘制。React Native 有一些声明式的组件可以避免这个问题，但声明式的写法很难满足复杂交互的需求。 由于没有渲染引擎，使用各端的原生组件渲染，相同代码渲染的一致性没有第一种高。 3. JavaScript 编译型 这类框架就是我们这篇文章的主角们：[代码]Taro[代码]、[代码]WePY[代码] 、[代码]uni-app[代码] 、 [代码]mpvue[代码] 、 [代码]chameleon[代码]，它们的原理也都大同小异：先以 JavaScript 作为基础选定一个 DSL 框架，以这个 DSL 框架为标准在各端分别编译为不同的代码，各端分别有一个运行时框架或兼容组件库保证代码正确运行。 这类框架最大优点和创造的最大原因就是小程序，因为第一第二种框架其实除了可以跨系统平台之外，也都能编译运行在浏览器中。(Qt 有 Qt for WebAssembly, Flutter 有 Hummingbird，React Native 有 [代码]react-native-web[代码], Weex 原生支持) 另外一个优点是在移动端一般会编译到 React Native/Weex，所以它们也都拥有 Web 技术型框架的优点。这看起来很美好，但实际上 React Native/Weex 的缺点编译型框架也无法避免。除此之外，编译型框架的抽象也不是免费的：当 bug 出现时，问题的根源可能出在运行时、编译时、组件库以及三者依赖的库等等各个方面。在 Taro 开源的过程中，我们就遇到过 Babel 的 bug，React Native 的 bug，JavaScript 引擎的 bug，当然也少不了 Taro 本身的 bug。相信其它原理相同的框架也无法避免这一问题。 但这并不意味着这类为了小程序而设计的多端框架就都不堪大用。首先现在各巨头超级 App 的小程序百花齐放，框架会为了抹平小程序做了许多工作，这些工作在大部分情况下是不需要开发者关心的。其次是许多业务类型并不需要复杂的逻辑和交互，没那么容易触发到框架底层依赖的 bug。 那么当你的业务适合选择编译型框架时，在笔者看来首先要考虑的就是选择 DSL 的起点。因为有多端需求业务通常都希望能快速开发，一个能够快速适应团队开发节奏的 DSL 就至关重要。不管是 React 还是 Vue（或者类 Vue）都有它们的优缺点，大家可以根据团队技术栈和偏好自行选择。 如果不管什么 DSL 都能接受，那就可以进入下一个环节： 生态 以下内容均以各框架现在（2019 年 3 月 11日）已发布稳定版为标准进行讨论。 开发工具 就开发工具而言 [代码]uni-app[代码] 应该是一骑绝尘，它的文档内容最为翔实丰富，还自带了 IDE 图形化开发工具，鼠标点点点就能编译测试发布。 其它的框架都是使用 CLI 命令行工具，但值得注意的是 [代码]chameleon[代码] 有独立的语法检查工具，[代码]Taro[代码] 则单独写了 ESLint 规则和规则集。 在语法支持方面，[代码]mpvue[代码]、[代码]uni-app[代码]、[代码]Taro[代码] 、[代码]WePY[代码] 均支持 TypeScript，四者也都能通过 [代码]typing[代码] 实现编辑器自动补全。除了 API 补全之外，得益于 TypeScript 对于 JSX 的良好支持，Taro 也能对组件进行自动补全。 CSS 方面，所有框架均支持 [代码]SASS[代码]、[代码]LESS[代码]、[代码]Stylus[代码]，Taro 则多一个 [代码]CSS Modules[代码] 的支持。 所以这一轮比拼的结果应该是： [代码]uni-app[代码] > [代码]Taro[代码] > [代码]chameleon[代码] > [代码]WePY[代码]、[代码]mpvue[代码] [图片] 多端支持度 只从支持端的数量来看，[代码]Taro[代码] 和 [代码]uni-app[代码] 以六端略微领先（移动端、H5、微信小程序、百度小程序、支付宝小程序、头条小程序），[代码]chameleon[代码] 少了头条小程序紧随其后。 但值得一提的是 [代码]chameleon[代码] 有一套自研多态协议，编写多端代码的体验会好许多，可以说是一个能戳到多端开发痛点的功能。[代码]uni-app[代码] 则有一套独立的条件编译语法，这套语法能同时作用于 [代码]js[代码]、样式和模板文件。[代码]Taro[代码] 可以在业务逻辑中根据环境变量使用条件编译，也可以直接使用条件编译文件（类似 React Native 的方式）。 在移动端方面，[代码]uni-app[代码] 基于 [代码]weex[代码] 定制了一套 [代码]nvue[代码] 方案 弥补 [代码]weex[代码] API 的不足；[代码]Taro[代码] 则是暂时基于 [代码]expo[代码] 达到同样的效果；[代码]chameleon[代码] 在移动端则有一套 SDK 配合多端协议与原生语言通信。 H5 方面，[代码]chameleon[代码] 同样是由多态协议实现支持，[代码]uni-app[代码] 和 [代码]Taro[代码] 则是都在 H5 实现了一套兼容的组件库和 API。 [代码]mpvue[代码] 和 [代码]WePY[代码] 都提供了转换各端小程序的功能，但都没有 h5 和移动端的支持。 所以最后一轮对比的结果是： [代码]chameleon[代码] > [代码]Taro[代码]、[代码]uni-app[代码] > [代码]mpvue[代码]、[代码]WePY[代码] [图片] 组件库/工具库/demo 作为开源时间最长的框架，[代码]WePY[代码] 不管从 Demo，组件库数量 ，工具库来看都占有一定优势。 [代码]uni-app[代码] 则有自己的插件市场和 UI 库，如果算上收费的框架和插件比起 [代码]WePy[代码] 也是完全不遑多让的。 [代码]Taro[代码] 也有官方维护的跨端 UI 库 [代码]taro-ui[代码] ，另外在状态管理工具上也有非常丰富的选择（Redux、MobX、dva），但 demo 的数量不如前两个。但 [代码]Taro[代码] 有一个转换微信小程序代码为 Taro 代码的工具，可以弥补这一问题。 而 [代码]mpvue[代码] 没有官方维护的 UI 库，[代码]chameleon[代码] 第三方的 demo 和工具库也还基本没有。 所以这轮的排序是： [代码]WePY[代码] > [代码]uni-app[代码] 、[代码]taro[代码] > [代码]mpvue[代码] > [代码]chameleon[代码] [图片] 接入成本 接入成本有两个方面： 第一是框架接入原有微信小程序生态。由于目前微信小程序已呈一家独大之势，开源的组件和库（例如 [代码]wxparse[代码]、[代码]echart[代码]、[代码]zan-ui[代码] 等）多是基于原生微信小程序框架语法写成的。目前看来 [代码]uni-app[代码] 、[代码]Taro[代码]、[代码]mpvue[代码] 均有文档或 demo 在框架中直接使用原生小程序组件/库，[代码]WePY[代码] 由于运行机制的问题，很多情况需要小改一下目标库的源码，[代码]chameleon[代码] 则是提供了一个按步骤大改目标库源码的迁移方式。 第二是原有微信小程序项目部分接入框架重构。在这个方面 Taro 在京东购物小程序上进行了大胆的实践，具体可以查看文章《Taro 在京东购物小程序上的实践》。其它框架则没有提到相关内容。 而对于两种接入方式 Taro 都提供了 [代码]taro convert[代码] 功能，既可以将原有微信小程序项目转换为 Taro 多端代码，也可以将微信小程序生态的组件转换为 Taro 组件。 所以这轮的排序是： [代码]Taro[代码] > [代码]mpvue[代码] 、 [代码]uni-app[代码] > [代码]WePY[代码] > [代码]chameleon[代码] 流行度 从 GitHub 的 star 来看，[代码]mpvue[代码] 、[代码]Taro[代码]、[代码]WePY[代码] 的差距非常小。从 NPM 和 CNPM 的 CLI 工具下载量来看，是 Taro（3k/week）> mpvue (2k/w) > WePY (1k/w)。但发布时间也刚好反过来。笔者估计三家的流行程度和案例都差不太多。 [代码]uni-app[代码] 则号称有上万案例，但不像其它框架一样有一些大厂应用案例。另外从开发者的数量来看也是 [代码]uni-app[代码] 领先，它拥有 20+ 个 QQ 交流群（最大人数 2000）。 所以从流行程度来看应该是： [代码]uni-app[代码] > [代码]Taro[代码]、[代码]WePY[代码]、[代码]mpvue[代码] > [代码]chameleon[代码] [图片] 开源建设 一个开源作品能走多远是由框架维护团队和第三方开发者共同决定的。虽然开源建设不能具体地量化，但依然是衡量一个框架/库生命力的非常重要的标准。 从第三方贡献者数量来看，[代码]Taro[代码] 在这一方面领先，并且 [代码]Taro[代码] 的一些核心包/功能（MobX、CSS Modules、alias）也是由第三方开发者贡献的。除此之外，腾讯开源的 [代码]omi[代码] 框架小程序部分也是基于 Taro 完成的。 [代码]WePY[代码] 在腾讯开源计划的加持下在这一方面也有不错的表现；[代码]mpvue[代码] 由于停滞开发了很久就比较落后了；可能是产品策略的原因，[代码]uni-app[代码] 在开源建设上并不热心，甚至有些部分代码都没有开源；[代码]chameleon[代码] 刚刚开源不久，但它的代码和测试用例都非常规范，以后或许会有不错的表现。 那么这一轮的对比结果是： [代码]Taro[代码] > [代码]WePY[代码] > [代码]mpvue[代码] > [代码]chameleon[代码] > [代码]uni-app[代码] 最后补一个总的生态对比图表： [图片] 未来 从各框架已经公布的规划来看： [代码]WePY[代码] 已经发布了 [代码]v2.0.alpha[代码] 版本，虽然没有公开的文档可以查阅到 [代码]2.0[代码] 版本有什么新功能/特性，但据其作者介绍，[代码]WePY 2.0[代码] 会放大招，是一个「对得起开发者」的版本。笔者也非常期待 2.0 正式发布后 [代码]WePY[代码] 的表现。 [代码]mpvue[代码] 已经发布了 [代码]2.0[代码] 的版本，主要是更新了其它端小程序的支持。但从代码提交， issue 的回复/解决率来看，[代码]mpvue[代码] 要想在未来有作为首先要打消社区对于 [代码]mpvue[代码] 不管不顾不更新的质疑。 [代码]uni-app[代码] 已经在生态上建设得很好了，应该会在此基础之上继续稳步发展。如果 [代码]uni-app[代码] 能加强开源开放，再加强与大厂的合作，相信未来还能更上一层楼。 [代码]chameleon[代码] 的规划比较宏大，虽然是最后发的框架，但已经在规划或正在实现的功能有： 快应用和端拓展协议 通用组件库和垂直类组件库 面向研发的图形化开发工具 面向非研发的图形化页面搭建工具 如果 [代码]chameleon[代码] 把这些功能都做出来的话，再继续完善生态，争取更多第三方开发者，那么在未来 [代码]chameleon[代码] 将大有可为。 [代码]Taro[代码] 的未来也一样值得憧憬。Taro 即将要发布的 [代码]1.3[代码] 版本就会支持以下功能： 快应用支持 Taro Doctor，自动化检查项目配置和代码合法性 更多的 JSX 语法支持，1.3 之后限制生产力的语法只有 [代码]只能用 map 创造循环组件[代码] 一条 H5 打包体积大幅精简 同时 [代码]Taro[代码] 也正在对移动端进行大规模重构；开发图形化开发工具；开发组件/物料平台以及图形化页面搭建工具。 结语 那说了那么多，到底用哪个呢？ 如果不介意尝鲜和学习 DSL 的话，完全可以尝试 [代码]WePY[代码] 2.0 和 [代码]chameleon[代码] ，一个是酝酿了很久的 2.0 全新升级，一个有专门针对多端开发的多态协议。 [代码]uni-app[代码] 和 [代码]Taro[代码] 相比起来就更像是「水桶型」框架，从工具、UI 库，开发体验、多端支持等各方面来看都没有明显的短板。而 [代码]mpvue[代码] 由于开发一度停滞，现在看来各个方面都不如在小程序端基于它的 [代码]uni-app[代码] 。 当然，Talk is cheap。如果对这个话题有更多兴趣的同学可以去 GitHub 另行研究，有空看代码，没空看提交： chameleon: https://github.com/didi/chameleon mpvue: https://github.com/Meituan-Dianping/mpvue Taro: https://github.com/NervJS/taro uni-app: https://github.com/dcloudio/uni-app WePY: https://github.com/Tencent/wepy (按字母顺序排序)

小程序提供了路由功能来实现页面跳转，但是在使用的过程中我们还是发现有些不方便的地方，通过封装，我们可以实现诸如路由管理、简化api等功能。 页面的跳转存在哪些问题呢？ 与接口的调用一样面临url的管理问题； 传递参数的方式不太友好，只能拼装url； 参数类型单一，只支持string。 alias 第一个问题很好解决，我们做一个集中管理，比如新建一个[代码]router/routes.js[代码]文件来实现alias： [代码]// routes.js module.exports = { // 主页 home: '/pages/index/index', // 个人中心 uc: '/pages/user_center/index', }; [代码] 然后使用的时候变成这样： [代码]const routes = require('../../router/routes.js'); Page({ onReady() { wx.navigateTo({ url: routes.uc, }); }, }); [代码] query 第二个问题，我们先来看个例子，假如我们跳转[代码]pages/user_center/index[代码]页面的同时还要传[代码]userId[代码]过去，正常情况下是这么来操作的： [代码]const routes = require('../../router/routes.js'); Page({ onReady() { const userId = '123456'; wx.navigateTo({ url: `${routes.uc}?userId=${userId}`, }); }, }); [代码] 这样确实不好看，我能不能把参数部分单独拿出来，不用拼接到url上呢？ 可以，我们试着实现一个[代码]navigateTo[代码]函数： [代码]const routes = require('../../router/routes.js'); function navigateTo({ url, query }) { const queryStr = Object.keys(query).map(k => `${k}=${query[k]}`).join('&'); wx.navigateTo({ url: `${url}?${queryStr}`, }); } Page({ onReady() { const userId = '123456'; navigateTo({ url: routes.uc, query: { userId, }, }); }, }); [代码] 嗯，这样貌似舒服一点。 参数保真 第三个问题的情况是，当我们传递的参数argument不是[代码]string[代码]，而是[代码]number[代码]或者[代码]boolean[代码]时，也只能在下个页面得到一个[代码]string[代码]值： [代码]// pages/index/index.js Page({ onReady() { navigateTo({ url: routes.uc, query: { isActive: true, }, }); }, }); // pages/user_center/index.js Page({ onLoad(options) { console.log(options.isActive); // => "true" console.log(typeof options.isActive); // => "string" console.log(options.isActive === true); // => false }, }); [代码] 上面这种情况想必很多人都遇到过，而且感到很抓狂，本来就想传递一个boolean，结果不管传什么都会变成string。 有什么办法可以让数据变成字符串之后，还能还原成原来的类型？ 好熟悉，这不就是json吗？我们把要传的数据转成json字符串（[代码]JSON.stringify[代码]），然后在下个页面把它转回json数据（[代码]JSON.parse[代码]）不就好了嘛！ 我们试着修改原来的[代码]navigateTo[代码]： [代码]const routes = require('../../router/routes.js'); function navigateTo({ url, data }) { const dataStr = JSON.stringify(data); wx.navigateTo({ url: `${url}?jsonStr=${dataStr}`, }); } Page({ onReady() { navigateTo({ url: routes.uc, data: { isActive: true, }, }); }, }); [代码] 这样我们在页面中接受json字符串并转换它： [代码]// pages/user_center/index.js Page({ onLoad(options) { const json = JSON.parse(options.jsonStr); console.log(json.isActive); // => true console.log(typeof json.isActive); // => "boolean" console.log(json.isActive === true); // => true }, }); [代码] 这里其实隐藏了一个问题，那就是url的转义，假如json字符串中包含了类似[代码]?[代码]、[代码]&[代码]之类的符号，可能导致我们参数解析出错，所以我们要把json字符串encode一下： [代码]function navigateTo({ url, data }) { const dataStr = encodeURIComponent(JSON.stringify(data)); wx.navigateTo({ url: `${url}?encodedData=${dataStr}`, }); } // pages/user_center/index.js Page({ onLoad(options) { const json = JSON.parse(decodeURIComponent(options.encodedData)); console.log(json.isActive); // => true console.log(typeof json.isActive); // => "boolean" console.log(json.isActive === true); // => true }, }); [代码] 这样使用起来不方便，我们封装一下，新建文件[代码]router/index.js[代码]： [代码]const routes = require('./routes.js'); function navigateTo({ url, data }) { const dataStr = encodeURIComponent(JSON.stringify(data)); wx.navigateTo({ url: `${url}?encodedData=${dataStr}`, }); } function extract(options) { return JSON.parse(decodeURIComponent(options.encodedData)); } module.exports = { routes, navigateTo, extract, }; [代码] 页面中我们这样来使用： [代码]const router = require('../../router/index.js'); // page home Page({ onLoad(options) { router.navigateTo({ url: router.routes.uc, data: { isActive: true, }, }); }, }); // page uc Page({ onLoad(options) { const json = router.extract(options); console.log(json.isActive); // => true console.log(typeof json.isActive); // => "boolean" console.log(json.isActive === true); // => true }, }); [代码] route name 这样貌似还不错，但是[代码]router.navigateTo[代码]不太好记，[代码]router.routes.uc[代码]有点冗长，我们考虑把[代码]navigateTo[代码]换成简单的[代码]push[代码]，至于路由，我们可以使用[代码]name[代码]的方式来替换原来[代码]url[代码]参数： [代码]const routes = require('./routes.js'); function push({ name, data }) { const dataStr = encodeURIComponent(JSON.stringify(data)); const url = routes[name]; wx.navigateTo({ url: `${url}?encodedData=${dataStr}`, }); } function extract(options) { return JSON.parse(decodeURIComponent(options.encodedData)); } module.exports = { push, extract, }; [代码] 在页面中使用： [代码]const router = require('../../router/index.js'); Page({ onLoad(options) { router.push({ name: 'uc', data: { isActive: true, }, }); }, }); [代码] navigateTo or switchTab 页面跳转除了navigateTo之外还有switchTab，我们是不是可以把这个差异抹掉？答案是肯定的，如果我们在配置routes的时候就已经指定是普通页面还是tab页面，那么程序完全可以切换到对应的跳转方式。 我们修改一下[代码]router/routes.js[代码]，假设home是一个tab页面： [代码]module.exports = { // 主页 home: { type: 'tab', path: '/pages/index/index', }, uc: { path: '/pages/a/index', }, }; [代码] 然后修改[代码]router/index.js[代码]中[代码]push[代码]的实现： [代码]function push({ name, data }) { const dataStr = encodeURIComponent(JSON.stringify(data)); const route = routes[name]; if (route.type === 'tab') { wx.switchTab({ url: `${route.path}`, // 注意tab页面是不支持传参的 }); return; } wx.navigateTo({ url: `${route.path}?encodedData=${dataStr}`, }); } [代码] 搞定，这样我们一个[代码]router.push[代码]就能自动切换两种跳转方式了，而且之后一旦页面类型有变动，我们也只需要修改[代码]route[代码]的定义就可以了。 直接寻址 alias用着很不错，但是有一点挺麻烦得就是每新建一个页面都要写一个alias，即使没有别名的需要，我们是不是可以处理一下，如果在alias没命中，那就直接把name转化成url？这也是阔以的。 [代码]function push({ name, data }) { const dataStr = encodeURIComponent(JSON.stringify(data)); const route = routes[name]; const url = route ? route.path : name; if (route.type === 'tab') { wx.switchTab({ url: `${url}`, // 注意tab页面是不支持传参的 }); return; } wx.navigateTo({ url: `${url}?encodedData=${dataStr}`, }); } [代码] 在页面中使用： [代码]Page({ onLoad(options) { router.push({ name: 'pages/user_center/a/index', data: { isActive: true, }, }); }, }); [代码] 注意，为了方便维护，我们规定了每个页面都必须存放在一个特定的文件夹，一个文件夹的当前路径下只能存在一个index页面，比如[代码]pages/index[代码]下面会存放[代码]pages/index/index.js[代码]、[代码]pages/index/index.wxml[代码]、[代码]pages/index/index.wxss[代码]、[代码]pages/index/index.json[代码]，这时候你就不能继续在这个文件夹根路径存放另外一个页面，而必须是新建一个文件夹来存放，比如[代码]pages/index/pageB/index.js[代码]、[代码]pages/index/pageB/index.wxml[代码]、[代码]pages/index/pageB/index.wxss[代码]、[代码]pages/index/pageB/index.json[代码]。 这样是能实现功能，但是这个name怎么看都跟alias风格差太多，我们试着定义一套转化规则，让直接寻址的name与alias风格统一一些，[代码]pages[代码]和[代码]index[代码]其实我们可以省略掉，[代码]/[代码]我们可以用[代码].[代码]来替换，那么原来的name就变成了[代码]user_center.a[代码]： [代码]Page({ onLoad(options) { router.push({ name: 'user_center.a', data: { isActive: true, }, }); }, }); [代码] 我们再来改进[代码]router/index.js[代码]中[代码]push[代码]的实现： [代码]function push({ name, data }) { const dataStr = encodeURIComponent(JSON.stringify(data)); const route = routes[name]; const url = route ? route.path : `pages/${name.replace(/\./g, '/')}/index`; if (route.type === 'tab') { wx.switchTab({ url: `${url}`, // 注意tab页面是不支持传参的 }); return; } wx.navigateTo({ url: `${url}?encodedData=${dataStr}`, }); } [代码] 这样一来，由于支持直接寻址，跳转home和uc还可以写成这样： [代码]router.push({ name: 'index', // => /pages/index/index }); router.push({ name: 'user_center', // => /pages/user_center/index }); [代码] 这样一来，除了一些tab页面以及特定的路由需要写alias之外，我们也不需要新增一个页面就写一条alias这么麻烦了。 其他 除了上面介绍的navigateTo和switchTab外，其实还有[代码]wx.redirectTo[代码]、[代码]wx.navigateBack[代码]以及[代码]wx.reLaunch[代码]等，我们也可以做一层封装，过程雷同，所以我们就不再一个个介绍，这里贴一下最终简化后的api以及原生api的映射关系： [代码]router.push => wx.navigateTo router.replace => wx.redirectTo router.pop => wx.navigateBack router.relaunch => wx.reLaunch [代码] 最终实现已经在发布在github上，感兴趣的朋友可以移步了解：mp-router。

写在前面 原生小程序插上 JSX 和 Less 的翅膀 mps 是什么？为什么需要 mps？先列举几个现状: 目前小程序开发使用最多的技术依然是原生小程序 原生小程序的 API 在不断完善和进化中 JSX 是表达能力和编程体验最好的 UI 表达式 JSX 可以表达一切想表达的 UI 结构也就能够描述任意 WXML 所以，就有了 mps。 让开发者直接在原生小程序使用 JSX 写 WXML，实时编译，实时预览。 → mps github 地址 [图片] JSX 代替 WXML 书写结构，精简高效 对原生小程序零入侵 支持 JS 和 TS 实时编译，实时预览 输出 WXML 自动美化 支持 Less 输出 WXSS 效果预览 [图片] 立即开始 [代码]$ npm i omi-cli -g $ omi init-mps my-app $ cd my-app $ npm start [代码] 接着把小程序目录设置为 my-app 目录便可以愉快地开始开发调试了！ [代码]npx omi-cli init-mps my-app[代码] 也支持(npm v5.2.0+) 生成的目录和官方的模板一致，只不过多了 JSX 文件，只需要修改 JSX 文件就会实时修改 WXML。 也支持 typescript: [代码]$ omi init-mps-ts my-app [代码] 其他命令一样。 [代码]npx omi-cli init-mps-ts my-app[代码] 也支持(npm v5.2.0+) JSX vs WXML 这里是一个真实的案例说明 JSX 的精巧高效的表达能力: 编译前的 JSX: [代码]<view class='pre language-jsx'> <view class='code'> {tks.map(tk => { return tk.type === 'tag' ? <text class={'token ' + tk.type}>{ tk.content.map(stk => { return stk.deep ? stk.content.map(sstk => { return <text class={'token ' + sstk.type}>{sstk.content || sstk}</text> }) : <text class={'token ' + stk.type}>{stk.content || stk}</text> })}</text> : <text class={'token ' + tk.type}>{tk.content || tk}</text> })} </view> </view> [代码] 编译后 WXML: [代码]<view class="pre language-jsx"> <view class="code"> <block wx:for="{{tks}}" wx:for-item="tk" wx:for-index="_anonIdx4"> <block wx:if="{{tk.type === 'tag'}}" ><text class="{{'token ' + tk.type}}" ><block wx:for="{{tk.content}}" wx:for-item="stk" wx:for-index="_anonIdx2" ><block wx:if="{{stk.deep}}" ><text class="{{'token ' + sstk.type}}" wx:for="{{stk.content}}" wx:for-item="sstk" wx:for-index="_anonIdx3" >{{sstk.content || sstk}}</text > </block> <block wx:else ><text class="{{'token ' + stk.type}}" >{{stk.content || stk}}</text > </block> </block> </text> </block> <block wx:else ><text class="{{'token ' + tk.type}}">{{tk.content || tk}}</text> </block> </block> </view> </view> [代码] 老项目使用 mps 拷贝以下文件到小程序根目录: _scripts 目录所有文件 package.json gulpfile.js .jsx 和 .less 文件 设置 project.config.json 里的 packOptions.ignore 忽略以上的文件，具体的配置可以从这里复制过去，然后: [代码]$ npm install $ npm start [代码] mps 约定 公共的 less 文件必须放在 common-less 目录，@import 使用的时候不需要写路径。 推荐搭配 既然用了原生小程序的方案，所有可以轻松使用 mps + omix 搭配一起使用。 欢迎使用腾讯 Omi 团队集合京东 O2Team 智慧联合打造的 mp-jsx 大幅提高开发效率，Have fun! Github → mps

为什么要做性能优化？ 一切性能优化都是为了体验优化 1. 使用小程序时，是否会经常遇到如下问题？ 打开是一直白屏 打开是loading态，转好几圈 我的页面点了怎么跳转这么慢？ 我的列表怎么越滑越卡？ 2. 我们优化的方向有哪些？ 启动加载性能 渲染性能 3. 启动加载性能 1. 首次加载 你是否见过小程序首次加载时是这样的图？ [图片] 这张图中的三种状态对应的都是什么呢？ 小程序启动时，微信会为小程序展示一个固定的启动界面，界面内包含小程序的图标、名称和加载提示图标。此时，微信会在背后完成几项工作：[代码]下载小程序代码包[代码]、[代码]加载小程序代码包[代码]、[代码]初始化小程序首页[代码]。下载到的小程序代码包不是小程序的源代码，而是编译、压缩、打包之后的代码包。 2. 加载顺序 小程序加载的顺序是如何？ 微信会在小程序启动前为小程序准备好通用的运行环境。这个运行环境包括几个供小程序使用的线程，并在其中完成小程序基础库的初始化，预先执行通用逻辑，尽可能做好小程序的启动准备。这样可以显著减少小程序的启动时间。 [图片] 通过2，我们知道了，问题1中第一张图是[代码]资源准备[代码]（代码包下载）；第二张图是[代码]业务代码的注入以及落地页首次渲染[代码]；第三张图是[代码]落地页数据请求时的loading态[代码]（部分小程序存在） 3. 控制包大小 提升体验最直接的方法是控制小程序包的大小，这是最显而易见的 勾选开发者工具中“上传代码时，压缩代码”选项； 及时清理无用的代码和资源文件（包括无用的日志代码） 减少资源包中的图片等资源的数量和大小（理论上除了小icon，其他图片资源从网络下载），图片资源压缩率有限 从开发者的角度看，控制代码包大小有助于减少小程序的启动时间。对低于1MB的代码包，其下载时间可以控制在929ms（iOS）、1500ms（Android）内。 4. 采用分包加载机制 根据业务场景，将用户访问率高的页面放在主包里，将访问率低的页面放入子包里，按需加载； [图片] 使用分包时需要注意代码和资源文件目录的划分。启动时需要访问的页面及其依赖的资源文件应放在主包中。 5 采用分包预加载技术 在4的基础上，当用户点击到子包的目录时，还是有一个代码包下载的过程，这会感觉到明显的卡顿，所以子包也不建议拆的太大，当然我们可以采用子包预加载技术，并不需要等到用户点击到子包页面后在下载子包，而是可以根据后期数据，做子包预加载，将用户在当先页可能点击的子包页面先加载，当用户点击后直接跳转； [图片] 这种基于配置的子包预加载技术，是可以根据用户网络类型来判断的，当用户处于网络条件好时才预加载；是灵活可控的 6. 采用独立分包技术 目前很多小程序[代码]主包+子包[代码]（2M+6M）的方式，但是在做很多运营活动时，我们会发现活动（红包）是在子包里，但是运营、产品投放的落地页链接是子包链接，这是的用户在直达落地时，必须先下载主包内容（一般比较大），在下载子包内容（相对主包，较小），这使得在用户停留时间比较短的小程序场景中，用户体验不是很好，而且浪费了很大部分流量； [图片] 可以采用独立分包技术，区别于子包，和主包之间是无关的，在功能比较独立的子包里，使用户只需下载分包资源； 7. 首屏加载的优化建议 7.1 提前请求 异步请求可以在页面onLoad就加载，不需要等页面ready后在异步请求数据；当然，如果能在前置页面点击跳转时预请求当前页的核心异步请求，效果会更好； 7.2 利用缓存 利用storage API, 对变动频率比较低的异步数据进行缓存，二次启动时，先利用缓存数据进行初始化渲染，然后后台进行异步数据的更新，这不仅优化了性能，在无网环境下，用户也能很顺畅的使用到关键服务； 7.3 避免白屏 可以在前置页面将一些有用的字段带到当前页，进行首次渲染（列表页的某些数据–> 详情页），没有数据的模块可以进行骨架屏的占位，使用户不会等待的很焦虑，甚至走了； 7.4 及时反馈 及时的对需要用户等待的交互操作进行反馈，避免用户以为小程序卡了，无响应 渲染性能优化 1. 小程序渲染原理 双线程下的界面渲染，小程序的逻辑层和渲染层是分开的两个线程。在渲染层，宿主环境会把WXML转化成对应的JS对象，在逻辑层发生数据变更的时候，我们需要通过宿主环境提供的setData方法把数据从逻辑层传递到渲染层，再经过对比前后差异，把差异应用在原来的Dom树上，渲染出正确的UI界面。 [图片] 分析这个流程不难得知：页面初始化的时间大致由页面初始数据通信时间和初始渲染时间两部分构成。其中，数据通信的时间指数据从逻辑层开始组织数据到视图层完全接收完毕的时间，数据量小于64KB时总时长可以控制在30ms内。传输时间与数据量大体上呈现正相关关系，传输过大的数据将使这一时间显著增加。因而减少传输数据量是降低数据传输时间的有效方式。 [图片] 2. 避免使用不当setData 在数据传输时，逻辑层会执行一次[代码]JSON.stringify[代码]来去除掉[代码]setData[代码]数据中不可传输的部分，之后将数据发送给视图层。同时，逻辑层还会将[代码]setData[代码]所设置的数据字段与[代码]data[代码]合并，使开发者可以用[代码]this.data[代码]读取到变更后的数据。因此，为了提升数据更新的性能，开发者在执行[代码]setData[代码]调用时，最好遵循以下原则： 2.1 不要过于频繁调用setData，应考虑将多次setData合并成一次setData调用； [图片] 2.2 数据通信的性能与数据量正相关，因而如果有一些数据字段不在界面中展示且数据结构比较复杂或包含长字符串，则不应使用[代码]setData[代码]来设置这些数据； [图片] 2.3 与界面渲染无关的数据最好不要设置在data中，可以考虑设置在page对象的其他字段下 [图片] 提升数据更新性能方式的代码示例 [代码]Page({ onShow: function() { // 不要频繁调用setData this.setData({ a: 1 }) this.setData({ b: 2 }) // 绝大多数时候可优化为 this.setData({ a: 1, b: 2 }) // 不要设置不在界面渲染时使用的数据，并将界面无关的数据放在data外 this.setData({ myData: { a: '这个字符串在WXML中用到了', b: '这个字符串未在WXML中用到，而且它很长…………………………' } }) // 可以优化为 this.setData({ 'myData.a': '这个字符串在WXML中用到了' }) this._myData = { b: '这个字符串未在WXML中用到，而且它很长…………………………' } } }) [代码] 利用setData进行列表局部刷新 在一个列表中，有[代码]n[代码]条数据，采用上拉加载更多的方式，假如这个时候想对其中某一个数据进行点赞操作，还能及时看到点赞的效果 解决方法 1、可以采用setData全局刷新，点赞完成之后，重新获取数据，再次进行全局重新渲染，这样做的优点是：方便，快捷！缺点是：用户体验极其不好，当用户刷量100多条数据后，重新渲染量大会出现空白期（没有渲染过来） 2、说到重点了，就是利用[代码]setData[代码]局部刷新 [代码]> a.将点赞的`id`传过去，知道点的是那一条数据, 将点赞的`id`传过去，知道点的是那一条数据 [代码] [代码]<view wx:if="{{!item.status}}" class="btn" data-id="{{index}}" bindtap="couponTap">立即领取</view> [代码] [代码]> b.重新获取数据，查找相对应id的那条数据的下标（`index`是不会改变的） > c.用setData进行局部刷新 [代码] [代码]this.setData({ list[index] = newList[index] }) [代码] 其实这个小操作对刚刚接触到微信小程序的人来说应该是不容易发现的，不理解setData还有这样的写法。 2.4 切勿在后台页面进行setData 在一些页面会进行一些操作，而到页面跳转后，代码逻辑还在执行，此时多个[代码]webview[代码]是共享一个js进程；后台的[代码]setData[代码]操作会抢占前台页面的渲染资源； [图片] [图片] 3. 用户事件使用不当 视图层将事件反馈给逻辑层时，同样需要一个通信过程，通信的方向是从视图层到逻辑层。因为这个通信过程是异步的，会产生一定的延迟，延迟时间同样与传输的数据量正相关，数据量小于64KB时在30ms内。降低延迟时间的方法主要有两个。 1.去掉不必要的事件绑定（WXML中的[代码]bind[代码]和[代码]catch[代码]），从而减少通信的数据量和次数； 2.事件绑定时需要传输[代码]target[代码]和[代码]currentTarget[代码]的[代码]dataset[代码]，因而不要在节点的[代码]data[代码]前缀属性中放置过大的数据。 [图片] 4. 视图层渲染原理 4.1首次渲染 初始渲染发生在页面刚刚创建时。初始渲染时，将初始数据套用在对应的WXML片段上生成节点树。节点树也就是在开发者工具WXML面板中看到的页面树结构，它包含页面内所有组件节点的名称、属性值和事件回调函数等信息。最后根据节点树包含的各个节点，在界面上依次创建出各个组件。 [图片] 在这整个流程中，时间开销大体上与节点树中节点的总量成正比例关系。因而减少WXML中节点的数量可以有效降低初始渲染和重渲染的时间开销，提升渲染性能。 简化WXML代码的例子 [代码]<view data-my-data="{{myData}}"> <!-- 这个 view 和下一行的 view 可以合并 --> <view class="my-class" data-my-data="{{myData}}" bindtap="onTap"> <text> <!-- 这个 text 通常是没必要的 --> {{myText}} </text> </view> </view> <!-- 可以简化为 --> <view class="my-class" data-my-data="{{myData}}" bindtap="onTap"> {{myText}} </view> [代码] 4.2 重渲染 初始渲染完毕后，视图层可以多次应用[代码]setData[代码]的数据。每次应用[代码]setData[代码]数据时，都会执行重渲染来更新界面。初始渲染中得到的data和当前节点树会保留下来用于重渲染。每次重渲染时，将[代码]data[代码]和[代码]setData[代码]数据套用在WXML片段上，得到一个新节点树。然后将新节点树与当前节点树进行比较，这样可以得到哪些节点的哪些属性需要更新、哪些节点需要添加或移除。最后，将[代码]setData[代码]数据合并到[代码]data[代码]中，并用新节点树替换旧节点树，用于下一次重渲染。 [图片] 在进行当前节点树与新节点树的比较时，会着重比较[代码]setData[代码]数据影响到的节点属性。因而，去掉不必要设置的数据、减少[代码]setData[代码]的数据量也有助于提升这一个步骤的性能。 5. 使用自定义组件 自定义组件的更新只在组件内部进行，不受页面其他不能分内容的影响；比如一些运营活动的定时模块可以单独抽出来，做成一个定时组件，定时组件的更新并不会影响页面上其他元素的更新；各个组件也将具有各自独立的逻辑空间。每个组件都分别拥有自己的独立的数据、setData调用。 [图片] 6. 避免不当的使用onPageScroll 每一次事件监听都是一次视图到逻辑的通信过程，所以只在必要的时候监听pageSrcoll [图片] 总结 小程序启动加载性能 控制代码包的大小 分包加载 首屏体验（预请求，利用缓存，避免白屏，及时反馈 小程序渲染性能 避免不当的使用setData 合理利用事件通信 避免不当的使用onPageScroll 优化视图节点 使用自定义组件