java初始化工作线程上的TextToSpeech对象

Question

多年来（从字面上讲），我的应用程序一直受到文本到语音引擎性能不佳的困扰，尤其是调用时的初始化时间：

tts = new TextToSpeech(context, myOnInitListener);

上述情况可能会导致用户界面延迟，如果你搜索“文本到语音初始化缓慢”，你会发现很多帖子。嵌入的高质量IVONA声音曾经是最糟糕的罪魁祸首，但现在Google TTS engine已经获奖

他们最新的APK更新导致了初始化的严重滞后——无需代码来测试这一点，你可以转到你的Android文本到语音设置，尝试在可用引擎之间切换，同时按下“收听示例”，滞后被“很好地”显示出来

为了应对这种情况，我实施了以下措施：

private volatile TextToSpeech tts;

AsyncTask.execute(new Runnable() {
    @Override
    public void run() {
        tts = new TextToSpeech(context, volatileOnInitListener);
    }
});

这已经完全解决了初始化的滞后问题，但我担心可能会有我没有考虑过的副作用？有人能想到什么吗

我也很困惑，因为我认为TextToSpeech Constructor是异步的，因此将这个构造函数移动到工作线程应该不会有什么不同？如果这个实现是前进的方向，那么谷歌为什么不在他们的TextToSpeechSettings中实现它呢

希望有人能澄清以上。提前谢谢

编辑-当我说“构造函数是异步的”时，我指的是它启动的引擎初始化过程，以及对onInit的最终调用

Answer 1

I had believed the the TextToSpeech Constructor was asynchronous

这只是部分正确。很多初始化都是同步执行的。这是Source

If this implementation is the way forward, then why don't Google implement it in their TextToSpeechSettings?

谷歌似乎很少检查他们的代码在中低端设备上的运行情况，我想这种滞后现象在高端设备上不会表现出来。（这种情况的另一个例子可以在当前的youtube应用程序中看到，我个人可以确认在中等规格的设备上存在延迟，在高端设备上没有延迟。）这纯粹是猜测，因为我不隶属于谷歌

I fear there may be side-effects to this that I've not considered? Can anyone think of any?

唯一（明显）的副作用是，您不能同步使用tts引擎，但必须等待异步任务完成。但无论如何，情况已经如此。你要做的唯一一件事就是在UI线程之外执行一些代码，而这些代码预计不会在UI线程上运行。这永远不应该是个问题。即使有问题，你也只能通过在应用程序中测试来发现

总的来说，你可以走了