Inizializzazione dell'object TextToSpeech su un thread di lavoratore

Per anni (letteralmente), la mia applicazione ha sofferto di problemi da motori di text a motori discontinui, in particolare, il tempo di initialization durante la chiamata:

tts = new TextToSpeech(context, myOnInitListener); 

Quanto sopra può causare un ritardo all'interface utente e se si cerca l'initialization di text in vocalizzazione in SO, troverai molti post. Le voci embedded di alta qualità IVONA erano il peggiore colpevole, ma il motore di Google TTS ora ha preso il premio.

  • Usando "android: textAppearance" su TextView / EditText non funziona, ma funziona "stile"
  • Applicare ColorFilter a ImageView con ShapedDrawable
  • startActivityForResult () da un elemento di frammento e di finitura, non chiama onActivityResult () in Frammento
  • Bitmap a grande
  • Testo Android TextView non avvolto
  • Come caricare i video dalla cartella degli asset? (per riprodurli con VideoView)
  • Il loro aggiornamento APK più recente provoca un grosso ritardo di initialization – Nessun codice necessario per verificare questo problema, puoi passare alle tue impostazioni di text da parlare di Android e provare a passare tra i motori disponibili mentre premere 'ascoltare un campione', il ritardo è dimostrato ' bene'.

    Per cercare di combattere questo problema, ho implementato quanto segue:

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

    Questo ha curato completamente il ritardo all'initialization, ma temo che ci possa essere effetti collaterali che non ho considerato? Qualcuno può pensare a nessuno?

    Sono anche perplesso, perché avevo creduto che il Costruttore di TextToSpeech fosse asincrono e quindi spostare questo constructor in un thread di lavoratore non dovrebbe fare differenza? Se questa implementazione è la via da seguire, perché non lo implementa Google nei propri TextToSpeechSettings ?

    Spero che qualcuno possa chiarire quanto sopra. Grazie in anticipo.

    Modifica – Quando ho detto che il "Costruttore era asincrono", mi riferivo davvero al process di initialization del motore che inizia e l'eventuale chiamata a onInit

  • Perdere 'MediaPlayer' (& altre variables) quando il dispositivo viene ruotato
  • Android proguard, mantenere la class interiore
  • OS X 10.6.6 e "dispositivi adb" non riescono a elencare i dispositivi android
  • Android: BitmapFactory.decodeByteArray fornisce bitmap pixelato
  • Come impostare un'altezza massima con il contenuto dell'involucro in android?
  • Come creare un object con JNI?
  • One Solution collect form web for “Inizializzazione dell'object TextToSpeech su un thread di lavoratore”

    Avevo creduto che il Costruttore di TextToSpeech fosse asincrono

    Ciò è solo parzialmente vero. Molta initialization viene eseguita in modo sincronico. Ecco la fonte

    Se questa implementazione è la via da seguire, perché non lo implementa Google nei propri TextToSpeechSettings?

    Sembra che google raramente controlla il modo in cui il codice esegue i dispositivi a metà e basso, immagino che il ritardo non si verifichi nei dispositivi di fascia alta. (Un altro esempio di questo avvenimento può essere visto nell'app current youtube app, per la quale personalmente posso confermare un ritardo su un dispositivo a metà spec e senza ritardo su un dispositivo di fascia alta.) Questa è una pura speculazione dato che non sono affiliato a google .

    Temo che ci possa essere effetti collaterali a questo che non ho considerato? Qualcuno può pensare a nessuno?

    L'unico lato (effetto ovvio) è che non è ansible utilizzare il motore TTS in modo sincronizzato, ma deve aspettare che l'attività asynchronous finisca. Ma questo è già il caso comunque. L'unica cosa che fai è eseguire un codice al di fuori del thread UI, che non si aspetta di essere eseguito sul thread UI. Questo non dovrebbe mai essere un problema. E anche se c'è un problema, lo troverai solo testandolo in un'applicazione.

    In generale sei bravo ad andare.

    L'Android è un fan Android di Google, tutto su telefoni Android, Android Wear, Android Dev e applicazioni Android Games e così via.