本篇文章给大家谈谈跨端开发应用实例教学,以及前端跨端框架对应的知识点,希望对各位有所帮助,不要忘了收藏本站喔。
今天给各位分享跨端开发应用实例教学的知识,其中也会对前端跨端框架进行解释,如果能碰巧解决你现在面临的问题,别忘了关注本站,现在开始吧!
本文目录一览:
如何开发跨平台移动App应用
什么是跨平台app?
所谓的跨平台app开发就是一套代码写完以后可以多端发布运行到各个平台,比如:安卓、iOS、微信 JS SDK、web、百度直达号、360流应用..
解决
方法:WEB APP。
所谓的 web app就是给web站打了个包加了个壳,我们看起来像是一个app可以上传到应用商店,可以从上面-,但是我们在手机上打开之后看到的实际上还是网页,只不过写成的是自适应的网页能够在手机上显示的也比较好,能够唬人,做到跟原生app神似!
Web App从实现角度是不是可以分为几种:
1、直接使用移动设备浏览器使用;
2、使用本地封装Embed Browser来调用Web接口;
3、使用Web技术(HTML,JavaScript,CSS)直接构建本地应用;
从这个角度讲,后两种很难分清Web和Native的区别,由于HTML5的支持以及现在JavaScript/CSS/DOM等性能和稳定程度越来越高,他们的表现不一定会跟Native差别太大。
跨平台app开发的UI就是基于html5 css3和js的,工程师只需要会前端就可以轻松学会跨平台app开发,大大降低了app开发的成本。
跨端开发面面谈之基于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的一些体验,可以保持关注。
如何实现iOS和安卓跨平台的开发
这是个比较专业的问题
首先我推荐一个:react native,facebook推出的一个跨平台解决方案,去年推出了iOS版,手机淘宝的有一个模块“猜你喜欢”就是用react native实现的,效果还不错,另外今年9月份,facebook推出了android版,大家不妨试一下,这里针对于webapp,做了一个比对:
相对于Webapp的优势:
不用Webview,彻底摆脱了Webview让人不爽的交互和性能问题;
有较强的扩展性,这是因为Native端提供的是基本控件,JS可以自由组合使用;
可以直接使用Native原生的「牛逼」动画(在FB Group这个app里面,面板滑出带一点果冻弹动,面板基于某个点展开这种动画随处可见,这种动画用Native code来做小菜一碟,但是用Web来做就难上加难)。
相对于Native app的优势:
可以通过服务端远程更新JS,进而直接更新app的页面;
相对于Webapp和Native的劣势:
扩展性仍然远远不如web,也远远不如直接写Native code;
从Native到Web,要做很多概念转换,势必造成双方都要妥协。最终web要用一套CSS的阉割版,Native要费劲地把这个阉割版转换成native原生的表达方式(比如iOS的Constraint\origin\Center等属性)。
另外我以前在CocoaChina上收藏过的一个帖子,整理了许多iOS和Android跨平台解决方案,感觉很不错,现在拿出来分享给大家,希望对题主有帮助。
1、jQuery Mobile
jQuery Mobile是jQuery 在手机上和平板设备上的版本。jQuery Mobile 不仅会给主流移动平台带来jQuery核心库,而且会发布一个完整统一的jQuery移动UI框架。支持全球主流的移动平台。jQuery Mobile文档比较全面,同时有在线工具帮你快速创建自己中意的UI风格。
技术需求:HTML,CSS,jQuery
平台支持: 绝大多数移动浏览器
2、Corona SDK(使用Lua语言):
Corona SDK的优点:
稳定;支持硬件加速、GPS、指南针及照相机等;支持与Map、Facebook、OpenFient、GameCenter的集成;内建的物理集成;Lua语言比较容易学习;
已经有了一些很不错的应用,至少能够证明这个SDK是可以做出优秀应用来的;不错的社区支持。
Corona SDK不太好的地方:
只支持iOS和Android;Lua语言不是面向对象的;每年都要交授权费(99美元/年)。
另外还有其他的一些补充,比如:
对于Corona SDK不支持的第三方SDK没法自己去集成;编译项目的时候需要把代码上传到Corona的服务器上去编译,不能在本地直接编译;无法扩展Corona的功能;物理模块还有一些缺陷。
3、Airplay SDK(后来更名为Marmalade,不少大的公司在使用Airplay SDK,尤其适用于进行2D/3D游戏的开发)
目前使用Marmalade的游戏有《割绳子》、《植物大战僵尸》、《你猜我画》、Build 'n' Bash 3D、Catch the Monkey、Need for Speed Shift以及WorkSnug Pro等多款游戏。
Airplay SDK文档中还包含多个示例。“感觉受到限制”的开发者还可以在Airplay SDK上进行扩展。开发者需要对C++比较熟悉。
4、Appcelerator(Titanium)
Appcelerator允许使用HTML/Javascript来开发原生app,开发者可以免费使用。目前世界上185个国家中有超多46万的开发者在使用Appcelerator提供的解决方案。
Titanium为Appcelerator于2008年底所推出的跨平台应用
程序开发解决方案,目前支持iOS/Android/Blackberry/WM7等行动平台,以及Windows/Linux/OS X这三种主流的桌上型平台。
基于Weex的跨多端融合方案(一)
大多数的应用都会在一个weex容器中进行页面跳转,这种场景下使用navigator就能比较好地实现(页面切换)。但是在实际混合开发场景中,会碰到更为复杂的跳转逻辑,如原生页面A跳转Weex页面,再从B跳转远程页面C,继而再从C跳转Weex页面D……再加上还会有跳转H5页面等等,这样对于后退栈的管理就会比较复杂。目前我们采用的解决方案是:为每一个weex页面单独使用一个容器(对于H5也是一样),这样页面的跳转就能交给原生系统的后退栈来管理。当然这么做也会有性能开销,但是综合来说,这种场景不多,因此从性价比考虑这么做是目前最合适的。
然而这么做又会来带新的问题,那就是weex所提供的消息机制只能是在单容器内使用,按照官方的说法即这是一个实例级别的事件而不是应用级别的。那么就需要我们自己来做一套消息通知机制供应用级别使用,来解决多weex容器实例以及连通weex、native以及H5。其实这套机制并不复杂,因为原生已经有很多消息机制可以供我们选择了,包括EventBus、LocalBroadcast等等。这里可以详见我的之前有关消息机制实现的文章(传送门: https://www.jianshu.com/p/774b77ddde52 )
之前说到大多数的weex使用场景是单容器(或者说是单实例)的,因此一般的实现也都是在一个Activity中(以安卓为例,下同)只有一个WXSDKInstance。然后有时候需求就是这么坑爹,在某些原生页面中希望可以内嵌一个甚至多个Weex的容器,那么这时候用来实现Weex容器的就不能再是Activity而是View了。我们需要自定义一个View来实现IWXRenderListener接口,并且在该View内部来维护一个WXSDKInstance,虽然初始化WXSDKInstance时候传入的Context还是Activity,但是好在instanceId是自增的,因此在一个Activity中有多个Weex的View,它们还是可以通过id来区分的。另外在使用View做容器的时候,也需要自己hook Activity的生命周期,来与WXSDKInstance中相应的方法绑定,不然在自定义Module等应用场景中将无法正确拿到Activity的生命周期回调。
想必很多团队在接触或者决定使用weex的时候,所在的项目已经是开发甚至是上线一段时间了,并且大多项目一定会用到WebView承载的H5页面,那么在开发H5相关页面时自然而然会定义很多通用的Bridge能力,比如账号登录机制、通用的loading组件、网络请求代理等等。然而我们在开发weex页面时候则不希望再重复实现这套Bridge,因此我们就需要实现一个适配器,通俗地说就是通过定义一个weex的Module去实例化H5的Bridge并且调用实例的方法。这套机制核心需要关注的是H5的Bridge需要怎么样的环境,我们通过哪种方法来实例化H5的Bridge(大多数情况下会需要用到反射)。此外,这种做法由于无法完全在weex容器中还原一个H5的环境,因此也并不是能100%复用H5的Bridge能力,对于无法复用的,我们还是需要基于weex重新开发一套。
在深度使用weex的时候,weex官方提供的组件会逐渐变得无法满足当前需求,这时就需要我们来做一些自定义的组件。当然这块并不需要用到什么黑科技,weex官方就提供了这类扩展,也就是WXComponent以及WXVContainer。常规的独立组件继承WXComponent即可,类似写一个原生的自定义View,具体的属性以及方法定义也可以参考官方文档( http://weex.apache.org/cn/guide/extend-android.html )。对于View的容器组件则需要继承WXVContainer,然后你就可以自定义各种cell,并且通过addSubView方法拿到加进去的cell。
weex官方提供了playground app,帮助你在设备上调试。但对于依赖自己项目环境的功能,就必须在项目内提供一个调试工具了,核心类似playground app,即提供一个扫码功能,能进入weex页面进行调试,对于调试这块功能,我会在后续的文章中详细讲解。
小程序平台现在已经成为一款应用不可或缺的阵地,因此跨端方案自然不能少了小程序这个平台。目前核心做法还是依赖于babel,并且需要在小程序端预先实现一套相对应的组件。详细的内容也将在后续文章中详细展开。
跨端方案既然是以提高效率为目的,那么自然需要有足够的数据来做支撑,因此我们需要在weex的几个生命周期内做好埋点,来统计各种耗时。另外在业务上也会有数据需求,一般也是通过埋点的形式来做统计
多端融合一定是未来移动端开发的一个方向,它除了解决一部分体验问题之外还能提高人效,因此未来各大企业也会越来越多地依赖这项技术。至于具体的方案选型,诸如weex、rn或者flutter,还是需要根据具体的业务场景来选择,目前并没有完美的方案,当然基于这些开源方案来二次开发,从而补足这些方案存在的不足则是更好的了。
对于我个人而言,自身的技术规划加上公司业务需求,有幸在这个时间点能学习到前端知识并且落地这套方案。因此我打算开一个文章系列,记录一下这套方案不断演进过程中的点点滴滴。
这段时间经历了很多事情,说是一夜长大也不为过吧。但是没有时间再自怨自艾了,找对方向,就算再难受爬着也要向前。失去的东西总会回到我们身边,虽然有时并不是以我们希望的方式。
阿里跨终端的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一探究竟!
关于跨端开发应用实例教学和前端跨端框架的介绍到此就结束了,不知道你从中找到你需要的信息了吗 ?如果你还想了解更多这方面的信息,记得收藏关注本站。
跨端开发应用实例教学的介绍就聊到这里吧,感谢你花时间阅读本站内容,更多关于前端跨端框架、跨端开发应用实例教学的信息别忘了在本站进行查找喔。
版权声明:本文内容由网络用户投稿,版权归原作者所有,本站不拥有其著作权,亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容,请联系我们jiasou666@gmail.com 处理,核实后本网站将在24小时内删除侵权内容。
暂时没有评论,来抢沙发吧~