跨端开发应用场景设计案例（前端跨端框架）

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

本文目录一览：

• 1、阿里跨终端的H5游戏开发解决方案——Hilo
• 2、跨端开发面面谈之基于WebView的Hybrid开发模式
• 3、开发应用场景及顺序

阿里跨终端的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一探究竟！

跨端开发面面谈之基于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的一些体验，可以保持关注。

开发应用场景及顺序

设计模式是被编程者总结出来的一套被反复使用的、多数人知晓的、经过分类编目的代码设计经验。掌握常用的设计模式对于Java应聘者来说十分重要，如单例模式、工厂模式、建造者模式等。接下来具体料及一下Java常用设计模式及应用场景：
1、单例模式：保证一个类仅有一个实例并提供一个全局访问点，如一些配置文件或者管理类可以设计为单例，常用的线程池也是单例。
2、模板方法：在定义好的算法骨架下允许子类为一个或多个步骤提供实现，一次性实现算法的不变部分将可变部分留给子类实现，当子类实现代码逻辑雷同时可以使用此设计模式。
3、工厂模式：创建对象需要大量的重复代码时，通过子类实现方法来创建对象。如Spring中通过工厂模式将创建对象的任务交给容器管理。
4、原型模式 ：在应用程序可能有某些对象的结构比较复杂，但又需要频繁的使用它们，如这个时候不断的新建这个对象势必会大大损耗系统内存的，这个时候需要使用原型模式来对这个结构复杂又要频繁使用的对象进行克隆。所以原型模式就是用原型实例指定创建对象的种类，且通过复制这些原型创建新的对象。主要应用与那些创建新对象的成本过大时。它的主要优点就是简化了新对象的创建过程，提高了效率，同时原型模式提供了简化的创建结构。
5、建造者模式：讲复杂对象的构建和表示分离，适用于流程固定，但是顺序不一定固定的场景。如需要给一个对象多次给不同的属性赋值，可以使用链式调用传参，最后生成对象。如策略模式，观察者模式，模板方法模式，foreach中的迭代器模式，spring 中ASM的访问者模式，动态代理等都有一些了解。
6、适配器模式：在应用程序中可能需要将两个不同接口的类来进行通信，在不修改这两个的前提下可能会需要某个中间件来完成这个衔接的过程。这个中间件就是适配器。所谓适配器模式就是将一个类的接口，转换成客户期望的另一个接口。它可以让原本两个不兼容的接口能够无缝完成对接。作为中间件的适配器将目标类和适配者解耦，增加了类的透明性和可复用性。
7、桥接模式 ：如果说某个系统能够从多个角度来进行分类，且每一种分类都可能会变化，那么我们需要做的就是讲这多个角度分离出来，使得他们能独立变化，减少他们之间的耦合，这个分离过程就使用了桥接模式。所谓桥接模式就是讲抽象部分和实现部分隔离开来，使得他们能够独立变化。桥接模式将继承关系转化成关联关系，封装了变化，完成了解耦，减少了系统中类的数量，也减少了代码量。
设计模式应用场景是什么?JavaEE应用中Spring用于创建IOC容器的-就是基于观察者模式的。Spring中获取FileSystemResource和ClassPathResource等功能雷同的类时使用模板方法。
单例模式包含懒汉饿汉式以及不同的变种，工厂类设计模式一般也设计为单例。项目中的一些配置或引入外部的sdk需要创建管理类，或封装自己的框架时需要用到单例;工厂方法在编码时不能预见需要创建哪种类的实例。
设计模式是一套被反复使用、多数人知晓、经过分类编目的、代码设计经验的总结。使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性。设计模式于己于他人于系统都是多赢，设计模式使代码编制真正工程化，设计模式是软件工程的基石。 关于跨端开发应用场景设计案例和前端跨端框架的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。 跨端开发应用场景设计案例的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于前端跨端框架、跨端开发应用场景设计案例的信息别忘了在本站进行查找喔。

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