Uedmagazine

@jayli

YUISlide——针对移动设备的动画性能优化

YUISlide这是一个集选项卡切换和幻灯切换功能于一体的小插件,基于YUI3实现,之前主要用在普通的PC终端里,在网厅项目中灵玉同学对Slide进行了改进,增加了手持设备里的小功能,比如手指滑动事件。但Slide的动画在移动端的表现出人意外的糟糕。

在普通的PC平台里,动画的实现大都是通过setInterval函数来完成,jQuery和YUI以及Kissy中亦是如此,只不过帧频有所差异。后来都各自添加了对内置css3 transition的检测,优先使用css3 animation,动画在现代浏览器中的性能又上升了一个台阶。Slide使用了YUI的Anim,在iphone/ipad/android平台中使用的是css3 animation,却依然不流畅,更流畅的动画则需要开启webkit的硬件加速。可以参照之前的一个ppt来了解js动画编程的一些背景知识。

首先要清楚css3的transitions和transform有着细微的差别,css3 transform本质上是将元素的内容作平移,而非直接对元素作属性渐变,因此性能更好,通过Demo可以看出,移动端的Dom操作性能要比css3 animation慢几个数量级。因此要在Slide运行当中尽量减少Dom操作,因此这里对Slide里的跑马灯的实现原理做了微调,即在初始化的时候就处理好待用的Dom节点,而不用在每次执行next()时剪切Dom节点。

另外还有一个css3动画相关属性就是keyframe,这个是用来辅助作复杂动画时用的,通过设定关键帧来作动画,Slide中的简单动画暂时用不到。因此css3动画的几个属性小结如下:

  • css3 transition:平滑的改变CSS属性值,和setInterval原理类似,但速度更快
  • css3 2d transform:二维变换,CSS属性值未渐变,未用到webGL加速,速度有提升,但提升程度有限
  • css3 3d transform:三维变换,CSS属性值未渐变,开启WebGL加速,速度明显提升
  • css3 animation:即使用keyframe来模拟动画,用来实现复杂动画,和性能无关

判断是否开启内置动画:

// true:支持,false:不支持
var nativeTransition = "webkitTransition" in document.body.style;

在支持transition的平台中使用translate3d来启用webGL进行硬件加速,注意这里使用transform代替了transition:

animNode.setStyles({
	'-webkit-transition-duration': speed + 's',
	'-webkit-transform':'translate3d('+dic+',0,0)'
});

最后比较下改造前和改造后的Slide在移动终端里的性能,在Ipad/Iphone中打开下面这两个Demo:

改造前,使用css3 2d transform(性能糟糕):Demo
改造后,使用css3 3d transform(动画流畅):Demo

Slide项目首页:http://jayli.github.com/gallery/yuislide/

JavaScript Autoload 的实现

熟悉PHP的同学一定对autoload不会陌生。我们知道,不管在任何语言和类库中,要使用某个类(或者方法)的前提是这个类必须存在,这个类或方法可能在类库的某个文件的某个角落中定义了,但当类库太过庞大时,初学者往往记不起某个方法属于哪个文件,或者不知道类库文件存放在哪里。另外,开发者不知道什么时候需要用到这个文件,特别是项目文件特别多时,不可能每个文件都在开始的部分写很长一串require。PHP5中提供了__autoload来解决这个问题。开发者将注意力完全放在程序逻辑上,大胆的使用基础类和方法,而不必考虑类和方法属于哪个模块、如何将模块require进来、何时require比较合适,是否有多余的require等等。PHP程序会对代码作分析,自动将程序中用到的“陌生的类和方法”所属的库文件引入进来,保证程序的正确执行。这就是autoload的基本机制,Ruby和Python中也实现了这种机制。

autoload听起来不错,非常适于初学者,而且是动态语言必不可少的组成部分(我才不要像写Java或C++那样一本正经的纠结于程序定义了哪些变量、都是什么类型、作用域是什么、用了哪些类库、类库的引用关系是什么……)。

现在我们在JavaScript中实现PHP的这种autoload机制,其中实现的难点在于对代码的静态分析,这里所指的静态分析只是伪分析(除非嵌入一个JavaScript解释器)。看下在Sandbox中实现的autoload:

Demo:http://jayli.github.com/sandbox/examples/autoload/main.html
Read the rest of this entry »

[翻译]YUI3.4.0 中对 Seed 和 Loader 的改造

原文:http://www.yuiblog.com/blog/2011/07/01/yui-and-loader-changes-for-3-4-0/
标题:YUI and Loader changes for 3.4.0
作者:Dav Glass
译文:YUI3.4.0 中对 Seed 和 Loader 的改造

YUI3.4.0 中,我们开始对 Loader 的核心逻辑进行升级改造。Loader 的性能有了很大提升,而且更加健壮,可以在更多场景下非常方便的使用(比如在服务器环境中)。同时我们会给出YUI的发展路线图,但首先还是有必要解释一下本次更新带来了哪些新内容,为什么做这些更新,以及这些更新对开发者带来的影响。对于大多数用例来说,开发者甚至不会察觉到有什么变化,但有一点变化最明显,就是速度更快,而且加载的资源文件更小了。

种子文件

我们首先来看 YUI 种子文件的一些变化,在之前的版本中,YUI 种子文件非常小,不包含 Loader 以及它的元组件(meta-data)。我们发现在90%的用例中,种子文件并未像我们设计的那样工作。大部分人引用种子文件之后再去载入他们自有的模块,也就意味着种子文件需要先获取 Loader,再计算模块依赖关系,然后再载入模块。我们感到这种策略是一种错误,它会带来一次额外的 http 请求,因此在新版的 YUI 中我们将 Loader 和它的元组件都整合进种子文件中。当然,这会让种子文件体积变大一些,但由于元组件已经包含在种子之内,页面模块的加载自然会提速很多。

如果你仍希望使用旧的方式加载YUI,你只需引入 yui-base 种子文件就可以了。基于 yui-base 可以单机模式运行YUI,它也可以根据需要去自动加载 Loader。如果你想更细粒度的使用 YUI,我们提供了 yui-core 种子文件,yui-core 文件几乎就是原来的 yui-base。

/build/yui/yui-min.js //YUI Seed + Loader
/build/yui-base/yui-base-min.js //Old YUI Seed with Loader fetch support
/build/yui-core/yui-core-min.js //Old yui-base without Loader fetch support

注意,这些URL和之前的URL有所不同。如果想使用 yui/yui-base.js 文件,则需要重新定位至 yui-core/yui-core.js,如果你想使用旧的方式来加载种子和 Loader,则需要使用 yui-base/yui-base.js 种子文件。

促使我们对 YUI 作这种调整的另一个重要原因是,根据 YUI 的发展路线图,我们需要 YUI 将来运行于各种平台上。如果你有 combo 服务器(译注:combo 是合并的意思,这里指可以在服务器端合并脚本的服务器),则旧有的种子外加 Loader 的使用方式是ok的,我们可以将种子和 Loader 合并入一个 http 请求。那么 YUI 如何运行在服务器端、离线应用程序以及手持终端里呢?这些场景所需的种子文件需要做到最小化,同时又要保持各自所需的功能。
Read the rest of this entry »

[翻译]F2E大会上关于@font-face的分享

原文:http://www.nczonline.net/blog/2011/04/05/lessons-on-font-face-from-the-f2e-summit/
标题:Lessons on @font-face from the F2E Summit
作者:NCZakas
译文:F2E大会上关于@font-face的分享

上周我参与组织了Yahoo F2E大会,这次大会聚集了Yahoo全球各地的前端工程师,其中@font-face是本次大会最受关注的话题之一,我们讨论了它的种种优势和缺陷,好记性不如烂笔头,我得赶紧把这些知识点记录下来,本篇内容来自于 Matt Seeley 关于“yahoo.com/tablet”的专题分享“iPad版Yahoo首页实战”(Lessons from the Tablet Front Page),以及来自于Adam Wang关于面向未来的CSS3的专题分享“无名小站新版首页案例分析”(Case Study:
Wretch New Front Page),在这里我只是将他们的分享做了摘录。

兼容性

如果你不清楚<video>和<audio>标签的兼容性问题的话,你可能也不会知道 @font-face 的兼容性情况,尽管在桌面浏览器中可以通过 OpenType、TrueType 和 WOFF 可以比较好的做到兼容,但在移动终端则没办法轻易做到兼容。iOS4.1 和较早的版本只支持 SVG 字体,而 Android 只支持 TrueType 字体。iOS4.2 及后续版本开始同时支持 OpenType、TrueType 和 SVG 字体。也就是说,要想兼容 iOS 和 Android,只要将 css 代码精简成如下模样即可:

@font-face {
    font-family: "Gotham Medium";
    font-weight: normal;
    font-style: normal;
    src: url(gothmed.ttf) format(truetype),
        url(gothmed.svg#id) format(svg);
}

Read the rest of this entry »

QCon 2011 后记

本文同期发表在http://ued.taobao.com

关于Qcon 2011

之前年初我参加了新版淘宝首页的开发,做了一些html5的实践,正好这次QCon有学鹍主持的html5专题,小马就推荐我去QCon分享一下这方面的心得,所以对我来说,能参加这次QCon很幸运,也很忐忑。一方面,我在html5方面的确算不得专家,另一方面,淘宝在html5实践之路上也在摸着石头过河,不过,感谢学鹍的鼓励,还有澄净承玉圆心完颜的帮助,让我仔细梳理html5实践原则和一些教训,这才有了这个ppt

说起来,这是我第二次参加QCon,之前QCon关于纯粹Web前端的专题很少,就像小马说的,QCon大会是后端开发工程师和架构师的技术大会,不过这次QCon前端的专题一下子增加到了三个,有点小意外。此外,敏捷开发、Java的回归、关于测试和服务器集群优化的专题演讲依然让人收获颇丰。 Read the rest of this entry »

[翻译]使用YUI 3开发Web应用的诀窍

本文同期发表在http://ued.taobao.com

导语:这篇“基于YUI3开发web应用的诀窍”是比较经典的介绍 YUI3 工作机制的文章,文章发布在yuiblog上,总体难度适中,比较适合初学者认识、了解 YUI3。以此纠集了三名应届同学来翻译这篇文章:函谷郝黎张勉,并希望能对正在学习YUI3的同学有所帮助和启发。

原文标题:A Recipe for a YUI 3 Application
原文地址:http://www.yuiblog.com/blog/2011/04/01/a-recipe-for-a-yui-3-application/
译文:使用YUI 3开发Web应用的诀窍

我们知道,YUI3的设计始终围绕着“模块”展开。今天我不想过多解释什么是模块,因为Nicholas Zakas在他的文章”构建可伸缩的前端架构“中已经做了详尽说明。在这里我将着重阐述如何构建这些模块。文章中的大部分内容都可以从在线文档查阅,并有其他可代替的方法。当然在线API文档的内容大而全。本文只是介绍其中的精华的部分——基于YUI3开发web应用的诀窍,这里的“诀窍”更针对短小精悍的程序场景,不像Nicholas Zakas所指的架构级场景,毕竟仅凭本文的篇幅无法全部展开讲述YUI3。

模块的定义

首先我们要对模块进行定义,一种常见的方法是将页面可视区域的不同部分做切分,导航、菜单、正文、边栏面板等等。然后查一下YUI是否已经提供了这些模块,比如YUI3就没有提供“菜单”组件,但提供了Node-MenuNav插件,这个插件可以将结构化好的html代码(ul>li)渲染成具有交互行为的菜单。或者你可以直接去YUI Gallery中去找基础组件。不管怎样,你总会找到一种容器或者布局,可以让你往里填充你需要的东西,ok,让我们从这里开始。

我建议将每个模块都封装进一个文件,放在和文件名同名的目录中,比如weather模块应当放在/weather/weather.js中,这样做的原因是,有可能你的组件会依赖一些样式,包括cssimg等,将这些样式和资源文件放到和js同一个目录下,YUILoader就会很方便的找到他们。这样,样式文件就可以放在weather/assets/skins/sam/weather.css,同样,其他图片和样式也可以按这种方式放置,当然我们假设你没有使用YUI Builder来打包你的项目,这就有点说来话长了。assets目录和skin目录的含义不言自明,但sam目录就搞不懂啥意思了,其实samYUI配置项中skin的默认值,指代YUI内嵌组件的默认样式,sam取名自其设计师Sam Lind。因此你也可以使用你的昵称作为你的组件皮肤名称,当然这需要你在YUI全局配置中传入skin参数,简单起见,我们这里只使用默认皮肤。

模块文件模板

这里是一段最常用的模块定义的代码: Read the rest of this entry »

JavaScript语法检查插件 jsLint for Vim

工欲善其事,必先利其器。作为更专业的前端工程师,我们需要强劲的IDE协助我们写出规范、美观、漂亮的JavaScript代码,首先要作的就是对代码进行合法性检查,而通过 www.jslint.com 进行手工操作又显得碍手碍脚。为了提高效率,这里推荐使用 jsLint + Vim(gVim),能够协助你达到事半功倍的效果。

首先,和 JavaScriptLint 不同[注1]jsLint 是需要 JavaScript 引擎的支持的,linux中可选的有基于 C 语言的 Spidermonkey 和基于 Java 的 Rhino,考虑到速度,推荐使用 Spidermonkey。另外,jsLint.vim 初始配置挂载的监听有些冗余,这会导致 Vim 运行很慢,影响编码的效率,这里我 hack 了一份 jslint.vim,只用F4键就可以开启/关闭语法检查,下面介绍配置方法(linux & windows)。

jsLint + vim for Linux

1,准备JS引擎

linux 下默认没有 JavaScript 引擎,需要安装,旧版本的 ubuntu 通过apt-get来安装

sudo apt-get install spidermonkey-bin

Read the rest of this entry »

数组去重——一道前端校招试题

很多校招题是没有严格的标准答案的,只有知识点,只要几个关键点能答上来,不管程序是否真的能跑通,都可以拿分的。比如最常见的一道题:

试题:
有这样一个数组,成员都是数字,例如
var a = [1,2,3,4,5,2,3,4,6,7,8];
请实现a.distinct()方法,用来给数组a去掉重复值,要求对Array的原型进行扩展方法,并尽可能做到效率最优。

考察点:
1,考察应试者是否理解原型链
2,考察应试者是否由意识的控制算法的时间复杂度,了解应试者对专业课知识的掌握程度
3,考察应试者对js数组函数的了解程度
Read the rest of this entry »

淘宝2011新版首页开发实践

本文同期发表于 http://ued.taobao.com

新年钟声刚过,淘宝新版首页全“心”上线了,这次设计大胆的将布局从 960px 伸展至 1000px,页面更通透,新首页更大范围的实践了 HTML5 CSS3,全面兼容 iPad,并在可访问性方面有了更多积极的尝试。对于我来讲,这次开发着实是一次奇妙的经历,也让我对可访问性、html5 和性能优化有了新的认识。
Read the rest of this entry »

[翻译] Zakas 对 John 的回应

题目:回应 John Resig 关于 YUI 的评论
作者:Nicholas C. Zakas
译者:拔赤
原文:http://www.nczonline.net/blog/2010/11/03/response-to-john-resigs-comments-about-yui/
外一篇:jq之父回答“YUI3如何提升其影响力?”

就在今早,有人在 Quora [注1]上提了一个问题:“YUI3 如何提升其影响力?”,这个问题很有意思,下面的回复也很有意思。我最感兴趣的一个回复来自于 jQuery 的作者 John Resig,他的解读非常独到,给出了创建 jQuery 庞大且充满活力的开源社区的路线图。只是其中很多观点我不敢苟同。

在讨论之前,应当说明的是,我在 YAHOO 工作,我一直都在为 YUI 贡献代码,尽管我不是 YUI 开发团队成员,因此我的观点不代表 YAHOO 公司和 YUI开发团队,仅仅是我个人针对 John Resig 回复来分享我的看法。再补充一点,我对 John 本人、jQuery 团队和 jQuery 社区开发者们十分敬重,所以,请不要将我的观点断章取义,做别有用心的理解。

首先,我承认,分散的站点的确是 YUI 的一个问题,不止一个人曾经纠结于到底应该访问 YDN 呢还是访问 YUILibrary.com?这是 YUI 首先要解决的问题。同样,John 对于简化 YUI 文档首页上的引导信息的建议也相当不错,是个好主意。

John 的下一段落介绍了 YUI 如何与 jQuery 正面竞争,我在 twitter 上有过一个简评:“我不认为他们之间存在你死我活的竞争关系”,我不想将 YUI 搞成另外一个 jQuery,这两个库各自都有优点,且重合度极小。jQuery 更适合小网站使用,毕竟它很简单、大众、人人都可以快速上手,因此 jQuery 有着庞大的设计师群体,但我不愿意拿 jQuery 来搭建 Yahoo 首页。对于可扩展的 web 应用,YUI 的确更胜一筹。我不相信仅凭一个单一的产品就能满足所有用户多样化的需求。jQuery 在其专注的方面的确富有想象力,而我宁愿将 YUI 的关注点放在解决复杂 web 应用方面的问题。
Read the rest of this entry »

Follow

Get every new post delivered to your Inbox.