【日常分享】纯异步填表思路
我知道大部分人填表都是采用同步方式，如下图，一条流水线式的操作这样做简单，思路也很清新，但是用多了你就会发现大部分时间你都在等待，效率不高，而且如果网页发生错误，你需要大量的返回重试或者重新等待，而且部分人用等待超时来判断失败，也并不高效，而且一旦没控制好（比如说：虽然超时但还未真正失败，又手动释放了，虽然这个目前本框架专门进行过处理，但依然不建议），还有崩溃的风险；
所以为什么我们不能换一条思路来考虑了？为什么非得放到一条流水线上了？？？？那我们用异步的思维将每个处理看做一条流水线，每个处理的异步事件看做是流水线之前的桥梁，如果这样来思考，又该如何来操作了？
异步流程大概思路图如下：
该图有些步骤没画出来，其实异步的主要思路就是不要等待直接在异步事件中操作，即使异步事件中又有异步操作，也无需取等待获取，而是再跳到另一个异步事件取处理；我估计这么说和上面简图还是有人会看不懂；所以下面还是按代码讲解，这里主要用火山代码，因为火山采用动态事件，更方便处理；
1.创建浏览器
这里的创建浏览的部分代码，我这里只做了创建，虽然后面也有个同步类的等待，实际我这里是等待的最终结果，并没有做进一步操作，进一步操作是在浏览器的事件里面；
2.异步事件中进一步处理
在“载入结束”事件中，其实因为浏览器存在多框架多资源，所以这个事件可能会被多次调用，就有可能这个事件创建了，但我们需要的元素并没有创建，有的同学采用同步创建浏览器的方式在这里去停止同步等待再反馈浏览器其实并不完美；
如上这里有两个判断，第一个其实就是在判断登录框元素有没有存在，而第二个其实已经是另一个流程，是在已经登录填表后取判断某个元素而确认是否登录成功；
如果我们正好当前资源创建完毕了，元素就存在了，执行判断就会一次命中；但因为回调是异步，你如果直接在事件中等待取判读，就会卡事件照成异常（手册多事件篇有描述原因）；
因此这里的代码直接操作，而是再对应的回调中取执行；
回调中代码如下，通过上面判断元素是否存在执行后，是不是存在都会返回给对应的回调，如下：
在代码第一个判断中，只要元素存在，就执行调表操作，然后点击按钮登录跳转；如果不存在就等待下一次回调，跳转登录成功后，就又会回到“载入结束”事件中去判断登录后会存在的元素，然后又会执行回调(其实这里已经是一个新类回调虽然代码还是一样,你也可以自己写成两个执行类)，去执行执行类型为1的相关代码；
这里我再通过一个任务投递到UI线程取执行登录成功后的事，这里采用异步也是为了防止卡执行事件回调；
其实最终停止等待输出数据，也是通过浏览器事件执行操作资源过后会跳转到某资源去取返回数据后标识当前浏览器操作完成停止等待，如下代码
所以上面的整体流程涉及的事件，都是异步处理，而不是先创建等待然后在事件或者回调中去结束等待返回后再处理，虽然最终执行完后才结束等待反馈执行结果，但整个流程并不是一条线流水线，等一下执行一下，等一下再执行一下，所以整体效率将会高很多；
该帖子的描述代码，因为一些特殊性暂不放出来，只要能理解异步的思路，开拓一下大家的想法，不一定要用这个代码，这代码也不一定所有网站都适用；
{:6_448:}{:6_448:}{:6_448:}{:6_448:}{:6_448:}{:6_448:} 666666666666666666666666666666 膜拜大神 感谢分享，很给力 {:6_479:}{:6_479:}{:6_479:}{:6_479:}{:6_479:} {:6_448:}{:6_448:}{:6_448:}{:6_448:}{:6_448:}{:6_448:} 来看看，支持下 666666666666666666666666666666 感谢分享，很给力 {:6_448:}{:6_448:}{:6_448:}{:6_448:}{:6_448:}{:6_448:}
页:
[1]
2