微信号:FrontDev

介绍:分享 Web 前端相关的技术文章、工具资源、精选课程、热点资讯

小程序开发实践总结

2018-08-25 20:07 前端大全

(点击上方公众号,可快速关注)

作者:Darko 

segmentfault.com/a/1190000016027966


从微信发布小程序以来,各大公司纷纷跟进都想从微信这个流量池里捞一杯羹。我司也不例外,我们整个前端团队这半年来基本上都是在开发小程序。前前后后也开发了四五个小程序了。总觉得要留下点什么,既是记录那些年我们踩过的坑,也是希望大家别再掉坑。


那些年我们踩过的坑


  • css样式不能引用本地图片资源,只能引用线上资源(background-image),引用本地图片资源只能用<image>标签。

  • {{}}不能执行函数方法,{{}}只支持基本的简单运算和ES6拓展运算符。如价格格式化这种常用的处理,只能在js代码中处理好然后再模板中渲染。


this.setData({

  price: this.formatPrice(this.data.price)

})


  • 可以通过wxs模块解决{{}}中不能执行函数的问题。可以做到模拟vue.js中过滤器的功能。


<!-- wxml模板 -->

<wxs src="../../modules/formatPrice.wxs" module="tools" />

 

<view>价格:{{tools.formatPrice(price)}}</view>

// wxs模块

var formatPrice = function (price){

    price = price >> 0;

    return Number(price / 100).toFixed(2);

}

 

module.exports = {

    formatPrice

}


  • 小程序不支持分享链接到朋友圈,暂时的通用做法是生成保存有页面小程序码的图片到本地相册。又用户自行发朋友圈转发。前端可以利用canvas来实现,减轻服务端压力。但是会有图片锯齿不清晰的问题。建议预览图和保存到真机的图片采用不同的尺寸。保存在真机的图片按照750的宽度实现。相比于预览图要大一些,这样保存到手机的图片会清晰很多。

  • 小程序布局采用rpx单位,UI稿按照750的宽度出图。可直接使用UI稿的尺寸。但是在某些机型上1rpx会无法显示。可以用H5的方式实现1px效果。

  • iphoneX吸底按钮的适配,可以用媒体查询获取wx.getSystemInfo获取机型。


@media only screen

    and (device-width : 375px)

    and (device-height : 812px)

    and (-webkit-device-pixel-ratio : 3) { }


  • 页面A -> 页面B,页面B的操作触发了页面A的数据更新。返回更新页面A的数据,通常有两种方式来实现(我司采用了方案二):

  • 在页面A监听onShow事件,在onShow事件触发时无脑更新页面数据。

  • 通过EventBus来实现跨页面通信。

  • 复杂组件的开发,省市区三级联动选择器的开发,获取微信地址库的地址的编码和业务采用的省市区编码对不上。

  • 页面路径的层级,最大不能超过10层。

  • 小程序小程序分包加载,微信对小程序包的大小有如下限制。

    • 整个小程序所有分包大小不超过 8M

    • 单个分包/主包大小不能超过 2M


微信小程序主流框架对比


  • wepy

  • mpvue

  • Taro


wepy


wepy应该算是最早发布的小程序开发框架,提供了类vue.js的语法风格和特性,现阶段应该也是应用最广泛的框架吧。我开发的几个小程序也都是采用了wepy这个框架。我先来说说当初为什么选择这个框架的原因吧。


  1. 类Vue.js的语法风格,适合我们团队原有的的技术栈

  2. 支持组件化(当时微信官方的API还不支持组件化)

  3. 支持加载外部npm包

  4. 支持ES6的写法


前期使用wepy的过程中,wepy自带bug。不过好在开发者响应及时,基本上都能覆盖大部分场景。


但是有个最大的坑点就是,wepy组件的实现方式。组件使用的是静态编译组件,即组件是在编译阶段编译进页面的,每个组件都是唯一的一个实例。 多个组件共享同一个数据。并且静态编译组件。导致组件A,在页面A和页面B被引用,会copy两份代码到页面A和页面B内部。导致拆分组件并没有对包的体积有任何减少。后期微信官方API支持组件化编程后,我们逐步把一些比较核心,体积较大的组件用原声API重构了。


mpvue


由美团团队开发,mpvue和wepy一样也是在小程序上提供了类vue.js的开发体验。作为后来者,抢占了很多wepy的市场份额(ps:我们团队近期也在考虑从wepy迁移到mpvue)。这个框架的原理相比wepy要更加复杂一点,mpvue 修改了 Vue.js 的 runtime 和 compiler 实现,提供了更加接近于vue.js的开发体验。


Taro


Taro是由京东团队开源的一套遵循 React 语法规范的多端开发解决方案。本身我对React和Taro都不是很了解,就不多解释了。具体可以看开发团队的博客和代码了解更多细节多端统一开发框架 – Taro



我看小程序


我想从技术的角度来谈谈我对微信小程序的理解,我觉得小程序本身是一个非常优秀的Hybrid App的技术方案。有很多值得学的地方,可以应用到我们Hybrid App的技术方案设计中来。了解和学习小程序技术原理也能更好的优化我们的代码。


渲染层和逻辑层分离



相比于之前常见的Hybrid的方案,小程序使用了双线程模型:小程序的渲染层和逻辑层是是分开的,逻辑层通过JSCore来解析和执行,渲染层是通过webview来渲染。之前的常见Hybrid离线包的方案大多使用webview同时实现页面的渲染和js的解析。这样做的的结果就是隔离了js的runtime,在js代码中无法操作webview中的DOM对象和BOM对象。Js无法做任何和页面渲染有关的操作。只能通过setData把数据从JsCore传递到webview。


独立的JS运行环境,相比于webview同时处理页面的渲染和JS的执行带来了一些好处:


  1. js无法动态的在页面插入节点和干预页面的渲染,解决了安全和管控的问题,否则小程序的上线审核就变得毫无意义。

  2. 渲染层和逻辑层的分离,减轻了webview的压力,js的执行和页面的渲染可以并行,不会出现js执行卡主页面渲染的情况。

  3. 多个页面可以共享一个JS运行环境,数据很方便的共享,整个小程序的生命周期共享同一个上下文,接近App的体验。


坏处在于:


  1. 多了很多webview和JSCore数据传输的消耗,数据需要序列化成字符串格式进行传输。


离线包加载


离线包加载,常见的Hybrid App通过webview加载H5页面,前端页面都是放在服务器端。虽说保证了灵活性。但是加载性能收网速影响大。页面切换白屏时间长。小程序离线包的加载方式。一次性加载所有的前端资源到本地再解压。大大提升了用户体验。不过微信官方为了防止下载离线包的时间过程,也严格限制了小程序包的体积。(分包加载情况下子包大小不能超过2M,也就是初次打开加载的资源不能超过2M)


多webview架构


多webview的页面架构,小程序每新开一个页面,都会用一个新的webview来渲染。为了防止webview对内存的消耗。小程序限制层级不能超过10层。


预加载webview


预加载webview,微信会预加载多一个wkwebview(ios平台)放后台,用户打开小程序时省去初始化wkwebview时间。



【关于投稿】


如果大家有原创好文投稿,请直接给公号发送留言。


① 留言格式:
【投稿】+《 文章标题》+ 文章链接

② 示例:
【投稿】《不要自称是程序员,我十多年的 IT 职场总结》:http://blog.jobbole.com/94148/

③ 最后请附上您的个人简介哈~



觉得本文对你有帮助?请分享给更多人

关注「前端大全」,提升前端技能

 
前端大全 更多文章 用 JS 写一个同 Excel 表现的智能填充算法 换壳 Chrome 的红芯浏览器,曾拿数百万政府和国企订单 程序员群嘲红芯浏览器:注释过度很业余 创新混淆视听 微信小程序30分钟从陌生到熟悉(上) 微信小程序30分钟从陌生到熟悉(下)
猜您喜欢 喜大普奔,PHP7正式发布! App架构之组件化理解 Kubernetes救援 - 教你如何从新技术的坑里爬出来(上) | TW洞见 打开MySQL数据库远程访问的权限