微盟小程序性能优化要分享的内容分为三部分，启动性能加载、首屏加载的体验建议和渲染性能优化。 先讲启动性能加载的性能优化实践，先看启动加载过程的流程： [图片] · 公共库注入 · 资源准备（基础UI创建，代码包下载） · 业务代码注入和渲染 · 渲染首屏 · 异步请求 优化方案 1、控制代码包大小 · 开启开发者工具中的 “ 上传代码时自动压缩 ” · 及时清理无用代码和资源文件 · 减少代码包中的图片等资源文件的大小和数量 · 将图片等资源文件放到CND中 · 提取公共样式 · 代码压缩，图片格式，压缩，或者外联 · 公共组件提取，代码复用 2、 分包加载 分包加载过程流程 [图片] 在开发小程序分包项目时，会有一个或者多个分包，其中没有分包小程序必须包含一个主包，即放置启动页面或者tabBar页面，以及一些分包都需要用到的公共资源脚本。 在小程序启动时，默认会下载主包并且启动主包内页面，如果用户打开分包内的页面，客户端会把分包下载下来，下载完之后再进行展示。 · 分包加载流程 [图片] 使用分包加载的优点： · 能够增加小程序更大的代码体积，开发更多的功能 · 对于用户，可以更快地打开小程序，同时不影响启动速度 使用分包加载有哪些限制： · 整个小程序所有分包不能超过8M · 单个主包/分包不能超过2M 3、 运行机制优化 · 代码中减少立即执行的代码数量 · 避免高开销和长时间阻塞代码 · 业务代码都写入页面的生命周期中 · 做好缓存策略 4、 数据管理优化 · 首屏请求数量尽量不能超过5个，超过的可以做接口合并（node层，服务端都可以处理） · 对多次提交的数据可以做合并处理 接下来和大家聊一聊首屏加载的体验建议和渲染性能优化。 二、首屏加载的体验建议 · 提前请求     异步数据请求不需要等待页面渲染完成。 · 利用缓存   利用storage API对异步请求数据进行缓存，二次渲染页面，再进行后台更新。 · 避免白屏   先展示页面骨架和基础内容。 三、渲染性能优化 ·  每次 setData 的调用都是一次进程间通信过程，通信开销与 setData 的数据量正相关 ·  setData 会引发视图层页面内容的更新，这一耗时操作一定时间中会阻塞用户交互 ·  setData 是小程序开发使用最频繁，也是最容易引发性能问题的 ·  在页面列表中使用懒加载+动态移除非可视区域范围内的内容，让dom小下去 ·  耗时比较长的js做到异步，不要阻塞进程（js属于单线程） ·  少使用scroll-view,这个组件对性能的影响太大，单纯的只是需要一块区域滚动，可以使用view+css的方式实现 ·  在页面频繁滚动触发回调函数，会导致页面卡顿，这时必须和防抖动函数或者节流函数相结合做一些处理 ·  页面中的图片可以使用懒加载的方式（添加lazy-load属性，只针对page与scroll-view下的image有效） ·  页面跳转要做一下限制，如果页面快速点击会出现跳转多次的情况  避免不正当的使用setData · 使用data在方法间共享数据，可能增加setData传输的数据量。data 应该仅仅包含与页面渲染相关的数据 · 使用setData 传输大量的数据，通讯耗时与数据量成正比，导致页面更新延迟 可能造成页面更新开销增加。所以setData 仅传输页面需要的数据,使用setData 的特殊Key 实现局部更新 · 短时间内频繁调用setData  (操作卡顿、交互延迟   阻塞通信、页面渲染延迟)，对连续的setData 调用进行合并 · 后台进行页面setData  (抢占前台页面的渲染资源) 例如 活动定时器 再页面切入后台时应该将关闭 避免不正当的使用onPageScroll · 只在必要的时候监听pageScroll 事件 · 避免在onPageScroll 中执行复杂的逻辑 · 避免在onPageScroll 中频繁调用setData · 避免频繁查询节点信息(SelectQuery) 部分场景建议使用节点布局相交状态 ·  监听( IntersectionObserver) 替代 使用自定义组件 在需要频繁更新的场景下，自定义组件的更新只在组件内部进行，不受页面部分内容的复杂性的影响。 使用体验评分功能 在开发过程中使用体验评分可以测试出代码中一些需要优化的点，准备定位到影响性能的原因，很大程序提高页面的性能。

一、首次启动性能优化 1、首次打开一个小程序，用户一般会观察到如下图所示的三种状态 [图片] 这张图中的三种状态对应的都是什么呢？小程序启动时，微信会为小程序展示一个固定的启动界面，界面内包含小程序的图标、名称和加载提示图标。 此时，微信会在背后完成几项工作：下载小程序代码包、加载小程序代码包、初始化小程序首页。下载到的小程序代码包不是小程序的源代码，而是编译、压缩、打包之后的代码包。 2、小程序加载的顺序 微信会在小程序启动前为小程序准备好通用的运行环境。这个运行环境包括几个供小程序使用的线程，并在其中完成小程序基础库的初始化，预先执行通用逻辑，尽可能做好小程序的启动准备。这样可以显著减少小程序的启动时间。 [图片] 通过这张图可以对比发现，小程序首次启动的 第一张图是资源准备（代码包下载）；第二张图是业务代码的注入以及落地页首次渲染；第三张图是落地页数据请求时的loading态（部分小程序存在）。 3、优化方案 控制包大小：上传代码时要先进行压缩、静态图片资源除小的icon外其余放到cdn、无用代码清除； 分包加载：根据业务场景，将用户访问率高的页面放在主包里，将访问率低的页面放入子包里，按需加载； 分包预加载：在进入小程序某个页面时，由框架自动预下载可能需要的分包，提升进入后续分包页面时的启动速度。对于独立分包，也可以预下载主包。分包预下载 官方文档链接 独立分包技术：区别于子包，和主包之间是无关的，在功能比较独立的子包里，使用户只需下载分包资源；独立分包 官方文档链接 二、渲染性能优化 1、数据渲染优化 双线程下的界面渲染，小程序的逻辑层和渲染层是分开的两个线程。在渲染层，宿主环境会把WXML转化成对应的JS对象，在逻辑层发生数据变更的时候，我们需要通过宿主环境提供的setData方法把数据从逻辑层传递到渲染层，再经过对比前后差异，把差异应用在原来的Dom树上，渲染出正确的UI界面。 [图片] 页面初始化的时间大致由页面初始数据通信时间和初始渲染时间两部分构成。其中，数据通信的时间指数据从逻辑层开始组织数据到视图层完全接收完毕的时间，数据量小于64KB时总时长可以控制在30ms内。传输时间与数据量大体上呈现正相关关系，传输过大的数据将使这一时间显著增加。因而减少传输数据量是降低数据传输时间的有效方式。 [图片] 在数据传输时，逻辑层会执行一次JSON.stringify来去除掉setData数据中不可传输的部分，之后将数据发送给视图层。同时，逻辑层还会将setData所设置的数据字段与data合并，使开发者可以用this.data读取到变更后的数据。因此，为了提升数据更新的性能，可以参考如下方法： 1.不要过于频繁调用setData，应考虑将多次setData合并成一次setData调用； 2.数据通信的性能与数据量正相关，因而如果有一些数据字段不在界面中展示且数据结构比较复杂或包含长字符串，则不应使用setData来设置这些数据； 3.与界面渲染无关的数据最好不要设置在data中，可以考虑设置在page对象的其他字段下； 4.勿在后台页面去setData； 5.建议创建一个检测data大小的方法，如果超过64K可以打印报警日志提醒开发者； 2、长列表优化方案 无限下拉加载后会大数据量展现导致的性能问题,一个常见的方法在诸多C端都有使用,一句话说就是"只渲染所需的元素"。虚拟列表是按需显示思路的一种实现，即虚拟列表是一种根据滚动容器元素的可视区域来渲染长列表数据中某一个部分数据的技术。简而言之，虚拟列表指的就是「可视区域渲染」的列表。有三个概念需要了解一下： 滚动容器元素：一般情况下，滚动容器元素是 window 对象。然而，我们可以通过布局的方式，在某个页面中任意指定一个或者多个滚动容器元素。只要某个元素能在内部产生横向或者纵向的滚动，那这个元素就是滚动容器元素考虑每个列表项只是渲染一些纯文本。在本文中，只讨论元素的纵向滚动。 可滚动区域：滚动容器元素的内部内容区域。假设有 100 条数据，每个列表项的高度是 50，那么可滚动的区域的高度就是 100 * 50。可滚动区域当前的具体高度值一般可以通过(滚动容器)元素的 scrollHeight 属性获取。用户可以通过滚动来改变列表在可视区域的显示部分。 可视区域：滚动容器元素的视觉可见区域。如果容器元素是 window 对象，可视区域就是浏览器的视口大小(即视觉视口)；如果容器元素是某个 div 元素，其高度是 300，右侧有纵向滚动条可以滚动，那么视觉可见的区域就是可视区域。 实现虚拟列表就是在处理用户滚动时，要改变列表在可视区域的渲染部分，其具体步骤如下： 计算当前可见区域起始数据的 startIndex 计算当前可见区域结束数据的 endIndex 计算当前可见区域的数据，并渲染到页面中 计算 startIndex 对应的数据在整个列表中的偏移位置 startOffset，并设置到列表上 计算 endIndex 对应的数据相对于可滚动区域最底部的偏移位置 endOffset，并设置到列表上 [图片] 虚拟列表的实现原理可以参考这篇文章：浅说虚拟列表的实现原理 3、长列表局部渲染技巧 在一个列表中，有n条数据，采用上拉加载更多的方式。假如这个时候想对其中某一个数据进行点赞操作，还能及时看到点赞的效果，可以采用setData全局刷新，点赞完成之后，重新获取数据，再次进行全局重新渲染，这样做的优点是：方便，快捷！缺点是：用户体验极其不好，当用户刷量100多条数据后，重新渲染量大会出现空白期（没有渲染过来）。 优化步骤： 1.将点赞的[代码]id[代码]传过去，知道点的是那一条数据, 将点赞的[代码]id[代码]传过去，知道点的是那一条数据 <view wx:if="{{!item.status}}" class=“btn” data-id="{{index}}" bindtap=“couponTap”>立即领取</view> 2.重新获取数据，查找相对应id的那条数据的下标（[代码]index[代码]是不会改变的） 3.用setData进行局部刷新 this.setData({ list[index] : newList[index] }) 4、用户事件优化 视图层将事件反馈给逻辑层时，同样需要一个通信过程，通信的方向是从视图层到逻辑层。因为这个通信过程是异步的，会产生一定的延迟，延迟时间同样与传输的数据量正相关，数据量小于64KB时在30ms内。降低延迟时间的方法主要有两个。 1.去掉不必要的事件绑定（WXML中的bind和catch），从而减少通信的数据量和次数； 2.事件绑定时需要传输target和currentTarget的dataset，因而不要在节点的data前缀属性中放置过大的数据。 三、生命周期优化 1、异步请求，页面渲染需要的数据最好在onLoad时异步请求数据，不要在onReady时请求；非页面渲染需要的数据，尽量放在onReady生命周期去调用； 2、定时器、事件监听、播放组件、音视频组件等，在页面转入后台(onHide)或者销毁(onUnload)时应该中止掉； 四、图片静态资源预加载 在日常小程序的开发中，有很多的大图片是放置于cdn上的，在需要进行展示的时候，如果没有预加载有可能出现图片展示的不及时，造成不好的体验，所以如下方式实现了图片预加载的功能，可以封装成组件的形式。 实现思路是将图片添加进页面中，设置不可见，然后加载图片，实现一个预加载的功能。 1、添加模版文件： img-loader.wxml <template name=“img-loader”> <image mode=“aspectFill” wx:for="{{ imgLoadList }}" wx:key="*this" src="{{ item }}" data-src="{{ item }}" bindload="_imgOnLoad" binderror="_imgOnLoadError" style=“width:0;height:0;opacity:0” /> </template> 2、添加js文件：img-loader.js /** 图片预加载组件 */ class ImgLoader { /** 初始化方法，在页面的 onLoad 方法中调用，传入 Page 对象及图片加载完成的默认回调 */ constructor(pageContext, defaultCallback) { this.page = pageContext this.defaultCallback = defaultCallback || function () { } this.callbacks = {} this.imgInfo = {} [代码]this.page.data.imgLoadList = [] //下载队列 this.page._imgOnLoad = this._imgOnLoad.bind(this) this.page._imgOnLoadError = this._imgOnLoadError.bind(this) [代码] } /** 加载图片 @param {String} src 图片地址 @param {Function} callback 加载完成后的回调（可选），第一个参数个错误信息，第二个为图片信息 */ load(src, callback) { if (!src) return; [代码]let list = this.page.data.imgLoadList, imgInfo = this.imgInfo[src] if (callback) this.callbacks[src] = callback //已经加载成功过的，直接回调 if (imgInfo) { this._runCallback(null, { src: src, width: imgInfo.width, height: imgInfo.height }) //新的未在下载队列中的 } else if (list.indexOf(src) == -1) { list.push(src) this.page.setData({ 'imgLoadList': list }) } [代码] } _imgOnLoad(ev) { let src = ev.currentTarget.dataset.src, width = ev.detail.width, height = ev.detail.height [代码]//记录已下载图片的尺寸信息 this.imgInfo[src] = { width, height } this._removeFromLoadList(src) this._runCallback(null, { src, width, height }) [代码] } _imgOnLoadError(ev) { let src = ev.currentTarget.dataset.src this._removeFromLoadList(src) this._runCallback(‘Loading failed’, { src }) } //将图片从下载队列中移除 _removeFromLoadList(src) { let list = this.page.data.imgLoadList list.splice(list.indexOf(src), 1) this.page.setData({ ‘imgLoadList’: list }) } //执行回调 _runCallback(err, data) { let callback = this.callbacks[data.src] || this.defaultCallback callback(err, data) delete this.callbacks[data.src] } } module.exports = ImgLoader 3、在需要使用预加载功能的xxx.wxml页面中加入模版文件和使用代码： <import src="…/…/templates/img-loader.wxml"/> <template is=“img-loader” data="{{ imgLoadList }}"></template> 4、在需要使用预加载功能页面的xxx.js文件中引入文件和使用代码： import ImgLoader from ‘…/…/templates/img-loader.js’; let images = [ ‘http://cdn.weimob.com/saas/activity/bargain/images/arms/shoulie.png’, ‘http://cdn.weimob.com/saas/activity/bargain/images/arms/shandian.png’, ‘http://cdn.weimob.com/saas/activity/bargain/images/arms/fengbao.png’ ] //初始化图片预加载组件，并指定统一的加载完成回调 this.imgLoader = new ImgLoader(this, this.imageOnLoad.bind(this)); images.forEach(item => { this.imgLoader.load(item) }) 备注：如有错误请帮忙指出；如有侵权，请联系我们删除，谢谢！

阅读基础：有小程序项目经验，有查阅官方文档习惯的小伙伴 随着公司小程序项目日益繁多，仅仅靠着官方提供的框架、组件、API，已经远远不能满足项目高效迭代的要求了，于是我们组内萌生了对小程序进行模块化的想法。 实际项目中我们对小程序模块化已经涉及各个模块，我总结一下，从三个方向跟大家分享我们不一样的模块化思路：[代码]Page+[代码]，[代码]basePage[代码]，[代码]适配层[代码]。 Page+：赋予页面更多的功能 [代码]Page()[代码]作为页面的入口，我们可以通过对其入参对象的封装实现：生命周期的改造、全局状态管理和新增页面功能。 官方删除了小程序分享回调 complete，一起来尝试将其恢复吧。一般我们的逻辑是这样的： [代码]// pages/index/index.js Page({ // 数据初始化 data: { shareFlag: false, //页面是否处于分享中 shareComplete: false //分享回调事件 }, // onShow 生命周期 onShow: function () { const { shareFlag, shareComplete } = this.data if( shareFlag ){ this.data.shareFlag = false //变量不涉及页面渲染，不使用 setData shareComplete && shareComplete() } }, // 分享事件 onShareAppMessage: function () { let shareInfo = { title: '分享测试标题', path: '', complete: function () { console.log('页面分享成功啦~') } } this.data.shareFlag = true this.data.shareComplete = typeof (shareInfo.complete) == 'function' ? shareInfo.complete : false return shareInfo } }) [代码] 在单页面内实现分享回调这样操作是可行的，如果多页面、多项目都要实现该功能，重复拷贝代码，则显格外得繁琐。 我们来将这个功能抽离封装一下吧。 [代码]// pages/index/index.js import PagePlus from './pagePlus.js' PagePlus({ // 分享事件 onShareAppMessage: function () { return { title: '分享测试标题', path: '', complete: function () { console.log('页面分享成功啦~') } } } }) [代码] [代码]// pages/index/pagePlus.js const PagePlus = (pageObj) => { const _onShow = pageObj.onShow, _onShareAppMessage = pageObj.onShareAppMessage, _data = { shareStatus: false, //页面是否处于分享中 shareComplete: false //分享回调事件 } Object.assign(_data, pageObj.data) delete pageObj.data pageObj.onShow = function () { typeof _onShow == 'function' && _onShow.apply(this) const { shareStatus, shareComplete } = this.data if (shareStatus) { this.data.shareStatus = false //变量不涉及页面渲染，不使用 setData shareComplete && shareComplete() } } pageObj.onShareAppMessage = function () { const shareInfo = typeof _onShareAppMessage == 'function' && _onShareAppMessage.apply(this) this.data.shareStatus = true shareInfo && (this.data.shareComplete = shareInfo.complete) return shareInfo } Page({ data: _data, ...pageObj }) } export default PagePlus [代码] 我们来增加一个新的生命周期回调——[代码]onReshow[代码]（页面非首次显示回调，常用于详情页操作影响上一页列表数据的场景）。 [代码]// pages/index/index.js import PagePlus from './pagePlus.js' PagePlus({ // 监听页面非首次显示 onReshow: function(){ console.log('onReshow lifeCallBack') }, onShareAppMessage: function () { return { title: '分享测试标题', path: '', complete: function () { console.log('页面分享成功啦~') } } } }) [代码] [代码]// pages/index/pagePlus.js class BasePage{ data = { pagePlus: { shareStatus: false, //页面是否处于分享中 shareComplete: false, //分享回调事件 firstEnter: true //第一次进入页面 } } methods = { onShow: this.onShow, onShareAppMessage: this.onShareAppMessage, onReshow: this.onReshow } onShow(){ const { shareStatus, shareComplete, firstEnter } = this.data.pagePlus if (firstEnter) { this.data.pagePlus.firstEnter = false } else { this.onReshow() } if (shareStatus) { this.data.pagePlus.shareStatus = false shareComplete && shareComplete() } } onShareAppMessage(shareInfo){ this.data.pagePlus.shareStatus = true shareInfo && (this.data.pagePlus.shareComplete = shareInfo.complete) } } const PagePlus = (pageObj) => { const basePage = new BasePage() for (var i in basePage.methods) { basePage.methods[i] = (() => { const key = i const _temFn = basePage.methods[key] return function () { if (key == 'onShareAppMessage') { const shareInfo = typeof pageObj[key] == 'function' && pageObj[key].apply(this, arguments) _temFn.apply(this, [shareInfo]) return shareInfo } typeof pageObj[key] == 'function' && pageObj[key].apply(this, arguments) typeof _temFn == 'function' && _temFn.apply(this, arguments) } })() } Object.assign(basePage.data, pageObj.data) delete pageObj.data Page({ data: basePage.data, ...pageObj, ...basePage.methods }) } export default PagePlus [代码] 自此，我们修改了原生的生命周期回调和增加了新的生命周期回调。当然我们还能为 Page+ 赋予更多的功能，例如： [代码]页面刷新[代码]：下拉自动刷新当前页。 [代码]定时器自动清除[代码]：离开页面时，自动清除页面执行的定时器。 [代码]全局状态管理[代码]：页面间数据共享，相关数据关联的组件即时渲染更新。 相关的代码实现，大家可以自己思考一下怎么实现；我的实现细节，如果大家感兴趣的话就在下方给我留言吧，你们的回复是我更新的动力哦。 basePage：公共 Component 管理器 小程序页面彼此独立，使用 Component 都需要各自引用，为了实现页面公共 Component 的统一管理，这个时候就可以引入 basePage 的概念：以 basePage 作为父组件，其他公共 Component 作为子组件，页面通过 basePage 对公共 Component 进行管理。 实现原理 1、定义一个 Component ，作为 basePage 。 2、每个页面统一引用 basePage ，且规定页面的元素都需要写到 <basePage/> 标签内部 。 3、通过 basePage 引用页面公共的 Component ，并进行业务逻辑编辑。 实现细节 实际使用过程中，我发现有两个问题： 1、Page 和 basePage 通信是非常频繁的，需要通过 WXML 数据绑定和 triggerEvent 触发事件，略显麻烦。 2、setTimeout、webSocket 等后台进程，可能触发[代码]非当前显示页面[代码]的渲染更新，而绝大部分情况，我们只需要[代码]当前显示页面[代码]的渲染更新。 针对这两种场景的优化，我们可以把当前显示页面的 basePage 实例对象赋值到 global 的某个具体变量；每当 Page 触发 show 生命周期回调的时候，我们就对这个变量赋值的实例对象进行更新，这样我们就可以通过 global 的变量直接操作当前显示页面的 basePage 了。 部分代码示例 [代码]{ "文件路径": "pages/index/index.json", "usingComponents": { "basePage": "../../components/basePage/index" } } [代码] [代码]<!--pages/index/index.wxml--> <basePage> <!-- 页面元素 --> </basePage> [代码] [代码]// components/basePage/index.js Component({ /** * Component 所在页面的生命周期函数 */ pageLifetimes: { show: function () { global.basePage = this }, hide: function () { global.basePage = null } } }) [代码] [代码]{ "文件路径": "components/basePage/index.json", "说明": "在此处统一引入页面公共的 Component", "component": true, "usingComponents": {} } [代码] [代码]<!--components/basePage/index.wxml--> <slot /> [代码] 适配层：让代码适应更多的场景 如果你的项目对代码后续维护、迭代和可移植性有较高需求，或者需要多项目并行，这个时候通过适配层去调用各个功能模块就显得尤为重要。适配层方面我做的还是比较粗糙的，如果有建议欢迎指出。 适配层的时机 项目不是 bugfix 级别的迭代，都有适配层设计的必要。 如果是[代码]新项目[代码]，心底不认为自己是“咸鱼”而是代码的“亲爹”，[代码]适配层完全可以作为标配[代码]去实现；这就是展现自己对代码全局观的时候了，把自己对代码的理解都用适配层去诠释吧。 如果是[代码]旧项目迭代[代码]，在项目排期允许的情况下，尽可能理解原代码的基本实现细节；对比新的项目是要束手束脚一些，适配层的设计要在[代码]尽可能少改变原有代码[代码]的情况下进行；如果排期比紧急，适配层的完整实现[代码]可以在几个版本迭代中逐步实现[代码]。 模块设计必须高内聚低耦合 如果功能模块的设计过于松散、耦合复杂，这就意味着适配层将需要做各种兼容，这和适配层设计的初衷背道而驰，不做也罢。 配置文件 如果你的代码有移植性要求，为这些不同环境准备对应的配置文件吧，配置文件可以通过自制脚手架实现，也可以粗暴地手动替换，在保证尽可能不出错的情况下实现即可。 功能模块的入口 所有整合的功能模块都需要通过适配层进行调用，适配层就是你的“王之财宝”。 规范 && 文档 适配层是从代码的全局考虑，如果是项目是分工完成，项目的开发人员都需要遵守适配层规范进行代码开发；文档我一直都认为都是非常必要的，但还是经常会懈怠，没有进行完整的文档编写，但我基本会在所有项目成员都能理解适配层的情况下，进行简单的口头说明。 因为开心说一些废话 一次需求迭代中，几乎涉及手头上的所有小程序项目；刚好就在需求前的半个月，我们小组完成了对所有项目模块化改造；虽然需求来得很急，我们还是很完美的实现了。毕竟[代码]模块化之前，每个项目的改造都是独立的工作量；模块化之后，就只有适配层迭代的工作量了[代码]。不过真是辛苦了测试小伙伴，因为对所有项目进行模块化改造，意味着测试小伙伴对所有项目进行回归测试，感谢测试小伙伴，比心！ 这篇文章，对 Page+ 的具体实现展示比较详细，感觉对 basePage 和适配层讲的都比较偏概念。毕竟这部分内容都和业务逻辑联系比较紧密，很难抽象深入讲解。刚好还有假期还有一段时间，如果自己还有时间就再写一篇关于最近项目的模块化剖析吧，哈哈。

最近更新的设置隐私指引功能太费事了,整了很长时间都不行,现在终于可以了.记录一下相关经验,以供参考. 1.通过查询接口,这个字段是小程序使用到的权限,所以这几个字段必须做设置说明. 昨天的时候查询接口总是出错,现在可以了. [图片] 2.设置的隐私描述尽量准确,不知道是不是跟这个有关系. 之前: [图片] 之后: [图片] 一开始我也不知道有哪些权限要弄,只弄了手机号和昵称信息,后来才知道,查询接口里已经列出了需要添加的权限. 总算踩过去了.

为进一步规范开发者的用户个人信息处理行为，保障用户合法权益，小程序、插件中涉及处理用户个人信息的开发者，无论是通过调用涉及用户个人信息的相关接口，还是自行收集用户个人信息，在提交代码版本前，均需补充相应用户隐私保护指引，具体如下： 一、 如小程序、插件有涉及收集用户个人信息（包含通过接口形式收集、通过非接口的形式收集）开发者需在【小程序管理后台-设置-功能设置-用户隐私保护指引】（如果是第三方开发者代开发小程序可通过接口进行配置）/【小程序管理后台-功能-小程序插件-基本设置-用户隐私保护说明】针对具体使用目的与用途进行说明填写，并补充完整隐私指引内容。 二、针对隐私指引说明内容，有如下要求： 1、隐私指引说明内容需与代码包内引用相关接口一致； 2、隐私指引说明内容文字表述需清晰、完整、告知用户处理相应信息的目的与用途； 3、在代码提审环节将对以上要求进行核验，如未满足相应要求，则无法通过代码版本审核，将影响开发者后续版本提审。 平台预计于11月1日对相关接口进行隐私指引说明审核，请开发者及时补充完善隐私指引说明，避免影响相关服务及用户体验。 微信团队 2021年10月29日