app跨端开发框（多端app开发框架）

本篇文章给大家谈谈app跨端开发框，以及多端app开发框架对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。 今天给各位分享app跨端开发框的知识，其中也会对多端app开发框架进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！

本文目录一览：

• 1、移动APP开发框架盘点2：Web移动前端框架大全
• 2、跨平台的html5移动app开发框架有哪些
• 3、如何选择AppCan与PhoneGap跨平台开发框架

移动APP开发框架盘点2：Web移动前端框架大全

开源项目其实有一个成熟周期，这个周期大概是三年左右，自React框架在2013年发布并引爆了前端框架的大潮，这个属于前端的周期就此开始了。

之后在2015年5月开源的React Native又开启了属于Web移动前端的周期，15-16年，18-19年，21-22年正好就是属于移动前端的三个爆发点。

三年前，在第一个成熟收获期，我盘点了移动开发框架。在这第二个成熟收获期，理所当然要来盘点一波。

不过，当我点开github项目的code-frequency时，还是被这个准到吓人的周期猜想惊呆了，先给你们看一波，剩下的自行验证。

1、https://github.com/youzan/vant/graphs/code-frequency

2、https://github.com/quasarframework/quasar/graphs/code-frequency

再来说第二个比较有意思的发现，停止维护的项目绝大多数是Vue框架项目。

盘点开始的时候我还觉得React框架处于绝对劣势，到完成时我发现React无论在选择面还是成熟度上都超过了Vue。

原因我这里就不分析了，反正大家都有自己的看法。

网页类框架就是前端组件框架，这一次虽然有大量项目停止维护，但是也有很多项目坚持了下来，而且还涌现出了一批新项目。

大厂占了主导，因为这些年大厂在移动开发上的需求，远高于其它方面。个人项目要坚持确实不易。

本来是想要做一个验证项目，把所有框架都试用一遍并给出推荐度的。由于进度太慢，还是下一次再发吧。

这次的重点是渐进类框架，就是所谓多端同构框架（小程序框架）。这几年国内的重点的各种小程序平台，所以多端框架的需求很是旺盛。

不过大多数先行者都没挺过来还是让我很意外，只有Taro成功了，想想还是有很多让人唏嘘的东西。

在这里还是先预测一波吧，因为这一类框架最变化最大，最终还是有很多框架要出局的。

渐进类框架是一个过渡性的产品，最终会变成桥接类框架的一部分，所以，与桥接类框架协同才是框架的出路。

这个赛道基本全是大厂了。

腾讯新一代跨端开发框架Hippy

Hippy一看就是淘宝Weex的对标项目，Kpi功能全面压制。所以官方支持 React 和 Vue 两种主流前端框架。在Weex2019年实质停更后发布，要不要这么卷？

Hippy 2.x 架构主要分成三层，UI(JS) 层 Hippy-React 和 Hippy-Vue 负责驱动 UI 指令生成；中间层 C++ HippyCore 负责抹平平台差异性和提供高性能模块；渲染层 Android 和 iOS 负责提供终端底层模块、组件，并与布局引擎通信。

对Weex惨遭遗弃，我上次就说过：「ReactNative提供工具，Weex提供框架，将平台差异化屏蔽（Write Once, Run Everywhere）。所以Weex则注定功能相对弱小，并且坑比较多。」Weex最终下马也是必然的，淘宝又发布升级版北海，为了实现（Write Once, Run Everywhere），它采用自绘，而且是基于Flutter自绘。

所以Hippy3.x就一如既往的Kpi功能层层加码，很有腾讯风格。在未来的 3.x 中业务与渲染层中的具体实现可根据用户实际场景进行切换：业务层上不再局限于 JS 驱动，还可选择（如：DSL/Dart/WASM 等）其它语言进行驱动；在渲染层中，渲染引擎除了支持现有原生（Native）渲染之外，还可以选择其他渲染 Renderer，如 Flutter(Voltron) 渲染。

「Kraken 北海」是一款高性能Web渲染引擎。底层基于 Flutter 进行渲染。

Kraken 不限制上层开发者使用的框架，无论你是使用 Vue 、Rax 还是 React 都可以开发 Kraken 应用。

Kraken 的 runtime 通过 JS Engine Binding 的方式提供了一系列 Web 标准的 API 接口，调用相应 API 会执行相关逻辑并创建一系列需要发送给 Dart 层处理的指令。

Kraken 其实就是一个小程序平台，而且追求全平台完全一致。我虽然认为各平台不一致是很自然的事情，但是也表示理解，毕竟别人吹牛有当真的传统（KFC表示认同）。

Kraken 现在也是一个小号浏览器，所以它的主要工作就是抠标准，毕竟它是一款基于 W3C 标准的高性能渲染引擎。

最后，我劝淘宝领导定Kpi要理智些，毕竟Hippy4我还蛮期待的。

滴滴出品的超轻量级动态化跨端开发框架，主打轻量和实用。

Hummer 以 JS 引擎为基石，目前已支持 JavaScriptCore、Hermers、QuickJS 等业内知名 JS 引擎（这里本来还有个V8的，我删除了，源码里面没有，Kpi需要）。再配合经过调优的 Yoga 布局引擎，抹平了两端视图布局差异（性能更佳的自研布局引擎开发中）。顺便提一下，Hippy采用V8（功能更强）自研布局引擎（性能更佳）。

Hummer 的特点是抛弃了业界其他动态化跨端框架普遍使用的DSL层和VDOM层，因此原生 Hummer 不具备前端开发常用的响应式编程的能力，但同时换来的是接近原生开发的体验和性能。再以原生 Hummer 为基础，在此之上开发了一套基于MVVM架构的开发框架 —— Tenon ，通过 Tenon，可以把使用 Vue/React 编写的代码，转换成原生 Hummer 的代码。

Hummer也是一个小程序平台，而且超轻量。如果想要无限提升自己APP的能力，可以考虑嵌入Hummer。

Web移动前端框架正在迎来第三个高速发展期，各类框架得到极大繁荣。

个人在具体项目的贡献已经微乎其微了，创新、架构创新是唯一制胜的手段，这也是我看好React的根本原因。

最后，还是想做点微不足道的 探索 ，现在前端组件库层出不穷，更换组件库带来的代价有点大。想创建一个框架，来实现上次说的组件公约数和公倍数，无缝切换组件库。理论上支持所有组件库 ，也能为后来者提供弯道超车的机会。我想大厂可能没有需求，也不会愿意发布这种框架，毕竟都是平台部门说了算。

这个库就是useMobile，当然分为useMobileReact和useMobileVue。下次先发布useMobileReact。等我发布后，再来填上面表中缺的推荐度。

原文地址： https://www-blogs.com/windfic/p/16019457.html

跨平台的html5移动app开发框架有哪些

jquery mobile和bootstrap都是较好app跨端开发框的框架
jQuery Mobile是jQuery 在手机上和平板设备上的版本。jQuery Mobile 不仅会给主流移动平台带来jQuery核心库app跨端开发框，而且会发布一个完整统一的jQuery移动UI框架。支持全球主流的移动平台。jQuery Mobile开发团队说：能开发这个项目，我们非常兴奋。移动Web太需要一个跨浏览器的框架，让开发人员开发出真正的移动Web网站。
Bootstrap 是基于 HTML、CSS、JAVASCRIPT 的，它简洁灵活，使得 Web 开发更加快捷。它由Twitter的设计师Mark Otto和Jacob Thornton合作开发，是一个CSS/HTML框架。Bootstrap提供了优雅的HTML和CSS规范，它即是由动态CSS语言Less写成。Bootstrap一经推出后颇受欢迎，一直是GitHub上的热门开源项目，包括NASA的MSNBC（微软全国广播公司）的Breaking News都使用了该项目。 国内一些移动开发者较为熟悉的框架，如WeX5前端开源框架等，也是基于Bootstrap源码进行性能优化而来。

如何选择AppCan与PhoneGap跨平台开发框架

不同的开发体验
从开发体验上讲，我认为AppCan和PhoneGap从设计时的目标用户群体是不同的。我不是PhoneGap的设计者，只能从其开发模式进行推测。我感觉PhoneGap的目标用户群是希望能够通过跨平台开发方式降低开发成本原生开发者。在项目开发中，PhoneGap是以原生开发人员为主，开发人员安装原生开发环境，配置工程，引入HTML、CSS、JS文件，编译生成应用。
AppCan的开发团队来自于原来的手机设计团队，设计思想来源于2005~2008年间非智能终端MMI(人机界面)开发方案。那个时代的手机设计团队承接众多厂商的定制终端需求，每家公司的手机终端当时还没有现在这样有相对统一的平台，相对统一的MMI体系。各家公司对UI的需求都会有很大不同。这就造成了定制终端开发成本的大头在MMI的实现。当时团队采用了自有浏览器引擎实现MMI开发框架，极大地降低了开发成本。
2010年初，AppCan刚刚火起来的时候就认为在智能终端开发领域，标准的HTML技术依然是最合适的跨平台开发方案。当时定位AppCan技术方案时，目标就是使无原生开发经验的HTML开发人员完成移动应用的开发。随着多个版本的推出，目前AppCan已经实现了以网页开发人员为主，原生开发人员为辅的混合开发模式。
通过减少原生开发人员在应用逻辑、数据对接等方面的工作，使其只关注于某个功能控件的开发，降低项目原生人员开发工作比率，减少项目开发成本。由于网页开发界面间耦合性小，更利于团队开发，并且开发人员不需要专用的苹果开发机和安装Andorid开发平台，有效地减低了开发成本。AppCan为了更好的组织网页开发人员、原生开发人员、项目管理人员、UI人员，为网页开发人员提供了专用的IDE开发环境、模拟器调试环境和本地打包环境，可以在无原生人员参与下完成应用的大部分功能调试和开发。
为原生开发人员提供了插件开发SDK，专为开发原生功能控件，并可直接编译网页开发人员的工程代码，生成目标版本，它等同于PhoneGap的开发环境。为项目管理人员、UI人员、网页原生开发人员提供了云端代码管理、项目管理、应用资源管理、插件管理、引擎管理服务，用于快速发布正式版本。目前AppCan-网站是为个人开发者提供的免费代码、项目管理平台。为企业开发用户有专用的企业云SDK开发环境。
不同的前端框架
从HTML，CSS，JS技术组成的前端框架上来讲，PhoneGap与AppCan也有很大区别。由于PhoneGap更多的是一种All In One Page的设计方案，因此开发者需要将应用功能整合在一个网页内部或通过异步加载方式加载到页面的方式实现用户操作流。在这种方式下不例外的都需要一个庞大的JS框架来帮助管理页面内内容的变化。例如JQuery Mobile、Sencha Touch方案。
AppCan则是参考原生开发模式，认为页面间是独立的，每个页面需要完成其主要功能，通过引擎的页面管理，把这些独立的页面串联起来就是一个应用。每个页面有其自身的生存期和上下文。这样可以组织更多的开发人员到一个项目中，且可以很少关心界面间的耦合性。
也就是说PhoneGap常使用JS框架进行窗口管理，AppCan采用引擎中的窗口管理器管理窗口。由于窗口管理机制的不同，AppCan可以在窗口切换、窗口间数据交互中更多的引入原生开发，来提高应用的感受性。AppCan的窗口管理器和窗口生存逻辑参考了Android的Activity，在很多地方可以找到其相似性。与UI开发框架有直接关系的还有分辨率适配方案。
不同分辨率的移动终端，浏览器为了展示网页时的适配，默认都会设定窗口缩放比率。假设480分辨率宽度的终端，网页中看到的依然是320宽度，缩放比率为1.5。这样网页适配320宽度的分辨率就可在大部分移动终端中正常显示。这虽然减小了适配问题，但是造成的后果却是，宽度为1的线在屏幕上显示时，实际并不是一个点，由此移动项目中无法充分发挥手机屏幕硬件的能力，应用界面无法和原生应用媲美。但如果调整了默认比率参数，使其直接采用屏幕硬件分辨率或者更小的缩放比率，都会造成不同分辨率下的界面适配问题。
AppCan 提供了整套的UI开发框架，应用引擎自动调整浏览器默认缩放比率，使其接近或等于屏幕硬件分辨率，采用弹性盒子框架，自动适配各种屏幕分辨率。采用相对大小方案，使应用在不同分辨率、不同屏幕精度，依然使界面保持最符合人体感受的大小和操作体验。通过这种方式，可以帮助开发者更有效的融合原生控件和网页界面，使其保持完美的布局。在适配新分辨率终端时，AppCan可以保证最小的网页代码修改。转载，仅供参考。
关于app跨端开发框和多端app开发框架的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。 app跨端开发框的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于多端app开发框架、app跨端开发框的信息别忘了在本站进行查找喔。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。