这是Jerry在2021年的第66篇文章，也是王子熙第343篇原创文章公众号。国庆黄金周开始的前一天，也就是9月30日，我的开发团队接到了一个关于Angular应用的服务端渲染（ServerSideRender，简称SSR）的客户事件，让我有了学习的机会如何使用Chrome开发或工具来分析Web应用程序的性能问题。Jerry之前写过一篇关于Chrome开发者工具的文章：Jerry和你聊聊Chrome开发者工具，这篇文章是那篇文章的后续。本来想以Angular应用为例来介绍一下工具的使用方法，但是考虑到这篇公众号的10000多位读者中，大部分前端开发的朋友还在使用SAPUI5，所以我最后选择使用SAPUI5Application来介绍使用ChromeDevTools进行web应用性能分析的步骤。本文所说的SAPUI5应用是指FreeStyle开发的SAPUI5应用。通过FioriElements开发的SAPUI5，本文不做讨论。根据我以往的工作经验，如果一个SAPUI5应用出现性能问题，很多时候性能瓶颈在于应用所消耗的后台API，比如OData服务或者其他AJAX调用。与Angular相比，SAPUI5框架为应用开发者屏蔽了很多Web前端开发中的底层细节，比如DOM操作、CSS编辑、数据双向绑定和事件注册等，这些都被封装起来用户界面5。.因此，在一个SAPUI5应用中，在纯前端代码中，由于应用人员的编码失误而出现性能问题的概率远低于Angular。因此，为了演示使用Chrome开发者工具进行SAPUI5性能分析，我特意在我的SAPUI5脚手架应用中写了一些会导致性能问题的前端代码，然后通过Chrome开发者工具，将这些导致性能问题的问题的代码位于。我的SAPUI5脚手架应用可以通过以下url访问：https://wangzixi-diablo.github...这个UI5应用的视图是通过JavaScript视图类型实现的。在视图实现文件App.view.js的createContent方法中，我调用了一个函数heavyFunction，它在for循环中创建10,000个div标签，将它们添加到DOM树，然后将1亿个元素插入到数组中。我期望的结果是能够使用Chrome开发者工具分析SAPUI5应用的性能，并借助该工具，快速定位性能问题到heavyFunction函数。其实使用Chrome开发者工具的Performance面板分析web应用的性能和SAPABAP数据库性能分析工具ST05非常相似，就是开启跟踪模式，运行数据库事务（web应用）在此模式下，然后关闭跟踪模式，并分析ST05（Chrome开发者工具）的跟踪输出。首先打开一个Chrome的隐身窗口，这是为了排除Chrome安装的其他扩展可能对性能分析造成的影响。打开Chrome开发者工具，选择Performance选项卡，打开设置选项，Network选择Slow3G，CPU选择Speedreduction6倍：6xslowdown。然后点击Record图标开启性能追踪模式：刷新应用程序使其进入性能追踪模式下一次运行：等待页面显示出来，点击Stop按钮关闭追踪模式。然后我们可以看到如下图所示的trace结果：请看下图代表CPU执行活动的条形图，其中在两个时间点内有大量密集的脚本执行（scripting）和渲染（rendering）活动记录。我们首先详细分析为什么会有如此密集的脚本操作。移动下图所示的两个滑块来缩小时间戳范围（范围）以进行故障排除。时间戳范围越小，显示的细节越具体。您是否注意到我在上图中用红色矩形突出显示的主下拉框？下拉框下方显示Main即指定左右时间戳范围内的主线程执行的CPU活动详情。我们把Main下拉框中显示的内容拖到最下面，突然发现我们特意写的heavyFunction被列出来了。在我们指定的时间戳范围内，总共执行了6.799秒。点击App.view.js的超链接直接跳转对应代码：接下来我们调整左右时间戳滑块来研究Rendering，也就是下图中紫色条代表的activity。我们观察到每个紫色条的右上角都有一个红色三角形图标。将鼠标放在上面，工具提示将显示：Forcedreflowisalikelyperformancebottleneck。这意味着强制回流是应用程序可能的性能瓶颈。在上图中，我们可以观察到RecalculateStyle和Layout的紫色条，这是两种不同的Rendering操作类型。我们在代码编辑器中编写的HTML代码，从服务器加载到浏览器并解析，呈现给最终用户时，需要经过如上图所示的几个步骤：执行HTML页面中的JavaScript代码，构建DOM树，将文本格式的CSS转换成浏览器可以理解的数据结构，计算元素样式，生成渲染树，遍历渲染树，计算渲染树中每个节点的大小和位置，创建列表进行绘制，最后进行绘制（Paint）和合成（Composite）。Web应用在使用过程中，由于用户与页面的交互，JavaScript代码的执行可能会导致页面元素的大小和位置发生变化，从而触发浏览器重新计算Layout，最终重新渲染页面。我们将这种行为称为浏览器回流，也就是我们在上面的Chrome开发者工具中观察到的警告信息：Forcedreflowisalikelyperformancebottleneck。回到我们的例子，回流操作影响的元素总数为10087，触发回流操作的代码：ResizeHandler-dbg.js。为什么文件ResizeHandler-dbg.js的第170行会触发浏览器回流？我们直接点击上图中的超链接，可以直接定位到第170行代码。首先，在Bar-dbg.js的onAfterRendering钩子函数（绿色）中，会调用_handleResize（黄色）检测当前是否应该抛出“resize”事件。这个检查最终被传递给ResizeHandler.checkSizes（橙色）进行处理。resize检测逻辑也很简单，比较DOM元素新旧宽高是否相同。如果不是，则触发resize事件，如下图红色矩形框内的代码所示。获取DOM元素新宽度的代码位于第170行。这行代码访问元素属性offsetWidth。根据该文档的记载，当JavaScript调用以下属性或方法时，会强制浏览器同步重新计算样式。布局操作被触发，即回流。https://gist.github.com/pauli...浏览器本身的机制没有问题，但是如果在某个时间点，大量页面元素的上述属性被访问，那就是很可能成为性能瓶颈。回到本文的例子，因为我在heavyFunction函数中插入了10000个div元素，resize检测时访问了这10000个元素的offsetWidth属性，导致浏览器reflow不断被触发，最终造成大量CPU时间花在渲染上。总而言之，本文描述的使用Chrome开发者工具分析Web应用程序性能问题的步骤只是如何使用该工具的冰山一角。如果以后有机会，Jerry会继续分享我在日常工作中学到的东西。SAPUI5应用遇到性能问题，首先要排查性能瓶颈是否是后台API造成的。对于SAPUI5应用的前端实现，由于UI5已经为应用开发者做了很好的封装，在大多数情况下，应用开发者不需要手动操作DOM元素和CSS样式，所以不太可能出现类似的情况到本文heavyFunction函数中模拟的cornercase。不管是不是，如果你怀疑你的SAPUI5应用的前端也可能存在性能问题，这时候你不需要胡乱猜测，只要尝试本文介绍的步骤你就知道了。谢谢阅读。Jerry的SAPUI5题目，在没有任何前端开发经验的情况下，创建了第一个SAPFioriElements应用来回答网友的问题：如何对使用SAPFioriTools创建的FioriElements应用进行二次开发？如何将本地开发的SAPFioriElements应用部署到ABAP服务器深入理解SAPFioriElements工作原理的前提：理解SmartField深入理解SAPFioriElements工作原理系列之二：如何添加自定义SAPFioriElements应用按钮SAPFioriElements框架中SmartTable控件的工作原理介绍SAPFioriElementsListReportSmartTable中计算列项宽度的奥秘作为ABAP资深顾问，SAP技术可以你选择作为下一步的主要进攻方向？SAPUI5应用开发者理解UI5框架代码含义SAPUI5模块懒加载机制SAPUI5控件渲染机制HTML原生事件VSSAPUI5语义事件元数据SAPUI5控件元数据实现实例数据修改和读取逻辑SAPUI5控件的实现原理SAPUI5控件数据绑定SAPUI5控件数据绑定的三种模式：OneWay、TwoWay和OneTime实现原理比较说说SAPUI5的视图控件ID，以及它与Angular视图的异同。对于了解不多的初学者，从什么资料开始学习比较好？SAPUI5OData辟谣者：极短时间内发送两个Odata请求，前一个会自动取消吗？SAPUI搜索和分页技术如何在SAPUI5应用中集成第三方库：一个在移动设备上查看web应用打印调试信息的小技巧基于OData模型和JSON模型的SAPUI5表单控制行项的增删纪念特洛伊的实现大侠Sinon-SAPUI5MockServer使用步骤及工作原理介绍本地修改远程SAPUI5框架文件的小技巧SAPUI5初学者详细教程-如何在SAPUI5中绘制图表更多Jerry原创文章在这里：《王子熙》：
