mui架构app-终章(我是怎样决定放弃mui)

背景

接mui上一篇文章,时间间隔大概有一年半了。写这一篇博客算是为mui收尾。mui对于app的编写确实是一个不错的框架,简洁的css,下拉刷新,上拉加载都还挺不错的。用了这么久了,对于优点和缺点我结合自己经验做一个总结吧。

优点

• 实现了js+html+css混编app
• 优秀的上拉刷新和下拉加载
• webview解决了单页面应用切换页面卡顿不流畅等问题
  想一想这个框架的优点差不多就这些了吧，严格意义上第一点和第三点是h5+的特性,跟mui没有半毛钱关系。

缺点

优点说来好像真的不太明显,如果不是因为有上拉加载和下拉刷新，我可能不会用这个框架。直接改用css+html+js+H5+API就开始搞了。但是最开始为了剩下这点时间我还是选择了mui,加上社区还有一个官方开源的聊天示例。
现在我来说说他的缺点吧

• 我想使用vue,但是mui作为传统框架vue智能在每个页面进行初始化。这样使用起来，vue的很多特性其实我都没用上
• 其次上拉加载和下拉刷新样式固定后，vue必须包裹上拉刷新和下拉加载。不然数据渲染会出问题，对我这样拥有强迫症的人来说，我其实很反感这总操作
• 仍然存在一些兼容问题,比如websocket连接，这个bug我可是解决了好久。我最初的构想是在首页初始化一个websocket。之后接收到数据使用mui.fire进行响应页面通知,但是实际上当你在其他页面很久的时候。fire指令好像并没啥卵用。通知也不行，这问题我反正是解决了，但是并不是我的理想方式
• 官方对于mui框架基本停止了维护快一年了。现在D-cloud团队正把大部分精力投入到uni-app的研发上
  其实缺点差不多就这些，严格意义上也不算缺点。只是我最心痛的是官方不维护了,毕竟了解一个框架，并将其熟练运用起来。并不是官方几句轻描淡写的几句话，我们就会了。要熟练运用每一个细节对于一个程序员来说需要很长的时间。毕竟你们是团队耗费很长的时间，而我们是个人学习你们开发的功能点。不知道D-cloud团队有没有意识到这个问题。我们从mui->uniapp也绝对不是一两天的事情,感觉这次的迁移就像app的大迭代。就好像有一天你打开微信想和微信的朋友聊聊天，却发现微信的界面大改动,每个功能点都要找一会才知道地方。

总结

自己作为D-cloud团队忠实的用户,我还是愿意将mui-app迁移为uniapp,毕竟在我的眼里，D-cloud团队真的很优秀，提供的编译器和这些所有的功能都是免费且开源的，也确实解决了小团队和个人开发者的开发效率问题(我自己后端JAVA出生的，我一个人就能完成前后端及app端了)。uniapp也业余接触了一两个月,加上用起来也有几个月了。说真的迁移并非像D-cloud团队所说那么容易。我作为一名个人开发者的体会真的是这样的。我没有小程序的基础，但是vue还用的不错。学习uniapp问题倒不算很大。我基本上看了5-10遍的官网，在看了一下相关的视频。就差不多可以摸索着走了。但是对于每个功能点，我其实都很深究的，毕竟我想自己做的app至少能够不卡顿,流畅.页面简洁。
我现在对uniapp还仍然只用来做app端。其实也有一些疑惑

• 我们都知道vue页面属于单页面应用，我在官网上其实并没有见到详细说明关于uniapp如何保证动画的流畅,数据的回收相关说明。只是知道跳转页面并不使用vue自带的路由，而是通过uni自己封装的跳转方式。如果uni自己封装的跳转方式，是打开新的webview那我觉得dom节点的操作开销挑战倒是可以解决了。因此希望官方能够在官网详细跟新下这一块的说明
• 因为我属于业余前端，对ios和安卓真的不太懂。只知道开发ios需要x-code和mac，安卓是基于java的，因此每次打包我都是直接丢给了D-cloud团队在线打包功能。我也懒得去学习ios和安卓了。uniapp也是如此,但是uniapp支持多端。我想知道我提上来的代码uniapp打包时候会不会针对安卓和ios专门优化处理。以保证页面性能更好
  当然uniapp提供了很多丰富的组件,其中nvue就是很好的一个东西。这个的原理我也不太清楚，但是官网说了会更好，有待自己慢慢摸索吧。为了性能，我甚至直接想把App.vue改成App.nuve，但是又不知道会不会出什么问题。试错成本也花销了，不过有时间我还是回去尝试了。我也不喜欢直接问官方问题，因为人家也忙的，还给你服务。
  总而言之，如果大家想用mui做app的话,我并不是很建议,虽然做出来也确实可用。但是我还是希望能看到这边博客的朋友使用uniapp,只有一起拥抱生态。生态才会更好。如果你像我一样已经有成型的mui-app了。那我建议不要迁移了,mui其实只是css样式表而已。核心功能点仍然在5+api上