Apache Adobe Flex TutorialTutoriaux Adobe Flex & AIR en Français

Cartographie interactive des TCL (Lyon) – Une consommation de ressources (RAM, CPU) jamais vue

Je travaille dans la cartographie web chez Business Geografic à Lyon alors quand les TCL (Transports en Commun de Lyon) sortent une application Flex de cartographie interactive de leur réseau, je suis plus qu'intéressé! Pour les non-lyonnais, le site des TCL avait un bon moteur de recherche d'itinéraire multi-modal (résultat sous forme de texte) ainsi qu'une carte au format PDF complète avec toutes les lignes. Cette carte entièrement vectorielle, on peut donc zoomer à foison sans perte de qualité.

Malheureusement, il n'existait aucun lien entre les deux et il n'est pas possible de voir l'itinéraire sur le plan ou de voir les horaires du bus à partir du PDF. Dans un cas comme celui-là, la solution assez logique qui s'impose est une application de cartographie interactive. Elle permet d'avoir un plan sur plusieurs niveaux tout en fournissant à l'utilisateur des informations contextuelles sur des POI (Point Of Interest).

Depuis la fin du mois de Juillet, cette application existe donc, réalisée par Actigraph / Nativia. On peut y accéder directement depuis la page d'accueil de tcl.fr, voici le lien direct:

http://carto-interactive.tcl.fr/v1.0/carteTCL/carte.html

Tiens, ça souffle…

A noter que pendant quelques jours, on a eu droit à une page avec deux liens HTML (accéder à la version Pre-Prod et accéder à la version Prod), super ^^. Après 1.6Mo de chargement d'application Flex (facile à reconnaître, ils n'ont pas pris soin de modifier le preloader ), on arrive sur l'application. Vous allez commencer à naviguer sur les 4 niveaux de zoom et dans quelques secondes, vous entendrez sûrement le ventilateur de votre PC se mettre en route.

Un petit tour dans le gestionnaire des tâches et vous aurez une belle surprise:

Oui oui, l'application est lancée sous Chrome, sans aucun autre onglet d'ouvert. Elle consomme donc bien 500Mo de RAM au démarrage, sans même que vous ayez utilisé la carte. Après quelques minutes d'utilisation, on arrive facilement à 700/800Mo de charge dédiée. Quand on a un laptop avec 2Go de RAM, on a du mal à lancer d'autres application en même temps… On remarquera aussi la consommation de 13% du CPU alors que l'on utilise même pas l'application.

Descendez donc d'un niveau de zoom (pour arriver sur Lyon) et passer votre souris sur la carte, même sans cliquer, entre les POI et voici ce que l'on obtient:

Le processeur oscille entre 45 et 50% d'utilisation (c'est-à-dire le maximal sur un des core). Descendez encore d'un niveau de zoom pour avoir plus de POI et vous verrez que le processeur est tellement occupé que le déplacement de la carte se met à saccader.

A part ça, le fonctionnel est pas mal, la suggestion d'adresse est correcte et la visualisation de l'itinéraire est suffisamment claire. Un effort a aussi été fait pour respecter la charte graphique des TCL qui rend plutôt bien. Il est cependant dommage que les informations disponibles sur les POI s'ouvrent dans une nouvelle fenêtre à chaque fois.

Comment arriver à ce résultat?

Si vous travaillez chez Actigraph et que vous traînez sur mon blog, je veux bien que vous passiez 2 minutes à m'expliquer comment une application Flex comme celle-ci peut consommer autant de ressource. Ce n'est pas la carte Google derrière qui alourdit l'application car celle-ci est très light.

Peut-être une mise en cache d'objets excessive ? Dans mes applications, j'utilise un Pool d'objet de type Tile (chaque tuile de la grille d'image). Cela évite d'avoir trop d'instanciations à la volée lors de l'utilisation de l'application tout en faisant un roulement. Mais même avec cette mise en cache, mes applications tournent plutôt autour des 100Mo de RAM que des 500Mo.

On peut remarquer que toutes les recherches ayant un nombre fini de résultat (liste des agences, listes des lignes de bus, …) sont chargées à la volée depuis un back-end PHP, pas de problème de lazy loading de ce côté là donc. Par contre, les informations qui arrivent au survol d'un POI sont requêtés à chaque passage de la souris, une petite mise en cache pourrait rendre l'application plus véloce à ce niveau-là.

Pour l'anecdote, j'ai essayé sous Android avec un HTC Desire. Cela fait crasher (mais de belle manière) le navigateur. Forcement, le mobile aurait juste assez de RAM pour faire tourner les 500Go de RAM si elle était toute seule.

Allez, pour la route, un message d'erreur énigmatique, juste pour chambrer ^^:

A vue de nez, je dirais que de nombreux calculs de collision sont effectués en permanence (hitTest et hitArea) sur les POI qui reviennent au format image (tuile). Ces calculs sont particulièrement consommateurs de ressource CPU mais pas vraiment en RAM. Bref, si quelqu'un voit une explication à ce demi giga de RAM, je suis preneur!