当前位置:网站首页 > 更多 > 编程开发 > 正文

[知识总结] 【Uni-App】nvue调研

作者:CC下载站 日期:2021-03-08 04:22:00 浏览:72 分类:编程开发

博主之前一直开发的是web端,但由于射击平台的需求,需要开发安卓端和ios端。当然再去重新学习flutter成本较高,可以继续使用以前开发winner的uni-app,结合其内置的nvue,以最低的学习成本达成Android和ios端的开发。

Weex介绍

Weex 是使用流行的 Web 开发体验来开发高性能原生应用的框架。
"Weex" 的发音是 /wiːks/, 和 "Weeks" 同音。

  • Weex 致力于使开发者能基于通用跨平台的 Web 开发语言和开发经验,来构建 Android、iOS 和 Web 应用。简单来说,在集成了 WeexSDK 之后,你可以使用 JavaScript 语言和前端开发经验来开发移动应用。

  • Weex 渲染引擎与 DSL 语法层是分开的,Weex 并不强依赖任何特定的前端框架。目前 Vue.js 和 Rax 这两个前端框架被广泛应用于 Weex 页面开发,同时 Weex 也对这两个前端框架提供了最完善的支持。Weex 的另一个主要目标是跟进流行的 Web 开发技术并将其和原生开发的技术结合,实现开发效率和运行性能的高度统一。在开发阶段,一个 Weex 页面就像开发普通网页一样;在运行时,Weex 页面又充分利用了各种操作系统的原生组件和能力。

nvue介绍

uni-app App端内置了一个基于 weex 改进的原生渲染引擎,提供了原生渲染能力。

  • 在App端,如果使用vue页面,则使用webview渲染;如果使用nvue页面(native vue的缩写),则使用原生渲染。一个App中可以同时使用两种页面,比如首页使用nvue,二级页使用vue页面,hello uni-app示例就是如此。
  • 虽然nvue也可以多端编译,输出H5和小程序,但nvue的css写法受限,所以如果你不开发App,那么不需要使用nvue。
  • 以往的 weex ,有个很大的问题是它只是一个高性能的渲染器,没有足够的API能力(比如各种push sdk集成、蓝牙等能力调用),使得开发时非常依赖原生工程师协作,开发者本来想节约成本,结果需要前端、iOS、Android 3拨人开发,适得其反。 nvue 解决了这个问题,让前端工程师可以直接开发完整 App,并提供丰富的插件生态和云打包。这些组合方案,帮助开发者切实的提高效率、降低成本。
  • 同时uni-app扩展了weex原生渲染引擎的很多排版能力,修复了很多bug。比如
    Android端良好支持边框阴影
    iOS端支持高斯模糊
    可实现区域滚动长列表+左右拖动列表+吸顶的复杂排版效果
    优化圆角边框绘制性能

适用场景

nvue的组件和API写法与vue页面一致,其内置组件还比vue页面内置组件增加了更多。
如果你熟悉 weex或react native 开发,那么 nvue 是你的更优选择,能切实提升你的开发效率,降低成本。
如果你是web前端,不熟悉原生排版,那么建议你仍然以使用vue页面为主,在App端某些vue页面表现不佳的场景下使用 nvue 作为强化补充。
这些场景如下

  • 需要高性能的区域长列表或瀑布流滚动。webview的页面级长列表滚动时没有性能问题的(就是滚动条覆盖webview整体高度),但页面中某个区域做长列表滚动,则需要使用nvue的listrecycle-listwaterfall等组件。这些组件的性能要高于vue页面里的区域滚动组件scroll-view
  • 复杂高性能的自定义下拉刷新。uni-app的pages.json里可以配置原生下拉刷新,但引擎内置的下拉刷新样式只有雪花和circle圈2种样式。如果你需要自己做复杂的下拉刷新,推荐使用nvue的refresh组件。当然插件市场里也有很多vue下的自定义下拉刷新插件,只要是基于renderjs或wxs的,性能也可以商用,只是没有nvue的refresh组件更极致。
  • 左右拖动的长列表。在webview里,通过swiper+scroll-view实现左右拖动的长列表,前端模拟下拉刷新,这套方案的性能不好。此时推荐使用nvue,比如新建uni-app项目时的新闻示例模板,就采用了nvue,切换很流畅。
  • 实现区域滚动长列表+左右拖动列表+吸顶的复杂排版效果,效果可参考hello uni-app模板里的swiper-list
  • 如需要将软键盘右下角按钮文字改为“发送”,则需要使用nvue。比如聊天场景,除了软键盘右下角的按钮文字处理外,还涉及聊天记录区域长列表滚动,适合nvue来做。
  • 解决前端控件无法覆盖原生控件的层级问题。当你使用mapvideolive-pusher等原生组件时,会发现前端写的view等组件无法覆盖原生组件,层级问题处理比较麻烦,此时使用nvue更好。或者在vue页面上也可以覆盖一个subnvue(一种非全屏的nvue页面覆盖在webview上),以解决App上的原生控件层级问题。
  • 如深度使用map组件,建议使用nvue。除了层级问题,App端nvue文件的map功能更完善,和小程序拉齐度更高,多端一致性更好。
  • 如深度使用video,建议使用nvue。比如如下2个场景:video内嵌到swiper中,以实现抖音式视频滑动切换,例子见插件市场;nvue的视频全屏后,通过cover-view实现内容覆盖,比如增加文字标题、分享按钮。

纯原生渲染模式

  • uni-app在App端,支持vue页面和nvue页面混搭、互相跳转。也支持纯nvue原生渲染。
  • 启用纯原生渲染模式,可以减少App端的包体积、减少使用时的内存占用。因为webview渲染模式的相关模块将被移除。
  • 在manifest.json源码视图的"app-plus"下配置"renderer":"native",即代表App端启用纯原生渲染模式。此时pages.json注册的vue页面将被忽略,vue组件也将被原生渲染引擎来渲染。
  • 如果不指定该值,默认是不启动纯原生渲染的。
    // manifest.json    
      {    
           // ...    
          /* App平台特有配置 */    
          "app-plus": {    
              "renderer": "native", //App端纯原生渲染模式
          }    
      }

快速上手

nvue开发与vue开发的常见区别

基于原生引擎的渲染,虽然还是前端技术栈,但和web开发肯定是有区别的。

您需要 登录账户 后才能发表评论

取消回复欢迎 发表评论:

关灯