在工作线程上初始化TextToSpeech对象 [英] Initialising the TextToSpeech object on a worker thread

问题描述

多年来（字面上），我的应用程序遭遇了性能不佳的文本到语音引擎的困境，特别是调用时的初始化时间：

For years (literally), my application has suffered woes from poorly performing text to speech engines, in particular, the initialisation time when calling:

tts = new TextToSpeech(context, myOnInitListener);

以上情况可能导致用户界面滞后，如果您搜索文字转语音初始化缓慢那么，你会找到很多帖子。嵌入式高品质IVONA语音曾经是最糟糕的罪魁祸首，但 Google TTS引擎现已获奖。

The above can cause the UI to lag and if you search for 'Text to Speech initialization slow' on SO, you'll find many posts. The embedded high quality IVONA voices used to be the worst culprit, but the Google TTS engine has now taken the prize.

他们最近的APK更新会导致初始化时出现严重延迟 - 无需测试此代码，您可以转到Android文本到语音设置并尝试在可用引擎之间切换在按收听样本的同时，延迟得到了很好的证明。

Their most recent APK update, causes major lag on initialisation - No code necessary to test this, you can go to your Android Text to Speech settings and try switching between available engines, whilst pressing 'listen to a sample', the lag is demonstrated 'nicely'.

为了尝试解决这个问题，我实施了以下内容：

To try and combat this, I've implemented the following:

private volatile TextToSpeech tts;

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

这完全解决了初始化的滞后问题，但我担心这可能会产生副作用我没考虑过？任何人都可以想到吗？

This has completely cured the lag on initialisation, but I fear there may be side-effects to this that I've not considered? Can anyone think of any?

我也很困惑，因为我相信 TextToSpeech构造函数是异步的，因此将此构造函数移动到工作线程应该使没有不同？如果这种实施方式是前进的方向，那么为什么Google不会在TextToSpeechSettings ？

I'm puzzled also, as I had believed the the TextToSpeech Constructor was asynchronous and therefore moving this constructor to a worker thread should make no difference? If this implementation is the way forward, then why don't Google implement it in their TextToSpeechSettings?

希望有人能澄清以上内容。在此先感谢。

Hope someone can clarify the above. Thanks in advance.

编辑 - 当我说构造函数是异步的时，我的确指的是它启动的引擎初始化过程，最后调用onInit

Edit - When I said the 'Constructor was asynchronous', I really was referring to the engine initialisation process it starts, and the eventual call to onInit

推荐答案

我相信TextToSpeech构造函数是异步的

I had believed the the TextToSpeech Constructor was asynchronous

这只是部分正确。许多初始化是同步执行的。这是来源

That is only partially true. A lot of the initialization is executed syncronously. Here is the Source

如果这种实施是前进的方向，那么Google为何不实施它在他们的TextToSpeechSettings？

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

似乎google很少检查他们的代码在中端和低端设备上的运行方式，我猜迟远没有t显示在高端设备上。 （在当前的YouTube应用程序中可以看到这种情况发生的另一个例子，我个人可以确认中等规格设备上的滞后和高端设备没有滞后。）这是纯粹的猜测，因为我不隶属于谷歌。

It seems like google seldomly checks how their code runs on mid and lowend devices, I guess the lag doesn't show on highend devices. (Another example of this happening can be seen in the current youtube app, for which I personally can confirm lag on a mid-spec device and no lag on a high-end device.) This is pure speculation as I am not affiliated to google.

我担心这可能会产生副作用，我没考虑过？任何人都可以想到吗？

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

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

The only (obvious) sideeffect is that you can't use the tts engine syncronously, but have to wait for the asyncronous task to finish. But that is already the case anyway. The only thing you do is execute some code outside of the UI thread, which does not expect to be run on the UI thread. This should never be a problem. And even if there is a problem, you will only find it by testing it in an application.

一般来说，你很高兴。

这篇关于在工作线程上初始化TextToSpeech对象的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！