xml地图|网站地图|网站标签 [设为首页] [加入收藏]
入门教程,Canvas前端游戏开发
分类:web前端

[Canvas前端游戏开发]——FlappyBird详解

2016/01/03 · HTML5 · Canvas

原文出处: xingoo   

一直想自己做点小东西,直到最近看了本《HTML5游戏开发》,才了解游戏开发中的一点点入门知识。

本篇就针对学习的几个样例,自己动手实践,做了个FlappyBird,源码共享在度盘 ;也可以参考github,里面有更多的游戏样例。

渐进式Web应用(PWA)入门教程(上)

2018/05/23 · 基础技术 · PWA

原文出处: Craig Buckler   译文出处:葡萄城控件   

最近关于渐进式Web应用有好多讨论,有一些人还在质疑渐进式Web应用是否就是移动端未来。

但在这篇文章中我并不会将渐进式APP和原生的APP进行比较,但有一点是可以肯定的,这两种APP的目标都是使用户体验变得更好。

移动端Web应用有很多优秀的概念让人应接不暇,但好在编写一个渐进式Web应用不是一个很困难的事情。在这篇文章里将向你介绍如何把一个普通的网站转换成渐进式Web应用。你可以按照这篇文章一步一步地做,做完之后你的网站将可以实现离线访问,并且可以在桌面上创建该网站的图标。那么下面即将开始入门教程。

大型单页面应用的进阶挑战

2015/09/30 · HTML5, JavaScript · 单页应用

原文出处: 林子杰(@Zack__lin)   

阅读须知:这里的大型单页面应用(SPA Web App)是指页面和功能组件在一个某个量级以上,举个栗子,比如 30+个页面100+个组件,同时伴随着大量的数据交互操作和多个页面的数据同步操作。并且这里提到的页面,均属于 hash 页面,而多页面概念的页面,是一个独立的 html 文档。基于这个前提,我们再来讨论,否则我怕我们 Get 不到同一个 G 点上去。

游戏截图

图片 1

图片 2

什么是渐进式Web应用?

渐进式Web应用是一种全新的Web技术,让Web应用和原生APP的体验相近或一致。

渐进式Web应用它可以横跨Web技术及Native APP开发的解决方案,对于开发者的优势如下:

  1. 你只需要关心W3C的Web标准,不用关心各种Native APP的代码。
  2. 用户可以在安装应用之前先试用。
  3. 在渐进式Web应用中,你不需要使用各种应用商店来分发应用,也不用关心应用发布时奇怪的审核标准以及应用内购的平台抽成。另外,应用程序更新是自动进行的,无需用户交互,所以整体的使用体验对于用户来讲更为的平滑。
  4. 渐进式Web应用的“安装”过程很快,只需要在主屏幕上添加一个图标即可。
  5. 渐进式Web应用启动时可以显示一个好看的启动画面。
  6. 你可以在渐进式Web应用中提供具有全屏体验的应用。
  7. 通过系统通知等形式提高用户的粘性。
  8. 渐进式Web应用将会在本地缓存必要的文件,所以渐进式Web应用会比普通的Web应用的性能更好。
  9. 轻量级安装——你只需要缓存几百KB的数据即可。
  10. 所有的数据传输必须使用安全的HTTPS连接
  11. 渐进式Web应用可以离线缓存数据,并且会在重新连接互联网时重新同步数据。

挑战一:前端组件化

基于我们所说的前提,第一个面对的挑战是组件化。这里还是要强调的是组件化根本目的不是为了复用,很多人根本没想明白这点,总是觉得造的轮子别的业务可以用,说不定以后也可以用。

其实前端发展迭代这么快,交互变化也快,各种适配更新层出不穷。今天造的轮子,过阵子别人造了个高级轮子,大家都会选更高档的轮子,所以现在前端界有一个现象就是为了让别人用自己的轮子,自己使劲不停地造。

在前端工业化生产趋势下,如果要提高生产效率,就必须让组件规范化标准化,达到怎样的程度呢?一辆车除了底盘和车身框架需要自己设计打造之外,其他标准化零件都可以采购组装(专业学得差,有啥谬误请指正)。也就是说,除了 UI 和前端架构需要自己解决之外,其他的组件都是可以奉行拿来主义的,如果打算让车子跑得更稳更安全,可以对组件进行打磨优化完善。

说了这么说,倒不如看看徐飞的文章《2015前端组件化框架之路》 里面写的内容都是经过一定实践得出的想法,所以大部分内容我是赞成而且深有体会的。

HTML5之Canvas

Canvas是Html5中用于绘图的元素,它可以绘制各种图形,比如长方形,多边形,圆形等等。如果想要了解Canvas的使用可以参考:

 

//如果想要使用canvas,首先需要获得上下文对象: ctx = document.getElementById('canvas').getContext('2d'); //然后使用这个ctx绘制图形

1
2
3
//如果想要使用canvas,首先需要获得上下文对象:
ctx = document.getElementById('canvas').getContext('2d');
//然后使用这个ctx绘制图形

在cavas每个绘制都是独立的操作。比如下图的两个绘制图形,第二个会以覆盖的形式绘制,因此绘制图形的顺序就显得十分重要了。

图片 3

渐进式Web应用发展的现状

渐进式Web应用才刚刚开始发展,但实际上在国内,有些网站已经实际开始PWA的实践了,例如:微博、豆瓣、淘宝等平台。可能这时候聪明的你可能就会产生疑问,那这个PWA不就是和微信小程序一样吗,对是这样,二者的目的是一致的,就是在移动端为用户提供足够轻量且与原生应用使用体验相近的“轻”应用。

但就目前来讲,PWA是Google主推的一项技术标准,FireFox,Chrome以及一些基于Blink的浏览器已经支持渐进式Web应用了,Edge上对渐进式Web应用的支持还在开发。Apple公司也表示会考虑在自己Safari支持PWA。然而这项功能已经进入了WebKit内核的五年计划中。长期来看,对浏览器兼容性的支持方面应该已经不算太大问题了。况且在现阶段,在不支持渐进式Web应用的浏览器中,你的应用也只是无法使用渐进式Web应用的离线功能而已,除此之外的功能均可以正常使用。

而在微信这边,凭借庞大的用户基数和体量能否与PWA分庭抗礼乃至笑到最后目前还不得而知。

挑战二:路由去中心化

基于我们所说的前提,中心化的路由维护起来很坑爹(如果做一两个页面 DEMO 的就没必要出来现眼了)。MV* 架构就是存在这么个坑爹的问题,需要声明中心化 route(angular 和 react 等都需要先声明页面路由结构),针对不同的路由加载哪些组件模块。一旦页面多起来,甚至假如有人偷懒直接在某个路由写了一些业务耦合的逻辑,这个 route 的可维护性就变得有些糟糕了。而且用户访问的第一个页面,都需要加载 route,即使其他路由的代码跟当前页面无关。

我们再回过头来思考静态页面简单的加载方式。我们只要把 nginx 搭起来,把 html 页面放在对应的静态资源目录下,启动 nginx 服务后,在浏览器地址栏输入 127.0.0.1:8888/index.html 就可以访问到这个页面。再复杂一点,我们把目录整成下面的形式:

/post/201509151800.html /post/201509151905.html /post/201509152001.html /category/js_base_knowledge.html /category/css_junior_use.html /category/life_is_beautiful.html

1
2
3
4
5
6
/post/201509151800.html
/post/201509151905.html
/post/201509152001.html
/category/js_base_knowledge.html
/category/css_junior_use.html
/category/life_is_beautiful.html

这种目录结构很熟吧,对 SEO 很友好吧,当然这是后话了,跟我们今天说的不是一回事。这种目录结果,不用我们去给 Web Server 定义一堆路由规则,页面存在即返回,否则返回 404,完全不需要多余的声明逻辑。

基于这种目录结构,我们可以抽象成这样子:

/{page_type}/{page_name}.html

1
/{page_type}/{page_name}.html

其实还可以更简单:

/p/{name}.html

1
/p/{name}.html

从组件化的角度出发,还可以这样子:

/p/{name}/name.js /p/{name}/name.tpl /p/{name}/name.css

1
2
3
/p/{name}/name.js
/p/{name}/name.tpl
/p/{name}/name.css

所以,按照我们简化后的逻辑,我们只需要一个 page.js 这样一个路由加载器,按照我们约定的资源目录结构去加载相应的页面,我们就不需要去干声明路由并且中心化路由这种蠢事了。具体来看代码。咱也懒得去解析了,里面有注释。

canvas之drawImage()

本篇的游戏开发中,主要使用的是依据图片绘制的api:drawImage(),它有两个基本的使用方法:

ctx.drawImage(image,this.bx,this.by,this.bwidth,this.bheight); ctx.drawImage(image,x,y,width,height,this.px,this.py,this.pwidth,this.pheight);

1
2
ctx.drawImage(image,this.bx,this.by,this.bwidth,this.bheight);
ctx.drawImage(image,x,y,width,height,this.px,this.py,this.pwidth,this.pheight);

第一个api中,指定Image对象,然后给出绘制图片的x,y坐标以及宽度和高度即可。

第二个api中,第一组x,y,width,height则指定了裁剪图片的坐标尺寸,这在使用多元素的矢量图时很常用。比如:

图片 4

上面的图片中为了减少图片资源的请求数量,把很多的元素放在了一个图片中,此时就需要通过裁剪的方式,获取指定的图片元素。

示例代码

大多数教程都讲述的是如何在Chrome上从零开始制作一个类似原生界面的应用。然而在这篇教程中,我们并不打算做一个单页面应用程序,所以在这我们也不必了解诸如Material Design等知识。那么下面我们就直接看示例吧。

你可以从GitHub中获取本教程对应的示例代码。

本示例中提供了一个有四个网页的网站,一个CSS文件和一个JavaScript文件。这个网站可以在所有的现代浏览器上正常工作(IE10+)。如果你的浏览器支持渐进式Web应用,用户可以在离线状态下将会直接访问缓存中的页面。

要想运行此示例,请确保你已经安装了Node.js。并请打开命令行,使用以下命令来运行该示例:

node ./server.js [port]

1
node ./server.js [port]

以上命令中,[port]是可选部分,默认为8888。使用 Ctrl + C 即可停止Web服务器。

打开基于Blink内核的浏览器(Opera,Vivaldi,Chrome),然后在地址栏中输入 或者 Cmd/Ctrl + Shift + I)来查看控制台信息。

图片 5图片 6

查看首页,也可以在页面上点击一下,然后使用以下方法进入离线模式:

选中Network标签或者Application -> Service Workers 标签下的“离线”选项。重新访问之前访问过的网页,之前网页仍然会加载:

图片 7图片 8

挑战三:领域数据中心化

对于单向数据流循环和数据双向绑定谁优谁劣是永远也讨论没结果的问题,要看是什么业务场景什么业务逻辑,如果这个前提没统一好说啥都是白搭。当然,这个挑战的前提是非后台的单页面应用,后台的前端根本就不需要考虑前端内存缓存数据的处理,直接跟接口数据库交互就行了。明确了这个前提,我们接着讨论什么叫领域数据中心化。

前面讨论到两种数据绑定的方式,但是如果频繁跟接口交互:

  • 内存数据销毁了,重新请求数据耗时浪费流量
  • 如果两个接口字段部分不一样但是使用场景一样
  • 多个页面直接有部分的数据相同,但是先来后到导致某些计数字段不一致
  • 多个页面的数据相同,其中某些数据发生用户操作行为导致数据发生变动

因此,我们需要在业务视图逻辑层和数据接口层中间增加一个 store(领域模型),而这个 store 需要有一个统一的 内存缓存 cache,这个 cache 就是中心化的数据缓存。那这个 store 究竟是用来弄啥勒?

图片 9

Store 具有多形态,每个 store 好比某一类物品的仓储(领域,换个词容易理解),如蔬果店 fruit-store, 服装店 clothes-store,蔬果店可以放苹果香蕉黑木耳,服装店可以放背心底裤人字拖。如果品种过于繁多,我们可以把蔬果店精细化运营变成香蕉专卖店,苹果专卖店(!== appstore),甚至是黑木耳专卖店…( _ _)ノ|,蔬果种类不一样,但是也都是称重按斤卖嘛。

var bannerStore = new fruitStore();

var appleStore = new fruitStore();

有了这些仓储之后,我们可以放心的把数据丢给视图逻辑层大胆去用。想修改数据?直接让 store 去改就行了,其他页面的 DOM 文本内容也得修改吧?那是其他页面的业务逻辑做的事,我们把事件抛出去就好了,他们处不处理那是他们的事,咱别瞎操心(业务隔离)。

那么 store 具体弄啥勒?

图片 10

  • 32 个赞位置可点赞或者取消,三个页面的赞数需要同步,按钮点赞与取消的状态也要同步。
  • 条目是否已收藏,取消收藏后 Page B 需要删除数据,Page A+C 需要同步状态,如果在 Page C 又有收藏操作,Page B 需要相应增减数据,Page A 状态需要同步。
  • 发评论,Page C 需要更新评论列表和评论数,Page A+B 需要更新评论数。如果 Page B 没有被加载过,这时候 Page B 拿到的数据应该是最新的,需要同步给 A+C 页面对应的数据进行更新。

所以,store 干的活就是数据状态读写和同步,如果把数据状态的操作放到各个页面自己去处理,页面一旦多了或者复杂起来,就会产生各个页面数据和状态可能不一致,页面之前双向引用(业务耦合严重)。store 还有另一个作用就是数据的输入输出格式化,简单举个栗子:图片 11

  • 任何接口 API 返回的数据,都需要经过 input format 进行统一格式化,然后再写入 cache,因为读取的数据已按照我们约定的规范进行的处理,所以我们使用的时候也不需要理会接口是返回怎样的数据类型。
  • 某些组件需要的数据字段格式可能不同,如果把数据处理放在模板进行处理,会导致模板无法更加简洁通用(业务耦合),所以需要 output format 进行处理。

所以,store 就是扮演着这样的角色——是数据状态读写和同步,以及数据输入输出的格式化处理。

本文由澳门新葡亰手机版发布于web前端,转载请注明出处:入门教程,Canvas前端游戏开发

上一篇:浏览器缓存机制,网页程序迁移至微信小程序w 下一篇:没有了
猜你喜欢
热门排行
精彩图文