uni-app-01

介绍

uni-app 是一个使用 Vue.js 开发所有前端应用的框架，开发者编写一套代码，可发布到iOS、Android、Web（响应式）、以及各种小程序（微信/支付宝/百度/头条/QQ/钉钉/淘宝）、快应用等多个平台。

uni-app开发小程序与微信原生开发的区别

渲染

uni-app是逻辑和渲染分离的。渲染层，在app端提供了两套排版引擎：小程序方式的webview渲染，和weex方式的原生渲染。
两种渲染引擎可以自己根据需要选。vue文件走的webview渲染，nvue走的原生渲染。
一般情况下用vue就可以了。如果是app且有部分场景vue页面的性能不满足你的需求时，这个页面可以改用nvue页面。如果app里同时存在同名的vue和nvue页面，在app端会优先执行nvue页面，而其他端仍然优先vue页面。
vue是浏览器模式渲染，多端通用，相对更稳定，坑更少。nvue是weex模式渲染，针对app做了优化，坑比较多，某些场景性能好一点点

语法

支持vue语法和小程序语法

生命周期

1.应用的生命周期（同小程序）

<script>
    // 只能在App.vue里监听应用的生命周期
    export default {
        onLaunch: function() {
            console.log('App Launch')
        },
        onShow: function() {
            console.log('App Show')
        },
        onHide: function() {
            console.log('App Hide')
        }
    }
</script>

应用生命周期仅可在App.vue中监听，在其它页面监听无效。

2.页面的生命周期 (小程序页面当中的生命周期)

• 页面生命周期仅在page页面有效，而单独封装的组件中【页面周期无效】，但是Vue 的生命周期依然有效 【Vue的生命周期在任何地方都是有效的】
• 推荐使用uni-app里面的onReady 代替 vue 里面的 mounted
• 推荐使用uni-app里面的onLoad 代替 vue 里面的 created

3.组件的生命周期函数（vue的生命周期在任何地方有效）

• mounted、updated 和 destroyed。生命周期钩子的 this 上下文指向调用它的 Vue 实例。
• 不要在选项属性或回调上使用箭头函数，比如 created: () => console.log(this.a) 或 vm.$watch(‘a’, newValue => this.myMethod())。因为箭头函数并没有 this，this 会作为变量一直向上级词法作用域查找，直至找到为止，经常导致 Uncaught TypeError: Cannot read property of undefined 或 Uncaught TypeError: this.myMethod is not a function 之类的错误。

组件

uni-app有内置组件和扩展组件。组件分2大类：1、vue组件（文件后缀为vue）；2、小程序自定义组件（文件后缀为wxml或其他小程序平台特有后缀名称）

• vue组件又分为2个细项：only for web、全端兼容
• 小程序组件又分为：微信/QQ小程序组件、阿里小程序组件、百度小程序组件、字节跳动小程序组件。这些组件uni-app都支持，但受组件本身技术特点限制，在不同端有不一样的支持度。下面这张表格，可以清楚的表达不同类型的组件的兼容性。

从表格中可以很明显看出，更推荐使用的是全端兼容的uni规范组件。

很多人容易搞错2个问题：

• 同样是vue组件，only for web的和全端的有什么区别？
  传统的vue组件，比如elementUI，都是only for web的，里面有大量dom和window对象操作。但小程序和App是没有dom这些api的，自然无法跨端使用。
  想要跨端，其实也不难，做一套无dom的vue组件即可。官方的uni-ui即是如此。还有众多开发者在插件市场提交了更多这种类型的库。
• vant是分web版和weapp版的，千万别搞混
  vant的web版操作了dom，所以只能用于web端；而vant weapp是微信小程序组件规范，可以用于微信、App、H5；vant自身并没有提供全端可用的无dom vue组件。

除了兼容性，在性能和生态完善度层面，不同类型组件有什么差别？

1.性能

• vue组件性能好于小程序自定义组件。这是因为uni-app在底层对vue数据更新使用了自动差量更新的机制。而小程序自定义组件，默认的setDate写法是没有差量数据更新的，需要写代码手动实现差量更新才能达到相同性能。

2.生态完整度

• 首先除了微信小程序，其他几个平台的小程序几乎是没有三方组件和模板生态的。开发其他端小程序，得靠uni-app的生态
• 再说微信小程序生态，之前在微信小程序平台上一些有名的库（比如wxParse、wx-Echart），实际上在性能、功能、技术支持上，大多做的不如uni-app生态下的新库好。而vant、iview的weapp版，其性能也均不如uni ui。

3.其他指标

• vue doc：HBuilderX支持vue doc，组件作者在vue组件源码里编写vue doc，可以让组件使用者写代码时得到良好的代码提示。
• easycom：uni-app支持easycom，可以大幅简化组件的使用
• nvue支持：如果开发App，可能会涉及到nvue原生渲染页面，这种渲染方式支持的css有限，此时就要甄别组件是否兼容nvue。

官方出的uni-ui模板，可在创建项目时直接选择使用

优点

1.优化逻辑层和视图层的通信折损：非H5端的各个平台，包括App和各种小程序，其逻辑层和视图层是分离的，两层之间通信交互会有折损，导致诸如跟手滑动不流畅。uni ui在底层会利用wxs等技术，把适当的js代码运行在视图层，减少通信折损，保证诸如swiperAction左滑菜单等跟手操作流畅顺滑

2.自动差量diff数据：在uni-app下，开发App和小程序，不需要手动setData，底层自动会差量更新数据。但如果使用了小程序组件，则需要按小程序的setData方式来更新数据，很难做到自动diff更新数据。

3.背景停止：很多ui组件是会一直动的，比如轮播图、跑马灯。即便这个窗体被新窗体挡住，它在背景层仍然在消耗着硬件资源。在Android的webview版本为chrome66以上，背景操作ui会引发很严重的性能问题，造成前台界面明显卡顿。而uni ui的组件，会自动判断自己的显示状态，在组件不再可见时，不会再做动画消耗硬件资源。

4.纯vue语法：uni ui的引用、开发都是纯vue方式。而小程序组件的引用注册、开发都是小程序语法，两种语法混合在一个工程，写的也不舒服，维护也麻烦。

5.与uni统计自动整合：比如使用uni ui的导航栏组件，就不需要写统计的自定义事件来触发页面标题上报。uni统计会自动识别导航栏组件的标题。类似的，收藏组件、购物车组件，都可以免打点直接使用。

6.uni ui兼容Android 4.4等低端机webview，没有浏览器兼容问题。

7.uni ui支持nvue：App端，uni-app同时支持webview渲染和原生渲染，而uni ui是可以一套代码同时支持webview渲染和原生渲染的。为了兼容原生渲染，uni ui也做到了纯flex布局。

8.uni ui内置vue doc，使用组件时有良好的代码提示

9.支持easycom规范，使用非常简单

10.支持datacom规范，云端一体全部封装掉

11.支持uni_module规范，方便插件的更新

组件的使用上：内置 > uni-ui > 插件市场

API

uni的api和微信小程序的api，小程序的api在uni-app中只需要把wx替换成uni即可使用。

网络请求

uni.request / wx.request

路由跳转

uni.navigateTo / wx.navigateTo 等

获取位置

uni.getLocation / wx.getLocation

在api的使用上兼容了微信的原生api，可自由选择，优先使用uni的api，如碰到不能实现需求的可在考虑微信原生api，没有太大差异。小程序api文档的变更需要以官方微信的为准。

语法上的差别

1.触摸事件名称：
①微信小程序：bindtap
②uni-app：@click

2.函数传参方式：
①微信小程序：<view bindtap="click" data-id="id"></view>
②uni-app：<view @click="click(id)"></view>

3.函数接收参数：
①微信小程序：

function(e){ 
     this.setData({ currentId:e.currentTarget.dataset.id }) 
}

②uni-app：

function(id){
    this.currentId = id
 }

4.for循环：
①微信小程序：

<view wx:for="{{currentList}}" wx:for-index="s_index" wx:for-item="s_item"></view>

②uni-app：

<view v-for="(s_item,s_index) in currentList"></view>

微信小程序可以不写wx:for-index和wx:for-item，默认为index和item

5.if判断：
①微信小程序：<view wx:if="{{isShow}}"></view>
②uni-app：<view v-if="isShow"></view>

6.src动态接收图片：
①微信小程序：<image src="{{item.img}}"></image>
②uni-app：<image :src="item.img"></image>

7.页面传参：
①微信小程序：<navigator url="/pages/live?id={{item.room_id}}"></navigator>
②uni-app：<navigator :url="'/pages/live?id=' + item.room_id"></navigator>
两者接收参数都是在onLoad(options){}方法中获取，在此不多提及。

8.全局数据定义：
①微信小程序：globalData:{baseUrl:"www.com"}
②uni-app：this.prototype.baseUrl = "https://www.ccc"

9.全局数据调用：
①微信小程序：getApp().globalData.baseUrl
②uni-app：this.baseUrl

10.阻止冒泡：
①微信小程序：<view catchtap="clickTab">我是按钮</view>
②uni-app：<view @click.stop="clickTab">我是按钮</view>

11.api的差别(支付作栗子)：
①微信小程序：wx.requestPayment({})
②uni-app：uni.requestPayment({})

总结

uni-app优点

1.支持原生小程序的API，支持原生写法，在功能上与原生小程序没有太大区别
2.vue的语法，熟悉vue的可以直接上手开发
3.在数据更新上，uni-app基于Vue的diff算法更新，减少了setData的传输数据量和调用次数
4.丰富的插件市场

uni-app缺点

1.文档不齐全，遇到问题反馈回复不及时
2.app开发效果不及原生，各端差异性较大，开发编译过程中需要注意。

如果有多端小程序的需求，可以考虑uni-app，如果仅做微信端小程序，优先考虑微信原生。app开发请考虑原生。