样式之美 » 前端架构 http://www.aoao.org.cn 没落的角落 Fri, 13 Jan 2012 03:37:59 +0000 en hourly 1 http://wordpress.org/?v=3.0.4 人肉gzip http://www.aoao.org.cn/blog/2008/11/human-flesh-gzip/ http://www.aoao.org.cn/blog/2008/11/human-flesh-gzip/#comments Sun, 16 Nov 2008 18:15:51 +0000 aoao http://www.aoao.org.cn/?p=118 gzip 是什么东东呢？百科跟我们说

gzip是GNU zip的缩写，它是一个 GNU 自由软件的文件压缩程序。…
gzip 的基础是 DEFLATE ，DEFLATE 是 LZ77 与哈夫曼编码的一个组合体。…
“gzip” 也经常用来表示 gzip 文件格式，这种格式：

  • 10 字节的头，包含幻数、版本号以及时间戳
  • 可选的扩展头，如原文件名
  • 文件体，包括 DEFLATE 压缩的数据
  • 8 字节的尾注，包括 CRC-32 校验和以及未压缩的原始数据长度

简单来说，Gzip就是一种让你的网页显示变快一种神奇的东东。

那么，什么是人肉Gzip呢？就把本来要服务器动态压的东东人工压，大家可以先看一下这篇：Gzipping CSS and Javascript files。实现方式就人工zip一下，然后服务器再派上头。

<link rel="stylesheet" href="style.cgz" media="all" type="text/css" />
# Compressed css files
AddEncoding x-gzip .cgz
AddType text/css .cgz

其实Gzip就是三个选择：CPU、内存、IO，通常都是cpu+内存来做，我并不喜欢这个人工IO的方式，它最大的一个问题就是不能解决http1.0的问题，而且很体力活，不过我们可以人工zip来看我们的东西Gzip后的大小。在中国，因为有好多xx版XP的原因，http1.0成为了可能。

]]> http://www.aoao.org.cn/blog/2008/11/human-flesh-gzip/feed/ 8 CSS Frameworks的概念 http://www.aoao.org.cn/blog/2008/01/css-frameworks/ http://www.aoao.org.cn/blog/2008/01/css-frameworks/#comments Sun, 20 Jan 2008 17:45:35 +0000 aoao http://www.aoao.org.cn/blog/2008/01/css-frameworks/ 最近看到N多介绍CSS框架，前些天我说过一句话：“在我有限的视野里，还没见到可以真正可以称得上css框架的东东~”，当然也可能是我的视野太小了，或者是说世界太大了，我自己还是感觉还有一大堆我看不到的东西。

先来看一下一个我比较认同的概念：

框架可分为白盒(White-Box)与黑盒(Black-Box)两种框架。

基于继承的框架被称为白盒框架。所谓白盒即具备可视性，被继承的父类的内部实现细节对子类而言都是可知的。利用白盒框架的应用开发者通过衍生子类或重写父类的成员方法来开发系统。子类的实现很大程度上依赖于父类的实现，这种依赖性限制了重用的灵活性和完全性。但解决这种局限性的方法可以是只继承抽象父类，因为抽象类基本上不提供具体的实现。白盒框架是一个程序骨架，而用户衍生出的子类是这个骨架上的附属品。

基于对象构件组装的框架就是黑盒框架。应用开发者通过整理、组装对象来获得系统的实现。用户只须了解构件的外部接口，无须了解内部的具体实现。另外，组装比继承更为灵活，它能动态地改变，继承只是一个静态编译时的概念。

在理想情况下，任何所需的功能都可通过组装已有的构件得到，事实上可获得的构件远远不能满足需求，有时通过继承获得新的构件比利用已有构件组装新构件更容易，因此白盒和黑盒将同时应用于系统的开发中。不过白盒框架趋向于向黑盒框架发展，黑盒框架也是系统开发希望达到的理想目标。

再回头看一下现在网上那样多CSS框架（YUI是叫“YUI Library CSS Tools” 并非是“YUI CSS Frameworks”），有多少是真正以框架的概念在写，有多少只是定义样式基类的。当然，每个人对框架的理解不一定，你可能不认同我的说法。

再谈一下CSS 框架，并不非我不认可这个东西的存在，我从一两年前也就一直在尝试这样的东西。对于大型网站，前端的开发需要一个解决方案。框架自然是首选的。可惜距离我太远了，我太弱了T_T，我只要要求两点：

  • 管理下面的内容的东西
  • 类/组件

很明显，第一点，CSS做不到，第二点，相对其它语言很弱的说。

大约在一年前做一个中型网站时，我为了偷懒，我想到内容模块化，让程序员拼页面。大约方向也就是封装了一个又一个的功能块，程序员在要用到哪一块内容时就只要使用相应的HTML与CSS，大家都方便，我不要拼页面，他不用重复套代码，大家好才是真的好。

在同一个网站，差不多的内容块，多次使用是很正常的事，这也是就让模块化成为可能，比如一个图片列表，可能是用户头像列表，或者群组的图标列表，这时你会怎样写呢？相同的用这样吗？

.photoListUesr,.photoListGroup{ /*_*/ }

这样不是说不行，但如果突然说要再加一个相似的呢？这时可能就要调整样式。而我呢？尝试过这样的使用方式：

<div class="photoList UesrCt" />
<div class="photoList GroupCt" />

这样的话，我们一开始就分离出共同表现的东西，把.photoList当成原型，通处额外的class再去处理细节。前些天，我写了面向对象的XHTML与CSS编程，其实只写了一半，另一半是详细的例子，不过介于要做太多的例子跟核心已经写出来就没写完，^^ 当然，这样也存在一定的问题，就是最初的原型的定义要很慎重，要尽量做到以后就算是改版也可能不用修改。CSS这东西，基本上一个框架最多只能适合一个站，当然，如果这个站足够大的话，这样使用才是有意义滴。

HTML与CSS越是模块化，文件越分散这个问题就越严重。HTML倒是好办，反正是应用程序最终要合并输出一份，但CSS一般会给抛弃直接使用。如果在刚才的例子中，在网页导入CSS的方式是这样的话：

@import url(/xxx/photoList.css);
@import url(/xxx/UserCt.css);
@import url(/xxx/GroupCt.css);

那甚至可以考虑用程序来拼页面，但是使用方便，请求数也成正比，一般情况大家都会选择手动合并文件。虽然人脑比电脑更智能，但很多时候，人脑的计算能力是比不上电脑滴。我曾经有这样的想法，就是使用服务端程序来处理CSS的发布机制，大约方向就是通过网站访问日志来分析出整个站各种页面的使用量，通过程序来计算哪些公共使用的要合并，合并的顺序（CSS的文件顺序会影响到优先权），等等各种计算并压缩输出。

可惜的是，这样一套复杂的程序可能只适合一个站，或者同系列的站群。虽然说做起来有点折腾，但我相信门户级别网站使用这样的方式是有必要滴，当然前提还要整个团队都要使用相同的设计模式。

PS:以上CSS发布程序，只是我的幻想，还没尝试过，有兴趣的朋友可以尝试一下，如有意外，概不负责。^_^~

当然，就以上这些还是不能称得上CSS Frameworks，或许只能叫成一个系统级解决方案，毕竟，CSS只是描述性语言。

前晚跟月影一起吃烤鸭时，有聊到这个，他问我有没有前端一体化的解决方案。JS组件化时也会面临同样的问题，差不多的发布机制应该也可以适用JS。不过完全的一体化解决方案我还没想好，也许月影多请我吃几次烤鸭我就能想好。

广告一下：Ucren-widgets，国内一个不错的JS组件。

扩展阅读：CSS Frameworks + CSS Reset: Design From Scratch

]]> http://www.aoao.org.cn/blog/2008/01/css-frameworks/feed/ 19 JavaScript分层的概念与本地存贮 http://www.aoao.org.cn/blog/2008/01/js-3-tier/ http://www.aoao.org.cn/blog/2008/01/js-3-tier/#comments Tue, 08 Jan 2008 14:42:09 +0000 aoao http://www.aoao.org.cn/blog/2008/01/js-3-tier/ 以前学了一个月的asp.net算没学，把三层结构的概念改改就套在JS上。^^，那JS要怎样分层呢？其实主要是多了一个页面级的数据库

  • 表现层：处理UI呈现
  • 业务逻辑层：除了上面跟下面的都算在这个里面。当然我不介意你再细分^_^
  • 数据与数据维护层：JS存数据也不是一天两天的事。可有多少人在网页维护JS数据库呢？

为什么要给自己找麻烦呢，把本来简单的东西复杂化，要数据找服务器要，自己干啥还得维护多一份数据，多无聊。主要的原因是：

  • 页面缓存数据，减少与服务端之间的交互。
    页面缓存数据有什么意义，比如在不稳定的无线网络里，不是每个操作都去访问网络，也就不会有因为不稳定网络引起的一大堆乱七八糟的问题。
  • 实现预加载，加快访问速度。
    Gmail的新版本号称邮件一点就开，其实是在网络空闲的时候，把数据先当下来。我没去看Google那些恶心的代码。估计也是用JS构建一个页面级的数据库。
  • 方便数据二次呈现。
    变更数据呈现有个“本地数据库”来查询自然方便多了。挖哈哈

当然也有一些负面的作用。比如性价比没那样高，以前，我们从服务器要到数据后一般就直接或者转换一下innerHTML到界面，如果按这种方式就一定要多存份到“数据库”。去掉某些东西时也要去通知“数据库”。由于JS的受限，我们折腾了半天的“数据库”在刷新一下就干掉了。这不是折腾吗? 看看Gmail是怎样做的，虽然它也是一刷新就干掉，但它已经养成用户一种习惯了GMail是不用刷新滴，挖哈哈。

当然，我们还是比较贪心的。如果能再加上本地存贮的话，折腾就少了点。现在离线比较出名的算是google的Gears，不过我对它没兴趣，估计我做的产品的用户们没人听说过它，再别说会使用，好像最近也给GFW的样子 。本地存贮如果要用的话，应该尽可能使用浏览器的原生技术。比如IE有userData、Firefox有sessionStorage，怎样用呢？石头老大写过一篇关于怎样操作的。当然也有人用flash来存东西，100K哦。

综合来说页面级的数据库并非适合所有的产品，个人认为最适合邮箱，或者某些后台管理、QZone等那些一个页面搞定一切的网站。当然这也不是空口说白话的，我已经在项目中一个模块尝试过。一点就开的感觉很爽滴~

]]> http://www.aoao.org.cn/blog/2008/01/js-3-tier/feed/ 6 如何减少网页的内存与CPU占用 http://www.aoao.org.cn/blog/2007/11/memory-cpu/ http://www.aoao.org.cn/blog/2007/11/memory-cpu/#comments Tue, 20 Nov 2007 18:02:29 +0000 aoao http://www.aoao.org.cn/blog/2007/11/memory-cpu/ 有的网页看起来并不大但打开会很卡，有的网页虽然很长但使用流畅，占用用户电脑的内存与CPU就影响这些。

浏览器问题，有各自的浏览器处理内存问题会影响到，但几乎没办法控制得了，Windows上的：

  • IE系列，刷新回收的量不大，但最小化会释放内存，。
  • Firefox2据说也会在最小化回收，可我从没见过最垃圾，用多少是多少，基本不回收。据说prototype的ajax还会引起内存一直增加。
  • Opera最好。一直控制得很好。不存在什么问题。。

Linux的内存分配机制与Win的不一样，有多少用多少，如果浏览器占光时说不定会干掉系统。

页面问题，浏览器渲染页面会消耗内存和CPU，能减少一点就减少点。

结构上

  • 使用DocType，告诉浏览器你在用什么，html4也有DTD。也许Transitional更适合你
  • 如果使用的是XHTML并能保持良好结构的话，记得输出相应的MIME跟XML头1，可以减少浏览器的代码检查，
  • 保持结构的完整，不要让浏览器帮你补全代码。
  • 控制页面的文件大小，可以通过程序把为了看代码比较舒服的缩进去掉。2~3K也是大小。
  • iframe会产生新的页面，其实有很多方式可以代替iframe
  • 引入的JS与CSS可以适当合并，同样背景图片也可以合并，甚至有人连Flash都合并
  • 给已知宽高的内容图片/Object加上宽度的属性可以减少页面的局部重渲染

表现上

  • 质量99跟70的jpg在大多数情况下只有文件有大小不一样。gif的也一样，特别是小图标，256色跟128色的差别是文件大小．
  • flash动得太快吃CPU很大，控制每秒的帧数及动画的效果可以减少一些，如果把品质用中低显示会省很多资源，但这样却牺牲了效果。。quality属性 有时选择Autolow2 或者Autohigh会更适合，没必要一直low 或者best，
  • flash使用矢量图会节省文件大小，但计算复杂的图形跟动画时花的是CPU。复杂的太多滤镜，则会占用大量内存，模糊滤镜有减少些3。
  • IE的滤镜也是比较占用内存，同时也有兼容性问题。全屏的半透明很吃资源的。
  • 2*2的图片跟8*8的图片大小差不多，但是平铺背景2*2却占用大很多。
  • gif动画同样有帧的概念，别把gif当成flash来玩就行。

行为上

  • 别为了使用一个$()引入整个prototype或jQuery，它们有更多的作用。
  • AJAX很帅。但是用xml会用上XML解析器，有人推荐用JSON，可是这样要eval数据，其实可以直接import已经是对象的script来用。只是要多传个对象名，或者把对象名写死，或者像flickr那样jsonFlickrApi({"xxx":"xxx"})，直接当函数用，挖哈哈。
  • 实现某些效果时能用visibility:hidden解决时就别用display:none来玩。
  • 在这里强调js变量要注全局跟局部等等的意义并不大，JS复杂的地方也不是一两句能说得清的，关注大家关注月影的正在出版的新书吧。^^

其实这里有的内容有不少跟如何快速的呈现我们的网页相近，不过那篇是以处理服务端为主，但在很多时候，节省服务端资源消耗的同时也会节省客户端的资源消耗。

再其实，这篇已经蹲在草稿箱里好久了，一直没有时间去整理。现在给的也不是完整的，因为没有完整，慢慢补充吧。

  1. 产生问题：虽然会引起浏览器的模式问题，但问题是可以解决滴。参考Serving up XHTML with the correct MIME type，派送XML头浏览器不会容错显示，出现错误结构会导致整个页面无法显法。
  2. Autolow: 优先考虑速度，但是也会尽可能改善外观。 回放开始时，消除锯齿功能处于关闭状态。 如果 Flash Player 检测到处理器可以处理消除锯齿功能，就会打开该功能。
    Autohigh:开始时回放速度和外观两者并重，必要时会牺牲外观来保证回放速度。 回放开始时，消除锯齿功能处于打开状态。如果实际帧频降到指定帧频之下，就会关闭消除锯齿功能以提高回放速度。使用此设置可模拟“消除锯齿”命令（“视图”>“预览模式”>“消除锯齿”）。
  3. 模糊滤镜:使用模糊滤镜时，如果用于 blurX 和 blurY 的值是 2 的整数次幂（例如 2、4、8、16 和 32），则可以加快计算速度，并且可以使性能提高 20% 到 30%（flash的帮助是介样说滴）。
]]> http://www.aoao.org.cn/blog/2007/11/memory-cpu/feed/ 29 iGoogle的主题与模块 http://www.aoao.org.cn/blog/2007/09/igoogle/ http://www.aoao.org.cn/blog/2007/09/igoogle/#comments Sat, 15 Sep 2007 06:58:17 +0000 aoao http://www.loaoao.com/blog/2007/09/igoogle.html iGoogle现在的主题是按时间或者天气变化的，它存放样式的方式也不错。每个主题存在一个xml，除公交车站外，什么时间应该读什么几乎全在XML里，3.14早已经不是什么秘密了，有兴趣就去看下3.14有什么特别。不过感觉他的文件命名有两个特别的：noon和midnight，不知道为什么不统一用时间格式的呢？已知的各套的主题的XML在这里，据说还有一些官方神秘主题，都不知道是什么样滴。

“冰天雪地”的名字是我起滴^_^，默认是看不到，如果想要看的话，打开iGoogle，先点选择主题，然后在地址栏上敲上：

javascript:_dlsetp('preview_skin=skins/winterscape.xml');

要不要保存就是自己的事了^^，XML地址源自All screenshots of Google Theme (iGoogle)，绕道而行。

update：2007.11.6 发现了新的五个 Five New iGoogle Themes，使用方式同冰天雪地，只要改XML就可以

3.14的看法也是敲代码。。

javascript:void(document.getElementById("ext_css").href="/ig/skins/hongkong/hongkong_3.14am.css");

iGoogle的模块处理的方式也不错，也是用xml来存，类如这样：

<?xml version="1.0" encoding="UTF-8" ?>
<Module>
  <ModulePrefs title="hello aoao example" />
  <Content type="html">
     <![CDATA[
       子乌不发威，你当我是hello aoao!
     ]]>
  </Content>
</Module>
  • <Module> 标记说明此 XML 文件包含小工具。
  • <ModulePrefs> 标记包含关于小工具的信息，如标题、说明、作者和其他可选功能。
  • <Content type="html"> 行说明此小工具的内容类型为 HTML。
  • <![CDATA[ ...insert HTML here... ]]> 用于在小工具内容类型为 html 时将 HTML 包括于其中，告诉小工具解析器 CDATA 部分内的文本不应视作 XML。CDATA 部分通常包含 HTML 和 JavaScript。

这个方式的定制性很大，也很自由，更详细的介绍可以看Google 小工具 API。早已经有人把Google 相关的模块都整理出来，起名Google OS，不过我忘记最早是在哪里发现的，我共享了我自己的”Google OS”标签页，Add to Google ^_^ 我最近也在接触类似的项目。

也有人做了“Custom iGoogle Skins” 的模块，Add to Google，可以玩转iGoogle主题。

update 08/7/20:要玩新版的igoogle可将语言设定为English；在地址栏中输入javascript:_dlsetp('v2=1')，回车。

]]> http://www.aoao.org.cn/blog/2007/09/igoogle/feed/ 3 如何快速的呈现我们的网页 http://www.aoao.org.cn/blog/2007/06/how-to-show-our-pages-quickly/ http://www.aoao.org.cn/blog/2007/06/how-to-show-our-pages-quickly/#comments Fri, 15 Jun 2007 10:38:44 +0000 aoao http://wordpress.cs/?p=37 前几天小芳同学一直在群发起一些加速的话题，我已经把聊天记录抽出来，正打算整理出份像样的，没想到小芳同学非常速度的出了这篇。我的就省掉了，挖哈哈。

特别说一下了，这些方案并非适合所有的网站，很多部分有的网站还是不要做反而会更好。如果你还有更多的想法，可以到这里讨论或者评论，我只是归档成为方便阅读的，对了论坛和群讨论的另一些结果如果有价值我也会补充进来。

如何快速的呈现我们的网页 作者：flashsoft，（内容被我略修删过）。

一.我们需达解决的麻烦

  • 减少HTTP请求数. 减少HTTP请求数有什么好处
    • 降低服务器跟客户端的建立和消除HTTP请求和响应Header的开销
    • 减少服务器为HTTP连接的进程和线程的开销,如果可能,还会包括GZIP压缩的CPU开销.
  • 减小被请求文件大小, 减少请求数据占用的网络带宽.
  • 让用户更快的看到想要的结果.
  • 提高客户端渲染速度.
  • 让浏览器同时能请求更多的数据.
  • 提高服务器相应速度.
  • 通过版本化控制客户端Cache.

二.如何解决我们的麻烦

A.如何减少HTTP请求数

  1. 合并JS文件跟CSS文件。
  2. 合并框架图片以及相对变动较少的图片成一张，通过CSS背景切割来完成渲染，比如：加速图片显示。
  3. 合理使用本地Cache来缓存JS/CSS/IMAGE。
  4. 合理使用UserData缓存JS文件,对于FF用户可以单独请求服务器,这样能解决80%用户的问题.代码可以蓉儿(meizz)的js framework1。
  5. 把JS跟CSS合并成一个文件

B.减小被请求文件大小,减少请求数据占用的网络带宽

  1. 压缩JS体积：删除JS中空白换行,注释,混淆把长变量换成短变量；
  2. 压缩CSS体积：删除CSS注释、写法尽量用简写；
  3. 使用(X)HTML+CSS方式搭建网站结构,提高CSS重用性,来减少(X)HTML文件大小；
  4. 使用服务器端GZIP压缩JS/ CSS文件,缩小传输文件大小。附注:Apache1跟Apache2的GZIP的效率跟方式不一样的，根据需要自行选择。

嗷嗷补充说明：压缩、合并JS和CSS都由程序处理。而不是自己手动去缩删，不然不利于后期维护。

C.让用户更快的看到想要的结果

用户对于一个站点的白页的忍受时间根据统计是8-12秒。白页的产生可能由于各种原因引起,我们能做的就是怎么让用户能变的稍微能等待更久。

  • 方案1.多做一个引导页,让用户体会其中的变化
    案例:mail.aol.com中的loading引导页
  • 方案2.优先载入页面结构以及结构图片,后一步载入当前页面数据,再后一步载入Iframe,Flash等数据.让用户尽早的看到被打开页面的希望.

D.提高客户端渲染速度

这个问题就比较泛泛了,影响客户端的渲染速度有多方面的,主要目的都是提高程序方面的效率.

  1. 对于大索引的结构,尽可能的少用索引访问,能用访问兄弟节点的方式尽可能用访问兄弟节点的方式.
  2. 字符串拼接尽可能用数组方式
  3. 大规模添加节点数据,请不要使用appendChild方式,尽量使用类似innerHTML的insertAdjacentHTML方式,FF下需修正2

E.让浏览器同时能请求更多的数据.

浏览器默认只是支持单域名同时有两个HTTP请求,使用多域名将能把请求数提高,在网络条件优良的情况下,能更快的下载数据,呈现结果.

F.提高服务器相应速度

对于需快速响应的文件,把其放入快速响应的服务器,应该是不错的方案,优化方案请系统储备组提供.

G.通过版本化控制客户端Cache.

通常js/css这类文件改动比较频繁,但是为了加载速度变快,我们有可能需要设定这类文件的过期时间为几天后,这样我们碰到的问题就是,如何及时更新这些在cache的文件?
通过一个简单的配置,通过修改JS的版本来及时告诉浏览器,这些文件必须重新请求了,不要继续使用浏览器cache中的数据. 方案有好几个:

  1. 手动改这些js的文件名
  2. 手动改这些js的路径
  3. 通过URL Rewrite方式来改重定位js路径
  4. 通过一个在高响应服务器上的一个js配置告知页面,这个页面该链接哪些JS文件
  5. 大版本不变,小版本不断追加,等一定时间后,统一更新,高效利用cache

标注

  1. meizz的js framework还没出正式版，有兴趣在CSDN的页面翻一下
  2. Firefox修正方式
    function addHTML(oParentNode, sHTML) { if(window.addEventListener) {// for MOZ var oRange = oParentNode.ownerDocument.createRange(); oRange.setStartBefore(oParentNode); var oFrag = oRange.createContextualFragment(sHTML); oParentNode.appendChild(oFrag); } else {// for IE5+ oParentNode.insertAdjacentHTML("BeforeEnd", sHTML); }}
]]> http://www.aoao.org.cn/blog/2007/06/how-to-show-our-pages-quickly/feed/ 6