search

DSAppTeam / Anchors

:white_check_mark: Anchors 是一个基于图结构，支持同异步依赖任务初始化 Android 启动框架。其锚点提供 "勾住" 依赖的功能，能灵活解决初始化过程中复杂的同步问题。参考 alpha 并改进其部分细节, 更贴合 Android 启动的场景, 同时支持优化依赖初始化流程, 自动选择较优的路径进行初始化。
Apache License 2.0
817 stars 79 forks source link

缺少任务暂停机制支持 #7

Closed lispking closed 4 years ago

lispking commented 4 years ago

看代码实现 ，貌似没办法支持任务暂停机制，实际上，有一些场景需要弹窗，等用户确认后才继续往后运行，取消后中断后续任务或继续运行。

YummyLau commented 4 years ago

初始化的场景比较复杂，而且还需要考虑多个同异步混合链。初始化需要在应用应用启动的时候尽可能快才是合理的。需要用户等待确认的场景一般是用于业务逻辑，如果真的你可以在业务场景中把你需要暂停的场景，建议把依赖链拆成两块，但这不是该库设计的初衷。

lispking commented 4 years ago

初始化的场景比较复杂，而且还需要考虑多个同异步混合链。初始化需要在应用应用启动的时候尽可能快才是合理的。需要用户等待确认的场景一般是用于业务逻辑，如果真的你可以在业务场景中把你需要暂停的场景，建议把依赖链拆成两块，但这不是该库设计的初衷。

拆成两块存在一些问题，用户需要在异步回调后手动调用恢复任务函数让任务继续往下运行，如果用户忘记调用该函数，会导致后续任务链陷入假死状态。

YummyLau commented 4 years ago

初始化的场景比较复杂，而且还需要考虑多个同异步混合链。初始化需要在应用应用启动的时候尽可能快才是合理的。需要用户等待确认的场景一般是用于业务逻辑，如果真的你可以在业务场景中把你需要暂停的场景，建议把依赖链拆成两块，但这不是该库设计的初衷。

拆成两块存在一些问题，用户需要在异步回调后手动调用恢复任务函数让任务继续往下运行，如果用户忘记调用该函数，会导致后续任务链陷入假死状态。

不过依然建议的是：这种业务场景不太符合设计初衷哦。实际上不拆除也有一些方法可以做。你可以把弹窗当作某个任务中的某部分内容，只有当确认的或者取消的时候，任务才可能继续完成执行这部分内容。如果该任务在子线程，用循环卡住，如果任务在主线程，用sleep+轮训处理。 你可以参考下处理。

lispking commented 4 years ago

初始化的场景比较复杂，而且还需要考虑多个同异步混合链。初始化需要在应用应用启动的时候尽可能快才是合理的。需要用户等待确认的场景一般是用于业务逻辑，如果真的你可以在业务场景中把你需要暂停的场景，建议把依赖链拆成两块，但这不是该库设计的初衷。

拆成两块存在一些问题，用户需要在异步回调后手动调用恢复任务函数让任务继续往下运行，如果用户忘记调用该函数，会导致后续任务链陷入假死状态。

不过依然建议的是：这种业务场景不太符合设计初衷哦。实际上不拆除也有一些方法可以做。你可以把弹窗当作某个任务中的某部分内容，只有当确认的或者取消的时候，任务才可能继续完成执行这部分内容。如果该任务在子线程，用循环卡住，如果任务在主线程，用sleep+轮训处理。 你可以参考下处理。

曾经思考这种处理方式，但是会把业务搞得过度复杂，比如，在框架层面提供一个暂停标志，默认不开启，用户可自行决定是否设置为暂停状态，待与后端交互完成后，再将任务设置为继续状态，但是这样做会有一个问题，用户忘记设置就麻烦大了。

YummyLau commented 4 years ago

@lispking 周末看了下，实际上如果需要添加暂停机制，框架层可以开放一些anchor给开发者。现在框架只是设置一些anchor等待前置任务执行，可以更灵活调整为除了等待前置任务，&上一些开发者的条件，比如你的场景需要窗口确认等。 如果感兴趣可以一下pr或者我后续新增一下就好。

YummyLau commented 4 years ago

1.0.3已支持，请阅读readMe及sample