第五届iWeb峰会议程概述

Aug -28, 2016

作为HTML5行业最具影响力的盛会之一，由HTML5梦工场举办的“2016 iWeb峰会·北京站”已成功举办，作为本届峰会规模最大、参会人数最多的主站——北京站，峰会当天行业各领域权威人士现场坐而论道，共同探讨HTML5最新技术与行业趋势，干货连连。

准备

2016年8月27日8点半国际会议中心开始签到入场。
9点一如既往的由h5女神娜姐开场。

主题峰会

《HTML5发行的力量》凌海（蝴蝶互动 CEO）

印象最深的是凌海说的如何规避风险，如何做时间管理，举例说明了有投资方要求360出3年规划，3年对互联网来说时间太长了，3年可能发生很多事，风险是无法预知的；列举自己针对一个需要90天的项目，他们公司往往是比较慎重的，他们会把时间细化到30分钟，相比90天或者3年30分钟的风险是基本可以完全把控的。

《2016：完善生态闭环，向全行业致敬》陈书艺（白鹭时代 CEO）

一个领先的html5移动技术与服务提供商，erget开放平台，出款多个游戏，什么暗黑之王，乱弹三国，稀有神传，小小战争，三国魂等，支持多种动画解决方案，平滑动画，可视化代码，专业游戏引擎。
h5游戏行业有机遇也有挑战，性能的大幅提升和微信带来的流量都是h5游戏行业的机遇（流量变现等）

《天下武功，唯快不破》王哲（触控科技副总裁）

他从h5游戏的性能方面做了分析，对于h5的未来，他报以谨慎乐观的态度。
分析了h5游戏的性能方面：

webGL性能提高 5~10倍
Canvas 脏矩形算法性能提高2倍
内存占用降低5%
包体减小30%

《社交生态下的HTML5游戏辛新契机》李明（很快CEO）

“很快”鼓励开发者将技术转化为流量，并现场宣布，和9g合作，启动了亿元流量计划，为开发者提供流量。

《HTML5和Docker容器如何重构和颠覆应用产业》马科（WeX5 CEO ）

首先这位被娜姐介绍说是“90后”CEO，引起现场一片轰动，90后出道的~ 哈哈
从互联网的扩大入口：h5会导致病毒式传播，形成闭环，不像传统app的场景分割。还有云计算即未来和对新技术的思考：要从应用场景切入，而不是重复造轮子。
对比了优秀app和传统app的区别， devops区别，这位干货很多。

《web技术：一个挑战极限的创新平台》江小丹（英特尔 web技术研发总监）

提到了web前沿技术：web assembly nodejs 还有Intel在虚拟现实的技术尝试和酷炫的体验。

《web 前端的是实时化》肖光宇（野狗实时联合创始人）

野狗是国内领先的实时后端云；野狗api–最实时通信api来了，应用于各大场景，可实时同步数据，网页通信，实时游戏，运用于汽车，实现实时同步汽车数据等。
使用野狗API,可以获得实时后端云的两大功能

实时通信，包括消息订阅，推送，双向通信等功能。网络延迟小，服务响应速度快，API简单易用。
数据存储，提供了一个Key-Value的云端数据存储，直接通过API就可以对数据进行存取操作。操作简单，按需扩展。

《移动互联网下半场-不用好HTML5，大部分公司都会死》王安（Dcloud CEO）

互联网下半场，原生应用成本高，留存率低等问题已经显现。如何用HTML5解决这个问题呢？他提供的答案就是流应用。

《H5游戏进入精品时代》谢成鸿（LayaBox CEO ）

这个比较接地气，说什么目的都是能挣钱，第一桶金开发一款小游戏赚到一点小钱650万。
LayaBox阐述了未来游戏市场将呈现页游、手游、HTML5多端融合的趋势，强调了HTML5技术跨端、多屏、免下载等特点给游戏行业带来的革新性变化。在LayaBox看来，HTML5游戏是游戏市场上一课冉冉升起的新星，即将迎来爆发。同时，LayaBox也详细介绍了旗下第二代HTML5游戏引擎LayaAir，其支持Flash页游、APP手游、HTML5游戏三端同发的特点和超越Unity3D的性能赢得了现场阵阵掌声。目前，LayaBox业务涵盖了引擎提供、游戏发行、游戏渠道、IP合作、项目投资、教育培训6大板块，是一家综合性的游戏服务企业。

工具应用专场1

《高性能HTML5 APP 开发云实践——基于完全开源的WeX5开发框架》王洁（WeX5 首席技术运营）

主要对原生APP和hybrid app的比较，简述为解决白页多webview 实现转场动画等，复杂效果native 实现，简单效果h5实现“重混” - wex5 “轻混”，只需前端调用，提供打包平台
WeX5的可视化操作
wex5，一个纯h5app开放平台，组件风格分离，基于css3，引入bootstrp资源，可快速开发。一次开发，全面拥有安卓app，苹果app，微信服务号。真正的html5 app开发云。
Hybrid App走向“轻混”，剖析WeX5开源高性能HTML5 App开发框架

一. Hybrid App从“重混”到“轻混”的技术发展历程
基本上从早期的多元化走向了只有Android和iOS两个系统的环境。对于开发者来说，就意味着一个App需要制定两套实现方案，这对开发成本和维护成本都是非常大的挑战。基于这样一个现实，其解决方案就是想办法实现套代码跨端运行，所以Hybrid APP混合应用模式应运而生
在Hybrid APP发展早期，Web运行性能是当时的主要的瓶颈。Web在性能方面有缺陷，Web不够就用Native来凑，就是选择了用原生技术来弥补Web上的性能不足，其实就是多WebView。混合的单WebView最大的障碍就是页面切换，闪白很明显。手机里面又讲究用户交互体验，从一个页到另一个页想做个平滑的动画，用纯Web技术在当时的条件下是非常难以实现的，其实目前大多数框架也是这么做的，就是采用多WebView，这样可以平滑的转场。
因为早期硬件比较差，浏览器性能也一般般，所以有一些比较复杂的组件在实现一些功能的时候，速度比较慢。当时框架里是用NativeUI组件来弥补的，配合Web来实现这些功能。这种模式被定义为“重混”，用原生的能力去弥补UI，或者技术更偏Native的框架就被定义为重混的Hybrid App框架。
重混框架优缺点很明显，优点是提升了运行性能、增强了交互。缺点是Web和Native技术交叉混杂，增加了开发人员的工作难度。但是，当下的手机硬件配置已经有了很大的改善，包括浏览器技术的发展也很重要，在GS引擎方面都有长足的进步。实现功能的时候用Web的技术的前提下已经不再需要Native技术来弥补了，随着技术的发展，性能已经不再是瓶颈。

另一个改变了移动应用这一领域的进程事件是，自从微信推出以后，相当于重新定义了移动应用的概念，通过它的服务号、公众号、企业号，微信本身变成了一种应用平台。包括微信最新的版本更新，它浏览器内核的升级，包括对游戏的支持，都和大量的移动App开发有着莫大的关联。而这个时候重混的框架就显得多余了，因为在重混框架里面很多性能的解决是依赖Native的原生部分。而到了微信里面，多WebView和NativeUI都没有了。原来在重混框架里面很强的一些能力完全就消失了，这时候在微信里面就有很多能力就不能用了。
于是轻混就成了目前真正要跨端Hybrid App的必然选择，这时候轻混的UI部分必须用纯Web技术，在底层的设备接口上，GS无法完成的原生部分需要Native技术来弥补。需要强调的是，Native的技术是不应该去侵入UI的，这样的一个框架就是我们所说的轻混Hybrid App框架，这才是真正的HTML5 App框架。

二.构建高性能HTML5 App跨端框架
伴随着以上的观点，接下来谈谈如何构建轻混模式下的HTML5 App框架。这种混合框架很简单，首先要有一个内置了浏览器的外壳，在浏览器里提供网页运行环境，同时在这个外壳上提供很多插件，可以让网络通过GS进行操作。
基于这样的认识，王洁说，在选择HTML5框架设计的时候，要解决两个框架的问题，一个是HTML5的框架，一个是Native的框架。首先看Native框架的选择，选择PhoneGap框架，受到了业内主流厂商支持，微软也是用Cordova，它的插件框架是开放的，很容易自定义。
另外就是要解决HTML5的一些性能问题，如果不采用重混架构的话，在页面切换还是会有一些障碍，王洁说到，WeX5采用SPA单页应用模式，它是基于传统的页面加载模式MPA，页面之间互相独立。但是SPA的不同之处在于，其框架里整个页面是由外壳页面框架组成的，是用AJAX技术完成的，AJAX在桌面时代就存在，通过局部刷新来提升用户体验。但是把AJAX技术最大化来使用，整个页面框架都用AJAX来实现，每个页面的加载都是这样的方式。
对设备的局部渲染，可以在加载的时候在后面预加载再做转场动画，而且还不需要依赖多Web应用，不需要依赖Native就可以完成。而且在加载多页框架时每个页面的共用功能要重复加载。所以从各方面来说SPA相对于MPA是有极大的性能提升的。
SPA确实很好用，但是在设计产品的时候需要考虑到多人协作过程中，支持复杂应用的开发过程中，会不会出现多个ID会冲突，样式冲突，JS冲突等等致命问题？所以下面就谈到了页面隔离的问题。
解决这样棘手的问题，王洁说，首先要考虑到HTML元素ID冲突的问题，因为是可视化工具，所以ID属性的设计是拖到一个属性栏里去定义ID，这时候刚好可以用一个替换原则，用了XID来替换，不会直接设定ID属性。这样到内存里，会动态的生成真实的ID，会在XID后面加一个页面标志，这样可以保证多人写的页面在加载内存里ID是不相同的，也就不存在冲突。当然提供一些API的时候是能拿到真实ID，对应相应的元素，不影响访问。在整个组件体系里，开发者利用很简单的方法就可以拿到组件，可以很平滑的解决掉ID冲突的问题。
CSS样式冲突问题分为两类，一类样式是共用样式，多页面引用同一个页面；另一类样式被定义为私有样式，只使用页面，但不希望这个页面干扰到其他页面。这时候给每个页面都配了一个CSS文件，定义私有样式，限定在当前页面。实现起来也很简单，通过对工具的编译，把私有CSS文件里的所有样式加一个页面标志，在页面节点的属性上加一个标志，这样就使得class只能作用于当前页面的HTML元素，这就成为了一个私有样式。
然后是JavaScript问题，现在JavaScript模块化技术很流行，借用JavaScript模块化技术，解决JavaScript隔离问题。王洁在这里顺便把RequireJS简单的提了一下，通过define可以定义模块，在RequireJS定义里，这个大括号里的才是模块里的代码。不管是方法还是变量，都封装在闭包里，每个代码都是写在define的模块里，这样就把代码自然隔离了。
王洁说他们在外围还做了一些工作，首先是实现完整的外壳管理，Shell类提供外壳管理。为了防止信息泄露，在配置的时候确实会把页面完整卸载掉。当加载页面片断时，会从当前外壳数把JS删掉，页面加载的时候创建的JS对象都会完整的释放掉，这是由框架来保证的。另外是路由的问题，在SPA单页面框架里路由是很重要的，因为是单页面应用，加载的页面都是片断，其实UI地址一直是外壳的地址。
下图是整体框架的架构。黄色部分用的是Cordova，解决安卓和苹果的原生调用问题。同时要兼容微信，所以上面把Cordova和微信又做了封装，抽象成统一的HTML5 API。如果通过统一的Native API去拍照，会自动根据页面环境，通过Cordova接口调用，这样可以更方便的实现一次开发，多端运行，代码不需要改，既可以运行在原生App里，也可以运行在微信里。包括拍照、GPS地图，一系列的API都可以进统一分装。
Bootstrap在这里提供了几个能力。一个是样式美化，扁平化风格，另外响应式布局。基于Bootstrap设计的页面，运行在不同的设备上不需要考虑分辨率，会自动处理设备分辨率。再上面实现了WeX5的组件框架和数据框架，页面上不仅有交互的UI组件，页面里面还有数据。接下来是业务框架层，即SPA单元页面框架。在服务端WeX5还提供了XBaaS服务，负责后端数据存取、逻辑，还有第三方地图、支付等功能实现。WeX5提供多语言实现，提供了不同语言的版本，开发者可以针对自己的版本来集成到自己的框架里。
三、WeX5可视化快速开发实践
在分享的最后，王洁给大家展示了基于WeX5这样的框架所开发出来的一些功能。首先是可视化的快速开发程度，帮助开发者通过可视化开发定义页面，框架可以保证运行体验，必须能快速加载，而且各种首试、硬件能力的是一体化集成的。把组件拖到表单上定义布局，设置属性，即可得到最终页面，设计室和运行室相邻，完全所见即所得。
丰富多样的组件，足以适应各种复杂表单的组合。通过把常见功能组件封装，可以极大减轻开发者的开发工作量。最关键的是整个组件框架完全开源，除了WeX5提供的上百个组件以外开发者还可以自己定义这个可视化组件，甚至可以继承第三方组件，通过规范的方式封装成HTML5的可视化组件。
编程问题也是重点，WeX5的定位是可视化程度更高的前端编程工具。不仅可以可视化设计，编程也是便捷。它能实现代码的智能提示、代码模板，还内致了Emmet框架。随后考虑的是调试问题，WeX5是一体化的环境，不仅要解决开发、编程，还要解决调试的过程，既可以在Web浏览器上调试，也可以连到手机上调试，所有代码都是开源的，底层内库也是开放的。最后就是打包的问题，打包要考虑很多插件的配置，参数，资源在命令行的配合。WeX5提供了一个打包的向导，完全本地打包，不需要依赖云打包服务，只需要把打包过程中要设置的东西完全工具化，可以设置应用版本、证书、LOGO、图片、插件里的参数，最后就可以应用到App上。

《web技术推进多样化人机交互方式》吴栋夏（英特尔软件工程师）

讲述了Intel的各种“黑科技”，还介绍了关于深度增强摄像，场景感知与模型，crosswalk，nw.js
crosswalk
nwjs
nwjs是在英特尔开源技术中心创建的，它是基于谷歌浏览器核心引擎和nodejs运行，你可以通过nwjs技术使用html和js语言编写本地应用程序，它也可以让你直接从DOM调用nodejs模块，使用一种新的方式与所有的Web技术编写本地应用。它主要有以下6个特点：

以网络最流行的技术编写原生应用程序的新方法
基于HTML5, CSS3, JS and WebGL而编写
完全支持nodejs所有api及第三方模块
可以使用DOM直接调用nodejs模块
容易打包和分发
支持运行环境包括32位和64位的Window、Linux和Mac OS
《Yo-去哪儿移动UI框架》杜瑶（去哪儿网前端开发总监）
瑶姐机智自不必说，网红魅力；
YO 一款基于Sass开发的css框架，用于快速构建移动UI项目
mobile First
why mobile First (以mobile作为基准的设计为出发点)
公司战略转移
新战场需要有力的框架抹平平台切换所带来的适应过程
pc端已有成熟的解决方案，无需推倒重来
专注于某一具体的领域更能变得专业
mobile First 的好处
可以减少对历史问题的考虑，不如不用考虑IE
保证交互方式的单一性，不用考虑PC上的交互行为
更及时的应用上新技术
代码更轻量

ios 默认风格
why ios
巨量的ios用户（超过50%）
安卓碎片化过重，不易挑选标示
ios的交互及展现更具备普适性

Pure CSS 纯粹的css 框架
why pure css
职能更分明
能被使用在任何项目中
不紧密捆绑UI组件

分层设计
Yo将不同的功能拆解成结构清晰的类别分散到不同的层去进行处理

yo|—usage
|—lib

分层设计的意义
清晰的依赖
高度解耦
高度复用
高可移植性
结束混乱的文件引用

rem+px

边框厚度使用px单位
字体，大小等除边框厚度外的定义使用rem
解决实现retina屏真正的1px 边框问题

封装了丰富的常规问题解决方案

独立配置层设计 config

厂商前缀
iconfont
响应式

元件

扩展超扩展

动画库

《手机QQ react web极致优化》李成熙（Alloyteam工程师）

讲述了手机QQ在react框架下的全家桶开发套件，以及踩过得各种坑和性能的极致优化
资料参考http://dev.qq.com/topic/579083d1c9da73584b02587d
react 全家桶
在手Q家校群重构之前，其实我们已经做了一版PC家校群。当时将native的页面全部web化，直接就采用了React比较常用的全家桶套装：

构建工具 => gulp + webpack
开发效率提升 => redux-dev-tools + hot-reload
统一数据管理=> redux
性能提升 => immutable + purerender
路由控制器 => react-router(手Q暂时没采用)

构建工具目录结构

React 优化三大方向

状态/数据管理优化

针对React的这个数据比较的深比较deepCompare，要点有2个：

尽量使传入的数据扁平化一点
比较的时候做一些限制，避免溢出栈

渲染性能优化

首屏性能优化

针对有cgi请求，需要吐大量数据的页面–同构直出
有几点值得说明：
比改造以前的项目，做直出更容易
减少的是首屏显示实践，而非首屏可交互时间
页面吐出html字符串之后，还需要在客户端，加载react包，进行事件绑定
做bigPipe之类的优化较难

react同构直出文章
《React同构直出优化总结》http://www.alloyteam.com/2016/06/react-isomorphic/?utm_source=tuicool&utm_medium=referral
《腾讯新闻React同构直出优化实践》 http://www.alloyteam.com/2016/06/tencent-news-react-isomorphic-straight-out-optimization/?utm_source=tuicool&utm_medium=referral
拆包
不用react-router，如何拆包？

非基础功能，如运营活动 —轻量化类react方案
Preact—压缩后只有10kb，gzip后3kb
开源社区有较多的star（认可）
较好的性能和兼容性
api跟React接近
足够的框架周边，配置redux，router等使用，还有同构直出的插件
团队成员有能力维护的
作者参考文章《Preact-React的轻量解决方案》https://github.com/lcxfs1991/blog/issues/13?utm_source=tuicool&utm_medium=referral
简单回购

Starter-Kit
steamer-react
https://github.com/SteamerTeam/steamer-react/tree/react-preact
web分支，同构分支，preact兼容分支
腾讯发起的交流会将于2016-10-23 日举行

《手机淘宝营销互动页面的最佳实践》黄华健（阿里巴巴前端工程师）

呆萌的前端工程师讲的很棒很棒

他鼓励前端开发者们沉淀出自己的最佳实践，同时大家可以去看一下他们开源的解决方案：站在巨人的肩膀上才能看得更远
对比以前需求来了-干活的工作模式，工程化-自动化工作流能提高效率即新一代构建工具 rollup （参考文章 http://jixianqianduan.com/frontend-build/2016/01/20/next-generation-js-module-bunlder.html?utm_source=tuicool&utm_medium=referral）

解析ES2015Module
Tree-shaking

再来总结下rollup： - 支持ES6模块规范打包成其它任一格式规范 - 支持tree-shaking方式打包 - 方便接入构建，如gulp - 需要书写配置任务
索性github上有demo，我还没有来的及实践，抛链接
手机淘宝营销互动脚手架

《从MI Cloud的架构变迁看大型spa的复杂工程如何化简》陈恺睿（小米高级前端工程师）

Mi Cloud的主站就是这样的一个大型的SPA，它主要定位于PC端，PC端包括Web版和桌面应用，同时也兼顾一下移动端。Mi Cloud也正在基于electron开发一个桌面应用
第一次重构
用CommonJS和browserify实现模块化方案，基于grunt实现自动化构建流程替代之前满屏jquery 操作dom
第二次重构
又对工程基础做了进一步的升级，采用标准的ES6的模块规范，加上更强大的webpack实现模块化方案，基于gulp实现自动化构建流程，完全是流式处理，减少硬盘IO，开发环境下进行一次实时编译从原来的20s左右压缩到1s内。最近几年，前端领域新技术层出不穷，其中不乏实实在在能提高生产力的方案，从browserify+grunt到webpack+gulp就是这样一个典型的例子，从backbone到angular再到react+redux也是一个典型的例子。
然后开始拿业务层开刀。当时恰好有一个业务要做比较大的改版，于是我开始基于Backbone实现MVC架构。
得到的是一个基于Backbone的MVC架构

完整的流程：
首先用户操作了界面，比如一个点击，view层抛出事件告诉controller，controller调用model层某个实例的方法，让model层向服务器操作，完了之后，model层抛出事件告诉controller，controller调用view层某个实例的方法，更新界面。
其实，我在实践这套MVC架构的时候，也一直觉得controller部分太复杂，仔细分析一下，controller内主要分为两套流程：步骤2，3是一套流程；步骤5，6是另一套流程。这两套流程其实是互相独立的、互不干涉的，但都流经同一个节点，这无疑加剧了这个节点的复杂度。
model层和view层不知道彼此的存在，甚至不知道controller的存在，它们只是通过抛出事件通知外界自己处于什么状态，比如view中的哪个按钮被点击了，model中的哪个字段有更新了。它们不关心谁监听这些事件。
好处：

model层和view层完全分离，可以由不同的人并行开发
可以不依赖走通整个流程来测试，model层和controller完全没有DOM操作，可以实现自动化的单元测试
要增加或删除功能，只需要开始或停止监听事件即可，层与层之间解耦之后很容易实现对某一部分的替换、增减

于是我将controller的两套流程分离一下，各司其职。
这样，不管是从model层到view层的数据流，还是从view层到model层的数据流，虽然这两个数据流的起点和终点是对调过来的，但它们流经的节点不一样，这样就清晰了很多。
熟悉react和redux的朋友，可能看这幅图会比较眼熟。是的，这个时候已经形成了一个单向数据流的闭环。其实，当时我也不知道这会形成所谓的单向数据流，只是在探索怎么化简复杂度罢了。
架构演变到这一步，其实已经开始了第二轮重构，当时还是2015年夏天，我开始热火朝天的写一些demo尝试这个架构模式。
另一方面，我已经开始尝试将view层组件化，也就是将一个个视图类实现成可组合可嵌套的，在通用的视图类上实现了一套添加子组件/移除子组件等等的API，将整个界面实现成一个个视图实例组成的树状结构。
但其中一直有一些痛点，其中以view层的痛点最加剧业务的复杂度。

于是在view层我改成使用react来实现。业务层只需要写全量渲染的代码，再也不用写局部更新的代码了，框架自己会帮业务层对DOM做局部更新。手动点个赞。
网上也有很多使用backbone的model配合react的文章，其实就类似于我们的架构演变到这一步时的方案。
于是我继续实践，很快又挖出了一个痛点。。
更新组件树中的深层节点时很麻烦。
一开始的做法是，从组件树的根节点一层层的往下传数据，这显然很麻烦。
再次带着问题寻找解决方案。此时redux框架经过多次迭代之后，开始成熟、稳定下来，我发现redux提供的connect函数正好能让我直接把数据传递给组件树中的深层节点。
于是我引入了redux，最终项目的架构就变成了这样

除了为业务降低复杂度的框架，大型SPA的未来还有很多挑战。比如：

强类型，静态类型检查
异常处理的最佳实践
自动化测试的健全：因为基于react这种视图层框架几乎不需要操作DOM，基于redux这种函数式编程思想的框架管理整个应用的状态，副作用和状态都得到很好的控制
控制复杂度的心得。
分治：不管多么庞大的问题，咋一看很复杂，但把它切割成一个个小问题之后，局面就变得清晰了很多。模块化、组件化都是这个思路，我觉得前端的路由也体现了分治的思想，把路由看作一个有限状态机，它就将应用的生命周期划分成了几个大的状态。
善于利用巨人的肩膀：其实，复杂度并不会减少，它只会从一个地方转移到另一个地方，复用组件如此，框架为业务层封装复杂性也是如此，所以，善于利于巨人的肩膀，因为它已经帮你转移了复杂度。
先确认瓶颈再做性能优化：虽然是老生常谈，但还是要强调一下，因为真的很有用但又很容易忘记。
二八原则：考虑项目的生命周期、影响力来衡量投入的资源，好钢用在刀刃上，我个人感觉小米挺强调成本控制的，毕竟我们是创业公司，跟大公司可以适当冗余不太一样。

《UC前端业务套件体系》三桥（阿里巴巴UC移动事业群高级前端工程师）

三桥大神主要讲的偏架构方向，也接近了尾声，实在太累没做过多记录。这里就不在提供摘要，近期会提供相关PPT。

很可惜，只参与了工具1的分会场
更多内容以及PPT会近期发布。