Dans quelles conditions ART compacte-t-elle le terril ?

Question

Le compactage du tas est l'une des caractéristiques du runtime ART d'Android 5.0+, qui vise à réduire la fragmentation du tas. Un tas fragmenté peut devenir OutOfMemoryErrors Il est en effet possible qu'il n'y ait pas un seul bloc de mémoire libre contigu suffisamment grand pour répondre à vos besoins, même si le tas dispose globalement de suffisamment d'espace libre.

Je crois savoir que cela se produit lorsque l'application passe en arrière-plan, d'après les présentations des conférences de Google et autres. Cependant, la seule déclaration que je peux trouver à ce sujet dans la documentation dit :

Le compactage d'espace homogène est un compactage d'espace de liste libre à espace de liste libre qui se produit généralement lorsqu'une application est déplacée vers un état de processus imperceptible en pause. Les principales raisons de cette opération sont la réduction de l'utilisation de la RAM et la défragmentation du tas.

On ne sait pas exactement ce que signifie, techniquement, un "état de processus imperceptible en pause".

Supposons qu'une application n'a pas d'activité au premier plan pour le moment. Le développeur aurait-il pu faire quelque chose pour empêcher le compactage du tas pour le processus de cette application ? Par exemple, le fait d'avoir un service au premier plan bloque-t-il le compactage du tas ?

Answer 1

Assembler les pièces du puzzle.

D'après ce que j'ai pu déterminer, ART compacte tout ce qui est en pause pendant 2 à 3 secondes. Par pause, on entend que l'application n'est pas en cours d'exécution en arrière-plan, donc des activités, mais pas des services en cours d'exécution. Il compacte également à la volée, ou simultanément pendant que l'application est au premier plan.

Actuellement, l'événement qui déclenche le compactage du tas est le changement d'état du processus ActivityManager. Lorsqu'une application passe en arrière-plan, elle informe ART que l'état du processus n'est plus jank "perceptible". Cela permet à ART de faire des choses qui provoquent de longues pauses des threads de l'application, comme le compactage et la déflation des moniteurs.

Chet Hasse États :

Collecte des ordures
ART a amélioré la dynamique de la collecte des déchets. D'une part, ART est un collecteur mobile ; il est capable de compacter le tas lorsqu'une longue pause dans l'application n'a pas d'impact sur l'expérience de l'utilisateur (par exemple, lorsque l'application est en arrière-plan et ne joue pas de musique). De plus, il existe un tas distinct pour les gros objets tels que les bitmaps, ce qui permet de trouver plus rapidement de la mémoire pour ces gros objets sans avoir à patauger dans le tas régulier potentiellement fragmenté. Les pauses dans ART sont régulièrement de l'ordre de 2-3 ms.

D'après ce que je peux voir, toute pause dans l'application est un jeu d'enfant pour l'ART GC.

Je soupçonne que l'application doit être complètement mise en pause de tous les services, etc. pour que le compactage se produise, car elle réalloue les adresses mémoire du tas, et pour que cela se produise, elle ne peut pas être en train de changer. Pour que cela se produise, les adresses mémoire du tas sont réallouées, et pour que cela se produise, elles ne peuvent pas être modifiées. Les seuls changements qui peuvent être effectués pendant les petites pauses sont le réacheminement de certaines adresses sur les processus qui ne sont plus utilisés.

Bien qu'il s'agisse d'une supposition éclairée, non définitive, je m'efforcerai d'obtenir plus d'informations.

Le site le code source ici devrait avoir la réponse . Ils utilisent des noms comme InJankPerceptibleProcessState() et j'essaie de m'y retrouver, comme vous l'avez probablement déjà fait vous-même.

Je le lis, je mettrai à jour la réponse quand/si je trouve la réponse définitive.

Answer 2

Le compactage d'espace homogène est un compactage d'espace de liste libre en espace de liste libre qui se produit généralement lorsqu'une application est déplacée vers un état de processus imperceptible en pause. Les principales raisons de cette opération sont la réduction de l'utilisation de la RAM et la défragmentation du tas.

Source : https://developer.Android.com/studio/profile/investigate-ram.html#LogMessages

Answer 3

En fait, vous pouvez mesurer le temps d'inactivité d'une application en Lancez le minuteur d'inactivité et arrêtez s'il y a un événement capturé dans TextWatcher/OnKeylistner, si votre application est en arrière-plan et qu'aucun de ces événements n'est appelé, il est bon d'être collecté par GC.

De plus, cette contraction du tas est basée sur des événements et des priorités. Par exemple, s'il n'y a jamais de scénario où l'utilisateur a besoin de mémoire, le système d'exploitation ne le fera même pas.

En ce qui concerne la priorité, pour le ramassage des ordures, il cherche les applications d'arrière-plan sans service d'arrière-plan, puis les applications avec service d'arrière-plan et enfin les applications d'avant-plan.