一、背景
收到某医药项目反馈，伙伴基于YonBIP的YonBuilder产品开发的UDI扫码性能出现了问题，客户需要紧急发货，目前伙伴已经不知道如何下手排查该问题， 这个时候找到我们，让我们帮忙尽快定位问题，保障UDI产品顺利交付客户。
二、问题描述
伙伴开发的UDI应用带有扫码录入功能，采用的YonBuilder前端脚本开发实现，在扫码的时候需要处理数据，用户在使用的时候发现扫码越扫越慢，当UDI扫码数量达到600的时候已经需要2分钟才能录入一个，严重影响了客户的使用，按照目前的速度不能正常讲货物进行发送。
三、问题解决过程
我们第一时间打开伙伴的代码，和伙伴一起分析。部分片段如下：
经过初次查看，伙伴的代码在循环中使用了循环，并且循环中进行了UDI码判重，比如有一条UDI码已经扫过了，不能再次扫描，和记录到单据上。
这个过程会随着UDI扫码数量的增加，解决的方法其实也比较简单，使用set集合，将扫描好的UDI码放到set集合，然后下次扫描的时候判断set集合是否存在，这样性能就有所提高。
写了一个模拟扫码demo，然后模拟扫UDI码，然后继续进行，发现到了1000的时候还是慢，此时需要继续查看代码哪里出现了问题。
通过观察，发现了孙表还有排序功能，这个时候需要将排序功能关闭。性能又提升了一些。
udiAdminDjxxList.setState('multiSort', false); //关闭排序
继续测试，还有问题，那继续采用前端代码console.error输出判断代码出现的时间。
此时发现这段代码随着UDI码的增多，速度越来越慢。经过业务分析，这段代码用于记录行数，每次扫描后需要记录孙表共扫描了多少行。这个时候继续优化。
通过直接使用解析表直接获取行数，然后替换为循环获取孙表数，性能又近了一步。
我们的目标是扫描3000行UDI码的时候还能访问在1s之内，目前还没有达到目标。这行代码用于孙表中写入数据，该行代码2000行之后，每行100ms以上，还是不行。另外，孙表回填扫码数量的时候也出现了问题。
这块主要是前端的渲染，因为每次扫码需要耗时，所以采用定时器的方式继续优化，通过定时渲染前端，达到优化的能力。这样就基本上满足业务上的要求了。
使用定时器，在1秒内赋值及增行1次
var tempCount=0；// 全局变量
var tempList={}; //孙表临时数据记录
//定义一个每隔1秒循环执行的定时器
var timer = setInterval(timeCount, 1000);
//循环执行的代码
function timeCount() {
udiAdminDjxxList.setCellValue(chekcSpIndex, "ziduan2", tempCount, true); //更新子表
udiAdminDjxxJxmxList.insertRows(0,tbrsslist) //孙表增行
};
扫码执行
……
tempCount ++; //扫码增加
tempList.push(孙表数据) ; //记录孙表
……
四、问题持续优化思考
目前达到业务要求了，但是还有一些不满足的内容，即每次扫描之后没有存储起来，这块需要增加一个暂存能力，这样的话，客户即使扫描出现了问题，也不用重新开始扫描。
基本思路：扫描好之后需要记录到一个自己制作的表中，然后下次使用的时候从表中把记录获取到并展示和进行业务处理，这样就可以基本解决了客户扫描一半后数据丢失而苦恼的问题。
另外，这个过程基本是前端处理，还得需要一些后端的API去及时处理和响应数据,把大量的运算工作放到后端进行处理。前端基本上用于展示，不做大数据量处理。
性能优化是一个持续的过程，要不断的进行优化和思考，如何能更好的满足客户需求及性能要求，不断完善，打造一个极致的产品。
