web app和html5给前端带来的变化 —— 我们的html5游戏平台之旅

Who am I ? 姓名：曹刘阳 （阿当） Blog : http://www.hi.baidu.com/new/cly84920 Email : cly84920@gmail.com 微博 : @真阿当

跑在浏览器里的联机游戏大厅

游戏列表、玩家后台和道具商城

房间列表和座位列表

各种类型的游戏

Web app的优点 跨终端，一次开发到处运行

Web app的优点 可集成至 web app store、web mashup

Web app的优点 免安装

Web app的优点 透明升级

Web app的优点 Web App 的入口很多，数据都存在服务端 游戏大厅 地址栏 浏览器 Web App Store Web OS

Web site VS Web app

Web site —— Web的主流形式 数据展现驱动 前端辅助 存取数据库 列表页 详情页 登录验证 … Tabview 模拟弹窗 图片轮播 Ajax

Web app —— Web的新锐 前端交互驱动 后端辅助 新颖的交互方式 更多的功能模块 更大的代码规模 模糊c/s和b/s … 没有跳转 Ajax Socket 数据持久性

Web的发展 Web 里程碑 产品形态 前端技术 Web 1.0 静态网站 和 CMS为主 table布局,、少量css、少量js SNS、微博、视频等 Css布局、js框架、ajax、web 标准 Web 3.0 ? Google地图、web qq等 单页应用、大规模前端代码、html5、移动终端

web app 的机遇 js框架的发展和html5的到来，从技术上支持了前端进行类桌面应 用的开发，模糊b/s和c/s结构的界线。 前所未有的终端大战，一次开发到处运行的强烈需求。

web app 的硬伤 只能等。前途光明，但眼下却没有出路。 尴尬的时期。 移动终端对html5的支持力度不够 —— 全屏、锁定横竖屏、访问硬件、性能 移动支付 —— 如何在移动终端的浏览器里付款 发布渠道 —— web app store何时登录ios和android桌面 用户习惯的培养 —— b/s结构的app需要大公司推出有力产品 只能等。前途光明，但眼下却没有出路。 尴尬的时期。

Web app的挑战(1) —— 编程技巧的要求 更大的代码量 更大的可维护性需求 更深的团队协作需求 你需要更强的框架，和更高水平的前端工程师

强大的framework，弥补语言层面的薄弱 原生js在语言层面薄弱 jQuery的重点在library上，而非framework，远不够强大

强大的framework，弥补语言层面的薄弱 我们选择YUI3. 地址：http://yuilibrary.com/

YUI3组织架构

YUI3的语言层支持 oop、aop、valuechangeEvent、customEvent、lazyload、sandbox、 customModule …

jQuery之父和YUI3架构师的对话 《 Nicholas C. Zakas vs John Resig 一场关于YUI3/jQuery的精彩辩论》 http://ued.taobao.com/blog/2010/11/06/yui3-vs-jquery/

应用层 框架 开发团队 架构师 web site的前端架构师与开发团队 【前端架构需求】 【开发团队需求 】 抽取通用组件 设计模块化机制 制定应用层范式 制定全局规范 【开发团队需求 】 学习应用层范式 学习通用组件api 团队成员、以及架构师，无需深入沟通，避免冲突即可

应用层 框架 开发团队 架构师 web app的前端架构师与开发团队 【前端架构需求 】 【开发团队需求】 抽取通用组件 设计模块化机制 制定模块范式 应用层需求分析 OO设计和API设计 【开发团队需求】 学习模块范式 学习通用组件API 实现OO设计 团队成员，以及架构师需深入沟通

前端编程的难度在哪？ 知乎：《 Web 前端开发面临的挑战主要有哪些？ 》 http://www.zhihu.com/question/19984897/answer/13562908 css、DOM、BOM提供的接口太底层 css、DOM、js，同时在跑的三个线程 相同效果，完全不同的实现方式，完全不同的可维护性 浏览器兼容性

3+倍于后端的开发时间 后端：抽象出类 => 设计API => 编码 前端：抽象出类 => 设计API => 考虑css+DOM+js组合 => 编码

web app不一定需要html5 html4一样可以开发web app，同样面临编程技巧的挑战 http://www.adanghome.com/tbs/manage.html

Web app的挑战(2) —— 外部环境更多变化 html5的标准未最终确定,浏览器的支持在不停变化 终端的碎片化，不同的物理尺寸，不同的分辨率 你需要更多的测试设备，更多的hack技巧，和更多 的debug时间。

我们如何解决终端碎片化问题

主流解决方案 (1) —— 响应式布局

响应式布局优缺点 优点 缺点 无dpi缩放，根据不同分辨率，在不同终端均用最合适的方式显示 沟通成本高，从交互设计、UI设计到前端工程师均需参与 开发成本高，做大量嗅探，写多个分支 未来的新的主流分辨率出现，需再增加分支

响应式布局真的是答案吗？ 沟通和开发成本高 一次开发，到处运行，b/s结构的优势是否大大消弱？

主流解决方案 (2) —— 移动终端优先

移动终端优先优缺点 优点 无dpi缩放，开发成本低，一次开发，到处运行 缺点 大分辨率下表现很糟

另一种思路 —— 在viewport上做文章 主流思路，设置浏览器分辨率和机器分辨率一至，无dpi缩放 <meta name="viewport" content="width=device-width … 如果放任dpi缩放会如何？ <meta name="viewport" content="width=1024 …

我们的解决方案 —— 统一viewport宽度

统一viewport宽度的注意事项 非ios下设置viewport宽度较麻烦 不同设备的宽高比不同，统一满屏时的宽度值，则高度弹性。UI设计师设计时，要注意在高度上的弹性 —— 全屏尺寸和安全区域尺寸

全屏 与 安全区域

全屏 与 安全区域 安全区域

统一viewport宽度优缺点 优点 缺点 开发成本低，一次开发，到处运行 在大分辨率下表现良好 面向未来，自适应性良好 有dpi缩放，显示效果非最优 大分辨率下，交互设计受制约 小分辨率下，图片大小没有得到最大优化

viewport是浏览器送给前端工程师们的礼物 利大于弊 开发成本骤降，done better than perfect 维护成本骤降 设计成本骤降 微笑面对新分辨率的出现 viewport是浏览器送给前端工程师们的礼物

前端在开发中的分层 应用层 框架、类库 底层API 前端开发工程师 浏览器

前端在实践方面发展

HTML5来了 —— 框架和应用层均需变化 HTML4 HTML5 应用层 应用层 框架、类库 (drag,resize,animate,selector 通过js实现) 框架、类库 底层API 应用层 框架、类库 resize,animate由css提供) (drag, selector由js提供 底层API

jQuery2.x的瘦身 jQuery2.x不支持ie9以下版本,预示一个时代的结束

探索新API的应用场景，是个类似发明的过程，是前端 工程师们的责任 HTML5来了 —— 新api带来的创意爆炸 Canvas Websocket Transform Geolocation … 探索新API的应用场景，是个类似发明的过程，是前端 工程师们的责任

HTML5来了 —— GUI的选型 DOM or Canvas，完全不同的两条路

html5的大明星canvas canvas既强大，又弱小，是神器，也是不毛之地 像素级控制，但也没了DOM和css的帮助

基于canvas编程，完全不同的编程体验 没有css，没有容器，一无所有 自己动手，封装一套API，模拟DOMNode封装CanvasNode http://code.google.com/p/canvas-node/ 尽管如此，没有css的日子，还是非常痛苦的。 有css可用的人是幸福的。

HTML5来了 —— server端变化 http协议 ： 客户端拉、ajax、会话无状态、多页面同session socket协议：全双工、open | close | message、多页面多个连接

HTML5来了 —— 保守还是激进 website —— pc终端仍是主力，兼容为主，木桶短板 web app —— 移动终端和pc并行，可适当激进

前端工程师的发展 网页设计师 交互设计师 UI设计师 前端开发工程师

网页设计师 交互设计师 UI设计师 前端开发工程师 Flash方向 HTML方向

网页设计师 交互设计师 UI设计师 前端开发工程师 Flash方向 HTML方向 Css工程师 Js工程师

网页设计师 交互设计师 UI设计师 前端开发工程师 Flash方向 HTML方向 Css工程师 Js工程师 Web site工程师 Web app工程师 Canvas工程师