DSAppTeam/Anchors

大家还希望 Anchor 新增哪些功能？欢迎大家盖楼。

YummyLau opened this issue · 26 comments

YummyLau commented
大家还希望 Anchor 新增哪些功能？欢迎大家盖楼。
YummyLau commented

任务暂停机制支持 v1.0.3 开发完毕

lispking commented

任务暂停机制支持 v1.0.3 开发完毕

lgtm

YummyLau commented

任务暂停机制支持 v1.0.3 开发完毕

lgtm

(⊙_⊙)? 啥

lispking commented

目前场景是图上所有路径都会执行，能否支持这么一种场景，只支持图中某一条路径，因为实际场景中，比如游戏等级，如果你选了不同难度级别，中间碰到的难关是不一样的，选择高难度看到的怪物是不一样，中级难度掉落物品也会不一样，低级难度获取经验更少，甚至中间不同的任务执行也会不一样，如果该场景支持，该库的普及度会更广。

galaxybruce commented

@YummyLau
首先感谢你的开源了这个项目，我对比了几个启动框架，感觉Anchors流程蛮适合我们的，然后我fork了一份，同时增加了多进程支持和注解。
https://github.com/galaxybruce/Anchors

YummyLau commented

@galaxybruce 感谢认可，我fork下看下

YummyLau commented

@YummyLau
首先感谢你的开源了这个项目，我对比了几个启动框架，感觉Anchors流程蛮适合我们的，然后我fork了一份，同时增加了多进程支持和注解。
https://github.com/galaxybruce/Anchors

昨天clone了代码仔细看了一番，说一下我的理解。新增了注解解析器用于新增依赖及Task支持进程功能。在start入口新增了工厂及多个task能力，但在内部再一次聚合。能解决业务的代码才是适合自己的代码，这里只讨论下两个功能对框架的影响。

  1. 注解申明依赖关系。由于单一task可能落在多条依赖链上，如果申明依赖关系实际上会限制了单一task的场景灵活性，这也是我一直权衡的原因，希望task的灵活使用时在使用者手上。但是如果task的依赖链不复杂且不存在交叉，注解是可以的。

  2. 关于多进程的初始化，目前我们线上的项目有严格的进程初始化管理，再根绝统一task可能出现在不同的进程且不同进程有着复杂的初始化链，所以并没有开放task的初始化绑定进程，同时，倘若业务新增了一个进程同时需要引入某个task的初始化，那么修改业务进程的初始化链的合理性会大于修改task的初始化代码。一个task的初始化代码建议只实现一个task的核心初始化功能即可。

针对多进程及初始化链的配置，一直在寻求合适的解决方案，欢迎随时pr或者探讨。

galaxybruce commented
andyhaha commented

有一个小小的疑问
AnchorsManager#start方法，最后一段有一个while的循环，这里有个sleep10ms的方法，这里为什么是10ms，可以换成1ms么，不用sleep会有什么问题吗

YummyLau commented

@andyhaha sleep为的是让主线程短暂挂起。改成1ms理论上是可以的，但是没有必要，1ms后重新唤起主线程太频繁，增加损耗。如果不 sleep ，由于外层 onCreate 是一个阻塞行为，则会导致 ANR。

  • 👍2
Alexxiaopang commented

现在的任务都是基于Runnable去实现的，如果基于协程去写，是否能节省更多的线程开支？通过async await等达到异步和同步还有锚点

YummyLau commented

@Alexxiaopang 本质上是一样的。引入协程只会让库的包体变得更大或者限制依赖方引入协程库，所以是不建议如此的。

NickHu150 commented

如果有一些必须在Splash之前要初始化完成的类是要放到anchors这个api里面去执行吧，后面放在图里面的同步task都是丢给Handler不能保证在UI渲染之前执行完毕，这个理解对么

YummyLau commented

@NickHu150 嗯是的

NickHu150 commented

@YummyLau 我们现在有这样的需求，默认启动的时候走一套初始化流程，判断用户是否同意了隐私弹窗，如果是就继续走，否则弹出隐私弹窗让用户点击之后通过回调再初始化一部分的三方库，这种需求有API支持么

YummyLau commented

@NickHu150 用户同意隐私弹窗，是你自己的界面吗？ 你可以参考lock功能设计就好了。

NickHu150 commented

@YummyLau 用户同意了隐私弹窗，继续初始化某一个task，lock功能可以在回调完成之后释放某一个task的锁才让某一个task执行是么，如果一直不释放就一直不会执行对么

YummyLau commented

@NickHu150 lock可以释放，也可以选择中断

NickHu150 commented

@YummyLau 我们现在保证稳定性做逐步拆解一开始只是拆成两个Task，每个版本迭代抽出一个task，目前我们这样写，貌似creator的creattask方法没有被执行，麻烦看下是不是使用姿势的问题

 factory = new AnchorTaskFactory(instance);
    Project project = new Project.Builder(TasksName.PROJECT_ONE,factory)
          .build();
    AnchorsManager.getInstance().debuggable(DuConfig.DEBUG).addAnchors(
            TasksName.TASK_SYNC,TasksName.TASK_INIT
    ).start(project);
YummyLau commented

@NickHu150 这个issue不做api使用讨论了，不然后续太长了。加一下微信我 Ming_Lyan 拉你进讨论组一下，到那边讨论。

openproject commented

执行时机能否区分 attachBaseContext 和 onCreate？

YummyLau commented

@openproject 框架内部对这两个实际没有区分。强调的是Anchor同步阻塞是方法级别的，如果在attachBaseContext启动链就是以attachBaseContext方法作为背景，有anchors就是阻塞该方法；同理application#onCreate也如此。甚至在任何主线程方法都如此。

Toyssabc commented

我需要一个直播平台。它将包含赌场

Fredlxy commented

可以增加task执行时机的功能，例如task可能在attachBaseContext 、onCreate、firstActivityResume、idleHandler中执行

shenxiaolin commented

kotlin版本，懵逼中，再出个java版本；皆大欢喜，还有https://github.com/galaxybruce/Anchors 提到的注解等是否考虑加到这个框架中来；

MichaelJokAr commented

有没有类似这样的对比图啊，跟alpha和appStartUp的
image