`
wenbois2000
  • 浏览: 46143 次
  • 性别: Icon_minigender_1
  • 来自: 湖南
社区版块
存档分类
最新评论

High Performance JavaScript 读书笔记(一)

    博客分类:
  • Web
阅读更多

一.Loading and Execution
   JavaScript performance in the browser is arguably the most important usability issue facing developers. The problem is complex because of the blocking nature of JavaScript, which is to say that nothing else can happen while JavaScript code is being executed.

    In fact, most browsers use a single process for both user interface (UI) updates and JavaScript execution, so only one can happen at any given moment in time. The longer JavaScript takes to execute, the longer it takes before the browser is free to respond to user input.

    On a basic level, this means that the very presence of a <script> tag is enough to make the page wait for the script to be parsed and executed. Whether the actual JavaScript code is inline with the tag or included in an external file is irrelevant; the page download and rendering must stop and wait for the script to complete before proceeding. This is a necessary part of the page’s life cycle because the script may cause changes to the page while executing. The typical example is using document.write() in the middle of a page (as often used by advertisements).
    When the browser encounters a <script> tag, as in this HTML page, there is no way of knowing whether the JavaScript will insert content into the <p>, introduce additional elements, or perhaps even close the tag. Therefore, the browser stops processing the page as it comes in, executes the JavaScript code, then continues parsing and rendering the page. The same takes place for JavaScript loaded using the src attribute; the browser must first download the code from the external file, which takes time, and then parse and execute the code. Page rendering and user interaction are completely blocked during this time.

  •  Script Positioning
         The HTML 4 specification indicates that a <script> tag may be placed inside of a <head> or <body> tag in an HTML document and may appear any number of times within each. Traditionally, <script> tags that are used to load external JavaScript files have appeared in the <head>, along with <link> tags to load external CSS files and other metainformation about the page. The theory was that it’s best to keep as many style and behavior dependencies together, loading them first so that the page will come in looking and behaving correctly. For example:
    <html>
    <head>
    	<title>Script Example</title>
    	<-- Example of inefficient script positioning -->
    	<script type="text/javascript" src="file1.js"></script >
    	<script type="text/javascript" src="file2.js"></script >
    	<script type="text/javascript" src="file3.js"></script >
    	<link rel="stylesheet" type="text/css" href="styles.css">
    </head>
    <body>
    	<p>Hello world!</p>
    </body>
    </html>
    
       Though this code seems innocuous, it actually has a severe performance issue: there are three JavaScript files being loaded in the <head>. Since each <script> tag blocks the page from continuing to render until it has fully downloaded and executed the JavaScript code, the perceived performance of this page will suffer. Keep in mind that browsers don’t start rendering anything on the page until the opening <body> tag is encountered. Putting scripts at the top of the page in this way typically leads to a noticeable delay, often in the form of a blank white page, before the user can even begin reading or otherwise interacting with the page.
        Internet Explorer 8, Firefox 3.5, Safari 4, and Chrome 2 all allow parallel downloads of JavaScript files. This is good news because the <script> tags don’t necessarily block other <script> tags from downloading external resources. Unfortunately, JavaScript downloads still block downloading of other resources, such as images. And even though downloading a script doesn’t block other scripts from downloading, the page must still wait for the JavaScript code to be downloaded and executed before continuing. So while the latest browsers have improved performance by allowing parallel downloads, the problem hasn’t been completely solved. Script blocking still remains a problem.
        Because scripts block downloading of all resource types on the page, it’s recommended to place all <script> tags as close to the bottom of the <body> tag as possible so as not to affect the download of the entire page. For example:
    <html>
    <head>
    	<title>Script Example</title>
    	<link rel="stylesheet" type="text/css" href="styles.css">
    </head>
    	<body>
    	<p>Hello world!</p>
    
    	<-- Example of recommended script positioning -->
    	<script type="text/javascript" src="file1.js"></script >
    	<script type="text/javascript" src="file2.js"></script >
    	<script type="text/javascript" src="file3.js"></script >
    </body>
    </html>
    
       This code represents the recommended position for <script> tags in an HTML file. Even though the script downloads will block one another, the rest of the page has already been downloaded and displayed to the user so that the entire page isn’t perceived as slow. This is the Yahoo! Exceptional Performance team’s first rule about JavaScript: put scripts at the bottom.

  • Grouping Scripts
       Since each <script> tag blocks the page from rendering during initial download, it’s helpful to limit the total number of <script> tags contained in the page. This applies to both inline scripts as well as those in external files. Every time a <script> tag is encountered during the parsing of an HTML page, there is going to be a delay while the code is executed; minimizing these delays improves the overall performance of the page.
       The problem is slightly different when dealing with external JavaScript files. Each HTTP request brings with it additional performance overhead, so downloading one single 100 KB file will be faster than downloading four 25 KB files. To that end, it’s helpful to limit the number of external script files that your page references. 
       Typically, a large website or web application will have several required JavaScript files. You can minimize the performance impact by concatenating these files together into a single file and then calling that single file with a single <script> tag.

  • Nonblocking Scripts
       JavaScript’s tendency to block browser processes, both HTTP requests and UI updates,is the most notable performance issue facing developers. Keeping JavaScript files small and limiting the number of HTTP requests are only the first steps in creating a responsive web application. The richer the functionality an application requires, the more JavaScript code is required, and so keeping source code small isn’t always an option.
       Limiting yourself to downloading a single large JavaScript file will only result in locking the browser out for a long period of time, despite it being just one HTTP request. To get around this situation, you need to incrementally add more JavaScript to the page in a way that doesn’t block the browser.
       The secret to nonblocking scripts is to load the JavaScript source code after the page has finished loading. In technical terms, this means downloading the code after the window’s load event has been fired. There are a few techniques for achieving this result.

    Deferred Scripts
        HTML 4 defines an additional attribute for the <script> tag called defer. The defer attribute indicates that the script contained within the element is not going to modify the DOM and therefore execution can be safely deferred until a later point in time. The defer attribute is supported only in Internet Explorer 4+ and Firefox 3.5+, making it less than ideal for a generic cross-browser solution. In other browsers, the defer attribute is simply ignored and so the <script> tag is treated in the default (blocking) manner. Still, this solution is useful if your target browsers support it. The following is an example usage:
    <script type="text/javascript" src="file1.js" defer></script >
        A <script> tag with defer may be placed anywhere in the document. The JavaScript file will begin downloading at the point that the <script> tag is parsed, but the code will not be executed until the DOM has been completely loaded (before the onload event handler is called). When a deferred JavaScript file is downloaded, it doesn’t block the browser’s other processes, and so these files can be downloaded in parallel with others on the page.
       Any <script> element marked with defer will not execute until after the DOM has been completely loaded; this holds true for inline scripts as well as for external script files. The following simple page demonstrates how the defer attribute alters the behavior of scripts:
    <html>
    <head>
    	<title>Script Defer Example</title>
    </head>
    <body>
    	<script defer>
    		alert("defer");
    	</script >
    	<script>
    		alert("script");
    	</script >
    	<script>
    		window.onload = function(){
    			alert("load");
    		};
    	</script >
    </body>
    </html>
    
       This code displays three alerts as the page is being processed. In browsers that don’t support defer, the order of the alerts is “defer”, “script”, and “load”. In browsers that support defer, the order of the alerts is “script”, “defer”, and “load”. Note that the deferred <script> element isn’t executed until after the second but is executed before the onload event handler is called.

    Dynamic Script Elements
        The Document Object Model (DOM) allows you to dynamically create almost any part of an HTML document using JavaScript. At its root, the <script> element isn’t any different than any other element on a page: references can be retrieved through the DOM, and they can be moved, removed from the document, and even created. A new <script> element can be created very easily using standard DOM methods:
    var script = document.createElement("script");
    script.type = "text/javascript";
    script.src = "file1.js";
    document.getElementsByTagName("head")[0].appendChild(script);
    
       This new <script> element loads the source file file1.js. The file begins downloading as soon as the element is added to the page. The important thing about this technique is that the file is downloaded and executed without blocking other page processes, regardless of where the download is initiated. You can even place this code in the <head> of a document without affecting the rest of the page (aside from the one HTTP connection that is used to download the file).
        When a file is downloaded using a dynamic script node, the retrieved code is typically executed immediately (except in Firefox and Opera, which will wait until any previous dynamic script nodes have executed). This works well when the script is self-executing but can be problematic if the code contains only interfaces to be used by other scripts on the page. In that case, you need to track when the code has been fully downloaded and is ready for use. This is accomplished using events that are fired by the dynamic <script> node.
        Firefox, Opera, Chrome, and Safari 3+ all fire a load event when the src of a <script> element has been retrieved. You can therefore be notified when the script is ready by listening for this event:
    var script = document.createElement("script")
    script.type = "text/javascript";
    //Firefox, Opera, Chrome, Safari 3+
    script.onload = function(){
    	alert("Script loaded!");
    };
    script.src = "file1.js";
    document.getElementsByTagName("head")[0].appendChild(script);
    
       Internet Explorer supports an alternate implementation that fires a readystatechange event. There is a readyState property on the <script> element that is changed at various times during the download of an external file. There are five possible values for ready State:
        
    "uninitialized"
           The default state
    
    "loading"
           Download has begun
    
    "loaded"
           Download has completed
    
    "interactive"
           Data is completely downloaded but isn’t fully available
    
    "complete"
           All data is ready to be used
    
     
         Microsoft’s documentation for readyState and each of the possible values seems to indicate that not all states will be used during the lifetime of the <script> element, but there is no indication as to which will always be used. In practice, the two states of most interest are "loaded" and "complete". Internet Explorer is inconsistent with which of these two readyState values indicates the final state, as sometimes the <script> element will reach the "loaded" state but never reach "complete" whereas other times "complete" will be reached without "loaded" ever having been used. The safest way to use the readystatechange event is to check for both of these states and remove the event handler when either one occurs (to ensure the event isn’t handled twice):
    var script = document.createElement("script")
    script.type = "text/javascript";
    //Internet Explorer
    script.onreadystatechange = function(){
    	if (script.readyState == "loaded" || script.readyState == "complete"){
    		script.onreadystatechange = null;
    		alert("Script loaded.");
    	}
    };
    script.src = "file1.js";
    document.getElementsByTagName("head")[0].appendChild(script);
    
        In most cases, you’ll want to use a single approach to dynamically load JavaScript files. The following function encapsulates both the standard and IE-specific functionality:
    function loadScript(url, callback){
    	var script = document.createElement("script")
    	script.type = "text/javascript";
    	if (script.readyState){ //IE
    		script.onreadystatechange = function(){
    			if (script.readyState == "loaded" || script.readyState == "complete"){
    				script.onreadystatechange = null;
    				callback();
    			}
    		}
    	} else { //Others
    		script.onload = function(){
    			callback();
    		};
    	}
    	script.src = url;
    	document.getElementsByTagName("head")[0].appendChild(script);
    }
    
       You can dynamically load as many JavaScript files as necessary on a page, but make sure you consider the order in which files must be loaded. Of all the major browsers, only Firefox and Opera guarantee that the order of script execution will remain the same as you specify. Other browsers will download and execute the various code files in the order in which they are returned from the server. You can guarantee the order by chaining the downloads together, such as:
    loadScript("file1.js", function(){
    	loadScript("file2.js", function(){
    		loadScript("file3.js", function(){
    			alert("All files are loaded!");
    		});
    	});
    });
    
       If the order of multiple files is important, the preferred approach is to concatenate the files into a single file where each part is in the correct order. That single file can then be downloaded to retrieve all of the code at once (since this is happening asynchronously, there’s no penalty for having a larger file).
        Dynamic script loading is the most frequently used pattern for nonblocking JavaScript downloads due to its cross-browser compatibility and ease of use.

    XMLHttpRequest Script Injection
        Another approach to nonblocking scripts is to retrieve the JavaScript code using an XMLHttpRequest (XHR) object and then inject the script into the page. This technique involves creating an XHR object, downloading the JavaScript file, then injecting the javaScript code into the page using a dynamic <script> element. Here’s a simple example:
    var xhr = new XMLHttpRequest();
    xhr.open("get", "file1.js", true);
    xhr.onreadystatechange = function(){
    if (xhr.readyState == 4){
    	if (xhr.status >= 200 && xhr.status < 300 || xhr.status == 304){
    		var script = document.createElement("script");
    			script.type = "text/javascript";
    			script.text = xhr.responseText;
    			document.body.appendChild(script);
    		}
    	}
    };
    xhr.send(null);
    
       This code sends a GET request for the file file1.js. The onreadystatechange event handler checks for a readyState of 4 and then verifies that the HTTP status code is valid (anything in the 200 range means a valid response, and 304 means a cached response). If a valid response has been received, then a new <script> element is created and its text property is assigned to the responseText received from the server. Doing so essentially creates a <script> element with inline code. Once the new <script> element is added to the document, the code is executed and is ready to use.
      The primary advantage of this approach is that you can download the JavaScript code without executing it immediately. Since the code is being returned outside of a <script> tag, it won’t automatically be executed upon download, allowing you to defer its execution until you’re ready. Another advantage is that the same code works in all modern browsers without exception cases.
      The primary limitation of this approach is that the JavaScript file must be located on the same domain as the page requesting it, which makes downloading from CDNs impossible. For this reason, XHR script injection typically isn’t used on large-scale web applications.

    Recommended Nonblocking Pattern
      The recommend approach to loading a significant amount of JavaScript onto a page is a two-step process: first, include the code necessary to dynamically load JavaScript,and then load the rest of the JavaScript code needed for page initialization. Since the first part of the code is as small as possible, potentially containing just the load Script() function, it downloads and executes quickly, and so shouldn’t cause much interference with the page. Once the initial code is in place, use it to load the remaining JavaScript. For example:
    <script type="text/javascript" src="loader.js"></script >
    <script type="text/javascript">
    	loadScript("the-rest.js", function(){
    		Application.init();
    	});
    </script >
    
       Place this loading code just before the closing </body> tag. Doing so has several benefits. First, as discussed earlier, this ensures that JavaScript execution won’t prevent the rest of the page from being displayed. Second, when the second JavaScript file has finished downloading, all of the DOM necessary for the application has been created and is ready to be interacted with, avoiding the need to check for another event (such as window.onload) to know when the page is ready for initialization.
分享到:
评论

相关推荐

    High Performance JavaScript(高性能JavaScript)读书笔记分析

    通过上述内容的详细解读,可以看出《High Performance JavaScript》一书对提高JavaScript代码性能的各个方面都进行了深入探讨,并提供了大量实用的建议和技巧。掌握书中的知识对于提升Web应用的响应速度和用户体验...

    High Performance Browser Networking

    《高性能浏览器网络》一书由Ilya Grigorik撰写,旨在向每一位网页开发者传达有关网络和网页性能的关键知识点。该书强调浏览器作为目前开发者最广泛部署的平台,其在网络性能方面的重要性。随着智能手机、平板电脑、...

    菜鸟吧 Web学习完全手册 网页设计工具大全

    我想学习建站技术,从哪里开始呢? XHTML基础教程 ...《High Performance Web Sites》读书笔记 单片机笔记 C51笔记 51单片机实验 51单片机的Proteus实验 单片机小工具 ARM的Proteus实验 全站打包资源

    JavaScript 总结几个提高性能知识点(推荐)

    前段时间花时间看了大半的《High Performance JavaScript》这本书啊,然后就开始忙项目了,庆幸最忙的一周已经熬过去了。由于空不出时间,这个月写的学习笔记也不多,忙完最苦X的一周,这两天晚上也算是挑灯夜读了…...

    MATLAB-GUI-平台的人脸购物系统.zip

    程序可以参考,非常好的思路建设,完美!

    MATLAB-GUI-平台的人脸考勤.zip

    程序可以参考,非常好的思路建设,完美!

    【毕业设计】java+springboot+vue二手车估值与销售平台实现(完整前后端+mysql+说明文档+LunW).zip

    【毕业设计】java+springboot+vue二手车估值与销售平台实现(完整前后端+mysql+说明文档+LunW).zip

    【悬索桥】基于matlab单跨悬索桥风致静位移的基准解决方案【含Matlab源码 9993期】.mp4

    海神之光上传的视频是由对应的完整代码运行得来的,完整代码皆可运行,亲测可用,适合小白; 1、从视频里可见完整代码的内容 主函数:main.m; 调用函数:其他m文件;无需运行 运行结果效果图; 2、代码运行版本 Matlab 2019b;若运行有误,根据提示修改;若不会,私信博主; 3、运行操作步骤 步骤一:将所有文件放到Matlab的当前文件夹中; 步骤二:双击打开main.m文件; 步骤三:点击运行,等程序运行完得到结果; 4、仿真咨询 如需其他服务,可私信博主; 4.1 博客或资源的完整代码提供 4.2 期刊或参考文献复现 4.3 Matlab程序定制 4.4 科研合作

    【图像加密解密】基于matlab混沌和DCT变换图像加密解密【含Matlab源码 9709期】.mp4

    海神之光上传的视频是由对应的完整代码运行得来的,完整代码皆可运行,亲测可用,适合小白; 1、从视频里可见完整代码的内容 主函数:main.m; 调用函数:其他m文件;无需运行 运行结果效果图; 2、代码运行版本 Matlab 2019b;若运行有误,根据提示修改;若不会,私信博主; 3、运行操作步骤 步骤一:将所有文件放到Matlab的当前文件夹中; 步骤二:双击打开main.m文件; 步骤三:点击运行,等程序运行完得到结果; 4、仿真咨询 如需其他服务,可私信博主; 4.1 博客或资源的完整代码提供 4.2 期刊或参考文献复现 4.3 Matlab程序定制 4.4 科研合作

    三菱PLC程序大型项目:QCPU+QD77MS集成电气开发系统,包含自动化设备控制程序、伺服模块设置与通信功能丰富的控制系统 ,三菱PLC大型自动化控制项目:涵盖电气开发全套资料、高效程序结构设计与丰

    三菱PLC程序大型项目:QCPU+QD77MS集成电气开发系统,包含自动化设备控制程序、伺服模块设置与通信功能丰富的控制系统。,三菱PLC大型自动化控制项目:涵盖电气开发全套资料、高效程序结构设计与丰富通信功能应用,三菱PlC程序大型项目QCPU+QD77MS16 项目说明如下: 1.包含一套完整的电气开发系统资料(包含plc程序,触摸屏程序,伺服模块设置程序,程序开发地址规划表) 2.这套开发程序是用一套完美的程序结构进行设计,掌握这套程序结构后就可以开发各种自动化设备控制程序 3.提供的这套三菱plc程序开发地址规划表可以大大提高程序开发效率 4.三菱伺服运动模块设置程序中包含详细的各轴参数设置可以参考学习 5.触摸屏程序中也有一套完美的框架结构,掌握以后可以套用各种自动化设备 6.这套控制系统,包含几十个三菱伺服,三协机器人,BCR,CCD色彩检测仪等,用到串口通信,socket套接字通信,Cclink IE通信功能丰富多样。 ,三菱PLC程序; QCPU+QD77MS16; 电气开发系统资料; 程序结构; 开发效率; 伺服运动模块设置; 轴参数设置; 触摸屏程序框架; 三菱

    096-FreeRTOS+LCD1602+ADS1015 application.rar

    freertos

    【毕业设计】java-springboot+vue高校学科竞赛平台源码(完整前后端+mysql+说明文档+LunW).zip

    【毕业设计】java-springboot+vue高校学科竞赛平台源码(完整前后端+mysql+说明文档+LunW).zip

    CmsTop模板帮助手册.mht

    CmsTop模板帮助手册

    【光学】基于matlab菲涅耳衍射S-FFT计算平面波照射下给定波长及距离的衍射场振幅图像【含Malab源码 11032期】.mp4

    海神之光上传的视频是由对应的完整代码运行得来的,完整代码皆可运行,亲测可用,适合小白; 1、从视频里可见完整代码的内容 主函数:main.m; 调用函数:其他m文件;无需运行 运行结果效果图; 2、代码运行版本 Matlab 2019b;若运行有误,根据提示修改;若不会,私信博主; 3、运行操作步骤 步骤一:将所有文件放到Matlab的当前文件夹中; 步骤二:双击打开main.m文件; 步骤三:点击运行,等程序运行完得到结果; 4、仿真咨询 如需其他服务,可私信博主; 4.1 博客或资源的完整代码提供 4.2 期刊或参考文献复现 4.3 Matlab程序定制 4.4 科研合作

    【PFJSP问题】基于matlab灰狼算法GWO求解置换流水车间调度问题PFSP【含Matlab源码 10023期】.mp4

    海神之光上传的视频是由对应的完整代码运行得来的,完整代码皆可运行,亲测可用,适合小白; 1、从视频里可见完整代码的内容 主函数:main.m; 调用函数:其他m文件;无需运行 运行结果效果图; 2、代码运行版本 Matlab 2019b;若运行有误,根据提示修改;若不会,私信博主; 3、运行操作步骤 步骤一:将所有文件放到Matlab的当前文件夹中; 步骤二:双击打开main.m文件; 步骤三:点击运行,等程序运行完得到结果; 4、仿真咨询 如需其他服务,可私信博主; 4.1 博客或资源的完整代码提供 4.2 期刊或参考文献复现 4.3 Matlab程序定制 4.4 科研合作

    【气动学】基于matlab飞行器机动飞行质点弹道仿真(侧向和纵向)【含Matlab源码 9722期】.mp4

    海神之光上传的视频是由对应的完整代码运行得来的,完整代码皆可运行,亲测可用,适合小白; 1、从视频里可见完整代码的内容 主函数:main.m; 调用函数:其他m文件;无需运行 运行结果效果图; 2、代码运行版本 Matlab 2019b;若运行有误,根据提示修改;若不会,私信博主; 3、运行操作步骤 步骤一:将所有文件放到Matlab的当前文件夹中; 步骤二:双击打开main.m文件; 步骤三:点击运行,等程序运行完得到结果; 4、仿真咨询 如需其他服务,可私信博主; 4.1 博客或资源的完整代码提供 4.2 期刊或参考文献复现 4.3 Matlab程序定制 4.4 科研合作

    【车间调度】基于matlab斑马算法ZOA求解分布式置换流水车间调度DPFSP【含Matlab源码 6134期】.mp4

    海神之光上传的视频是由对应的完整代码运行得来的,完整代码皆可运行,亲测可用,适合小白; 1、从视频里可见完整代码的内容 主函数:main.m; 调用函数:其他m文件;无需运行 运行结果效果图; 2、代码运行版本 Matlab 2019b;若运行有误,根据提示修改;若不会,私信博主; 3、运行操作步骤 步骤一:将所有文件放到Matlab的当前文件夹中; 步骤二:双击打开main.m文件; 步骤三:点击运行,等程序运行完得到结果; 4、仿真咨询 如需其他服务,可私信博主; 4.1 博客或资源的完整代码提供 4.2 期刊或参考文献复现 4.3 Matlab程序定制 4.4 科研合作

    基于遗传算法优化的CNN-LSTM股票预测模型研究与应用

    内容概要:本文提出了一种基于遗传算法(GA)优化的CNN-LSTM混合深度学习模型,用于预测韩国股市指数(KOSPI)的日收盘价。CNN用以提取特征,LSTM用于处理时间序列数据并发现长短期相关性,而GA则用于优化参数选择,确保模型最佳性能。研究表明,相比单一CNN、LSTM以及未优化的CNN-LSTM模型,提出的模型在误差率指标上显著提高预测准确性。具体而言,在均方误差(MSE)、平均绝对误差(MAE)和平均绝对百分比误差(MAPE)方面表现出更好的表现。作者还强调了未来改进方向,如纳入宏观经济因素和延长预测周期。 适合人群:对金融市场特别是股价预测有兴趣的研究人员、交易员和投资者。 使用场景及目标:本模型适用于利用深度学习进行股票价格波动预测的需求,为决策提供更具可靠性的依据。 其他说明:文章详细阐述了数据准备流程和技术细节,并提供了实验设置与结果分析图表。同时指出了一些潜在的发展趋势,比如融合多种分析手段提升精度的可能性及其局限性讨论。

    【图像去噪】小波变换图像去噪【含Matlab源码 3726期】.md

    CSDN Matlab武动乾坤上传的资料均是完整代码运行出的仿真结果图,可见完整代码亲测可用,适合小白; 1、完整的代码内容 主函数:main.m; 调用函数:其他m文件;无需运行 运行结果效果图; 2、代码运行版本 Matlab 2019b;若运行有误,根据提示修改;若不会,私信博主; 3、运行操作步骤 步骤一:将所有文件放到Matlab的当前文件夹中; 步骤二:双击打开main.m文件; 步骤三:点击运行,等程序运行完得到结果; 4、仿真咨询 如需其他服务,可私信博主或扫描博客文章底部QQ名片; 4.1 博客或资源的完整代码提供 4.2 期刊或参考文献复现 4.3 Matlab程序定制 4.4 科研合作

    燃料电池仿真模型:基于Cruise与Simulink联合开发,源文件全包的实战项目解析,燃料电池仿真模型:基于Cruise与Simulink联合开发,源文件全包的实战项目解析,燃料电池仿真模型燃料电池

    燃料电池仿真模型:基于Cruise与Simulink联合开发,源文件全包的实战项目解析,燃料电池仿真模型:基于Cruise与Simulink联合开发,源文件全包的实战项目解析,燃料电池仿真模型燃料电池仿真模型,本模型基于Cruise软件和 Simulink软件共同搭建完成,并基于实际项目搭建,本资料包包含所有源文件 ,关键词:燃料电池仿真模型;Cruise软件;Simulink软件;实际项目;源文件;,Cruise Simulink 联合建模的燃料电池仿真模型全套源文件分享

Global site tag (gtag.js) - Google Analytics