做跨端开发(跨平台开发需要)

网友投稿 579 2023-01-23

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

本文目录一览:

跨端开发面面谈之基于WebView的Hybrid开发模式

跨终端移动开发是近期准备总结的一个主题,作为这一系列的开始,首先简单说说基于WebView的Hybrid混合开发模式。

有过混合应用开发经验的同学,对基于WebView的Hybrid开发模式应该不会陌生。借助于原生端各平台的WebView组件,可以实现Native和JavaScript的双向通信,从而将Web App与Mobile App融合起来,开启混合开发的新模式。

基于WebView的Hybrid开发模式到如今已经非常成熟,不再是一个实验性新技术,而是广泛应用在各大厂商的平台型应用如微信、手Q中。

JSBridge作为连接Native和JavaScript的桥梁,是基于WebView的Hybrid开发模式中的关键点。
在了解其通信原理后,再来看JSBridge究竟是什么。从前端角度来看,可能会把JSBridge理解为业务开发过程中,以全局变量注入到WebView中,帮助调用原生API的JavaScript工具库。这样的理解不够准确,按照我的理解,JSBridge不是一个标准的规范,基于原生系统为WebView组件提供的能力,已经可以建立起WebView JavaScript bridge,即使不再做更高程度的封装,也可以完成从Native到JavaScript的双向通信了。

我们所说的JSBridge,是对底层通道的抽象封装,这一过程包括了原生和JavaScript两侧内容,在原生端需要考虑系统API差异,对上层调用提供统一接口,在JavaScript端需要考虑调用方式,请求管理等内容。JSBridge的设计实现已经是成熟技术了,其设计可以参考 In-depth Profiling of JSBridge 、 Hybrid APP架构设计思路 ,一个安卓端完整JSBridge实现可以参考 JsBridge实现 。

目前,基于WebView的Hybrid开发模式非常成熟,广泛应用于各类平台型App中。实现一个完善的JSBridge是在现有App中集成使用Hybrid开发模式的基础,在完成这一基础设施建设后,大家继续在各个方向深挖,在不同的维度不断优化性能和体验。

多数App的Hybrid部分做到上面部分,已经有了还不错的体验。在我的了解中,空间团队在上面基础上继续优化给出的是当前做的更好的方案。其主要流程如下图所示,详细内容可以参考 QQ空间前端工程师如何做首屏优化
除了在现有App中集成使用这一开发模式,还可以使用这一技术开发独立App。早期的PhoneGap、Cordova、现在的Ionic,是这一领域较为知名的开发框架。

我司前端技术栈曾以Angular为主,一些App也由前端团队基于Angular技术栈选型Ionic。初入团队曾维护过基于Angular 1.x的Ionic App,用于我司投资顾问服务客户的以IM为主、综合一些其他业务,可以算一个比较复杂的应用。

前端技术背景的同学,采用Ionic框架开发App的学习成本不高。开发过程中仍在沿用前端技术,写的仍是Web App,跑在原生WebView容器中。采用Ionic提供的组件库,可以快速搭建项目界面。其扩展原生的机制也比较方便,如有原生能力的需求,并且没有现成实现的,可以自行封装使用,不过这个过程就需要原生开发同学的参与了。在我们的上述App开发中,主要是安卓端消息推送模块由原生开发同学提供了支持,其余对原生能力的需求如拍照、相册访问等常见需求,都有现成方案。

然而,采用Ionic完成上述应用,也有明显不足的地方。首先是聊天列表方面,我们知道,如微信和QQ聊天窗口,这是一个异构的无限滚动长列表,在进入聊天界面时,一般只加载最近的一屏聊天数据,然后通过滚动加载历史消息。在原生端完成这一需求有各种常见手段,而仅靠Web端技术,在各种折腾后,效果都不尽如人意。其次是动画,这里的动画包括了换页动画和其他动画,流畅程度一般。最后是前端开发通病,要处理浏览器兼容性问题,crosswalk只是一个理论解决方案,其体积限制了几乎不会被采用。

Ionic不断迭代,新的版本中依赖新的Angular。新的Angular与Angular 1.x开发体验已经完全不同,如果你还不了解,可以阅读我们团队书籍 揭秘Angular 2 。新的Ionic的开发体验,相比以往也有提升,在其工具链中,提供了拖拽式项目生成工具
同时,Ionic pro提供的开发者工具,为应用整个生命周期提供了完善的支持平台,包括了以下功能,不过,使用需要付费。

站在当下来看,对于前端技术背景开发者来说,如果已有Angular基础,不希望引入过高学习成本,需要快速开发一个复杂程度不算太高、或者对应用性能不是特别敏感的跨终端App,选择Ionic依然是一个可行方案。

然而,既然你已经身在前端领域这样一个技术更迭日新月异的圈子里,还是应该使劲的折腾,关注跨端开发这个主题新的技术热点,接下来我也会继续谈谈在NativeScript、React Native、Flutter的一些体验,可以保持关注。

前端开发未来的发展前景怎么样?

Web前端开发,这已经发展多年的技术从最早的萌芽状态,发展到了今天的枝繁叶茂,各种技术的层出不穷也让开发者们不断地成长壮大。从最早的简单学习就能轻松应付,到今天的需要系统学习才能入职。那么,未来这项技术又将会走向何方呢?今天,千锋广州小编就和大家一起来看下。


小程序

作为目前前端最热门的方向之一,小程序自诞生之日起,就承担着重要的历史使命,其开发相对简便,无需安装就可使用的特性让一众APP开发者们如临大敌,毕竟如果这项技术得到了普及,APP或许就会被替代掉。

虽然发展势头迅猛,但是目前来看小程序想要在市场中拿到更多的份额或许还需要时日。厂商更新不积极,对超级APP平台的过于依赖,都是摆在小程序面前的棘手问题。所以,尽管小程序是Web前端开发未来的趋势之一,但是还是需要花费不少努力才能做到的。

跨端开发

得益于移动互联网的飞速发展,目前用户能够接触到的终端种类已经越来越丰富了,从最早的手机、电脑,到今天的电视平板等。万物互联这一概念将一众设备连接到了一起,而跨端开发,也就成了这一大趋势中受益最多的技术了。

目前较为成熟的跨端开发方案就数RN和fluter两种,其中RN已经有一段时间没更新了,进展速度缓慢,fluter使用的也相对较少。不过既然已经有了需求,那相信这些技术也会逐步跟上需求的成长速度。

Typescript

作为脱胎于JavaScript的一个超集,其到今天已经发展了有一段时间了,甚至已经有人猜想在未来typescript会取代JavaScript,尽管目前来看这是不可能的。但是它的出现,弥补了js的类型缺陷问题,也确实能够让Web前端开发变得更加轻松。所以,typescript在未来或许也可以在这个领域中占有一席之地。

5G

这虽然不是前端技术,但是它在未来的价值远高于前三个。如果说前三个是打造前端的技术,那么5G就是承载他们的载体。随着5G时代的深入发展,前端技术也必然会从中受益,实现更好的发展。

另外,目前5G还没有专属的应用场景,而Web前端开发,则是轻量化快速开发的代表,二者的结合将会碰撞出怎样的火花?我们拭目以待。

移动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

阿里跨终端的H5游戏开发解决方案——Hilo

Hilo是由阿里巴巴集团开发的一款 HTML5 跨终端 游戏 解决方案,可以帮助开发者快速创建 HTML5 游戏 。有以下特征:独立模块设计,支持多种模块范式的包装版本;面向对象程序化开发;多重渲染模型,其中包括 Canvas,DOM 和 WebGL 等;兼容多台台式机和移动浏览器;使用 Flash Shim 来支持 IE ;支持物理扩展: Chipmunk;支持骨骼动画扩展: DragonBone!
1、Hilo 支持多种模块范式的包装版本,包括AMD,CMD,COMMONJS,Standalone多种方式接入。另外,你可以根据需要新增和扩展模块和类型;
2、极精简的模块设计,完全面向对象;
3、多种渲染方式, 提供DOM,Canvas,Flash,WebGL等多种渲染方案(目前已经申请专利);
4、全端浏览器的支持和高性能方案,独有的Flash渲染方案,即使在低版本IE浏览器下也可以跑起来“酷炫” 游戏 ; DOM渲染方案能显著解决低性能手机浏览器遇到的性能问题;
5、物理引擎支持——Chipmunk,支持自扩展物理实现;骨骼动画支持——DragonBones,同时内建骨骼动画系统——Tahiti(目前内部使用);
6、案例丰富,框架成熟,已经经历多届阿里巴巴双十一,年中大促互动营销活动考验;
舞台Stage是一个各种图形、精灵动画等的总载体。所以可见的对象都要添加到舞台或其子容器后,才会被渲染出来。

Stage构造函数接收一个参数properties,此参数包含创建stage的各种属性。

舞台Stage上的物体的运动等变化,都是通过一个定时器Ticker不断地调用Stage.tick()方法来实现刷新的。

舞台上的一切对象都是可视对象,可以是图片、精灵、文字、图形,甚至DOM元素等等。Hilo提供了一些基本的可视类供您使用,比如添加一个图片到舞台上:

要想舞台上的图形、精灵动画等对象能响应用户的点击、触碰等交互事件,就必需先为舞台开启DOM事件响应,然后就可以使用View.on()来响应事件。

接下来,您就可以开始利用hilo提供的各种可视类来创建各种图形、精灵动画,尽情发挥您的创造力,开始您的HTML5 游戏 之旅吧!

Hilo对于开发H5 游戏 的开发者和对Web端渲染感兴趣的小伙伴来说值得一看,Hilo有诸多案例可供参考,如果你想继续深入了解它,可移步官方文档或者Github一探究竟!

跨平台桌面开发,Electron还是WebView2 (中篇)

这一周继续聊跨平台桌面开发这个事情。

在这篇文章中做跨端开发,我暂时会放下Electron与WebView2做跨端开发的一个对比,而聊一聊跨平台这个对于程序员群体来说不陌生的词。

一个趋势是:跨平台开发几乎是在各个技术方向都会持续发展的

跨平台这个词,对于程序员来说,应该是不陌生的。因为这个概念不只在某一端存在,后端,前端,移动端,桌面端几乎所有方向都对跨平台有需求。

在后端,Java是跨平台的,当你用Java来编写后端服务时,并不需要考虑操作系统,因为它几乎支持主流的操作系统。现在,编写一个后端服务,选用Java仍是主流。虽然可能它的跨平台特性已经不是程序员最在意的点了。

而在移动端,类似React Native,Flutter也是非常有名的跨平台移动开发,它们与移动原生开发方式之间一直是竞争与共存。

而前端因为依托于浏览器,天然就是跨平台的。事实上,很多应用或服务早期纷纷选择从原生应用迁移至前端WEB方式的一个非常重要的原因就在于它是跨平台的。

桌面操作系统很长一段时间一直是Windows一家独大,所以桌面开发一直是Windows独占,直至现在为止,很多专业级的软件仍然是Windows独占的。

而Linux桌面操作系统与MacOS桌面操作系统,早些年几乎可以忽略不计,压根不需要考虑这两种系统。但随着近些年它们的慢慢流行,特别是苹果的MacOS的以其杰出的工艺,流畅的体验,叠加苹果手机的流行,其市场份额增长非常之快,在特定的诸如编程,设计等行业人群中使用范围较广,这使得开发支持MacOS系统这个点变得越来越重要。

所以,在桌面开发领域,跨平台的需求也越来越高。

这也是Electron及早期的NW.js能迅速发展起来并得到非常广应用的原因所在。

无论是哪一端,跨平台技术之所以频繁出现与不断发展,其根本原因就在于编程的一个重要痛点在于:

为了让同一个服务能在所有设备上运行,程序员不得不编写与维护非常多不同版本的程序

每一个程序或软件后面的服务,都有一个非常迫切的需求,就是期望它的用户无论何时,无论何地,无论使用任何设备,都能方便友好的使用这个服务。

也是因为这个原因,Web发展起来了,因为Web的优势就在这,只要你的设备上有浏览器,就能访问。

但Web毕竟性能有限,且浏览器这种形式并不利于用户忠诚度的培养,它存在天然的弱点。一些简单的操作服务使用Web并无问题,但稍微有点要求的,Web可能就并不是非常适合。

所以,一种趋势不可避免地流行起来:

对不同设备或系统进行抽象,基于某一种特定的编程语言,编写出能与原生程序相媲美的,又能跨平台的技术便层出不穷了

对吧,Java是使用JVM来抽象不同的操作系统,React Native则是使用虚拟DOM以及转换成原生控件的方式来实现跨平台,而Electron则是通过性能较好的Chrome内核+NodeJS原生调用能力的搭配来实现跨平台桌面开发。

总而言之,这种跨平台的技术不会消亡,只会有新的技术层出不穷,而它们与原生开发一定是相互竞争,配合与共存的。相互之间无法取代。

那再回到跨平台技术上来说,一个良好的跨平台开发的技术或框架,重点是什么。

或者换种方式说,哪些特性使得它更易于流行起来?

我个人认为有以下的几个点:

跨平台开发技术能不能流行起来的一个非常重要的点就在于,使用了什么样的编程语言。

以移动端跨平台开发技术来说明,一个React Native,一个Flutter,这两个是比较知名主流的跨平台移动开发技术。React Native使用的是前端React技术,而Flutter则是Google的D语言。

显而易见的是,虽然Flutter是使用skia引擎在底层重绘一套UI,其性能相比React Native这种模式更佳,但React Native更易于被接受。

在流行度上,React Native始终比Flutter更流行,一个最重要的原因也在于:

使用已熟知的前端编程语言,比起重新学习一个D语言更易于被接受,维护成本更可控。

这个问题在跨平台桌面开发中也是类似,跨平台桌面开发技术也不是Electron最开始出现,比如著名的QT很早就有了,但比起Electron这种使用前端编程技术来说,显然在编程语言的门槛上和程序员群体上都存在困难,这也是Electron能后来居上的原因所在。

因为,大多数程序员群体,相比较另外学习一门什么语言去做什么,使用自己熟悉的语言来做什么是更容易,意愿也更高。

而从公司或团队的考量上看,选择偏门的小众语言存在成本上的顾虑,比如人员招聘是否容易?

跨平台技术在尝试解决不同平台不一致,它或多或少会损耗性能。这也决定了几乎没有任何一个跨平台技术能取代原生开发。

这是一个取舍的问题,对于一个程序来说,究竟性能有多重要。对于比较看重性能的程序来说,原生开发可能是最优选择。

但跨平台的性能损耗也有高低之分,并不在同一水平线上。

其实,无论是Electron,或是WebView2,都是基于浏览器内核+前端技术的跨平台桌面解决方案,这也是为什么要把它们放在一起聊的原因。

Electron是先行者(当然,严格说来,NW.js出现的更早,但今天它的流行度已远远落后于Electron了),而WebView2则是后来者。

那做为后来者的WebView2究竟做了哪些改进?它又有多大的能力来挑战Electron呢?

下一篇,继续聊。

web前端的行业趋势是什么?

web前端就是用代码做跨端开发的形式做跨端开发,还原UI设计师设计的界面,并实现各种交互效果。web前端工程师是程序员里面入行门槛较低的一个职业,就前端应用开发框架而言,已经形成做跨端开发了HTML5、CSS3、《Ecmascript 6》标准规范。

要学的内容主要有做跨端开发

计算机基础以及PS基础

②前端开发基础(HTML5开发、JavaScript基础到高级、jQuery网页特效、Bootstrap框架)

③移动开发

④前端高级开发(ECMAScript6、Veu.js框架开发、webpack、前端页面优化、React框架开发、AngularJS 2.0框架开发等)

⑤小程序开发

⑥全栈开发(MySQL数据库、Python编程语言、Django框架等)

⑦就业拓展(网站SEO与前端安全技术)

互联网行业目前还是最热门的行业之一,学习IT技能之后足够优秀是有机会进入腾讯、阿里、网易等互联网大厂高薪就业的,发展前景非常好,普通人也可以学习。

想要系统学习,你可以考察对比一下开设有相关专业的热门学校,好的学校拥有根据当下企业需求自主研发课程的能力,能够在校期间取得大专或本科学历,中博软件学院、南京课工场、南京北大青鸟等开设相关专业的学校都是不错的,建议实地考察对比一下。

祝你学有所成,望采纳。

关于做跨端开发和跨平台开发需要的介绍到此就结束了,不知道你从中找到你需要的信息了吗 ?如果你还想了解更多这方面的信息,记得收藏关注本站。 做跨端开发的介绍就聊到这里吧,感谢你花时间阅读本站内容,更多关于跨平台开发需要、做跨端开发的信息别忘了在本站进行查找喔。

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

上一篇:商业银行app运营模式(商业银行的运营模式)
下一篇:简述什么是混合app开发(app混合开发和原生开发)
相关文章

 发表评论

暂时没有评论,来抢沙发吧~