¿Por qué los subprocesos nativos se comportan de forma diferente cuando la aplicación está en segundo plano?
En mi aplicación, uso hilos nativos para procesar datos de audio. El código se parece mucho a esto:
std::thread([this] () { while (enabled) { if (condition()) { process(); } usleep(100); } });
Esto funciona bien cuando la aplicación está en primer plano. En segundo plano, el procesamiento no es lo suficientemente rápido como para obtener buffer-underruns. Sólo funciona sin usleep
en segundo plano. El valor que paso a usleep
no hace la diferencia. No funciona con valores más pequeños también. También intenté std::this_thread::sleep_for(std::chrono::microseconds(100))
pero no hace la diferencia.
- C ++ 11 funciones cmath no en el espacio de nombres std para android NDK w / gcc-4.8 o clang 3.4
- No se pueden incluir encabezados de C ++ como vector en Android NDK
- Vinculación de la compilación de la biblioteca con ndk r10 en la compilación del proyecto con ndk r13 utilizando c ++ _ stl compartido
- Uso de NDK con STL en Android Studio gradle project
- Uso de la STL con Android NDK C ++
Tengo que usar usleep
o algo similar para evitar el uso de CPU de alta y por lo tanto para ahorrar batería de por vida.
¿Qué puedo hacer para que los subprocesos nativos se comporten igual cuando la aplicación está en segundo plano?
- Distribuir la biblioteca NDK con gnustl?
- ¿Cuál es el comportamiento si una aplicación de Android NDK carga más de una implementación compartida de STL de C ++?
- Std :: map linker error ndk r8c con APP_STL: = gnustl_static
- Excepciones de Android NDK y C ++: estado actual?
- Manejo de excepciones de Android NDK
- Android NDK STL c ++ _ compartido con resultados LIBCXX_FORCE_REBUILD en std :: stringstream NOP
- Vinculación de STL a un ejecutable NDK independiente de Android
- ¿Cuál es la diferencia entre gnustl y stlport en el desarrollo android ndk?
Parece que Android establece la prioridad Thread para aplicaciones de fondo inferior si no se especifica explícitamente lo contrario. Esta documentación menciona
Generalmente, los subprocesos en el grupo de primer plano obtienen aproximadamente el 95% del tiempo de ejecución total del dispositivo, mientras que el grupo de fondo obtiene aproximadamente el 5%.
Lo que explicaría sus infracciones. Usted debe tratar de aumentar la prioridad como se describe allí. El video enlazado también parece útil.
Puedo estar equivocado, pero parece que debe priorizar su hilo en la CPU. Cuando la aplicación está en segundo plano (o destruida pero con subprocesos en directo), los subprocesos son priorizados por el sistema operativo y su actividad se reduce la mayor parte del tiempo, especialmente si se inicializan con la prioridad predeterminada.
Trate de trabajar con HandlerThread (android.os). De esta manera usted puede definir su prioridad, y en su caso podría intentar THREAD_PRIORITY_AUDIO
Java: (lo siento por no c ++)
HandlerThread thread = new HandlerThread("MyThread", Process.THREAD_PRIORITY_AUDIO)
- Extensión de android: WindowTitle
- Cómo utilizar tabContentStart para iniciar el contenido desde la mitad de la pantalla del dispositivo