Utilisation d'Android: processus
J'ai ce fichier AndroidManifest.xml:
<manifest xmlns:Android="http://schemas.Android.com/apk/res/Android"
Android:versionCode="1" Android:versionName="1.0.0.0721"
Android:process="com.lily.process" package="com.lily.test">
<provider Android:authorities="com.lily.test"
Android:name="com.lily.test.provider"
Android:process="com.lily.process">
</provider>
"Android: processus" est ajouté à la fois en tant que balise manifeste et balise de fournisseur, je sais que s'il est ajouté en tant que balise de fournisseur, le fournisseur peut être exécuté dans le processus "com.lily.process". Mais à quoi ça sert quand il est écrit comme une balise manifeste? J'ai essayé, mais tous les composants ne pouvaient pas fonctionner dans le processus identifié.
Je conviens que peu de gens trouveraient Android: processus utile comme attribut de la balise d'application. Cependant, je l'ai trouvé utile comme attribut de la balise activité.
Le but de Android:process sur une activité consiste à spécifier que votre activité doit être lancée dans un processus portant un nom spécifique. Le choix de ce nom peut être utilisé soit pour isoler l'activité dans son propre processus (différent de celui qui l'a lancée), soit pour la forcer à cohabiter en un seul processus avec d'autres activités qui utilisent le même nom.
Selon le guide du développeur ( http://developer.Android.com/guide/topics/manifest/activity-element.html ):
"Si le nom attribué à cet attribut commence par deux points (':'), un nouveau processus, privé de l'application, est créé lorsque cela est nécessaire et l'activité s'exécute dans ce processus. Si le nom du processus commence par un caractère en minuscule, l'activité s'exécutera dans un processus global de ce nom, à condition qu'il y soit autorisé. Cela permet aux composants de différentes applications de partager un processus, ce qui réduit l'utilisation des ressources. "
J'ai récemment trouvé cet attribut utile pour résoudre un problème rencontré lors du lancement d'une activité d'aide pour une application qui, dans certaines circonstances, était assez proche de la limite de segment de 16 Mo qui s'applique toujours à certains appareils. Le lancement de son activité d'aide a, dans ces situations, poussé mon application au-dessus de la limite, ce qui a entraîné une fermeture forcée.
En utilisant le Android:process tag, j'ai pu spécifier que mon activité d'aide devait être lancée dans un processus distinct. Ce processus avait son propre segment de mémoire de 16 Mo, et il n'était pas pris en compte dans le segment de mémoire de mon application principale qui l'avait lancé. Cela a empêché définitivement et complètement mon application de manquer d'espace de stockage et de se bloquer lorsque l'aide a été lancée.
Si votre application de lancement a le nom du package
com.mycompany.mymainapp
et se voit donc attribuer un nom de processus qui est la même chaîne, puis, si vous utilisez
Android:process=":myhelp"
sur votre activité lancée, le nom du processus lui sera attribué
com.mycompany.mymainapp:myhelp
et ce processus aura son propre ID de processus distinct, que vous pouvez afficher (par exemple dans DDMS).
C'est du moins mon expérience. Jusqu'à présent, mes tests ont été effectués sur un ancien Moto Droid exécutant CM6 (Android 2.2.1), configuré pour avoir une limite de tas de 16 Mo.
Dans mon cas, comme je ne voulais pas que l'utilisateur perçoive l'aide comme distincte de mon application, j'ai inclus le
Android:excludeFromRecents="true"
pour empêcher l'activité d'aide d'apparaître dans la liste des applications récentes (appui long sur Accueil). J'ai aussi inclus
Android:taskAffinity="com.mycompany.mymainapp.HelpActivity"
où HelpActivity est le nom de l'activité d'aide, pour séparer l'activité dans sa propre tâche
J'ai également ajouté:
Android:launchMode="singleInstance"
pour empêcher la création de plusieurs instances de cette application à chaque fois que l'utilisateur a appelé l'aide.
J'ai également ajouté le drapeau:
Intent.FLAG_ACTIVITY_NEW_TASK
à l'intention utilisée pour lancer l'activité d'aide.
Ces paramètres peuvent être nécessaires ou non, selon l'utilisation que vous faites du Android:process attribut.
Considérant la fréquence à laquelle on rencontre des limites de mémoire lors du développement pour les appareils Android, ayant une technique qui peut, dans certains cas, vous permettre de diviser des parties de votre application en processus séparés, chacun avec son propre tas , semble être un cadeau merveilleux. Il peut y avoir des dangers cachés en faisant cela que je n'ai pas encore envisagé ou expérimenté, mais jusqu'ici, tout va bien, dans mon cas particulier.
@Carl
Il peut y avoir des dangers cachés:
- La mémoire ne peut pas être libérée Lorsqu'il existe un service en arrière-plan (par exemple: Android: process = ": myhelp") dans le même processus.
- Le motif singleton ne peut pas être utilisé.
Réf: http://developer.Android.com/training/articles/memory.html#MultipleProcesses
Le processus a maintenant presque triplé, à 4 Mo, simplement en affichant du texte dans l'interface utilisateur. Cela conduit à une conclusion importante: si vous allez diviser votre application en plusieurs processus, un seul processus devrait être responsable de l'interface utilisateur. Les autres processus devraient éviter toute interface utilisateur, car cela augmentera rapidement le RAM requis par le processus (en particulier une fois que vous commencez à charger les actifs bitmap et d'autres ressources). Il peut alors être difficile ou impossible de réduire la l'utilisation de la mémoire une fois l'interface utilisateur dessinée.
Android: process et shareduserid peuvent être utilisés pour transmettre des ressources entre les packages. Dans mon cas, cela devient pratique maintenant :)
Exemple de code source: https://github.com/ikust/hello-sharedprocess
Android: le processus doit être utilisé avec prudence
(Citation du lien ci-dessous)
Un comportement peu connu et apparemment non documenté de Android est que chaque processus d'une application possède sa propre instance d'application.
Donc, si vous avez un service qui s'exécute dans un processus différent, l'appel à startService () lancera la classe Appplication pour votre application.
Plus d'informations - Démarrage du service dans Android appelle Applications onCreate