Réponse courte
Les widgets ne fonctionnent pas de manière autonome, comme le font les applications normales. Le widget hôte (c'est-à-dire l'application de l'écran d'accueil ou de l'écran de verrouillage) est chargé de dessiner tous les widgets. Le widget fournisseur (partie de l'application) indique à l'hôte la disposition à donner à chaque widget et la fréquence à laquelle il souhaite que le widget soit mis à jour. Il n'y a rien en cours d'exécution à "suspendre", que le widget soit visible ou non.
Coût des ressources
Si le widget ne "fonctionne" pas, il doit néanmoins être affiché à l'écran. Chaque widget rend donc le processus hôte (c'est-à-dire le lanceur) un peu plus coûteux en utilisation du CPU et de la mémoire. Chaque fois que le widget est redessiné (lorsqu'il change, ou lorsque l'écran d'accueil s'anime), ce redessin utilise quelques cycles CPU supplémentaires. De plus, une fois que le fournisseur a indiqué à l'hôte la disposition à utiliser, l'hôte doit utiliser la RAM pour se souvenir de la disposition du widget. Comme c'est l'hôte qui stocke ces informations et qui dessine le widget, cela compte dans l'utilisation de la batterie et l'empreinte mémoire de l'hôte, et non de l'application. Le coût dépend de l'hôte (c'est-à-dire du lanceur que vous utilisez), ainsi que de la complexité de la disposition.
Pour cette raison, Android impose des limites strictes à la complexité de la mise en page de chaque widget, ainsi qu'à la taille totale de toutes les images utilisées dans le widget. La limite dépend de la taille en pixels de l'écran, donc sur un écran de type nexus-10 c'est énorme. Si vous avez beaucoup de widgets, utilisant tous de grandes images ou des mises en page complexes, le processus du lanceur peut prendre beaucoup de mémoire, et il est donc plus probable qu'il soit tué pendant que vous exécutez une application au premier plan. Il est donc plus probable qu'il soit tué pendant que vous exécutez une application au premier plan. Cela aurait pour effet de provoquer un court retard lors de l'affichage de l'écran d'accueil.
Services
Bien sûr, il est également possible qu'un arrière-plan service pour continuer à donner à l'hôte (écran d'accueil) une nouvelle disposition pour le widget. C'est ainsi qu'un widget de courrier électronique, par exemple, peut être mis à jour lorsque vous recevez de nouveaux messages. Un tel service fonctionnerait que le widget soit affiché ou non : il n'y a aucun moyen pour le service de le savoir.
Par exemple, si vous avez un widget de courrier électronique, le service de courrier électronique normal doit fonctionner à intervalles réguliers pour vérifier le courrier et mettre à jour le widget au cours de son exécution normale s'il y a un nouveau courrier. Dans ce cas, le seul coût du widget est le petit coût à l'intérieur de l'hôte, car le service fonctionnerait de toute façon pour synchroniser votre courrier en arrière-plan.
Le fait d'avoir une liste tournante (comme dans votre exemple) ne devrait pas en soi vous faire penser qu'il y a un service qui tourne en permanence en arrière-plan, pour cette raison :
Listes et bannières rotatives
L'interface que les fournisseurs de widgets utilisent pour spécifier ce que doit être la mise en page leur permet de donner une liste d'éléments. Par exemple, il peut s'agir d'une liste de messages électroniques ou d'une liste de rendez-vous dans le calendrier, que vous pouvez faire défiler. Le fournisseur peut également faire tourner l'écran d'accueil dans la liste automatiquement. Le widget YouTube utilise cette fonction, par exemple, pour que le widget puisse continuer à afficher de nouvelles vidéos sans que le fournisseur ait à modifier la mise en page. Si votre widget utilise cette fonction, l'écran d'accueil n'exécute un code supplémentaire que lorsqu'il est temps de faire tourner la liste.
Quel est le coût le plus important ?
Le coût en ressources d'un widget normal (c'est-à-dire un widget qui n'a pas une mise en page extrêmement compliquée et qui n'utilise pas d'énormes bitmaps) est minuscule comparé au coût d'un service d'arrière-plan pour le mettre à jour avec de nouvelles informations. Pour reprendre l'exemple des offres quotidiennes d'EA, vous n'avez pas à vous soucier de la rotation du widget, mais plutôt de la manière dont les offres quotidiennes sont mises à jour. Le service fonctionne-t-il en permanence, ou toutes les quelques minutes, ou bien une fois par jour pour récupérer les nouvelles offres ? S'arrête-t-il de lui-même s'il n'y a pas de connexion Internet ? Est-ce qu'il réveille l'appareil pour effectuer une mise à jour ? Ce sont toutes des choses que l'auteur de l'application a dû programmer et que les utilisateurs ne peuvent pas contrôler (et n'ont pas besoin de connaître directement), mais elles ont un effet beaucoup plus important sur le coût du widget que tout ce que fait le lanceur.
TL;DR
Dessiner des widgets, même des widgets rotatifs, est bon marché : trop bon marché pour en mesurer le coût. Le coût réel est celui de l'application qui tourne en arrière-plan pour mettre à jour le widget avec de nouvelles données. La fréquence d'exécution de cette application dépend de l'application, et ne dépend pas de l'affichage du widget à un moment donné.
