zoukankan      html  css  js  c++  java
  • javascript if else优化指南

    不管是平时在学习js中还是在项目书中写js代码,都避免不了一个问题就是有时候要做大量的分支判断,很多人的第一反应就是使用if else。无可厚非,if else早平时做分支判断的时候是非常好用的,但是代码中嵌套的if/else结构往往导致代码不美观,也不易于理解而且性能低下。所以有时候在我们做项目的时候不可避免的一点的就是要做一些代码的性能以及逻辑的优化。

     

    1简单的逻辑判断常用的优化方法 

    1.1使用‖

    var a = 1;
    if(a){
      a = 1;
    }else{
      a = 0;
    };
    //可写成
    a = a || 0;

     

    1.2使用三元表达式

    var a = 1;
    var b = 2;
    var c = 3;
    var d = 4;
    if(a == b){
      a = c;
    }else{
      a = d;
    }
    //可写成
    a = (a == b) ? c : d;

     

     

    1.3按位异或运算符^

    var a = 1;
    var b = 2;
    var c = 1;
    if(a == c){
      c = b;
    }else if(b == c){
      c = a;
    };
    //可写成
    c = a ^ b ^ c;

     


     

     

    2复杂的逻辑判断常用的优化方法

     

    2.1优化if逻辑

     

    人们考虑的东西到时候,都会把最可能发生的情况先做好准备。优化if逻辑的时候也可以这样想:把最可能出现的条件放在前面,把最不可能出现的条件放在后面,这样程序执行时总会按照写的逻辑的先后顺序逐一检测所有的条件,知道发现匹配的条件才会停止继续检测。

     

    if的优化目标:最小化找到分支之前所判断条件体的数量。 
    if优化的方法:将最常见的条件放在首位。

    var a = 1;
    if(a < 10){
      //代码
    }else if(a > 10 && a < 100){
       //代码
    }else{
       //代码
    }

     

    以上只有在a值经常出现小于5的时候是最优化的。如果a值经常大于或者等于10的话,那么在进入正确的分支之前,就必须两次运算条件体,导致表达式的平均运算时间增加。if中的条件体应该总是按照从最大概率到最小概率排列,以保证理论速度最快

     

    2.2switch/case

     

    switch和if else在性能上是没有什么区别的,主要还是根据需求进行分析和选择。

    条件较小的话选用if else比较合适。 
    条件数量较大的话,就建议选用switch。 
    在大多数的情况下switch比if else运行的更加快。

    var title = document.querySelector('h1'); //h1节点对象
    var txt = title.innerText; //h1节点文本内容
    var dayText = ''; //星期几 对应的文本
    var date = new Date();  //日期对象
    var day = date.getDay(); //获得 星期几 0 - 6

    switch (day) {
       case 0:
           dayText = '日';
           break;
       case 1:
           dayText = '一';
           break;
       case 2:
           dayText = '二';
           break;
       case 3:
           dayText = '三';
           break;
       case 4:
           dayText = '四';
           break;
       case 5:
           dayText = '五';
           break;
       case 6:
           dayText = '六';
           break;
       default:
           break;
    }
    title.innerText = txt.substr(0,5)+ dayText;

     

    上述的逻辑情况在具体的判断选择上,不管是代码的优雅程度还是性能上明显switch是比要if else要优。

     

    2.3数组映射

     
    在数据查找速度方面,如果能够直接映射到的查找方式绝对比if else判断包括switch的性能好的太多。在js中,熟练的应用数组(包括后面提到的JSON),不管是在数据的存储方面还是在业务逻辑的优化方面绝对是所有做前端开发者中必须套掌握的

     

    //用空间换取时间
    var dayArr = ['天','一','二','三','四','五','六'];
    //用day做下标 指引元素
    dayText = dayArr[day];
    title.innerText = txt.substr(0,5)+ dayText;

     

    上述代码就是通过映射的方式来查找数据,直接省去了诸多的判断过程。

     

    2.4使用JSON优化

     

    在前后台传输数据的过程中,现在用的越来越多的传输的数据格式为JSON,第一是因为JSON是基于文本的数据格式,相对于基于二进制的数据,所以JSON在传递的时候是传递符合JSON这种格式的字符串;第二就是JSON比较轻量,即相同数据,以JSON的格式占据的带宽更小,这在有大量数据请求和传递的情况下是有明显优势的。

     

    //用空间换取时间
    var data = {
       "0" : "日",
       "1" : "一",
       "2" : "二",
       "3" : "三",
       "4" : "四",
       "5" : "五",
       "6" : "六",
    };
    //用key做下标 指引元素
    dayText = data[key];
    title.innerText = txt.substr(0,5)+ dayText;

     

    2.5重构,用OO里面的继承或者组合

     

    如果是乔丹,就是23
    如果是科比,就是24
    如果是韦德,就是3
    如果是麦迪,就是1
    如果都不是,就是0

     

    来重构一下,改成OO

     

    *定义类: 球员(或者接口)
    *定义方法:就是
    *定义子类:乔丹、科比、韦德、麦迪、无
    *重写方法 ---- 就是

     

    定义一个函数,如果说是用if else:

     

    function getNumber(name) {
      if (name === "乔丹") {
           console.log(23);
       } else if (name === "科比") {
           console.log(24);
       } else if (name === "韦德"){
           console.log(3);
       }else if (name === "麦迪"){
           console.log(1);
       }else{
            console.log(0);
       }
    }

     

    那如果用下面的方法会更好:

     

    function getNumber(name){
       var player = {
           "乔丹" : "23",
           "科比" : "24",
           "韦德" : "3",
           "麦迪" : "1",
           "无"  : "0"
       };
       console.log(player[name] ? player[name] : player["无"] );
    }

     

    总结

     

    其实写代码记住三个字即可,短简易。代码短,读起来简单,维护容易,如果在性能和代码长度上二选一,我肯定选代码短,性能好的。而冗长的代码并不是加个程序员就能搞定的。 
    保持着这个心态写代码,写出的东西离设计模式也不会差太多了。 
    多说一句:存在必有其价值,不能说if else多了就不好,凡事无绝对,适合A的未必就适合B,每个东西都有其实现的场景。同理改写设计模式未必就是最棒的,听起来高大上点而已

  • 相关阅读:
    团队项目-第一阶段冲刺7
    团队项目-第一阶段冲刺6
    Spring Boot 揭秘与实战(七) 实用技术篇
    Spring Boot 揭秘与实战(七) 实用技术篇
    Spring Boot 揭秘与实战(六) 消息队列篇
    Spring Boot 揭秘与实战(五) 服务器篇
    Spring Boot 揭秘与实战(五) 服务器篇
    Spring Boot 揭秘与实战(五) 服务器篇
    Spring Boot 揭秘与实战(五) 服务器篇
    Spring Boot 揭秘与实战(四) 配置文件篇
  • 原文地址:https://www.cnblogs.com/ifworld/p/8094402.html
Copyright © 2011-2022 走看看