Initialisieren des TextToSpeech-Objekts in einem Arbeitsthread

8

Seit Jahren (wörtlich) hat meine Anwendung Probleme mit schlecht funktionierenden Text-zu-Sprache-Engines gehabt, insbesondere die Initialisierungszeit beim Aufruf von:

%Vor%

Das obige Verhalten kann dazu führen, dass die Benutzeroberfläche verzögert wird. Wenn Sie in SO nach "Text-zu-Sprache-Initialisierung langsam" suchen, finden Sie viele Posts. Die eingebetteten hochqualitativen IVONA-Voices waren der schlimmste Schuldige, aber die Google TTS-Engine hat nun den Preis gewonnen.

Ihr aktuellstes APK-Update verursacht eine große Verzögerung bei der Initialisierung - Es ist kein Code erforderlich, um dies zu testen, Sie können zu Ihren Android-Text-zu-Sprache-Einstellungen wechseln und versuchen, zwischen verfügbaren Engines umzuschalten wird 'nett' demonstriert.

Um dies zu bekämpfen, habe ich Folgendes implementiert:

%Vor%

Das hat die Verzögerung bei der Initialisierung vollständig geheilt, aber ich befürchte, dass es Nebenwirkungen gibt, die ich nicht berücksichtigt habe? Kann jemand an etwas denken?

Ich bin auch verwirrt, als ich geglaubt hatte, dass die Der TextToSpeech-Konstruktor war asynchron und daher sollte es keinen Unterschied machen, diesen Konstruktor in einen Worker-Thread zu verschieben. Wenn diese Implementierung der richtige Weg ist, warum implementiert Google sie nicht in ihrer TextToSpeechSettings ?

Hoffe jemand kann das oben verdeutlichen. Vielen Dank im Voraus.

Bearbeiten - Als ich sagte, dass der Konstruktor asynchron war, bezog ich mich wirklich auf den Initialisierungsprozess der Engine und den eventuellen Aufruf von onInit

    
brandall 15.03.2016, 14:07
quelle

1 Antwort

-1
  

Ich hatte geglaubt, der TextToSpeech-Konstruktor sei asynchron

Das ist nur teilweise richtig. Ein Großteil der Initialisierung wird synchron ausgeführt. Hier ist die Quelle

  

Wenn diese Implementierung der richtige Weg ist, warum implementiert Google sie dann nicht in ihren TextToSpeechSettings?

Wie es scheint, überprüft Google selten, wie sein Code auf Mid- und Low-End-Geräten läuft. Ich denke, dass die Verzögerung auf High-End-Geräten nicht angezeigt wird. (Ein weiteres Beispiel für dieses Geschehen ist in der aktuellen Youtube-App zu sehen, für die ich Lag auf einem Mid-Spec-Gerät und keine Verzögerung auf einem High-End-Gerät bestätigen kann.) Dies ist reine Spekulation, da ich nicht mit Google verbunden bin .

  

Ich befürchte, dass es Nebenwirkungen gibt, die ich nicht berücksichtigt habe? Kann jemand an etwas denken?

Der einzige (offensichtliche) Nebeneffekt besteht darin, dass Sie die TTS-Engine nicht synchron verwenden können, sondern warten müssen, bis die asynchrone Aufgabe abgeschlossen ist. Aber das ist ohnehin schon der Fall. Das einzige, was Sie tun, ist Code außerhalb des UI-Threads auszuführen, von dem nicht erwartet wird, dass er auf dem UI-Thread ausgeführt wird. Dies sollte niemals ein Problem sein. Und selbst wenn es ein Problem gibt, werden Sie es nur finden, indem Sie es in einer Anwendung testen.

Im Allgemeinen ist es gut zu gehen.

    
F43nd1r 29.03.2016 14:51
quelle