javascript高效简洁代码的编写及优化技巧

http://www.js8.in/350.html

前言

随着互联网前端技术的革新,javascript越 来越重要,并且js的轻便,非严格的写法,使越来越多的人掌握了js,可是谈到js的写法,很多人都觉得自己很熟悉,很了解,但是笔者在实践中发现js并 非大家想象的那么简单,就像同事一句话:php会的很多,一抓一大把,而真正会js的却不多。仔细想想,原因很简单,js的加载到客户端运行的,不像 php可以一个include就可以搞定,而且引入的文件中不用的函数可以放着不动,而js不同,如果加入很多很多无用的函数会大大的占有带宽,不利于用 户体验。下面结合笔者实际开发过程中遇到的问题,以及自己收集的技巧,谈谈js高效简洁代码的编写及其优化的技巧。当然网上也有很多类似的文章,不过建议 大家还是不要人云亦云,真正适合自己的技巧跟编写习惯才是最好的!

真假的判断

Javascript中有null、undefined、string、number、boolean五种基本的类型,一般判断真假或者为空的时候大家会使用下面的代码:

if(a==true){
    //doSomeTing();
}

但是这种方法很不简洁,我们完全可以使用1,0来判断,比如我们设定一个a,如果a为假,我们就改成真,而a在程序后面可能用于判断,最简单也是最好理解的方法就是下面的写法

var a=false;
if(a==false){
    a=true;
}

既然提到了0,1,肯定有人想到了第二种写法:

var a=0;
if(!a){
    a=1;
}

这个代码还可以进一步简写优化,就是使用js的三元运算符,也就是三目运算符:

var a=0;
!a?a=1?null;

还有一点,对于空字符串的判断,往往采用if(a==””),其实对于空字符本身就是false,下面我总结了下Javascript中的真假值,希望对大家有用

 

JavaScript 中的真假值
类型 真假值
Null 总是为假(false)
Undefined 总是为假(false)
Boolean 保持真假值不变
Number +0,-0 或是 NaN 的时候为假,其它值为真
String 空字符串的时候为假,其它值为真
Object 总是为真(true)

数组跟对象的定义

对于类似下面的正统数组跟对象的定义

var a=new Array;
var b=new obj;
obj.name="WYQ";
obj.webSite="http://www.js8.in";

我们可以使用

var a=[];
var b={name:"WYQ",webSite:"http://www.js8.in"};

来代替

循环的控制

在使用循环遍历时候要注意提前把长度或者要计算的长度记录下来,如下面的写法

var list = document.getElementsByTagName('p');
for (var i = 0, l = list.length; i < l; i++) {//注意此处把list的长度提前计算出来,避免了每次循环重复计算
    ……
}

注意循环体内部的写法,该放在外面的放在外面如下面的代码

var list = $(".abc");
for (var i = 0, l = list.length; i < l; i++) {//注意此处把list的长度提前计算出来,避免了每次循环重复计算
    var a=list[i].html();
    $("#abc").after(a);
}

我们分析一下:每次循环的时候,都要首先解析$(”#abc”);势必效率变低,接着在使用after插入到#abc中去。这样子写效率会很低的,而下面的写法就高效了

var list = $(".abc");
var b = $("#abc");
for (var i = 0, l = list.length; i < l; i++) {//注意此处把list的长度提前计算出来,避免了每次循环重复计算
    var a=list[i].html();
    b.after(a);
}

这样的写法还不是最高效的,看下面的方法

var list = $(".abc");
var b = "";
for (var i = 0, l = list.length; i < l; i++) {//注意此处把list的长度提前计算出来,避免了每次循环重复计算
    b+=list[i].html();
}
$("#abc").after(b);

看似简单的Javascript代码,其实要做的功夫很多!

用while还是for?

对于我来说,那个使用的方便,那个用的变量少使用那个,如对顺序没有关系的循环可以使用while,如下面的两段代码,前者使用了for,后者使用了while,两者明显while使用的变量少,虽然for容易使大家理解

//使用for
var arr = [1,2,3,4,5,6,7];
var sum = 0;
for (var i = 0, l = arr.length; i < l; i++) {
    sum += arr[i];
}   
//使用while
var arr = [1,2,3,4,5,6,7];
var sum = 0, l = arr.length;
while (l--) {
    sum += arr[l];
}

条件判断的优化技巧

1、对于可能性的排列按照从高到底的顺序进行排列

原因很简单,可以减少程序的试探次数。
2、使用三目运算符三目运算符比if else判断语句效率高,而且往往代码比较简洁如下面的两段代码

//使用if else
if (a > b) {
    num = a;
} else {
    num = b;
}
//三目运算符
num = a > b ? a : b;
//谁说三目不能代替if else的function?
c=a>b?function(){
            }:function(){
                 };
c();

使用switch 代替if对于同一个条件不同情况的判断,使用switch简洁易懂,并且switch本身比if效率要高,在IE下尤为明显!

==与===的区别

看过jQuery源码的朋友发现,其中很多使用的是===,而不是==,这是因为===的效率比==要高,但是使用===要注意,===不会进行类型的转换,比如如果你确定比较两者类型相同,推荐使用===,这也是大家在编写代码时候自己细节的养成。当然也有一定的注意情况,下面仔细的说说==跟===的区别

=== 操作符的判断算法

在使用 === 来判断两个值是否相等的时候,如判断x===y,会首先比较两个值的类型是否相等,如果不相等的话,直接返回 false 。接着根据 x 的类型有不同的判断逻辑。

如果 x 的类型是 Undefined 或 Null,则返回 true 。
如果 x 的类型是 Number,只要 x 或 y 中有一个值为 NaN,就返回 false ;如果 x 和 y 的数字值相等,就返回 true ;如果 x 或 y 中有一个是 +0,另外一个是 -0,则返回 true 。
如果 x 的类型是 String,当 x 和 y 的字符序列完全相同时返回 true,否则返回 false 。
如果 x 的类型是 Boolean,当 x 和 y 同为 true 或 false 时返回 true,否则返回 false 。
当 x 和 y 引用相同的对象时返回 true,否则返回 false 。
== 操作符的判断算法

在使用 == 来判断两个值是否相等的时候,如判断x==y,当 x 和 y 的类型一样的时候,判断逻辑与 === 一样;如果 x 和 y 的类型不一样,== 不是简单的返回 false,而是会做一定的类型转换。

如果 x 和 y 中有一个是 null,另外一个是 undefined 的话,返回 true 。如null == undefined。
如果 x 和 y 中一个的类型是 String,另外一个的类型是 Number 的话,会将 String 类型的值转换成 Number 来比较。如3 == “3″。
如果 x 和 y 中一个的类型是 Boolean 的话,会将 Boolean 类型的值转换成 Number 来比较。如true == 1、true == “1″
如果 x 和 y 中一个的类型是 String 或 Number,另外一个的类型是 Object 的话,会将 Object 类型的值转换成基本类型来比较。如[3,4] == “3,4″
需要注意的是 == 操作符不一定是传递的,即从A == B, B == C并不能一定得出A == C。考虑下面的例子,var str1 = new String(”Hello”); var str2 = new String(”Hello”); str1 == “Hello”; str2 == “Hello”,但是str1 != str2。

typeof使用时候注意

对于同一个var a=”abc”;
在FF下typeof a==string 返回 true
在IE下返回false,IE就是这样的娇贵!
推荐写法:

typeof a==”string”

最后,尽量避免使用eval等语句!

eval、Function、execScript等语句会再次使用javascript解析引擎进行解析,需要消耗大量的执行时间。

P.S.此文章不断整理更新中,有好的想法,大家可以提出来讨论

Redis几个认识误区

前几天微博发生了一起大的系统故障, 很多技术的朋友都比较关心,其中的原因不会超出James Hamilton在On Designing and Deploying Internet-Scale Service(1)概括的那几个范围,James第一条经验“Design for failure”是所有互联网架构成功的一个关键。互联网系统的工程理论其实非常简单,James paper中内容几乎称不上理论,而是多条实践经验分享,每个公司对这些经验的理解及执行力决定了架构成败。

题外话说完,最近又研究了Redis。去年曾做过一个MemcacheDB, Tokyo Tyrant, Redis performance test, 到目前为止,这个benchmark结果依然有效。这1年我们经历了很多眼花缭乱的key value存储产品的诱惑,从Cassandra的淡出(Twitter暂停在主业务使用)到HBase的兴起(Facebook新的邮箱业务选用 HBase(2)),当再回头再去看Redis,发现这个只有1万多行源代码的程序充满了神奇及大量未经挖掘的特性。Redis性能惊人,国内前十大网站 的子产品估计用1台Redis就可以满足存储及Cache的需求。除了性能印象之外,业界其实普遍对Redis的认识存在一定误区。本文提出一些观点供大 家探讨。

1. Redis是什么

这个问题的结果影响了我们怎么用Redis。如果你认为Redis是一个key value store, 那可能会用它来代替MySQL;如果认为它是一个可以持久化的cache, 可能只是它保存一些频繁访问的临时数据。Redis是REmote DIctionary Server的缩写,在Redis在官方网站的的副标题是A persistent key-value database with built-in net interface written in ANSI-C for Posix systems,这个定义偏向key value store。还有一些看法则认为Redis是一个memory database,因为它的高性能都是基于内存操作的基础。另外一些人则认为Redis是一个data structure server,因为Redis支持复杂的数据特性,比如List, Set等。对Redis的作用的不同解读决定了你对Redis的使用方式。

互联网数据目前基本使用两种方式来存储,关系数据库或者key value。但是这些互联网业务本身并不属于这两种数据类型,比如用户在社会化平台中的关系,它是一个list,如果要用关系数据库存储就需要转换成一种 多行记录的形式,这种形式存在很多冗余数据,每一行需要存储一些重复信息。如果用key value存储则修改和删除比较麻烦,需要将全部数据读出再写入。Redis在内存中设计了各种数据类型,让业务能够高速原子的访问这些数据结构,并且不 需要关心持久存储的问题,从架构上解决了前面两种存储需要走一些弯路的问题。

2. Redis不可能比Memcache快

很多开发者都认为Redis不可能比Memcached快,Memcached完全基于内存,而Redis具有持久化保存特性,即使是异步 的,Redis也不可能比Memcached快。但是测试结果基本是Redis占绝对优势。一直在思考这个原因,目前想到的原因有这几方面。

  • Libevent。和 Memcached不同,Redis并没有选择libevent。Libevent为了迎合通用性造成代码庞大(目前Redis代码还不到 libevent的1/3)及牺牲了在特定平台的不少性能。Redis用libevent中两个文件修改实现了自己的epoll event loop(4)。业界不少开发者也建议Redis使用另外一个libevent高性能替代libev,但是作者还是坚持Redis应该小巧并去依赖的思 路。一个印象深刻的细节是编译Redis之前并不需要执行./configure。
  • CAS问题。CAS是Memcached中比较方便的一种防止竞争修改资源的方法。CAS实现需要为每个cache key设置一个隐藏的cas token,cas相当value版本号,每次set会token需要递增,因此带来CPU和内存的双重开销,虽然这些开销很小,但是到单机10G+ cache以及QPS上万之后这些开销就会给双方相对带来一些细微性能差别(5)。

3. 单台Redis的存放数据必须比物理内存小

Redis的数据全部放在内存带来了高速的性能,但是也带来一些不合理之处。比如一个中型网站有100万注册用户,如果这些资料要用Redis来存 储,内存的容量必须能够容纳这100万用户。但是业务实际情况是100万用户只有5万活跃用户,1周来访问过1次的也只有15万用户,因此全部100万用 户的数据都放在内存有不合理之处,RAM需要为冷数据买单。

这跟操作系统非常相似,操作系统所有应用访问的数据都在内存,但是如果物理内存容纳不下新的数据,操作系统会智能将部分长期没有访问的数据交换到磁盘,为新的应用留出空间。现代操作系统给应用提供的并不是物理内存,而是虚拟内存(Virtual Memory)的概念。

基于相同的考虑,Redis 2.0也增加了VM特性。让Redis数据容量突破了物理内存的限制。并实现了数据冷热分离。

4. Redis的VM实现是重复造轮子

Redis的VM依照之前的epoll实现思路依旧是自己实现。但是在前面操作系统的介绍提到OS也可以自动帮程序实现冷热数据分离,Redis只 需要OS申请一块大内存,OS会自动将热数据放入物理内存,冷数据交换到硬盘,另外一个知名的“理解了现代操作系统(3)”的Varnish就是这样实 现,也取得了非常成功的效果。

作者antirez在解释为什么要自己实现VM中提到几个原因(6)。主要OS的VM换入换出是基于Page概念,比如OS VM1个Page是4K, 4K中只要还有一个元素即使只有1个字节被访问,这个页也不会被SWAP, 换入也同样道理,读到一个字节可能会换入4K无用的内存。而Redis自己实现则可以达到控制换入的粒度。另外访问操作系统SWAP内存区域时block 进程,也是导致Redis要自己实现VM原因之一。

5. 用get/set方式使用Redis

作为一个key value存在,很多开发者自然的使用set/get方式来使用Redis,实际上这并不是最优化的使用方法。尤其在未启用VM情况下,Redis全部数据需要放入内存,节约内存尤其重要。

假如一个key-value单元需要最小占用512字节,即使只存一个字节也占了512字节。这时候就有一个设计模式,可以把key复用,几个key-value放入一个key中,value再作为一个set存入,这样同样512字节就会存放10-100倍的容量。

这就是为了节约内存,建议使用hashset而不是set/get的方式来使用Redis,详细方法见参考文献(7)。

6. 使用aof代替snapshot

Redis有两种存储方式,默认是snapshot方式,实现方法是定时将内存的快照(snapshot)持久化到硬盘,这种方法缺点是持久化之后 如果出现crash则会丢失一段数据。因此在完美主义者的推动下作者增加了aof方式。aof即append only mode,在写入内存数据的同时将操作命令保存到日志文件,在一个并发更改上万的系统中,命令日志是一个非常庞大的数据,管理维护成本非常高,恢复重建时 间会非常长,这样导致失去aof高可用性本意。另外更重要的是Redis是一个内存数据结构模型,所有的优势都是建立在对内存复杂数据结构高效的原子操作 上,这样就看出aof是一个非常不协调的部分。

其实aof目的主要是数据可靠性及高可用性,在Redis中有另外一种方法来达到目的:Replication。由于Redis的高性能,复制基本没有延迟。这样达到了防止单点故障及实现了高可用。

小结

要想成功使用一种产品,我们需要深入了解它的特性。Redis性能突出,如果能够熟练的驾驭,对国内很多大型应用具有很大帮助。希望更多同行加入到Redis使用及代码研究行列。