uView2.0与uView1.x之间，是有非常大差异的，1.x不能升级到2.x版本。
造成这个问题的根本原因是，2.x是一个重构版本，对1.x进行了整个架构的改造升级，摒弃了1.x中一些不合理的理念和做法，同时引入很多优秀的新特性，让2.0更加 健壮和稳定。
下面列出一些1.x与2.x的差异，让您能更好的对2.x有整体的认识，了解该使用哪个版本，以及是否值得升级到2.0版本。

#1. 对nvue的支持

众所周知，1.x是不支持nvue的，所以2.x立项的首要目标就是对nvue的兼容，目前uView2.0也全面实现了兼容nvue。
我们也知道，nvue的背后其实是weex，在渲染上有出色的效果，但是其也有很多无法填平的兼容问题，导致某些情况下费尽心思依然无法实现理想的效果。

#2. form表单校验的加强

在1.x中，prop参数不支持a.b.c的写法，2.x实现了支持，同时对form组件引入了validateField、resetFields、clearValidate等方法，从各个方面对表单功能 进行了加强，让您在移动端依然能对表单校验游刃有余。

#3. 优化popup弹窗组件

在2.x中，我们对弹窗进行了优化，有如下：

• 修复了1.x中快速切换可能会卡死；
• 移除了内置的scroll-view组件，让popup内的内容可以超出边界；
• 优化弹窗的响应速度
• 处理了由于uni-app的问题，导致微信小程序内，弹窗内无法准确获取元素尺寸而导致某些内嵌组件失效的问题；
• 提供一个bgColor参数，设置为transparent可以方便去掉背景色，实现个性化的中部弹窗；

#4. 提供通用性的customStyle参数

我们为每个组件都提供了一个customStyle，一般作用于组件内部的根节点，可以方便设置一些基础样式，它同时能接受对象或者字符串的样式形式，如下：

// 对象形式
<u-badge :customStyle="{backgroundColor: 'red'}"></u-badge>// 字符串形式
<u-badge customStyle="background-color: red;"></u-badge>

copy

#5. 优化在微信小程序上的差异

微信小程序中，默认情况下，自定义组件本身的那个节点是一个“普通”的节点，使用时可以在这个节点上设置class style 、动画、 flex布局等，但是在复杂的 布局下，这可能会导致我们无法控制组件的整体布局，所以在2.x中，我们统一将所有组件设置为“虚拟的”，让其能更好的按我们的预期进行工作。

// #ifdef MP-WEIXIN
// 将自定义节点设置成虚拟的，更加接近Vue组件的表现，能更好的使用flex属性
options: {virtualHost: true
}
// #endif

copy

#6. 加强calendar日历组件

在2.x中，我们加入了多个控制参数，让您能够对日历进行各个方面进行细致的操作，如通过formatter参数，可以自定义日历提示语，角标等；允许控制日期最大和最小范围； 可以通过滚动的形式，同时展示多个月份；总之，相比1.x，我们从每个方面进行了细致的考虑，并提供了对应的处理方法。

#7. picker组件的调整

在1.x中，我们提供了picker和select组件，这些组件存在一些不足与混乱，同时可能无法配置出我们想要的场景，在2.x中，我们对此进行了梳理，拆分为典型的picker组件， 用于普通的非时间类型选择，同时提供datetime-picker组件，用于专门的时间选择，并针对时间的格式化，最小和最大时间等方面，提供了多样化的控制参数。

#8. 加强numberBox组件

在1.x上，由于历史原因，此组件存在更新值时可能会有异常的问题。在2.x中，我们对此组件进行了重构和加强，加入异步控制，以及样式完全自定义的特性，让它能适用于 任何您需要它的场景。

#9. 优化upload组件

在1.x中，我们将上传的核心功能集成在组件内，导致在某些特殊返回状态，以及有前端直传oss时，可能会操作不方便的问题。
所以，在2.x中，我们重构了此组件，此后，组件内部只提供图片(新增了视频和文件类型)的选择与展示，将上传的步骤交由外部用户自定义的逻辑进行操作，实现更好的解耦。

#10. 优化radio和checkbox组件

在1.x中，我们没法控制这两个组件的排列形式，所以在2.x中，我们提供了一个placement参数，可以对调图片与文本的位置，用于在特殊场景的布局，同时我们在组件内部进行了 特殊处理，让他们能更好的配合form组件进行表单校验。

#11. switch组件细节优化

在1.x中，该组件能够满足正常使用，在2.x中，我们对它进行优化，比如加入更好的loading效果、切换动画、以及提供space参数让您配置出另一种风格的样式。

#12. 优化countDown倒计时组件

在2.x中，我们对此组件进行如下优化：

• 加入毫秒级的功能
• 提供完全自定义的样式配置，让它能适用于任何场景。

#13. 优化swipeAction滑动单元格组件

在2.x中，我们针对不同的平台，采用不同的方案去实现此组件的效果，在nvue上，我们采用了BindingX方案，在APP和微信小程序，H5上，我们采用了wxs的方案， 这些优化 ，能让我们滑动单元格时，有丝滑和细腻的效果。

#14. 组件内部获取尺寸时机的优化

在1.x中，普遍的做法是在组件初始化完成后获取内部元素的尺寸，这导致在内容变化而导致尺寸变化后，可能导致不准确，或者需要通过调用组件的方法重新进行初始化。
而在2.x中，我们对此进行了反思，采用的方法为每次需要进行操作的时候，重新获取元素的尺寸，典型的为collapse折叠面板组件，在每次打开的时候，组件都会重新 计算该展示的高度。

#15. 父子嵌套组件调用的优化

在uView中，有很多组件都采用父子嵌套的做法，比如radio组件，就由u-radio-group和u-radio组件，1.x中对类似的组件采用了统一的处理方法，该方法存在一定的缺陷， 导致反复操作一些子组件时，重复加入一些实例到管理状态中，从而导致卡顿或者混乱。在2.x中，我们对类似的问题进行了优化，保证了状态的正确性，以及在组件被卸载的时候，进行移除。

#16. 骨架屏组件重构

在1.x中，我们需要给骨架屏组件提供类名，以及初始的模拟数据，让组件内部进行尺寸获取以及在对应的位置绘制占位图，在便捷性的同时，舍弃了可控性。
所以，在2.x中，我们采用了另一种实现方式，让用户可以通过参数的形式，配置出想要的占位图信息，可以获得更强的自定义性。

#17. 加强http请求

在1.x中，我们提供了基本可用的http支持，它也存在一些缺陷，比如不支持upload、download，其他各项配置不够细化等。
在2.x中，我们引入更专业的luch-request插件，它能全面的支持一个企业应用在各种复杂场景下的请求配置需求，我们对此插件进行了进一步的封装，并提供了详细实践用例， 您可以在Http请求 (opens new window)章节中查阅更多关于它的用法。

#18. 提供全局性的组件默认参数配置

我们知道，每个组件都有很多的props参数，在调用组件的时候，通过修改对应的参数，可以覆盖组件的默认值。但是在对于某个常用的组件来说，如果组件的某个参数 默认值不符合自己的需求，就需要在每次调用的时候，都去覆盖它。
在2.x中，我们对此提供了一个解决方案，假设u-text的color为#333333，而您应用的默认色值为#555555，就需要每次使用u-text组件时，都去修改它，如下：

<!-- 列表页 -->
<u-text color="#555555" text="列表内容"></u-text><!-- 详情页 -->
<u-text color="#555555" text="详情内容"></u-text>

copy

在2.x中，我们可以通过uni.$u.props.组件名.参数名的形去对组件的某个默认参数进行全局覆盖，比如我们我要修改u-text组件color参数：

// 建议在main.js中(初始化uView之后)引入外部配置文件中进行统一处理
uni.$u.props.text.color = '#555555'

copy

在进行如上设置后，整个应用中，任意调用u-text的地方，color参数的默认值都成为了#555555。

#19. 优化demo演示效果，以及移除了模板和js的模块

为了让组件库更加专注和简洁，我们在演示demo中，移除了1.x中关于模板和js的模块，同时优化了组件的演示效果，不再使用1.x切换按钮的形式去动态切换效果， 而是提供更直观的形式对组件的重要效果进行罗列演示。
同时，在官网中，我们也移除了模板模块。

#20. 加强tag组件

在2.x中，我们对tag组件进行了加强，相较1.x，它具有如下优势：

• 可以配置关闭功能
• 可以配置图标
• 可以适用于进行多选和单选的场景

#21. 加强swiper轮播图组件

在2.x中，我们对swiper组件进行了加强，让它可以配置出更加灵活的指示器样式，同时加入加载中的状态，以及可以嵌入视频播放的特性。

#22. 优化sticky吸顶组件

在1.x中，我们采用的是监听元素状态的形式，通过js方案进行吸顶，但是随着时代的进步以及设备的升级，大部分设备以及某些平台已经实现了对css sticky支持， 所以在2.x中，我们采用了两种方案，在各个平台，比如nvue, App, Ios，Android，微信小程序，H5等，通过各种手段，去判断当前平台或者设备是否支持css sticky， 如果支持则优先使用css方案以获得更细腻的效果。如果不支持css方案，则自动降级为js方案。

#23. 优化tabs组件

在1.x，可能会存在动态增减菜单下，底部滑块位置可能会错乱的问题，得益于2.x的整体架构调整，我们在每次移动滑块时，都会重新获取菜单的尺寸，再进行移动，保证了滑块 能准确移动到如期的位置。同时，我们对此组件还进行其他细节优化，比如可以禁用某个菜单，显示角标，可以配合u-sticky进行吸顶等。