关于sap:使用工具分析-SAP-UI5-应用前端执行的性能问题

0次阅读

共计 4089 个字符，预计需要花费 11 分钟才能阅读完成。

这是 Jerry 2021 年的第 66 篇文章，也是汪子熙公众号总共第 343 篇原创文章。

国庆黄金周开始的前一天，9 月 30 日，我所在的开发团队收到了一个对于 Angular 利用的服务器端渲染(Server Side Render，简称为 SSR）的客户 incident，让我有机会学习如何应用 Chrome 开发者工具来剖析 Web 利用的性能问题。

Jerry 之前已经写过一篇对于 Chrome 开发者工具的文章：Jerry 和您聊聊 Chrome 开发者工具，本文算是该文的后续。

原本我是想用 Angular 利用为例来介绍工具的用法，但思考到本公众号一万多读者外面，绝大多数前端开发敌人们，应用的还是 SAP UI5，因而最初还是抉择了基于 SAP UI5 利用来介绍应用 Chrome Dev Tools 进行 Web 利用性能剖析的应用步骤。

本文提及的 SAP UI5 利用，指通过 FreeStyle 形式开发的 SAP UI5 利用。通过 Fiori Elements 开发的 SAP UI5，不在本文探讨之列。

依据我以往的工作教训，如果一个 SAP UI5 利用呈现了性能问题，很多时候性能瓶颈都出在该利用生产的后盾 API，比方 OData 服务或者其余 AJAX 调用。

同 Angular 相比，SAP UI5 框架为利用开发人员屏蔽了 Web 前端开发中的很多底层细节，比方 DOM 操作，CSS 的编辑，数据双向绑定和事件注册等逻辑，均应用 UI5 封装之后的形式来实现。因而一个 SAP UI5 利用，纯正的前端代码里，因为利用人员编码失误导致性能问题的概率绝对 Angular 要低得多。

因而，为了演示 Chrome 开发者工具进行 SAP UI5 性能剖析的应用办法，我在本人的 SAP UI5 脚手架利用里，成心编写了一些会引起性能问题的前端代码，而后通过 Chrome 开发者工具，把这些导致性能问题的代码进行定位。

我这个 SAP UI5 脚手架利用能够通过如下 url 拜访：

https://wangzixi-diablo.githu…

这个 UI5 利用的视图我采取 JavaScript 视图类型实现，在视图实现文件 App.view.js 的 createContent 办法里，我调用了一个函数 heavyFunction，该函数在一个 for 循环里创立了一万个 div 标签，增加到 DOM 树中，而后插入一亿个元素到数组中。

我冀望的后果是，可能应用 Chrome 开发者工具，对该 SAP UI5 利用进行性能剖析，通过工具的帮忙，将性能问题疾速定位到这个 heavyFunction 函数。

其实应用 Chrome 开发者工具的 Performance 面板对 Web 利用进行性能剖析，应用形式和 SAP ABAP 数据库性能剖析工具 ST05 十分相似，即开启跟踪模式，在该模式下运行数据库事务(Web 利用)，而后敞开跟踪模式，而后剖析 ST05 (Chrome 开发者工具) 输入的跟踪后果。

首先关上一个 Chrome 隐身窗口，这是为了排除 Chrome 装置的其余扩大对性能剖析可能造成的影响。

关上 Chrome 开发者工具，抉择 Performance 标签页，关上设置选项，Network 抉择成 Slow 3G，CPU 抉择成六倍速升高：6x slowdown.

而后点击 Record 图标，开启性能跟踪模式：

刷新利用，使其在性能跟踪模式下运行：

期待页面显示结束后，点击 Stop 按钮，敞开跟踪模式。
而后咱们就能看到下图所示的跟踪后果：

大家请看下图代表 CPU 执行流动的这根条状图，其中在两个工夫点之内，有大量密集的脚本执行 (scripting) 和渲染 (rendering) 的流动记录。

咱们首先详细分析，为什么会有如此密集的 scripting 操作。挪动下图所示的两根滑动条，放大咱们排查问题的工夫戳范畴(range).

工夫戳范畴越小，显示的明细越具体。大家留神到上图我用红色矩形框高亮的 Main 下拉框了吗？该下拉框之下，显示的就是在指定的左右工夫戳范畴内，Main 即主线程执行的 CPU 流动明细。

咱们把 Main 下拉框显示的内容拖至底部，一下子就发现了咱们成心编写的 heavyFunction 赫然在列，在咱们指定的工夫戳范畴内，总共破费了 6.799 秒的工夫去执行。

点击 App.view.js 的超链接，还能间接跳转到对应的代码去：

上面咱们再调整左右工夫戳滑动条，来钻研 Rendering，即下图紫色条代表的流动。咱们察看到，每一根紫色条，右上角都有一个红色三角形图标。鼠标放上去，tooltip 会显示：Forced reflow is a likely performance bottleneck.

意思是，强制回流是利用一个可能的性能瓶颈。

上图咱们能察看到 Recalculate Style 和 Layout 紫色条，别离是 Rendering 的两种不同的操作类型。

咱们在代码编辑器里编写的 HTML 代码，在从服务器端被加载到浏览器并被解析，到出现在最终用户眼前，需经验上图所示的几个步骤：执行 HTML 页面里的 JavaScript 代码，构建 DOM 树，将文本格式的 CSS，转换成浏览器能够了解的数据结构，计算元素款式，生成渲染树，遍历渲染树，计算渲染树中每一个节点的大小和地位，创立待绘制列表，最终进行绘制 (Paint) 和合成(Composite).

而 Web 利用在应用过程中，因为用户与页面交互，导致 JavaScript 代码执行，可能会使得页面元素的大小及地位等属性产生扭转，从而触发浏览器从新计算布局，最终从新渲染页面。咱们称浏览器这种行为叫做回流(reflow)，即咱们在上图 Chrome 开发者工具里观测到的正告信息：

Forced reflow is a likely performance bottleneck.

回到咱们的例子，受到回流操作影响的元素总数为 10087，触发回流操作的代码：ResizeHandler-dbg.js.

为什么文件 ResizeHandler-dbg.js 的第 170 行会触发浏览器回流呢？咱们间接单击上图的超链接，能够间接定位到第 170 行代码。

首先，在 Bar-dbg.js 的 onAfterRendering 钩子函数 (绿色) 里，会调用 _handleResize(黄色), 检测以后是否应该抛出 “resize” 事件。这个检测最终被投递交给 ResizeHandler.checkSizes(橙色)进行解决。

Resize 检测逻辑也很简略，比拟 DOM 元素新旧 width 和 height 是否雷同。若不雷同，则如下图红色矩形框内代码所示，触发 resize 事件。

获取 DOM 元素新的宽度的代码正好位于 170 行，这行代码拜访了元素属性 offsetWidth.

依照这篇文档的记录，下列属性或办法被 JavaScript 调用时，会迫使浏览器以同步的形式从新计算款式，触发布局操作即回流。

https://gist.github.com/pauli…

浏览器这一机制自身没有什么问题，然而如果某个工夫点，有大量的页面元素的上述属性被拜访时，则很可能成为性能瓶颈。

回到本文的例子，因为我在 heavyFunction 函数里插入了一万个 div 元素，在 resize 检测时，这一万个元素的 offsetWidth 属性被拜访，造成了浏览器回流的一直触发，最终导致了大量的 CPU 工夫被破费在了 rendering 之上。

总结

本文介绍的应用 Chrome 开发者工具来剖析 Web 利用性能问题的步骤，只是该工具应用技巧的冰山一角。后续有机会，Jerry 会持续把我在日常工作中学到的货色分享进去。

如果遇到 SAP UI5 利用呈现性能问题，优先排查性能瓶颈是否由后盾 API 造成。对于 SAP UI5 利用的前端实现来说，因为 UI5 曾经为利用开发人员做出了良好的封装，因而绝大部分情景，利用开发人员无需手动操纵 DOM 元素和 CSS 款式，所以也不大可能呈现相似本文 heavyFunction 函数里模仿的极其状况。

无论如果，如果你狐疑你的 SAP UI5 利用的前端也可能有性能问题，此时无需胡乱猜想，用本文介绍的步骤一试便知分晓。

感激浏览。

Jerry 的 SAP UI5 专题