最近学习了然后仿写了一个任务流来处理首次打开App启动问题，下面的介绍也基于启动App的情况下介绍的，写完发现才先起来早就有jetpack的WorkManager！！但是写都写了还是做个记录吧，就当学习WorkManager铺路
GIthub传送门
提前说明一下，阻塞Task是在主线程执行的，如果有阻塞任务没执行完，那么主线程是一直被阻塞中的，所以要尽快处理完阻塞任务
先看一下效果吧
先看一下任务流，就是start --> 阻塞任务 --> 异步任务 --> end
这里让我让阻塞任务执行一秒钟，异步任务执行两秒钟，start和end是自动添加上去的，里面没有执行任何东西
执行结果
这个demo的UML图，大概是这样，虽然我不会画，但是画给自己看也没什么关系对错
流程图
大概就是这样吧
代码重点
代码中比较重要的就是TaskRunTime，Task，Project
Task
Task.class中的变量
TaskRunTime
这是两个比较重要的List
我觉得里面最重要的就是这个方法，
executeTask 执行每个Task任务
1: 如果不是异步任务的话，是可以做延迟的，但是这里出现了一个问题,
比如：delayTask(2000) --> blockTask() 延迟任务后面有阻塞任务，这样有可能其他任务都执行完了，但是却不能释放Application，因为你还有延迟任务需要执行，就只能一直在等待着。影响启动速度
所以要判断后面有没有阻塞任务，有的话，这个延迟任务就不能再做延迟了
Project
注意，Project也是个Task，下面两张图是Project里面的Builder
红框是比较重要的地方,这里画图解释一下添加的流程，
先记住**behind**是添加到某个task的后面，
假设我们要添加如下图的链路，
第一步
这是刚开始加第一个task的情况，此时的变量状况是
mCurrentTaskShouldDependOnStartTask = true
mCurrentAddTask == null
那么在add方法中中，第一个if条件是不会执行的，因为mCurrentAddTask是null
接下来就对mCurrentAddTask赋值，此时的mCurrentAddTask == block1，并且接在end的前面，那么就是这样的情况
第二步
接下来来了第二个任务block2，他是依赖于block1的，此时的变量状况是
mCurrentTaskShouldDependOnStartTask = true
mCurrentAddTask == block1（记住这里是block1）
那么在add方法中中，第一个if条件开始执行，他将调用到behind连接到start的后面
注意在if语句过后，currentTask会被重新赋值，注意此时currentTask == block2
并且!!注意add方法中，是会把currentTask 接到end的前面的，所以执行完后应该会是这种关系
第三步
接着在dependOn方法中中，
此时的变量条件是
task == block1
mCurrentAddTask = block2
那么这个方法做的事情就是
这个就形成了一调完整的链路了
第四步
接下来就是build方法了
此时的变量条件是
mCurrentTaskShouldDependOnStartTask== false （在dependOn方法中改变）mCurrentAddTask = block2也没什么好说的，直接看能看明白
TaskFlowManager
假设任务链是这种情况，在阻塞任务block1执行完毕之后，会并发执行async1和async2，但是block2，block3又依赖前面的异步任务，这就有可能造成，提前释放掉了application，进入了LaunchActivity了
