lizuncong

> 干得漂亮，后面安排推荐。 招人吗老板

> 目前React关于Scheduler设计存在两个队列：保存未就绪任务timerQueue和保存已就绪任务taskQueue，每次调度时会判断未就绪任务是否已就绪，是加入到taskQueue。但是从过期时间的角度来看，貌似这种设计有点冗余，如果把延迟的任务也转换为过期时间，然后放在统一的任务队列（假设是taskQueue），统一走最小堆的维护和取值策略，那是不是也能满足需求，并且逻辑上也更简单点 是需要两个队列的，假如没有调度普通的任务(存放在taskQueue中的任务)，只调度了延迟任务，这时候是需要为延迟任务启动一个定时器的，而普通任务不需要，因此不能简单的将延迟任务转换为过期时间添加到普通任务队列（taskQueue）中的

这个问题是因为你把背景色设置在TouchableOpacity上面了，并不是性能的问题

请问你还保留着添加创建活动之前的代码吗

First of all thank you for your reply. I try to call the callback 10,000 times, and the result is that the official tapable synchook execution time is still dozens...

@sokra I just called the tap 10,000 times，and found that the official tapable sync hook took almost 60ms, while my synchook took 0.8ms.

@sokra This time I call the tap 1000 times and call the `call` 10,000 times，the result as the image shows `const { SyncHook } = require('tapable') class MySyncHook{ constructor(argNames){ this.argNames...

@sokra I think it should be the new version of nodejs that has been optimized, and the performance is better than the function body dynamically generated by new Function.

I just tried it. When the number of calls is more than 17000 times, the efficiency of tapable does to be faster ! But in what scenarios will the `call`...

`const { SyncHook } = require('tapable') const CALL_DELEGATE = function(...args){ this.call = this._createCall(); // The function is dynamically generated when it is called for the first time return this.call(...args) }...