一周前，在给高帅富新浪网的 flame 递交了两个 PR 后，我将它PCB成了罐子，用作记事本和新浪网应用领域的管理工作。
但在北迁对个人记事本的操作过程中，我察觉到 flame 在操控性上的整体表现并并非不光好，只好我做了两个改良版：flare。
写在后面
在聊 flare 以后，我想先谈谈 flame。
flame 是两个高帅富新浪网的网址工程项目，你能将你常见的记事本和新浪网应用领域储存在它下面。它由两个立陶宛老赵建立，工程项目门牌号是
在试玩后，我真的工程项目还极好，只好稍加修正，PCB了两个捷伊快照：
在工程项目文件格式中，历史记录了我的修正：
精简流程功单纯的常姓。但随著深入细致采用，我辨认出页面有著较为大的操控性难题。
即使立陶宛老赵选用了 SPA 计划，工程项目内又包涵了 6700 数个 SVG 工具栏、和若干个页面手写体，因此在USB上有许多小难题，引致了页面表面积十分大，USB允诺数目也十分多。
甚至当你上传许多包涵元素较为多的 SVG 作为你记事本工具栏的时候，由 React 触发的页面渲染会造成浏览器卡死。
我大概有几百个记事本需要处理，预估未来记事本数目还会增长，所以我采用流程批量建立了接近一千个记事本。然后我辨认出渲染如此多的记事本，页面会出现卡顿，甚至在页面内搜索包涵关键词的记事本也会感受到明显的掉帧。
所以，我决定重新写两个轻量许多的流程，来解决我的需求。捷伊工程项目门牌号在这里，如果你好奇的话，能试试看：
制做 flare 的操作过程，其实也是 flame 操控性调优的操作过程。不过在解决难题以后，我们首先得能定位难题有哪些。
应用领域操控性难题分析
关于这个应用领域的操控性强化，其实并不复杂，和传统应用领域强化差别不大：优先减少计算量，在实在减少不了的情况下采用计算效率更高的方式来解决难题。
不过结合采用场景来说，在分析技术难题以后，能先从功能入手。
对于我不适用的功能
首先从功能上看，我不需要这个应用领域与 Docker 集成，提供“服务辨认出”功能。比如在我启动罐子后，这个应用领域会自动将新启动的罐子作为记事本或者应用领域进行添加。
其次，在拥有自己的 SSO 服务后，我也不再需要采用单纯的账号密码登录之类的功能，所以这个功能也能去掉。
最后，关于记事本数据的储存，我真的在缺少用户体验十分棒的 Web 编辑器的前提下，可能不如配置声明的方式更易于管理工作和维护。（你能采用任何你喜欢的编辑器来更新和维护内容，你能采用 Git 或者任何你喜欢的方式，以白盒形式保存你自己的数据）。
基于下面的变化，我大概能少写两个部分的代码：罐子（Docker & K8S）集成、登录鉴权、应用领域和记事本，和记事本分类的 “CRUD”。
前端架构中的难题
Flame 工程项目中，作者采用都是 create-react-app 脚手架建立的工程项目，工程项目依赖为： React v17 + TypeScript + Redux，为了提供简洁一致的工具栏，作者在前端引入了Templarian/MaterialDesign-JS，两个被精心处理过的 DOM 结构十分单纯的 SVG 工具栏库。
在采用构建工具打包、服务端 GZip 压缩后，需要传输接近 1MB 的资源，原始脚本流程表面积接近 3MB。相对膨大的流程表面积引致了页面加载和执行时间都会较为长。比如页面页面首次渲染时间在 1s 上下浮动，多数情况下会超过 1s，完成时间一般都在 1.5s 以上。可能是作者对于服务端流程开发不够熟悉，虽然在前端进行应用领域配置更新时会复用USB，但在内容页面展示时，会调用多达8个USB。此外，为了在页面中展示和更新天气信息，立陶宛老赵还采用了 WebSocket 来进行数据交互。
其他的难题，在文章后面已经提到过了，就不赘述了。
后端架构中的难题
工程项目采用的技术栈为 Node.js，Web 框架为市占率十分高的 Express 的最新版本，ORM 框架选择的则是 Sequelize，数据储存落地为 SQLite3 。下面的选择粗看难题不大，如果应用领域不需要公开提供浏览访问，应该不会出现任何操控性难题。
但，如果我们仔细观察服务响应，会辨认出有许多允诺的响应的时间十分长，比如页面资源、比
能瓶颈。
针对应用领域进行改进
当我们清楚了解到下面的难题后，比如容易采取的计划是：基于原流程进行重构修正，精简前端允诺、合理拆分模块、处理资源加载和执行时机，修正数据储存和处理方式，提高服务端响应能力等组合拳。然而，这会是最单纯和收益最高的计划嘛？
修正前端实现
如果说在需要交互的页面流程中采用 MVVM 框架会有较高的收益和性价比，那么在缺少多端组件代码复用、没有服务端渲染需求的场景下，采用这类框架则是两个性价比不高的选择。
或许有同学会问，如果不采用 React、Vue、Angular 这类框架，难道在 2022 年还要再拾起 jQuery 等老的工具吗？虽然能，但其实在近乎于纯展示的场景下，我们
所以，在修正实现的时候，其实还有两个选择：不采用任何脚本。
成页面渲染的时间更是缩短到了 1.65ms。
在得到了页面快速渲染能力后，即使不采用浏览器针对资源进行缓存，加速渲染，我们也能够做到页面切换的“无刷新”浏览（即使渲染速度足够快）。
修正后端实现
虽然我非常喜欢采用 Node.js，以往也分享过不少基于 Node.js编写的流程或者强化实践，但，为了能够低成本提高高操控性的资源响应，这里进行技术栈切换是必要的：比如 Golang。
在采用 Golang 精简流程功能后，流程对于每个允诺的响应基本能够保持在几毫秒的水平（受限于网络传输），相较为以后大概下降了2～3个量级。页面关键的 DOM ContentLoad 时间更是缩短到原来的八分之一。
结合下面的前端强化提到的渲染时间来粗略估计，从资源下载到渲染加起来都不到 10ms，如果并非浏览器的许多限制，绘制帧率应该能够远超 60 帧，进一步满足我们实现“即使刷新了也比没许多没刷捷伊实现还顺滑”。
下面的实现中，我将页面工具栏允诺和页面文件格式进行了拆分，在记事本数目和工具栏种类不多的场景下，或许并并非最优的计划，但一旦记事本数目级到几百、上千后，你会辨认出工具栏拆分能极大地提升操控性。
工具栏资源强化
Flame 采用的计划是读取后端USB配置，从前端脚本中动态建立 SVG 工具栏并插入文件格式中，Flare 流程预设的方式则是将 SVG 和文件格式拆分，以应对大量记事本状况下的页面性能难题。
虽然解决了页面操控性难题，但服务端 IO 难题却会伴随而来，所以这里还需要处理资源在服务端的释放和读取难题，尽量将资源的磁盘 IO 变为零。
听起来较为玄乎，但其实结合代码生成的方式，还是蛮好实现的。当然，即使 Go 存在自动 GC，所以在不同的资源被采用的时候，会出现大量内存的分配，影响效率，这里能考虑采用持久化计划来解决难题，处理起来挺有意思的，受限于篇幅和主题就不展开啦。有一部分我在前两篇文章中提到了，关于 Golang 嵌入资源的采用和强化。
比如，在不针对 HTTP 服务实现做任何强化、限制运行资源为两核心的前提下，仅强化资源 IO 后，能达到稳定 3ms 输出资源，每秒提供2万7千次以上的响应服务。
罐子快照的强化
除了常规强化之外，罐子时代的应用领域，快照强化也是十分关键的。罐子强化方式，我在后面的文章反复提过多次，所以也不再展开了，感兴趣可以自行翻阅以后的内容。
能看到，相较为原版流程，强化后的流程在本地解压后的尺寸大概是以后十五到十六分之一。
额外的强化
如果我们采用 lighthouse 针对 Flame 前端实现进行测试，能够看到前端流程在实现上的许多小难题，得分虽然四个环绿三个，但只有两个环是绿色的。
在重新实现的操作过程中，除了精简结构，调试实现之外，还顺手将这四个圈都打到了满分（Chrome 版本 v97+）。
最后
聊到这里，相信你已经了解了我是怎么做的啦，如果你对 Flare 感兴趣，因此也需要两个单纯的导航流程，能访问工程项目https://github.com/soulteary/docker-flare，来亲自上手试试。
–EOF
我们有两个小小的折腾群，里面聚集了几百位喜欢折腾的小伙伴。
在不发广告的情况下，我们在里面会一起谈谈软硬件、HomeLab、编程上的许多难题，也会在群里不定期的分享许多技术沙龙的资料。
，否则不会通过审核）
如果你真的内容还算实用，欢迎点赞分享给你的朋友，在此谢过。
如果你想更快的看到后续内容的更新，请戳“点赞”、“分享”、“喜欢”，这些免费的鼓励将会影响后续有关内容的更新速度。
本文作者: 苏洋
建立时间: 2022年01月19日 统计字数: 5054字 阅读时间: 11分钟阅读 本文链接:https://soulteary.com/2022/01/19/flare-production-record-application-frontend-and-backend-performance-optimization.html
