Guide d'émulation d'appareil : profils mobile, tablette et bureau
Comment émuler des identités d'appareils complètes incluant les événements tactiles, les métriques d'écran et le UA mobile pour des profils mobiles et bureau authentiques.
Vous préférez la doc produit maintenue ?
Cet article a une page équivalente dans le centre de documentation. Utilisez les docs pour le flux canonique, les flags à jour et la référence durable.
Introduction
Un navigateur révèle son appareil à travers des dizaines de signaux : dimensions de l'écran, ratio de pixels de l'appareil, capacités tactiles, mémoire de l'appareil, caractéristiques GPU, modalités d'entrée, et plus encore. Ces signaux forment une image cohérente de l'appareil physique exécutant le navigateur. Un Pixel 7 a des dimensions d'écran spécifiques, un DPR spécifique, un nombre spécifique de points de contact, un GPU spécifique et une mémoire spécifique. Lorsque ces signaux sont cohérents, le navigateur semble fonctionner sur du vrai matériel. Lorsqu'ils sont contradictoires, l'incohérence est visible.
BotBrowser charge des profils d'appareils complets capturés depuis du vrai matériel. Lorsqu'un profil mobile est chargé sur un système de bureau, tous les signaux de l'appareil se mettent à jour de manière cohérente car ils proviennent tous du même appareil source. Il n'y a pas de combinaison disparate, pas de configuration manuelle de propriétés individuelles et aucun risque de conflit de signaux.
Impact sur la vie privée : pourquoi les signaux d'appareil comptent
L'émulation d'appareil est importante pour plusieurs raisons au-delà de simplement apparaître comme un navigateur mobile ou de bureau.
Les systèmes de suivi utilisent les signaux d'appareil dans leur processus de fingerprinting. La combinaison de la résolution d'écran, du DPR, du support tactile, de la mémoire de l'appareil, du renderer GPU et du nombre de coeurs CPU crée une empreinte au niveau de l'appareil qui persiste entre les sessions. Contrôler ces signaux est nécessaire pour maintenir des identités de navigateur cohérentes et pour étudier comment les systèmes de suivi utilisent les caractéristiques de l'appareil.
Les plateformes de commerce en ligne et de contenu servent des expériences différentes selon l'appareil détecté. Les utilisateurs mobiles peuvent voir des prix différents, des mises en page différentes et des sélections de contenu différentes. Les chercheurs en confidentialité ont besoin d'une émulation précise de l'appareil pour étudier ces pratiques de manière fiable.
Pour la gestion multi-comptes, la diversité des appareils est importante. Avoir chaque identité qui se présente comme le même modèle d'appareil avec des dimensions d'écran identiques est suspect. Utiliser une variété de profils d'appareils, en mélangeant bureau et mobile, différentes tailles d'écran et différentes valeurs DPR, crée une variation naturelle.
Contexte technique
Signaux d'appareil dans le navigateur
Le navigateur expose les caractéristiques de l'appareil via plusieurs API :
Dimensions de l'écran : screen.width, screen.height, screen.availWidth, screen.availHeight rapportent la taille physique de l'affichage. window.innerWidth et window.innerHeight rapportent le viewport. window.outerWidth et window.outerHeight incluent le chrome du navigateur.
Ratio de pixels de l'appareil : window.devicePixelRatio rapporte le ratio entre les pixels CSS et les pixels physiques. Les écrans de bureau ont typiquement un DPR de 1.0 ou 1.25. Les appareils mobiles vont de 2.0 à 3.5 ou plus. Les MacBooks Retina rapportent 2.0.
Capacités tactiles : navigator.maxTouchPoints rapporte le nombre maximum de points de contact simultanés (0 pour le bureau, 5-10 pour le mobile). La disponibilité du gestionnaire d'événement ontouchstart sur l'objet window indique le support tactile. Les media queries CSS (pointer: coarse) et (hover: none) distinguent les entrées tactiles des entrées par pointeur.
Mémoire de l'appareil : navigator.deviceMemory rapporte la RAM approximative en Go. Les appareils mobiles rapportent typiquement 4-8 Go, les postes de bureau 8-16 Go.
Parallélisme matériel : navigator.hardwareConcurrency rapporte le nombre de coeurs CPU disponibles. Les appareils mobiles rapportent typiquement 4-8, les postes de bureau 4-16 ou plus.
Informations de connexion : navigator.connection fournit le type de réseau, le type effectif, la vitesse descendante et le RTT. Les appareils mobiles rapportent souvent des caractéristiques réseau différentes des systèmes de bureau.
GPU : La chaîne du renderer WebGL identifie le matériel graphique. Les GPU mobiles (Adreno, Mali, PowerVR, Apple GPU) diffèrent complètement des GPU de bureau (NVIDIA GeForce, AMD Radeon, Intel UHD).
Exigences de cohérence des signaux
Ces signaux doivent être cohérents entre eux. Un navigateur rapportant maxTouchPoints: 10 mais (pointer: fine) et (hover: hover) contient une contradiction. Un navigateur avec un écran de 412 px de large mais 16 Go de mémoire et un GPU NVIDIA combine des dimensions d'écran mobiles avec des caractéristiques matérielles de bureau. Ces incohérences montrent clairement que des signaux individuels ont été usurpés plutôt que provenant d'un vrai appareil.
Approches courantes et leurs limitations
Émulation d'appareil Chrome DevTools
Le Chrome DevTools Protocol fournit l'émulation d'appareil via Emulation.setDeviceMetricsOverride. Cela définit les dimensions du viewport, le DPR et le support tactile. Playwright et Puppeteer exposent cela via leurs API d'émulation d'appareil.
Limitations :
- Ne change pas
navigator.platformni les données User-Agent au-delà de ce qui est explicitement défini - Les chaînes du renderer WebGL rapportent toujours le GPU de bureau
navigator.deviceMemoryetnavigator.hardwareConcurrencyrestent aux valeurs de bureau- L'émulation tactile est superficielle, pas au niveau du moteur
- La disponibilité des polices reste spécifique au bureau
- Les media queries peuvent ne pas s'aligner complètement avec l'appareil émulé
Remplacements manuels de propriétés
Vous pouvez remplacer des propriétés individuelles via l'injection JavaScript :
Object.defineProperty(navigator, 'maxTouchPoints', { get: () => 10 });
Object.defineProperty(navigator, 'deviceMemory', { get: () => 4 });
Cela change les valeurs visibles par JavaScript mais n'affecte pas le comportement réel du navigateur. Les media queries CSS, le comportement du pipeline de rendu et les en-têtes HTTP ne sont pas affectés par les remplacements de propriétés JavaScript.
Approches viewport uniquement
Définir une taille de viewport mobile (par ex., 412x915) via le framework d'automatisation change la mise en page mais ne change aucun autre signal d'appareil. Le navigateur rapporte toujours les dimensions d'écran de bureau, le DPR de bureau, zéro point de contact et les informations GPU de bureau.
L'approche de BotBrowser
Les profils BotBrowser sont capturés depuis de vrais appareils, ce qui signifie que tous les signaux d'appareil proviennent du même matériel physique. Lorsqu'ils sont chargés sur n'importe quel système, ces signaux sont appliqués ensemble au niveau du moteur, assurant une cohérence interne complète.
Identité d'appareil basée sur le profil
Chaque profil contient un instantané des caractéristiques de l'appareil :
- Dimensions de l'écran (largeur, hauteur, largeur disponible, hauteur disponible)
- Ratio de pixels de l'appareil
- Capacités tactiles (maxTouchPoints, support des événements tactiles)
- Mémoire de l'appareil
- Parallélisme matériel
- Chaînes de renderer et de vendeur GPU
- Propriétés navigator spécifiques à la plateforme
- Dimensions du chrome de la fenêtre (pour calculer les dimensions extérieures)
Tous ces signaux sont appliqués en tant qu'unité, pas individuellement. Cela élimine le risque de conflits de signaux.
Support tactile au niveau du moteur
Lorsqu'un profil mobile est chargé, le support tactile est activé au niveau du moteur Chromium, pas via l'injection JavaScript :
navigator.maxTouchPointsretourne la vraie valeur de l'appareilontouchstartest nativement disponible sur l'objet window- Les media queries CSS
(pointer: coarse)et(hover: none)s'évaluent correctement dans le moteur de style - Les constructeurs et propriétés des événements tactiles se comportent exactement comme sur le vrai appareil
- L'API
InputDeviceCapabilitiesrapporte correctement le tactile
Profils bureau, mobile et tablette
BotBrowser supporte des profils de toutes les catégories d'appareils :
Profils bureau : Grands écrans (1920x1080, 2560x1440), DPR de 1.0-2.0, zéro point de contact, pointeur fin, GPU de bureau, 8-16 Go de mémoire.
Profils mobiles : Petits écrans (412x915, 390x844), DPR de 2.0-3.5, support tactile avec 5-10 points, pointeur grossier, GPU mobile, 4-8 Go de mémoire.
Profils tablettes : Écrans moyens (1024x1366, 820x1180), DPR de 2.0, support tactile, parfois pointeur à la fois grossier et fin, GPU mobile ou intégré.
Configuration de la fenêtre et de l'écran
BotBrowser fournit un contrôle précis des propriétés de fenêtre et d'écran via les flags CLI :
# Utiliser les dimensions capturées du profil (par défaut pour headless)
--bot-config-window=profile
--bot-config-screen=profile
# Dimensions spécifiques
--bot-config-window=1920x1080
--bot-config-screen=2560x1440
# Personnalisation JSON complète
--bot-config-window='{"innerWidth":1920,"innerHeight":1080,"devicePixelRatio":2}'
Configuration et utilisation
Profil d'appareil mobile
chrome --bot-profile="/profiles/pixel7-chrome-130.enc" \
--user-data-dir="$(mktemp -d)"
Intégration Playwright
const { chromium } = require('playwright-core');
(async () => {
const browser = await chromium.launch({
executablePath: '/path/to/botbrowser/chrome',
args: [
'--bot-profile=/profiles/pixel7-chrome-130.enc',
],
headless: true,
});
// Important : ne pas définir le viewport - laisser le profil le contrôler
const context = await browser.newContext();
const page = await context.newPage();
const metrics = await page.evaluate(() => ({
screenWidth: screen.width,
screenHeight: screen.height,
innerWidth: window.innerWidth,
innerHeight: window.innerHeight,
dpr: devicePixelRatio,
touchPoints: navigator.maxTouchPoints,
touchStart: 'ontouchstart' in window,
pointer: matchMedia('(pointer: coarse)').matches ? 'coarse' : 'fine',
hover: matchMedia('(hover: none)').matches ? 'none' : 'hover',
memory: navigator.deviceMemory,
cores: navigator.hardwareConcurrency,
}));
console.log('Device metrics:', metrics);
await browser.close();
})();
Puppeteer avec profil bureau
const puppeteer = require('puppeteer-core');
(async () => {
const browser = await puppeteer.launch({
executablePath: '/path/to/botbrowser/chrome',
args: [
'--bot-profile=/profiles/win11-desktop-1080p.enc',
],
headless: true,
defaultViewport: null, // Laisser le profil contrôler le viewport
});
const page = await browser.newPage();
await page.goto('https://example.com');
await browser.close();
})();
Taille de fenêtre personnalisée avec profil
# Remplacer uniquement la taille de la fenêtre, garder tout le reste du profil
chrome --bot-profile="/profiles/win11-chrome-130.enc" \
--bot-config-window=1440x900 \
--bot-config-screen=1920x1080
Vérification
Vérifiez l'émulation d'appareil en contrôlant l'ensemble des signaux d'appareil :
const page = await context.newPage();
await page.goto('https://example.com');
const deviceCheck = await page.evaluate(() => ({
// Écran
screen: {
width: screen.width,
height: screen.height,
availWidth: screen.availWidth,
availHeight: screen.availHeight,
},
// Fenêtre
window: {
innerWidth: window.innerWidth,
innerHeight: window.innerHeight,
outerWidth: window.outerWidth,
outerHeight: window.outerHeight,
dpr: window.devicePixelRatio,
},
// Tactile
touch: {
maxTouchPoints: navigator.maxTouchPoints,
ontouchstart: 'ontouchstart' in window,
pointerCoarse: matchMedia('(pointer: coarse)').matches,
hoverNone: matchMedia('(hover: none)').matches,
},
// Matériel
hardware: {
deviceMemory: navigator.deviceMemory,
hardwareConcurrency: navigator.hardwareConcurrency,
},
}));
console.log('Device verification:', JSON.stringify(deviceCheck, null, 2));
Bonnes pratiques
- Utilisez toujours
defaultViewport: nulldans Playwright et Puppeteer. Cela laisse le profil contrôler les dimensions du viewport. Les paramètres de viewport du framework remplacent les valeurs du profil, cassant la cohérence. - Choisissez des profils d'appareils qui correspondent à votre cas d'utilisation. Pour l'automatisation web générale, utilisez des modèles d'appareils courants. Pour les tests mobiles, utilisez des profils de modèles de téléphones populaires.
- Ne mélangez pas les remplacements manuels avec les profils. Laissez le profil contrôler l'identité complète de l'appareil. Les remplacements manuels (comme définir un viewport personnalisé sur un profil mobile) risquent de créer des incohérences de signaux.
- Vérifiez toutes les catégories de signaux. Contrôlez les signaux d'écran, tactiles, matériels et GPU ensemble, pas individuellement.
- Utilisez
--bot-config-windowet--bot-config-screenpour des remplacements contrôlés. Lorsque vous avez besoin de dimensions spécifiques, ces flags ajustent les propriétés d'affichage tout en gardant tous les autres signaux cohérents. - Faites correspondre l'appareil au cas d'utilisation. Pour les tests e-commerce, utilisez des profils de téléphones grand public. Pour les tests d'entreprise, utilisez des profils de bureau avec des résolutions de moniteur de bureau typiques.
Questions fréquemment posées
BotBrowser génère-t-il de vrais événements tactiles ?
BotBrowser active le support tactile au niveau du moteur, ce qui signifie que maxTouchPoints, ontouchstart et les media queries CSS rapportent tous correctement. Pour générer des séquences d'événements tactiles (tap, balayage, pincement), utilisez les API d'entrée tactile de votre framework d'automatisation. Playwright fournit page.touchscreen.tap() et Puppeteer fournit des méthodes similaires.
Que se passe-t-il si je définis un viewport dans Playwright avec un profil mobile ?
Définir un viewport via Playwright ou Puppeteer remplace les dimensions de fenêtre du profil. Cela peut créer des incohérences entre innerWidth/innerHeight (définis par le framework) et screen.width/screen.height (définis par le profil). Utilisez defaultViewport: null pour éviter cela.
Puis-je personnaliser les dimensions de l'écran tout en conservant les autres signaux de l'appareil ?
Oui. Utilisez --bot-config-window et --bot-config-screen pour remplacer les dimensions d'affichage tout en conservant les signaux tactiles, de mémoire, GPU et autres du profil.
Comment fonctionne devicePixelRatio avec les captures d'écran ?
Lors de la prise de captures d'écran, les dimensions réelles en pixels de l'image sont largeur * devicePixelRatio par hauteur * devicePixelRatio. Un viewport mobile de 412 px de large avec un DPR de 2.625 produit des captures d'écran de 1081 pixels de large.
Les profils tablettes ont-ils le support tactile ?
Oui. Les profils tablettes incluent le support tactile (typiquement maxTouchPoints: 10) ainsi que des dimensions d'écran et des valeurs DPR appropriées aux tablettes.
Puis-je utiliser différents profils d'appareil pour différents contextes dans le même navigateur ?
Les caractéristiques de l'appareil sont définies au niveau de l'instance du navigateur via le profil. Les différents contextes au sein du même navigateur partagent les mêmes signaux d'appareil. Pour des identités d'appareil différentes, lancez des instances de navigateur séparées avec des profils différents.
Quelles chaînes GPU les profils mobiles rapportent-ils ?
Les profils mobiles rapportent le GPU de l'appareil source. Les exemples courants incluent "Adreno (TM) 730" pour les appareils Qualcomm, "Mali-G710" pour les appareils Samsung Exynos et "Apple GPU" pour les iPhones.
Résumé
L'émulation d'appareil dans BotBrowser fournit des identités d'appareils complètes et cohérentes via des profils capturés depuis du vrai matériel. Tous les signaux d'appareil, des dimensions d'écran et des capacités tactiles aux chaînes GPU et à la mémoire de l'appareil, proviennent du même appareil source, assurant la cohérence interne sans configuration manuelle.
Pour les sujets connexes, consultez Émulation Android pour l'émulation spécifique au mobile, Fingerprinting écran et fenêtre pour les détails sur les signaux d'écran, et Profils inter-plateformes pour l'exécution de profils sur différents systèmes d'exploitation.
Articles Connexes
Faites passer BotBrowser de la recherche à la production
Utilisez ces guides pour comprendre le modèle, puis passez à la validation multi-plateforme, aux contextes isolés et au déploiement navigateur prêt pour l'échelle.