按照官网流程发布，放到服务器根目录，这个时候访问就是空白页面。我一直以为是我这边发布的时候配置有问题，到处找解决办法，打了N次包都不行。最后是因为服务器的地址指向没有指向我打包的h5文件，直接指向了服务器的根目录。这个时候改一下地址指向访问页面就出来了（例：www.xxx.com:8000/服务器根目录/h5）

自Android-SDK@2.3.4.70239_20191014版开始，离线SDK更新google play版个推SDK，解决了提交google play违反相关政策的问题。

新版SDK添加aps-igexin-gp-release.aar和aps-unipush-gp-release.aar，打包应用上传google play时，替换原aps-igexin-release.aar或aps-unipush-release.aar。注意，google play版SDK与原版SDK存在冲突，所以使用时只能保留其中一个。

AndroidManifest.xml配置

google play版UniPush配置

在AndroidManifest.xml中添加如下配置。

        <activity  
            android:name="com.igexin.sdk.PrivacyActivity"  
            android:exported="false"/>  

google play版个推配置

在原个推离线配置基础上将如下配置添加到AndroidManifest.xml中。原个推配置参考：Android平台离线打包推送插件配置或SDK中的Feature-Android.xls文件。

        <service  
            android:name="io.dcloud.feature.apsGt.GTPushDevService"  
            android:exported="true"  
            android:label="PushService"  
            android:process=":pushservice" />  
        <activity  
            android:name="com.igexin.sdk.PrivacyActivity"  
            android:exported="false"/>  

aps-igexin-gp-release.aar和aps-unipush-gp-release.aar位于离线SDK/libs下。

以前做webapp的时候，在uc手机浏览器及个别浏览器下使用constant(safe-area-inset-top)和env(safe-area-inset-top)会有不兼容情况，甚至出现样式错误
于是在:root下去定义css变量。
但是小程序或者uniapp下是是不可以的。那么，真的要uni-app 全面屏适配（iphoneX适配）及安全区设置一样写3条css兼容吗？
其实不用，将page替换:root即可，上代码

page {  
    --safe-area-inset-top: 0px;  
    --safe-area-inset-right: 0px;  
    --safe-area-inset-bottom: 0px;  
    --safe-area-inset-left: 0px;  

}  

@supports (top: constant(safe-area-inset-top)) {  
    page {  
        --safe-area-inset-top: constant(safe-area-inset-top);  
        --safe-area-inset-right: constant(safe-area-inset-right);  
        --safe-area-inset-bottom: constant(safe-area-inset-bottom);  
        --safe-area-inset-left: constant(safe-area-inset-left);  
    }  

}  

@supports (top: env(safe-area-inset-top)) {  
    page {  
        --safe-area-inset-top: env(safe-area-inset-top);  
        --safe-area-inset-right: env(safe-area-inset-right);  
        --safe-area-inset-bottom: env(safe-area-inset-bottom);  
        --safe-area-inset-left: env(safe-area-inset-left);  
    }  
}  

```用法：  
1、margin-top: var(--status-bar-height);  
2、height: calc(100vh - 88rpx - 100rpx - var(--safe-area-inset-bottom) - var(--status-bar-height));

废话不多说直接上源码，如有不足，请留言

<template>  
  <div class="scan">  
    <header>  
      <p @click="closeScan">返回</p>  
      <span>请扫码二维码</span>  
      <p @click="scanImg">相册</p>  
    </header>  
    <div id="bcid">  
      <div style="height:40%"></div>  
      <p class="tip">...载入中...</p>  
    </div>  
  </div>  
</template>

下面是js部分

<script type='text/ecmascript-6'>  
let scan = null;  
export default {  
  data() {  
    return {  
      codeUrl: ""  
    };  
  },  
  mounted() {  
    //跳转时自动开启  
    this.startRecognize();  
  },  
  methods: {  
    // 创建扫描控件  
    startRecognize() {  
      let that = this;  
      if (!window.plus) return;  
      scan = new plus.barcode.Barcode(  
        "bcid",  
        [plus.barcode.QR, plus.barcode.EAN8, plus.barcode.EAN13],  
        {  
          frameColor: "#009DE2",  
          scanbarColor: "#009DE2"  
        }  
      );  
      //scan.onmarked = onmarked;  

      // 开始扫描  
      //scan.start();  
      function onmarked(type, result, file) {  
        switch (type) {  
          case plus.barcode.QR:  
            type = "QR";  
            break;  
          case plus.barcode.EAN13:  
            type = "EAN13";  
            break;  
          case plus.barcode.EAN8:  
            type = "EAN8";  
            break;  
          default:  
            type = "其它" + type;  
            break;  
        }  
        result = result.replace(/\n/g, "");  
        that.codeUrl = result;  
        window.localStorage.codeUrl = result;  
       // alert(result);  
        //that.closeScan();  
      }  
    },  
    // 关闭返回  
    closeScan() {  
      if (!window.plus) return;  
      scan.close();  
      this.$router.push({ path: "/home" });  
    },  
    scanImg() {  
      // 从系统相册选择文件  
      if (!window.plus) return;  
      plus.gallery.pick(  
        function(path) {  
         // alert(path);  
          plus.barcode.scan(  
            path,  
            function(type, result) {  
             // alert("Scan success:(" + type + ")" + result);  
              window.localStorage.codeUrl2 = result;  
            },  
            function(e) {  
              console.log(e);  
              window.localStorage.codeUrl2 = e;  
              plus.nativeUI.alert("如果图片无法识别,请用扫码上传");  
            }  
          );  
        },  
        function(e) {  
          alert("取消选择图片");  
        },  
        { filter: "image" }  
      );  
    }  
  }  
};  
</script>

下面是样式可以自行写

<style lang="scss">  
.scan {  
  height: 100%;  
  #bcid {  
    width: 100%;  
    position: absolute;  
    left: 0;  
    right: 0;  
    top: 1rem;  
    bottom: 0;  
    text-align: center;  
    color: #fff;  
    background: #ccc;  
  }  
  header {  
    position: absolute;  
    display: flex;  
    justify-content: space-between;  
    font-size: 16px;  
    color:#009DE2;  
    left: 0.3rem;  
    top: 0;  
    right: 0.3rem;  
    height: 1rem;  
    line-height: 1rem;  
    z-index: 2;  
    span{  
      color: #000;  
    }  
  }  
}  
</style>

觉得有用就关注点个赞吧，么么哒

第一步,在项目根目录创建index.html.

如图

然后再index.html中复制一下代码

这段代码,在官方文档中有 地址:https://uniapp.dcloud.io/collocation/manifest?id=%e5%ae%8c%e6%95%b4-manifestjson 有关自定义模板的

第二步,将ico图标放入根目录的/static/img 中,如图:

第三步,在创建的index.html文件中加入代码

第四步,在manifest.json中H5配置中配置自定义模板,如图:

最后,配置好之后,编译h5文件,放在本地服务器中预览,是否达到效果

该问题已经整理入笔记，欢迎大家收藏：HBuilderX 检测不到XCode上的模拟器

HBuilder 检测不到XCode上的模拟器

在终端中尝试命令：

xcrun simctl list

返回：xcrun: error: unable to find utility "simctl", not a developer tool or in PATH

搜索发现是多个XCode 版本导致，想想由于昨天刚安装了homebrew，可能是它导致的

解决方法：

选择一个code版本：

sudo xcode-select -s /Applications/Xcode.app/Contents/Developer/

再次运行：xcrun simctl list

问题解决。

1. uni.chooseImage 在手机浏览器中无法在异步回调中拉起；
2. 可以在异步完成后调用uni.showModal 然后在showModal的success回调中再去调用uni.chooseImage可以拉起成功。

chooseImage: async function() {  
    let that = this;  
    if (this.imageList.length === 3) {  
        let isContinue = await this.isFullImg();  
        if (!isContinue) {  
            return;  
        }  
    }  

    uni.chooseImage({  
        sourceType: sourceType[that.sourceTypeIndex],  
        sizeType: sizeType[that.sizeTypeIndex],  
        count: that.imageList.length + that.count[that.countIndex] > 3 ? 3 - that.imageList.length : that.count[that.countIndex],  
        success: (res) => {  
            that.imageList = that.imageList.concat(res.tempFilePaths);  
        },  
        fail: (err) => {  
        }  
    })  
},  
isFullImg: function() {  
    let that = this;  
    return new Promise((res) => {  
        setTimeout(function() {  
            //如果我把uni.showModal这段代码注释掉替换成 res(true); ，uni.chooseImage 就不会在手机端的浏览器中调起来  
            uni.showModal({  
                content: "已经有3张图片了,是否清空现有图片？",  
                success: (e) => {  
                    if (e.confirm) {  
                        that.imageList = [];  
                        res(true);  
                    } else {  
                        res(false)  
                    }  
                },  
                fail: () => {  
                    res(false)  
                }  
            })  
        },2000)  
    })  
}  

历时三个月 ，基本完成了公司的app项目！下面我我在使用uniapp时遇到的问题做个总结【可能并非全部】（其实只用了两个多月，后面app部分页面，及流程重做了）  

1、项目开始时
其实项目开始时，页面已经用vue做了一半了，但是后来老大说可能要做成小程序，然后告诉了我这个框架《uniapp》花了近一个星期，边学边做又将vue上的项目转移到uniapp ，做开始遇到了几个小问题都是一些标签使用上的问题，基本多看几遍文档就能够解决！
2、修改BUG
在整个项目编写过程中，我将几个遇到的问题列举下：
1、注册（上传多张图片）
这个问题一共用了差不多一个多星期。
需求：用户注册需要填写信息，上传图片 1、身份证正反2、生活照（用来做人脸识别）3、权限证书（权限证书又分了三种对应三种权限）
这个需求，这么理解，三个权限可以组合，也就是权限1
单独的权限需要传1、身份证正 2、身份证反 3、生活照 4、权限证书
两个权限需要传1、身份证正 2、身份证反 3、生活照 4、权限证书1 5、权限证书2
三个权限都有的 1、身份证正 2、身份证反 3、生活照 4、权限证书1 5、权限证书2 6、权限证书3
在这里遇到的问题就是关于上传的问题，刚开始我没有使用uniapp内置的api 我直接调用的接口，后来发现传不了，需要用表单，但是页面结构都已经做好了，所以就放弃了这一种，然后就是百度，发现又uploadfile 这个api 然后就开始了 钻坑之旅
1.多张图片传不了？（files）
用了差不多一天多的时间发现多张图片传不了？？？一头雾水不是写的5+app吗？
因为花了太多的时间果断放弃！

2. 将图片转未base64
   又去百度搜索图片转base64的方法，最后发现转完图片太大了这个方法肯定不行，转完后的大小几十M到一两百M，好吧又果断放弃
   3.然后有回到在页面添加标签form表单的方法
   这个方法用了半天去改页面弄东西，后来发现，需要操作dom通过js去创建表单。。嫌弃太麻烦又放弃了！
   4.最后还是用回了uploadfile
   选来选去最后还是用回了这个内置的api，经过自己不断的学习（问人），发现自己少了个东西 {name：name，uri:图片地址}在一个不起眼的角落里还有一个files 的说明uri 和name 的问题如图

其实很简单，使用这个工具就可以生成了

https://www.yunedit.com/createcert

使用方法非常简单，也就是登录进去这个工具，创建证书，就可以像使用苹果电脑钥匙串访问那样创建一个csr文件了，还能在线生成p12证书

而且是免费的，非常好用

随着微信、阿里、百度、头条、QQ纷纷推出小程序，开发者的开发维护成本持续上升，负担过重。这点已经成为共识，现在连小程序平台厂商也充分意识到了。

阿里小程序团队，为了减轻开发者的负担，在官方的小程序开发者工具中整合了多端框架。

经过阿里团队仔细评估，uni-app 在产品完成度、跨平台支持度、开发者社区、可持续发展等多方面优势明显，最终选定 uni-app 内置于阿里小程序开发工具中，为开发者提供多端开发解决方案。

经过之前1个月的公测，10月10日，阿里小程序正式发布0.70版开发者工具，通过 uni-app 实现多端开发，成为本次版本更新的亮点功能！

如下图，在阿里小程序工具左侧主导航选择 uni-app，创建项目，即可开发。

集成 uni-app，这对于阿里团队而言，并不是一个容易做出的决定。毕竟 uni-app 是一个三方产品，要经过复杂的评审流程。

这一方面突显出阿里团队以开发者需求为本的优秀价值观，另一方面也证明 uni-app 的产品确实过硬。

很多开发者都有多端需求，但又没有足够精力去了解、评估 uni-app，而处于观望态度。现在大家可以更放心的使用 uni-app 了，它没有让阿里失望，也不会让你失望。

自从 uni-app 推出以来，DCloud也取得了高速的发展，目前拥有370万开发者，框架运行在4.6亿手机用户设备上，月活达到1.35亿（仅包括部分接入DCloud统计平台的数据）。并且数据仍在高速增长中，在市场占有率上处于遥遥领先的位置。

本次阿里小程序工具集成 uni-app，会让 uni-app 继续快速爆发，取得更大的成功。

后续DCloud还将深化与阿里的合作，在serverless等领域给开发者提供更多优质服务。

使用多端框架开发各端应用，是多赢的模式。开发者减轻了负担，获得了更多新流量。而小程序平台厂商，也能保证自己平台上的各种应用可以被及时的更新。

DCloud欢迎更多小程序平台厂商，与我们一起合作，为开发者、平台、用户的多赢而努力。

进一步了解uni-app，详见：https://uniapp.dcloud.io

欢迎扫码关注DCloud公众号，转发消息到朋友圈。

​

小程序原生开发有不少槽点：

1. 原生wxml开发对Node、预编译器、webpack支持不好，影响开发效率和工程构建流程。所以大公司都会用框架开发
2. 微信定义的这套语法，wxml、wxs，以及wx:if等语法，私有化太强。不如正经学vue，学会了全端通用，而不是只为微信小程序
3. vue生态里有太多周边工具，可以提高开发效率，比如ide、校验器、三方库。。。而微信的开发者工具和专业编辑器相比实在不好用，个性化设置也非常少

作为前端工程师，除了微信小程序，还要开发web、其他小程序甚至App，人们不喜欢来回切换开发工具和变更语法思考方式。

uni-app自然可以解决这些问题，但开发者又经常有些顾虑：

1. 怕使用uni-app后，微信小程序里有的功能无法实现，受制于uni-app的更新
2. 怕性能不如原生WXML
3. 怕框架不成熟，跳到坑里
4. 担心社区生态不完善

本文从开发者关心的功能、性能、学习门槛、开发体验、生态、可扩展性等维度，逐个分析对比，给予说明。

1.功能实现

开发者最常问的问题：如果小程序迭代升级，新增了一批API，但uni-app框架未及时更新，该怎么办？

其实这是误解，uni-app不限制底层API 调用；在小程序端，uni-app支持直接编写微信原生代码。

类比传统web开发，如果vue、react等框架的使用，造成开发者无法操作浏览器提供的所有api，那这样的框架肯定是不成熟的。小程序开发也一样，uni-app框架中，同样可调用微信提供的所有原生API。

故如果存在某些API（平台特有或新增API），uni-app尚未封装，开发者可直接在uni-app中编写微信原生API，即wx.开头的各种API。

举个例子，目前uni-app虽然尚未封装跨平台的广告（ad）组件，但开发者在小程序端依然可以使用微信<ad>组件来展现广告，代码示例如下：

 <view>  
    <view>微信公众号关注组件</view>  
    <view>  
        <!-- uni-app未封装，但可直接使用微信原生的official-account组件-->  
        <official-account></official-account>  
    </view>  
</view>

包括微信小程序自定义组件、WXS、云开发这些复杂用法，在uni-app里一样全面支持。尤其是wxs，目前在各种小程序开发框架里，也只有uni-app支持。

所以，结论是：使用uni-app框架开发，在功能上和原生小程序开发没有区别，不会有任何限制。

2. 性能体验

开发者常问的第二个问题：三方框架，内部大多做了层层封装，这些封装是否会增加运行负载，导致性能下降？

同样是多虑了，uni-app不会导致性能下载，甚至对很多环节做了自动优化，很多场景下性能体验比微信原生开发更好。

类似使用vue.js开发web，不但不会造成性能比原生js差，反而由于虚拟dom和差量更新技术的运用，在大多数场景下，比开发者手动写代码操作dom的性能还好。

小程序中需要频繁的写setData代码来更新数据，这里很重要的就是差量数据更新。如果不做差量，代码性能不好，如果每处逻辑都判断差量数据更新，那代码写起来太麻烦了。

使用uni-app，底层自动差量数据更新，简单而高性能。

我们从优化理论、实测数据两个维度来仔细说明。

2.1 理论：框架优化方案

为提高性能体验，小程序从架构设计层面做了很多工作：

• 逻辑层、视图层分离，避免JS运算阻塞视图渲染
• 单独定义组件标签（wxml），减少DOM复杂度
• 精简样式（wxss），提升渲染性能
• 复杂组件原生化（video/map等），解决web组件的功能/体验缺失

通过这些规范约束，大幅提升了小程序的整体性能体验，但依然存在不少性能坑点，其中以setData最为频繁普遍。

这里引用微信官方的描述，简单介绍一下setData背后的工作原理：

小程序的视图层目前使用 WebView 作为渲染载体，而逻辑层是由独立的 JavascriptCore 作为运行环境。在架构上，WebView 和 JavascriptCore 都是独立的模块，并不具备数据直接共享的通道。当前，视图层和逻辑层的数据传输，实际上通过两边提供的 evaluateJavascript 所实现。

为简化开发，微信将evaluateJavascript调用封装成了setData JS方法，实现视图层和逻辑层的数据传输，数据流示意图如下：

setData的执行会受到很多因素的影响，setData每次传递数据量过大或频繁被调用（见微信官方介绍），都可能引发性能体验问题。

幸运的是，uni-app在这两个方面都有优化。

2.1.1 减少 setData 传递数据量

假设当前页面有一个列表（初始值为a,b,c,d），现在要向列表后追加4个新列表项（e,f,g,h），我们分别以微信原生、uni-app 两种模式编写代码。

小程序原生代码：

page({  
    data:{  
        list:['a','b','c','d']  
    },  
    change:function(){  
        let newData = ['e','f','g','h'];  
        this.data.list.push(...newData);  
        this.setData({  
            list:this.data.list  
        })  
    }  
})

如上微信原生代码，change方法执行时，会将list中的a,b,c,d,e,f,g,h8个列表项通过setData全部传输过去。

uni-app 代码：

export default{  
    data(){  
        return {  
            list:['a','b','c','d']  
        }  
    },  
    methods:{  
        change:function(){  
            let newData = ['e','f','g','h'];  
            this.list.push(...newData)  
        }  
    }  
}

如上uni-app代码，change方法执行时，仅会将list中的e,f,g,h4个新增列表项传输过去，实现了setData传输量的极简化。

uni-app借鉴了 westore JSON Diff库，在调用setData之前，会先比对历史数据，精确、高效计算出有变化的差量数据，然后再调用setData，仅传输变化的数据，这样就实现 setData 传递数据量的最小化，大幅提高通讯性能。

Tips：也许有些同学对传递数据从a,b,c,d,e,f,g,h8个列表项优化为e,f,g,h4个列表项，不以为然，但我们提醒，不要小看这个机制，上述只是demo示例。

• 在实际列表场景中，每个列表项可能包含缩略图、标题、摘要、时间等各种信息，每个列表项数据都会更大（假设为1k）；
• 假设当前页面有20个列表项，连续上拉4次后，页面变成100条记录；如果再次上拉，页面变成120条记录时，情况会有不同
• 上述微信原生的方式，将120条记录数据(120k)全部传输过去
• 上述 uni-app 模式，仅会将新增的20条（101 ~ 120）记录数据（20k）传输过去，数据量是原生方式的1/6！
• 当页面列表项数据越多，这个差别就越大，页面有200条记录时，uni-app传递数据量会变成微信原生数据传递量的1/10！

2.1.2 减少 setData 调用频次

假设我们有更改多个变量值的需求，我们分别以微信原生、uni-app 两种模式编写代码。

小程序原生代码：

change:function(){  
    this.setData({a:1});  
    this.setData({b:2});  
    this.setData({c:3});  
    this.setData({d:4});  
}

如上四次调用setData，就会引发4次逻辑层、视图层数据通讯

uni-app 代码：

change:function(){  
    this.a = 1;  
    this.b = 2;  
    this.c = 3;  
    this.d = 4;  
}

如上uni-app的代码，最后会被合并成{"a":1,"b":2,"c":3,"d":4}一条数据，然后仅调用一次setData完成所有数据传递，大幅降低了setData的调用频次。

uni-app之所以有这样的优势，是因为 uni-app 基于 Vue Runtime 深度定制实现，并借助了 Vue 的 nextTick 机制。

2.2 实测：性能对比数据

有了如上的理论分析，我们接着进行真机实测，用数据来对比。

测试模型如下：

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

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

• 界面如下：
  

• 开发版本：使用微信原生、uni-app分别开发两套代码，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进程、清空内存，保证测试机环境基本一致；每次从本地读取静态数据，屏蔽网络差异。

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

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

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

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

测试结果如下：

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

这个数据，可能违反了很多人的直觉，uni-app 的性能竟然比微信原生还好！

当然，使用微信原生开发，也可以自己单独写代码优化setData。但每处业务都编写太多判断是不现实的，自然是用框架更舒心。

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

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

3.社区生态

3.1 周边轮子

小程序是脱离web自造生态，很多web生态中轮子无法使用。

微信小程序还是有周边生态的，而其他几家小程序平台的生态基本没建起来。

uni-app的周边生态非常丰富，在插件市场有近数千个插件，详见 ext.dcloud.net.cn。

首先uni-app兼容小程序的生态，各种自定义组件均可直接引入使用。在此基础上，uni-app的插件市场，有更多vue组件，同时可跨多端使用，并且性能优秀。

这使得uni-app的生态成为最丰富的小程序开发生态。

比如富文本解析、图表、自定义下拉刷新等组件，uni-app的插件性能均超过了wxparse、wx-echart等微信小程序组件。包括 uni ui等ui库的性能也超过了vant、iview等ui库的小程序版。

如果开发者需要丰富和高性能的组件，更应该使用uni-app，而不是原生小程序开发。

3.2 活跃的QQ/微信群和论坛

uni-app官方有 70 个开发者QQ/微信交流群（大多2千人群，近10万开发者），三方群更多。

问答社区，每天有数百篇帖子。活跃度与微信小程序官方论坛相同，远超过其他小程序官方论坛。

uni-app三方培训活跃，腾讯课堂官方都为uni-app制作了课程，各种培训网站到处可见免费或收费的uni-app培训视频教程。

4.学习门槛、开发体验

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

uni-app则对开发者更为友好，简单来说是 vue的语法 + 小程序的js api。

它遵循Vue.js语法规范，组件和API遵循微信小程序命名，这些都属于通用技术栈，学习它们是前端必备技能，uni-app没有太多额外学习成本。

有一定 Vue.js 和微信小程序开发经验的开发者可快速上手 uni-app 。

没学过vue的同学，也不用掌握vue的全部，只需了解vue基础语法、数据绑定、列表渲染、组件等，其他如路由、loader、cli、node.js、webpack并不需要学。

因为HBuilderX工具搭配uni-app可以免终端开发，可视化创建项目、可视化安装组件和扩展编译器，也就是uni-app的学习门槛，比web开发的vue.js还低。

开发体验层面，微信原生开发相比uni-app有较大差距，主要体现在：

• 更为强大的组件化开发能力：vue的组件开发比小程序自定义组件开发的体验要好很多
• 应用状态管理：uni-app支持vuex
• 使用 Sass 等 CSS 预处理器
• 完整的 ES Next 语法支持
• 自定义构建策略

开发工具维度，差距更大：

• 微信开发者工具被吐槽无数
• uni-app的出品公司，同时也是HBuilder的出品公司，DCloud.io。HBuilder/HBuilderX系列是四大主流前端开发工具（可对比百度指数），其为uni-app做了很多优化，故uni-app的开发效率、易用性非微信原生开发可及。

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

5.未来扩展性

虽然当前产品仅要求发布到微信小程序，但阿里、百度、字节跳动、QQ、快应用等众多平台的流量越来越多，覆盖这些平台是迟早要考虑的事情。

此时，uni-ap的跨端功能将成为程序员的自救神器，基于uni-app开发的小程序，无需修改，即可同时发布到多家小程序，甚至App、H5平台。这不是梦想，而是现实。大家可依次扫描如下8个二维码，亲自体验最全面的跨平台效果！。

6.结语

结论：只开发微信小程序，也应该使用uni-app

demo https://gitee.com/hw2016/hbuilderx_simplify

具体请看原贴：

帖子 https://www.jianshu.com/p/35d6111bd215

我使用的资源库如图（精简版）：