分发器就是由OKHTTP封装的Dispatcher类（可自定义）；
为什么会使用分发器：
我们在使用OKHTTP网络工具类，一定不会只请求一次网络数据，而是同时或紧凑的请求，但是如此的频繁或大量的请求数据很可能会造成频繁的创建和销毁线程从而降低了程序的性能和效率，此时就出现了分发器通过线程池来管理并控制网络请求实现了无等待，高并发；
分发器的好处是什么：
分发器控制了网络请求并发请求的数量，有效的避免了网络拥堵提高了程序的稳定性和性能，通过线程池管理和复用线程，解决了请求顺序可以通过选择先进先出或优先级的方法来进行请求数据，并且可以随时中断正在进行的请求，避免了卡顿死锁和ANR；
分发器的运行流程：
当我们在外部请求网络数据后，一般会使用异步来进行操作，首先会将要执行的任务通过execute方法加入到ThreadPoolExecutor线程池，去判断线程的数量是不是小于corePooSize（默认定义的是64可以自定义）&&同个域名的请求最大数不大于5个(可定义)，条件满足就会走到runningAsyncCalls方法新建核心线程来处理被添加的任务，反之执行readyAsyncCalls方法将任务加入到队列等待，如果添加成功会在队列内等待，添加失败的话如果线程数量小于maximumPoolSize最大线程数，就会新建线程执行新任务，线程数量小于maximumPoolSize，使用拒绝策略RejectedExecutionHandler（抛出异常），在线程池中作者采用了SynchronousQueue而不是ArrayBlockingQueue和LinkedBlockingQueue，原因也很简单，使用ArrayBlockingQueue会因为他的数据结构的原因导致如果第一个任务耗时过长，第二个任务就会进入队列等待，而第三个任务又因为队列已经有正在等待的任务从而去看有没有超出最大线程数，如果没超出才会开启新的线程去执行这个任务，第三个任务执行完成之后第二个正在等待的任务才会收到通知开始执行，因此就导致了任务顺序变成了任务一先执行任务二等待任务三又因为任务二占用了队列且没有到达最大线程数创建新的线程执行任务三结束后才通知任务二开始执行，任务从此就变的混乱，这非常不符合我们的开发逻辑，而LinkedBlockingQueue又和ArrayBlockingQueue类似，所以作者就不会采用他们，这时候我们看SynchronousQueue，我们向队列添加数据一定就会失败，从而去创建新的线程去跑这个任务，因为这个队列他没有容量，也就不需要去等待，从而实现了最大化并发，这非常符合OKHTTO的场景