在 Node.js 如火如荼发展的今天,我们已经可以用它来做各种各样的事情。前段时间UP主参加了极客松活动,在这次活动中我们意在做出一款让“低头族”能够更多交流的游戏,核心功能便是 Lan Party 概念的实时多人互动。极客松比赛只有短得可怜的36个小时,要求一切都敏捷迅速。在这样的前提下初期的准备显得有些“水到渠成”。跨平台应用的 solution 我们选择了 node-webkit,它足够简单且符合我们的要求。 按照需求,我们的开发可以按照模块分开进行。本文具体讲述了开发 Spaceroom(我们的实时多人游戏框架)的过程,包括一系列的探索与尝试,以及对 Node.js、WebKit 平台本身的一些限制的解决,和解决方案的提出。

Getting started

Spaceroom 一瞥 {#spaceroom-} 在最开始,Spaceroom 的设计肯定是需求驱动的。我们希望这个框架可以提供以下的基础功能:

  • 能够以 房间(或者说频道) 为单位,区分一组用户
  • 能够接收收集组内用户发来的指令
  • 在各个客户端之间对时,能够按照规定的 interval 精确广播游戏数据
  • 能够尽量消除由网络延迟带来的影响 当然,在 coding 的后期,我们为 Spaceroom 提供了更多的功能,包括暂停游戏、在各个客户端之间生成一致的随机数等(当然根据需求这些都可以在游戏逻辑框架里自己实现,并非一定需要用到 Spaceroom 这个更多在通信层面上工作的框架)。

APIs {#apis} Spaceroom 分为前后端两个部分。服务器端所需要做的工作包括维护房间列表,提供创建房间、加入房间的功能。我们的客户端 APIs 看起来像这样:

  • spaceroom.connect(address, callback) – 连接服务器
  • spaceroom.createRoom(callback) – 创建一个房间
  • spaceroom.joinRoom(roomId) – 加入一个房间
  • spaceroom.on(event, callback) – 监听事件
  • ……  

客户端连接到服务器后,会收到各种各样的事件。例如一个在一间房间中的用户,可能收到新玩家加入的事件,或者游戏开始的事件。我们给客户端赋予了“生命周期”,他在任何时候都会处于以下状态的一种:

ss_0 你可以通过 spaceroom.state 获取客户端的当前状态。 使用服务器端的框架相对来说简单很多,如果使用默认的配置文件,那么直接运行服务器端框架就可以了。我们有一个基本的需求:服务器代码 可以直接运行在客户端中,而不需要一个单独的服务器。玩过 PS 或者 PSP 的玩家应该清楚我在说什么。当然,可以跑在专门的服务器里,自然也是极好的。 逻辑代码的实现这里简略了。初代的 Spaceroom 完成了一个 Socket 服务器的功能,它维护房间列表,包括房间的状态,以及每一个房间对应的游戏时通信(指令收集,bucket 广播等)。具体实现可以参看源码。 查看更多

在移动 App 开发领域,主流的开发模式可分为 Native、Hybrid、WebApp 三种方式。然而 2013 年,纯 WebApp 开发模式的发展受到一定挫折,以 Facebook 为代表的独立 App 转投 Native 阵营。但是开发者对 WebApp 更新速度快,跨平台优势的渴望却并未减弱,最终的结果是促成了 Hybrid App 在 2013 年数量的激增,并且增长的速率非常之快。 简单的说,Hybrid App是 Native App 和 Mobile Web 二者混合开发的产物,HTML5 的页面被嵌入到 Natvie App 的 webview 中。因此它综合了更新速度快,交互体验好,跨平台等优点。

本文分享的就是 HTML5 页面(尤其是被嵌入的 H5 应用) 借助 Hybrid 架构来提升自己的加载速度和性能的一种解决方案。该方案要求你对 Hybrid App 进行以下三步骤的改造:

一:模块化你的 H5 页面/应用,引入模块加载器(可选)

模块加载器不必多说,SeaJS、requireJS、kissy loader 等耳熟能详,任你挑选。使用模块化的方式来开发你的应用,不仅仅将有利于后期的代码维护,在 Hrbrid 的架构中,还将会有利于性能的提升。

或许你有疑问:模块开发粒度越细化,加载时请求的JS、CSS等静态资源的数量越多,页面的性能不会越差吗?我的回答是:如果你仅仅是使用了模块加载器并异步加载各个模块,那么加载的性能一定很差,因为请求的数量太多。当然你肯定会想到在发布前打包合并静态资源,那么对这样的解决方案我只能给到 50 分,因为被打包合并的文件中只要有一个子文件发生变化,那么整个文件(JS或CSS)都要被重新下载,对移动带宽而言还是个负担。

怎么破?请继续进行步骤二:

二:启用 AppCache ,并引入增量更新机制

做过 WebApp 的同学应该会了解 mainfest 文件,Html5提供的应用缓存功能,开发者只要把需被缓存的静态资源文件名罗列在这个列表中即可保证二次访问时无需重新加载。看起来不错!这样前面说的模块化开发造成的请求数量过多的问题,至少在二次访问时不会再发生了。嗯,这样的方案可以给到 70 分吧。其实,Html5 提供的 mainfest 缓存机制有个比较大的问题(兼容性就先不提了):如果 mainfest 列表中的一个资源文件需要更新,那么整个 mainfest 中的其它文件也都需要被重新下载一遍。 也即是说二次访问没有问题了,但是 Html5 应用更新时还是会出现全量下载的问题。

别忘了,我们是 Hybrid App,还可以充分利用 Native 层的强大能力,所以抛弃mainfest吧,让 Native 来帮助 Html5 应用缓存静态资源文件。总体思路是:

1、Html5 应用首次启动时,调用 Native 提供的加载资源文件专用的 Device API 来请求所需的资源文件,由 Native 层发出真正的资源请求,并将请求结果缓存在手机的SD卡上。当然,这里完全可以优化为一次 zip 包请求,因为 native 能够提供强大的解压能力。

2、H5 应用再次启动时,所有的静态资源都是通过 Device API 读取本地缓存,无需再走网络。

3、H5 应用出现静态资源更新时,在应用启动时首先通过 Device API 加载需要更新的文件,并更新本地缓存,其它未变更文件继续走缓存。

流程看起来挺顺,其中有几个关键问题需要解决:

1、如何通过 Device API 加载资源文件?

这里使用模块加载器的优势就体现出来了,只需要在加载器中做点小修改,不直接走Http请求了,而直接调用 Native 提供的文件加载 DeviceAPI 即可。 如果你没有模块加载器,就需要写统一的函数来做加载资源的功能了。

其实 Native 也提供了拦截机制,能够拦截到 H5 应用发出的所有 Http 请求并进行自定义处理,可惜这样好的功能在 Andorid 4.0 以下版本不支持。 故现阶段还是主动调用 Device API 更靠谱。

2、何时需要进行静态资源的更新?

每次静态资源发布都会产生一个唯一的发布时间戳(或是所有资源内容的MD5编码),H5应用启动后,可将当前时间戳保存下来,等应用下次启动时,请求最新的发布时间戳并与本地时间戳进行对比,若不同,则首先进行静态资源的增量更新。

3、如何判断哪些是需要被增量更新替代的静态资源文件?

这个问题的回答会比较复杂些,核心思路是通过对前后两次资源文件(js、css、image等)发布的内容对比完成:

如此,H5 应用借助 Native 应用的能力完成了资源的缓存与增量更新,可以保证 H5 应用在启动与更新时的加载速度。当然也有方案借助 HTML5 的 localstorage 来替代 Native 的缓存更新策略,但是可能会受到两处限制:

1、若 Hybrid App 比较复杂,涉及多个子域甚至主域间的静态资源共享,则 localstorage 的方案首先要解决跨域访问的问题,并且在每个子域存储空间上存在上限,是 5M。

2、Native 能够支持更新包的 zip 打包下载,一次请求,然后解压并更新本地缓存。而 localstorage 无法实现。

若应用中以上两点不是问题,则使用 localstorage 缓存的策略完全 OK。

三:启用 spdy 协议

spdy 协议在移动开发上大有可为,它是HTTP协议的增强版本,能够通过一次TCP链接同时请求到多个资源文件,请求速度上的提升那是自然的了,非常强大!chrome 等 webkit 内核浏览器都已经支持。 可惜若是借助浏览器自身使用 spdy 协议则要求静态资源服务(js、css、image)必须是 https 的域名服务,且后台server 能支持spdy协议。相信大多数静态服务器都还是http 服务,是无法通过浏览器来直接支持的。(最近有个好消息是集团的大部分静态CDN服务会提供 spdy 协议支持)

还是那句话,因为我们是 hybrid 应用,可以发挥native的优势! native 层完全可以实现基于 spdy 协议请求的 device API,供 H5 应用(JS)来调用。这样就不需要 https 域名服务器也能使用 spdy了。

如果你的 Hybrid 应用已经支持了 spdy 协议,那么你可以考虑不再需要把增量更新的资源文件打包成 zip 下载了,直接 spdy 协议并行下载即可!

SPDY 与 HTTP 协议速度对比:

以上解决方案已应用在1688主客户端5.0版本的架构设计中,有改进之处,欢迎探讨~

2014年2月22日下午1:30,1688技术部在滨江园区举办了杭州前端下线聚会交流活动。

聚会共分为《前端无线开发实践》、《用户行为采集、大数据》、《NodeJS 的实践及应用》,《前端集成开发环境》等四个开放式的分组主题讨论,

每个分组先由阿里前端同学介绍相关主题及开发经验,参与同学积极发表自己对分享的看法和平时的工作经验,起到共同交流的作用。分组讨论结束后,分组成员自由交换分组,继续讨论感兴趣的话题。

活动中还由阿里前端同学进行技术演示:PSD2HTML,Lofty前端基础框架,服务端的AMD加载器,积木盒子。

本次聚会共到场40余位同学,还有3位对前端开发感兴趣的后台同学,收到20份反馈表。摘录部分反馈:

  1. 收获很多,会议流程很合理,建议举办多次这样的会议
  2. 前端的集成开发环境,解决了前端人员的实际问题,提高了开发效率。
  3. 非常好,但第二阶段的主题不明确
  4. 认识很多人,初步认识了前端得开发过程和关注的重点,建议下次有一个前沿的热点

一位厂外前端童鞋(申若亮)对聚会过程的详细记录《阿里前端聚会记录
查看更多

为什么要来这:

  • 1、大型站点——大型web站点的开发建设让你有更快的成长并充满成就感。
  • 2、技术创新——HTML5、CSS3,这里有吸引前端开发攻城狮的土壤。
  • 3、性能优化——前端代码的效率、性能是你追求的方向,一同创建用户体验最好的站点是我们的梦想。

职位描述:

  • 1、阿里巴巴中文站新一代前端框架设计及UI组件库开发;
  • 2、前端通用工具平台的开发及建设;
  • 3、中文站核心业务产品线的前端开发工作。
  • 4、H5无线应用开发。
  • 5、各方向都紧缺人才,期待你的加入!

职位要求:

  • 1、掌握良好的前端技能,包括XHTML/XML/CSS/Javascript,了解WEB标准化、性能优化方法,了解可用性、可访问性和安全性。
  • 2、熟悉掌握一种常见JS框架,如Jquery,YUI,ExtJS等
  • 3、热爱前端,热爱设计,对新鲜事物充满好奇心,有折腾的想法和精力,喜欢捣鼓各种互联网应用。
  • 4、自我管理能力强良好,崇尚团队合作,快速的学习能力,乐于分享与沟通。
  • 5、有Web后端脚本的语言(如Java/PHP/C#/C++/Python)开发经验者优先。

简历请发送到:terence.wangt@alibaba-inc.com

职位有效期:2014-6-30前

最近看到前端趋势2013大会上的一篇文章,题目是《各位快看,不用后端》,觉得有点意思,恰好近期的一次讨论及半年前的一次开发实践也涉及到这种模式,简单谈谈我的想法。

不得不说,文章的题目确实很吸引眼球,开发应用可以不用后端了?前端同学完全自己搞定?那服务器、数据库、服务接口神马的怎么办?

说到这,大家可能会想到开放平台,开放平台不就是这种的架构模式吗?服务器、底层数据、OpenAPI大公司都给你提供了,前端同学完全可以通过JS来操作各种数据,把注意力集中在显示层上,独自完成一个应用的开发。

纵观国内的开放平台可以分为两大类:

一种是业务接口开放平台,比如1688开放平台,目的是为了让开发者围绕其业务生态圈创建自己的应用,它只提供业务型OpenAPI,开发者还是需要搭建自己的服务器,甚至是数据库等,算不上noBackend。

另一种是玩“云”概念的开放平台,比如GAE、BAE、阿里云等,他们提供的是服务器和存储(数据库),OpenAPI也有,但通常是比较底层的和业务无关的通用型接口,如存储,消息通信等,真正的业务接口还是需要用后台语言开发,也算不上是文章所谓的noBackEnd。

而国外目前有另外一种类型的开放平台,可以说是为移动应用而生的 (PC站点也能支持),它真正的做到了noBackEnd。 我之前曾折腾过一个移动小应用,偶然接触了Titanium Cloud Services,真是感觉相见恨晚,佩服至极。。。服务器、数据库就不必说了,对开发者完全透明。而他的亮点在于OpenAPI,不像国内的那种纯底层接口,而是暴露给应用一些更偏向业务层面的通用API,比如用户注册API、好友关系API、json格式的KV存储API、文件处理API等等。这些通用接口组合起来,解决80%应用的后端逻辑是不成问题的。

有了这样的开放平台,应用开发时就可以完全通过js来完成各类业务逻辑,而无需进行任何的后台开发和配置工作,对开发应用的前端同学而言,这听起来貌似不错。类似这样的平台国外还有几个,比如 Firebase, ParseBackendless。而国内的我尚未发现,但我觉得这种开放平台应该会很有市场,谁用过谁知道。。。 对一些大公司而言这是不是一个机会呢?

noBackEnd的开发模式其实对前端同学提出了更高的开发能力要求,当后端的模板层完全撤去,只剩下纯净的数据接口时,意味着js将负责更多的业务逻辑处理,代码的组织架构需要有更好的设计。责任大了,压力也自然不会小,据闻腾讯盛行这种开发模式,而其配有500+的前端开发队伍,也就完全可以理解了。

不管你信不信,我是相信noBackEnd的趋势的,应用致胜的关键是idea及用户体验,后台的服务功能是趋同并可抽象的,也因此有了新型开放平台的存在,让我们不必再重复开发后台逻辑;而显示层的设计是无法趋同的,对体验的追求不会有极致,更多的精力和开发将会投入其中。

移动开发之touch event篇

一、前言

如今,智能手机和平板电脑越来越普及, 越来越多的人用过移动设备浏览网页。移动设备的流量已经占到北美网络总流量的20%(http://allthingsd.com/20120525/mobile-devices-now-make-up-about-20-percent-of-u-s-web-traffic/)。幸好目前最流行的两大移动操作系统IOS和Android都具备了解析标准的HTML、CSS和JS的能力,网页开发者还是可以用桌面浏览器来开发网页。通过这两个系统上的浏览器看到的网页和我们桌面浏览器上看到的网页几乎是一致的。虽然看起来是一致的,但是在交互上面还是有一些区别的,最大的区别就是,这些移动设备都没有鼠标,我们平时在桌面浏览器上用的鼠标事件,在移动设备浏览器上用起来怪怪的。想要发挥移动设备触摸屏的特点,给用户提供良好的体验,就要用到浏览器的触摸事件。

二、开发准备(Android)

Android设备可以使用ADB(Android Debug Bridge)来调试android程序,也可以通过ADB来调试移动版Chrome中的网页。

ADB调试说明

http://developer.android.com/tools/help/adb.html

远程调试使用说明

https://developers.google.com/chrome-developer-tools/docs/remote-debugging

查看更多

工作地点:杭州

简历请发送到:terence.wangt@alibaba-inc.com

职位有效期:2013-12-31前

来做的事:

1、阿里巴巴中文站新一代前端框架设计及UI组件库开发。

2、前端通用工具平台的开发及建设。

3、除此之外,还得研究些新玩意,尽情发挥你的创造力。

4、总之,不会让你做码农。

 

职位要求:

1、掌握良好的前端技能,包括XHTML/XML/CSS/Javascript,了解WEB标准化、性能优化方法,了解可用性、可访问性和安全性。

2、熟悉掌握一种常见JS框架,如Jquery,YUI,ExtJS等,并有一定的前端框架设计能力。

3、热爱前端,热爱设计,对新鲜事物充满好奇心,有折腾的想法和精力,喜欢捣鼓各种互联网应用。

4、自我管理能力强良好,崇尚团队合作,快速的学习能力,乐于分享与沟通。

5、有Web后端脚本的语言(如Java/NodeJS/PHP/C#/C++/Python)开发经验者优先。

jQuery选择器探讨进阶

jQuery选择器探讨

在jQuery中,当用户把选择器表达式作为参数传递给$()函数时,jQery的Sizzle先对这个选择器表达式进行语法分析,然后再决定如何获得表达式所代表的这些元素。在框架底层,Sizzle应用了浏览器所支持的最高效的DOM 方法来获取一个节点列表(nodeList),这个节点列表是一个类似于数组的对象的DOM元素的集合。下面的列表展示了jQuery的Sizzle内部采用的浏览器DOM遍历方法和浏览器的支持情况:

  1. 1. .getElementById()  浏览器支持情况:IE 6+, Firefox 3+, Safari 3+, Chrome 4+, and Opera 10+;
  2. 2. .getElementsByTagName()  浏览器支持情况:IE 6+, Firefox 3+, Safari 3+,Chrome 4+, and Opera 10+;
  3. 3. .getElementsByClassName() 浏览器支持情况:IE 9+, Firefox 3+, Safari4+, Chrome 4+, and Opera 10+;
  4. 4. .querySelectorAll() (这个是浏览器内置的css选择符查询元素方法,比getElementsByTagName和getElementsByClassName效率要高很多。)浏览器支持情况:IE 8+, Firefox 3.5+, Safari 3+, Chrome 4+, and Opera 10+;

查看更多

jQuery事件编写进阶

jQuery事件编程进阶

事件委托,是一种优化DOM元素事件绑定的技巧,利用事件冒泡的原理,通过绑定事件到父元素,检查event触发元素的target,最终执行相应的事件函数处理,它的几个好处一般前端开发程序员都知道。在jQuery中,一般是delegate()方法和.live()方法,但是,如何选择事件委托的方法,或者在什么情况下用.live(),什么情况下用.delegate(),这个值得讲一讲:

live: function( types, data, fn ) {
      jQuery( this.context ).on( types, this.selector, data, fn );
      return this;
    }
delegate: function( selector, types, data, fn ) {
      return this.on( types, selector, data, fn );
}

查看这2个事件委托的源代码可知,live方法中,有个元素的执行环境,这个执行环境默认是document,所以,如果把live事件委托写在$(document).ready(function() {})之外,也是没有问题的。live()在某种情况下会引起性能问题,这主要包括2个方面:1.live()方法虽然避免了绑定事件处理到很多DOM元素,但是,它在一开始选择了文档中的所有元素,如果一个文档有很多的子节点,比如文档中的一个表有几十列,几百行表内容,而事件要绑定到这个表的某一行某一列,那么,live()方法在一开始选择这个表的所有行,所有列的时候,就是一个非常大的性能消耗,会导致脚本反应很迟钝。2.因为live()是绑定到document上面,所以会有大量的事件冒泡,事件冒泡要从嵌套最深的DOM元素往上一直冒到document上面,这样长路径的事件冒泡也是一个很昂贵的性能消耗。而采用.delegate(),事件绑定到$()函数的选择表达式元素上,因此页面的事件注册更加清晰,而事件冒泡更少。

查看更多

    CSS选择符由一些初始化参数组成,这些参数指明了要应用这个CSS规则的页面元素。作为一个网站的前端开发工程师,应该避免编写一些常见的开销很大的CSS选择符模式,尽量编写高效的CSS选择符,从而加快页面的渲染速度,缩短页面呈现时间。

我们先来看一下safari和webkit的架构师David Hyatt的两段话:

  1. 样式系统从最右边的选择符开始向左进行匹配规则。只要当前选择符的左边还有其他选择符,样式系统就会继续向左移动,直到找到和规则匹配的元素,或者因为不匹配而退出
  2. 如果你非常在意页面的性能那千万别使用CSS3选择器。实际上,在所有浏览器中,用 class 和 id 来渲染,比那些使用同胞,后代选择器,子选择器(sibling, descendant and child selectors)对页面性能的改善更值得关注。

Google 资深web开发工程师Steve Souders对CSS选择器的效率从高到低做了一个排序:

1.id选择器(#myid)2.类选择器(.myclassname)3.标签选择器(div,h1,p)4.相邻选择器(h1+p)5.子选择器(ul < li)6.后代选择器(li a)7.通配符选择器(*)8.属性选择器(a[rel=”external”])9.伪类选择器(a:hover,li:nth-child)

上面九种选择器中ID选择器的效率是最高,而伪类选择器的效率则是最底。详细的介绍大家还可以点击Writing efficient CSS selectors

综合上面的顺序,我们清楚的知道,id和类名用于关键选择器上效率是最高的,而CSS3的仿伪类和属性选择器,虽然使用方便,但其效率却是最低的

知道了基本原理以后,我们编写CSS时就应该注意了。下面举几个例子,让大家理解的更透彻一些:

1.不要在编写id规则时用标签名或类名

  1. BAD
  2. button#backButton {…}
  3. BAD
  4. .menu-left#newMenuIcon {…}
  5. GOOD
  6. #backButton {…}
  7. GOOD
  8. #newMenuIcon {…}

由于样式系统从最右边的选择符开始向左进行匹配,只要当前选择符的左边还有其他选择符,样式系统就会继续向左移动,直到找到和规则匹配的元素,或者因为不匹配而退出,所以,在button#backButton {…}中,样式系统先找到id为backButton的元素,然后继续向左匹配,查看该元素的标签名是不是button,如果不是,查找下一个id为backButton的元素,再检查这个元素的标签名,如此周而复始,直到到达文档末尾。如果只是#backButton {…},则样式系统找到id为backButton的元素后,因为左边没有其他选择符了,它就退出而结束查找了。

另外,根据HTML规范,id在HTML中是唯一的,也就是说一个HTML页面只限定有一个id为“XX”的元素,而不限制拥有这个ID元素的标签名,所以,在button#backButton {…}中,button标签完全是无意义的,可以,而且应该去掉,button#backButton {…}与#backButton {…}是等价的。在#backButton前多写了button,只会引起样式系统向左移动,继续查找页面元素,损耗页面性能,延长页面渲染时间。

另一方面,在id元素前面添加标签名,还会引起另一个致命的问题,比如原来id为backButton的标签名是button,如果原来样式声明写成button#backButton {…},则现在需要把button标签改成input,id不变,则button#backButton {…}声明的样式规则在这个id同样为backButton的input元素上不起作用,不信大家可以自己动手编写试一下。

2.不要在编写class规则时用标签名

  1. BAD
  2. treecell.indented {…}
  3. GOOD
  4. .treecell-indented {…} //语言化和标签名绑在一起 假设treecell
  5. BEST
  6. .hierarchy-deep {…} //语言化和标签名无关

原理参考第一条。

3.把多层标签选择规则用class规则替换,减少css查找

  1. BAD
  2. treeitem[mailfolder=”true”] > treerow > treecell {…}
  3. GOOD
  4. .treecell-mailfolder {…}

4.避免使用子选择器

现在我们来看看David Hyatt的第3段话:后代选择器在CSS中是最昂贵的选择器。贵得要命——尤其是把它和标签或通配符放在一起!

  1. BAD
  2. treehead treerow treecell {…}
  3. BETTER, BUT STILL BAD (see next guideline)
  4. treehead > treerow > treecell {…}

标签后面最好永远不要再增加子选择器

  1. BAD
  2. treehead > treerow > treecell {…}
  3. GOOD
  4. .treecell-header {…}
  5. BAD
  6. treeitem[IsImapServer=”true”] > treerow > .tree-folderpane-icon {…}
  7. GOOD
  8. .tree-folderpane-icon[IsImapServer=”true”] {…

5.依靠继承

  1. BAD
  2. #bookmarkMenuItem > .menu-left { list-style-image: url(blah) }
  3. GOOD
  4. #bookmarkMenuItem { list-style-image: url(blah) }

最后,我们来做个总结,网站编写CSS时,应该优先考虑使用class选择器,避免使用通配符选择器(*)和属性选择器(a[rel=”external”]),后代选择器与标签选择器结合使用也应避免。使用id选择器的性能最好,但是编写时要注意其唯一性,谨慎使用。CSS3选择器(例如::nth-child(n)第n个孩子)在帮助我们锁定我们想要的元素的同时保持标记的干净和语义化,但事实是,这些花哨的选择器让更多的浏览器资源被密集使用。引用David Hyatt关于CSS3选择器的论述:如果你关心页面性能的话,他们真不该被使用!

  1. 英文文档参考资源:
  2. http://blog.archive.jpsykes.com/151/testing-css-performance/
  3. http://blog.archive.jpsykes.com/152/testing-css-performance-pt-2/
  4. http://blog.archive.jpsykes.com/153/more-css-performance-testing-pt-3/
  5. Testing CSS Performance  Jon Sykes
  6. https://developer.mozilla.org/en-US/docs/CSS/Writing_Efficient_CSS?redirectlocale=en-US&redirectslug=Writing_Efficient_CSS
  7. •Original Document Information
  8. •Author: David Hyatt
  9. •Original Document Date: 2000-04-21
  10. •Original Document URL: http://www.mozilla.org/xpfe/goodcss.html
  11. http://css-tricks.com/efficiently-rendering-css/
  12. (Efficiently Rendering CSS)
  13. https://developers.google.com/speed/docs/best-practices/rendering?hl=zh-CN
  14. (google建议)

Web前端性能优化WPO,相信大多数前端同学都不会陌生,在各自所负责的站点页面中,也都会或多或少的有过一定的技术实践。可以说,这个领域并不缺乏成熟技术理论和技术牛人:例如Yahoo的web站点性能优化黄金法则,以及大名鼎鼎的优化大师Steve Souders。本文并非一篇讨论性能优化技术方法的文章,而更多的是对中文站搜索List页面持续两年多的前端性能优化实践的思路总结。希望对正在从事这个领域研究的前端同学能有所帮助。

简单的说,我们的性能优化实践分为三个阶段:初探期、立规期、创新期, 每个阶段大概持续半年左右,有足够的时间形成一些优化思路的沉淀。

一:初探期 

2010年底我们开始接手搜索List页面,这是中文站历史最为悠久的页面之一,当时它的生命体征正如它的年龄一样,非常虚弱:当时的基调网络监控显示,页面的完全加载的时间是16秒!作为以“快”为核心业务指标的搜索页面,这个状态显然已是无法承担重任了。

性能是一定要优化的,但我们也面临着大多数前端同学所面临的共性问题 — 业务需求紧张,况且我们是刚刚接手这个业务,非常不熟悉,别说是优化了,就是做个小需求也都经常出现线上故障。就是在这样的情况下,我们开始了搜索页面的性能优化之路,并且给自己定下了当时看起来非常难以实现的目标:在2011年年中前把全页面加载时间降低到7秒以下。

我们很快成立了一个性能优化小组,3-4个前端同学参与其中,一个人的力量毕竟有限,尤其是应对这样一个历史业务繁多的页面。参与的同学多些,技术氛围也相对浓烈,大家很全面的分解了目前页面上出现的性能瓶颈,并分别领取了自己的优化任务。

在这个阶段里,我们基本是照葫芦画瓢,把雅虎性能优化的那些法则与我们的页面一一对照,完成了许多优化点,例如:

  • 小图片的合并,形成CSS Sprite,并优化图片
  • 模块的异步加载
  • 图片的懒加载
  • CSS文件引用放在页面顶部,JS文件引用放在页面底部,并对代码压缩
  • 缩小cookie体积
前人的技术理论果然是靠谱,经过我们半年时间加班加点的性能优化后,我们奇迹般的达成了优化目标!(附性能曲线图)

查看更多

上文中我们讲述了在一个星球上发生的有关overflow:hidden的故事。这次,我们再欣赏下她另一个迷人之处。其实,关键也不是她啦。而是由于她会引起BFC(Block Formatting Context)。BFC又是什么?什么情况会创建BFC?它有什么用?其实在写代码时经常会遇到。

什么是BFC

BFC(Block Formatting Context),简单讲,它是提供了一个独立布局的环境,每个BFC都遵守同一套布局规则。例如,在同一个BFC内,盒子会一个挨着一个的排,相邻盒子的间距是由margin决定且垂直方向的margin会重叠。而float和clear float也只对同一个BFC内的元素有效。

什么情况产生BFC

W3C标准中这样描述:

Floats, absolutely positioned elements, block containers (such as inline-blocks, table-cells, and table-captions) that are not block boxes, and block boxes with ‘overflow’ other than ‘visible’ (except when that value has been propagated to the viewport) establish new block formatting contexts for their contents.

非块级盒子的浮动元素、绝对定位元素及块级容器(比如inline-blocks,table-cells和table-captions),以及overflow属性是visible之外任意值的块级盒子,都会创建了一个BFC。即当元素CSS属性设置了下列之一时,即可创建一个BFC:

  • float:left|right
  • position:absolute|fixed
  • display: table-cell|table-caption|inline-block
  • overflow: hidden|scroll|auto

查看更多

overflow:hidden真的失效了吗

项目中常常有同学遇到这样的问题,现象是给元素设置了overflow:hidden,但超出容器的部分并没有被隐藏,难道是设置的hidden失效了吗?
其实看似不合理的现象背后都会有其合理的解释。

我们知道,overflow属性值有这几种:
visible:声明内容不会被剪裁。比如内容可能被渲染到容器外面。
hidden:声明内容将被剪裁,并且也甭想使用滚动条来查看剪裁掉的内容。
scroll:声明内容将被剪裁,但有可能出现滚动条来查看被剪裁掉的内容。滚动条出现的位置在inner border adge和outer padding adge之间。
auto:声明决策将依赖于客户端,优先使用scroll。

W3C标准中指明:
通常一个盒子的内容是被限制在盒子边界之内的。但有时也会产生溢出,即部分或全部内容跑到盒子边界之外。溢出将在满足下列条件之一时出现:
1. 一个不换行的行元素宽度超出了容器盒子宽度。
2. 一个宽度固定的块元素放在了比它窄的容器盒子内。
3. 一个元素的高度超出了容器盒子的高度。
4. 一个子孙元素,由负边距值引起的部分内容在盒子外部。
5. text-indent属性引起的行内元素在盒子的左右边界外。
6. 一个绝对定位的子孙元素,部分内容在盒子外。但超出的部分不是总会被剪裁。子孙元素的内容就不会被子孙元素和其包含块之间的祖先元素的overflow的设置所剪裁。

当溢出发生时,overflow属性约定了容器盒子是否剪裁掉超出其内边界的部分,并且决定是否出现滚动条来访问被剪裁掉的内容。它会影响到元素所有内容的剪裁,但有个例外情况,即上面第6条所提到的:元素的子孙元素的包含块(Containing blocks)是整个视窗(viewport)或是该元素的祖先元素,内容将不会被剪裁。包含块是什么呢?简单的说,就是可以决定一个元素位置和大小的块。通常一个元素的包含块由离它最近的块级祖先元素的内容边界决定。但当元素被设置成绝对定位时,包含块由最近的position不是static的祖先元素决定。

查看更多

此文原载于:http://blog.allenm.me/2012/12/whats-sourcemap/

今天在方凳会上做了一次 SourceMap 的分享。现在在博客上分享出来给大家。

简介:

什么是 SourceMap 呢?

在这个年代,对于前端开发来说,很少有用户浏览器执行的代码和我们写的 code 完全相同的情况。因为我们的代码一般要经过压缩、合并。另外现在还有 sass, less, stylus, coffscript, typescript 等等预编译语言。那么在这些情况下我们如何进行调试呢?SourceMap 就是为了解决这个问题而生的,虽然它还不够成熟,支持它的工具还不够多,但是我们能从它身上看到未来。

欲了解详情,请观看下面的 slide 吧。(有疑问或者建议可以在下面评论交流,或者微博 @allenm 进行交流)

sourcemap.001
查看更多

前言

如果你想开发一个js应用,甭管多简单,都要先创建整个宇宙

来看看我们的Javascript小宇宙:

  1. 确定如何根据需求、功能划分模块,如何将代码分成多个文件开发,合成一个发布
  2. 保证上一条的同时,使用 Coffeescript、SCSS/LESS 等技术
  3. 保证上2条的同时,想想怎么在浏览器的刷新后一切都最新
  4. 保证上3条的同时,想想怎么在开发、测试、生产、预发布环境中都OK
  5. 保证上4条的同时,进行TDD式的开发
  6. …这还是js, 我们还没有涉及到HTML

 

Grunt 可以将创建小宇宙的工作变得轻松很多。

初识 grunt

以一个jQuery插件的开发为例。 开始之前,让我们先安装Grunt.

首先需要Nodejs环境,这里假设你已经安装好了NodejsNPM.

然后安装 grunt :

npm install grunt

命令行方式更适合前端开发。这里我都用命令行来进行操作,windows用户推荐用git-shell或者powershell.

第一招:快速搭建脚手架

Grunt 已经安装好了,第一步就是利用grunt快速搭建脚手架出来。所谓的脚手架,就是指包含了目录结构和初始的一些功能,测试文件的一个环境。我们来搭建一个jquery插件的脚手架:

grunt init:jquery

这时grunt会问你一些问题,比如项目名称, git地址,作者等等,比如:
查看更多

PM培训的答疑课小结

原文出自独占神话

这期PM培训的最后一次课安排的是答疑,回答了一些同学们普遍关心的问题。对学员们和讲师的讨论,我做了些小结如下:

一. 项目失控怎么办?

产生这种情况说明项目管理已经存在大的问题了。要做到的是提前预知,避免这种情况的出现。
万一出现了,首先要深入了解原因。多问自己问题,是人的原因吗?因为开发是新人?负面情绪引发懈怠?还是沟通不畅? 再看如何解决。两个方向,项目内搞定或者项目外搞定。项目内可以搞定吗?回答这个问题的关键是找关键路径。看从非关键路径是否可以抽调资源到关键路径上。这是要注意关键路径的变化。如果没法解决,项目外解决。项目外也就是看项目管理三角形,在资源、时间、范围上找解决方法。

二. PM如何建立威信?

其实PM需要建立的不是威信,而是信任。这里提到一个非常有趣的概念,Johari Windows。乔哈里之窗能够用来展现、提高个人与组织的自我意识,也可以用来改变整个组织的动态信息沟通系统。
乔哈里之窗把人的内心世界比作一个四格的窗口:
The Open Arena:开放区,自己和他人都知道的领域。
The Hidden Facade:隐藏区,自己知道别人不知道的领域。
The Blind Spot:盲区,别人知道但自己不知道的领域。
The Closed Area:封闭区,双方都不了解的领域。
真正有效的沟通,只能在公开区内进行。因为在此区域内,双方交流的主题是共知的,沟通效果是会令双方满意的。实际沟通中,很多情况下信息不对等,处于封闭区,导致沟通无效。要使得沟通更有效,需要增强信息的真实度、透明度,进而扩大开放区。扩大开放区的方式可以经由自我坦诚,或经由反馈。

三. 遇到能力强但固执的项目成员怎么办?

1. 识别出其固执的原因。
2. 和其身边的朋友多沟通,对其个性和行事风格等更多了解。
3. 使其承担责任,成为某个课题的owner,自我价值实现。
4. 多搞团建,和团队融合。
5. 不能被团队认可,请出项目组。

四. 跨团队的资源如何协调?

1. 要清楚的认识到,我们不是去要资源,而是要取得一致目标。是我们大家一起要把这个事情做出来。讲讲清楚要做什么,得到认可,把事情变成大家的事情,而不是变成对立。
2. 要有结果,要及时反馈。

五. PM要对技术方案负责吗?

PM对技术方案影响越少越好,要认清PM的职责,是带领团队在竞争中取胜。要识别出可以对技术方案或业务拍板的关键人物,他们去负责。
这里又涉及到PM正确的心态应该是怎样的,一是善假于力,融会贯通。对人,要知人善任,了解团队,了解成员的长处短处。对事,项目管理各个环节都要融汇进去。二是正向关注,助人自助。对人,给人机会,也要慎重淘汰。对事,接受挑战,积极正向。

原文

在项目的交互或视觉评审中,前端同学常常会对一些交互效果质疑,提出这样做不好那样做不好。主要原因是这些效果通常会产生一系列的浏览器重绘和重排,需要付出高昂的性能代价。那么,什么是浏览器的重绘和重排呢?二者何时发生以及如何权衡?如何在具体的开发过程中将重绘和重排引发的性能问题考虑进去?本文期待可以部分解释以上三个问题。

浏览器从下载文档到显示页面的过程是个复杂的过程,这里包含了重绘和重排。各家浏览器引擎的工作原理略有差别,但也有一定规则。简单讲,通常在文档初次加载时,浏览器引擎会解析HTML文档来构建DOM树,之后根据DOM元素的几何属性构建一棵用于渲染的树。渲染树的每个节点都有大小和边距等属性,类似于盒子模型(由于隐藏元素不需要显示,渲染树中并不包含DOM树中隐藏的元素)。当渲染树构建完成后,浏览器就可以将元素放置到正确的位置了,再根据渲染树节点的样式属性绘制出页面。由于浏览器的流布局,对渲染树的计算通常只需要遍历一次就可以完成。但table及其内部元素除外,它可能需要多次计算才能确定好其在渲染树中节点的属性,通常要花3倍于同等元素的时间。这也是为什么我们要避免使用table做布局的一个原因。

重绘是一个元素外观的改变所触发的浏览器行为,例如改变vidibility、outline、背景色等属性。浏览器会根据元素的新属性重新绘制,使元素呈现新的外观。重绘不会带来重新布局,并不一定伴随重排。

重排是更明显的一种改变,可以理解为渲染树需要重新计算。下面是常见的触发重排的操作:

1. DOM元素的几何属性变化。
当DOM元素的几何属性变化时,渲染树中的相关节点就会失效,浏览器会根据DOM元素的变化重建构建渲染树中失效的节点。之后,会根据新的渲染树重新绘制这部分页面。而且,当前元素的重排也许会带来相关元素的重排。例如,容器节点的渲染树改变时,会触发子节点的重新计算,也会触发其后续兄弟节点的重排,祖先节点需要重新计算子节点的尺寸也会产生重排。最后,每个元素都将发生重绘。可见,重排一定会引起浏览器的重绘,一个元素的重排通常会带来一系列的反应,甚至触发整个文档的重排和重绘,性能代价是高昂的。

2.DOM树的结构变化。
当DOM树的结构变化时,例如节点的增减、移动等,也会触发重排。浏览器引擎布局的过程,类似于树的前序遍历,是一个从上到下从左到右的过程。通常在这个过程中,当前元素不会再影响其前面已经遍历过的元素。所以,如果在body最前面插入一个元素,会导致整个文档的重新渲染,而在其后插入一个元素,则不会影响到前面的元素。
查看更多

前言:

如果你碰巧是一名前端开发,而又碰巧在维护着一个对可用性有极高要求的站点,那么也许你我有过共同的苦恼:如何在第一时间发现线上出现的前端异常?毕竟前端不是每天都可以过网页裸奔节,线上的Javascript错误也足以让用户抓狂地拿起他们的投诉电话。。。每天心惊胆战发布的日子不好过吧?

是时候改变下了,让心惊胆战见鬼去吧!我的目标很简单:要在用户和boss发现异常之前就彻底修复问题,其余的时间充分地享受高质量生活:)

一:前端异常监控系统的构建目标

在对被监控页面无侵入的前提下,提供7*24小时全天候的监控任务,第一时间发现“裸奔”、“半裸奔”页面或是有Javascript异常抛出的页面,并给网站前端负责人提供短信、邮件等方式的报警服务。

可以说,前端异常监控系统主要是解决两大异常情况:a. 页面上有javascript异常  b. 各种因素造成的页面的样式丢失。我先分别介绍下两种这两种异常的解决思路:

二:Javascript的异常监控

由于客户端浏览器环境的不同,在开发环境中能够工作的代码,并非就能够在用户的电脑上正常运行,各种畸形浏览器造成的问题弄得我们很头大,如果能像后端开发那样可以随时地查看服务器端错误日志就好了!可为什么不呢?

Javascript语言自身就提供了try catch的异常处理语法,我们假以利用的话,就能够在增强前端应用鲁棒性的同时,又可以把捕获到的异常抛送给前端异常监控系统,以错误日志的形式记录到数据库中。

给应用添加异常处理功能,我们是可以充分发挥javascript语言是动态语言这一优势的。我可不想为了添加异常处理而在代码中写N多的try-catch语句。 我的思路是:通过Javascript类模块在应用中注册的时候,遍历类模块中的每个函数,然后统一的加上try-catch处理,这样前端里面的所有函数就都在异常处理的范围之内了。怎么样,是不是要比Java等静态语言cool很多? 代码示例如下:
查看更多