一、移动端框架选型1、原生or 稠浊 or web
选型问题实在我并没有考虑，由于根据我们实际情形，最适宜的还是稠浊开拓。这里大概阐述一下原生、稠浊、web的差异。
原生开拓没什么可说的，体验肯定是最好的，但是需android、ios两批人，小程序还要加人，人力成本相对较高。
这里所说的web是指用webview包装，紧张问题是体验不太好，开拓本钱最低。
而稠浊开拓则结合两者的上风，即可感想熏染原生的体验，也可享受热更新。原生通过js调用android及ios的API（iOS是jscore，Android是v8）。特殊是首页，列表等页面达到近似于原生的性能，也可以通过webview达到热更新的便利。
这里选型紧张考虑人力情形、开拓本钱情形、人才的知识构造等。见下图：
2、三大框架不谈论。根据职员知识构造决定了选择vue。
3、flutter or uniapp这里特殊说下flutter,由于它是google的产品，性能高。但它也只是个界面库。渲染性能排序：flutter>js调用原生渲染（react native/weex/uni-app）>webview渲染。但是flutter的写法很有可奇葩，不适应web开拓者；其余三方接口调用方面能力弱。虽然flutter的发展势头不错，但对我们团队来说，本钱还是太高。
二、uniapp框架选择其实在写文章之前已经决定采取uniapp了，并不是它有多好，而是它适宜我们目前的小团队。由于之前我们已经用uniapp来开拓app,但由于库太旧，对nvue的支持弱，就决定升级原框架及页面，但并不想从头开始布局，于是选择得当的根本通用框架。
1、uni-starterdcloud官方供应的快速框架，官方描述：uni-starter是一个集成了大量商用项目常见功能的，云端一体运用快速开拓基本项目模版。APP有很多通用的功能，比如登录注册、头像、设置、banner、... uni-starter将这些功能都已经集成好。
实在已经基本知足一个通用框架的基本条件，本来准备采取它，但是它后台基于uniCloud，而且“不能将后台改成php、java等其他后台，这将违反利用容许协议“，由于我们后台有自己的框架，以是只能放弃了。
2、uni-xiaofan终极我们采取的根本框架。
缘故原由有三：
（1） 跟旧框架一脉相承，升级本钱低。
（2） 采取uview2,支持nvue。
（3） Mit协议，且目前作者在掩护。
3、ruoyi-uniapp基于ruoyi的根本框架，目前只实现部分功能，界面可借鉴。
终极我们采取uni-xiaofan框架，并借鉴uni-starter及ruoyi-uniapp的部分功能。
三、uniapp实践1、实践目标（1）平台必须支持app(android和Ios)，微信小程序、Chrome。
（2）app只管即便采取nvue,特殊是首页和列表部分。
（3）只管即便采取flex布局，布局不该用百分比、没有媒体查询。
（4）基本框架支持vue3，只管即便同时支持vue3。
（5）部分功能用uni-cloud实践，如版本升级及问题反馈功能。
2、UI库本项目UI库紧张采取uni-app自带的，再结合第三方库。第三方根本库紧张采取uview2.0。
优先级：内置组件>uni-ui扩展组件>uview2.0组件>…
可通过uni_modules来安装扩展组件，不须要引用、注册，并可以通过右键快速更新组件。
3、布局支持跨平台，框架利用 Flex 布局。
4、CSS※只管即便不该用百分比布局，如width：100%
※class 进行绑定时只支持数组语法。
※不支持媒体查询。
※不能在 style 中引入字体文件。
※不支持在css里写背景图background-image，但可以利用image组件和层级来实现类似web中的背景效果。由于原生开拓本身也没有web这种背景图观点。
※设置background-color。
※笔墨内容，必须只能在text组件下，text组件不能换行写内容，否则会涌现无法去除的周边空缺。
※只有text标签可以设置字体大小，字体颜色。
其余只管即便不该用uview2.0中的内置样式。
5、国际化目前框架已支持国际化。利用时{{$t('mine.notLoggedInfo')}}or$t('mine.feedback')调用即可。
6、支持uniCloud虽然我们不完备采取uniCloud，但是部分功能可通过unicloud实现，如版本升级及问题反馈等，实现更便捷。
四、uniapp页面1、我的2、
3、通讯录
4、事情台
