混合app开发框架uniapp（混合型app开发框架）
今天给各位分享混合app开发框架uniapp的知识，其中也会对混合型app开发框架进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！
本文目录一览：
- 1、混合开发之uni-app
- 2、uniapp是未来的趋势吗？
- 3、做混合的话Uniapp和Flutter我应该学哪个啊？
- 4、uniapp页签栏特点
- 5、目前编写一款简单的手机应用APP一般用什么编程语言？
- 6、怎样评价uni-app？
混合开发之uni-app
uni-app App端内置weex渲染引擎，提供原生渲染能力
然而， Weex并不是一个前端框架 。实际上，前端框架仅仅是 Weex 的语法层或称之为 DSL (Domain-specific Language)，它们与原生渲染引擎是分离的。换句话说，Weex 并不依赖于特定的前端框架，随着前端技术的发展，Weex 也可以集成更多广泛使用的前端框架。
以往的 weex ，有个很大的问题是它只是一个高性能的渲染器，没有足够的API能力，使得开发时非常依赖原生工程师协作，开发者本来想节约成本，结果需要前端、iOS、Android 3拨人开发，适得其反。而 nvue 解决了这个大问题，让前端工程师可以直接开发完整 App，并提供原生插件的市场交易和云打包。这些组合方案，开发者切实的提高效率、降低成本。
如果你是web前端，不熟悉 weex，那么建议你仍然以使用 vue 为主，在App端某些 vue 表现不佳的场景下使用 nvue 作为强化补充：
uni-app App 端内置 HTML5+ 引擎，让 js 可以直接调用丰富的原生能力。
小程序及 H5 等平台是没有 HTML5+ 扩展规范的，因此在 uni-app 调用 HTML5+ 的扩展规范时，需要注意使用条件编译。否则运行到h5、小程序等平台会出现 plus is not defined错误。
在普通的 H5+ 项目中，需要使用 document.addEventListener 监听原生扩展的事件。
uni-app 中，没有 document。可以使用 plus.globalEvent.addEventListener 来实现（注意manifest中需开启新编译器，即自定义组件模式"usingComponents":true）。
同理，在 uni-app 中使用 Native.js 时，一些 Native.js 中对于原生事件的监听同样需要按照上面的方法去实现。
注意：旧编译器（非自定义组件模式）不支持 plus.globalEvent 这个对象。
uniapp是未来的趋势吗？
未来太遥远，不想这么多，技术栈几年一换才是常态。目前很多应用开发者在尝试使用uni-app，可以尝试一下，多学一点多一个技术选择不是坏事。
想学一个长久可用的技术，在IT界特别是中国，并不太现实。如果选择了前端，那情况只怕是更糟。
uniapp是未来趋势？NO！NO！
说uniapp成为趋势感觉有点好笑。
不懂行的可能不了解，我就换个说法。
我可以说手机行业小米手机会成为未来的趋势吗？
你认为可能性多大？当然不可否认小米很优秀了，当然实话实说，这也是相对的。想变成趋势可谓有点夜郎自大。
uniapp是什么？简单点说说吧
一个基于vue的跨平台开发的框架，有了它你可以写一套代码打包成安卓、苹果安装包，还可以导出各种小程序，还可以导出h5…，反正功能很强大。
它的出现，只要你懂点前端，只要你会点vue，OK那你就可以开发APP了。
厉害不厉害？可以说在某种程度上确实很牛逼，很方便，特别又是国产，文档、demo之类的很多。
平台又出有云服务，支付，广告等各种插件。小白上手也很快。所以一时圈了很粉，社区还算凑合吧。
uniapp之所以被越来越多的人需要，不得不说下跨平台。
APP开发跨平台确实是个刚需，也是一个真正的趋势。毕竟纯原生开发一个APP太复杂了，成本也高。有些APP根本不需要关心所谓的性能、流畅度之类的。所以跨平台，一套代码完全搞定，可谓是个不错的选择。
但是跨平台可选性的技术方案太多，与uniapp直接相对的，apicloud，在国产圈也是拉了不少粉。
此外rn，lonic，cordova，weex等之类的前辈仍然具有一定的地位，还有新起来flutter也是火的不得了。
所以uniapp只能说在小范围内可以说很好，但是和那些成熟，风靡海内外的技术框架还是有差距的。
uniapp真的好用吗？
首先，我感觉它越来越废了。有时真是感觉积累！
开发APP就专业开发APP吧，你还搞的适配一堆小程序，所以造成越来越臃肿。文档杂乱。
有时，选择你，我就是想仅仅开发APP。压根不要小程序！
所以，特别是新手，因此会有一定的烦恼。
另一个 值得 吐槽的就是不太稳定！
架构经常换，而且之前的很难兼容！
为此估计不少人想骂人。特别那些已经有了成熟运营的APP。
再次升级的话，不好意思，很多东西重写吧。
从当初非自定义组件、自定义组件，再到今天的v3架构。可谓一步一个坑，真的严重依赖它的话，真的花费大精力去踩坑了。
当然一般的开发拿来用用还是不错的
我司项目开始用的h5+那一套，也用uniapp做过几个项目。反正要求不是很高，效果感觉还可以。
真的真的去完全适配安卓，苹果的话，要做的还是有很多。
OK，就这了。技术本身无所谓好坏，只有适合不适合。
有时基于时间、项目成本、人员技术水平，只要合适就是最好的。
uniapp也一样，希望它快快成长，快快稳定，完善吧！
uniapp目前确实很火，暂且不说uniapp这种框架是不是未来的趋势，但大前端绝对是未来的趋势。
在计算机编程领域，前端近几年的技术更新速度达到了顶峰。
这并不是得益于前端的语言优势，而是开放繁荣的生态。
uniapp这类框架正是前端进军移动互联网的利刃。
移动互联网过时了吗？不，移动互联网正在以新的形态进军PC。
所以，未来几年uniapp这类框架还会繁荣，而前端慢慢融合，PC与移动的前端界限越来越模糊。
serverless是趋势，unicloud正好整合了阿里云与腾讯云！
最重要的是unicloud开始标准化，uni-id ,unicloud-admin就是苗头！
听从开发者建议且更新频繁的框架！两年左右完善度已经非常高！
现在他们需要做的功能太多，所以一些细节性并未完善，一旦稳定下来，他们能把一些细节做好，这个框架与开发者工具绝对不容小嘘！
免费的服务器，免费的框架，对于初创团队，或者个人创业者，有想法的开发者，可以省大多成本！
自己独立完成的项目(超级档案)已上架小米，华为，苹果应用商店，同时，各大平台小程序也全部上架！
不是。h5类的优势在于开发简单，周期短，一套代码跑多端。适合初创快速迭代。任何一个成熟的产品在达到一定规模后，都会回归原生，或者混合。这是性能，用户体验，安全等多方面因素决定的。这也是有了rn后，为什么还会有flutter出现的原因。
何为趋势？在互联网高速发达的时代，物竞天择的规律同样适用，这个开发平台的主要目的就是解决了多平台重复，跨平台生态不好，开发和使用用户体验不好的问题，真正做到了一套代码全平台适用，一劳永逸，同时还不影响平台特色，随着整个业内开发者的用户数越来越多，势必会取代不合时宜的开发平台。从目前的使用广度和应用产品的市场反馈来看，它是具备这个能力的。
uniapp还是很多人用的，尤其在现在这个时间，用来开发小程序还是不错的
如果没有意外的话，他还会保持现状很长时间
对于小型项目或者交互要求不高的项目来说，基本是够用的，这种项目又普遍对成本或者开发效率非常敏感，在这点做的比uniapp好的确实不多，所以他的用户群会非常稳定
至于感觉上没人讨论的原因也很简单
一是有影响力的开发人员几乎不可能是uniapp的用户，uniapp的用户多数也提不出值得讨论的内容
二是这东西真没什么可讨论的，上限实在不高
uniapp目前在国内的生态很好，因为大前端是趋势，是uniapp在未来一段时间内还是很火的，个人认为如果创业阶段如果没有原生客户端工程师，只有web团队，uniapp非常适合
目前来说uniapp是 一款很好的开发小程序的编码工具，
优点有
一：简单易学，学习成本低。
二:可以跨多个平台，制作一套代码可以在多个平台发布
三：运行比较流畅，运行体验更好，兼容weex,组件·api和微信小程序一致
综合以上几点来看uniapp前景不错。
目前确实有这个趋势。用uniapp开发了一款app，叫小 时尚 ，目前已经在各大应用商店上线。
做混合的话Uniapp和Flutter我应该学哪个啊？
本文由阿里闲鱼技术团队祈晴分享，本次有修订和改动，感谢作者的技术分享。
1、内容概述
本文总结了阿里闲鱼技术团队使用Flutter在对闲鱼IM进行移动端跨端改造过程中的技术实践等，文中对比了传统Native与现在大热的Flutter跨端方案在一些主要技术实现上的差异，以及针对Flutter技术特点的具体技术实现，值得同样准备使用Flutter开发IM的技术同行们借鉴和参考。
学习交流：
- 移动端IM开发入门文章：《新手入门一篇就够：从零开发移动端IM》
- 开源IM框架源码：
（本文同步发布于：）
2、闲鱼IM现状
闲鱼IM的移动端框架构建于2016至2017年间，期间经过多次迭代升级导致历史包袱累积多，后面又经历IM界面的Flutter化，从而造成了客户端架构愈加复杂。
从开发层面总结闲鱼IM移动端当前架构主要存在如下几个问题：
1）研发效率较低：当前架构涉及到Android/iOS双端的逻辑代码以及Flutter的UI代码，定位问题往往只能从Flutter UI表相倒查到Native逻辑层；
2）架构层次较差：架构设计上分层不清晰，业务逻辑夹杂在核心的逻辑层致使代码变更风险大；
3）性能测试略差：核心数据源存储Native内存，需经Flutter Plugin将数据源序列化上抛Flutter侧，在大批量数据源情况下性能表现较差。
从产品层面总结闲鱼IM移动端当前架构的主要问题如下：
1）定位问题困难：线上舆情反馈千奇百怪，测试始终无法复现相关场景，因此很多时候只能靠现象猜测本质；
2）疑难杂症较多：架构的不稳定性造成出现的问题反复出现，当前疑难杂症主要包括未读红点计数、iPhone5C低端机以及多媒体发送等多个问题；
3）问题差异性大：Android和iOS两端逻辑代码差异大，包括埋点逻辑都不尽相同，排查问题根源时双端都会有不同根因，解决方案也不相同。
3、业界的移动端跨端方案
为解决当前IM的技术痛点，闲鱼今年特起关于IM架构升级项目，重在解决客户端中Andriod和iOS双端一致性的痛点，初步设想方案就是实现跨端统一的Android/iOS逻辑架构。
在当前行业内跨端方案可初步归类如下图架构：
在GUI层面的跨端方案有Weex、ReactNative、H5、Uni-APP等，其内存模型大多需要通过桥接到Native模式存储。
在逻辑层面的跨端方案大致有C/C++等与虚拟机无关语言实现跨端，当然汇编语言也可行。
此外有两个独立于上述体系之外的架构就是Flutter和KMM（谷歌基于Kotlin实现类似Flutter架构），其中Flutter运行特定DartVM，将内存数据挂载其自身的isolate中。
考虑闲鱼是Flutter的前沿探索者，方案上优先使用Flutter。然而Flutter的isolate更像一个进程的概念（底层实现非使用进程模式），相比Android，同一进程场景中，Android的Dalvik虚拟机多个线程运行共享一个内存Heap，而DartVM的Isolate运行隔离各自的Heap，因而isolate之间通讯方式比较繁琐（需经过序列化反序列化过程）。
整个模型如下图所示：
若按官方混合架构实现Flutter应用，开启多个FlutterAcitivty/FlutterController，底层会生成多个Engine，对应会存在多个isolate，而isolate通讯类似于进程通讯（类似socket或AIDL），这里借鉴闲鱼FlutterBoost的设计理念，FlutterIM架构将多个页面的Engine共享，则内存模型就天然支持共享读取。
原理图如下：
4、闲鱼IM基于Flutter的架构设计
4.1 新老架构对比
如下图所示：是一个老架构方案，其核心问题主要集中于Native逻辑抽象差，其中逻辑层面还设计到多线程并发使得问题倍增，Android/iOS/Flutter交互繁杂，开发维护成本高，核心层耦合较为严重，无插拔式概念.
考虑到历史架构的问题，演进如下新架构设计：
如上图所示，架构从上至下依次为：
1）业务层；
2）分发层；
3）逻辑层；
4）数据源层。
数据源层来源于推送或网络请求，其封装于Native层，通过Flutter插件将消息协议数据上抛到Flutter侧的核心逻辑层，处理完成后变成Flutter DB的Enitity实体，实体中挂载一些消息协议实体。
核心逻辑层将繁杂数据扁平化打包挂载到分发层中的会话内存模型数据或消息内存模型数据，最后通过观察者模式的订阅分发到业务逻辑中。
Flutter IM重点集中改造逻辑层和分发层，将IM核心逻辑和业务层面数据模型进行封装隔离，核心逻辑层和数据库交互后将数据封装到分发层的moduleData中，通过订阅方式分发到业务层数据模型中。
此外在IM模型中DB也是重点依赖的，个人对DB数据库管理进行全面封装解，实现一种轻量级，性能佳的Flutter DB管理框架。
4.2 DB存储模型
Flutter IM架构的DB存储依赖数据库插件，目前主流插件是Sqflite。
其存储模型如下：
依据上图Sqflite插件的DB存储模型会有2个等待队列：
一个是Flutter层同步执行队列；
一个是Native层的线程执行队列。
其Android实现机制是HandlerThread，因此Query/Save读写在会同一线程队列中，导致响应速度慢，容易造成DB SQL堆积，此外缺失缓存模型。
于是个人定制如下改进方案：
Flutter侧通过表的主键设计查询时候会优先从Entity Cache层去获取，若缓存不存在，则通过Sqflite插件查询。
同时改造Sqflite插件成支持sync/Async同步异步两种方式操作，对应到Native侧也会有同步线程队列和异步线程队列，保证数据吞吐率。但是这里建议查询使用异步，存储使用同步更稳妥，主要怕出现多个相同的数据元model同一时间进入异步线程池中，存储先后顺序无法有效的保证。
4.3 ORM数据库方案
IM架构重度依赖DB数据库，而当前业界还没有一个完备的数据库ORM管理方案，参考了Android的OrmLite/GreenDao，个人自行设计一套Flutter ORM数据库管理方案。
其核心思想如下：
由于Flutter不支持反射，因此无法直接像Android的开源数据库方式操作，但可通过APT方式，将Entity和Orm Entity绑定于一身，操作OrmEntity即操作Entity，整个代码风格设计也和OrmLite极其相似。
参考代码如下：
4.4 IM内存数据模型
基于Flutter的IM移动端架构在内存数据模型主要划分为会话和消息两个颗粒度：
1）会话内存数据模型交托于SessionModuleData：会话内存数据有一个根节点RootNotice，然后其挂载PSessionMessageNotice（这里PSessionMessageNotice是ORM映射的会话DB表模型）子节点集合。
2）消息内存数据模型交托于MessageModuleData：消息内存数据会有一个MessageConatiner容器管理，其内部挂载此会话中的PMessage(PMessage是ORM映射的消息DB表模型)消息集合。
依据上一章节，PSessionMessageNotice设计了一个OrmEnitity Cache，考虑到IM中会话数是有限的，因此PSessionMessageNotice都是直接缓存到Cache中。
这种做法的好处是各地去拿会话数据元时候都是缓存中同一个对象，容易保证多次重复读写的数据一致性。而PSessionMessageNotice考虑到其数量可以无限多的特殊性，因此这里将其挂载到MessageContainer的内存管理中，在退出会话的时机会校验容器中PMessage集合的数量，适当缩容可以减少内存开销。
模型如下图所示：
4.5 状态管理方案
基于Flutter的IM移动端架构状态管理方案比较简单，对数据源Session/Message维度使用观察者模式的订阅分发方式实现，架构类似于EventBus模式，页面级的状态管理无论使用fish-redux、scopeModel或者provider几乎影响面不大，核心还是需保留一种插拔式抽象更重要。
架构如下图：
4.6 IM同步模型方案
当前现状的消息同步模型：
如上图所示是，模型中存在ACCS Thread/Main Thread/Region Thread等多线程并发场景，导致易出现多线程高并发的问题。
native的推送和网络请求同步的隔离方案通过Lock的锁机制，并且通过队列降频等方式处理，流程繁琐且易出错。整体通过Region Version Gap去判断是否有域空洞，进而执行域同步补充数据。
改进的同步模型如下：
如上图所示，在Flutter侧天然没多线程场景，通过一种标记位的转化同步异步实现类似Handler消息队列，架构清晰简约了很多，避免锁带来的开销以及同步问题。
5、本次改造进展以及性能对比
1）针对架构层面：
在基于Flutter的IM架构中，重点将双端逻辑差异性统一成同一份Dart代码，完全磨平Android/iOS的代码差异性带来的问题。
带来的好处很明显：
1）降低开发维护、测试回归、视觉验收的一半成本，极大提高研发效率；
2）架构上进行重构分层，实现一种解耦合，插拔式的IM架构；
3）同时Native到Flutter侧的大量数据上抛序列化过程改造程Flutter引用传递，解决极限测试场景下的私聊卡顿问题。
2）针对线上舆情：
1）补齐UT和TLog的集团日志方式做到可追踪，可排查；
2）针对于很多现存的疑难杂症重点集中专项解决，比如iphone5C的架构在Flutter侧统一规划；
3）未读红点计数等问题也在架构模型升级中修复；
4）此外多媒体音视频发送模块进行改造升级。
3）性能数据对比：
当IM架构的逻辑层和UI层都切换成Flutter后，和原先架构模式初步对比，整体内存水位持平。
其中：
1）私聊场景下小米9测试结构内存下降40M，功耗降低4mah，CPU降低1%；
2）极限测试场景下新架构内存数据相比于旧架构有一个较为明显的改观（主要由于两个界面都使用Flutter场景下，页面切换的开销降低很多）。
6、未来展望
JS跨端不安全，C++跨端成本有点高，Flutter会是一个较好选择。彼时闲鱼FlutterIM架构升级根本目的从来不是因Flutter而Flutter，是由于历史包袱的繁重，代码层面的维护成本高，新业务的扩展性差，人力配比不协调以及疑难杂症的舆情持续反馈等等因素造成我们不得不去探索新方案。
经过闲鱼IM超复杂业务场景验证Flutter模式的逻辑跨端可行性，闲鱼在Flutter路上会一直保持前沿探索，最后能反馈到生态圈。
总结一句话，探索过程在于你勇于迈出第一步，后面才会不断惊喜发现。
（原文链接：点此进入，本次有修订和改动）
附录：更多文章汇总
[1] 更多阿里团队的文章分享：
《阿里钉钉技术分享：企业级IM王者——钉钉在后端架构上的过人之处》
《现代IM系统中聊天消息的同步和存储方案探讨》
《阿里技术分享：深度揭秘阿里数据库技术方案的10年变迁史》
《阿里技术分享：阿里自研金融级数据库OceanBase的艰辛成长之路》
《来自阿里OpenIM：打造安全可靠即时通讯服务的技术实践分享》
《钉钉——基于IM技术的新一代企业OA平台的技术挑战(视频+PPT) [附件下载]》
《阿里技术结晶：《阿里巴巴Java开发手册(规约)-华山版》[附件下载]》
《重磅发布：《阿里巴巴Android开发手册(规约)》[附件下载]》
《作者谈《阿里巴巴Java开发手册(规约)》背后的故事》
《《阿里巴巴Android开发手册(规约)》背后的故事》
《干了这碗鸡汤：从理发店小弟到阿里P10技术大牛》
《揭秘阿里、腾讯、华为、百度的职级和薪酬体系》
《淘宝技术分享：手淘亿级移动端接入层网关的技术演进之路》
《难得干货，揭秘支付宝的2维码扫码技术优化实践之路》
《淘宝直播技术干货：高清、低延时的实时视频直播技术解密》
《阿里技术分享：电商IM消息平台，在群聊、直播场景下的技术实践》
《阿里技术分享：闲鱼IM基于Flutter的移动端跨端改造实践》
[2] 更多IM开发综合文章：
《新手入门一篇就够：从零开发移动端IM》
《移动端IM开发者必读(一)：通俗易懂，理解移动网络的“弱”和“慢”》
《移动端IM开发者必读(二)：史上最全移动弱网络优化方法总结》
《从客户端的角度来谈谈移动端IM的消息可靠性和送达机制》
《现代移动端网络短连接的优化手段总结：请求速度、弱网适应、安全保障》
《移动端IM中大规模群消息的推送如何保证效率、实时性？》
《移动端IM开发需要面对的技术问题》
《开发IM是自己设计协议用字节流好还是字符流好？》
《IM消息送达保证机制实现(一)：保证在线实时消息的可靠投递》
《IM消息送达保证机制实现(二)：保证离线消息的可靠投递》
《如何保证IM实时消息的“时序性”与“一致性”？》
《一个低成本确保IM消息时序的方法探讨》
《IM单聊和群聊中的在线状态同步应该用“推”还是“拉”？》
《IM群聊消息如此复杂，如何保证不丢不重？》
《谈谈移动端 IM 开发中登录请求的优化》
《移动端IM登录时拉取数据如何作到省流量？》
《浅谈移动端IM的多点登录和消息漫游原理》
《完全自已开发的IM该如何设计“失败重试”机制？》
《通俗易懂：基于集群的移动端IM接入层负载均衡方案分享》
《微信对网络影响的技术试验及分析（论文全文）》
《开源IM工程“蘑菇街TeamTalk”的现状：一场有始无终的开源秀》
《如约而至：微信自用的移动端IM网络层跨平台组件库Mars已正式开源》
《子弹短信光鲜的背后：网易云信首席架构师分享亿级IM平台的技术实践》
《微信技术分享：微信的海量IM聊天消息序列号生成实践（算法原理篇）》
《自已开发IM有那么难吗？手把手教你自撸一个Andriod版简易IM (有源码)》
《融云技术分享：解密融云IM产品的聊天消息ID生成策略》
《IM开发基础知识补课(六)：数据库用NoSQL还是SQL？读这篇就够了！》
《适合新手：从零开发一个IM服务端（基于Netty，有完整源码）》
《拿起键盘就是干：跟我一起徒手开发一套分布式IM系统》
《适合新手：手把手教你用Go快速搭建高性能、可扩展的IM系统(有源码)》
《IM里“附近的人”功能实现原理是什么？如何高效率地实现它？》
《IM“扫一扫”功能很好做？看看微信“扫一扫识物”的完整技术实现》
《IM消息ID技术专题(一)：微信的海量IM聊天消息序列号生成实践（算法原理篇）》
《IM消息ID技术专题(二)：微信的海量IM聊天消息序列号生成实践（容灾方案篇）》
《IM消息ID技术专题(三)：解密融云IM产品的聊天消息ID生成策略》
《IM消息ID技术专题(四)：深度解密美团的分布式ID生成算法》
《IM消息ID技术专题(五)：开源分布式ID生成器UidGenerator的技术实现》
《IM消息ID技术专题(六)：深度解密滴滴的高性能ID生成器(Tinyid)》
《IM开发宝典：史上最全，微信各种功能参数和逻辑规则资料汇总》
《IM开发干货分享：我是如何解决大量离线消息导致客户端卡顿的》
《零基础IM开发入门(一)：什么是IM系统？》
《零基础IM开发入门(二)：什么是IM系统的实时性？》
《零基础IM开发入门(三)：什么是IM系统的可靠性？》
《零基础IM开发入门(四)：什么是IM系统的消息时序一致性？》
《IM开发干货分享：如何优雅的实现大量离线消息的可靠投递》
《IM开发干货分享：有赞移动端IM的组件化SDK架构设计实践》
《一套亿级用户的IM架构技术干货(下篇)：可靠性、有序性、弱网优化等》
《IM扫码登录技术专题(一)：微信的扫码登录功能技术原理调试分析》
《IM扫码登录技术专题(二)：市面主流的扫码登录技术原理调试分析》
《IM扫码登录技术专题(三)：通俗易懂，IM扫码登录功能详细原理一篇就够》
《理解IM消息“可靠性”和“一致性”问题，以及解决方案探讨》
《阿里技术分享：闲鱼IM基于Flutter的移动端跨端改造实践》
更多同类文章 ……
本文已同步发布于“即时通讯技术圈”公众号。
同步发布链接是：
uniapp页签栏特点
特点如下，ni-app是一种近年新兴的一种多端混合开发框架，在国内已经有越来越多的工程师选择在uni-app的平台进行开发。
拓展性强 Uni-app支持nvue,封装了H5+。同时,还支持原生的iOS和安卓开发
目前编写一款简单的手机应用APP一般用什么编程语言？
编写手机App，用什么语言？
从简单到复杂，可以分三级：
简单方案：HTML5
其实就是把网页封装成App。编程语言就是网页三件套：HTML+CSS+Javascript
有多种工具和框架，如Cordova, uni等等。
这种方式实现“App”最容易，且跨平台，对于iOS和Android做一套就行了。代价是功能弱，性能低，换句话说就是“卡”。
中等方案：原生跨平台框架
这类方案在iOS和Android之上自行实现一套原生框架。通用的Flutter, ReactNative都是流行的原生跨平台框架。适用于 游戏 的Cocos2D，Corona SDK也可以算在这一级里。
这类方案实现App难度中等，因为跨平台，一次开发，iOS和Android都能运行。功能和性能也是中等，比不上原生App，但比HTML5的又好很多。
复杂方案：原生开发
直接在iOS和Android上各自开发一套原生App。
iOS可以使用Objective C或Swift。
Android可以使用Java或Kotlin。
还是来一个图表吧，虽然简单，却很明了：
推荐用Flutter，简单。
以前自己用android原生写过7天酒店签到程序，不过当时的安卓还是比较难写的，不像现在越来越容易上手。
Flutter
Flutter是一个由谷歌开发的开源移动应用软件开发工具包，用于为Android、iOS、 Windows、Mac、Linux、Google Fuchsia开发应用。
Flutter应用是使用Dart语言编写的，虽然是新的一种语言，但是难度不算大，上网搜下相关教程学习下，应该就能很快上手。
Flutter效果
这里是我上个月仿照教程弄的一个简单APP，效果图如下：
点击"Next"就切换下一张，点击"Pre"就切换前一张，点击“Reset”就全部滑落下来。
我女儿最喜欢中间的Reset效果，哈哈。
希望这个答案能帮到你。
现在Flutter正式版已经出来了，原生性能，安卓iOS多平台支持，谷歌大厂背书，大家可以比较放心的学习。编程语言用的是Dart，可以看做是加了语法糖版本的Java，学习起来也比较容易，如果想做手机app，可以考虑使用它。
如果只是自己做着玩的话推荐用H5开发，开发工具HBuilder或者HBuilderX。
先科普下什么是IOS和Android吧。
IOS只是操作系统而已，是苹果的操作系统。
开发IOS上运行的APP的话，现在流行的语言是Object-C和Swift。
Android也是操作系统，是谷歌基于Linux内核开发出来的手机操作系统。
开发Android上运行的APP的话，现在流行的语言我觉得仍然还是JAVA。
如果想要真的做一款APP的话，不仅仅会一门语言就够了，涉及的东西比较多，如下是我给你的学习推荐路线。
学习路线：
1：先学习js，然后学习下html 、css。
学习这些可以上菜鸟教程或者W3School网站学习。
开发工具使用vscode或者Notepad++都可以的。
2：了解Mui常用组件（官网：），
熟悉常用API(官网：)。
3：服务端的开发，要么用java开发，要么用.net webapi开发，推荐理由，java目前是主流，.net webapi简单容易。
java 开发工具IntelliJ IDEA，.net 开发工具 vs。
4：数据存储使用mysql。
补充说明：如果是想做专业开发APP的话还是建议用java开发客户端，ios APP则用swift开发。
当然现在为了一套代码多个平台，使用H5开发专业APP的也有。
会了就可以正式撸代码实现自己简单的APP了。
回答完毕，谢谢。我是只说代码的大饼。
那当然首选是h5套壳了。关于语言方面，我建议还是用PHP吧。随着进一步学习，可以学习uinapp一键多端。H5、小程序、App、小程序支持多个平台上架、微信抖音支付宝百度，希望可以帮助你
目前有三种app开发方式：原生app、混合app、webapp。
原生app：安卓需要java语言，ios需要 objec t-c，wp需要的.net语言。这种app用户体验最好，性能也是最好的，开发成本高，开发周期长，一款app需要开发多个语言版本；
混合app：需要h5，javascript，了解每个混合框架，比如appcan、hbulider、phonegap等等，以及封装的中间件。这种开发方式的用户体验、性能没有原生的好，但是他的开发周期短，开发成本低，对开发人员技能掌握比较高，开发一套程序可以兼容到多个设备上；
webapp：需要h5、javascript语言，不能调用底层设备，用户体验效果次之，开发简单，开发成本低，开发周期短，可以兼容多个设备。
综上所述三种开发各有优缺点，要根据具体的项目需求来选择适合自己的开发语言和开发场景。
uniapp了解下，多端应用。app的话要考虑安卓和苹果，但学了二种学习成本比较高。用uniapp就解决了。
现在中小型企业都在逐渐采用跨平台开发的模式 效率高 成本低 作为个人更是开发不二的选择 你问的iOS和安卓是原生开发 需要不同的开发语言和框架 学习成本也很高 既然你说你是小白 如果采用原生开发 可能得大概花一年半载才能开始上手
采用跨平台开发 只需要学习一下html css JavaScript 然后选择跨平台开发框架 比如react flutter uniapp 都可以 跨平台就是指你这一套代码编写的app可以到不同平台运行 比如iOS安卓都OK 但其实很多还可以编译到各类小程序平台运行 所以很方便
我这里推荐uniapp 一个基于vue的跨端开发框架 我自己也用这个开发了很多项目 确实很快 也提供了原生渲染能力 不做 游戏 等软件 基本没啥问题 社区插件市场也很热闹 基本有问题可以很快解决 希望可以帮到你。
按照开发方式可分为原生开发、混合开发、webapp开发，不同的开发方式学习的编程语言不一样，下面我们来一个一个分析一下：
一、原生开发
原生开发的编程语言主要为针对IOS运行环境的为编程语言为Swift或Object c，安卓环境为Java或Kotlin，WP环境为NET。原生开发的运行效率最高，用户体验最好，但是需要学习不同平台的编程语言，学习门槛较高。
二、混合开发（伪原生开发）
混合开发技术主要采用一套特别的渲染引擎来渲染UI界面和交互，按照渲染引擎可分为html与dart，其编程语言主要是Javascript或Typescript、Dart。
目前基于html渲染的开发框架有react native、weex、uniapp，基于dart的开发框架只有flutter。
混合开发由于调用了原生的控件来渲染UI，所以加载和体验与原生差不多，学习成本比较低，只要会js，选择一个框架开发就行了，或者学习dart语言，进行flutter开发。
三、webapp开发
webapp开发主要利用原生环境中的浏览器控件来装载服务器上的html页面，实际这个app就是一个自定义的浏览器app，所以只要会html，就会开发webapp，由于app内部加载的是远程的网页，所以加载速度和体验最差。
以上是我个人的总结，有不对的欢迎指出，谢谢。
本人用c#，除了单片机用c，cad CATIA，多媒体主要Adobe，它干完所有，不需要性能的视图混合dom代码。
怎样评价uni-app？
前端最火热的话题无法就是flutter,不管是刷哪个论坛，必定有探讨flutter的文章。没用过flutter，但是对于跨平台的技术，我一直都在研究。
为什么是uni-app
之前一直在找解决跨平台的方案，尝试了很多方案，比如滴滴的变色龙，但是最终还是选择了uni-app，这里附上uni-app的官网。为什么会选择它呢，第一，vue语法，学习成本低，上手速度快，只要之前你做过vue的项目，那么就能很快上手，其实是vue和微信小程序的结合体，一半vue，一半微信小程序。第二，长期维护，之前做微信小程序的时候，选择了美团的mpvue，但是后面发现长期不维护了，提了Issues也没人理，随之就放弃了，而uni-app长期在维护，这样看出了开发团队的用心。第三，跨平台的能力，uni-app能够跨多个终端，H5，安卓，Ios，微信小程序，百度小程序，头条小程序，支付宝小程序，真正实现了一套代码，多端运行，而且很好适应了我国的市场。第四，日益丰富的插件市场，uni的插件市场也在日益强大，能够基本上满足我们平时的开发需求。
uni-app的组件有原生调用能力，第三方的vue库在调原生接口时跟 5+runtime 不兼容。就像nativescript 有vue版和angular版，类似于react native , 都是起源于phonegap/cordova
实际开发效果遵义小红椒 做了一款app，打包了安卓，Ios,微信小程序3个平台，产出的效果都还是不错，总体还是比较满意。而且打包过程也很方便简单，配套的HBuilderX自动内置了打包功能，所以也省去了打包的烦恼。
遵义小红椒 建议
如果你现在想做一款跨平台的产品，而且有vue和微信小程序的经验，最重要的，你不想学习一门新语言，那么uni-app也许是你的一个选择。
混合app开发框架uniapp的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于混合型app开发框架、混合app开发框架uniapp的信息别忘了在本站进行查找喔。
