Anchors
Anchors copied to clipboard
DSAppTeam
大家还希望 Anchor 新增哪些功能？欢迎大家盖楼。
目前场景是图上所有路径都会执行，能否支持这么一种场景，只支持图中某一条路径，因为实际场景中，比如游戏等级，如果你选了不同难度级别，中间碰到的难关是不一样的，选择高难度看到的怪物是不一样，中级难度掉落物品也会不一样，低级难度获取经验更少，甚至中间不同的任务执行也会不一样，如果该场景支持，该库的普及度会更广。
@YummyLau 首先感谢你的开源了这个项目，我对比了几个启动框架，感觉Anchors流程蛮适合我们的，然后我fork了一份，同时增加了多进程支持和注解。 https://github.com/galaxybruce/Anchors
@YummyLau 首先感谢你的开源了这个项目，我对比了几个启动框架，感觉Anchors流程蛮适合我们的，然后我fork了一份，同时增加了多进程支持和注解。 https://github.com/galaxybruce/Anchors
昨天clone了代码仔细看了一番，说一下我的理解。新增了注解解析器用于新增依赖及Task支持进程功能。在start入口新增了工厂及多个task能力，但在内部再一次聚合。能解决业务的代码才是适合自己的代码，这里只讨论下两个功能对框架的影响。
-
注解申明依赖关系。由于单一task可能落在多条依赖链上，如果申明依赖关系实际上会限制了单一task的场景灵活性，这也是我一直权衡的原因，希望task的灵活使用时在使用者手上。但是如果task的依赖链不复杂且不存在交叉，注解是可以的。
-
关于多进程的初始化，目前我们线上的项目有严格的进程初始化管理，再根绝统一task可能出现在不同的进程且不同进程有着复杂的初始化链，所以并没有开放task的初始化绑定进程，同时，倘若业务新增了一个进程同时需要引入某个task的初始化，那么修改业务进程的初始化链的合理性会大于修改task的初始化代码。一个task的初始化代码建议只实现一个task的核心初始化功能即可。
针对多进程及初始化链的配置，一直在寻求合适的解决方案，欢迎随时pr或者探讨。
很感谢你抽出时间对我的修改做了点评。我比较赞同你的看法。 关于第一条看法，其实注解是支持多依赖的，而且是下收集所有的task，最后再处理依赖关系。应该可以解决单一task场景灵活性的问题。
- 所有的task id是task的class.simpleName
- 注解支持多依赖
- TaskFactory构造函数中调用loadTasks()函数，收集所有的task
- AnchorsManager.start方法中处理依赖关系 [image: image.png]
[image: image.png] [image: image.png]
不知道是否正确理解你的意图。
YummyLau [email protected] 于2020年1月20日周一 上午10:14写道：
@YummyLau https://github.com/YummyLau 首先感谢你的开源了这个项目，我对比了几个启动框架，感觉Anchors流程蛮适合我们的，然后我fork了一份，同时增加了多进程支持和注解。 https://github.com/galaxybruce/Anchors
昨天clone了代码仔细看了一番，说一下我的理解。新增了注解解析器用于新增依赖及Task支持进程功能。在start入口新增了工厂及多个task能力，但在内部再一次聚合。能解决业务的代码才是适合自己的代码，这里只讨论下两个功能对框架的影响。
注解申明依赖关系。由于单一task可能落在多条依赖链上，如果申明依赖关系实际上会限制了单一task的场景灵活性，这也是我一直权衡的原因，希望task的灵活使用时在使用者手上。但是如果task的依赖链不复杂且不存在交叉，注解是可以的。 2.
关于多进程的初始化，目前我们线上的项目有严格的进程初始化管理，再根绝统一task可能出现在不同的进程且不同进程有着复杂的初始化链，所以并没有开放task的初始化绑定进程，同时，倘若业务新增了一个进程同时需要引入某个task的初始化，那么修改业务进程的初始化链的合理性会大于修改task的初始化代码。一个task的初始化代码建议只实现一个task的核心初始化功能即可。
针对多进程及初始化链的配置，一直在寻求合适的解决方案，欢迎随时pr或者探讨。
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/YummyLau/Anchors/issues/9?email_source=notifications&email_token=AASZHXUOOS3SGBSBAVNEXULQ6UCGVA5CNFSM4JXKQD6KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJLEKOI#issuecomment-576079161, or unsubscribe https://github.com/notifications/unsubscribe-auth/AASZHXR4QEGNEU6VGI5MF4LQ6UCGVANCNFSM4JXKQD6A .
--
姓名：张小龙 手机：13739188962 QQ: 282347554 MSN: [email protected] Email：[email protected]
有一个小小的疑问 AnchorsManager#start方法，最后一段有一个while的循环，这里有个sleep10ms的方法，这里为什么是10ms，可以换成1ms么，不用sleep会有什么问题吗
@andyhaha sleep为的是让主线程短暂挂起。改成1ms理论上是可以的，但是没有必要，1ms后重新唤起主线程太频繁，增加损耗。如果不 sleep ，由于外层 onCreate 是一个阻塞行为，则会导致 ANR。
如果有一些必须在Splash之前要初始化完成的类是要放到anchors这个api里面去执行吧，后面放在图里面的同步task都是丢给Handler不能保证在UI渲染之前执行完毕，这个理解对么
@YummyLau 我们现在有这样的需求，默认启动的时候走一套初始化流程，判断用户是否同意了隐私弹窗，如果是就继续走，否则弹出隐私弹窗让用户点击之后通过回调再初始化一部分的三方库，这种需求有API支持么
@YummyLau 用户同意了隐私弹窗，继续初始化某一个task，lock功能可以在回调完成之后释放某一个task的锁才让某一个task执行是么，如果一直不释放就一直不会执行对么
@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);
@openproject 框架内部对这两个实际没有区分。强调的是Anchor同步阻塞是方法级别的，如果在attachBaseContext启动链就是以attachBaseContext方法作为背景，有anchors就是阻塞该方法；同理application#onCreate也如此。甚至在任何主线程方法都如此。
可以增加task执行时机的功能，例如task可能在attachBaseContext 、onCreate、firstActivityResume、idleHandler中执行
kotlin版本，懵逼中，再出个java版本；皆大欢喜，还有https://github.com/galaxybruce/Anchors 提到的注解等是否考虑加到这个框架中来；
