Informations pratiques et mesures

Les paragraphes suivants offrent un regard critique sur l’application par le biais de tests

de performance, d’avis d’utilisateurs et de dysfonctionnements remarqués.

3.3.3.1 Tests et performances

L’application a été testée avec succès sur plus d’une dizaine de téléphones de différentes

marques (Acer, Google, Motorola, Samsung, Sony, Wiko, MTT

¹⁰

), de différentes gammes

et sur deux versions d’Android (2.3 et 4.0). Des tests ont été menés pour estimer l’impact

sur le smartphone du fonctionnement de l’application, les résultats sont présentés dans la

table 3.4. Les tests ont été effectués sur 1 smartphone de haute gamme (le Samsung Galaxy

10. Acronyme de Mobile Tout Terrain. La marque se concentre sur des appareils résistants à l’immersion, à l’infiltration de poussière et de neige et vise ainsi des conditions d’utilisation extérieures. Pour plus de détails, voir le sitehttps://www.mobiletoutterrain.com/FR/

SIII).

Sources Charge proc. Utilisation batterie Stockage (Mo)

Accéléromètre (A) 8 % -5 % 3,9 Microphone (M) 29 % -5 % 31,8 Wi-Fi (W) < 1 % -5 % < 1 GPS (G) < 1 % -16 % < 1 (A + M + W + G) 30 % -16 % 36 Tous 32 % -16 % 54

T

ABLE

3.4: Performances mesurées pour l’enregistrement de différentes sources via R

E

-CORD

M

E

La charge du processeur a été mesurée au moyen de la commande top sur le

télé-phone et accessible par le programme de débuggage adb, livré avec le kit de

développe-ment. Celui-ci permet entre autres d’ouvrir un terminal sur l’appareil et d’y exécuter des

commandes. La commande est exécutée 10 fois pendant 10 minutes lors de l’enregistrement

de sources. Chaque réponse de la commande représente la charge du processeur moyennée

sur la période d’une minute. Nous avons moyenné les dix réponses fournies par la

com-mande. Comme on peut le voir sur la table, l’enregistrement représente presque le tiers de la

charge totale du processeur. Cela peut s’expliquer par la fréquence d’échantillonnage élevée

et le calcul des descripteurs (en particulier, les calculs de transformée de Fourier nécessitent

beaucoup d’opérations).

La mesure de la consommation de la batterie est plus délicate car il n’y a pas de méthode

pour calculer précisément la consommation d’un processus. Cependant, nous pouvons

ré-duire l’impact de certaines sources connues pour leur forte consommation d’énergie. Ainsi,

les différentes radios (antennes-relais, Bluetooth, Wi-Fi, GPS) doivent être coupées si elles

ne servent pas à l’expérimentation. Également, l’écran doit être allumé le moins possible

pendant la mesure pour limiter la consommation d’énergie. À l’inverse, l’obligation dans

l’application R

ECORD

M

E

de maintenir le processeur éveillé est une source de

consomma-tion importante, imputable à l’applicaconsomma-tion. Ainsi, les mesures ont été effectuées suivant ces

considérations et ont consisté à calculer la différence du pourcentage de charge restant avant

et après un enregistrement d’une heure.

L’espace de stockage nécessaire à l’enregistrement des différentes ressources est obtenu

par calcul et a été vérifié sur les téléphones. Les chiffres indiqués représentent l’espace

oc-cupé par un fichier contenant une heure d’enregistrement. Les données sonores occupent

le plus d’espace, tout en restant raisonnable avec à peine plus de 30 Mo d’espace alloués.

L’enregistrement simultané de toutes les sources requiert un peu plus de 50 Mo pour une

heure d’enregistrement. Cette taille est raisonnable et permet d’envisager des

enregistre-ments d’une dizaine d’heures avec la plupart des cartes externes de stockage vendues sur

le marché (dont la taille se chiffre très souvent en une dizaine de giga-octets). L’usage de la

seule mémoire interne du téléphone pour le stockage des fichiers est également possible,

mais il faut s’assurer d’avoir au minimum 500 Mo libres pour pouvoir envisager dix heures

d’enregistrement.

3.3.3.2 Avis d’utilisateurs

Un entretien a été conduit avec deux participants à la collecte. Ces participants sont

membres de l’équipe mais n’étaient pas impliqués dans le projet, leur retour nous semble

donc important puisqu’ils peuvent être assimilés à des participants extérieurs. L’entretien

s’est déroulé sous forme d’une conversation, orientée par des questions prédéfinies. Parmi

elles, les points suivants ont été abordés :

— Impression générale de l’application (fonctionnement, interface) ;

— Comportement et annotations (compréhension des annotations, changement des

ha-bitudes, oubli d’annotations) ;

— Sentiment d’intrusion dans la vie privée (sentiment de surveillance, modification des

conditions d’enregistrement en conséquence) ;

— Comportement du smartphone (ralentissements, décharge plus rapide de la batterie,

manque d’espace de stockage) ;

— Dysfonctionnements notables (description, conséquences telles que fonction

non-réalisée, gêne, terminaison brutale d’une application).

L’impression générale des participants interrogés est bonne. L’interface leur a paru

simple à utiliser et fonctionnelle, le comportement de l’application a été stable à

l’excep-tion d’un problème rencontré par l’un des participants (impossibilité de transférer des

fi-chiersvial’interface de transfert des données sans fil). Le procédé d’annotation ainsi que les

contextes à annoter ont été globalement bien compris par les participants. Par ailleurs, les

participants n’ont pas eu l’impression d’être surveillés par l’application pendant les

enregis-trements.

3.3.3.3 Dysfonctionnements remarqués

Au cours des nombreux tests et enregistrements réalisés, nous avons relevé deux

com-portements problématiques. Le premier est celui rapporté par les participants et concerne

l’envoi de fichiersviala fonctionnalité de transfert sans fil. Après investigation, nous avons

remarqué que l’application a tenté d’établir une connexion au serveur mais celle-ci a été

coupée. Une discussion avec les administrateurs du serveur suggère qu’il pourrait s’agir d’un

blocage du fournisseur d’accès à internet pour empêcher l’utilisation du protocole SCP sur

certains ports de communication.

Le second problème concerne les données sonores enregistrées. Nous avons remarqué

des discontinuités dans la séquence d’échantillons. Nous expliquons ce problème par la

charge de l’enregistrement sur le processeur, confirmée par les mesures rapportées

précé-demment. En imaginant un fonctionnement normal avec les différentes radios allumées et

le fonctionnement d’applications tierces, il est raisonnable d’imaginer une charge

impor-tante du processeur, pouvant mener à l’interruption momentanée d’applications, ce qui

peut conduire à la perte de tableaux d’échantillons. Cependant, nous avons pu détecter la

plupart des discontinuités grâce à l’horodatage des échantillons.

3.3.3.4 Exemple de signaux collectés

Nous donnons à titre indicatif un exemple de plusieurs signaux collectés par un

volon-taire au cours d’un enregistrement de plusieurs heures afin d’illustrer les possibilités

d’ana-lyse de ces signaux. De haut en bas, les signaux correspondent à l’amplitude de l’accélération

exprimée enm.s

−2

; l’usage courant des applications, dont les noms sont remplacés par des

indices pour les rendre anonymes ; l’état de l’écran du smartphone ; l’évolution des antennes

relais visitées au cours du temps, elles aussi anonymes ; et la séquence des environnements

visités.

On peut alors imaginer des analyses par comparaison ou corrélation des motifs des

dif-férents signaux. Des corrélations peuvent être observées entre les données et les scènes (par

exemple, l’usage d’une application qui se produit souvent dans une scène particulière). Cette

information peut ensuite être exploitée dans un système de reconnaissance. Aussi, les

don-nées de fonctionnement, telles que l’allumage de l’écran de l’appareil, peuvent être

exploi-tées comme des références ou des annotations complémentaires. Par exemple, si l’on

sou-haite analyser les accélérations dans les scènes afin d’étudier les mouvements effectués, on

peut considérer les périodes où l’écran est éteint, suivant l’hypothèse que durant ces

pé-riodes, l’appareil n’est pas utilisé. Les périodes avec l’écran éteint sont identifiables grâce

aux données collectées.

08:30:00⁰ 09:30:00 10:30:00 11:30:00 12:30:00 13:30:00 14:30:00 10 20 Acceleration normalized Time (hours) Acceleration (m.s −2) 08:30:00 09:30:00 10:30:00 11:30:00 12:30:00 13:30:00 14:30:00 0 1 2 3 4 5 6 7 8 9 10 Application Transitions Time (hours) Application Ids 08:30:00 09:30:00 10:30:00 11:30:00 12:30:00 13:30:00 14:30:00 Off On Screen Transition Time (hours)

Screen State (on/off)

08:30:00⁰ 09:30:00 10:30:00 11:30:00 12:30:00 13:30:00 14:30:00 20

40

Registration to Cell Towers over Time

Time (Hours)

Cell Tower Ids

08:30:00 09:30:00 10:30:00 11:30:00 12:30:00 13:30:00 14:30:00 Home Street Tram Office Restau Admin

Scene Annotations over Time

Time (Hours)

Scene Ids

Dans le document Reconnaissance de scènes multimodale embarquée (Page 78-82)