2016iweb峰会参会总结

2016年8月27日去国家会议中心参加iweb峰会。

8点半开始签到入场,8点20分排队签到的人已经排到另一个门口,人超级多啊。

9点一如既往的由h5女神娜姐开场。

上午场

基本是各公司的大佬们介绍各公司产品,回收往事如何抓住机遇,如何赚的人生第一桶金,如何规避风险等。宣传性质居多。

首先是蝴蝶互动ceo 凌海,《HTML5发行的力量》

代表游戏 传奇世界 千年
身为一个程序媛妹子,我基本上是不怎么玩游戏的,对游戏的理解也限于平常身边男同事的聊天中,对游戏不多说。
印象最深的是凌海说的如何规避风险,如何做时间管理,举例说明了有投资方要求360出3年规划,3年对互联网来说时间太长了,3年可能发生很多事,风险是无法预知的;列举自己针对一个需要90天的项目,他们公司往往是比较慎重的,他们会把时间细化到30分钟,相比90天或者3年30分钟的风险是基本可以完全把控的。

白鹭时代CEo 陈书艺 《2016:完成生态闭环,向全行业致敬》

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

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

他从h5游戏的性能方面做了分析,对于h5的未来,他报以谨慎乐观的态度
分析了h5游戏的性能方面
1. webGL性能提高 5~10倍
2. Canvas 脏矩形算法 性能提高2倍
3. 内存占用降低5%
4. 包体减小30%
5.

很快ceo 李明 《社交生态下的HTML5游戏辛新契机》。

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

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

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

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

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

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

野狗是国内领先的实时后端云;
野狗api--最实时通信api来了,应用于各大场景,可实时同步数据,网页通信,实时游戏,运用于汽车,实现实时同步汽车数据等
使用野狗API,可以获得实时后端云的两大功能
1. 实时通信 ,包括消息订阅,推送,双向通信等功能。网络延迟小,服务响应速度快,API简单易用。
2.数据存储,提供了一个Key-Value的云端数据存储,直接通过API就可以对数据进行存取操作。操作简单,按需扩展。

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

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

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

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

下午场 (因为去的人太多了,工具一专场爆满,下午场一直在工具一)

《高性能HTML5 APP 开发云实践——基于完全开源的WeX5开发框架》 王洁 Wex5

主要对原生APP和hybrid app的比较,简述为解决白页多webview 实现转场动画等, 复杂效果native 实现,简单效果h5实现“重混” - wex5 “轻混”,只需前端调用,提供打包平台
WeX5的可视化操作,同我们公司Hy框架比较来说,wex5基于phonegap 源码改造,组价可拖拽组成页面,HY是自己实现的一套,组件开发参考phonegap
wex5,一个纯h5app开放平台,组件风格分离,基于css3,引入bootstrp资源,可快速开发。一次开发,全面拥有安卓app,苹果app,微信服务号。真正的html5 app开发云。

Hybrid App走向“轻混”,剖析WeX5开源高性能HTML5 App开发框架

因为去年参加完D2大会后,我在公司内部做过一次Hybird的分享,主要对百度BlendUI和其他框架对比展开,当时虽然查了很多资料,单由于实际使用不多,对hybird一知半解,分享效果很不理想,我亦耿耿于怀数日,但是当时的辛苦没有白费,昨天再听到wex5 王洁讲述Hybird的时候,易于接受很多~ 所以啊,别因你当下的努力没有效果就懊恼~ 由于本人演讲时易紧张,不善措辞,想用自己的话把wex5解释明白有点困难,遂转载如下文章,供个人参考学习 [http://www.weixinla.com/document/22647975.html]

一. 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技术来弥补了,随着技术的发展,性能已经不再是瓶颈。

2016iweb峰会参会总结

另一个改变了移动应用这一领域的进程事件是,自从微信推出以后,相当于重新定义了移动应用的概念,通过它的服务号、公众号、企业号,微信本身变成了一种应用平台。包括微信最新的版本更新,它浏览器内核的升级,包括对游戏的支持,都和大量的移动App开发有着莫大的关联。而这个时候重混的框架就显得多余了,因为在重混框架里面很多性能的解决是依赖Native的原生部分。而到了微信里面,多WebView和NativeUI都没有了。原来在重混框架里面很强的一些能力完全就消失了,这时候在微信里面就有很多能力就不能用了。

于是轻混就成了目前真正要跨端Hybrid App的必然选择,这时候轻混的UI部分必须用纯Web技术,在底层的设备接口上,GS无法完成的原生部分需要Native技术来弥补。需要强调的是,Native的技术是不应该去侵入UI的,这样的一个框架就是我们所说的轻混Hybrid App框架,这才是真正的HTML5 App框架。
![](media/14723796454471/14723805778403.jpg)
二.构建高性能HTML5 App跨端框架
伴随着以上的观点,接下来谈谈如何构建轻混模式下的HTML5 App框架。这种混合框架很简单,首先要有一个内置了浏览器的外壳,在浏览器里提供网页运行环境,同时在这个外壳上提供很多插件,可以让网络通过GS进行操作。
基于这样的认识,王洁说,在选择HTML5框架设计的时候,要解决两个框架的问题,一个是HTML5的框架,一个是Native的框架。首先看Native框架的选择,选择PhoneGap框架,受到了业内主流厂商支持,微软也是用Cordova,它的插件框架是开放的,很容易自定义。
另外就是要解决HTML5的一些性能问题,如果不采用重混架构的话,在页面切换还是会有一些障碍,王洁说到,WeX5采用SPA单页应用模式,它是基于传统的页面加载模式MPA,页面之间互相独立。但是SPA的不同之处在于,其框架里整个页面是由外壳页面框架组成的,是用AJAX技术完成的,AJAX在桌面时代就存在,通过局部刷新来提升用户体验。但是把AJAX技术最大化来使用,整个页面框架都用AJAX来实现,每个页面的加载都是这样的方式。

2016iweb峰会参会总结

对设备的局部渲染,可以在加载的时候在后面预加载再做转场动画,而且还不需要依赖多Web应用,不需要依赖Native就可以完成。而且在加载多页框架时每个页面的共用功能要重复加载。所以从各方面来说SPA相对于MPA是有极大的性能提升的。
SPA确实很好用,但是在设计产品的时候需要考虑到多人协作过程中,支持复杂应用的开发过程中,会不会出现多个ID会冲突,样式冲突,JS冲突等等致命问题?所以下面就谈到了页面隔离的问题。

2016iweb峰会参会总结

解决这样棘手的问题,王洁说,首先要考虑到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的模块里,这样就把代码自然隔离了。
![](media/14723796454471/14723810488469.jpg) 王洁说他们在外围还做了一些工作,首先是实现完整的外壳管理,Shell类提供外壳管理。为了防止信息泄露,在配置的时候确实会把页面完整卸载掉。当加载页面片断时,会从当前外壳数把JS删掉,页面加载的时候创建的JS对象都会完整的释放掉,这是由框架来保证的。另外是路由的问题,在SPA单页面框架里路由是很重要的,因为是单页面应用,加载的页面都是片断,其实UI地址一直是外壳的地址。 下图是整体框架的架构。黄色部分用的是Cordova,解决安卓和苹果的原生调用问题。同时要兼容微信,所以上面把Cordova和微信又做了封装,抽象成统一的HTML5 API。如果通过统一的Native API去拍照,会自动根据页面环境,通过Cordova接口调用,这样可以更方便的实现一次开发,多端运行,代码不需要改,既可以运行在原生App里,也可以运行在微信里。包括拍照、GPS地图,一系列的API都可以进统一分装。

2016iweb峰会参会总结

Bootstrap在这里提供了几个能力。一个是样式美化,扁平化风格,另外响应式布局。基于Bootstrap设计的页面,运行在不同的设备上不需要考虑分辨率,会自动处理设备分辨率。再上面实现了WeX5的组件框架和数据框架,页面上不仅有交互的UI组件,页面里面还有数据。接下来是业务框架层,即SPA单元页面框架。在服务端WeX5还提供了XBaaS服务,负责后端数据存取、逻辑,还有第三方地图、支付等功能实现。WeX5提供多语言实现,提供了不同语言的版本,开发者可以针对自己的版本来集成到自己的框架里。
三、WeX5可视化快速开发实践
在分享的最后,王洁给大家展示了基于WeX5这样的框架所开发出来的一些功能。首先是可视化的快速开发程度,帮助开发者通过可视化开发定义页面,框架可以保证运行体验,必须能快速加载,而且各种首试、硬件能力的是一体化集成的。把组件拖到表单上定义布局,设置属性,即可得到最终页面,设计室和运行室相邻,完全所见即所得。

2016iweb峰会参会总结

丰富多样的组件,足以适应各种复杂表单的组合。通过把常见功能组件封装,可以极大减轻开发者的开发工作量。最关键的是整个组件框架完全开源,除了WeX5提供的上百个组件以外开发者还可以自己定义这个可视化组件,甚至可以继承第三方组件,通过规范的方式封装成HTML5的可视化组件。
编程问题也是重点,WeX5的定位是可视化程度更高的前端编程工具。不仅可以可视化设计,编程也是便捷。它能实现代码的智能提示、代码模板,还内致了Emmet框架。随后考虑的是调试问题,WeX5是一体化的环境,不仅要解决开发、编程,还要解决调试的过程,既可以在Web浏览器上调试,也可以连到手机上调试,所有代码都是开源的,底层内库也是开放的。最后就是打包的问题,打包要考虑很多插件的配置,参数,资源在命令行的配合。WeX5提供了一个打包的向导,完全本地打包,不需要依赖云打包服务,只需要把打包过程中要设置的东西完全工具化,可以设置应用版本、证书、LOGO、图片、插件里的参数,最后就可以应用到App上。

《web技术推进多样化人机交互方式》Intel的软件工程师 吴栋夏 女

讲述了Intel的各种“黑科技”,还介绍了关于深度增强摄像,场景感知与模型,crosswalk,nw.js

crosswalk

2016iweb峰会参会总结

2016iweb峰会参会总结

nwjs

nwjs是在英特尔开源技术中心创建的,它是基于谷歌浏览器核心引擎和nodejs运行,你可以通过nwjs技术使用html和js语言编写本地应用程序,它也可以让你直接从DOM调用nodejs模块,使用一种新的方式与所有的Web技术编写本地应用。它主要有以下6个特点:

(1)以网络最流行的技术编写原生应用程序的新方法
(2)基于HTML5, CSS3, JS and WebGL而编写
(3)完全支持nodejs所有api及第三方模块
(4)可以使用DOM直接调用nodejs模块
(5)容易打包和分发
(6)支持运行环境包括32位和64位的Window、Linux和Mac OS

《Yo-去哪儿移动UI框架》-杜瑶

瑶姐机智自不必说,网红魅力;

开场前有蹲在我旁边的妹子跟同伴聊天说“瑶姐,原来是个男的啊”,后面还有一位男生听到是去哪儿的遂说“去哪儿的杜瑶是要讲avalon吧“,我和胖子王涛笑哭,不知司徒听到这话会不会哭

虽然用了很长时间Yo,既然是写参会总结,我在这里在整理一下:

YO 一款基于Sass开发的css框架,用于快速构建移动UI项目

mobile First
  • why mobile First (以mobile作为基准的设计为出发点)
    1. 公司战略转移
    2. 新战场需要有力的框架抹平平台切换所带来的适应过程
    3. pc端已有成熟的解决方案,无需推倒重来
    4. 专注于某一具体的领域更能变得专业
  • mobile First 的好处
  1. 可以减少对历史问题的考虑,不如不用考虑IE
  2. 保证交互方式的单一性,不用考虑PC上的交互行为
  3. 更及时的应用上新技术
  4. 代码更轻量
ios 默认风格
  • why ios
    1. 巨量的ios用户(超过50%)
    2. 安卓碎片化过重,不易挑选标示
    3. ios的交互及展现更具备普适性
Pure CSS 纯粹的css 框架

why pure css

  1. 职能更分明
  2. 能被使用在任何项目中
  3. 不紧密捆绑UI组件
分层设计

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

yo|---usage

|---lib

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

rem+px

  • 边框厚度使用px单位
  • 字体,大小等除边框厚度外的定义使用rem

    解决实现retina屏真正的1px 边框问题

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

下面是瑶姐展示的一些demo:

大致是使用scss语法 @include XX(yo定义好的插件模块eg: circle(2rem) ellipsis)

独立配置层设计 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暂时没采用)

构建工具目录结构

2016iweb峰会参会总结

React 优化三大方向

  1. 状态/数据管理优化

    针对React的这个数据比较的深比较deepCompare,要点有2个:
    • 尽量使传入的数据扁平化一点
    ![](media/14723796454471/14723916417700.jpg)
    ![](media/14723796454471/14723917054772.jpg)
    • 比较的时候做一些限制,避免溢出栈
  2. 渲染性能优化

    2016iweb峰会参会总结

    2016iweb峰会参会总结

    2016iweb峰会参会总结

  3. 首屏性能优化

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

他鼓励前端开发者们沉淀出自己的最佳实践,同时大家可以去看一下他们开源的解决方案:站在巨人的肩膀上才能看得更远

对比以前需求来了-干活的工作模式,工程化-自动化工作流能提高效率即新一代构建工具 rollup (参考文章 http://jixianqianduan.com/frontend-build/2016/01/20/next-generation-js-module-bunlder.html?utm_source=tuicool&utm_medium=referral)

  1. 解析ES2015Module
  2. Tree-shaking

    2016iweb峰会参会总结

    2016iweb峰会参会总结

    这里实在看不清楚

    2016iweb峰会参会总结

    再来总结下rollup: - 支持ES6模块规范打包成其它任一格式规范 - 支持tree-shaking方式打包 - 方便接入构建,如gulp - 需要书写配置任务

索性github上有demo,我还没有来的及实践,抛链接

手机淘宝营销互动脚手架 https://github.com/amfe/activity-template

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

ppt 地址 https://pan.baidu.com/s/1kVwbDsV
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架构

    2016iweb峰会参会总结

    完整的流程:

    首先用户操作了界面,比如一个点击,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操作,可以实现自动化的单元测试

• 要增加或删除功能,只需要开始或停止监听事件即可,层与层之间解耦之后很容易实现对某一部分的替换、增减

2016iweb峰会参会总结

于是我将controller的两套流程分离一下,各司其职。

这样,不管是从model层到view层的数据流,还是从view层到model层的数据流,虽然这两个数据流的起点和终点是对调过来的,但它们流经的节点不一样,这样就清晰了很多。

熟悉react和redux的朋友,可能看这幅图会比较眼熟。是的,这个时候已经形成了一个单向数据流的闭环。其实,当时我也不知道这会形成所谓的单向数据流,只是在探索怎么化简复杂度罢了。

架构演变到这一步,其实已经开始了第二轮重构,当时还是2015年夏天,我开始热火朝天的写一些demo尝试这个架构模式。

另一方面,我已经开始尝试将view层组件化,也就是将一个个视图类实现成可组合可嵌套的,在通用的视图类上实现了一套添加子组件/移除子组件等等的API,将整个界面实现成一个个视图实例组成的树状结构。

但其中一直有一些痛点,其中以view层的痛点最加剧业务的复杂度。

2016iweb峰会参会总结

2016iweb峰会参会总结

于是在view层我改成使用react来实现。业务层只需要写全量渲染的代码,再也不用写局部更新的代码了,框架自己会帮业务层对DOM做局部更新。手动点个赞。

网上也有很多使用backbone的model配合react的文章,其实就类似于我们的架构演变到这一步时的方案。

于是我继续实践,很快又挖出了一个痛点。。

更新组件树中的深层节点时很麻烦。

一开始的做法是,从组件树的根节点一层层的往下传数据,这显然很麻烦。

再次带着问题寻找解决方案。此时redux框架经过多次迭代之后,开始成熟、稳定下来,我发现redux提供的connect函数正好能让我直接把数据传递给组件树中的深层节点。

于是我引入了redux,最终项目的架构就变成了这样

2016iweb峰会参会总结

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

•	强类型,静态类型检查
• 异常处理的最佳实践
• 自动化测试的健全:因为基于react这种视图层框架几乎不需要操作DOM,基于redux这种函数式编程思想的框架管理整个应用的状态,副作用和状态都得到很好的控制

控制复杂度的心得。

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

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

作者出过书

2016iweb峰会参会总结

2016iweb峰会参会总结

  • scrat2 scrat3

    2016iweb峰会参会总结

http://www.doc88.com/p-1896013152047.html

https://github.com/scrat-team/scrat

上一篇:今天装了一个RTI工具


下一篇:推荐eclipse velocity一款插件 --- veloeclipse