在使用小程序的时候，偶然会发生闪退。这里来讲一下闪退的问题该如何排查。 版本排查 发生闪退的时候，首先，要确认下 版本 是不是最新的。如果不是，建议更新版本再重试。旧版本的问题会在新版本进行修复哦。 微信版本： 微信官网 基础库版本：基础库更新日志小程序自查 确认版本都是最新情况下，还是有闪退的问题的话，建议先进行小程序自查~ 一般情况下，闪退是因为内存使用过多导致的，小程序侧可以通过基础库提供 wx.onMemoryWarning 接口来监听内存不足的告警，当收到告警时，通过回收一些不必要资源避免进一步加剧内存紧张。 反馈官方 如果问题还是会出现的话建议反馈给官方处理，需要附带上以下信息点协助排查（划重点：完整的提供信息才可以加速问题处理进度哦！！！） 示例： 系统及微信版本号：安卓7.0.17、IOS 7.0.17（出现问题的时候，建议两端都测试，给出有问题的case）必现 or 偶现：必现可复现场景：代码片段 或者 线上小程序复现步骤：进入首页，点击添加按钮等等，推荐录制复现的 视频（重点）进行上传。上传日志：提供微信号，复现时间点（操作步骤：手机微信那里上传下日志： 我 -> 设置 -> 帮助与反馈：右上角扳手 -> 上报日志，选择出现问题的日期，上传日志）

在代码当中，模拟双向绑定，page调取组件可以使用 let pages = getCurrentPages(); let page = pages[pages.length - 1];     page.setData({     name:‘simple’ }) 但是组件里调取组件就不行了, 使用this.triggerEvent()太闹心了，封装组件不能模拟双向绑定，求官方看看是否可以这一块做出更好的方案。

小程序提供了路由功能来实现页面跳转，但是在使用的过程中我们还是发现有些不方便的地方，通过封装，我们可以实现诸如路由管理、简化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。

什么是kbone 微信小程序开发过程中，许多开发者会遇到 小程序 与 Web 端一起的需求，由于 小程序 与 Web 端的运行环境不同，开发者往往需要维护两套类似的代码，这对开发者来说比较耗费力气，并且会出现不同步的情况。 为了解决上述问题，微信小程序推出了同构解决方案 [代码]kbone[代码] 来解决此问题。 那么，[代码]kbone[代码] 要怎么使用呢？这里我们将通过一个 [代码]todo[代码] 的例子来跟大家讲解。 基本结构 首先，我们来看下一个基本的 kbone 项目的目录结构（这里的 [代码]todo[代码] 是基于 [代码]Vue[代码] 的示例，[代码]kbone[代码] 也有 [代码]React[代码]，[代码]Preact[代码]，[代码]Omi[代码] 等版本，详情可移步 kbone github）。 因为 kbone 是为了解决 小程序 与 Web 端的问题，所以每个目录下的配置都会有两份（小程序 与 Web 端各一份） [图片] 入口 不管是 小程序 端还是 Web 端，都需要入口文件。在 [代码]src/index[代码] 目录下，[代码]main.js[代码] 为 Web 端用主入口，[代码]main.mp.js[代码] 则为 小程序 端用主入口。 当然，Web 端会比 小程序 多一个入口页面，即 [代码]index.html[代码]（位于根目录下）。 [图片] 下面两段代码分别是 小程序端 入口与 Web 端入口的代码，可以看到 小程序端的入口代码封装在 [代码]createApp[代码] 函数里面（这里固定即可），内部会比 Web 端多一个创建 [代码]app[代码] 节点的操作，其他的基本就是一致的。 [代码]// 小程序端入口 import Vue from 'vue' import todo from './todo.vue' export default function createApp() { // 创建app节点用于绑定 const container = document.createElement('div') container.id = 'app' document.body.appendChild(container) return new Vue({ el: '#app', render: h => h(todo) }) } [代码] [代码]// web端入口 import Vue from 'vue' import todo from './todo.vue' new Vue({ el: '#app', render: h => h(todo) }) [代码] todo.vue 在上面的入口图可以看到，源码目录中，除了入口文件分开之前，页面文件就是共用的了，这里直接使用 Vue 的写法即可，不用做特殊的适应。 配置 写完代码之后，我们要怎么跑项目呢？这时，配置就派上用场啦。 Web 端配置为正常的 Vue 配置，小程序端配置与 Web 端配置的唯一不同就是需要引入 [代码]mp-webpack-plugin[代码] 插件来将 Vue 组件转化为小程序代码。 [图片] 构建代码 接着，我们需要构建代码，让代码可以运行到各自的运行环境中去。构建完成后，生产代码会位于 dist 目录中。 [代码]// 构建 web 端代码 // 目标代码在 dist/web npm run build // 构建小程序端代码 // 目标代码在 dist/mp npm run mp [代码] 小程序端 的构建会比 Web 端的构建多一个步骤，就是 npm 构建。 进入 [代码]dist/mp[代码] 目录，执行 [代码]npm install[代码] 安装依赖，用开发者工具将 [代码]dist/mp[代码] 目录作为小程序项目导入之后，点击工具栏下的 [代码]构建 npm[代码]，即可预览效果。 效果 最后，我们来看一下 todo 的效果。kbone 初体验，done~ todo 代码可到 kbone/demo13 自提。 [图片] 最后 如果你想了解更多 kbone 相关的使用及详情，可移步 kbone github。 如有疑问，可到 Kbone小主页 发帖沟通。

大家好，微信中调用统一下单接口如下 String xml = "<xml version='1.0' encoding='utf-8'>" + "<appid>" + orderPay.getAppId() + "</appid>" + "<body><![CDATA[" + orderPay.getBody() + "]]></body>" + "<mch_id>" + orderPay.getMchId() + "</mch_id>" + "<nonce_str>" + orderPay.getNonceStr() + "</nonce_str>" + "<notify_url>" + orderPay.getNotifyUrl() + "</notify_url>" + "<openid>" + orderPay.getOpenid() + "</openid>" + "<out_trade_no>" + orderPay.getOutTradeNo() + "</out_trade_no>" + "<spbill_create_ip>" + orderPay.getSpbillCreateIp() + "</spbill_create_ip>" + "<total_fee>" + orderPay.getTotalFee() + "</total_fee>" + "<trade_type>" +orderPay.getTradeType() + "</trade_type>" + "<sign>" + mysign + "</sign>" + "</xml>" 后，返回CDATA[openid参数长度有误] 我的openid，是在微信小程序获取openid时，生成的。如下所示 //请求参数 String params = "appid=" + wxspAppid + "&secret=" + wxspSecret + "&js_code=" + code + "&grant_type=" + grant_type; //发送请求 String sr = HttpRequest.sendGet"https://api.weixin.qq.com/sns/jscode2session", params); //解析相应内容（转换成json对象） JSONObject json1 = JSONObject.parseObject(sr); //获取会话密钥（session_key） String session_key = json1.get("session_key").toString(); //用户的唯一标识（openid） String openid = (String) json1.get("openid"); 请问该如何处理呢。谢谢了

目前是选择‘总是保持以上选择，"不再询问"后，可以在设置中开启或拒绝接收，但不会再次拉起授权弹窗

背景音频 BackgroundAudioManager    里 webUrl页面链接，原生音频播放器中的分享功能，分享出去的卡片简介，也将使用该值。 这个值怎么用呀，设置的页面链接在哪里看了

服务商模式下调用刷脸支付接口的时候，openid之前一直传的是sub_appid对应的openid，一直以来运行都没有问题。从今天凌晨开始突然就不行了，提示openid或sub_openid无效。 可以确定的是这段时间没有修改任何前后端的代码。刷脸支付突然不行这是什么情况？ 另外，除了刷脸支付，其他微信支付的接口调用都是正常的，比如小程序支付、刷卡支付等，也都是用sub_appid对应openid进行支付，目前都是正常的 [图片]

[图片] 之前也开发过很多小程序，都没有这个东西。现在这个点击可以回到首页，也可能是relaunch，没有仔细测试。我想知道是怎么来的，我看了设置项跟之前的代码没有什么差别啊

[图片] 小程序应避免出现任何 JavaScript 异常 出现 JavaScript 异常可能导致小程序的交互无法进行下去，我们应当追求零异常，保证小程序的高鲁棒性和高可用性 小程序所有请求应响应正常 请求失败可能导致小程序的交互无法进行下去，应当保证所有请求都能成功 所有请求的耗时不应太久 请求的耗时太长会让用户一直等待甚至离开，应当优化好服务器处理时间、减小回包大小，让请求快速响应 避免短时间内发起太多的图片请求 短时间内发起太多图片请求会触发浏览器并行加载的限制，可能导致图片加载慢，用户一直处理等待。应该合理控制数量，可考虑使用雪碧图技术或在屏幕外的图片使用懒加载 避免短时间内发起太多的请求 短时间内发起太多请求会触发小程序并行请求数量的限制，同时太多请求也可能导致加载慢等问题，应合理控制请求数量，甚至做请求的合并等 避免 setData 的数据过大 setData工作原理 小程序的视图层目前使用 WebView 作为渲染载体，而逻辑层是由独立的 JavascriptCore 作为运行环境。在架构上，WebView 和 JavascriptCore 都是独立的模块，并不具备数据直接共享的通道。当前，视图层和逻辑层的数据传输，实际上通过两边提供的 evaluateJavascript 所实现。即用户传输的数据，需要将其转换为字符串形式传递，同时把转换后的数据内容拼接成一份 JS 脚本，再通过执行 JS 脚本的形式传递到两边独立环境。 而 evaluateJavascript 的执行会受很多方面的影响，数据到达视图层并不是实时的。 由于小程序运行逻辑线程与渲染线程之上，setData的调用会把数据从逻辑层传到渲染层，数据太大会增加通信时间 常见的 setData 操作错误 频繁的去 setData Android 下用户在滑动时会感觉到卡顿，操作反馈延迟严重，因为 JS 线程一直在编译执行渲染，未能及时将用户操作事件传递到逻辑层，逻辑层亦无法及时将操作处理结果及时传递到视图层 染有出现延时，由于 WebView 的 JS 线程一直处于忙碌状态，逻辑层到页面层的通信耗时上升，视图层收到的数据消息时距离发出时间已经过去了几百毫秒，渲染的结果并不实时 每次 setData 都传递大量新数据 由setData的底层实现可知，数据传输实际是一次 evaluateJavascript 脚本过程，当数据量过大时会增加脚本的编译执行时间，占用 WebView JS 线程 后台态页面进行 setData 当页面进入后台态（用户不可见），不应该继续去进行setData，后台态页面的渲染用户是无法感受的，另外后台态页面去setData也会抢占前台页面的执行 避免 setData 的调用过于频繁 setData接口的调用涉及逻辑层与渲染层间的线程通过，通信过于频繁可能导致处理队列阻塞，界面渲染不及时而导致卡顿，应避免无用的频繁调用 避免将未绑定在 WXML 的变量传入 setData setData操作会引起框架处理一些渲染界面相关的工作，一个未绑定的变量意味着与界面渲染无关，传入setData会造成不必要的性能消耗 合理设置可点击元素的响应区域大小 我们应该合理地设置好可点击元素的响应区域大小，如果过小会导致用户很难点中，体验很差 避免渲染界面的耗时过长 渲染界面的耗时过长会让用户觉得卡顿，体验较差，出现这一情况时，需要校验下是否同时渲染的区域太大 避免执行脚本的耗时过长 执行脚本的耗时过长会让用户觉得卡顿，体验较差，出现这一情况时，需要确认并优化脚本的逻辑 对网络请求做必要的缓存以避免多余的请求 发起网络请求总会让用户等待，可能造成不好的体验，应尽量避免多余的请求，比如对同样的请求进行缓存 wxss 覆盖率较高，较少或没有引入未被使用的样式 按需引入 wxss 资源，如果小程序中存在大量未使用的样式，会增加小程序包体积大小，从而在一定程度上影响加载速度 文字颜色与背景色搭配较好，适宜的颜色对比度更方便用户阅读 文字颜色与背景色需要搭配得当，适宜的颜色对比度可以让用户更好地阅读，提升小程序的用户体验 所有资源请求都建议使用 HTTPS 使用 HTTPS，可以让你的小程序更加安全，而 HTTP 是明文传输的，存在可能被篡改内容的风险 不使用废弃接口 使用即将废弃或已废弃接口，可能导致小程序运行不正常。一般而言，接口不会立即去掉，但保险起见，建议不要使用，避免后续小程序突然运行异常 避免过大的 WXML 节点数目 建议一个页面使用少于 1000 个 WXML 节点，节点树深度少于 30 层，子节点数不大于 60 个。一个太大的 WXML 节点树会增加内存的使用，样式重排时间也会更长 避免将不可能被访问到的页面打包在小程序包里 小程序的包大小会影响加载时间，应该尽量控制包体积大小，避免将不会被使用的文件打包进去 及时回收定时器 定时器是全局的，并不是跟页面绑定的，当页面因后退被销毁时，定时器应注意手动回收 避免使用 css ‘:active’ 伪类来实现点击态 使用 css ‘:active’ 伪类来实现点击态，很容易触发，并且滚动或滑动时点击态不会消失，体验较差 建议使用小程序内置组件的 ‘hover-*’ 属性来实现 滚动区域可开启惯性滚动以增强体验 惯性滚动会使滚动比较顺畅，在安卓下默认有惯性滚动，而在 iOS 下需要额外设置 [代码]-webkit-overflow-scrolling: touch[代码] 的样式