微信小程序开发——进阶篇

提示：扫一扫查出行
【扫一扫了解最新限行尾号】
复制提示

由于项目的原因，最近的工作一直围绕着微信小程序。现在也算告一段落，是时候整理一下这段时间的收获了。我维护的小程序有两个，分别是官方小程序和一个游戏为主的小程序。两个都是用了wepy进行开发，就是这个：

由于是进阶篇，所以一些有关于开发基础的我就直接跳过，直接讲我最近遇到的几个需求场景。写的急，可能顺序有一些乱，还请见谅！

用什么框架开发小程序？

现有的比较公认的有3个小程序开发框架：原生、wepy、mpvue。3者个有利弊：

原生框架：微信的亲儿子，可直接在微信开发者工具中开发，方便调试，结构直接对应微信文档，框架无缝升级，最快支持最新版本的开发基础库。缺点是原生开发提供的开发方式比较朴素，缺乏大量的语法糖和成熟的组建化模式。
wepy：出现的较早，有大量的开发者支持，已由此基础上开发了大量的小程序，在早起原生框架不支持组件化时率先提出组建化小程序开发模式，并加入async/await的支持和类vue的语法。但本身和vue仍有差距，且不支持vuex类似的数据管理，更多解决的是view层的问题
mpvue：真正的vue开发模式，并且支持vuex 。可用vue-cli初始化项目，短期内就积累了11.38k的star（wepy：12.3k）成长迅速，但出现较晚，且基于mpvue的小程序还远远少于wepy。

我选用wepy主要是时间较早，mpvue还没兴起，wepy也是比较稳定，如果现在有个新的小程序要做，我很可能会选用mpvue。

小程序的调试vConsole

先来一个简单的就是在非正式环境下启动调试：点击菜单的三个点的按钮-》打开调试-》重启小程序-》打开右下角的vConsole

当然文档中还有远程调试等，文档写的比较细，我就不多说了。

如何全屏展示小程序？

小程序有一个自己的 navigationBar，如果有APP开发经验的同学应该知道，navigationBar也就是程序最顶部的一条，我们同常的开发页面，也都是在navigationBar下方的主体区用标签开发UI部分

如下面两个图片，左边的翻译君官方小程序中上面就有这样一个navigationBar用于展示自己的title和菜单按钮；但是右侧的小程序中就没有这样的navigationBar，而是页面直接覆盖整个屏幕，开发了一个全屏的小程序。

那么两种模式有什么区别呢？

有navigationBar的小程序上方有一个系统导航区，这个区域不可定制化，可以通过配置小程序的app.json（https://developers.weixin.qq.com/miniprogram/dev/framework/config.html）来配置或者在js中调用wx.API（https://developers.weixin.qq.com/miniprogram/dev/api/ui.html#wxsettopbartextobject）。
无navigationBar的小程序则完全相反，整个屏幕都是开发区域，都可以用前端标签+样式自定义。原有的菜单相当与浮在页面的右上角。可控区域变大。

那是不是无navigationBar的模式更好？

模式的配置是在app.json中的window配置navigationStyle为default/custom（default：默认有navigationBar；custom自定义即无navigationBar全屏），值得注意的是这个属性是在微信版本 6.6.0之后才有的（2018年2月左右，正好是我开发右侧小程序的时候）

这两种模式最好要保持风格统一，小程序的每一个page都会继承这个属性，最好不要在不同的页面动态设置这个值。

如果有navigationBar的话不仅有title和菜单，还会在页面跳转后记录跳转历史，并在右上角提供一个后退的按钮比如下图，如果全屏模式的话，就要自己维护导航历史了。

navigationBar的模式下定制化较弱，背景色只能是RGB，不带透明度，不能有背景图，如果有这种需求，就要用全屏模式；另外当我在页面区域有一个蒙层或全屏的fixed（100%）时，navigationBar的模式也无法盖到navigationBar区域。

选用哪种模式就要看你的设计风格和产品需求，并尽量风格统一。二者个有利弊，我建议工具类的用navigationBar显得更整洁、正规；游戏类的用全屏自定义，增加可操作区域。

页面跳转的次数限制

既然刚刚提到了navigationBar中的导航历史，我们就说一下这个导航历史栈的大小问题，目前的导航跳转共有两种方式：

<navigator>组件（https://developers.weixin.qq.com/miniprogram/dev/component/navigator.html）
wx.api调用（https://developers.weixin.qq.com/miniprogram/dev/api/ui-navigate.html）

在wx.navigateTo(OBJECT)的文档中明确的写出 “注意：目前页面路径最多只能十层。” 也就是说导航历史栈大小是10，但是我实际开发中发现基本到5的时候就已经报错了。

为了避免出现历史栈满了的情况，建议大家在跳转到不需要有返回的页面调用wx.reLaunch(OBJECT) 关闭所有页面，打开到应用内的某个页面。这个API可以清空历史栈，或者当用户跳转到首页的时候，主动清空历史栈。

小程序打开另一个小程序

我这次要做的一个很大的功能就是小程序的相互调起，而且打开同一公众号下关联的另一个小程序。（注：必须是同一公众号下，而非同个 open 账号下）。

比较贴心的是，虽然可以指定打开对应小程序的版本（开发、体验、正式），但是正式的只能打开正式的，避免了测试代码上线的风险。

在这里小程序一共提供了两种方法，但是并不是两种方法可以通用替换的：

调用API wx.navigateToMiniProgram(OBJECT) （https://developers.weixin.qq.com/miniprogram/dev/api/navigateToMiniProgram.html）
<navigator>使用组件（https://developers.weixin.qq.com/miniprogram/dev/component/navigator.html）

二者不可替换，在API wx.navigateToMiniProgram(OBJECT) 的文档中写到：

也就是说API wx.navigateToMiniProgram(OBJECT)有可能随时被废弃掉，但是与之对应的API：wx.navigateBackMiniProgram(OBJECT)却没说要废弃。

新的调转方式 <navigator>的文档中又写到：

也就是说API的调用有可能废弃，新的组件功能，还要看当前的库够不够新。所以需要开发者做好兼容处理。

wx.canIUse判断API可用性

对于上面的情况在微信小程序的开发过程中还有很多，我们不能依靠版本号来判断可用性，那样的成本是巨大的且不好管理，还好微信提供了wx.canIUse（https://developers.weixin.qq.com/miniprogram/dev/api/api-caniuse.html?search-key=can）来辅助判断API的可用性。它的强大住处在于不仅仅能判断js的API还能判断组件的可用性：

这样就不怕微信API的变化了。

小程序的关闭

有一些场景需要我们关闭小程序，但是文档中并没有这样一个API，我在开发中一个小程序打开另一个后，被打开的小程序在完成任务后许哟啊关闭自身，最开始我用的方法是利用微信的bug，后退大于导航历史的层数，即：

wepy.navigateBack({
delta: 10
})

这样就会触发关闭小程序，但是后来这个bug被修复了，我又找到了另一个方法，即wx.navigateBackMiniProgram(OBJECT)，直接返回。但是对于非被调起的小程序，还是没有方法。

小程序的webview

小程序作为一款类APP的的开发生态，齐必然可以加载H5页面，使用的就是小程序的组件<web-view> (https://developers.weixin.qq.com/miniprogram/dev/component/web-view.html)。如图：

有两点值得注意的是：

web-view会自动铺满小程序（不包含navigatorBar的内容区），也就是说，要用就必须是作为一个页面，绝对不能作为页面的一部分，可能是考虑安全性。
被加载的页面必须是在小程序后台配置了业务域名的，这是一个域名白名单。而且配置的过程需要又一个域名校验的过程，小程序会生成一个校验文件，放在对应域名的根路径下，只有访问到了这个文件，才能校验通过。也就是说自己维护的或者与对方达成一致的才能作为三方H5页面来访问。