Quantcast
Channel: Memoria de Acceso Aleatorio » Faq-Mac
Viewing all articles
Browse latest Browse all 4

iOS: Dominando la caché

0
0

En faq-mac publicaban un comentario de asiersylvano, bajo el título de La caché de iOS a veces no es tu amiga.

En primer lugar, recordemos que una caché (del inglés cache, a su vez del francés cacher, esconder) es un espacio en el que se depositan cosas en un lugar más cercano a donde se van a utilizar (por ejemplo, una caseta de aperos de labranza en el campo es una cache para tenerlos en el campo, y no en la casa).

En él, asiersylvano describe un par de escenarios en los que encuentra que el comportamiento de iOS no es el que debería ser:

  1. Cuando marcamos un archivo con estrella en Dropbox, Box, Spotify o similares, el archivo pasa a la caché. Pero cuando se desmarca, el espacio no se libera. asiersylvano argumenta que ése debería ser el comportamiento esperado.
  2. Existen aplicaciones, como Amazon Cloud, que guardan una caché de archivos enorme correspondiente a la información que hay en la nube… justo cuando lo que uno quiere es liberar espacio en el dispositivo utilizando la nube para descargar los datos bajo demanda.

El resto del artículo lo dedica a poner de relieve otros mecanismos por los que el espacio interno de nuestro dispositivo iOS puede mermar (actualizaciones, archivos “reservados” por otras funciones del sistema, descargas asociadas a compras in-app, o la lista de lectura offline de Safari).

La tesis principal es, pues, que el comportamiento de la caché de iOS, que guarda los datos de las aplicaciones para disponer de ellas cuando no hay acceso a internet, no es el que debería ser: esto es, debería ser posible borrar un elemento de la caché, o indicar que no se quiere que forme parte de la caché, para que se borre.

Veremos cuál es el comportamiento que debemos esperar de las aplicaciones iOS con respecto a los datos que guardan las aplicaciones, para poder gestionar mejor su almacenamiento.

iOS y datos de aplicaciones

Veremos ahora cómo ha tratado iOS a los datos que forman parte de las aplicaciones.

iPhone OS 2.0 a iPhone OS 4.x

En las primeras versiones de iOS (iPhone OS 2.0, con la App Store, es la primera versión que merece la pena considerar, ya que las aplicaciones del sistema, salvo la cámara, guardan poca información en local) los datos que generaban las aplicaciones siempre se guardaban con ellas… y sólo podían crecer.

Existían un par de directorios, /APLICACION/Cache y /APLICACION/tmp, dentro de las aplicaciones, que Apple recomendaba para guardar archivos temporales, pero no era obligatorio. El sistema no hacía copia de seguridad del contenido de esos directorios al conectar con iTunes (después de todo, una cache duplica contenido de otros sitios, y un archivo temporal se crea temporalmente, pero no es esencial, se puede reconstruir).

Así que hasta iOS 5, el contenido de las aplicaciones sólo podía crecer, y sólo podía disminuirse el tamaño reinstalando… preferiblemente desde una copia de seguridad. Por supuesto, las aplicaciones bien comportadas limpiaban periódicamente su directorio de caché o temporal.

iOS 5.x: el sistema empieza a gestionar el espacio

Con la llegada de iOS 5, debuta iCloud, y en particular las copias de seguridad en iCloud. Eso hace que Apple se ponga en contacto con los desarrolladores de aplicaciones que guardan gran cantidad de documentos en /APLICACION/Documents, como Instapaper o Dropbox: lo que está en /APLICACION/Documents debe ser contenido generado por el usuario.

Si se trata de contenido accesible de otra forma, o que la aplicación puede volver a generar, debe estar, obligatoriamente, en /APLICACION/Cache y /APLICACION/tmp. Pero además, el sistema se reserva el derecho de borrar el contenido de las carpetas /Cache y /tmp de cada aplicación si el dispositivo tiene poco espacio. Por ejemplo, si se instala una nueva aplicación, el sistema buscará archivos en dichas carpetas para eliminarlos.

El problema que eso generaba es que, ahora, aplicaciones como Instapaper o Dropbox podían encontrarse con que el sistema les obligaba a sacar los datos fuera de /APLICACION/Documents, pero que si los ponían en /APLICACION/Documents, el sistema podría borrarlos a discreción.

Eso generaba un problema de usabilidad: quiero usar Instapaper para llevarme artículos para leer… pero como los pone en /APLICACION/Cache, el sistema los borra. ¡Adiós lectura! Y lo mismo con archivos que quisiéramos tener a mano en Dropbox.

Para solucionar ese problema, a partir de iOS 5.0.1 las aplicaciones pueden marcar archivos en /APLICACION/Documents como do not back up (no hacer copia de seguridad). Los archivos que están en /APLICACION/Documents se respetan, pero puede que tampoco se copien ni se sincronicen si están marcados como do not back up.

Y a partir de iOS 5.1, se pueden marcar otros elementos también como do not back up, e incluso se recomienda una tercera carpeta, /APLICACION/Library/Application Support, utilizando el atributo mencionado anteriormente, para contenido como el que estamos hablando.

Podéis leer (en inglés) un muy buen resumen de esta situación, y su resolución con iOS 5.0.1, de la mano de Marco Arment.

Otra oportunidad de gestión del espacio son las aplicaciones/revistas de Newstand. En ese caso, todos los números pueden, potencialmente, borrarse del dispositivo en caso de que haya poco espacio en disco, pero se puede marcar el número actual como currentlyReadingIssue (número actualmente leyéndose), para que ese ejemplar no desaparezca.

Otra forma de que se incremente el espacio ocupado por las aplicaciones es la recepción de archivos, bien mediante iTunes, o bien mediante el envío entre aplicaciones.

El envío entre aplicaciones se realiza copiando los archivos en una carpeta /APLICACION/Documents/Inbox, y luego las aplicaciones pueden, bien mover el documento a /APLICACION/Documents, si el usuario va a modificarla, o a /APLICACION/Caches si se va a hacer algo que no sea editar el documento. Los documentos que están /APLICACION/Documents/Inbox sí entran también dentro de la copia de seguridad, y en principio el sistema no es capaz de borrarlos.

Por parte de iOS 6 no ha habido grandes cambios en la gestión de los archivos, pero iOS 7 incorporará AirDrop, y ese puede ser bien un nuevo “quebradero” de cabeza, o bien (al menos, la base de) una solución.

Siguiendo a un archivo entre aplicaciones

Así que supongamos que recibimos un mensaje de correo con un archivo adjunto que sea un vídeo (video.mp4), y queremos pasarlo a Dropbox.

  1. Mail genera una copia del adjunto (decodificando el mensaje de correo) dentro de /Mail.app/Library/Application Support.
  2. El usuario utiliza el botón de Abrir en… para seleccionar Dropbox.
  3. El sistema hace una copia del video.mp4 en Dropbox.app/Documents/Inbox, y lanza Dropbox con un URL vinculado con el vídeo.
  4. Para hacer la sincronización, Dropbox debería mover el vídeo de Dropbox.app/Documents/Inbox a /Dropbox.app/Library/Application Support, y utilizar dropboxd para que sincronice el archivo a la nube. (¿Por qué ese archivo debe pasar a /Dropbox.app/Library/Application Support? Porque mientras está subiendo al repositorio en nube de Dropbox, no debería poder borrarse. En ese directorio está más protegido de borrados que si estuviera en /Dropbox.app/Caches, mientras sube a Dropbox.) Otro destino podría ser /Dropbox.app/Documents, siempre que queden marcados como do not back up, pero dado que el usuario no crea archivos en Dropbox, según las guías de uso no deberían estar ahí.
  5. Una vez subido a Dropbox, la aplicación mueve video.mp4 a /Dropbox.app/Caches, donde el sistema (o el propio Dropbox, si se sobrepasa el tamaño asignado a su caché) podría borrarlo.
  6. Si marcamos video.mp4 como favorito, puede pasar de nuevo a /Dropbox.app/Library/Application Support, para que quede protegido de borrados.

En cualquier caso, es la aplicación que recibe (o genera) el archivo quien decide la política de gestión. La aplicación debe permitir borrar los archivos recibidos, y seguir las recomendaciones del sistema.

Lo que sí que podemos ver es que ahora tenemos dos copias de video.mp4: una en Mail, y otra en Dropbox. Si desde Dropbox la enviamos a VLC, por ejemplo, tendríamos una tercera copia.

¿Debería ser posible borrar la copia de Mail? Como es un archivo que se puede recuperar de un mensaje, no debe haber problema, y Mail lo hace. ¿La copia de Dropbox? Igualmente, porque Dropbox gestiona el tamaño de la caché en sus preferencias. ¿En VLC? Aquí ya tenemos unproblema: VLC no muestra ninguna información sobre qué tamaño de archivos va a guardar, así que podemos suponer que, para vídeos que vengan de un enlace externo, los descargará en /VLC.app/Caches o /VLC.app/Library/Application Support; lo mismo para los que recupere de Dropbox. Pero los que entren a través de compartir aplicaciones, irán a /VLC.app/Documents/Inbox, y aumentará el tamaño de la copia de seguridad, y su espacio no podrá ser reclamado por el sistema.

Puntos negros de iOS en la gestión de almacenamiento

Hemos visto que el sistema sí que tiene mecanismos para eliminar archivos sobrantes en caso de necesidad.

Entonces, ¿por qué no desaparece un archivo de Dropbox (el video.mp4 de nuestro ejemplo) en cuanto que lo he quitado de favoritos? Porque depende:

  1. del desarrollador;
  2. de dónde haya colocado el archivo, como hemos visto antes;
  3. de que realmente se necesite la memoria.

Cuando el sistema necesita espacio urgentemente, va a cada aplicación y borra, sistemáticamente, el contenido de sus directorios /APLICACION/Cache y /APLICACION/tmp, independientemente de las necesidades del usuario. No está clara la heurística que se utiliza (esto es, si empieza por los archivos más antiguos —menos utilizados—, o si lo hace por los más grandes, o por orden inverso de instalación…), pero se trata de una situación que se hace bajo demanda del sistema, entre otras cosas porque es una operación costosa en tiempo para el usuario.

Lo que no existe es la posibilidad de reclamar espacio de todas las aplicaciones. Debería ser posible (mediante un comando similar a la familia de comandos de Restablecer que viven en Ajustes) reclamar el espacio ocupado por Caches, en caso de que no nos importe que todo se tenga que volver a descargar de nuevo… porque la alternativa es que los usuarios vayan aplicación por aplicación, bien en el dispositivo iOS, o bien en iTunes, para borrar los documentos que hayan recibido… y luego cada aplicación tendrá su propia gestión.

Referencias


Viewing all articles
Browse latest Browse all 4

Latest Images

Trending Articles





Latest Images