ABAP程序效率优化系列文章历史
前几期的总结
之前几期分享的是，从业务层面到技术层面，在思维逻辑上需要解决的问题。
需要建立先是业务角度然后才是开发角度的思路，即便业务角度很多时候并没问题，但就算是走个过场，我也还是建议养成这样的习惯；
需要知道ABAP时间包含的内容及优化方法；
需要知道数据库时间优化的点；
需要知道ST05的应用方法及HINTS的使用建议。
但这些还不够。
如果一个程序优化到极致，仍然需要2分钟才能执行完(事实上还有很多很多需要执行时间更久的)，而用户只能眼睁睁盯着屏幕，等到结果出来的那一刻。
设想一下，如果我们登录一个网页，如果10秒钟网站打不开，而且不给我们任何反馈，我们都有关掉网页或刷新网页的冲动，我们需要网页的反馈。
而我们的用户也是一样的，他们也需要反馈。
用户体验
提升用户体验，也是程序设计应该遵循的一条原则。
为用户提供反馈信息的方式很简单啦，用函数SAPGUI_PROGRESS_INDICATOR设置进度条和消息文本即可，但有几个需要注意的地方是：
1、如果程序执行超过5分钟，我们让程序在5分钟内把进度从0%转到100%，合适吗？
2、在LOOP中，每一次循环时都调用这个函数设置进度提示，合适吗？
我的答案是，不是特别合适。
代码建议
对于第一个问题，我们可以把程序结构分成若干大的步骤，每个步骤都是0%-100%的进度过程。
比如一个报表执行时间较长，要取很多基础数据、成本数据、收入数据，然后进行数据处理，最后进行展示。那我们可以按代码块的不同功能，将其分成四步：
第一步，从若干表中取基础数据的信息，提示：“第一步：正在获取基础数据信息之AAA/BBB/CCC……”，进度从0%-100%
第二步，取若干类型的成本数据，提示：“第二步：正在获取AAA/BBB/CCC类型成本……”，进度从0%-100%
第三步，类似
第四步，在循环中对处理进度进行提示：“第四步：正在处理数据项A/B/C……”,进度从0%-100%
(最后展示的时间可以忽略不计)
(以上只是个示例，对于不同的报表，我们可以划分为不同的功能块)
对于第二个问题，如果LOOP的内表很大，就要调用很多次函数，一方面用户会看不清提示信息，另一方面会带来不必要的时间消耗。
对此，我们可以做如下方式的处理：
DATA: l_percent type i, "计算百分比
l_cur_percent type i, "当前百分比
l_lines type i.
l_lines = lines( lt_tab ).
loop at lt_tab into ls_tab.
l_percent = sy-tabix / l_lines.
if l_cur_percent <> l_percent.
l_cur_percent = l_percent.
"用l_cur_percent设置进度提示
endif.
endloop.
这样，在一个循环中，函数最多也就只会调用100次了。虽然会进行大量的百分比运算和比较，但这些时间是完全可以忽略的。
潜在问题
对循环中的进度提示，提示信息可能与实际处理状态不符。
比如，LT_TAB中有编号10000-20000的一万条数据，我们在提示状态中只能提示100次，也就是说提示信息中只能出现100条数据，剩余的19900条数据都不会显示在提示信息中。
但是这没有什么关系，我们的目的是给用户提供一个反馈信息。用户在这时候也并不能干预程序的执行，他需要的是收到程序的反馈，需要对程序的执行结束有个预期。
(很多标准报表也是这么处理的)
最后
用户很多时候可以接受程序慢一些，但更讨厌没有信息反馈。
所以，我们要做一个有操守的程序猿。
我们应该尊重自己的代码，在必要的时候，用“信息提示”把她打扮的美美的，为用户提供更好的使用体验。
IOS/ANDROID用户打赏——赞赏码
