都是无代码，smardaten凭啥快人一步？

你是不是也听说，无代码比低代码慢，比纯代码更慢？还有无代码用户反馈说，页面初始化加载要上十秒……我们今天就来把无代码性能那点事说明白，一起看看吧！无代码平台天生就有性能缺陷吗？很多人认为无代码天生就会慢，原因是无代码相比纯代码会进行多一层解析，而这个过程测算下来只有约1%的差距，几乎无感知。

换个角度来看，无代码有没有天生的性能优势呢？答案是肯定的。无代码平台在大量项目交付的过程中，统一封装大量组件供不同项目复用。我们将性能差的模块或组件重构，提升它的性能表现后，一次优化就可以修复多个项目上的性能问题。随着交付项目越来越多，无代码平台的性能获得持续提升，项目交付性能稳定、可预期、持续提升。这些组件对应的业务功能如果是传统代码方式开发，大概率是一个或多个通用代码模板ctrl c 、ctrl v，然后基于实际业务修修改改，甚至是从零开始写的。每一次新建或者修改都像掷骰子，如果开发人员是个高手，那么性能表现可能会好，如果开发是个低手，那么性能表现可能会差。都是无代码，smardaten凭啥快人一步？我们来看smardaten研发团队近期的一波优化操作，就能明白了。

react18架构升级1+1>21首先，react18本身新增了自动批处理、过渡更新、紧急更新、并发渲染等新特性，对于页面的构建、绘制、渲染、交互、更新、卸载性能显著提升。smardaten一方面将架构升级到react18，另一方面是我们还改掉了大量不合理代码，重写了大量方法引用，重新对接有更好性能表现的API，并抛弃了一部分已经过时的第三方库。如此一来，通过架构升级smardaten性能获得极大提升，也可以说是获得了1+1>2的效果。自研diff算法组件刷新次数降低95%2react的diff算法用于区分组件是否刷新。打个比方，我们比较两种食物，通常只比较哪个口味好，而之前的diff算法则是比较食物口味、颜色、重量、是否健康等等维度，而且要重复比较几百次才确定，这就是速度慢的原因。此次，我们给出了更专业的自研diff算法，就好比不仅单次比较提速，还大幅降低了比较次数，组件综合刷新次数降低约95%，极大提升了页面加载速度。查询引擎能力下沉充分利用软硬件算力3在分析仪模块，smardaten将数据检索能力下沉到数据层，启用数据库的查询能力，分散性能压力。这里等于是换了一个更合适的方案计算后台数据，效率更高，扩展性更强。精简启动项，渲染逻辑细分页面初始化减重提速4首先是精简启动项，增加懒加载模式。这个优化删除了大量冗余、无效的资源文件和引用关系，减少首次加载的资源文件数量，提升页面加载速度。类似于我们爬山少背点东西，爬的更快、更轻松。其次是，从业务逻辑出发，将分析仪、大屏、表单的查询接口拆分出独立的运行态接口。渲染逻辑细分，排除无效数据查询与返回时间损耗，接口响应速度自然就快了。 多级缓存，无感压缩挖掘每一种提升可能5这次优化我们增加了多级缓存，可以有效减少前后台请求次数。同时还增加了一个特性，就是这个页面跳走后，强制结束还没结束的后台请求，腾出资源给新的页面。在接口层面，smardaten进一步减少交互，提升性能，比如：①如果接口返回值较大，则启用压缩机制提升传输速度；②若查询类接口请求一致，则强制使用前端缓存数据……同一个大屏的分析仪数据查询请求，每5-6个合并为一个请求，后台通过多线程等技术提升查询效率，使数据查询获取速度提升了5-6倍。简化资产查询配置逻辑页面加载更快6原来逻辑控制配置资产查询时，一次只能查一个字段，如果要查多个字段，就要配多次。资产查询还是高频场景，之前的能力需要查询多次才能将本来查一次就够了的数据凑齐，浪费了大量时间。我们提供了新的配置方案，现在可以在一个资产查询节点查出所有需要的字段了。随之，接口查询数量减少，页面加载变快。smardaten典型场景性能实测实测 1复杂表单计算    200+组件，6个子表，24个逻辑控制入口。页面加载（最大内容绘制）3秒内，单任务执行时间小于0.5秒。

再来看CPU资源消耗情况，CPU利用率瞬间最高才30%，随后逐渐下降，趋于平稳。

实测 2复杂大屏    23个分析仪、43个工作区、1个画布列表、逻辑控制10+入口。页面完全加载（最大内容绘制）小于4秒，单任务执行时间小于0.5秒。

CPU利用率瞬间最高才40%，随后逐渐下降，趋于平稳。

性能问题上没有银弹其实，在性能问题上没有银弹，极致的性能通常意味着极高的成本。在商业上，大家更愿意寻求性能与成本的平衡，也就是性价比。传统代码项目的性能类似于木桶原理，取决于最短的那块木板。而无代码恰恰相反，随着各行各业项目的交付，无代码平台会经历持续不断的优化，性能水平取决于性能要求最高的行业应用，并且每一次优化都意味着所有项目的性能水平提高，无疑是性价比最高的选择。