Aller au contenu
Retour au blog

Exploitation#multi-appareils#matériel#performance

Dix appareils Android sur un seul PC : où sont vraiment les goulots

Bande passante USB, décodage vidéo, CPU et RAM — ce qui limite réellement un parc multi-appareils, et les réglages qui récupèrent le plus de marge.

Par AppsMobs6 min de lecture

Passer d'un téléphone à trois est facile. De trois à dix, c'est là qu'on découvre que le goulot n'a jamais été le logiciel.

Voici ce qui limite réellement un montage multi-appareils, dans l'ordre où vous rencontrerez les limites, et quoi faire pour chacune.

1. Le bus USB, bien avant le nombre de ports

Un contrôleur USB 3.0 annonce 5 Gb/s. Ce chiffre vaut par contrôleur, pas par port, et une carte mère expose typiquement six à dix ports depuis deux ou trois contrôleurs. Brancher un hub dix ports sur un seul port, c'est dix appareils qui se partagent la bande passante d'un contrôleur et, surtout, sa gestion d'interruptions.

Le flux d'écran est la partie gourmande. Un flux H.264 en 1080p/30 à 4 Mb/s est modeste ; dix, c'est 40 Mb/s, ce qui n'est rien pour le bus. Le problème n'est pas le débit mais le coût par transaction : chaque clic, chaque demande de capture, chaque battement de cœur est un petit transfert, et ce sont les petits transferts qui mettent à genoux un contrôleur partagé.

Ce qui aide, par ordre d'efficacité :

  • Répartir les appareils sur plusieurs contrôleurs. Utilisez les ports avant et arrière, et une carte PCIe USB pour le reste. usbview sous Windows montre quel port dépend de quel contrôleur.
  • Utiliser des hubs alimentés. Dix téléphones qui se chargent à travers un hub non alimenté finiront par faire chuter la tension, et un appareil qui redémarre en plein run ressemble exactement à un bug dans votre script.
  • Basculer une partie en ADB Wi-Fi. adb tcpip 5555 les sort complètement du bus. La latence monte de quelques millisecondes et vous l'échangez contre de la marge sur le bus — un bon marché pour les appareils que vous ne regardez pas. Précision : AppsMobs ne propose pas lui-même de connexion Wi-Fi (il détecte les appareils branchés en USB, plus LDPlayer), ce conseil vaut donc pour un pilotage ADB à la main.

2. Le décodage vidéo côté PC

Chaque écran en direct est un flux vidéo que votre PC doit décoder et afficher. Dix flux 1080p à 60 FPS, c'est 600 trames décodées par seconde, de quoi occuper entièrement un processeur milieu de gamme à ne rien faire d'utile.

Le correctif est presque gratuit, puisque vous ne regardez pas neuf de ces écrans :

  • Les appareils d'arrière-plan à 5 FPS et 1 Mb/s, parfaitement suffisant pour voir que ça tourne encore
  • L'appareil que vous observez à 30–60 FPS
  • Une résolution maximale abaissée (720 px suffisent pour voir que ça tourne), pour que le flux soit moins coûteux à décoder

Ce seul changement — un FPS par appareil plutôt qu'un réglage global (AppsMobs le permet dans les Paramètres, avec images par seconde, débit et résolution réglables appareil par appareil) — fait souvent la différence entre une grille de dix appareils qui saccade et une qui ne saccade pas.

3. Le CPU, et ce qui le mange vraiment

Un budget réaliste par appareil, sur un processeur milieu de gamme actuel :

TravailCoût par appareil
Décodage à 5 FPS~2 % d'un cœur
Décodage à 60 FPS~15 % d'un cœur
Exécution de script (attentes)négligeable
Template matching à 1 Hz~5 % d'un cœur
Inférence YOLO nano à 1 Hz, CPU~15 % d'un cœur
Inférence YOLO nano à 1 Hz, GPU~1 % d'un cœur

Dix appareils en FPS réduit avec du template matching tiennent confortablement sur six cœurs. Dix appareils avec de l'inférence en direct sur CPU, non — c'est là que le GPU cesse d'être facultatif. Notez aussi que la fréquence d'interrogation compte plus que la taille du modèle : passer un détecteur de 5 Hz à 1 Hz, c'est 5× d'économie, et c'est presque toujours suffisant, parce que ce que vous attendez n'apparaît pas puis disparaît en une seconde.

4. La RAM, plus simple

Comptez environ :

  • 300 à 500 Mo par flux 1080p en direct
  • 1 à 2 Go pour l'application hôte elle-même
  • 2 à 4 Go si vous entraînez un modèle de vision pendant que les appareils tournent

Donc : 8 Go, c'est une machine à deux appareils ; 16 Go tiennent cinq à dix sans souci ; 32 Go, c'est ce qu'il faut si vous entraînez des modèles sur la machine qui fait tourner le parc.

5. Ce que personne ne budgète : la chaleur

Dix téléphones à 100 % de CPU, en charge par USB, empilés sur une étagère, vont throttler thermiquement en moins d'une heure. Un appareil bridé exécute votre boucle de 4 minutes en 6, et votre modèle de débit devient silencieusement faux.

Un ventilateur de bureau dirigé vers le rack est l'achat le plus rentable de tout cet article. Espacer les appareils pour qu'ils ne se touchent pas arrive juste derrière.

À quoi ressemble vraiment la courbe de montée en charge

Une montée en charge parfaite voudrait dire que dix appareils font dix fois le travail d'un seul. En pratique, la contention du bus, le CPU hôte et les réessais prennent une part qui grandit avec le nombre d'appareils — autour de 25 à 30 % une fois à dix, sur un montage typique.

Cela reste sept fois le débit d'un appareil seul, ce qui est bien l'intérêt. Mais un plan de capacité bâti sur « dix appareils × quinze passages par heure = 150 » sera faux d'une quarantaine de passages, et cet écart compte si vous promettez un chiffre quotidien à quelqu'un.

Mesurez votre propre courbe : faites tourner un appareil pendant une heure, puis cinq, puis dix, et notez les passages terminés. Vingt minutes de mesure valent mieux qu'un tableur d'hypothèses.

Les émulateurs changent l'arithmétique

Si votre app cible tourne en émulateur, dix instances LDPlayer (le seul émulateur qu'AppsMobs gère explicitement ; pour les autres, la connexion passe par ADB et n'est pas vérifiée) sur un PC costaud évitent complètement le problème USB — il n'y a plus de bus, seulement de la RAM et du CPU. Comptez 2 Go et environ un cœur par instance, et le calcul devient simple.

En échange, certaines apps détectent les émulateurs et refusent de démarrer, et les capteurs, caméras et comportements tactiles émulés sont des approximations. Pour la QA et la plupart des boucles de récompense, l'émulateur est la voie la plus simple. Pour tout ce qui vérifie, l'appareil physique est la seule voie.

Une configuration qui tient

Si vous montez une machine spécifiquement pour ça :

  • Processeur : 6 à 8 cœurs récents. Au-delà de huit, la fréquence compte plus que le nombre de cœurs.
  • Mémoire : 32 Go. C'est bon marché et ça supprime toute une catégorie de problèmes.
  • Carte graphique : n'importe quelle NVIDIA récente avec CUDA, si vous comptez entraîner ou faire de l'inférence en direct.
  • USB : une carte PCIe USB 3.x à contrôleurs séparés, plus des hubs alimentés.
  • Stockage : un SSD. Les logs de captures de dix appareils s'accumulent plus vite qu'on ne croit.
  • Refroidissement : un ventilateur pour les téléphones, pas seulement pour le PC.

Rien d'exotique là-dedans, et tout cela compte davantage que l'outil d'automatisation que vous ferez tourner par-dessus. Pour brancher et vérifier chaque appareil, voir Brancher un téléphone ou un émulateur.

Arrête de lire comment faire. Automatise-le.

Tout ce qui est dans cet article fonctionne tel quel dans AppsMobs.