memory - memoria - liberar espacio sistema iphone

¿Cómo manejar las limitaciones de memoria en iOS 8 Photo Extensions?

Question

Agregué una nueva extensión de fotos iOS 8 a mi aplicación de edición de fotos existente. Mi aplicación tiene un inventario de filtros bastante complejo y necesita mantener múltiples texturas en la memoria a la vez. Sin embargo, en dispositivos con 1 GB de RAM, puedo procesar imágenes de 8 MP fácilmente.

En la extensión, sin embargo, hay restricciones de memoria mucho más altas. Tuve que reducir la imagen a menos de 2 MP para que se procesara sin colapsar la extensión. También pensé que los problemas de memoria solo ocurrían cuando no tenía un depurador conectado a la extensión. Con eso, todo funciona bien.

Hice algunos experimentos. Modifiqué una aplicación de prueba de presupuesto de memoria para trabajar dentro de una extensión y obtuve los siguientes resultados (que muestran la cantidad de RAM en MB que se puede asignar antes de fallar):

╔═══════════════════════╦═════╦═══════════╦══════════════════╗
║        Device         ║ App ║ Extension ║ Ext. (+Debugger) ║
╠═══════════════════════╬═════╬═══════════╬══════════════════╣
║ iPhone 6 Plus (8.0.2) ║ 646 ║       115 ║              645 ║
║ iPhone 5 (8.1 beta 2) ║ 647 ║        97 ║              646 ║
║ iPhone 4s (8.0.2)     ║ 305 ║        97 ║              246 ║
╚═══════════════════════╩═════╩═══════════╩══════════════════╝

Algunas observaciones:

• Con el depurador conectado, la extensión se comporta como la aplicación "normal"
• Aunque el 4 tiene solo la mitad de la cantidad total de memoria (512 MB) en comparación con los otros dispositivos, obtiene los mismos ~ 100 MB del sistema para la extensión.

Ahora mi pregunta: ¿cómo se supone que debo trabajar con esta pequeña cantidad de memoria en una extensión de edición de fotos? Una textura que contiene una imagen RGBA de 8 MP (resolución de la cámara) consume ~ 31 MB solo. ¿Cuál es el objetivo de este mecanismo de extensión si tengo que decirle al usuario que la edición de tamaño completo solo es posible cuando se usa la aplicación principal?

¿Alguno de ustedes también llegó a esa barrera? ¿Encontró una solución para eludir esta restricción?

Answer 1

Si está utilizando una "receta" de Core Image, no necesita preocuparse por la memoria, tal como dijo Marco. No se representa ninguna imagen en la que se apliquen filtros de imagen principal hasta que el objeto imagen se devuelve a la vista.

Eso significa que puede aplicar un millón de filtros a una foto del tamaño de una cartelera de carretera, y la memoria no sería el problema. Las especificaciones del filtro simplemente se compilarían en una convolución o kernel, que todos tienen el mismo tamaño, sin importar qué.

Los malentendidos sobre la administración de la memoria y el desbordamiento y similares pueden remediarse fácilmente al orientarse con los conceptos básicos de su lenguaje de programación, entorno de desarrollo y plataforma de hardware elegidos.

La documentación de Apple que introduce la programación del filtro de Imagen Principal es suficiente para esto; Si desea referencias específicas a partes de la documentación que creo que pertenecen específicamente a sus inquietudes, solo pregunte.

Answer 2

Aquí se explica cómo aplica dos núcleos de convolución consecutivos en Core Image, con el "resultado intermediario" entre ellos:

- (CIImage *)outputImage { 

const double g = self.inputIntensity.doubleValue;
const CGFloat weights_v[] = { -1*g, 0*g, 1*g,
                              -1*g, 0*g, 1*g,
                              -1*g, 0*g, 1*g};

CIImage *result = [CIFilter filterWithName:@"CIConvolution3X3" keysAndValues:
          @"inputImage", self.inputImage,
          @"inputWeights", [CIVector vectorWithValues:weights_v count:9],
          @"inputBias", [NSNumber numberWithFloat:1.0],
          nil].outputImage;

CGRect rect = [self.inputImage extent];
rect.origin = CGPointZero;

CGRect cropRectLeft = CGRectMake(0, 0, rect.size.width, rect.size.height);
CIVector *cropRect = [CIVector vectorWithX:rect.origin.x Y:rect.origin.y Z:rect.size.width W:rect.size.height];
result = [result imageByCroppingToRect:cropRectLeft];

result = [CIFilter filterWithName:@"CICrop" keysAndValues:@"inputImage", result, @"inputRectangle", cropRect, nil].outputImage;


const CGFloat weights_h[] = {-1*g, -1*g, -1*g,
    0*g,   0*g,   0*g,
    1*g,   1*g,     1*g};


result = [CIFilter filterWithName:@"CIConvolution3X3" keysAndValues:
          @"inputImage", result,
          @"inputWeights", [CIVector vectorWithValues:weights_h count:9],
          @"inputBias", [NSNumber numberWithFloat:1.0],
          nil].outputImage;

result = [result imageByCroppingToRect:cropRectLeft];

result = [CIFilter filterWithName:@"CICrop" keysAndValues:@"inputImage", result, @"inputRectangle", cropRect, nil].outputImage;

result = [CIFilter filterWithName:@"CIColorInvert" keysAndValues:kCIInputImageKey, result, nil].outputImage;

return result;

}

Answer 3

Estoy desarrollando una extensión de edición de fotos para mi empresa, y estamos enfrentando el mismo problema. Nuestro motor de procesamiento interno de imágenes necesita más de 150 mb para aplicar ciertos efectos a una imagen. Y esto ni siquiera cuenta imágenes panorámicas que tomarán alrededor de ~ 100mb de memoria por copia.

Solo encontramos dos soluciones, pero no una solución real.

1. Escalar la imagen y aplicar el filtro. Esto requerirá mucho menos memoria, pero el resultado de la imagen es terrible. Al menos la extensión no se bloqueará.

o

2. Usa CoreImage o Metal para el procesamiento de imágenes. A medida que analizamos la extensión de edición de fotografías de muestra de Apple, que utiliza CoreImage, podemos manejar imágenes de gran tamaño e incluso panoramas sin pérdida de calidad o resolución. En realidad, no pudimos bloquear la extensión cargando imágenes muy grandes. El código de muestra puede manejar panoramas con una vista de memoria de 40 mb, que es bastante impresionante.

De acuerdo con la Guía de programación de extensión de aplicaciones de Apple, página 55, capítulo "Manejo de restricciones de memoria", la solución para la presión de memoria en extensiones es revisar el código de procesamiento de imágenes. Hasta ahora estamos portando nuestro motor de procesamiento de imágenes a CoreImage, y los resultados son mucho mejores que nuestro motor anterior.

Espero poder ayudar un poco. Marco Paiva