manualDispatch的使用问题 about android-startup HOT 5 CLOSED

补充：当前的时间统计是无法统计create到异步onDispatch这一段的，也就导致了问题难以排查。

from android-startup.

@opLW

1. manualDispatch = true，设计理念是针对任务内部做异步逻辑，例如网络请求(但本身create是在主线程执行)，这个时候当异步获取到结果时调用onDispatch，并不会出现mObservers 为空的情况。所以，如果在create中（严谨的说就是create线程）直接调用onDispatch本身就是一个错误的使用方式。针对这种情况，正确的使用方式是不设置manualDispatch = true，直接使用正常的逻辑就能满足。
2. A,B任务都在主线程执行，注意这里有两个核心概念。任务执行与任务等待是不同的层面，等待可以阻塞线程也可以不阻塞。例如任务在主线程执行，但它的等待并不需要阻塞主线程。所以针对这个问题，应该让B任务非阻塞等待A任务的通知（waitOnMainThread = false）
3. 针对异步时间统计，这里设计到一个时间概念问题，这个时间具体是什么？可以是create任务执行完的时间(当前create所处线程的耗时)；也可以是每个任务的内容自己的耗时（例如网络请求耗时)等等。Android Startup使用的是前者。当然角度不一样，结果自然也不一样。

from android-startup.

@idisfkj

1. 是的，从设计理念讲没错。但实际使用时，task内部需要根据条件选择同步还是异步，这种需求是存在的，如果使用者不看源码，可能就会犯错了。
2. 是的，你的做法可以解决这个问题。但是从使用者的角度出发，我觉得并不能马上了解到这个问题并作出跟你一样的解法。而且实际情况可能是任务B就是需要在主线程执行，即使任务B甚至后续的所有任务都在子线程执行，最后还有一个mAwaitCountDownLatch会阻塞主线程，所以主线程的阻塞在所难免。所以我偏向于manualDispatch = true是个潜在的风险，作为一个开源框架。
3. 是的，角度不同结果也会不同。manualDispatch = true的设计理念就是允许任务内部做异步逻辑，但问题是这个异步逻辑，本身就会对所有任务的执行总时长造成影响，如果这个异步时间不统计，那我觉得时间统计可能缺少一些准确性，不利于开发者发现问题。

from android-startup.

@opLW
手动通知的功能是不能取消的，这是一个非常常见的使用场景。
主线程的阻塞与否，根据任务来决定，更多的是由使用者自身控制。
同时避免使用困扰，已经提供了详细的代码示例与文档。

当然，一些可能存在混淆的概念，是有必须突出强调一下，后续可以完善一下

from android-startup.

也欢迎提交优质的PR

from android-startup.