¿Existen grandes limitaciones al desarrollar aplicaciones de cámara para Android?

Trabajé en la cámara personalizada de Path en Android http://bit.ly/wT3Vpr [3].

Tenía la misma pregunta en mente cuando comencé a trabajar en la cámara. Lamentablemente, esta es una sección donde la fragmentación de Android te golpea muy fuerte.

En términos de API , el mayor problema es que Android no proporciona una API para obtener marcos de cámara en tiempo real en formato RGB. Te queda un conjunto de formatos YUV [1]. Esto hace que sea muy difícil renderizar la vista previa de la cámara usando OpenGL para aplicar filtros en tiempo real antes de que el usuario tome la imagen. Tuvimos que pasar mucho tiempo para hacer que la conversión de YUV a RGB sea lo suficientemente rápida como para que podamos renderizar filtros en tiempo real en teléfonos de gama baja alrededor de 15 fps. Afortunadamente, este problema se ha solucionado en Honeycomb, donde puede obtener la imagen de la cámara como una textura OpenGL [2]. Esta no era una opción viable para nosotros en ese entonces, ya que la mayoría de los teléfonos Android todavía tenían 2.3.x.

Lamentablemente, la cámara es la parte donde la fragmentación de Android te golpea más fuerte. Hay muchos teléfonos con hardware de cámara diferente y tienen comportamientos inconsistentes. Si no renderiza la vista previa de la cámara usted mismo y se basa en la vista de la cámara incorporada, debe lidiar con un montón de casos extremos. Algunos teléfonos informan que la orientación es incorrecta, algunos requieren más tiempo para configurar la cámara, todos tienen diferentes resoluciones y relaciones de aspecto, etc. Si utiliza la vista de cámara integrada, debe realizar muchas pruebas para cubrir estos casos extremos. Dado que renderizamos nuestra propia vista de cámara a través de OpenGL, no tuvimos que lidiar con la mayoría de estos problemas. Por ejemplo, para evitar diferentes problemas de resolución sin mostrar espacio en blanco en la interfaz de usuario, simplemente estamos ampliando la imagen hasta que llena la pantalla. Todas estas tareas de 1 hora en iPhone se convierten en un proyecto de un par de días en Android.

Si sigue el camino de OpenGL, ahora necesita lidiar con pilas inconsistentes de OpenGL entre diferentes teléfonos. Por ejemplo, los dispositivos Sony XPeria trajeron soporte OpenglES 2 a la plataforma antes de que formara parte de Android. Esto crea un problema en el que su conjunto predeterminado de formatos de textura, etc., no coincide con las especificaciones de Android. Debe solucionar todos estos problemas e implementar un código flexible que pueda detectar y solucionar todos estos casos extremos. Esto nuevamente requiere muchas pruebas y lectura de código fuente.

Otro problema en términos de procesamiento de imágenes es el límite de memoria en las aplicaciones de Android. Cuando toma una imagen de 5MP de la cámara y desea editarla, es muy probable que alcance el límite de memoria en los teléfonos de gama baja. Para solucionar este problema, debe mover la mayor parte del código de procesamiento de imágenes a NDK, donde la memoria física del teléfono es su límite de memoria (que es suficiente la mayor parte del tiempo). Mover la mayor parte del procesamiento de imágenes a OpenGL es otra buena solución alternativa en la que el tamaño de la textura no se cuenta en función del uso de memoria de la aplicación.

Por naturaleza, escribir una aplicación de cámara no es una tarea fácil. Con la carga adicional de problemas específicos de la plataforma, esto se vuelve realmente difícil para Android y la mayoría de las startups no tienen suficiente tiempo y recursos para lidiar con estos problemas.

[1] ImageFormat | Desarrolladores de Android
[2] Cámara | Desarrolladores de Android setPreviewTexture
[3] una captura de pantalla de la aplicación de cámara de Path: