Pixel 3 : des problèmes de RAM poussent des applis à se fermer en utilisation

Pierre Crochart

Spécialiste smartphone & gaming

23 octobre 2018 à 14h37

Les Pixel 3 ont beau être parmi les meilleurs smartphones de cette fin d'année, ils ne sont pas pour autant dépourvus de défauts. Au rang des déceptions, on pointe notamment les 4 Go de RAM seulement, qu'Android a bien du mal à gérer convenablement.

Applications qui se ferment, lecture vidéo qui s'interrompt, ou encore photographies qui ne s'enregistrent pas dans la galerie : voici en substance les problèmes auxquels sont confrontés de nombreux utilisateurs des Pixel 3.

Le nouveau flagship estampillé Google est sorti au pays de l'Oncle Sam le 19 octobre, et les premiers acheteurs pointent ces soucis qui, d'après eux, seraient imputables à une enveloppe de mémoire vive insuffisante.

4 Go de RAM sont-ils suffisants ?

2018 a vu apparaître quantité de très bons smartphones, dont certains disposent même de 10 Go de RAM. Alors avec ses 4 petits gigaoctets de mémoire vive, Google fait-il fausse route ?

Improbable, d'après les observateurs les plus éclairés. La chaîne YouTube PhoneBuff a d'ailleurs passé au peigne fin le Pixel 3 de Google, et l'a comparé à l'iPhone XS d'Apple - qui dispose lui aussi de 4 Go de RAM. Les résultats sont sans appel : le smartphone à la pomme est ultra rapide, et ne peine aucunement à garder les applications ouvertes, même après une heure de veille.

Des changements dans le kernel pointés du doigt

Mais alors d'où peut bien provenir le problème, qui empêche aux utilisateurs impactés de profiter pleinement du multitâche de leur appareil ? D'après un développeur Android interrogé par Android Police, la quantité de mémoire vive incluse dans les Pixel 3 n'est pas le problème.

« Apparemment, Google a modifié sa façon de gérer les états à faible mémoire en utilisant quelque chose appelé Imkd », explique Android Police. « Ce module pourrait se montrer un peu trop agressif à la fermeture des applications ».

Une bonne nouvelle, dans le sens où si le souci est bien causé par la partie logicielle des Pixel 3, il peut être corrigé par une mise à jour future.

En France, les Pixel 3 et Pixel 3 XL sortiront le 2 novembre, à partir de 859€.

Pierre Crochart

Spécialiste smartphone & gaming

Monsieur GSM et jeux vidéo du Clubic. J’aime autant croquer dans la pomme que trifouiller dans les circuits de l’Android. Grassement payé par les marques pour dire du bien de leurs produits.

Lire d'autres articles

Monsieur GSM et jeux vidéo du Clubic. J’aime autant croquer dans la pomme que trifouiller dans les circuits de l’Android. Grassement payé par les marques pour dire du bien de leurs produits.

Lire d'autres articles

Commentaires (8)

Rumpelstiltskin

Même Wiko fait mieux ! ^^ Non mais sérieusement je suis bien content d’avoir mon x626 à 60 balles sous miui10 , qui a déjà 4go qu’il sait gérer correctement ^^

KlingonBrain

4Go c’est pas assez ? Non, mais j’hallucine quoi… Au début des années 80, on trouvait des micro ordinateurs avec 1Ko de RAM, soit plus de 4 millions de fois moins (Les ZX80/81 pour ceux que ça intéresse). Au milieu des années 80, on trouvait des ordinateurs avec 512Ko de RAM avec une interface graphique et des menus déroulants fonctionnant de manière fluide. Le manque de savoir faire des programmeurs modernes en terme d'optimisation et de gestion des resources, ça fait vraiment de la peine à voir.

Nmut

@KlingonBrain La nature a horreur du vide et le programmeur de la mémoire inutilisée! Mais on ne peut pas comparer le ZX81, une machine qui affichait en 1/10ième de seconde 800 charactères/pixels en noir et blanc, avec un portable qui affiche une vidéo full HD agrandie sur du 2160*1080 en 16M de couleur avec un paquet de tâches de fond (gestion du BT, du Wifi, de la 4G, téléchargements, agenda, …). Et pour tes 512ko et le CGA monochrome d’enfer (je sais, il y pouvait afficher 16 couleurs…), il y avait à l’époque des “vieux cons” et des visionnaires (Bill G. si tu m’entends :-P) qui prédisaient que l’informatique personnelle atteignait une limite raisonnable. Et enfin si tu allumes un PC 8088, un To7, un Amstrad PC 1512, un MSX ou une autre antiquité, tu comprendras ce que c’est d’attendre et d’avoir mal aux yeux. Il y a maintenant des musées pour ça et ça met en perspective les avancées informatiques. Edit: Bon en me relisant, je me dis qu’il faut peut-être ajouter quelques explications: Le nombre de fonction a réaliser à explosé (réseaux, stockage, affichage) => plus de mémoire utilisée La complexité des fonctions est bien plus importante => le développement se fait par couches => plus de mémoire (c’est le seul cas ou on pourrait dire mémoire gaspillée mais on ne peut se passer de ça, on ne va pas tout ré-inventer à chaque fois) Même la définition des écrans joue sur plusieurs facteurs: plus de cache à utiliser, frame buffer bien plus important, plus de textures (pour un jeu) => BEAUCOUP plus de mémoire Interfaces plus poussées, plus de contrôle, plus de couleurs, plus d’écrans => plus de mémoire Bref la puissance disponible augmente très vite (CPU, GPU et mémoire) mais les besoins aussi.

KlingonBrain

@Nmut Pas du tout. Avec 512ko, un Amiga 500 était loin de l’image monochrome. Il pouvait afficher jusqu'a 4096 couleurs. Le tout avec de la musique, des bruitages, de bons jeux vidéo. Sans oublier un OS pleinement multitâche. “Et enfin si tu allumes un PC 8088, un To7, un Amstrad PC 1512, un MSX ou une autre antiquité, tu comprendras ce que c’est d’attendre et d’avoir mal aux yeux.” Je vais vous décevoir, à l’époque je travaillait sur 8 bits. On avait pas du tout mal aux yeux et on trouvait même les graphismes très sympa. Cela dit, il y avait mieux que les machines que vous avez cité. “Il y a maintenant des musées pour ça et ça met en perspective les avancées informatiques.” Je ne remet pas en question les énormes progrès du matériel informatique, mais plutôt la qualité de la programmation. De nos jours, les programmeurs sont mal formés et ne comprennent plus rien aux problèmes d’optimisation. Ils sont formés pour bosser vite et être facilement remplaçable. Ils gaspillent, code vite et mal. Rien à voir avec les orfèvres de l’époque. Certains programmeurs sont si “doués” qu’ils arrivent à faire ramer une machine moderne bien couillue sur des choses très simples. C’était bien la peine de faire autant de progrès… Vous avez cité quelques justifications à l’augmentation de la mémoire. Et vous n’avez bien sûr pas complètement tort. Mais la principale reste le fait que les programmeurs développent vite et mal. On developpe des couches par dessus des couches, par dessus des couches, par dessus des couches sans que personne ne comprenne ce qui se passe en dessous. Résultat, ça finit juste par ramer et bouffer toute la mémoire. On consomme une quantité de RAM incroyable juste pour afficher un simple texte. Mais croyez moi, tout cela n’est pas une fatalité. Il y a encore des gens qui savent programmer et heureusement. C’est juste que de nos jours, ces gens ne courent pas les rues. Et si encore ce qu’on faisait sur les Smartphone était incroyable et extraordinaire. Mais le moins qu’on puisse dire est que je ne suis pas subjugué par cette logithèque. Pour moi, les smartphones sont la plateforme la plus décevante jamais inventée.

steeven_eleven

Je suis d’accord, 4go de ram c’est juste portenawak. Le pire c’est que du coup les « vieux » téléphones rament à mort à cause de 2-3 fonctions sans beaucoup d’interêt alors qu’ils étaient parfaitement fluides à leur sortie.

Nmut

@KlingonBrain Tout d’abord permettez moi de vous tutoyer, ce n’est absolument pas de irrespect, juste l’habitude des forums. C’est une bonne partie de mon métier d’optimiser et de valider les softs: architecte système et dev sénior. En ce moment, je bosse sur un soft qui est porté depuis des super calculateurs sur des PCs bureautique (question de coût), l’optimisation, je connais! Je suis d’accord en partie avec toi, mais par contre je pense qu’il n’y a pas énormément de gâchis. Ton exemple d’Amiga est pour moi au contraire un exemple de ce qui ne peut (et ne doit) plus se faire. Tes 4096 couleurs, si mes souvenirs sont bons, on ne les obtenait par décalage de la palette entre chaque ligne, non (souvenir de vieux croûton…)? Bref, du bricolage possible uniquement parce que la puce graphique acceptaient seulement quelques instructions basiques, que le programmes faisant quelques milliers de lignes maîtrisées par une toute petite équipe (dev, graphiste et musicien), même chose pour la musique et son processeur spécialisé. Va maintenant choisir toi-même entre MMX (totalement obsolète je sais, mais facile à utiliser! :-D), SSEx.x, AVX, AVX2, … Et les couches, c’est un mal nécessaire! On a besoin d’inter-connectivité entre les matériels et les logiciels. Cela passe par des couches d’abstraction. Cela peut être vu comme du gâchis, je vois cela comme une obligation! Par exemple, l’accès aux fichiers, au multithreading, etc via POSIX est un minimum. Je ne me vois pas à chaque nouveau projet devenir un spécialiste du système d’exploitation, voir directement de la plateforme, l’OS étant en lui-même une couche que l’on pourrait court-circuiter. On peut prendre aussi l’exemple du réseau qui est parlant pour beaucoup de gens. Si on veut communiquer avec un autre système, on passera par du TCP/IP. On est donc obligé d’avoir les couches basses du modèle OSI. On va probablement attaquer la couche 7 car bonjour le bazar pour coder les couches inférieures, et même probablement utiliser un CORBA ou autre messaging services pour s’abstraire de toutes les vicissitudes de la gestion des messages (tout dépend aussi de ce qui est “à l’autre bout du tuyau” si ton système doit s’insérer dans un environnement existant, dans 99% des cas)! J’ai travaillé sur un système multimédia automobile. On avait besoin de capter la radio/le RDS/l’info traffic, de connectivité BT/WIFI/4G/USB/USB2/bus CAN, d’afficher des vidéos/des images, de lire de l’audio, d’afficher des menus et de la 3D. On a évidement repris des outils sur étagère qui consomment plus (CPU + mémoire) que ce que l’on aurait pu faire nous-même (il y a probablement pas mal de choses inutiles) mais c’était impossible de tout refaire en quelques mois avec une 50aine de dev qui n’auraient de toutes façon pas toutes les compétences requises. On va prendre l’analogie de l’assembleur. Peu de gens peuvent encore programmer en assembleur pour plusieurs raisons: On ne peut bien sur pas faire un soft complet en assembleur, les millions de lignes nécessaires ne sont plus gérables par une équipe raisonnable (disons 5 à 10 programmeurs) qui maîtrise tout de bout en bout et la maintenance n’est plus possible. Ce n’est de plus qu’une optimisation “locale”. La gestion de l’hétérogénéité du matériel et la multiplicité des fonctions demande une programmation par couche (encore plus sur téléphone ou on a plusieurs architectures à gérer et des ressources) ou encore mieux l’utilisation d’interfaces standards (donc par couche aussi dans les faits), impossible ou presque à code en asm. Les derniers cas de programmation en assembleur que j’ai croisé (embarqué pour des fonction très spécifiques) ont été avantageusement remplacés par des programmes en C++ : oui l’objet a un overhead important mais qui est plus que compensé par une conception plus simple et des compilateurs très performants. Le dernier obstacle était la certification des compilateurs C++ mais le résultat s’avère finalement plus fiable que l’assembleur (meilleur résilience au bugs, détection et correction bien plus rapide de ces bugs). On peut aussi prendre le cas du Java. La facilité de codage et l’abstraction au matériel peuvent faire peur (peu de maîtrise de la performance CPU et mémoire). Mais avec quelques règles de codage simples, on a un résultat qui peut, dans des cas particuliers (applications relativement répétitives de calcul ou traitement de données), avoir une performance (rapidité ET mémoire) bien supérieures à de la programmation C ou C++. La qualité du code est effectivement un problème majeur en ces temps de dev offshore mais je persiste, je pense que ce n’est pas si “catastrophique” que tu le penses.

KlingonBrain

@Nmut Cela fait plaisir de voir quelqu’un qui prends le temps d’argumenter et fournit de arguments interessants et construits. Un très grand merci à toi. Allons directement à l’essentiel : (1) L’empilement des couches. Tu dit que les couches sont nécessaires. Et la dessus, je ne te contredirait pas, c’est évident. Ce que je dénonce, c’est l’excès d’empilement et la non maîtrise croissante de ce qui se passe au sein de ces couches. Les couches, cela apporte du bon et du moins bon. Des fonctions évoluées pour le positif, un éloignement de la réalité de la machine pour le négatif. Lorsqu’une couche est de mauvaise qualité, la logique voudrait qu’on dénonce la situation et qu’on la réécrive. Mais bien souvent quand un programmeur doit faire avec une couche merdique, il choisit par facilité d’écrire une nouvelle couche par dessus. Avec le temps, au lieu de restructurer les couches, on continue d’empiler parce que c’est la voie de la facilité. Au final, on obtient un empilement infâme qui bouffe toujours plus de puissance. Et la plupart des programmeurs n’ont plus la moindre idée de ce qui s’y passe et de comment écrire du code efficient avec ça. Un jour ou l’autre, il faudra bien restructurer tout cela. On ne pourra pas empiler éternellement. Parce que la réalité, c’est que toute la puissance apportée par le progrès matériel est bouffé au fur et à mesure qu’on empile. La loi de moore à donné de mauvaises habitudes. Mais ce temps la est fini. On gagne désormais bien plus à virer des couches inutiles qu’a changer un proco de 10 ans d’age. Et les programmeurs comme moi ne s'en privent pas quand cela est possible. (2) Les langages. Les objets n’ont pas forcément un overhead important, mais cela dépends beaucoup du langage. En Javascript, c’est une catastrophe. Mais en C++, si on sait bien se servir des objets, l’impact est quasiment nul. Donc on ne s'en prive pas. Mais encore faut t’il avoir appris comment cela fonctionne à bas niveau pour savoir ce qu’il faut faire et ne pas faire. Parce que l'objet, comme tout ce qui est puissant, on peut en faire le meilleur et le pire. Pour ce qui est de la comparaison des langages, Java est très inférieur en performances à C/C++. Du moins entre les mains de bons programmeurs. En rapidité, Java est plombé par le bound checking sur ses accès mémoire. Et les accès mémoire, sur les systèmes moderne, c’est très cher. Attention aux benchmarks naifs. Un test naïf viens souvent démontrer que le garbage collector de Java est plus rapide qu’une gestion de la mémoire de débutant en C/C++. Par contre, il se fait détruire littéralement par une collection de gestionnaires mémoires personnalisés en C/C++. Au niveau des types de données et leur gestion, quand j’ai découvert Java, j’ai halluciné devant la catastrophe. Et que dire sur l’absence de fichiers d’en tête… et le code peu lisible qui en découle. Pour ce qui est du calcul, Java à l’avantage d’être compilé en mode JIT. Ce qui a l’avantage de pouvoir exploiter plus facilement les extensions d’un processeur particulier. Mais il suffit de compiler son soft C/C++ sur la plateforme avec les bons flags pour obtenir la même chose. Et même encore mieux (voir plus loin). C’est la ou l’on arrive au débat sur l’assembleur. Beaucoup pensent à tort que l’assembleur n’est plus utilisé. Mais cela n’est pas vrai. De nos jours, il est vrai que l’on n’écrirait plus un soft complet en assembleur. Trop compliqué, trop long, pas assez portable. Et les compilateurs sont plutôt bons de nos jours. Sur des milliers d’instruction, je vous garantit que vous ferez moins bien qu’un compilateur. Sauf que… l’assembleur est toujours utilisé pour des petites portions de code. Des portions petites, mais extrêmement importantes en terme de performance. Des cas ou il faut justement faire des calculs très intensifs et ou l’on choisit les quelques instructions assembleur les meilleures avec beaucoup de soin et avec des codepath pour chaque processeur particulier. Beaucoup de gens connaissent les instructions MMX, AVX et autres. Mais chaque processeur dispose de particularités qui sont souvent très difficiles à exploiter autrement qu’en assembleur. Il y a tellement de subtilités et de complexités dans les processeurs modernes. Regardez certains softs ou bibliothèque de bas niveau, vous verrez que l’assembleur est plus utilisé que certains le pensent. Et c’est la ou les bons compilateurs C/C++ ont une autre supériorité, celle de permettre d’écrire de l’assembleur directement. Mais également, certaines aides permettent d’écrire de l’assembleur de manière portable. Ce qui est très utile, par exemple, quand on veut faire interagir plusieurs thread avec un minimum de pertes de performances. Enfin, pour finir, les optimisations les plus importantes ne sont pas la ou beaucoup le pensent. Bien souvent, les optimisations les plus rentables sont dans la manière d’architecturer un logiciel. Mais sans connaissance de la programmation bas niveau, il est impossible d’écrire des choses performantes. (3) Le cas que vous décrivez d’un système multimédia automobile me parait assez symptomatique. Les gens arrivent avec un cahier des charges de dingue sans vouloir mettre les compétences, l’argent, le temps et le matériel adéquat sur la table. Bref, ils veulent tout pour rien et si possible, pour la veille. Ils pensent qu’il suffit de mettre des boites en concurrence pour que la magie du Dieu Marché tout puissant rende possible les exigences les plus folles. Et ils obtiennent au final la merde qu’ils méritent… Le plus amusant avec l’informatique dans les auto, c’est quand il faut dépanner… et qu'on y colle des gars qui ont un CAP alors que même des ingénieurs s'arrachent parfois les cheveux. (4) Pour L’amiga, le propos était de démontrer qu’on était loin d’un simple affichage monochrome. Mais si on veut se montrer tatillon, il pouvait afficher ses 4096 couleurs sans bidouilles grâce à plusieurs dispositifs. Le premier, c’est le mode graphique HAM, un mode capable d’afficher 4096 couleurs avec un dispositif de compression assez astucieux. Le second, c’est le copper, un coprocesseur spécialisé capable de placer une valeur dans un registre au moment ou le faisceau d’électrons était à la position de l’écran que l’on souhaite, mais cela sans intervention du processeur. Maintenant, si on compare avec du matériel moderne, c’est à dire un GPU piloté en DirectX ou OpenGL, c’est devenu plus complexe pour optimiser. Le fait de passer par une API de haut niveau n’est pas toujours une aide. Parfois il faut passer beaucoup de temps pour comprendre pourquoi telle opération est plus lente que telle autre… et que c’est le contraire sur un autre GPU. Mais la démarche n’a pas vraiment changé au final. Le fait de comprendre ce qui se passe à bas niveau permet d’écrire du code de haut niveau performant. Pour finir, tu dit que ce n’est pas aussi catastrophique que je le pense. Je ne partage pas cet avis. Il suffit de regarder le fiasco de certains gros logiciels publics qui ont du être abandonnés faute de pouvoir simplement en maîtriser les bugs. Et je suis peut être un vieux con, mais j’en ai mare de voire des softs qui rament pour faire des choses très simple. Des lenteurs, des affichages pas fluides. Tout cela est mauvais d’un point de vue expérience utilisateur. S’il y a 40 ans on m’avait dit qu’on inventerait toute cette puissance fabuleuse mais qu’on ne ferait que la gaspiller pour au final avoir des interfaces lentes et peu réactives, parfois pire que dans les années 70, ça m’aurait carrément déprimé. Je me souviendrais toujours du remplacement des vieilles bornes automatiques de billeterie dans les grandes gares parisienne. Le vieux modèle avec son écran tout tremblotant en noir et blanc était rapide. Le nouveau avec son interface graphique était d’une lenteur affligeante. Et les voyageurs devaient faire la queue. Pour qui a connu l’évolution de cette informatique, il y a vraiment des choses à dire sur les soit disant progrès.

Voir tous les messages sur le forum

Pixel 3 : des problèmes de RAM poussent des applis à se fermer en utilisation

4 Go de RAM sont-ils suffisants ?

Des changements dans le kernel pointés du doigt

A découvrir en vidéo

Commentaires (8)

Top app & logiciels

Sur le même sujet