1. 概述
大数据量模板优化方法请参见:
2. 具体解决方案
注:模板检测助手 可以发现可能导致模板性能出现问题的地方,提醒给用户并提供建议修改方案。
问题痛点 | 应用场景 | 解决方案 | 备注 |
---|---|---|---|
减少格子数及格子数相同下的优化 | 行列调优 | 列转行 | 1)产品逻辑:格子数相同情况下,列越多,计算越慢 2)大数据情况下一个 sheet 100 行,比两个 sheet 每个 50 行要慢 3)列转行更多的是提供一种减少方向,尽可能减少列多的用法,运用到实际场景中可能有:减少交叉模板使用,专注使用行式明细模板 |
减少行列、格子数 | 1)通过取数限制减少行,如mysql 中 limit 100(如果有求和且需要保持全量可以用sql函数) 2)减少展示的列数 | 特例:遇到纵向列为id,横向行为时间的设计,数据源本来就1W行,最终格子数确是 1W(列数)*40(日期数),其中格子实际使用数不到3%,大片都是空白格 | |
格子内计算-公式 | 存在层次坐标、sql类函数 | 减少层次坐标、SQL 类函数(sql,value,map、select)在扩展行的使用 | SQL 类函数在即时取数时每一个行都会独立执行一遍sql、填报校验时同理 |
模板存在大量被公式调用的图片 | 1)安装 外置图片插件 、把内置图片都改为外置图片 2)单元格把数据转图片的方法的优先使用顺序:html>webimage>toimage>单元格图片 | - | |
格子内计算-控件 | 控件数量、使用可以简化的场景 | 减少控件使用,如纯导入模板,不配置控件 | 经测试发现,导入一个 200 行 10 列的 Excel,增加控件的模板需要 100 秒左右才可以完成页面加载,去掉控件的模板只需要 10 秒左右 |
控件数据字典优化 | 控件数据字典尽量用数据集并开启缓存,尽可能不要直接用数据查询 | - | |
控件默认值优化 | 1)简化或者去掉控件默认值 2)控件默认值,工具栏,加载事件中尽量不要用单元格如=A1 3)下拉树控件设置全选或联动时、不用sql函数,把sql函数的语句放在数据集里面,然后默认值里把sql函数的部分换成value | 控件里的参数默认值也是在初始化时计算的,不是在点击的时候才计算,如果按钮控件里大量调用sql函数,并且计算时间较久,也会对模板加载时间产生影响 参数面板控件默认值同样引发性能问题 | |
客户允许不开启直接显示控件 | 不开启直接显示控件 | 当一个页面的控件数量超过 100 个,就会拖慢页面展现速度,超过 500 就很容易造成超时 | |
格子内计算-控件相关 | js计算按钮控件里的参数默认值过久 | 修改js | 按钮控件控件里的参数默认值也是在初始化时计算的,不是在点击的时候才计算,如果按钮控件里大量调用sql函数,并且计算时间较久,也会对模板加载时间产生影响 |
条件属性中使用sql函数做控件联动 | 不要在条件中使用sql函数写sql语句,优化下sql的取数时间或者换用其他方式实现 | - | |
新计算引擎下拉树加载慢 | 数据量不多的情况下,可以换成多个控件联动实现需求 | - | |
下拉框控件联动 | 勾选允许控件直接编辑和允许自定义值 | 不勾选的话会读控件默认值,如果客户的控件默认值是写的数据集里的字段,且这个数据集也是有参数的,就会导致sql一直重读 | |
格子内计算-父子格 | 笛卡尔积 | 防止填报笛卡尔积 | 提交入库时如果重复提交了很多数据(不只重复一次),很可能是单元格的父子格设置导致成为笛卡尔积的形式提交了,所以需要检查父子格设置 |
模板扩展行支持使用统一左父格 | 所有格子尽量使用同一个父格、而不是依次继承 | - | |
过滤配置推荐 | 同一行不同格子设置过滤的时候,尽量只对第一个格子设置过滤 | - | |
列表、分组的选择 | 大数据量的明细模板,列表展示比分组快 | - | |
格子内计算-其他 | 条件属性实现隐藏行列、行变色 | 1)使用条件属性的时候,如果对单个单元格设置条件属性就能满足需求的情况下,就只对一个格子设置条件属性,不要对每个格子设置,例如隔行显示背景色,配合为整行生效。 2)如果可以直接隐藏行列,则不用条件属性隐藏 | - |