图文讲解uni-app支持PC宽屏

天下苦平台碎片化已久。

在移动互联网以前,开发者只需幸福的面对web。进入移动互联网时代,iOS、Android、H5以及各种小程序快应用层出不穷,开发者再也幸福不起来。
– 学习n个技术
– 开发n个版本
– 各版迭代混乱,无法拉齐,用户茫然、内部痛苦
– 开发测试成本n倍暴涨

结果就是工程师不停加班到头秃,但产品的需求仍然做不完、老板的预算一直压不下去,全都痛苦。

uni-app之前已经实现了手机端全覆盖,支持iOS、Android、H5、微信小程序、阿里小程序、百度小程序、字节跳动小程序、QQ小程序、快应用、360小程序,并且在各端均有优异的运行性能。

从2.9版本起,uni-app 进一步提供了PC等宽屏的适配方案,完成了大统一。

开发者终于可以做到使用一个框架,一把撸掉所有项目。

不说虚的,先来个实际示例,大家直观感受一下:

如下是基于uni-appDCloud社区在mobile端的展示效果,列表、详情分为两个页面,点击列表中的帖子,打开详情页面:

如下是基于uni-appDCloud社区同一套代码,稍作配置后,在pc端的展示效果,列表、详情在同一个页面中左右分栏显示,点击左侧列表中的帖子,刷新右侧详情窗口的内容,这个UI更适合pc宽屏,也更有pc桌面App的体验。

Tips:点击 DCloud社区演示系统,自己感受PC和Mobile的自适应。

怎么样?有没有被酷到?

下面我们具体来讲讲uni-app的pc宽屏适配方案,总的来说,包括三个方面:
– 窗体级适配:leftwindow、rightwindow、topwindow等分栏
– 组件级适配:match-media组件
– rpx的宽屏响应

1. 窗体级适配:leftwindow分栏

手机屏幕和PC显示器的设计不同。为了方便手持及接听电话,大多手机的设备高度大于设备宽度(即为窄屏设计),故mobile App 多为竖屏/窄屏显示的UI。

而pc显示器多为宽屏设计,即设备宽度大于设备高度,在pc上的桌面应用,很多会采用左右分栏的UI设计。

uni-app以目前手机屏幕为主窗体(window),在左/右/上三个方向,新扩展 leftWindowrightWindowtopWindow三个窗体,这三个窗体可设定在屏幕宽度大于某一阀值时自动出现(展现分栏的宽屏设计),屏幕宽度小于某一阀值后自动消失(恢复单窗口的窄屏设计)。

uni-app主窗体和扩展的三个窗体各自独立,支持互相通信,点击链接、切换页面时支持在相应的窗体内刷新,而不是整屏刷新。

我们以本文开头的DCloud社区为例,讲解如何在uni-app中快捷实现宽屏适配。

我们将社区的列表页作为主窗体,将详情内容扩展到rightWindow中,示意如下:

接下来分步说明,如何在uni-app项目中完成分栏实现。

step 1: 新建right-window.vue展现帖子详情

当然,rightWindow无需重写新闻详情页面,是可复用原有代码的,支持把已有详情页面当组件放到 rightWindow 页面中,如下:

<!-- responsive/right-window.vue -->
<template>
  <view>
    <!-- 将原来的详情页(/pages/detail/detail.vue),作为一个组件(pages-detail-detail)使用 -->
    <pages-detail-detail ref="detailPage"></pages-detail-detail>
  </view>
</template>

<script>
  export default {
    created(e) {
      //监听自定义事件,该事件由左侧列表页的点击触发
      uni.$on('updateDetail', (e) => {
        // 执行 detailPage组件,即:/pages/detail/detail.vue 页面的load方法
        this.$refs.detailPage.load(e.detail);
      })
    }
  }
</script>

step 2: 在列表页面,处理点击列表后与rightWindow交互通信的逻辑。

// 列表页的改造
goDetail(detail) {
    if (this._isWidescreen) { 
        //若为宽屏,则触发右侧分栏详情页的自定义事件,通知右侧窗体刷新新闻详情
        uni.$emit('updateDetail', {
            detail: encodeURIComponent(JSON.stringify(detail))
        })
    } else { 
        // 若为窄评,则打开新窗体,在新窗体打开详情页面
        uni.navigateTo({
            url: '/pages/detail/detail?query=' + encodeURIComponent(JSON.stringify(detail))
        });
    }
},

step 3:pages.json中注册rightWindow,如下:

{
  "rightWindow": {
    "path": "responsive/right-window.vue", // 指定 rightWindow 页面文件
    "style": {
      "width": "calc(100vw - 400px)" // 页面宽度
    },
    "matchMedia": {
      "minWidth": 768 //生效条件,当窗口宽度大于768px时显示
    }
  }
}

可以看到,无需太多工作量,就可以快速把一个为手机窄屏开发的应用,快速适配为PC宽屏应用。并且以后的代码维护,仍然是同一套,当业务迭代时不需要多处升级。

这套方案的实施,有如下特征:

  • 原先为手机窄屏开发的代码,基本无需修改,可完全适配到pc宽屏上;后续新增的业务模块,也是一套代码,同时兼容款窄屏。
  • 增加pc宽屏适配后,不影响原先mobile端的窄屏实现,窄屏上会自动隐藏leftWindow/rightWindow等扩展窗体。
  • rightWindow里的页面是复用的,不需要重写新闻详情页面,支持把已有详情页面当组件放到 rightWindow 页面中。

更多配置细节,详见文档:https://uniapp.dcloud.net.cn/collocation/pages?id=topwindow

leftWindow方案除了适用于将原有的Mobile App适配到大屏显示,也适用于新开发的PC应用,尤其是PC Admin管理控制台。

如下是基于leftwindowtopwindow构建的经典pc admin布局:

2. 组件级适配:match-media组件

leftWindow等方案是页面窗体级适配方案,适用于多页面的组合分栏显示。

那么在同一个页面中,组件是否可以适配不同屏宽?当然可以,此时可以使用组件级适配方案。

除了传统的css媒体查询外,uni-app还提供了全平台兼容的 match-media组件 和配套的 uni.createMediaQueryObserver 方法。

match-media是一个媒体查询适配组件,可以更简单的用于动态屏幕适配。

match-media组件中放置内容,并为该组件指定一组 media query 媒体查询规则,如屏幕宽度。运行时,如屏幕宽度满足查询条件,则这个组件就会被展示,反之则隐藏。

match-media组件的优势包括:
1. 开发者能够更方便、显式地使用 Media Query 能力,而不是耦合在 CSS 文件中,难以复用。
2. 能够在模板中结合数据绑定动态地使用,不仅能做到组件的显示或隐藏,在过程式 API 中可塑性也更高。
3. 能够嵌套式地使用 Media Query 组件,即能够满足局部组件布局样式的改变。
4. 组件化之后,封装性更强,能够隔离样式、模版以及绑定在模版上的交互事件,还能够提供更高的可复用性。

uni-app推荐采用运行时动态适配的方案,而不是为PC版单独编写条件编译(虽然你也可以通过自定义条件编译来实现单独的PC版)。这样设计的好处是在ipad等设备的浏览器上可以方便的横竖屏切换。

3. rpx的宽屏响应

设计Mobile App时,设计师常会以 iPhone6 作为视觉稿的标准,即按照750px屏幕宽度出图;程序员以750px作为基准,根据设备实际尺寸,动态换算(缩放)出适合当前设备屏幕的元素宽高。

这就是rpx(responsive pixel)的实现思路,只不过rpx由框架引擎动态换算元素尺寸,无需程序员写代码干预。

面向mobile端时,rpx是一种很理想的解决方案,因为各种移动设备的屏幕宽度差异不是很大,相对于750px微调缩放后的效果,可最大化的还原设计师的设计。

但是,一旦脱离移动设备,在pc屏幕,或者pad横屏状态下,因为屏幕宽度远大于750了。此时rpx根据屏幕宽度变化的结果就严重脱离了预期,大的惨不忍睹。

假设一个图文列表的展现,我们针对左侧缩略图定义如下css:

.uni-media-list-logo {
    width: 180rpx;
    height: 140rpx;411*(180/750)411*(180/750)411*(180/750)
}

在手机端,这个显示效果是比较理想的,如下:

当前选择 pixel 2作为模拟设备,屏幕宽度为411px,故缩略图的宽度变为:180*(411/750) = 98px,高度变为:140*(411/750) = 76px,这个理论计算和实际运行相符,且效果较佳。

同样的代码,如果运行到pc端,假设屏幕宽度为1920px,则缩略图的尺寸将变为:180*(1920/750) = 460px,高度变为:140*(1920/750) = 358px,这个惨不忍睹的大就出来了,一个1920*1080的显示器,只能显示2条记录(主要是缩略图高度放大导致的),效果如下:

为此,在uni-app 2.9+起,新增了 rpx 按750px做基准屏宽的生效范围控制,即屏幕宽度超过某阀值(默认为960px)后,将不再以屏幕实际宽度换算元素宽高,而改以固定屏幕宽度(默认为375px)计算元素宽高。

以上述图文列表为例,当屏幕宽度为1920px(大于960px)时,将采用固定的屏幕宽度(默认375px)计算缩略图的宽高,即:180*(375/750) = 90px,高度变为:140*(375/750) = 70px,按照这个机制,pc端运行效果如下,相比上图的放大变丑,展现更为理想优雅。

Tips:
– 750px生效的屏幕宽度阀值,及宽屏时计算所用的固定屏幕宽度,均支持自定义配置

{
  "globalStyle": {
    "rpxCalcMaxDeviceWidth": 960, // rpx 计算所支持的最大设备宽度,单位 px,默认值为 960
    "rpxCalcBaseDeviceWidth": 375, // 设备实际宽度超出 rpx 计算所支持的最大宽度时,rpx计算所采用的固定屏幕宽度,单位 px,默认值为 375
  }
}
  • 开发者可在rpx宽度管控的基础上,略作调整,实现更好的pc宽屏效果,如宽屏时,固定列表宽度且居中显示,如下图。当然,此处仅为了演示rpx在宽屏下的失控管理,实际应用中,可采用分栏窗口,将列表在左侧分栏中显示,如本文开篇示例截图。

4. 补充

4.1 通过electron打包为windows、mac、linux客户端

有了宽屏适配,uni-app的应用就可以方便的通过electron打包为电脑客户端应用,windows、mac、linux均支持。

开发者可以随意调用electron的API,以调用更多操作系统的能力(为方便多端兼容,可以将这些特殊API写在自定义的条件编译里)

uni-app插件市场有已经封装好的一些插件,详见:https://ext.dcloud.net.cn/search?q=electron

4.2 一个让手机版网页临时可用于pc浏览器的方案

如果你的h5版已经开发完毕,还没来得及适配pc,但想在pc上先用起来。那么可以在pc网页里使用iframe,约定好宽度,在里面套用uni-app的窄屏版。

当然还可以在iframe旁边放置二维码,提供手机版扫码地址,如下是一个实现示例:

5. 结语

uni-app团队将keep running,继续完善uni-app在pc、pad等宽屏设备上的更好适配,并会在ssr、serverless方向上重点投入,提供云端一体的更高效率的解决方案(详见uniCloud),帮助企业更高效,帮助开发者更轻松!

欢迎大家到https://github.com/dcloudio/uni-app上给我们star鼓励😄

uniapp和ionic的区别是什么?

1、uni-app是多webview模式,ionic是单webview模式;故uni-app的窗口动画是webview的原生动画,ionic的动画是spa的div动画,故uni-app的窗口动画效果更佳;

2、uni-app架构和小程序一致,逻辑层、视图层分离,JS运行在v8中,页面渲染在webview中,因此JS的逻辑计算不会和UI渲染竞争资源。而ionic的js运行在webview中,js和UI渲染会竞争资源。

3、uni-app除了支持web渲染,还支持weex原生渲染;ionic仅支持web渲染。

4、uni-app内置支持微信登录、支付、分享等国内常见的SDK,ionic需自己集成或使用三方SDK。

5、uni-app支持跨端发行,可同时生成小程序、H5(包括PC端),这个ionic显然是不行的。

uni-app支持PC版360小程序

uni-app 开发 360 小程序

uni-app 是一个遵循 Vue.js 语法的跨端框架,开发者编写一套代码,可发布到App、H5、小程序(微信/阿里/百度/字节跳动)及快应用。

近期,uni-app新增支持发行到360小程序平台,目前hello uni-app 已上线360小程序,可以在360浏览器中点击链接打开体验:so.mp.360.cn

如下是简易体验教程,Enjoy~

通过 HBuilderX 可视化界面

  1. 下载HBuilderX,官方地址

  2. 创建uni-app项目

HBuilderX开发者工具中,点击文件 -> 新建 -> 项目:选择uni-app类型,输入工程名,选择模板,点击创建,即可成功创建。

  1. 进入已创建的项目,点击工具栏的运行 -> 运行到小程序模拟器 -> 360开发者工具,等待编译完成时自动调起 360浏览器

  1. 在360浏览器中导入编译后的目录,见 HBuilderX 控制台输出

  2. HBuilderX中修改代码,uni-app编译器会热更新到 360浏览器

注意: 运行时为未压缩代码,正式上线时需要点击发行菜单

通过vue-cli命令行

习惯cli脚手架的同学,可以通过vue-cli创建uni-app项目。

  1. 全局安装vue-cli
npm install -g @vue/cli
  1. 创建uni-app项目,选择项目模板
vue create -p dcloudio/uni-preset-vue my-project

此时,会提示选择项目模板,初次体验建议选择 hello uni-app 项目模板,如下所示:

  1. 使用如下命令进行360小程序的编译预览及发行打包
# npm script
# dev 模式,编译预览
$ npm run dev:mp-360
# build 模式,发行打包
$ npm run build:mp-360

发行到360小程序,需要你下载并打开360浏览器,然后选择项目编译目录(dev模式、build 模式编译目录不同,见下方说明)进行预览或发行。

dev模式 和 build 模式的区别:
– dev 模式编译目录为项目根目录下的 /dist/dev/ 目录
– build 模式编译目录为项目根目录下的 /dist/build/ 目录
– dev 模式有 SourceMap 可以方便的进行断点调试
– build 模式会将代码将会进行压缩,体积更小更适合发布为正式版应用

开发规范

uni-app 内置的组件及API已兼容360小程序,详见uni-app官网

对于 360 小程序特殊的组件及API,可以通过条件编译调用360原生能力。

问题反馈

大家在使用 uni-app 开发360小程序时,若碰到问题,欢迎到 DCloud问答社区交流反馈。

小程序的未来方向

序言:DCloud CTO 崔红保在 GMTC 全球大前端技术大会(深圳站)2019 分享了 《小程序的未来方向》,介绍了小程序技术架构,分析了通讯阻塞、混合渲染、同层渲染等深层次问题,这里是针对演讲整理的文字版,分享给大家,Enjoy~

简单介绍一下我自己:

分享大纲

简要介绍今天的分享大纲,罗马不是一天建成的,小程序也不是一天发明的;小程序这种介于H5和Native App之间的特殊应用形态,从探索到成熟,经历了哪些过程,我们首先带大家回顾梳理一下,然后从现有技术架构出发,分析小程序当下几个主要性能坑点,各家小程序引擎为解决这些坑点,做了哪些完善工作;比如大家知道小程序是以web渲染为主、原生渲染为辅,那引入原生渲染后,引发了哪些新的问题?为解决这些,微信提出了同层渲染的方案,同层渲染在技术层面上又是如何实现的?最后从当前已知问题出发,对于小程序未来的技术更迭,抛出一些我们认为的可能方向,供大家参考。

小程序历史

HTML5 于 2007 年在 W3C 立项,与 iPhone 发布同年。

乔布斯曾期待 HTML5 能帮助 iPhone 打造起应用生态系统。

但 HTML5 的发展速度并不如预期,它虽然成功地实现了打破 IE+Flash 垄断局面的目标,却没有达到承载优秀的移动互联网体验的地步。

于是在 iPhone 站稳脚跟后,发布了自己的 App Store,开启了移动互联网的原生应用时代。

大家知道现在手机端主要是iOS、Android两大系统,实际上在早期有3大系统竞争,还有一个就是诺基亚的Meego系统,MeeGo 采用 C + HTML5 的双模应用生态策略,然而 C 的开发难度太大,HTML5 体验又不行,所以后来 MeeGo就掉队了;与之对应,Android 依靠 Java 技术生态,在竞争中脱颖而出。

于是在移动互联网初期,应用生态被定了基调 —— 原生开发。

在那个时候,硬件不行,也没有其他办法,原生开发才能在低配硬件上带来商用体验。

但大家都在怀念 HTML,那种无需安装更新、即点即用,直达二级页面的特点,一直让人迷恋。

国内有一批做浏览器的厂商,尝试去改进 HTML5,比如百度在2013年的百度世界大会上发布了轻应用,方式是通过给 WebView 扩展原生能力,补充 JS API,让 HTML5 应用可以实现更多功能。

不过这类业务没有取得成功,HTML5 的问题不止是功能不足,性能体验是它更严重的问题,而体验问题,不是简单地扩展 JS 能力能搞定的。

这类业务发展的顶峰,是微信在2015年初发布的微信 JS SDK,作为国内事实上最大的手机浏览器,微信为它的浏览器内核扩充了大量 JS API,让开发者可以用 JS 调用微信支付、扫码等众多 HTML5 做不到的功能。

但微信团队对这套方案的体验仍然不满意,微信钱包栏目里打车、理财等很多应用虽然嵌入了 JS SDK,但每次点击要等半天白屏,让人用着很痛苦,他们在业内开始寻找新的解决方案。

与浏览器不同,Hybrid 应用是另一个细分领域,开发者使用JS编写应用,为了让 JS 应用更接近原生应用的功能体验,这个行业的从业者做出了很多尝试。我们DCloud公司是业内主流Hybrid App引擎提供方之一,我们提出了改进 HTML5 的“性工能”障碍的解决方案 —— 通过工具、引擎优化、开发模式调整,让开发者可以通过 JS 写出更接近原生 App 体验的应用。

多 WebView 模式,原生接管转场动画、下拉刷新、Tab 分页,预载 WebView……各种优化技术不停迭代,终于让 Hybrid 应用取得了性能体验的突破。

Hybrid 应用和普通的轻应用相比,还有一个巨大的差别:一个是 Client/Server,一个是 Browser/Server。简单来说,Hybrid 应用是 JS 编写的需要安装的 App,而轻应用是在线网页。

C/S 的应用在每次页面加载时,仅需要联网获取 JSON 数据;而 B/S 应用除了 JSON 数据外,还需要每次从服务器加载页面 DOM、样式、逻辑代码,所以 B/S 应用的页面加载很慢,体验很差。

可是这样的 C/S 应用虽然体验好,却失去了 HTML5 的动态性,仍然需要安装、更新,无法即点即用、直达二级页面。

那么 C/S 应用的动态性是否可以解决呢?对此,DCloud首先提出了流应用概念,把之前 Hybrid 应用里的运行于客户端的 JS 代码,先打包发布到服务器,制定流式加载协议,手机端引擎动态下载这些 JS 代码到本地,并且为了第一次加载速度更快,实现了应用的边下载边运行。

就像流媒体的边下边播一样,应用也可以实现边用边下。

在这套方案的保障下,终于解决了之前的各种难题:让 JS 应用功能体验达到原生,并且可即点即用、可直达二级页面。

这套技术,需要让客户端引擎提前预置在手机上,就像流媒体的普及,建立在 Flash 的装机量巨大的基础上,那么普及这个客户端引擎就变得很重要。

2015 年,360 和 DCloud 合作,在 360 手机助手里内嵌了这个客户端引擎,推出了业内第一个商用的小程序,360 称之为 360 微应用,这个实际上是国内小程序形态的最早原型。

之后,DCloud曾找过几个大厂探索过流应用的合作方式,并在部分厂商中发行上线,比如金立的应用市场、中国移动的MM市场等;但各大公司的利益诉求不同,流应用想借助大厂流量快速推广的愿望,困难重重。

接着就是微信小程序,最初的名字实际上是微信应用号,之后改名为小程序,2016年9月份内测,2017年1月正式发行,再之后阿里巴巴、手机厂商联盟、百度、今日头条,陆续推出了自己的小程序平台,小程序时代滚滚而来。

小程序火爆了,开发者的困扰也跟着来了,各家小程序规范各不相同,每个平台单独开发一套小程序,人力成本极大,DCloud看到开发者这些真实痛点,随之提供了小程序跨端开发框架,这就是uni-app

2018年9月,微信率先推出云开发,这个功能我们认为是小程序发展历史上的一个重要节点,它可以让前端工程师从前到后将所有业务闭环实现,减少前后端的沟通成本、人力成本、运维成本,属于开发模式的重大升级。和之前前端同学既可通过JS/CSS编写前端UI,又可通过node.js写后端业务,这种所谓全栈开发模式相比,云开发有更好的优势,因为前端同学对于DB优化、弹性扩容、攻击防护、灾备处理等方面还是有经验欠缺的,但云开发将这些都封装好了,真正做到仅专注业务实现,其它都委托云厂商服务。

小程序架构

这是一个比较通用的小程序架构,目前几家小程序架构设计大致都是这样的(快应用的区别是视图层只有原生渲染)。

大家知道小程序是一个逻辑、视图层分离的架构。

逻辑层就是上图左上角这块,小程序中开发的所有页面JS代码,最后都会打包合并到逻辑层,逻辑层除了执行开发者的业务JS代码外,还需处理小程序框架的内置逻辑,比如App生命周期管理。

视图层就是上图右上角这块,用户可见的UI效果、可触发的交互事件在视图层完成,视图层包含web组件、原生组件两种,也就是小程序是原生+web混合渲染的模式,这块后面会详细讲。

逻辑层最后运行在JS CORE或V8环境中;JS CORE既不是DOM环境,也不是node环境,你是无法使用JS中的DOM或BOM对象的,你能调用的仅仅是ECMAScript标准规范中所给出的方法。

那如果你要发送网络请求怎么办?window.XMLHttpRequest 是无法使用的(当然即使可以调用,在iOS的WKWebView中也存在更严格的跨域限制,会有问题)。这时候,网络请求就需要通过原生的网络模块来发送,JS CORE和原生之间呢,就需要这个JS Bridge来通讯。

架构引发的性能坑点

小程序这种架构,最大的好处是新页面加载可以并行,让页面加载更快,且不卡转场动画;但同时也引发了部分性能坑点,今天主要介绍 3 点:

逻辑层/视图层通讯阻塞

我们从swipeaction这个例子讲起,需求是用户在列表项上向左滑动,右侧隐藏的菜单跟随用户手势平滑移动

若想在小程序架构上实现流畅的跟手滑动,是很困难的,为什么?

我们再回顾一下上面的小程序架构,小程序的运行环境分为逻辑层和视图层,分别由2个线程管理,小程序在视图层与逻辑层两个线程间提供了数据传输和事件系统。这样的分离设计,带来了显而易见的好处:

环境隔离,既保证了安全性,同时也是一种性能提升的手段,逻辑和视图分离,即使业务逻辑计算非常繁忙,也不会阻塞渲染和用户在视图层上的交互

但同时也带来了明显的坏处:

  • 视图层(webview)中不能运行JS,而逻辑层JS又无法直接修改页面DOM,数据更新及事件系统只能靠线程间通讯,但跨线程通信的成本极高,特别是需要频繁通信的场景

基于这样的架构设计,我们回到swipeaction,分析一次touchmove的操作,小程序内部的响应过程:

  • 用户拖动列表项,视图层触发touchmove 事件,经Native层中转通知逻辑层(逻辑层、视图层不是直接通讯的,需Native中转),即下图中的⓵、⓶两步
  • 逻辑层计算需移动的位置,然后再通过 setData 传递位置数据到视图层,中间同样会由微信客户端(Native)做中转,即下图中的⓷、⓸两步

实际上,用户滑动过程中,touchmove的回调触发是非常频繁的,每次回调都需要4个步骤的通讯过程,高频率回调导致通讯成本大幅增加,极有可能导致页面卡顿或抖动。为什么会卡顿,因为通讯太过频繁,视图层无法在16毫秒内完成UI更新。

为解决这种通讯阻塞的问题,各家小程序都在逐步提供对应的解决方案,比如微信的WXS、支付宝的SJS、百度的Filter,但每家小程序支持情况不同,详细见下表。

另外,微信的关键帧动画、百度的animation-view Lottie动画,也是为减少频繁通讯的一种变更方式。

其实,通讯阻塞是业界普遍存在的一个问题,不止小程序,react nativeweex等同样存在通讯阻塞的问题。只不过react nativeweex的视图层是原生渲染,而小程序是web渲染。我们下面以weex为例来说明。

大家知道,weex底层使用的 JS-Native Bridge,这个 Bridge 使得 JS 和 Native 之间的通信会有固定的性能损耗。

继续以上述swipeaction为例,要实现列表项菜单的跟手滑动,大致需经如下流程:

  • 在UI视图上绑定 touch 事件(或 pan 事件)
  • 当手势触发时, Native UI层将手势事件通过 Bridge 传递给 JS逻辑层 , 这产生了一次 Native UI到 JS 逻辑的通信,即下图中的⓵、⓶两步
  • JS 逻辑在接收到事件后,根据手指移动的偏移量驱动界面变化,这又会产生一次 JS 到 Native UI的通信,即下图中的⓷、⓸两步

同样,手势回调事件触发的频率是非常高的,频繁的的通信带来的时间成本很可能导致界面无法在16ms中完成绘制,卡顿也就产生了。

weex为解决通讯阻塞,提供了BindingX解决方案,这是一种称之为Expression Binding的机制,简要介绍一下:
– 接收手势事件的视图,在移动过程中的偏移量以x,y两个变量表示
– 期望改变(跟随移动)的视图,变化的属性为translateXtranslateY,对应变化的偏移量以f(x),f(y)表达式表示
– 将”交互行为”以表达式的方式描述,并提前预置到Native UI层
– 交互触发时,Native UI根据其内置的表达式解析引擎,去执行表达式,并根据表达式执行的结果驱动视图变换,这个过程无需和JS逻辑通讯

伪代码 – 摘录自weex官网

{

   anchor: foo_view.ref                    // ----> 这是"产生手势的视图"的引用  
   props:
            [
                {
                    element: foo_view.ref, // ----> 这是"期望改变的视图"的引用
                    expression: f(x) = x,  // ----> 这是具体的表达式
                    property: translateX   // ----> 这是期望改变的属性
                },
                {
                    element: foo_view.ref,
                    expression: f(y) = y,  // ----> y 属性
                    property: translateY
                }
            ]
}

React Native 同样存在类似问题,为避免频繁的通信,React Native 生态也有对应方案,比如Animated组件及Lottie动画支持。以 Animated 组件为例,为实现流畅的动画效果,该组件采用了声明式的API,在 JS 端仅定义了输入与输出以及具体的 transform 行为,而真正的动画是通过 Native Driver 在 Native 层执行,这样就避免了频繁的通信。然而,声明式的方式能够定义的行为有限,无法胜任交互场景。

uni-app在App端同样面临通讯阻塞的问题,我们目前的方案是采用类似微信wxs的机制(内部叫renderjs),但放开了wxs中无法获取页面DOM元素的限制,比如下图中多个小球同时移动的canvas动画,uni-app在App端的实现方案是:

  • renderjs 中获取canvas对象
  • 基于web的canvas绘制动画,而非原生canvas绘制

Tips:大家需要注意,并不是所有场景都是原生性能更好,小程序架构下,如上多球同时移动的动画,原生canvas并不如在wxs(renderjs)中直接调用web canvas

下表总结了跨端框架在通讯阻塞方面的解决方案。

数据/组件差量更新

小程序架构存在通讯阻塞问题,厂商为解决这个问题,创造了wxs脚本语言及关键帧动画等方式,但这些都是厂商维度的优化方案。我们作为小程序开发者,在性能优化方面,又能做哪些工作呢?

小程序开发性能优化,核心就是setData的调用,你能做只有两件事情:
– 尽量少调用setData
– 每次调用setData,传递尽可能少的数据量,即数据差量更新

减少setData调用次数

假设我们有更改多个变量值的需求,示例如下:

change:function(){
    this.setData({a:1});
    ... //其它业务逻辑
    this.setData({b:2});
    ... //其它业务逻辑
    this.setData({c:3});
    ... //其它业务逻辑
    this.setData({d:4});
}

如上4次调用setData,会引发4次逻辑层、视图层数据通讯。这种场景,开发者需意识到setData有极高的调用代价,自己需手动调整代码,合并数据,减少数据通讯次数。

部分小程序三方框架已内置数据合并的能力,比如uni-app在 Vue runtime 上进行了深度定制,开发者无需关注setData的调用代价,可放心编写如下代码:

change:function(){
    this.a = 1;
    ... //其它业务逻辑
    this.b = 2;
    ... //其它业务逻辑
    this.c = 3;
    ... //其它业务逻辑
    this.d = 4;
}

如上4次赋值,uni-app运行时会自动合并成{"a":1,"b":2,"c":3,"d":4}一条记录,调用一次setData完成所有数据传递,大幅降低setData的调用频次,结果如下图:

减少setData调用次数,还有个注意点:后台页面(用户不可见的页面)应避免调用setData

数据差量更新

假设我们有一个 “列表页 + 上拉加载” 的场景,初始化列表项为 “item1 ~ item4”,用户上拉后要向列表追加4条新记录 “item5 ~ item8″,小程序代码如下:

page({
    data:{
        list:['item1','item2','item3','item4']
    },
    change:function(){
        let newData = ['item5','item6','item7','item8'];
        this.data.list.push(...newData); //列表项新增记录
        this.setData({
            list:this.data.list
        })
    }
})

如上代码,change方法执行时,会将list中的 “item1 ~ item8” 8个列表项通过setData全部传输过去,而实际上变化的数据只有”item5 ~ item8″。

开发者在这种场景下,应通过差量计算,仅通过setData传递变化的数据,如下是一个示例代码:

page({
    data:{
        list:['item1','item2','item3','item4']
    },
    change:function(){
        // 通过长度获取下一次渲染的索引
        let index = this.data.list.length;
        let newData = ['item5','item6','item7','item8'];
        let newDataObj = {};//变化的数据
        newData.forEach((item) => {
            newDataObj['list[' + (index++) + ']'] = item;//通过list下标精确控制变更内容
        });
        this.setData(newDataObj) //设置差量数据
    }
})

每次都手动计算差量变更数据是繁琐的,新手不理解小程序原理的话,也容易忽略这些性能点,给App埋下性能坑点。

此处建议开发者选择成熟的小程序三方框架,这些框架已经自动封装差量数据计算,对开发者更友好。比如uni-app借鉴了 westore JSON Diff库,在调用setData之前,会先比对历史数据,精确高效计算出有变化的差量数据,然后再调用setData,仅传输变化的数据,这样可实现传递数据量的最小化,提升通讯性能。如下是一个示例代码:

export default{
    data(){
        return {
            list:['item1','item2','item3','item4']
        }
    },
    methods:{
        change:function(){
            let newData = ['item5','item6','item7','item8'];
            this.list.push(...newData) // 直接赋值,框架会自动计算差量数据
        }
    }
}

Tips:如上change方法执行时,仅会将list中的”item5 ~ item8″4个新增列表项传输过去,实现了setData传输量的极简化

组件差量更新

下图是一个微博列表截图:

假设当前有200条微博,用户对某条微博点赞,需实时变更其点赞数据(状态);在传统模式下,一条微博的点赞状态变更,会将整个页面(Page)的数据全部通过setData传递过去,这个消耗是非常高的;而即使通过之前介绍,通过差量计算的方式获取变更数据,这个 Diff 遍历范围也很大,计算效率极低。

如何实现更高性能的微博点赞?这其实就是组件更新的典型场景。

合适的方式应该是,将每条微博封装成一个组件,用户点赞后,仅在当前组件范围内计算差量数据(可理解为Diff范围缩小为原来的1/200),这样效率才是最高的。

提醒大家注意,并不是所有小程序三方框架都已实现自定义组件,只有在基于自定义组件模式封装的框架,性能才会大幅提升;如果三方框架是基于老的template模板封装的组件开发,则性能并不会有明显改善,其 Diff 对比范围依然是Page页面级的。

混合渲染

大家知道,小程序当中有一类特殊的内置组件——原生组件,这类组件有别于 WebView 渲染的内置组件,他们是由原生客户端渲染的。

小程序中的原生组件,从使用方式上来说,主要分为三类:

  • 通过配置项创建的:选项卡、导航栏,还有下拉刷新
  • 通过组件名称创建的,比如:camera、canvas、input、live-player、live-pusher、map、textarea、video
  • 通过API接口创建的,比如:showModal、showActionSheet等

除了上面提到的这些之外,其它基本都是web渲染。所以说,小程序是混合渲染模式,web渲染为主,原生渲染为辅。

为什么要引入混合渲染

接下来的问题,为什么要引入原生渲染?以及为什么仅针对这几个组件提供了原生增强?其他组件为什么没有做原生实现?

这就需要我们针对每个组件单独进行分析思考,这里举了几个例子:
– tabs/navigationbar:避免页面白屏,提升新窗口进入时的用户体验
– Video:全屏后的滑动控制(声音、进度、亮度等)
– map:更流畅的双指缩放、位置拖动
– input:web端的input,键盘弹出时,只有完成按钮,无法让键盘显示发送下一个这样的按键

提到input控件的原生化,可以稍微发散一下。

小程序中原生input控件的通用做法是,未获取焦点时以web控件显示,但在获取焦点时,绘制一个原生input,盖在web input上方,此时用户看见的键盘即为原生input所对应的键盘,原生弹出键盘是可自定义按钮(如上图中下一步、send按钮)的。这种做法存在一个缺陷:web和原生,毕竟不同渲染引擎,在键盘弹出和关闭时,对应input的placeholder会闪烁。

在Android平台,还有一种做法是基于webkit改造,定制弹出键盘样式;这种方案,在键盘弹出和关闭时,input控件都是web实现的,故不存在placeholder闪烁的问题。

混合渲染引发的问题

原生组件虽然带来了更丰富的特性及更好的性能,但同时也引入了一些新的问题,比如:

1.层级问题:原生永远在最高层,无法通过z-index设置不同元素的层级,无法与 view、image 等内置组件相互覆盖,不支持在picker-viewscroll-viewswiper等组件中使用

2.通讯问题:比如一个长列表中内嵌视频组件,页面滚动时,需通知原生的视频组件一起滚动,通讯阻塞,可能导致组件抖动或拖影

3.字体问题:在Android手机上,调整系统主题字体,所有原生渲染的控件的字体都会变化,而web渲染的字体则不会变化。如下图,系统rom字体为一款“你的名字”的三方字体,设置后,小程序顶部标题字体变了,底部选项卡字体也变了,但小程序中间内容区字体不变,这就是比较尴尬的一种情况,一个页面,两种字体。

当然,并不是所有小程序都存在这种问题,部分小程序通过修改自带的webview内核,实现了webview也可以使用rom主题字体,比如微信、qq、支付宝;其他小程序(百度、头条),webview仍然无法渲染为rom主题字体。

混合渲染改进方案

既然混合渲染有这些问题,对应就会有解决方案,目前已有的方案如下。

方案1:创造层级更高的组件

既然其它组件无法覆盖到原生组件上,那就创造出一种新的组件,让这个新组件可以覆盖到video或map上。cover-view/cover-image就是基于这种需求创造出来的新组件;其实它们也是原生组件,只不过层级略高,可以覆盖在 map、video、canvas、camera等原生组件上。

目前除了字节跳动外,其它几家小程序均已支持cover-view/cover-image

cover-view/cover-image 在一定程度上缓解了分层覆盖的问题,但也有部分限制,比如严格的嵌套顺序。

方案2:消除分层,同层渲染

既然分层有问题,那就消除分层,从2层变成1层,所有组件都在一个层中,z-index岂不就可生效了?

这个小目标说起来简单,具体实现还是很复杂的,下个章节具体介绍。

同层渲染

抛开小程序当前架构实现,解决混合渲染最直接的方案,应该更换渲染引擎,全部基于原生渲染,video/map和image/view均为原生控件,层级相同,层级遮盖问题自然消失。这正是uni-app在App端的推荐方案。

uni-app在App端支持weex原生渲染,至于uni-app如何抹平weex和小程序的各项差异,这是另外一个话题,后续可单独分享。

回归到当前web渲染为主、原生渲染为辅的主流小程序现状,如何实现同层渲染?

基于我们的分析研究,这里简单讲解一下同层渲染实现的方案,和微信真实实现可能会有出入(目前仅微信一家实现了同层渲染)。

iOS平台

小程序在 iOS 端使用 WKWebView 进行渲染,WKWebView 在内部采用的是分层的方式进行渲染,一般会将多个DOM节点,合并到一个层上进行渲染,因此DOM节点和层之间不存在一一对应关系。但是,一旦将一个 DOM 节点的 CSS 属性设置为 overflow: scroll 后,WKWebView 便会为其生成一个 WKChildScrollView,且WebKit 内核已经处理了WKChildScrollView与其他 DOM 节点之间的层级关系,这时DOM节点就和层之间有一一对应关系了。

小程序 iOS 端的同层渲染可基于 WKChildScrollView 实现,主要流程如下:
– 创建一个 DOM 节点并设置其 CSS 属性为 overflow: scroll
– 通知原生层查找到该 DOM 节点对应的原生 WKChildScrollView 组件
– 将原生组件挂载到该 WKChildScrollView 节点上作为其子 View

Android平台

小程序在 Android 端采用 chromium 作为 WebView 渲染层,和iOS的WKWebView不同,是统一渲染的,不会分层渲染。但chromium 支持 WebPlugin 机制,WebPlugin 是浏览器内核的一个插件机制,可用来解析<embed>。Android 端的同层渲染可基于 <embed> 加 chromium 内核扩展来实现,大致流程如下:

  • 原生层创建一个原生组件(如video)
  • WebView 创建一个 <embed> 节点并指定其类型为video
  • chromium 内核创建一个 WebPlugin 实例,并生成一个 RenderLayer
  • 原生层将原生组件的画面绘制到 RenderLayer 所绑定的 SurfaceTexture 上
  • chromium 渲染该 RenderLayer

这个流程相当于给 WebView 添加了一个外置插件,且<embed>节点是真正的 DOM 节点,可将更多的样式作用于该节点上。

未来可能

如果要探讨小程序接下来的技术升级方向,我们认为应该在用户体验、开发效率两个方向上努力。

更优秀的用户体验

先说用户体验的问题,主要也是两个方面:
– 解决现有的性能坑点,比如前面分析的这几项,通讯阻塞、分层限制等,这里不再赘述
– 支持更多App的体验,更自由灵活的配置,比如高斯模糊

如果你也想快速搭建的自己的小程序引擎,并更优的解决如上体验问题,该怎么办?

这里放一个福利。

uni-app发行到App端,实际上就是一个完整的小程序引擎,DCloud会在近期将这个引擎完整开源,欢迎大家基于uni-app小程序SDK快速打造自己的小程序平台。

uni-app小程序SDK具备如下几个特征:
– 性能更高:支持native渲染,扩展wxs,更高的通讯性能
– 开放性更强:更灵活的配置,支持更多App的体验
– 开源不受限:无需签订任何协议,拿走就用
– 生态丰富:支持微信小程序自定义组件,支持所有uni-app插件,uni-app插件市场目前已有上千款成熟插件

开发效率

开发效率应该从跨端、跨云两个维度进行分析。

跨端开发

目前的小程序都带有明显的厂家属性,每个厂家各不相同。之前更遭,阿里内部有多套小程序(支付宝、淘宝、钉钉等),幸好阿里圆老板给力,目前已基本统一。但腾讯体系下,微信和QQ小程序依然是两队人马,两套规范。

小程序之前是手机端的,今年360出了PC端小程序。

接下来,会不会还有其它厂家推出自己的小程序?会不会有新的端的出现?比如面向电视的小程序、面向车载的小程序?

一切皆有可能。

逐水草而居是人类的本能,追求流量依然是互联网的制胜法宝。当前的小程序宿主,都是亿级流量入口,且各家流量政策不同。比如微信的流量最大的,但有各种限制;百度和头条系是支持广告投放的,通过广告投放,可以快速获得大量较为精准的用户;百度小程序还有个web化的功能,可以通过将web的搜索流量,转化成小程序的流量。

面对众多小程序平台及各自巨大的入口流量,开发者如何应对?

等待w3c的小程序标准统一,短期不太现实。当下,若想将业务快速触达多家小程序,借助跨端框架应该是唯一可行的方案。

跨云开发

开发商借助uni-app或其它跨端框架,虽然已可以开发所有前端应用。但仍然需要雇佣php或java等后台开发人员,既有后端人员成本,又有前/后端沟通成本。

腾讯、阿里、百度小程序虽陆续上线了云开发,但它们均只支持自己的小程序,无法跨端,分散的服务器对开发商更不可取。

故我们认为跨厂商的 serverless 是接下来的一个重点需求,开发者在一个云端存储所有业务数据及后端逻辑,然后将前端小程序发行到各家小程序平台,也就是“一云多端”模式。

总结

基于小程序的现状,我们也许可以总结一下小程序技术上的可能方向:
– 其它小程序拉齐与微信的差距,让开发者可以做出足够高性能的应用服务
– 所有小程序应拉齐和App的体验差距,虽然功能API方面仍有不足,但操作性能和交互体验,不应该弱于app
– 跨端框架 + serverless,让开发者更轻松,让企业更高效

OK,我的分享到此结束,若有错误,欢迎交流指正。

uni-app 2.2发布,大幅优化H5端性能体验

背景

uni-app发布以来,已经服务了几十万开发者。让我们意外,或者说惊喜的是,有大量开发者用uni-app只编写H5版,并没有多端发布(可参考案例)。

这其实也符合uni-app的初衷,uni-app的定位并不是需要多端发布时才用uni-appuni-app是一个使用vue.js开发所有前端应用的统一框架。对于一个前端工程师来说,使用uni-app做多端效率更高,做单一端也没问题,并在各端有不少出彩的地方。

过去的版本迭代中,uni-app已经成为了更好的小程序开发框架,比使用原生微信开发更有优势。(见评测

uni-app2.2的新版中,我们大幅优化了H5版的性能,让使用uni-app开发的H5,性能体验和直接使用vue.js开发H5拉齐。

可能不少开发者有某种误解:多端框架要适配多端,所以性能肯定不如原生。我们想纠正一下:
1. 切忌想当然,多看数据评测。还不信就自己动手实验
2. 请问使用vue.js开发的web性能好,还是使用原生js开发web性能好?答案是:使用vue.js框架。为什么?因为它在底层会自动优化数据同步、虚拟dom,比大多数开发手动写的代码要更高效。同样的,使用uni-app也如此,框架底层的优化处理比大多数开发者手动写setdata或dom操作更高效。
3. 多端适配很多是在编译时做的,并不影响运行时的性能

优化难点

想优化H5端的性能,并不是一件容易的事。

“功能全面”和“小巧极速”,这是一对最难调和的冤家。

为了保障多端的一致性,uni-app实现了一套小程序的H5版Runtime,支持各种小程序的组件、API、配置。所以uni-app的H5版拥有比其他框架更好的跨端一致性。

但这也造成了老版的uni-app,输出H5端时,包体积过大(框架未压缩前有500k,部署gzip后162k)。

这确实是一个非常大的runtime,包含了几十个内置组件,数百个API。而且这些API仍然在快速增加中。

不能像其他框架一样因为功能少,所以体积小。我们不会用功能换性能,我们需要更好的方案。

优化方法

uni-app包含几十个内置组件、数百个API,是个“大而全”的框架;但开发者在开发具体应用时,未必能使用到所有的组件及API。若能根据项目具体情况,删掉没用到的组件及API,保留对项目有用的组件及API,便可精简框架、减少体积,这即是“摇树优化”的思路。

摇树优化(Tree-Shaking),顾名思义,摇晃树干,将枯死无用的枝条摇掉,仅保留有用的树枝。对应到框架层面理解,就是一个框架的众多组件和API,可以按需使用,把未引用的框架部分裁剪掉。Tree-Shaking 最早由 Rollup 提出,属于死码删除的一种形式。

常见的前端框架摇树,一般是基于明确的import引用关系。比如引用某UI库时,在A页面使用该UI库的search组件,此时需要写js代码import这个search组件,那么摇树分析就很容易。

uni-app和小程序一样,内置组件和API是不需要import的,这提升了开发的易用性,但此时却加大了摇树的难度,依靠简单的import分析无法实现摇树了。

幸好对DCloud团队而言,AST语法分析是看家本事,多年来HBuilder以js和vue语法提示著称。通过AST分析,uni-app新版可以精准判定这个项目使用了哪些组件和API。

不过这还不够,分析工程源码使用了什么组件和API之后,还得考虑框架各组件和API之间可能存在依赖和耦合关系,这需要进一步的计算和关系梳理,具体而言:

  • 组件:通过vue-template-compiler分析出来的AST,映射生成项目中使用到的组件清单,然后再基于Webpack插件将使用到的组件打包构建
  • API:编译器维护一个 api 依赖关系的 json 文件,该 json 文件描述每个 api 可能依赖的文件,然后 babel 查找到对应的 api 后,根据api 的依赖关系自动导入,重新编译

在工程师持续的加班奋战后,uni-app终于推出了全新的2.2版本,解决了这些难题,大幅降低了发行包体积,gzip后的框架体积,从162k降低到92k,仅相当于你在工程中引用了vue.jsvue-router、以及部分es6 polyfill库。(后续有详细比较)

除了大幅降低发行包体积,新版还调整了预载策略,可以进一步加快页面的渲染速度。

优化结果

搭建环境

我们使用vue-cli创建uni-app默认模板

vue create -p dcloudio/uni-preset-vue my-project

项目创建后,编译生成H5端的发行目录

npm run build:h5

然后配置nginx服务器,指定root目录并启用gzip压缩,示例如下:

server {
    ...
    gzip on;
    gzip_min_length 1k;
    gzip_buffers 4 16k;
    gzip_comp_level 4;
    gzip_types text/plain application/javascript application/x-javascript text/css application/xml text/javascript application/x-httpd-php image/jpeg image/gif image/png;
    ...
}

runtime 动态裁剪

然后通过 Chrome DevTools 的 Network 面板,查看优化前的首页网络请求包大小,结果如下:

然后启用H5平台的优化开关,重新查看首页的网络请求包大小,结果如下:

可以看到框架主库(chunk-vendors.js)从162k变为92.8k,体积压缩43%!

实际上,框架主库主要分为三个部分:

  • vue/vue-router基础库
  • es6 polyfill库
  • uni-app runtime(组件&API实现)

如果对这三个部分再拆开对比,我们会看到uni-app组件库优化比例更高:

vue/vue-router es6 polyfill库 uni-app runtime 累计
优化前 38k 43k 81k 162k
优化后 38k 26k 28.8k 92.8k

Tips:

  • uni-app runtime从81k瘦身为28.8k,裁剪比例达到64%
  • 新编译器对es6的使用也做了动态扫描,项目中用到的es6语法(包括uni-app runtime用到的es6语法),才会打包对应的polyfill实现,故es6 polyfill库从43k瘦身为26k

脚本执行时间

然后,我们再通过Chrome DevTools 的 Performance 面板,查看优化前后的性能数据,对比结果如下:

可以看出,最耗时的脚本执行时间,从227ms提升为154ms,时间提升达到32%。

如何使用

虽然内部实现比较复杂,但uni-app对外暴漏了简单的配置,开发者只需在配置文件中打开一个开关即可。具体在 manifest.json 中h5节点配置如下选项:

"h5" : {
    "optimization":{
        "treeShaking":{
            "enable":true //启用摇树优化
        }
    }
}

2.2版的其他优化

uni-app2.2版中,还开放了package.jsonvue-config.js的自定义,开发者可以自由的配置编译策略。

现在可以自定义支持所有小程序平台,包括钉钉小程序、高德小程序、抖音小程序…等。这样除了标准的8大平台(iOS、Android、H5、微信小程序、支付宝小程序、百度小程序、头条小程序、QQ小程序),这些生态的子生态也可以分版本条件编译。

同样,也支持对H5端进行多子端编译,比如微信里的内嵌的H5、App里内嵌的H5…都可以分开条件编译。

如此灵活的条件编译,对于一套工程的多端发布、共享复用、同步升级,有莫大的好处。即便是仅开发H5版,uni-app的多端条件编译也提供了更灵活和强大的工程化能力。

2.2版本还可以设置各种静态资源、js、小程序自定义组件的编译和拷贝策略。如果你之前的h5项目或小程序项目想转换至uni-app下,又不想挪动某些目录结构,那么在vue-config.js里配置策略即可。

使用uni-app开发H5和直接开发H5相比的优势

在与直接开发h5拉齐性能的基础之上,uni-app给开发者提供了更多优势:

  1. 开发效率
    uni-app提供了大量适合手机页面的基础组件(其实就是小程序组件)。还提供了扩展组件uni ui。插件市场更有600多款插件。

无论开发者想找一个电商的模板,还是找一个图表组件,都可以手到擒来。开发效率更胜以往。

  1. 多端编译
    我们开发H5时,经常需要给浏览器输出一份、给微信等超级App输出一份、给自家的App输出一份。甚至不同地域、不同用户画像,都会输出不同版本。以前,开发者只能对js部分进行条件编译,甚至不得不建多个仓库进行多版维护。

uni-app解决了这些烦恼,它的条件编译非常灵活强大:
– 不管是组件、js还是css,都可以按平台编译输出
– 还可以多个平台进行“与和或”的运算编译
– 除了文件中的代码,整个文件、甚至整个目录,都可以条件编译

例如微信、QQ等在支持x5内核的内置浏览器中,使用x5的视频同层渲染;或者在微信服务号中调用微信卡劵,这段代码只有build到 dist/h5-weixin 这个目录下的版本才会被编译进去,其他平台不会有这段代码

// #ifdef H5-WEIXIN
wx.openCard({
    cardList: [{
        cardId: '',
        code: ''
    }]// 需要打开的卡券列表
});
// #endif

后续计划

接下来,uni-app在H5端将提供服务端渲染机制(SSR)和PC宽屏界面适配优化,在追求性能极致和大一统的道路上继续前进!

相关代码全部托管在 github,欢迎大家 star 或提交 pr!

小程序开发:用原生还是选框架(wepy/mpvue/taro/uni-app)– 第1季

引言:这应该是一个系列,uni-app团队计划根据各个主流框架的最新升级情况,每季度更新一次评测,向开发者提供最新、最深的小程序开发选型报告。

2017-1-9微信小程序诞生以来,历经2年多的迭代升级,已有数百万小程序上线,成为继Web、iOS、Android之后,第四大主流开发技术。

与之相随,小程序的开发生态也在蓬勃发展,从最初的微信原生开发,到wepympvuetarouni-app等框架依次出现,从刀耕火种演进为现代化开发,生态越来越丰富。

选择多了,问题也就来了,开发小程序,该用原生还是选择三方框架?

首先,微信原生开发的槽点大多集中如下:
1. 原生开发对Node、预编译器、webpack支持不好,影响开发效率和工程构建流程
2. 微信定义了一个不伦不类的语法,不如正经学vue、react,学会了全端通用,而不是只为微信小程序
3. vue/react生态里有太多周边工具,可以提高开发效率,比如ide、校验器、三方库。。。
4. 微信那个ide和专业编辑器相比实在不好用

同时,开发者对三方框架,又总是有各种顾虑:
1. 怕性能不如原生
2. 怕有些功能框架实现不了,只能用原生
3. 怕框架不稳定,跳到坑里
4. 以及诸多三方框架,到底该用哪个

面对如此纠结的场景,不少热心开发者发布评测文章分享经验,但感觉众说纷纭,过期信息太多。缺少一份非常专业的、深度的,或者按如今流行的话来讲,“硬核的”评测报告。

做评测报告这件事,不同于泛泛经验分享,其实非常花费时间。它需要:
– 你必须成为每一个框架的专业使用人员,而不是浅浅的了解一下这些框架
– 真实的动手写多个平台的测试例,比较各个平台的功能、性能,了解他们的社区情况、技术服务情况
– 你要有长期跟踪和更新报告的能力,避免半年后沦为过期信息

换言之:评测要想真,功夫得做深!

uni-app团队花费2个周时间完成本报告,并坚持每个季度更新一次本评测报告。目前更新时间为2019年5月。

本文从面向用户、面向开发者两大维度七大细项,对微信原生及主流的wepympvuetarouni-app开发框架进行横向对比,希望给开发者在小程序框架选型时提供一种参考思路。本文基于各框架官网可采集到的公开数据及真实测试数据,希望客观公正地评价各个框架的现状和优劣。但宥于利益相关,本文的观点很可能是带有偏向性的,大家可以带着批判的眼光来看待,如发现本文中有任何评测失真,欢迎在这里报 issuse

面向用户、面向开发者维度,具体包括:

  1. 用户:提供完整的业务实现,并保证高性能体验
  2. 开发者:平缓的学习曲线、现代开发体验(工程化)、高效的社区支持、活跃的开发迭代、多端复用

2. 用户

1.1 功能实现

软件开发,首要目标是向用户提供完整、闭环的业务功能。

在web开发中,如果vue、react等框架的使用,造成开发者无法操作浏览器提供的所有api,那这样的框架肯定是不成熟的。小程序开发也一样,任何开发框架,都不能限制底层的api调用。

而各种业务功能底层依赖微信暴漏的组件和接口(微信官网介绍的组件和 API 规范,也即微信原生API),三方框架是基于微信原生进行的二次封装,开发者此时常会有个疑问:小程序在不断的迭代升级,如果某项业务依赖于最新的小程序API,但三方框架尚未封装,该怎么办?

实际上就像web开发的vue、react一样,浏览器出了一个新API,并不会涉及vue、react的升级。本评测里的所有框架,都不会限制开发者调用底层能力。这里详细解释下原因:

  • wepy:未对小程序API作二次封装,API依然使用微信原生的,框架与微信小程序是否新增API无关
  • mpvue:支持微信的所有原生组件和api,无限制。同时框架封装了自己的跨端API,使用方式类似mpvue.request()
  • taro:支持微信的所有原生组件和api,无限制。同时框架封装了自己的跨端API,使用方式类似Taro.request(),支持Taro 代码与小程序代码混写,可通过混写的方式调用框架尚未封装的小程序新增API
  • uni-app:支持微信的所有原生组件和api,无限制。在跨端方面,即便仍然使用微信原生的组件和API,也可以直接跨端编译到App、H5、以及支付宝百度头条等小程序。但为了管理清晰,推荐使用uni封装的API,类似uni.request()。同时支持条件编译,可在条件编译代码块中,随意调用各个平台新增的API及组件

注:以上顺序,按各个框架的诞生顺序排序,下同。

故,三方框架均可调用所有小程序API,完成用户的业务需求,这个维度各框架是无差别的。

然而有差别的,是性能体验。

1.2 性能体验

三方框架,内部大多做了层层封装,这些封装是否会增加运行负载,导致性能下降?尤其是与原生微信小程序开发相比性能怎么样,这是大家普遍关心的问题。

为客观的进行对比,我们特意搭建了一个测试模型,详细如下:

  • 开发内容:开发一个仿微博小程序首页的复杂长列表,支持下拉刷新、上拉翻页、点赞。

  • 界面如下:

  • 开发版本:一共开发了5个版本,包括微信原生版、wepy版、mpvue版、taro版、uni-app版,按照官网指引通过cli方式默认安装。

  • 测试代码开源(Github仓库地址:https://github.com/dcloudio/test-framework),
    Tips:若有同学觉得测试代码写法欠妥,欢迎提交 PR 或 Issus

  • 测试机型:红米 Redmi 6 Pro、MIUI 10.2.2.0 稳定版(最新版)、微信版本 7.0.3(最新版)

  • 测试环境:每个框架开始测试前,杀掉各App进程、清空内存,保证测试机环境基本一致;每次从本地读取静态数据,屏蔽网络差异。

我们以上述仿微博小程序为例,测试2个容易出性能问题的点:长列表加载、大量点赞组件的响应。

1.2.1 长列表加载

仿微博的列表是一个包含很多组件的列表,这种复杂列表对性能的压力更大,很适合做性能测试。

从触发上拉加载到数据更新、页面渲染完成,需要准确计时。人眼视觉计时肯定不行,我们采用程序埋点的方式,制定了如下计时时机:

  • 计时开始时机:交互事件触发,框架赋值之前,如:上拉加载(onReachBottom)函数开头
  • 计时结束时机:页面渲染完毕(微信setData回调函数开头)

Tips:setData回调函数开头可认为是页面渲染完成的时间,是因为微信setData定义如下(微信规范):

测试方式:从页面空列表开始,通过程序自动触发上拉加载,每次新增20条列表,记录单次耗时;固定间隔连续触发 N 次上拉加载,使得页面达到 20*N 条列表,计算这 N 次触发上拉到渲染完成的平均耗时。

测试结果如下:

说明:以400条微博列表为例,从页面空列表开始,每隔1秒触发一次上拉加载(新增20条微博),记录单次耗时,触发20次后停止(页面达到400条微博),计算这20次的平均耗时,结果微信原生在这20次 触发上拉 -> 渲染完成 的平均耗时为876毫秒,最快的uni-app是741毫秒,最慢的mpvue是4493毫秒

大家初看这个数据,可能比较疑惑,别急,下方有详细说明

说明1:为何 mpvue/wepy 测试数据不完整?

mpvuewepy 诞生之初,微信小程序尚不支持自定义组件,无法进行组件化开发;mpvuewepy 为解决这个问题,将用户编写的Vue组件,编译为WXML中的模板(template),变相实现了组件化开发能力,提高代码复用性,这在当时的技术条件下是很棒的技术方案。

但如此方案,在页面复杂、组件较多的时,会大量增加页面 dom 节点数量,甚至超出微信的 dom 节点数限制。我们在 红米手机(Redmi 6 Pro)上实测,页面组件超过500个时,mpvuewepy 实现的仿微博App就会报出如下异常,并停止渲染,故这两个测试框架在组件较多时,测试数据不完整。这也就意味着,当页面组件太多时,无法使用这2个框架。

dom limit exceeded please check if there’s any mistake you’ve made

Tips1:wepy官网的CHANGELOG,提到 v1.7.2 测试版本添加了对小程序原生组件的支持,实测坑很多,因为是测试版,官方在 issue 中也表示不推荐使用;按照官网文档,默认安装的 v1.7.3 正式版本并不支持原生组件

Tips2:wepy在400条列表以内,为何性能高于微信原生框架,这个跟自定义组件管理开销及业务场景有关(wepy编译为模板,不涉及组件创建及管理开销),后续对微博点赞,涉及组件数据传递时,微信原生框架的性能优势就提现出来了,详见下方测试数据。

说明2:为什么测试数据显示uni-app 会比微信原生框架的性能略好呢?

其实,在页面上有200条记录(200个组件)时,taro 性能数据也比微信原生框架更好。

微信原生框架耗时主要在setData调用上,开发者若不单独优化,则每次都会传递大量数据;而 uni-apptaro 都在调用setData之前自动做diff计算,每次仅传递变动的数据。

例如当前页面有20条数据,触发上拉加载时,会新加载20条数据,此时原生框架通过如下代码测试时,setData会传输40条数据

data: {
    listData: []
},
onReachBottom() { //上拉加载
    let listData = this.data.listData;
    listData.push(...Api.getNews());//新增数据
    this.setData({
        listData
    }) //全量数据,发送数据到视图层
}

开发者使用微信原生框架,完全可以自己优化,精简传递数据,比如修改如下:

data: {
    listData: []
},
onReachBottom() { //上拉加载
    // 通过长度获取下一次渲染的索引
    let index = this.data.listData.length;
    let newData = {}; //新变更数据
    Api.getNews().forEach((item) => {
        newData['listData[' + (index++) + ']'] = item //赋值,索引递增
    }) 
    this.setData(newData) //增量数据,发送数据到视图层
}

经过如上优化修改后,再次测试,微信原生框架性能数据如下:

从测试结果可看出,经过开发者手动优化,微信原生框架可达到更好的性能,但 uni-apptaro 相比微信原生,性能差距并不大。

这个结果,和web开发类似,web开发也有原生js开发、vue、react框架等情况。如果不做特殊优化,原生js写的网页,性能经常还不如vue、react框架的性能。

也恰恰是因为Vuereact框架的优秀,性能好,开发体验好,所以原生js开发已经逐渐减少使用了。

复杂长列表加载下一页评测结论:微信原生开发手工优化,uni-app>微信原生开发未手工优化,taro > wepy > mpvue

Tips:有人以为uni-app和mpvue是一样的,早期uni-app确实使用过mpvue,但后来因为性能和vue语法支持度问题已经重新开发了。

1.2.2 点赞组件响应速度

长列表中的某个组件,比如点赞组件,点击时是否能及时的修改未赞和已赞状态?是这项测试的评测点。

测试方式:
– 选中某微博,点击“点赞”按钮,实现点赞状态状态切换(已赞高亮、未赞灰色),
– 点赞按钮 onclick函数开头开始计时,setData回调函数开头结束计时;

在红米手机(Redmi 6 Pro)上进行多次测试,求其平均值,结果如下:

说明:也就是在列表数量为400时,微信原生开发的应用,点赞按钮从点击到状态变化需要111毫秒。

测试结果数据说明:
– wepy/mpvue 测试数据不完整的原因同上,在组件较多时,页面已经不再渲染了
– 基于微信自定义组件实现组件开发的框架(uni-app/taro),组件数据通讯性能接近于微信原生框架,远高于基于template实现组件开发的框架(wepy/mpvue)性能

组件数据更新性能测评:微信原生开发,uni-app,taro > wepy > mpvue

综上,本性能测试做了2个测试,长列表加载和组件状态更新,综合2个实验,结论如下:

微信原生开发手工优化,uni-app>微信原生开发未手工优化,taro > wepy > mpvue

2.开发者

在满足用户业务需求的前提下,我们谈谈开发者的需求,从如下几个维度比较:

  • 平缓的学习曲线:简单易学,最好能复用现有技术栈,丰富的学习资料
  • 高效的开发体验:现代前端开发流程、工程化支持
  • 高效的社区支持:遇到问题,可很快的寻求到帮助
  • 活跃的开发迭代:框架处于积极更新升级状态,无需担心停更

2.1 平缓的学习曲线

2.1.1 DSL语法支持

选择开发团队熟悉的、能快速上手的DSL,是团队框架选型的基本点。

首先微信原生的开发语法,既像React ,又像Vue,有点不伦不类,对于开发者来说,等于又要学习一套新的语法,大幅提升了学习成本,这一直被大家所诟病。

其它开发框架基本都遵循React、Vue(类Vue)语法,其主要目的:复用工程师的现有技术栈,降低学习成本。此时,框架对于原框架(React/Vue)语法的支持度就是一个重要的衡量标准,如果支持度较低、和原框架语法差异较大,则开发者无异于要学习一门新的框架,成本太高。

实际开发中发现,各个开发框架,都没有完全实现VueReact在web上的所有语法:

wepy开发风格接近于 Vue.js,属于类Vue实现,相对微信原生开发算前进了一大步,但相比完整Vue语法还有较大差距,开发时需要单独学习它的规则;

mpvueuni-app 框架基于 Vue.js 核心,通过修改 Vue.jsruntimecompiler,实现了在小程序端的运行。mpvue支持的Vue语法略少,uni-app 则基本支持绝大多数vue语法,如filter、复杂 JavaScript 表达式等;

taro 对于 JSX 的语法支持度,也达到了绝大多数都支持的完善程度。

DSL语法支持评测:taro,uni-app > mpvue > wepy > 微信原生

2.1.2 学习资料完善度

官方文档、问题搜索、示例demo的完备度方面:

  • 微信原生:文档丰富,API搜索准确,官方有示例demo,支持官网上调起微信开发者工具,预览运行效果 详见
  • wepy:文档只有2页,没有搜索,组件API等文档都直接看微信的文档。没有提供示例demo,很多配置需要靠猜。详见
  • mpvue:文档较少,但其概念不复杂,组件API等文档都直接看微信的文档,学习难度低。问题搜索效果一般。没有提供示例demo。详见
  • taro:基础文档完整,具体使用问题资源较少,问题搜索效果一般,示例demo只包含基础功能,仅发布了微信一端。详见
  • uni-app:基础文档和各种使用专题内容丰富,问题搜索效果较好,示例demo功能完备,并发布为7端上线。详见

教学课程方面:

学习资料完善度评测:微信原生 > uni-app > mpvue , taro > wepy

2.2 现代前端开发体验

开发体验层面,处于明显劣势的是微信原生开发,主要差距在于:

  • 框架开发提供了精简的代码组织(微信原生开发,一个Page由4个文件构成,写个代码要开的标签卡太多)
  • 框架开发提供了更强大的组件化能力
  • 框架开发提供了应用状态管理(类Vuex/Redux/Mobx等)
  • 框架开发能灵活支持各种 Sass 等 预处理器
  • 框架开发可提供完整的 ES Next 语法支持
  • 框架开发方便自定义构建策略

其它小程序开发框架均支持cli模式,可以在主流前端工具中开发,且基本都带有d.ts的语法提示库。

由于mpvueuni-apptaro直接支持vuereact语法,配套的ide工具链较丰富,着色、校验、格式化完善;wepy要弱一些,有部分三方维护的vscode插件。

好的开发工具,绝对可以大幅提升开发体验,这个维度上,明显高出一截的框架是uni-app,其出品公司同时也是HBuilder的出品公司,DCloud.io。HBuilder是四大主流前端开发工具(可对比百度指数),其为uni-app做了很多优化,故uni-app的开发效率、易用性非其他框架可及。

开发体验维度,对比结果:uni-app > taro,mpvue > wepy > 微信原生

这里可以输出一个结论:如果你需要工程化能力,那就直接忘了微信原生开发吧。

2.3 高效的社区支持

学习、开发难免遇到问题,官方技术支持和社区活跃度很重要。

本次评测demo开发期间,我们的同学(同时掌握vue和react),在学习研究各个多端框架时,切实感受到由于语法、学习资料、社区的差异带来的学习门槛,吐出了很多槽。

综合评估,本项评测结论:微信原生 , uni-app > taro > mpvue > wepy

2.4 活跃的开发迭代

开发者必须关心一个问题:该项目是否有人长期维护?

这个问题可以通过github commits 频次、产品更新日志(changelog)、百度搜索指数等指标来衡量和对比。

github commits 频次

我们采集2019年4月份(时间为4.1 ~ 4.30),每个项目在github上的master分支有commit的天数,结果如下:

Tips:
– 微信原生是闭源的,看不到 commits 数量,但保持每月至少一次的更新节奏,详见
wepy的master分支无commit,最新的2.0.x分支在4月份也仅1天有commit记录

从 commit 的记录来看,tarouni-app处于更新比较活跃的状态,wepympvue则相对疲软,呈现无人维护之态。

产品更新日志

通过浏览产品更新日志,可确认产品是否在积极迭代、增加新功能、修复用户bug。

我们分别查看各框架官方链接的更新日志(CHANGELOG),下方是链接地址:

通过产品更新日志对比,微信原生、tarouni-app 三者更新频繁,bug修复、新功能补充都处于比较紧凑的状态;而mpvuewepy则已有长时间没有版本发布,wepy甚至有将近1年时间未发布正式版本,开发者选型需谨慎。

2.5 多端复用

随着微信小程序的火爆,支付宝、百度、字节跳动等公司也先后进入小程序领域,这些公司个个日活过亿,坐拥海量用户,企业主希望将自己的业务触达每个用户,不管这个用户在哪个小程序中。

需求转接到程序员这里,程序员怎么办?难道真的每个平台到处搬砖吗?此时,一套代码、多端发布就成为很多程序员的梦想,小程序跨端框架应运而生。

现实真能如此理想吗?每个跨端框架能否真的像官网宣传的那样,实现开发一次,发布到所有小程序平台?甚至和H5平台复用代码?

我们用事实说话,依然使用上述仿微博App,依次发布到各平台,验证每个框架在各端的兼容性,结果如下:

测试结果说明:
– ⭕ 表示支持且功能正常,❌ 表示不支持,其它则表示支持但存在部分bug或兼容问题

通过这个简单的例子可以看出,跨端支持度测评结论: uni-app,taro > mpvue> 原生微信小程序wepy

但是仅有上面的测试还不全面,实际业务要比这个测试例复杂很多。但我们没法开发很多复杂业务做评测,所以还需要再对照各家文档补充一些信息。
由于每个框架的文档中都描述了各种组件和API的跨端支持程度。我们过了几家的文档,发现各家基本是以微信小程序为基线,然后把各种组件和API在其他端实现了一遍:
taro:H5端实现了大部分微信的API
uni-app:组件、API、配置,大部分在各个端均已实现,个别API有说明在某些端不支持。可以看出uni-app是完整在H5端实现了一套微信模拟器

跨端框架,一方面要考虑框架提供的通用api跨端支持,同时还要考虑不同端的特色差异如何兼容。毕竟每个端都会有自己的特色,不可能完全一致。
taro:提供了js环境变量判断和统一接口的多端文件,可以在组件、js、文件方面扩展多端,不支持其他环节的分平台处理。
uni-app:提供了条件编译模型,所有代码包括组件、js、css、配置json、文件、目录,均支持条件编译,可不受限的编写各端差异代码。

跨端框架,还涉及一个ui框架的跨端问题,评测结果如下:
taro:官方提供了taro ui,只支持微信小程序和H5两端,不支持App,详见
uni-app:官方提供了uni ui,可全端运行;uni-app还有一个插件市场,里面有很多三方ui组件,详见

最后补充跨端案例:
– mpvue:微信端案例丰富,未见其它端案例
– taro:微信端案例丰富,百度、支付宝、H5端亦有少量案例
– uni-app:多端案例丰富,官方示例已发布到7端(包括App端)

综合以上信息,本项的最终评测结论:uni-app > taro > mpvue > 原生微信小程序wepy

这里可以输出一个结论,如果有多端发布需求,微信原生开发、wepy这两种方式可以直接排除了。

结语

真实客观的永远是实验和数据,而不是结论。不同需求的开发者,可以根据上述实验数据,自行得出自己的选型结论。

但作为一篇完整的评测,我们也必须提供一份总结,虽然它可能加入了我们的主观感受:

如果你只开发微信小程序,不做多端,那么使用uni-apptaro是更优的选择,他们相当于web世界的vue和react,有了这些工具,不再需要使用原生wxml开发。
– 如果坚持微信原生开发,需要注意手动写优化代码来控制setdata,并且注意其工程化能力非常弱
– 如果你是react系,那就用taro
– 如果是vue系,那就用uni-appuni-app在性能、周边生态和开发效率上更有优势

如果你开发多端,uni-apptaro都可以,可根据自己熟悉的技术栈选择,相对而言uni-app的多端成熟度更高一些。

如有读者认为本文中任何评测失真,欢迎在这里报 issuse

微信原生、wepy、mpvue、uni-app、taro,小程序主流开发框架深度对比

上周,Taro 团队发布了一篇《小程序多端框架全面测评》,让开发者对业界主流的跨端框架,有了初步认识。感谢 Taro 团队的付出。

不过横评这件事,要想做完善,其实非常花费时间。不是只看文档就行,它需要:
– 真实的动手写多个平台的测试demo,比较各个平台的功能、性能,它们的实际情况到底是不是如文档宣传的那样?
– 真实的学习每个框架,了解它们的学习曲线,在实际开发中遇到问题时,感受它们的文档、教程、社区生态和技服能力到底怎么样?

我们 uni-app 团队投入一周完成了这个深度评测,下面我们就分享下,实际开发不同框架的测试例遇到的问题,和最终的测试结果。

评测实验介绍

  • 开发内容:开发一个仿微博小程序首页的复杂长列表,支持下拉刷新、上拉翻页、点赞。

  • 界面如下:

  • 开发版本:一共开发了6个版本,包括微信原生版、wepy版、mpvue版、taro版、uni-app版、chameleon版(以这些产品发布时间排序,下同),按照官网指引通过cli方式默认安装(应该是最新稳定版)。

  • 测试代码开源(Github仓库地址:https://github.com/dcloudio/test-framework),
    Tips:若有同学觉得测试代码写法欠妥,欢迎提交 PR 或 Issus

  • 测试机型:红米 Redmi 6 Pro、MIUI 10.2.2.0 稳定版(最新版)、微信版本 7.0.3(最新版)

  • 测试环境:每个框架开始测试前,杀掉各App进程、清空内存,保证测试机环境基本一致;每次从本地读取静态数据,屏蔽网络差异。

  • 测试维度:

    1. 跨端支持度如何?
    2. 性能如何?
    3. 学习门槛
    4. 工具与周边生态

1. 跨端支持度如何

开发一次,到处运行,是每个程序员的梦想。但现实往往变成开发一次,到处调错。

各个待评测框架,是否真得如宣传的那样,一次开发、多端发布?

我们将上述仿微博App依次发布到各平台,验证每个框架在各端的兼容性,结果如下:

平台 微信原生 wepy mpvue taro uni-app chameleon
微信小程序 ⭕️ ⭕️ ⭕️ ⭕️ ⭕️ ⭕️
支付宝小程序 ⭕️ ⭕️ ⭕️
百度小程序 ⭕️ ⭕️ ⭕️
头条小程序 ⭕️ ⭕️ ⭕️
H5端 上拉加载/下拉刷新失效 ⭕️ 上拉加载/下拉刷新失效
App端 上拉加载失效 ⭕️ 列表无法滚动,无法测试上拉加载/下拉刷新

测试结果说明:
– ⭕ 表示支持且功能正常,❌ 表示不支持,其它则表示支持但存在部分bug或兼容问题
wepy 2.0 宣称版已支持其他家小程序,本测试基于wepy官网指引安装的wepy-cli默认版本为1.7.3,尚不支持多端
chameleon尝鲜版宣称支付宝、百度小程序,本测试基于chameleon官网指引安装的chameleon-tool默认版本为0.1.1,尚不支持其它小程序

通过这个简单的例子可以看出,跨端支持度测评结论:uni-app > taro > chameleon > mpvue >wepy原生微信小程序

但是仅有上面的测试还不全面,实际业务要比这个测试例复杂很多。但我们没法开发很多复杂业务做评测,所以还需要再对照各家文档补充一些信息。
由于每个框架的文档中都描述了各种组件和API的跨端支持程度。我们过了几家的文档,发现各家基本是以微信小程序为基线,然后把各种组件和API在其他端实现了一遍:
taro:H5端实现了大部分微信的API,App端和微信的差异比较大。
uni-app:组件、API、配置,大部分在各个端均已实现,个别API有说明在某些端不支持。可以看出uni-app是完整在H5端实现了一套微信模拟器,在App端实现了一套微信小程序引擎,才达到比较完善的平台兼容性。
chameleon:非常常用的一些组件和API在各端已经实现,这部分的平台差异较少。但大量组件和API需要开发者自己分平台写代码。

跨端框架,一方面要考虑框架提供的通用api跨端支持,同时还要考虑不同端的特色差异如何兼容。毕竟每个端都会有自己的特色,不可能完全一致。
taro:提供了js环境变量判断和统一接口的多端文件,可以在组件、js、文件方面扩展多端,不支持其他环节的分平台处理。
uni-app:提供了条件编译模型,所有代码包括组件、js、css、配置json、文件、目录,均支持条件编译,可不受限的编写各端差异代码。
chameleon:提供了多态方案,可以在组件、js、文件方面扩展多端,不支持其他方式的分平台处理。

跨端框架,还涉及一个ui框架的跨端问题,评测结果如下:
taro:官方提供了taro ui,支持小程序(微信/支付宝/百度)、H5平台,不支持App,详见
uni-app:官方提供了uni ui,可全端运行;uni-app还有一个插件市场,里面有很多三方ui组件,详见
chameleon:官方提供了cml-ui扩展组件库,可全端运行,但组件数量略少,详见

最后补充跨端案例:
– mpvue:微信端案例丰富,未见其它端案例
– taro:微信端案例丰富,百度、支付宝、H5端亦有少量案例
– uni-app:微信、App、H5三端案例丰富,官方示例已发布到6端
– chameleon:未看到任何端案例

综合以上信息,本项的最终评测结论:uni-app > taro > chameleon > mpvue > wepy原生微信小程序

之前曾有友商掀起一番真跨端和伪跨端之争,通过本次Demo实测,这个争论可以盖棺定论了。

2. 跨端框架性能如何

跨端框架基本都是compiler + runtime模式,引入的runtime是否会降低运行性能?

尤其是与原生微信小程序开发相比性能怎么样,这是大家普遍关心的问题。

我们依然以上述仿微博小程序为例,测试2个容易出性能问题的点:长列表加载、大量点赞组件的响应。

2.1 长列表加载

仿微博的列表是一个包含很多组件的列表,这种复杂列表对性能的压力更大,很适合做性能测试。

从触发上拉加载到数据更新、页面渲染完成,需要准确计时。人眼视觉计时肯定不行,我们采用程序埋点的方式,制定了如下计时时机:

  • 计时开始时机:交互事件触发,框架赋值之前,如:上拉加载(onReachBottom)函数开头
  • 计时结束时机:页面渲染完毕(微信setData回调函数开头)

Tips:setData回调函数开头可认为是页面渲染完成的时间,是因为微信setData定义如下(微信规范):

字段 类型 必填 描述
data Object 这次要改变的数据
callback Function setData引起的界面更新渲染完毕后的回调函数

测试方式:从页面空列表开始,通过程序自动触发上拉加载,每次新增20条列表,记录单次耗时;固定间隔连续触发 N 次上拉加载,使得页面达到 20*N 条列表,计算这 N 次触发上拉 -> 渲染完成的平均耗时。

测试结果如下:

列表条数 微信原生 wepy mpvue taro uni-app chameleon
200 770 625 969 752 641 1261
400 876 781 4493 974 741 1970
600 1111 1250 910 2917
800 1406 1547 1113 4040
1000 1690 1878 1321 5196

说明:以400条微博列表为例,从页面空列表开始,每隔1秒触发一次上拉加载(新增20条微博),记录单次耗时,触发20次后停止(页面达到400条微博),计算这20次的平均耗时,结果微信原生在这20次 触发上拉 -> 渲染完成 的平均耗时为876毫秒,最快的uni-app是741毫秒,最慢的mpvue是4493毫秒

大家初看这个数据,可能比较疑惑,别急,下方有详细说明

说明1:为何 mpvue/wepy 测试数据不完整?

mpvuewepy 诞生之初,微信小程序尚不支持自定义组件,无法进行组件化开发;mpvuewepy 为解决这个问题,将用户编写的Vue组件,编译为WXML中的模板(template),变相实现了组件化开发能力,提高代码复用性,这在当时的技术条件下是很棒的技术方案。

但如此方案,在复杂组件较多的页面,会大量增加 dom 节点,甚至超出微信的 dom 节点数限制。我们在 红米手机(Redmi 6 Pro)上实测,页面组件超过500个时,mpvuewepy 实现的仿微博App就会报出如下异常,并停止渲染,故这两个测试框架在组件较多时,测试数据不完整。这也就意味着,当页面组件太多时,无法使用这2个框架。

dom limit exceeded please check if there’s any mistake you’ve made

Tips:wepy在400条列表以内,为何性能高于微信原生框架,这个跟自定义组件管理开销及业务场景有关(wepy编译为模板,不涉及组件创建及管理开销),后续对微博点赞,涉及组件数据传递时,微信原生框架的性能优势就提现出来了,详见下方测试数据。

说明2:uni-app 比微信原生框架性能更好?逆天了?

其实,在页面上有200条记录(200个组件)时,taro 性能数据也比微信原生框架更好。

微信原生框架耗时主要在setData调用上,开发者若不单独优化,则每次都会传递大量数据;而 uni-apptaro 都在调用setData之前自动做diff计算,每次仅传递有变化的数据。

例如当前页面有20条数据,触发上拉加载时,会新加载20条数据,此时原生框架通过如下代码测试时,setData会传输40条数据

data: {
    listData: []
},
onReachBottom() { //上拉加载
    let listData = this.data.listData;
    listData.push(...Api.getNews());//新增数据
    this.setData({
        listData
    }) //全量数据,发送数据到视图层
}

开发者使用微信原生框架,完全可以自己优化,精简传递数据,比如修改如下:

data: {
    listData: []
},
onReachBottom() { //上拉加载
    // 通过长度获取下一次渲染的索引
    let index = this.data.listData.length;
    let newData = {}; //新变更数据
    Api.getNews().forEach((item) => {
        newData['listData[' + (index++) + ']'] = item //赋值,索引递增
    }) 
    this.setData(newData) //增量数据,发送数据到视图层
}

经过如上优化修改后,再次测试,微信原生框架性能数据如下:

组件数量 微信原生框架(优化前) 微信原生框架(优化后) uni-app taro
200 770 572 641 752
400 876 688 741 974
600 1111 855 910 1250
800 1406 1055 1113 1547
1000 1690 1260 1321 1878

从测试结果可看出,经过开发者手动优化,微信原生框架可达到更好的性能,但 uni-apptaro 相比微信原生,性能差距并不大。

这个结果,和web开发类似,web开发也有原生js开发、vue、react框架等情况。如果不做特殊优化,原生js写的网页,性能经常还不如vue、react框架的性能。

也恰恰是因为Vuereact框架的优秀,性能好,开发体验好,所以原生js开发已经逐渐减少使用了。

复杂长列表加载下一页评测结论:微信原生开发手工优化,uni-app>微信原生开发未手工优化,taro > chameleon > wepy > mpvue

2.2 点赞组件响应速度

长列表中的某个组件,比如点赞组件,点击时是否能及时的修改未赞和已赞状态?是这项测试的评测点。

测试方式:
– 选中某微博,点击“点赞”按钮,实现点赞状态状态切换(已赞高亮、未赞灰色),
– 点赞按钮 onclick函数开头开始计时,setData回调函数开头结束计时;

在红米手机(Redmi 6 Pro)上进行多次测试,求其平均值,结果如下:

列表数量 微信原生 wepy mpvue taro uni-app chameleon
200 91 279 666 92 93 101
400 111 501 1507 125 107 145
600 144 152 148 178
800 176 214 181 236
1000 220 229 234 272

说明:也就是在列表数量为400时,微信原生开发的应用,点赞按钮从点击到状态变化需要111毫秒。

测试结果数据说明:
– wepy/mpvue 测试数据不完整的原因同上,在组件较多时,页面已经不再渲染了
– 基于微信自定义组件实现组件开发的框架(uni-app/taro/chameleon),组件数据通讯性能接近于微信原生框架,远高于基于template实现组件开发的框架(wepy/mpvue)性能

组件数据更新性能测评:微信原生开发,uni-app,taro > chameleon > wepy > mpvue

综上,本性能测试做了2个测试,长列表加载和组件状态更新,综合2个实验,结论如下:

微信原生开发手工优化,uni-app>微信原生开发未手工优化,taro > chameleon >> wepy > mpvue

3. 学习门槛

DSL语法支持度

主流跨端框架基本都遵循React、Vue(类Vue)语法,其主要目的:复用工程师的现有技术栈,降低学习成本。此时,跨端框架对于原框架(React/Vue)语法的支持度就是一个重要的衡量标准,如果支持度较低、和原框架语法差异较大,则开发者无异于要学习一门新的框架,成本太高。

实际开发中发现,各个多端框架,都没有完全实现vue、react在web上的所有语法:
taro 对于 JSX 的语法支持是相对完善的,其文档中描述未来版本计划,

更多的 JSX 语法支持,1.3 之后限制生产力的语法只有只能用 map 创造循环组件一条

mpvueuni-app 框架基于 Vue.js 核心,通过修改 Vue.jsruntimecompiler,实现了在小程序端的运行,支持绝大部分的Vue语法;uni-app 编译到微信端曾经使用过mpvue,但后来重写框架,支持了更多vue语法如filter、复杂 JavaScript 表达式等;

wepychameleon 都是 类Vue 的实现,仅支持 Vue 的部分语法,开发时需要单独学习它们的规则;

DSL语法支持评测:taro,uni-app > mpvue > wepy,chameleon

学习资料完善度

  • 官方文档、搜索系统的完备度方面:uni-app文档内容丰富,示例demo完备,taro次之,其他几个框架相对要弱一些。mpvue文档虽少,但其概念不复杂,也没有支持H5、App,组件、API文档都可直接看微信的文档,学习难度倒也很低。
  • 教程方面:uni-app官方有视频教程,不少三方专业培训机构也录制的uni-app教程,包括腾讯课堂自家NEXT学院也录制了uni-app培训视频课,公开售卖;mpvue在腾讯课堂也有三方视频教程售卖;taro没有视频教程,但官方发布了掘金小册;wepychameleon还没有专业教程。

学习资料完善度评测:uni-app > mpvue , taro > chameleon > wepy

技术支持和社区活跃度

开发难免遇到问题,官方技术支持和社区活跃度很重要。

目前看,uni-apptarochameleon都有专职人员做技术支持,uni-app因交流群过多,还单独引入了智能客服机器人。

活跃的社区意味着你遇到问题有人可问、或者前人会沉淀经验到文章里供你搜索。uni-app官方有30多个交流群(其中有很多千人大群),自建论坛中有大量交流帖子;taro和mpvue有9个500人微信群;wepy官网的微信已无法添加,chameleon发布较晚,用户群还较少。除uni-app外,其他框架没有自建论坛社区。

本次评测demo开发期间,我们的同学(同时掌握vue和react),在学习研究各个多端框架时,切实感受到由于语法、学习资料、社区的差异带来的学习门槛,吐出了很多槽。

综合评估,本项评测结论:uni-app > taro > mpvue > wepy > chameleon

Tips:本测评忽略React、Vue两框架自身的学习门槛

4. 工具和周边生态

工具

所有多端框架均支持cli模式,可以在主流前端工具中开发。
各框架基本都带有d.ts的语法提示库。
由于mpvueuni-apptaro直接支持vuereact语法,配套的ide工具链较丰富,着色、校验、格式化完善,chameleon针对部分编辑器推荐了插件,wepy有一些三方维护的vscode插件。

工具属性维度,明显高出一截的框架是uni-app,其出品公司同时也是HBuilder的出品公司,DCloud.io
HBuilder/HBuilderX系列是国产开发工具,有300万开发者用户。
HBuilderX为uni-app做了很多优化,故uni-app的开发效率、易用性非其他框架可及。
当然对于不习惯HBuilderX的开发者而言,uni-app的这个优势无法体现。

周边生态

一个底层框架,其周边配套非常重要,比如ui库、js库、项目模板。
– wepy:出现时间久,开源项目多,占据一定优势。
– mpvue:发布时间也较早,历史积累较多。
– taro:官方提供了taro ui,github上有一些开源项目。
– uni-app:提供了插件市场,ui库、周边模板丰富
– chameleon:还没有形成周边生态。

值得注意的是,uni-appmpvue的插件生态是互通的,都是vue插件。所以双方还联合举办了插件大赛。这个联合生态的周边丰富度,是目前各个框架中最丰富的。

顺便打个广告,欢迎有实力的同学参加 uni-app/mpvue插件开发大赛,领取iPhone Xs Max等丰厚奖品。

综上比较,工具和周边生态评测结论:uni-app,mpvue > wepy > taro > chameleon

其他常见评测指标

github star:

wepy mpvue taro uni-app chameleon
17136 16650 17078 4728 4287

github star 数对比:wepy > taro > mpvue > uni-app > chameleon

Tips:
– star 数采集时间:2019.03.31 21:30
– star 数量和产品发布时间有关,也和用户使用习惯有关;除uni-app外,其他框架的交流互动主要是github的issus,uni-app的开发者一般在uni-app问答社区中交流反馈,github页面访问量较低。

百度指数

百度指数代表了开发者的搜索量和包含关键字的网页数量。如下是各跨端框架近7天(2019-03-24 ~ 2019-03-30)的百度指数:

Tips:
wepy未被百度指数收录,说明其搜索量和包含该关键字的网页数量都不够多。
tarochameleon 的名称取自于已存在的名称,实际指代开发框架的指数应该更低。

案例

仅看发布到微信小程序的案例,数量和质量综合对比,wepy > mpvue > taro , uni-app > chameleon

如果看多端案例,综合对比,uni-app > taro > mpvue > wepy > chameleon

除了uni-app外,其他跨端框架的出品方本身为一线开发商,其内部项目会使用这些框架,经受过实战考验。但同时鲜有其他大开发商使用这类框架。

这里面有面子问题,也有兼容问题。很多开发商做的框架,可以满足其自身业务需求,但对外开放后想满足所有开发者,仍然需要投入大量工作完善产品,很多开发商主营业务不在此,并没有这么做。

这也是很多开源项目被称为KPI项目的原因。

客观讲,凹凸实验室投入如此大精力打磨taro,让uni-app团队也很惊讶和佩服。
chameleon团队初期投入也很大,但发布时间还短,如果能长期投入下去,也是令人敬佩的。
uni-app团队本身就是专业做开发者服务的,案例很多,但创业者居多。

可以说整个多端框架市场仍处于起步期,距离让更多开发者接受,还需要所有框架作者的共同努力。

其他补充说明

1. 开源和App侧的补充说明

有的友商在评测中提到uni-app的开源性不足问题。
需要说明下,uni-app和其他多端框架一样,都是前端框架,是纯开源的。

除了uni-app,其他框架的App端,或者使用expo(一个基于react native的封装库)、或者使用weex

做过这些开发的人都知道,原生排版引擎和web排版引擎有很多差异。而且不管react native还是weex,都只是渲染器,能力部分还需要开发者写原生代码,这就无法跨端了。exporeact native强的是多封装了一些能力,但也带来新的限制。

uni-app的App端,是一个真的小程序引擎,又补充了可选的weex引擎。这也是uni-app在App端能够提供比其他跨端框架更好兼容性的原因。

而这个引擎,是另一个开源项目,叫h5p,这个引擎是部分开源状态。

整个业内目前还不存在一个完全开源的小程序引擎。

不过uni-app的App端使用许可是完全免费,可以放心使用。

其实也不用好奇为什么DCloud会有小程序引擎,因为业内第一个做小程序的并不是微信,而是DCloud。

关于App端,其实可以再写出一篇很长的专业评测。后续uni-app团队会再做一篇App端与react nativeweexcordovaflutter等框架的对比。

2. 转换和混写

taro提供了原生小程序转换为taro工程的转换器,也支持在原生小程序里部分页面嵌入taro编写的页面,这是taro的特色,其他跨端框架没有提供。这对于降低入门门槛有不少帮助。

结语

真实客观的永远是实验和数据,而不是结论。不同需求的开发者,可以根据上述实验数据,自行得出自己的选型结论。

但作为一篇完整的评测,我们也必须提供一份总结,虽然它可能加入了我们的主观感受:

如果你想多端开发,提升效率,不想踩太多坑,uni-app相对更完善。

如果你只开发微信小程序,不做多端,那么使用uni-app、微信原生开发、taro是更优的选择。
– 如果使用微信原生开发,需要注意手动写优化代码来控制setdata
– 如果你是react系,那就用taro
– 如果是vue系,那就用uni-appuni-app在性能、周边生态和开发效率上更有优势

如果你主要为了微信端和H5端,那么uni-apptaro都可以。可以根据自己熟悉的技术栈选择。

如果你主要需要跨App端,uni-app兼容性更好,其他框架的App端差异过大。如果你只关心App,不关心小程序和H5,那欢迎关注我们后续的评测:uni-appcordovareact nativeflutter的深度比较。

如果你主要为了各家小程序,且不用复杂组件,那除了uni-apptarompvue也是不错的选择。mpvue发布2.0版本后,搜索指数明显爬升,希望能持续更新,迎来二次繁荣。

chameleon发布不久,提供的组件和API还很少,但其未来的规划比较令人期待,值得关注。

这篇评测写完后,小编有点惴惴不安。

一方面本评测不太温和,容易得罪人。但我们相信,这样的评测,会激起所有跨端框架从业者的斗志,让大家投入更多去完善产品,这对整个产业、对前端开发者,是大好事。

另一方面,读者可能会以为现阶段的uni-app很完美,其实我们深知uni-app还有很多需要完善的地方。uni-app团队也将持续投入心血,为中国的前端开发者造福!

如有读者认为本文中任何评测失真,欢迎在这里报issues

全新重构,uni-app实现微信端性能翻倍

多次论证、数月研发,我们重写部分Vue底层、重构uni-app框架,实现了微信端性能翻倍及更多Vue语法支持。

背景

uni-app在初期借鉴了mpvue,实现了微信小程序端的快速兼容,感谢美团点评团队对于开源社区的贡献!

随着使用uni-app的开发者愈来愈多,业务复杂度不断增加,不少开发者抱怨uni-app支持的vue语法少,某些场景性能有问题(特别是页面存在复杂组件的情况),这些问题其实是由mpvue的实现机制导致的,我们以复杂组件的性能问题为例简要说明。

mpvue/wepy 诞生之初,微信小程序尚不支持自定义组件,无法进行组件化开发;mpvue/wepy 为解决这个问题,创造性的将用户编写的Vue组件,编译为WXML中的模板(template),这样变相实现了组件化开发能力,提高代码复用性,这在当时的技术条件下是很棒的技术方案。但如此方案,也导致Vue组件中的数据会被编译为Page中的数据,对组件进行数据更新也会基于路径映射调用Page.setData。特别是组件较多、数据量交大的页面中,每个组件的局部更新会引发页面级别的全局更新,产生极大的性能开销。

微信后来推出的自定义组件,其实支持组件级别的局部更新,经验证,我们发现组件级别的数据更新,相比页面全局更新,有大幅性能提升。

另外,mpvue在Vue层进行的vnode对比及数据diff计算不彻底,也会消耗部分性能。

基于这些原因,我们开始了微信端的框架重写工作。

新版特性

性能翻倍

新版 uni-app 调整重写了部分Vue.js底层实现,主要包括:

  • 基于小程序自定义组件实现 Vue.js 的组件化开发
  • Vue层取消vnode对比
  • 更彻底的diff计算,setData()通讯数据量更少

新框架重写后,我们构造了如下测试模型:

  • 构造一个列表界面,每个列表项为一个自定义组件
  • 上拉加载触发数据更新,每次从本地读取静态数据,屏蔽网络差异
  • 触发数据更新计时开始,页面渲染完毕计时结束,求其时间差作为对比指标(耗时,单位为毫秒)

然后分别使用新、老框架,在同一台手机(vivo nex)上进行多次测试,求其平均值,获取如下结果:

组件数量 老框架(mpvue) 新框架
200 204ms 129ms
400 280ms 139ms
800 341ms 180ms
1000 653ms 196ms

从测试数据来看,新框架在复杂页面下,性能有翻倍提升!特别是数据越多、组件越复杂的页面,性能提升越大!

更多 Vue 语法支持

我们同时增强了uni-app编译器,支持了更多 Vue 语法,详细如下:

  • 支持过滤器 filter
  • 支持比较复杂的 JavaScript 渲染表达式
  • 支持在 template 内使用 methods 中的函数
  • 支持 v-html (同 rich-text 的解析)
  • 组件支持原生事件绑定,如:@tap.native

体验方式

目前新框架在微信端已完成开发,其他小程序和App的编译器仍为旧版。我们放出群测版,邀请开发者在微信端抢鲜体验,开发者可选择vue-cliHBuilderX两种方式体验。

vue-cli 命令行

按照如下方式创建vue-cli并创建uni-app项目,编译发行到微信小程序:

# npm script
# 全局安装vue-cli
$ npm install -g @vue/cli
# 创建uni-app项目,会提示选择项目模板,初次接触建议选择 hello uni-app 模板
$ vue create -p dcloudio/uni-preset-vue my-project
# 进入项目目录
$ cd my-project
# dev 模式,编译预览
$ npm run dev:mp-weixin
# build 模式,发行打包
$ npm run build:mp-weixin

HBuilderX工具

开发者可从uni-app官网左侧加入QQ群,从QQ群文件中获取HBuilderX最新的群测版。

新老版本切换

为了不影响老项目,uni-app群测版目前同时内置新、老两个框架,且默认使用老框架,开发者可通过配置 manifest.json -> mp-weixin -> usingComponents节点启用新编译框架,如下:

// manifest.json
{
    // ...
    /* 小程序特有相关 */
    "mp-weixin": {
        "usingComponents":true //启用新框架编译,默认为false
    }
}

如果你使用了新增的vue语法,请注意只有h5和微信支持这些新语法,编译到其他平台时,要用条件编译处理。

Tips:
– 为保证自定义组件兼容性,运行到微信开发者工具时,建议将微信基础库设置为最新版本。
– 体验新框架时,有任何问题或者建议,欢迎到github提交 issue

现状与未来

春节过后,uni-app1.6版本发布,新增字节跳动小程序平台支持;至此,实现一套代码、7端发布!7端分别包括:App(iOS/Android)、小程序(微信/支付宝/百度/字节跳动)、H5平台,见下图:

大量开发者热情涌入 uni-app 社区,目前已有几十个uni-app交流群,下图为一个500人的QQ交流群,创建2天即满群,开发者的热情可见一斑。

目前,每天新创建的uni-app项目(包括测试项目)达数千个,案例早已过万,部分案例见https://uniapp.dcloud.io/case。与Taro等框架清一色微信小程序案例相比,uni-app跨端案例要丰富很多。

在小程序跨端框架中,uni-app也许是使用人数最多、跨端案例最丰富的前端框架。

近期,为活跃Vue多端开发生态,由uni-appmpvue团队联合举办的插件开发大赛正式开始了!欢迎各位开发者踊跃参与,制造轮子、造福社区的同时,顺手再拿个奖品(iphone Xs Max、4K显示器等奖品多多),一举多得^_^,点击了解详情

接下来,uni-app团队将继续全力奔跑,在如下方面快速完善:

  • uni-app新框架兼容到其它平台
  • uni-ui 跨端UI库精致化
  • App端引入更多原生渲染,提升系能体验
  • 周边生态进一步完善,比如行业模板、跨端统计等

“为开发者而生”,不是口号,而是定位。

uni-app团队将一如既往的为开发者解决开发痛点、提升开发效率!

uni-app 1.4 发布,一套代码,发行小程序(微信/支付宝/百度)、H5、App多个平台

uni-app 1.4 发布

在2019新年到来之际,uni-app 1.4版本正式发布,新增支持百度、支付宝小程序,开放插件市场,同时注入更多优秀特性,为开发者送上了一份新年大礼!

支持更多小程序平台

uni-app 1.4 版本新增支持百度、支付宝小程序,从此一次开发,可发布小程序(微信/支付宝/百度)、H5、App(iOS/Android)6大平台!

uni-appHBuilderX开发工具中有非常友好高效的支持,提供可视化操作菜单,发行各家小程序简单便利详情,这里不再赘述;本文主要说明如何通过vue-cli编译发行各家小程序。

使用cli编译到各家小程序之前,需先安装vue-cli并创建uni-app项目,主要命令如下:

# npm script
# 全局安装vue-cli
$ npm install -g @vue/cli
# 创建uni-app项目,会提示选择项目模板
$ vue create -p dcloudio/uni-preset-vue my-project
# 进入项目目录
$ cd my-project

Tips:如果之前已使用过老版本的uni-app cli插件,则通过npmuni-app升级到最新版,即可获得将原有uni-app项目转换到各家小程序的能力

支持支付宝小程序

使用如下命令进行支付宝小程序的编译预览及发行打包

# npm script
# dev 模式,编译预览
$ npm run dev:mp-alipay
# build 模式,发行打包
$ npm run build:mp-alipay

发行到支付宝小程序,需要你下载并打开支付宝小程序开发者工具,然后选择项目编译目录(dev模式、build 模式编译目录不同,见下方说明)进行预览或发行。

dev模式 和 build 模式的区别:

  • dev 模式编译目录为项目根目录下的 /dist/dev/ 目录
  • build 模式编译目录为项目根目录下的 /dist/build/ 目录
  • dev 模式有 SourceMap 可以方便的进行断点调试
  • build 模式会将代码将会进行压缩,体积更小更适合发布为正式版应用

目前hello uni-app 已上线支付宝小程序,可以打开支付宝,扫描以下二维码进行体验:

支持百度智能小程序

百度智能小程序的编译方式与支付宝小程序一致,简单替换平台标识(mp-baidu)即可。

你可以使用如下命令进行百度智能小程序编译预览及打包:

# npm script
# dev 模式,编译预览
$ npm run dev:mp-baidu
# build 模式,发行打包
$ npm run build:mp-baidu

发行到百度智能小程序,需要你下载并打开百度开发者工具,然后选择项目编译目录进行预览或发行。

Tips:dev 模式、build模式差异同支付宝小程序

支持通过 cli 命令行编译到微信小程序平台

uni-app 很早就支持发行到微信小程序,但需在 HBuilderX 开发工具中操作;uni-app 1.4版本支持通过vue-cli 编译到微信小程序,方式同支付宝小程序。

你可以使用如下命令进行微信小程序编译预览及打包:

# npm script
# dev 模式,编译预览
$ npm run dev:mp-weixin
# build 模式,发行打包
$ npm run build:mp-weixin

同样,发行到微信小程序,需要你下载并打开微信开发者工具,然后选择项目编译目录进行预览或发行。

其它功能特性

uni-app 插件市场上线了!支持前端组件、js sdk、页面模板、项目模板、原生插件等多种类型,还支持原生插件的云打包,详情

插件市场作为轮子的需求者和制造者之间的对接平台,将提升所有 uni-app 开发者的效率和重用程度。

另外,uni-app 1.4版本在条件编译、H5平台等方面也有大量改建,详见如下:

  • 新增 条件编译 static 支持平台目录,不同平台可定义自己的独有静态文件 详情
  • 新增 条件编译 支持多平台“或”运算符:||。例如: // #ifdef MP-WEIXIN || MP-BAIDU 代表在微信小程序和百度小程序均生效
  • 新增 条件编译 pages.json 支持条件编译。pages.json里不引用的页面不会打包,可以更自由的管理不同平台文件的打包策略。
  • 修复 条件编译 使用 ifndef 导致编译错误的问题
  • 新增 manifest.json 中(mp-weixin 节点下) 新增 permission 配置,用于微信小程序接口权限相关设置
  • 新增 蓝牙相关API 详情
  • 新增 低功耗蓝牙相关API 详情
  • 新增 iBeacon相关API 详情
  • 优化 css 编译报错提示
  • 修复 v-for item 部分写法编译失败的问题
  • H5平台 新增 canvas 组件和相关 API
  • H5平台 优化 导航栏自定义按钮支持 float 属性
  • H5平台 修复 uni.showModal 内容过多显示超出屏幕的问题
  • H5平台 修复 picker 组件未设置 value 属性值时报错的问题
  • H5平台 修复 TabBar 页面 onHide 钩子函数不触发的问题
  • H5平台 修复 map 组件中 marker 图像不显示的问题
  • H5平台 修复 AudioContext 事件监听报错的问题
  • H5平台 修复 swiper 组件动态设置 current 后 swiper 不切换的问题
  • H5平台 修复 swiper 组件设置属性 previous-margin、next-margin 显示异常的问题
  • H5平台 修复 picker 组件显示的选中项不正确的问题 #103
  • H5平台 修复 picker 组件动态设置高度后显示异常的问题
  • H5平台 修复 radio 组件设置 color 属性不生效的问题 #119
  • H5平台 修复 picker 组件 columnchange 事件不触发的问题

未来规划

uni-app 将尽快适配字节跳动小程序,并进一步抹平H5、各家小程序之间的平台差异,让开发者尽可能的一套代码,顺滑的发行到多个平台。

uni-app 在小程序端,引用和改造了mpvueMegalo,感谢美团点评团队、网易考拉团队对开源社区的贡献!

uni-app会在开源的路上继续前行,为帮助uni-app更好的成长,更好的服务开发者,欢迎您给uni-app反馈改进意见,或 Star 鼓励。

使用uni-app快速将Vue项目输出到小程序、H5

  1. 跨端彻底,直接发行,无需二次开发;
  2. 通过Tree-Shaking摇出最小化内置组件等优化策略,提升性能

这应该是uni-app在H5平台的相对其他小程序框架更友好的地方

背景

随着微信小程序的火爆及百度、头条小程序的持续推进,跨端开发的需求愈发迫切,业界随之出现了一系列的跨端框架,但对于H5平台跨端支持的都不太彻底:

  • Vue技术栈的小程序框架:对于H5平台支持普遍较弱
  • 部分React技术栈的小程序框架:虽支持生成可在H5端运行的代码,但仅仅是代码可运行,离项目直接发行上线的目标还存在一定差距。

鉴于客观需求及现状,DCloud前端团队响应开发者彻底跨端的呼声,经过连续奋战,uni-app 1.2版本支持发行到H5平台,完整模拟小程序生命周期、事件处理、组件规范等,真正实现“一套代码、多端发行”的目标。

本文主要分享,我们在实现uni-app发行到H5平台时,在引擎实现、差异抹平、性能优化方面都做了哪些工作。

完整模拟小程序引擎

uni-app设计的开发标准是:Vue.js的语法 + 小程序的API + 条件编译扩展平台个性化能力。其中:

  • Vue.js 的语法在微信小程序端,uni-app是在mpvue的基础上增强实现的,在H5端则默认支持;
  • 而小程序的API,其实包括三个部分:框架 + 组件(UI)+ 接口(API),这三部分在微信小程序端是内置支持的,而uni-app若要发布到H5平台,则需完整模拟实现小程序运行时环境。

如下是一个简易的小程序运行时框架,核心是一个响应的数据绑定系统。

为实现小程序、H5两端的完整跨端,uni-app在H5平台完整模拟实现了小程序的逻辑层和视图层,相比业界其它跨端框架,uni-app在H5平台有如下几点实现更完善。

页面配置

小程序中的导航条、选项卡是通过配置文件生成的,配置后由原生组件进行渲染,uni-app在H5平台同样兼容这些配置,不过会降级通过div控件模拟实现,因此开发者无需单独为H5平台添加导航条或选项卡。

生命周期

uni-app在H5平台实现了完整的小程序生命周期,为此填了很多坑。举一个详情页互跳的栗子:

详情A 打开 详情B,在通常的 web 端 SPA 方案中,会在详情A页面获取B详情的数据,仅会触发详情页A的updated生命周期,不会触发onHide;但在小程序中,则会打开一个新的webview并加载详情B,此时会触发详情A的onHide生命周期,也会触发详情B的onShow生命周期;uni-app完整模拟了小程序的生命周期,详情页之间互相切换时,会触发onHideonShow等生命周期;这样的实现,即保证了两端兼容性,同时在详情B返回详情A时,详情A已被缓存,无需再次联网加载,也会有更高的性能。

方法 作用
onLoad 监听页面加载
onShow 监听页面显示
onReady 监听页面初次渲染完成
onHide 监听页面隐藏
onUnload 监听页面卸载

事件处理

uni-app对于页面事件处理函数支持更为全面,下拉刷新、上拉触底等常用函数均可在H5平台正常复用,无需二次开发。

方法 作用
onPullDownRefresh 页面相关事件处理函数–监听用户下拉动作
onReachBottom 页面上拉触底事件的处理函数
onPageScroll 页面滚动触发事件的处理函数
onTabItemTap 当前是 tab 页时,点击 tab 时触发

组件规范

uni-appH5平台的组件实现,有两个特点:

  • 兼容的组件数量更多:比如navigator等组件在H5平台可正常跳转
  • 组件属性、嵌套实现更接近小程序实现

抹平引擎差异

fixed元素遮挡

微信小程序是一种 native + web 混合渲染的机制,比如小程序的导航条(navigationBar)、选项卡(tabBar)为原生组件,但H5平台为纯 web 渲染,导航条、选项卡均为 web 实现,这可能引发页面 fixed 元素 和导航条/选项卡位置发生互相遮挡的问题,如下一段 fixed 定位的代码:

.fixed{
    position: fixed;
    z-index: 9999;
    bottom: 0px;//底部距离为0
    background-color:peru;
}

在不同平台上运行效果不同,如下图所示:

uni-app通过引入css变量解决这类问题,在编译到不同平台时,给css变量设置对应的值。

CSS变量 描述 小程序 H5
–window-top 内容区域距离顶部的距离 0 若有导航条则为导航条 的高度,否则为0
–window-bottom 内容区域距离底部的距离 0 若有TabBar则为TabBar 的高度,否则为0

有了css变量,开发者若需处理 fixed 定位的元素,只需像如下方式编写即可:

.fixed{
    bottom:var(--window-bottom)
}

css作用域

uni-app在开发时遵循 Vue 单文件组件 (SFC) 规范,编译到微信小程序时会生成对应的 wxml 文件,最终运行时由 webview 渲染,iOS 平台由 WKWebView 渲染,Android 平台由 XWeb 引擎基于 Mobile Chrome 53 内核渲染;uni-app中的不同.vue页面文件( 编译后的.wxml 文件),在小程序端会由不同的 webview 渲染,故 .vue页面文件中的 css 作用域是天然隔离的,开发者无需在<style> 标签上增加scoped 属性。但H5平台是一套SPA框架,无scoped就会变成全局样式,影响其他页面。uni-app在H5平台做了智能处理,自动增加了scoped

平台性能优化

性能一直是 web app 首要关注的焦点,uni-app发行到H5平台时也做了很多性能优化。

内置组件按需打包(Tree-Shaking)

uni-app有8大类、几十个内置组件,但开发者实际开发时仅会使用其中的一部分组件,比如很多App不会用到mapcanvas等组件,若打包时将uni-app整个组件类库都打包进去,则会造成极大的资源浪费,延迟首页渲染速度。

uni-app发行到H5平台时采用了摇树优化(Tree-Shaking)策略,将开发者项目中没用到的组件从整个框架中“摇”掉,保证编译后的 JS 文件最小化。具体来说,uni-app编译到H5平台时分为预编译、再编译两个阶段,预编译阶段通过vue-template-compiler分析出来的AST,映射生成项目中使用到的组件清单,然后再基于Webpack插件将使用到的组件编译生成一个最小化的uni-app框架文件。

我们以uni-app的两个开源项目模板登录模板看图模板为例,测试 Tree-Shaking 前后组件框架的大小,效果喜人,数据如下:

项目 优化前 Shaking优化后
登录模板 148k 64k
看图模板 148k 53k

路由组件按需加载(Lazy-Loading)

当打包构建 SPA 应用时,Javascript 包会变得非常大,影响页面加载。虽然开发者基于Vue异步组件Webpackcode-splitting 功能,可以实现路由组件的懒加载,但开发者需调整.vue源码及Webpack配置,有一定的学习门槛,且比较繁琐。

uni-app在H5平台实现了自动按需加载路由组件,开发者无需调整组件开发方式,仅需关心业务实现即可。

其它方面

uni-app为提升性能体验,在很多细节上都有特殊设计。比如常见的 SPA 框架一般采用div区域滚动,uni-app为改善用户体验,使用的是body滚动,由此填了很多坑,比如不同页面的background-color,若使用div滚动,则在编译阶段就可完成样式定义,但基于body滚动,就需要在页面前进、后退时动态设置body的背景色。

github

uni-app在H5平台的相关代码均已全部开源,详见uni-app,欢迎大家 star 支持.