uniapp小程序生命周期_uniapp小程序如何做登录

为什么国内的uniapp一直没人讨论呢？

uniapp能够实现一套代码，多端实现（android,ios,小程序，百度小程序等）如此强大而又符合国内的市场环境的方案，为什么国内一直不火？感觉很少人讨论。反而react nactive或谷歌出的flutter，一出来就特别多的。

主要看兼容性和扩展性如何。首先uni-app的想法是好的，解决了开发者的难题，但是如何跟得上原生平台的SDK更新和设备的兼容，这个问题如何解决，这是一个很大的问题，还有一个第三方库的使用和兼容的问题，这都是需要解决的。如果只是一个简单的web的开发项目，那么可以试试，功能复杂的话就不太适合了，特别是对性能和兼容，以及适配上面需要有要求的时候，就需要特别注意了。

最后再来做一个对比：

1、首先你要搞清楚什么才是跨平台的真正目的。任何跨平台无非就是以下几种方式去解决问题：

• 语言层面编译转换一下，编译成C语言或者字节码之类的，能够运行在不同的设备上面，但是这个语言转换过程很复杂，而且还需要做移植的工作。比如著名的：swiftUI，kotlin-native就是这类型的跨平台框架。
• 自带渲染引擎，不依赖于任何平台，一套代码就可以自动编译成多个平台的应用程序。比如：Flutter
• 中转类型的框架，使用JS衔接原生平台的一些功能，要么由社区开发者自己维护一套扩展兼容库，要么本身带有一系列的兼容库，但是还是摆脱不了Web的环境和编程思想，全部依赖于JS，如果不熟悉JS的朋友，去用这种类型的框架开发跨平台应用程序，简直是灾难。这类型的框架有：React Native，Weex，当然也包括楼主提出的5+app以及uni-app。

2、既然有了上面的介绍，相信大家也会大概了解跨平台框架的一些大概分类和作用了。那么我们再回到问题本身来。

无论5+app也好，还是uni-app也好，终究只是对传统h5 app做的优化。

下面来看看对比：

h5+ app：

• 【优点：】h5+内置runtime，可以使用它去调用native的一些功能，产品体验比较好（针对UI来说的）。
• 【缺点：】但是开发难度也高，另外不管是兼容性，还是native功能衔接以及适配都是一个很大的问题，如果要针对不用版本的系统（比如Android SDK一直在更新）和手机设备做兼容，这个还需要h5+ app研发团队做定制化更新，但是你的项目需要用到啊，你要等到猴年马月才能等到h5+ app更新？所以如果一个框架重度内置一些固定的native功能，一般推荐你慎重考虑，因为你需要兼容不同的系统和设备，你不可能让h5+ app这类第三方的框架随时帮你升级到你想要的native功能，说实话你的项目也等不了这么久。

uni-app：

• 【优点：】uni-app内部兼容了vue的写法，用于跨平台，可以同时支持android、ios，多家主流小程序，以及H5，可以说是很全面的一个框架。兼容性做的还行，至少用市面上流行的web框架来看，uni-app应该算是集大成的一个框架了。如果你的应用程序只是用纯web开发的话，你又想做小程序，uni-app一举两得，倒是很适合你的。
• 【缺点：】

1.但它也有缺点的，比如很多web库你无法使用，因为uni-app的内部原理决定了它不支持web库，所以如果你要用第三方web库，抱歉了很多都不支持，除非你不用uni-app。
2.另外一个就是uni-app如果想个性化定制一些功能的话，有点难度，因为目前你只能按照它的要求去做，所以如果你想开发很牛逼的功能，或者UI界面，那么你应该放弃使用uni-app。
3.真机调试debug是一个很严重的问题，对移动设备的调试和兼容方面做的还不够。

Flutter：

• 【优点：】Flutter是谷歌推出的一个全新的跨平台的开发框架。

1.你只需要使用Dart语言写一套代码，即可自动编译到各个平台，目前支持Android,iOS,Web(Beta)，Desktop(Alpha)，当然也有Windows PC和linux平台的兼容支持官方正在研发中。所以你完全不用担心框架内部是如何帮你实现的。你只需要一个命令行就可以在对应平台运行你的代码了，比如：flutter run xxx，这里的xxx指的是你的平台设备名称，比如“flutter run chrome"表示将程序运行在浏览器上面。
2.高性能高一致性。你的代码编译出来的程序可以达到60bps的高性能。
3.丰富的组件支持，你完全可以按照你的想法去做，扩展性非常强大，MD风格的，以及ios风格的组件都有，足够满足平时开发需求。而且Flutter基于react以及flex的思想进行布局，Dart语法很像JS+Java+Swift+Kotlin+C#+TypeScript+JavaScript+PHP，虽然表面上没有使用web开发，但是你完全不用担心，你仍然可以进行开发，只是语言写法不一样，但是这里面很多都是熟悉的东西，基本上上手成本也是很低的。
4.丰富的社区支持。目前常用的组件以及一些第三方包都有大佬开源出来了，足够应对平时的开发了。如果你不清楚的话，也没干系，我特意收集了Flutter工具集合，这里面啥都有，足够让你可以快速找到你要的东西，你可以点进来看看：https://github.com/AweiLoveAndroid/Flutter-learning/
5.开源免费的。你可以随意修改内核引擎代码，以及组件代码，定制化的开发，比如闲鱼，腾讯，字节跳动等大厂都基于Flutter进行针对他们的App开发做了定制化的整合方案，当然你要是感兴趣的话，你也可以这么做。

• 【缺点：】

如果不熟悉原生开发，第三方包满足不了你的需求的时候，那么就需要你自己去写或修改已有的插件，这个需要学习一点原生开发的知识（其实这也是很多跨平台技术必不可少的步骤），当然如果你们公司有android或ios的程序员，可以让他们协助写一个插件，这对于他们来说都是小问题。

最近我们用uni-app开发了一款产品，目前ios已上，安卓各应用市场还在审核中。

接触uni-app的时间大概也就一年多，今年开始了一个app的项目，我作为技术负责人，在前端最终选了uni-app，先说一下为什么选它，这也算是uni-app比较大的优势：

1.学习成本低。只要懂vue，或者小程序，配合官方文档和插件市场的一些示例项目，这个框架上手很快，不需要环境配置、webpack之类的一堆事，hbuilderX的提示功能也还不错，基本上可以当作一个vue项目来写。

2.开发成本低。一开始我们也想做原生开发，但是吧，一个二线城市，金主自掏腰包，自然在预算上就不充足，相应的高水平开发人员也就不好找，肯定也不能维持ios、android两个组同时开发，所以跨端框架是我们的最优先选择。

3.社区还算活跃。在插件市场上有很多第三方组织和个人开发者维护插件，还有一些可支持完整项目的组件库，都挺不错。

4.一个产品初期肯定要满足快速开发，快速迭代的需求。不太了解原生开发，目前来看，用uni-app改需求的效率还可以。

所以我个人的看法是，uni-app是个不错的框架，尤其是对一些小公司、小项目，在初期需要进行产品验证、演示，需要快速迭代，完善业务逻辑的环节，是个非常不错的选择，简单、易上手、跨端表现优秀。

目前来看，我们业务刚起步，uni-app算是提供了一个很不错的框架，让我们在比较短的时间内完成了一款app（2前1后[1老2新]，4月开始，7月中基本完成）。由于对框架的一些方面研究不深，经验尚浅，所以优化的空间还挺大，感觉在未来一年之中，它还能支撑我们的业务走挺长一段时间。

接下来说说uni-app的一些让我感觉不爽的地方：

1.如果只是一个演示或demo性质的产品，uni-app还不错。但如果想做一款比较正式的产品，那么对性能什么的必须有要求，这时，单纯的vue就不能满足了，你需要了解weex/nvue，BindingX，原生开发，对于很多新手或没接触过的人来说，很蒙，需要花一些时间来熟悉这些。

2.我们的app在ios下表现还不错，基本没有一些比较怪异的问题，在android下就完蛋了，比如华为下元素闪烁（android8/9没问题，android10有问题），小米下列表不能滚动，阴影问题无法解决，等等，这些应该是系统的问题，不是uni-app的问题，还有各种屏幕类型带来的问题，只安卓一端就一堆问题，要是用它跨多端，我得原地爆炸。

3.uni-app的官方文档与小程序的文档有大量类似，其中穿插了uni-app的内容，文档写的不行，找点东西挺费劲的，这时就要赞一下vue的文档了。官方对社区的一些问题反应比较慢。

再回答一下题主的问题，为啥没有讨论？

小项目项目前期用了uni-app，后来项目没成（参照创业成功率），自然就没心思讨论

最后吐槽一下小米应用商城，拒绝我们的理由是“有相同或类似应用”，那个相似的app我也看了，一个挂羊头卖狗肉的app，小米真垃圾！

用uni-app开发了一个APP以及一个开源IM项目，总体来说，一次编译到包括H5/小程序/APP的体验还是不错的。但是小问题太多。

对比其他各框架，比如weex/react native，只能开发APP，与小程序和H5并不通用。此外Taro，使用react开发小程序，但是对RN支持度就很低了。还有一些mpvue之类的，支持度就更低了，所以要想一次性包含三端，几乎只有uni-app可选。

uni-app看似完美，小问题确实太多：

1、自研IDE – Hbuilder X，对比vscode以及webstorm，很难看到Hbuilder X的优势在哪里。而且编译uni-app还非得使用Hbuilder X，当然你可以使用离线编译，但是离线编译版本跟不上Hbuilder X，并且里面的坑巨多。投入大量人力来开发Hbuilder X，反而分散了大量精力，无法深入研发uni-app。

2、发版问题，之前我就在官方群里吐槽过uni-app发版随意，修复过的bug反复出现在更新版本中，简直是没经过测试就发布新版本，结果……我就被禁言了。此类问题并非黑uni-app，随便在论坛一搜一大把。

3、nvue，官方开发了一个nvue来支持weex，本意是为了提高性能，但是nvue居然不支持typescript，这意味着在被这个nvue页面引用的所有文件你都不能用typescript。那么开发者会面临一个问题是放弃使用nvue还是放弃使用typescript呢，这就很头痛了。

整体来说，uni-app思路还是不错的，就是小问题有点多，如果在线上使用了uni-app，那么你得谨慎升级，避免线上莫名其妙出现BUG，人在家中坐，BUG天上来。

一、想让人讨论是需要金钱投入宣传的

比如每年开一次 conf，比如专人对接某公司的需求，或者你已经有一些业界名气别人愿意给你一个面子试一试。

二、想让人使用时需要人力财力支撑的

Google 和 Facebook 的技术实力摆在这，而 uniapp 是否能解决用户提出来的大部分问题还值得商榷，比如我最近想做一款有视频缓存功能的 app，稍微搜了一下 uniapp 相关的讨论，我就觉得不能用 uniapp：

video组件与视频缓存问题 – DCloud问答【报Bug】stop（）方法停止或暂停后，zo造成 poster 没有取到， 当前页面onHide之后再onShow 或者appHide 再appShow video封面黑屏video 终于要迎来大改了吗?

长期维护这么大一个项目，是需要成吨的人力和财力投入的。我不确定 uniapp 背后的团队是否有这个实力。

三、生态问题

纯中文的项目相当于放弃了所有英文开发者，这一点就会使得生态做不大……所以我还是看看其他方案（Flutter 或 React Native）吧，虽然其他方案问题也不少，但是遇到相同问题的开发者会多很多。

本人典型的吃饭砸锅，希望uniapp越来越好，也真的觉得官方好讨厌，好不务正业，是真的不会考虑开发者的看法，固执己见，一切为了他们所谓的开发效率，你搞个ai开发不更提高开发效率？抬杠谁不会，都是个取舍，别说你们做的就能更多的提高开发效率，你好好修复uniapp的bug，修一个bug，开发者们就少用几个小时去解决问题，这不是在提高开发效率？

动不动就给你来句一切向开发效率妥协，问题是除了uniapp其他的东西你提高毛线开发效率了啊，

1. hbuilder官方自认好用，胜webstorm，你能顶他百分之50，我就觉得你做的有意义，啥也不是，多看看评论区，github的issues里用户怎么说吧，老说自己用户多，比webstorm多，也不知道你咋统计的，你统计有多少人是一个月用一次，打包才用一次，或者迫不得已才用的了吗，自己骗自己好玩吗
2. uni_cloud，uni_modules，集成后端能力插件，提供免费数据库，不用写后端代码，js梭哈

免费的数据库，外部无法使用正常方式访问，用了他的数据库就必须用他的cloud，不兼容其他后端代码，其他后端代码想要调用数据库内容，可以是可以，反正比正常后端应用访问数据库是难多了，别人要访问你的接口，一定要提前配置允许的ip啥的，开放接口这种需求肯定是不支持的了。

可能跟经历有关，我不知道谁家数据库里的数据是只有一个应用使用的，乱七八糟的后端那些东西肯定是都不支持。

就目前这种情况，你作为一个附加功能来说，是不错的，可非要作为一个对标后端的功能来说，就垃圾的要死了。

本人经历有限，所以就我看来，没几个正经公司会用uni_cloud的去上生产，也就是搞个小demo级别的项目，这玩意想限制一大堆，谁敢用。

自己接触的公司，项目，也还都是在用标准的后端，没几个用这玩意的，不是说不好，是还不完善，没到强推的阶段，就跟50年前你非要强推下线自动驾驶汽车一样，撞死一堆人。

这东西可能也就萌新感兴趣，接触接触，可真正的萌新有多少人，大部分还是搞了几年开发，上了几年班的打工人，谁公司没几个后端，谁不懂点后端。就感觉官方意淫出来一个小需求，就自己高潮了，嗨皮了两年了，有效果么，有数据吗，欢迎贴个数据打脸，劝浪子回头，迷途知返，别越陷越深，你越高越好我拦不住你，你搞了半天没效果，还不知道反省吗

啥都要自己搞一套，你有那么多员工吗，人的精力有限，专注做好一件事，做精湛不好吗，啥都要搞，啥也搞不好，气死，uniapp给我带来了很多好处，但官方不务正业也让人好难受，就发泄发泄

真心希望dcloud能专注，跨端编译这件事，少搞些乱七八糟的绑定，什么编辑器、uni_modules,uni_cloud全都绑定他家全家桶，只能用他家的。

信仰技术的，不都应该喜欢开放自有，拥抱开放的生态么，什么都要自己搞一套，又不跟别人相同，难用的要死，