背景微信上传代码流程 PR -> 审核通过 -> 切到master分支 -> git pull -> 切到ide -> 点击上传代码 -> 填入备注和版本号 CI PR -> 审核通过 -> CI上传 利用CI后除了一开始的人工提PR和审核后，不需要进行任何操作，并且会给出开始上传和上传完成的通知，解决了之前上传代码流程较长的人工链路，释放自己，不用一直做无意义且无趣的事。 执行过程的效果图如下： [图片] 上传成功后 我们需要去小程序后台提交审核信息。 [图片] 钉钉自定义机器人文档：钉钉webHooks，码云webHook对钉钉的支持，钉钉自定义机器人SDK 需要设置群机器人群设置 -> 智能群助手 -> 添加机器人 -> 自定义机器人 -> 勾选安全设置加签使用access_token和secret完成自定义机器人初始化[图片] 码云WebHooks文档：码云webHooks，码云webHook推送数据格式说明 在URL处填入刚刚的接口，比如https://xxx.com/upload勾选Pull Request，然后点击更新即可，这里需要注意他会发送好几次，比如创建PR发送一次，审核通过发送一次，合并发送一次，所以在接口里需要判断一下只有合并完成的时候才执行后续逻辑（state === 'merged'[图片] 微信小程序准备工作微信官方CI API 密钥：微信公众号 -> 开发 -> 开发设置，下载代码上传密钥，然后在调用CI时设置好privateKeyPath白名单配置：微信公众号 -> 开发 -> 开发设置，配置白名单（必须IP）开发先来个流程图，让大家了解一下接口的逻辑 [图片]判断是否是合并到master（十一后可能要改为main了）值得一提的是目前码云的webHook的推送数据格式是Request Payload，所以我们需要利用koa2-formidable插件对数据进行处理后就能直接使用ctx.request.body获取数据了 router.post('/api/upload', async ctx => { const body = ctx.request.body // 合并状态并且合到master才会自动上传到后台 if (body.state === 'merged' && body.target_branch === 'master') { ... } } 钉钉初始化const Robot = require("dingtalk-robot-sdk") const robot = new Robot({ accessToken: config.robotAccessToken, secret: config.robotSecret }); const text = new Robot.Text('开始上传') robot.send(text) 是否存在项目const xcxPath = path.join(process.cwd(), config[type].publicProject) // 判断是否存在xcx项目文件夹，没有就去clone，有就pull最新代码 if (fs.existsSync(xcxPath)) { child_process.execSync('git pull', { cwd: xcxPath }) } else { child_process.execSync(`git clone ${config[type].git}`, { cwd: path.join(process.cwd(), config.publicRoot) }) } 项目初始化和上传// 创建项目对象 const project = new ci.Project({ appid: config.wx.appid, type: 'miniProgram', projectPath: publicProject, privateKeyPath: path.join(process.cwd(), config.publicRoot, '../wx.key'), // wx.key为小程序appSecret ignores: ['node_modules/**/*'], }) const year = new Date().getFullYear() - 2000 let month = new Date().getMonth() + 1 const day = new Date().getDate() // 根据年月日当版本号 const version = '2.5.' + year + (month < 10 ? '0' + month : month) + (day < 10 ? '0' + day : day); // 上传 const previewResult = await ci.upload({ project, version, desc: body.title, setting: { es6: true, minify: true, autoPrefixWXSS: true, minifyWXML: true, minifyWXSS: true, minifyJS: true } }) 钉钉通知完成const markdown = new Robot.Markdown() .setTitle('上传完成！！！！') .add(`### [上传完成](https://mp.weixin.qq.com)\n`) .add(`1. version：${version}`) .add(`2. size：${fullSize}`) .add(`3. ${JSON.stringify(previewResult)}`) robot.send(markdown) 支付宝小程序准备工作文档：支付宝官方CLI文档，支付宝官方SDK文档 开发其余逻辑均与上面的微信小程序开发一致，只有项目初始化和上传是不一致的，所以这里我们只说一下项目初始化和上传 项目初始化使用alipaydev key create -w 生成的私钥和工具id完成项目初始化 // 初始化项目 alipaydev.setConfig({ toolId: config.ali.toolId, privateKey: config.ali.privateKey, }) 上传version不传的话默认线上包版本自增0.0.1，所以我们不需要传version const uploadResult = await alipaydev.miniUpload({ appId: config.ali.appid, clientType: 'alipay', project: publicProject, experience: true // 设置体验版（不是主账户，所以其实目前没用） })

作者：HerryLo 原文永久链接： https://github.com/AttemptWeb/Record... 将从代码层面和项目层面，聊一聊微信小程序的性能优化问题，希望有所帮助。也是自己最近的一个总结。(前置知识：微信小程序的视图层是WebView支持，逻辑层是JSCore支持，逻辑层通过setData与视图层发生交互。每一个页面都是一个WebView页面）详见：小程序的运行环境 下面的内容不论是使用Taro框架开发，还是微信小程序原生开发，都是适用的。 代码层面 拆分组件 图片压缩 减少不必要数据 避免频繁setData 使用webView组件开发 项目层面 拆分小程序 分包预加载 尽量升级版本库 #代码层面通过代码细节提升性能，而且在这方面，空间是非常大的。对于比较早期的小程序项目，由于代码细节方面没有过多的考虑，也导致了开发出的小程序非常的消耗性能。下面将提到的一些点，不论是正在开发的项目，还是在维护的项目，都会有一定的帮助。 #👇· 拆分组件对于小程序的项目，由于野蛮式开发，不会太多的考虑组件拆分。当然对于关注组件开发的公司，肯定会在早期就做好一定的规划。做好组件的拆分，可以保证组件的复用，大量的减少重复的代码。（组件开发的思想，目前基本适用所有的前端开发项目）。如何有效拆分组件方法，详见[译] 你是如何拆分组件的？。 #👇· 图片压缩在微信小程序项目中，不会在本地存放图片，基本都是网络图片，而网络图片的下载，需要消耗一定的时间和内存。较小图片的大小，可以提升小程序的渲染时间，减少内存的占用。通过CDN静态资源服务器获取图片资源，添加图片压缩规则，可以极大的提升性能。 #👇· 减少不必要数据减少data中的亢余数据。不必要数据，传入setData会造成不必要的性能消耗。建议：不要直接将接口数据全部保存在data中，只有页面需要渲染的 数据，才通过setData进行挂载，非必要的数据可以直接挂载在当前页面page的this上。 [代码]let data = {[代码][代码]    [代码][代码]list: [item, item, item, item, item],[代码][代码]    [代码][代码]title: [代码][代码]"xxxx"[代码][代码],[代码][代码]    [代码][代码]path: [代码][代码]'xx/xx/xx'[代码][代码]}[代码] [代码] [代码] [代码]// ❌不好的处理[代码] [代码] [代码] [代码]this.setData({[代码] [代码]    [代码][代码]data: data[代码] [代码]})[代码] [代码] [代码] [代码]// 👌好的处理 只挂载必要参数[代码] [代码] [代码] [代码]this.setData({[代码] [代码]    [代码][代码]dataList: data.list[代码] [代码]})[代码] [代码]this[代码][代码].title = data.title[代码] [代码]this.path = data.pat[代码] 👇· 避免频繁setData [代码]// ❌不好的处理[代码] [代码]this.setData({[代码] [代码]    [代码][代码]count: 1[代码] [代码]})[代码] [代码]this[代码][代码].setData({[代码] [代码]    [代码][代码]count: 2[代码] [代码]})[代码] [代码]this[代码][代码].setData({[代码] [代码]    [代码][代码]count: 3[代码] [代码]})[代码] 三次[代码]setData[代码]会被全部触发嘛？是的，会被全部调用。 在微信小程序中，并不像react，把多次操作合并。每次setData的过程，就是一次JSCore逻辑层 和 webView视图层的交互。过多的交互，会降低小程序的用户体验。例如 滑动监听滚动，操作setData，非常的消耗性能，可以考虑使用节流函数，降低调用频率。 官方给出的说法是：setData接口的调用涉及逻辑层与渲染层间的线程通信，通信过于频繁可能导致处理队列阻塞，界面渲染不及时而导致卡顿，应避免无用的频繁调用。来修改一下上面的代码。 [代码]// 👌好的处理[代码][代码]let data = { count: 1 }[代码][代码]data.count = 2;[代码][代码]data.count = 3;[代码] [代码] [代码] [代码]this[代码][代码].setData(data)[代码] # 👇· webView组件开发 灵活性非常强的页面，同时需要多端使用，建议使用微信小程序提供的webView组件，套用h5页面进行页面开发，避免重复开发。当微信小程序包过大之后，也建议使用h5页面替换开发。详见webView 组件 [代码]<web-view [代码][代码]src=[代码][代码]"{{link}}"[代码][代码]bindmessage=[代码][代码]"bindMes"[代码][代码]bindload=[代码][代码]"bindLoad"[代码][代码]/>[代码]# 项目层面 通过微信小程序项目配置来提升加载性能，下面的方案可以有效的解决问题，不过也要试情况而定。 #👇· 拆分小程序在包过大的情况下下，可以进行小程序包的拆分，详见：分包加载。对小程序进行分包，可以优化小程序首次启动的下载时间，以及在多团队共同开发时可以更好的解耦协作。如果业务庞大，也可以单独抽离一个新的小程序。 #👇· 分包预加载采用分包配置之后，分包加载也是需要时间的。对于一些比较常用，或者比较重要的页面，可以采取分包预加载的手段，来完成分包的提前下载，减小分包载入的时间。详见 分包预下载 #👇· 尽量升级版本库注意基础版本库的问题，在合适的前提下升级版本库，尽量将版本库升级为最新版本。因为版本库升级为最新，可以有效避免很多问题。 目前随着各大公司业务的不断迭代，小程序的体积不断真大，小程序渐渐的不在小。请让小程序尽量的小起来，发挥它小的作用。希望以上内容可以帮到你。 更多内容： '小程序个人开发指南 ps: 微信公众号：Yopai，有兴趣的可以关注，每周不定期更新，分享可以增加世界的快乐 [图片]

为什么要做性能优化？ 一切性能优化都是为了体验优化 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 优化视图节点 使用自定义组件

当我们需要自定义底部导航栏时   首先要解决iphoneX的底部大横条对这个兼容   通常不设置兼容  都会被挡住 如何编写 在你要编写的底部菜单中插入   样式 [代码]padding-bottom[代码][代码]: calc(env(safe-area-inset-[代码][代码]bottom[代码][代码]) / [代码][代码]2[代码][代码])   即可兼容 [代码] [代码] 例如：css中插入[代码] [代码]@supports ([代码][代码]bottom[代码][代码]: constant(safe-area-inset-[代码][代码]bottom[代码][代码])) or ([代码][代码]bottom[代码][代码]: env(safe-area-inset-[代码][代码]bottom[代码][代码])) {[代码][代码]    [代码][代码].fixed-wrap {[代码][代码]        [代码][代码]height[代码][代码]: calc(env(safe-area-inset-[代码][代码]bottom[代码][代码]) / [代码][代码]2[代码][代码]);[代码][代码]        [代码][代码]width[代码][代码]: [代码][代码]100%[代码][代码];[代码][代码]    [代码][代码]}[代码] [代码]    [代码][代码].fixed-pay {[代码][代码]        [代码][代码]padding-bottom[代码][代码]: calc(env(safe-area-inset-[代码][代码]bottom[代码][代码]) / [代码][代码]2[代码][代码]);[代码][代码]    [代码][代码]}[代码] [代码]}[代码]其中       [代码]env(safe-area-inset-[代码][代码]bottom[代码][代码])  是计算兼容的高度   通常一半即可   [代码]         calc  是计算css   你也可以加入高度  假设有第二层 底部固定栏【即底部导航栏上面还有一层固定栏】  可如下编写   view.footer {     bottom: calc(100rpx + env(safe-area-inset-bottom)); } 这样轻轻松松解决兼容  不需要写js代码 <-------------大横条-------------> [图片]