带有异步回调的方法被设定为锚定时无法运行到回调中

[Cr321]

我有一段初始化代码，他本身没有同步方法，所以我用 CountDownLatch 去把它转变为同步的方法，在未把该任务设为锚定时这段运行完全没有问题，可以达到预期的效果，但当我把它设为锚定点时，运行后就无法再走到回调里了。

private static class TestTask extends Task {

        private final CountDownLatch countDownLatch = new CountDownLatch(1);

        TestTask() {
            super(TASK_TEST, true);
        }

        @Override
        protected void run(String name) {
            mTest.runAsync(mContext, new CallBack() {
                @Override
                public void callback() {
                    countDownLatch.countDown();
                }
            });
            try {
                countDownLatch.await();
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        }
    }
`

[YummyLau]

@Cr321 你的task构造器第二个参数为true，指明task为异步操作，mTest.runAsync 应该存在有问题的。你可以贴完整的代码。run只是一个任务体的执行内容，不建议在run里面再做异步切换。

[Cr321]

@Cr321 你的task构造器第二个参数为true，指明task为异步操作，mTest.runAsync 应该存在有问题的。你可以贴完整的代码。run只是一个任务体的执行内容，不建议在run里面再做异步切换。

我也不想再在异步任务里再做一次异步切换，但很多 SDK 提供的 init 都只有异步方法，如果我想等待这个异步方法真的运行完才退出任务需要怎么办呢？

[YummyLau]

我的经验。希望能帮你解惑。 首先不知道我的理解对不对，你说述的 “很多 SDK 提供的 init 都只有异步方法”。应该是提供一个方法，接收一个callback，方法里面的实现切到异步线程处理切会回主线程调用callback吧。这也是常规的提供sdk的做法。不知道我的理解对得上你的场景不。这种sdk不适合做初始化阻塞链。原因是这个sdk的初始化时间是未知的，所以这个sdk的回调结果也是未知的，任何获得到的异步结果之后要执行的任务，都应该不要不在application初始化的阻塞流程中。所以，你一个申明一个task为同步，执行你的异步init初始化，在回调成功中做你的进一步工作就好了。

[Cr321]

我的经验。希望能帮你解惑。 首先不知道我的理解对不对，你说述的 “很多 SDK 提供的 init 都只有异步方法”。应该是提供一个方法，接收一个callback，方法里面的实现切到异步线程处理切会回主线程调用callback吧。这也是常规的提供sdk的做法。不知道我的理解对得上你的场景不。这种sdk不适合做初始化阻塞链。原因是这个sdk的初始化时间是未知的，所以这个sdk的回调结果也是未知的，任何获得到的异步结果之后要执行的任务，都应该不要不在application初始化的阻塞流程中。所以，你一个申明一个task为同步，执行你的异步init初始化，在回调成功中做你的进一步工作就好了。

感谢你的分享，我最近也一直在想这类初始化的位置，因为后续有些依赖任务，所以希望在进入应用主界面前把相关的都初始化完成。 但正如你所说，如果阻塞 application 的初始化流程，由于初始化时间未知，所以给用户体验造成的影响会更大，我会考虑其他的办法的。

[YummyLau]

@Cr321 有更好的办法可邮件我