适应场景： 小程序页面跳转redirect/navigate/其它方式 分析： 从用户触发跳转行为到下一个页面onload生命周期函数内时间差会有500ms左右，如果在页面跳转之后进行onload函数内才开始去加载页面数据，那么这500ms左右的时间就浪费了。 改进： 在页面触发跳转行为的处理函数里结合promise预先加载下个页面的数据，并将promise对象缓存，此时页面跳转和加载数据同时进行，到了目标页面再取出缓存的promise对象进行判断和取数据操作。 效果： 跳转页面加载速度提高了600ms。 示例： 代码结构 [图片] pageManager.js [代码]// 写在utils里的公用方法 const pageList = {}; module.exports = { putData:function(pageName, data){ pageList[pageName] = data; }, getData:function(pageName){ return pageList[pageName]; } } [代码] util.js [代码]const myPromise = fn => obj => { return new Promise((resolve, reject) => { obj.complete = obj.success = (res) => { resolve(res); } obj.fail = (err) => { reject(err); } fn(obj); }) } module.exports = { myPromise : myPromise } [代码] index.js [代码]// 跳转页面 const {myPromise} = require('../../utils/util'); const pageManager = require('../../utils/pageManager'); page({ data: { }, onLoad:function(){ }, gotoPageA:function(){ const PromisePageA = myPromise(wx.request)({ url : '' }).then((res)=>{ return res.data; }) pageManager.putData('pageA',promisePageA); wx.navigateTo({ url: 'pages/pageA/pageA' }) } }) [代码] pageA.js [代码]// 被跳转页面 const util = require('../../utils/util.js'); const pageManager = require('../../utils/pageManager'); const {myPromise} = require('../../utils/util'); Page({ data:{ logs:[] }, onLoad: function(){ const promisePageA = pageManager.getData('pageA'); if(promisePageA){ const resData = promisePageA.then( function(data){ }, function(){ console.log("err"); } ) } } }) [代码]

[图片]

2019年上半年微信发布了基于小程序页面的搜索，为了让我们更好地发现及理解小程序的页面，结合过去一段时间来我们遇到的各种情况，我们强烈建议各位开发者花一些宝贵的时间认真阅读本文：） 爬虫访问小程序内页面时，会携带特定的 user-agent "mpcrawler" 及场景值：1129 1. 小程序里跳转的页面 (url) 可被直接打开。 小程序页面内的跳转url是我们爬虫发现页面的重要来源，且搜索引擎召回的结果页面 (url) 是必须能直接打开，不依赖上下文状态的。特别的：建议页面所需的参数都包含在url 2. 页面跳转优先采用navigator组件。 小程序提供了两种页面路由方式：   a.navigator 组件      b. 路由 API，包括 navigateTo / redirectTo / switchTab / navigateBack / reLaunch 建议使用 navigator 组件，若不得不使用API，可在爬虫访问时屏蔽针对点击设置的时间锁或变量锁。 3.清晰简洁的页面参数。 结构清晰、简洁、参数有含义的 querystring 对抓取以及后续的分析都有很大帮助，但是将 JSON 数据作为参数的方式是比较糟糕的实现。 4. 必要的时候才请求用户进行授权、登录、绑定手机号等。 建议在必须的时候才要求用户授权（比如阅读文章可以匿名，而发表评论需要留名）。 5. 我们不收录 web-view 中的任何内容。 我们暂时做不到这一点，长期来看，我们可能也做不到。 6. 利用 sitemap 配置引导爬虫抓取，同时屏蔽无搜索价值的路径。 https://developers.weixin.qq.com/miniprogram/dev/framework/sitemap.html 7. 设置一个清晰的标题和页面缩略图。 页面标题和缩略图对于我们理解页面和提高曝光转化有重要的作用。 通过wx.setNavigationBarTitle或 自定义转发内容onShareAppMessage对页面的标题和缩略图设置，另外也为 video、audio 组件补齐 poster /poster-for-crawler属性。 8. 使用页面路径推送能力 可极大丰富微信可以收录的内容，进而提高小程序内容的曝光机会。请参考： https://developers.weixin.qq.com/miniprogram/dev/api-backend/open-api/search/search.submitPages.html

- 当前 Bug 的表现（可附上截图） [图片] - 预期表现 [图片] - 复现路径 https://developers.weixin.qq.com/s/Nk1VSvmX7Z7H 页面拉到底部时唤起软键盘  顶部导航会被顶出页面

目前项目大都通过组件化来简化单页的复杂性，后期也很容易维护； 组件封装方面，我们要求： 样式独立 结构独立 有业务功能（网络请求等）必须在组件内完成； 这样一个复杂页面会引用很多组件，如果这些组件都有获取初始数据（或配置数据）的行为，这样在页面初始化时会产生大量相同网络请求，如下图： [图片] 虽然无伤大雅，程序也能正常进行，但是还是想把这样重复的请求统一合并下；优化后如下： [图片] 怎么优化处理呢？找了 网络请求管理器、请求合并 等相关的，但是没有合适的，这里需要防止并发重复请求；所以自己动手改造请求； 封装请求管理器类，通过类内部变量存储所有的请求记录(tasks) check 用于检查5秒内是否有相同的请求 get 等同于 promise 封装的 wx.request，这里将去获取 set 的值 set 请求成功或失败时 set 下，tasks 里就存放了相应的结果 [代码]class rpcm { tasks = {} check(key) { let nt = new Date().getTime() if (this.tasks[key]) { //console.log('resSetIntervalnt',nt , this.tasks[key].timeout) if (nt <= this.tasks[key].timeout) { return true } } return false } get(key) { return new Promise((success, fail) => { let resSetInterval=setInterval(()=>{ console.log('resSetInterval',key,this.tasks[key]) if(this.tasks[key].type=='success'){ wx.hideLoading(); success(this.tasks[key].res) clearInterval(resSetInterval) } if(this.tasks[key].type=='fail'){ wx.hideLoading(); fail(this.tasks[key].res) clearInterval(resSetInterval) } },500) }) } set(key,type='',res=null) { let nt = new Date().getTime() this.tasks[key] = { timeout: nt + 5000 } if(type){ this.tasks[key]['type']=type this.tasks[key]['res']=JSON.parse(JSON.stringify(res)) } } } [代码] 请求的处理，这里 myRequest 只是示例，请根据你的业务改造 [代码]function myRequest(url,params){ const RMT = new rpcm() //cache_key 是url地址+请求参数params // 如果已经存在可用请求，就直接去get 请求的结果 if (RMT.check(cache_key)) return RMT.get(cache_key) RMT.set(cache_key)// 请求管理器中创建一个请求占用 return new Promise((success, fail) => { wx.request({ url: url, method: 'POST', data: params, success: function (res) { success(res.data); //将返回结果存入请求管理器 RMT.set(cache_key,'success',res.data) }, fail: function (res) { fail(res); //将返回结果存入请求管理器 RMT.set(cache_key,'fail',res) }, complete: function () { wx.hideLoading(); } }) }) } [代码] 这样在5秒内多次调用 myRequest , 相同的url和参数就只会发起一次请求，其它请求会去等待首次请求的返回结果； 为什么多次请求不能直接忽略掉呢？每个请求之后都有自己的业务要做，不能简单的忽略！

在社区文章里看到老哥分享的。尝试使用了下。

wx.setNavigationBarTitle 使用结果：如果只设置非tabBar标题没问题。 如果是设置tabBar页的标题，会导致接下来点击跳转（wx.navigateTo）后的所有的页面标题都一起被修改。 真机和微信开发者工具都是这样，不知道这是bug还是什么情况。

- 在TabA页面，接口请求成功之后，通过调用setNavigationBarTitle设置页面顶部的title。在TabA页面请求未完成时，切换到TabB页面，此时，在TabA页面请求完成之后设置的title会被设置到TabB页面 - 荣耀8，红米6A、iPhoneX、iPhone6等安卓和苹果机型均会出现此问题。 - 官方文档中写明的是setNavigationBarTitle这个API是动态设置当前页面的title，但是很明显并不是这个样子的，js代码更像是在同一个容器中执行，并没有区分页面，所以当切换到TabB页面的时候，处于TabA页面的setNavigationBarTitle这个API仍然会执行，并且仍然会成功设置title，只不过现在用户已经切换到了TabB页面，所以title也就设置到了TabB页面。

第一次加载页面，点击跳转二级页，然后跳转底部的tab第二个页面 这时,页面会先闪到第一个底部tab页，然后自动到指定的tab页面

最近做小程序云开发时，用到了一个数据库的模糊搜索功能，并且是要求多字段的模糊搜索。 网上也有一大堆资源，但是都是单个字段的搜索。如下图 [图片] 上图只可以实现time字段的模糊搜索。但是我们如果相对数据表里的多个字段做模糊查询呢？该怎么办呢。 多字段模糊搜索 一，如我们的数据表里有以下数据，我们想同时模糊查询name和address字段 [图片] [图片] 如我们搜索“周杰”可以看到我们查询到下面两条数据。 [图片] 二，如我们搜索“编程”，可以搜索到下面数据 [图片] 可以看到我们搜索到的两条数据，一个是name字段为 编程小石头， 一个是address字段里包含“编程“ 字样。 下面把代码贴给大家 [代码] let key = "编程小石头"; console.log("查询的内容", key) const db = wx.cloud.database(); const _ = db.command db.collection('qcl').where(_.or([{ name: db.RegExp({ regexp: '.*' + key, options: 'i', }) }, { address: db.RegExp({ regexp: '.*' + key, options: 'i', }) } ])).get({ success: res => { console.log(res) }, fail: err => { console.log(err) } }) [代码] key就是我们要搜索的关键字。主要是用到了数据库查询的where,or,get方法。 代码都给大家贴出来来，如果对云开发和云数据库还不是很了解的同学可以去翻看下我以前写的文章。

[图片] 如图 要更新红框中字段：prizewinner中的数组-数组中的对象，改如何实现？？弄晕我一个晚上了！！ 还有一个问题，云开发可以向记录中的某个字段对象插入数据吗？比如上面这段json数据，我要往prizewinner中增加一条新的object，我看官方文档 只有往集合中增加新记录的api 两个问题：求大神解答

大家好！请教一个问题，我的身份证被一个小程序绑定了，这个小程序不是我的，我也不知道是谁的，这种情况该怎么办，原始ID:gh_d93ed06b45ee。多谢！

picker选择日期（粒度年月）ios的默认时间不显示当前，直接显示了起始时间，安卓没问题

阅读基础：有小程序项目经验，有查阅官方文档习惯的小伙伴 随着公司小程序项目日益繁多，仅仅靠着官方提供的框架、组件、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 和适配层讲的都比较偏概念。毕竟这部分内容都和业务逻辑联系比较紧密，很难抽象深入讲解。刚好还有假期还有一段时间，如果自己还有时间就再写一篇关于最近项目的模块化剖析吧，哈哈。