多年来(字面上),我的应用程序一直因为性能不佳的文本到语音引擎而陷入困境,特别是调用时的初始化时间:
tts = new TextToSpeech(context, myOnInitListener);上面的内容会导致用户界面延迟,如果你在上面搜索“文本到语音初始化缓慢”,你会发现很多帖子。嵌入的高质量IVONA的声音曾经是最糟糕的罪魁祸首,但是Google引擎现在已经获得了这个奖项。
他们最新的APK更新会导致初始化上的严重滞后--没有必要对此进行测试,您可以将Android文本转到语音设置,并尝试在可用引擎之间切换,同时按“听一个示例”,就会显示出“很好”。
为了解决这一问题,我实现了以下几个方面:
private volatile TextToSpeech tts;
AsyncTask.execute(new Runnable() {
@Override
public void run() {
tts = new TextToSpeech(context, volatileOnInitListener);
}
});这完全治愈了初始化的滞后,但我担心这可能有副作用,我还没有考虑过呢?有人能想到什么吗?
我也感到困惑,因为我曾经认为TextToSpeech构造器是异步的,因此将这个构造函数转移到一个工作线程应该没有什么区别?如果这个实现是前进的方向,那么为什么不谷歌在他们的TextToSpeechSettings中实现它呢?
希望有人能澄清上面的内容。提前谢谢。
编辑-当我说‘构造函数是异步的’时,我实际上是指它启动的引擎初始化过程,以及对onInit的最终调用。
发布于 2016-03-29 14:51:11
我曾经相信TextToSpeech构造器是异步的。
这只是部分正确。很多初始化都是同步执行的。这是来源
如果这个实现是前进的方向,那么为什么谷歌不在他们的TextToSpeechSettings中实现它呢?
谷歌似乎很少检查他们的代码是如何在中低端设备上运行的,我想这种滞后在高端设备上不会显示出来。(这种情况的另一个例子可以在当前的youtube应用程序中看到,我个人可以确认在中规格设备上滞后,而在高端设备上没有滞后。)这纯粹是猜测,因为我不附属于谷歌。
我担心这可能有副作用,我还没考虑过呢?有人能想到什么吗?
唯一(明显的)副作用是您不能同步使用tts引擎,而必须等待异步任务的完成。但无论如何,情况已经如此。您所做的唯一的事情就是在UI线程之外执行一些代码,这些代码不会在UI线程上运行。这不应该是个问题。即使存在问题,也只能通过在应用程序中进行测试才能找到它。
一般来说你可以走了。
https://stackoverflow.com/questions/36013611
复制相似问题