Android Go est le futur milliard d'appareils et une limite de 50 Mo. Conférence Yandex

De nouvelles directions pour le développement d'une plateforme déjà familière - c'est toujours intéressant. D'une part, vous élargissez la clientèle, d'autre part, vous n'investissez pas dans la création de logiciels à partir de zéro, mais en utilisant les développements existants. Mais si la direction est vraiment nouvelle, avec ses spécificités, alors il ne sera pas possible de gérer avec très peu de sang. Lors de la prochaine réunion de la communauté Mosdroid dans notre bureau, le développeur Arthur Vasilov Arturka a parlé de l'adaptation de l'application Yandex au système Android Go.

En moyenne, si vous n'écrivez pas de calculatrice, de réveil, etc., alors soit vous êtes très cool, bien fait et avez tout bien fait, soit votre application prend 150-170 mégaoctets.

- Je m'appelle Arthur, je suis développeur Android, je travaille sur l'application Yandex. Aujourd'hui, je vais partager avec vous une histoire sur la façon dont nous nous sommes adaptés à Android Go. Je vais vous dire sur quel type de râteau nous sommes tombés, ce qui n'a pas fonctionné pour nous et comment tout cela fonctionne, pourquoi il est nécessaire.

Une petite digression sur ce dont il s'agit. Android Go est une version spéciale d'Android conçue pour les appareils à bas prix. Ils coûtent de 60 à 100 dollars et sont donc très faibles, lents, ralentis. Google a donc décidé pour eux de créer leur propre système afin qu'ils fonctionnent au moins normalement. Il a été annoncé sur Google I / O en 2017, soit un an et plusieurs mois se sont écoulés. Par conséquent, lorsque le mitap a été annoncé, une question logique a été soulevée: "Êtes-vous toujours en vie, ou quoi?" J'ai alors dit que tout va bien, tout va bien, je vais le dire. Et maintenant, en tant que héros Internet typique, je répondrai a posteriori pourquoi cela s'est produit.


Que s'est-il passé exactement? Google a déclaré: "Nous créons un tel système." Puis il a dit: "D'accord, nous avons besoin de temps pour finaliser" et tout ça. Après cela, les fournisseurs ont toujours un certain retard dans l'adaptation de cette version pour eux-mêmes. Et la nouvelle version avec nous est déjà sortie au plus tôt un an plus tard, il n'y a donc rien de surprenant ici. De plus, ils devaient décider de faire une telle chose: ils parlent d'appareils bon marché et il n'est pas clair s'ils en profiteront ou non. De plus, cet appareil doit être neuf, il faut le faire, apprendre à vendre, comprendre comment il fonctionnera.

Le premier smartphone avec Android Go est apparu il n'y a pas si longtemps. Quelque part en avril, les ventes ont probablement commencé, ou peut-être en mai. C'est Nokia 1, il est vendu partout. Je traîne ici. Maintenant, à mon avis, il n'y a que neuf de ces smartphones sur le marché, mais à la fin de l'année, ils promettent plus d'une centaine. Et en principe, aucun des principaux acteurs tels que Huawei, Samsung et d'autres n'ont dit leur mot, alors ils ajouteront autre chose, ils ne pourront pas rester à l'écart d'un marché aussi important.

Avant le rapport, je suis allé sur la page Android Go et j'ai vu qu'ils faisaient l'édition Android Pie Go. Mais ils n'y ont rien fait, ils ont simplement réduit à l'avance le nombre d'applications installées et leur poids. Ils ont dit: - "Vous avez maintenant deux fois plus d'espace libre." Et les excuses standard: correction de bugs, amélioration des performances, tout. Mais au moins, ils ont appelé, ce qui signifie qu'ils n'ont pas oublié.

Quelles sont les limites de ces appareils, en particulier? Premièrement, ils ont 512 mégaoctets ou 1 gigaoctet de RAM, 8 ou 16 gigaoctets de stockage. Il est clair que dans de telles conditions, ils sont extrêmement inhibés et toutes les applications normales sur eux fonctionneront approximativement de la même manière. Pour que les applications fonctionnent avec une adéquation minimale, Google a déclaré: «Introduisons les exigences suivantes.» Ils sont assez logiques, découlent de ce qui était sur la diapositive précédente.



Tout d'abord, c'est une bonne performance abstraite. Votre application doit fonctionner correctement et rapidement sur un tel appareil. Nous sommes: «Génial. Nous travaillons. "

De plus, il existe déjà des numéros spécifiques auxquels nous devons correspondre. L'espace occupé après le déballage et l'installation de l'APK ne dépasse pas 40 mégaoctets. Parfois, c'est un problème car quelqu'un et l'APK pèsent tous les 80 mégaoctets. Ça va faire mal. De plus, cela ne peut pas être correctement pris et mesuré. Autrement dit, vous ne pouvez pas dire: "Je sais que mon APK pèse tellement, donc après l'installation, l'application prendra tellement." Tout cela dépend beaucoup du fournisseur, de la version de l'appareil, d'Android, etc. Mais si votre APK prend 10 mégaoctets, alors, en principe, tout va bien et vous ne dépasserez jamais ce nombre.

Et maintenant, l'exigence la plus amusante et la plus cool: la RAM consommée lors du travail avec l'application ne doit pas dépasser 50 mégaoctets.

Qui sait combien de RAM sa demande prend en moyenne pendant le fonctionnement? Qui s'est jamais interrogé sur cette question? Y a-t-il quelqu'un avec moins de 100 mégaoctets? Beau. Mais peut-être que vous mentez. En général, en moyenne, si vous n'écrivez pas de calculatrice, de réveil et ainsi de suite, alors soit vous êtes très cool, bien fait et vous avez tout bien fait, soit votre application prend 150-170 mégaoctets. Le mettre dans 50 mégaoctets est très difficile. Par conséquent, le reste du temps, nous en parlerons, nous discuterons de la façon de mettre le globe en hibou, etc.


Que comprend notre conversation sur la mémoire? Il est directement nécessaire de comprendre ce que nous mesurons exactement, puis quelle est la meilleure façon de le mesurer. Aussi pour les appareils Android Go, il y a une spécificité qui doit être prise en compte, et nous en parlerons également. Et je vais également vous dire des choses générales, des conseils généraux que vous n'auriez peut-être pas devinés, mais ils peuvent vraiment vous manger beaucoup de mémoire.

En 2018, après le passage des E / S Google, vous devez commencer l'histoire de la mémoire en faisant référence à ce rapport . Qui l'a regardé?

Super. Les 180 personnes restantes savent quoi faire dans un avenir proche. À mon avis, c'est l'un des meilleurs rapports sur Google I / O. Mec a dit des choses incroyablement cool. Il a tout raconté sur les étagères, enfin, et avec beaucoup de détails profonds. Ceux qui l'ont regardé et qui s'en souviennent bien remarqueront probablement que j'ai copié certaines choses à partir de là, car c'est impossible autrement, il a tout dit, alors je vais le répéter.

Que mesurons-nous? Il y avait une telle chose appelée PSS (Proportional Set Size). Autrement dit, la RAM dans Android est représentée par environ 40 blocs de kilo-octets, et ces blocs peuvent appartenir entièrement à l'application ou fouiller entre les processus et les applications.

Et la question est: comment comprendre exactement à quelle application relier cette mémoire partagée? Il existe plusieurs approches, elles sont assez logiques. PSS dit que si la mémoire tente entre N processus, nous supposerons que votre application possède 1 / N de cette mémoire. Et exactement de la même manière, il y a la taille de l'ensemble résidentiel et la taille de l'ensemble unique, qui disent que «Aucune de la mémoire partagée ne m'appartient» et «Tout appartient». En principe, PSS est le plus logique ici.

Comment pouvez-vous mesurer exactement la mémoire consommée? Ici, tout est simple. Soit c'est un profileur dans Android Studio, soit c'est dumpsys. Il existe bien sûr d'autres outils. Ils peuvent vous donner des résultats plus détaillés, quelque chose de plus compliqué, mais le problème est que pour comprendre leurs résultats, les utiliser tout cela est très, très difficile. Souvent, vous avez besoin de root ou d'une version personnalisée d'Android. Et en gros vous n'en avez pas besoin, les deux premiers outils suffisent.

_{^{Lien depuis la diapositive}}

Je ne parlerai pas du profileur dans Android Studio, je pense que beaucoup de gens l'ont utilisé. Qui n'a pas utilisé, assurez-vous de pousser. En particulier, j'ai fourni le lien ci-dessous - juste un bon article de la documentation avec vidéo, comment l'utiliser, avec des démos. Et, en principe, tout est clair. Il montre où va votre mémoire, le montre en temps réel. La seule chose à retenir est qu'elle impose néanmoins certaines erreurs qui découlent du fait que nous mesurons constamment cette mémoire. Mais ils sont dans des limites acceptables.

_{^{Lien depuis la diapositive}}

Dumpsys est une console simple qui ne nécessite rien de vous, juste un téléphone connecté et un adb. Et vous pouvez exécuter cette commande: appelez dumpsys meminfo, passez-lui le paquet et il vous renverra quelque chose comme ça. Et si nous sommes intéressés par la consommation de notre application, nous pouvons examiner spécifiquement TOTAL, qui indique que "votre application consomme environ 168 mégaoctets". Beaucoup, mais que faire?

_{^{Lien depuis la diapositive}}

Il vous montre également une ventilation exacte de la quantité de mémoire nécessaire dans cette mémoire consommée. Il y a différentes sections ici, elles sont complexes, nous en parlerons plus loin, mais pour l'instant nous pouvons remarquer l'essentiel - ce sont Java Heap, nos objets Java, et tout est plus compliqué.

Quoi d'autre est important? La mémoire est une chose très sensible à toutes sortes de tests et à toutes sortes de conditions externes. Autrement dit, tous les tests que vous devez effectuer autant que possible dans les mêmes conditions. Il est clair que cela devrait idéalement être un seul appareil, car la mémoire dépend de la version d'Android. Il suffit de rappeler les différences entre les quatre et les cinq. Cela dépend de la taille ou de la résolution de l'écran, car plus la taille de l'écran est grande, plus le contenu s'introduit, plus vous avez besoin de mémoire pour tout dessiner. Plus la résolution est élevée, plus votre bitmap occupe de pixels et plus de mémoire est nécessaire pour les stocker.

Le scénario d'application affecte également les tests. Vous pouvez lire le texte ou faire défiler la galerie avec un tas d'images. Et il est clair où il y aura plus de mémoire.

Une autre chose importante est la charge sur l'appareil. Autrement dit, vous pouvez tout avoir de la même façon, mais dans un cas, votre application est la seule qui fonctionne pour vous, et dans l'autre cas, vous avez un tas d'applications qui font quelque chose en arrière-plan, téléchargent quelque chose, le suppriment, travaillent au premier plan , et en même temps, votre mémoire est simplement épuisée, car vous devez la donner à d'autres applications. Par conséquent, idéalement, il est préférable de prendre et de tuer d'abord toutes les autres applications qui fonctionnent, pas la vôtre. Tout ce que vous pouvez atteindre, puis tuer. Juste dans ce cas, et PSS vous remerciera certainement, car il ne sera pas nécessaire de tâtonner la mémoire entre les processus.


Vous pouvez, par exemple, prendre et voir les informations actuelles sur la mémoire libre, sur la mémoire occupée. Il vous apportera quelque chose comme un signe qui dit: «Ici, j'ai tellement de mémoire libre, tellement de mémoire en cache, tellement de mémoire occupée.» Et si vous avez 200 à 250 mégaoctets de mémoire libre pour votre bien-aimé là-bas, alors c'est bien, très probablement, alors rien n'affectera vos tests.

Peut-être que quelqu'un a maintenant la question "Pourquoi ai-je besoin de tout cela?" C'est un tel casse-tête dans lequel je dirai en outre la motivation de tout cela.

Premièrement, même si vous ne faites rien sous Android Go maintenant et pensez qu'il est mort, il pourrait bien se développer, venir à vous, et à un moment donné, vous devrez faire face à tout cela.

La deuxième chose que je considère très importante est que vous pouvez simplement faire des tests de régression à partir de la mémoire. Autrement dit, vous pouvez simplement écrire un script qui exécutera l'application, fera des vidages, prendra de telles mesures et observera comment ces indicateurs changent entre les versions. Un tel script peut être écrit en quelques heures, l'infrastructure peut être configurée plus longtemps, mais il me semble que c'est une bonne chose.

Si nous parlons des spécificités d'Android Go - notre troisième point dans la lutte contre la mémoire - alors il y a de bonnes nouvelles. Tout d'abord, personne ne vous oblige vraiment à respecter ces restrictions. Autrement dit, vous pouvez utiliser l'application telle quelle, la mettre sur l'appareil avec Android Go, et tout va bien. Le problème est que l'utilisateur est très susceptible de vous retirer car vous prenez beaucoup de place. Votre application peut également s'exécuter lentement et avoir beaucoup de mémoire, oui. Mais jusqu'à présent, personne ne l'a interdit, car sinon il n'y aurait eu aucune application autre que les applications Google sur Android Go. Mais si cette chose se développe, beaucoup s'adapteront à de telles conditions, puis, au final, votre application peut simplement être réduite dans l'émission Android Go, ou dire comment l'utilisateur installe l'application sur son smartphone Android Go, ils peuvent lui montrer Alert : "Mec, l'application ne fonctionne pas bien avec Android Go. Peut-être que vous ne le mettrez pas? "

Il y a un autre point - vous pouvez exclure manuellement les appareils Android Go de Google Play, c'est-à-dire que l'application ne peut pas être installée sur les appareils Android Go. Il est apparu il n'y a pas si longtemps.

Et Google est également assez intelligent, et les 50 mégaoctets qui sonnaient dans le titre du rapport ne sont pas un nombre fixe, cela dépend de la résolution de l'appareil, de la taille de l'écran et, en outre, du type d'application. Par exemple, les jeux sont alloués plus, à mon avis, 115 mégaoctets. En principe, cela est compréhensible.

_{^{Lien depuis la diapositive}}

Et si nous parlons directement de ce test? Il y a un autre point, qui nous préoccupe beaucoup en particulier: travailler avec des préréglages. Lorsque les fournisseurs fabriquent un nouveau téléphone, ils y mettent souvent un ensemble d'applications préinstallées. En particulier, nous y sommes très impliqués, et le problème est qu'ils y exécutent des choses comme Compatibility Test Suite. Ce sont des tests google, ils les exécutent. Et là, si votre application ne correspond pas à ces 50 mégaoctets, alors tout est mauvais, et votre application ne peut pas être préinstallée sur un tel appareil.

Malheureusement, les tests que Google fait ne sont pas open source, je ne peux pas leur dire, ils sont sous le NDA, mais de bons développeurs de Google ont écrit un tel article sur Android Go, et là, en principe, il y a des recommandations qui sont assez bonnes

Autrement dit, tout est banal. Nous lançons l'application. Nous attendons 5 secondes pour que tout se charge. Nous faisons dumpsys, écrivons la valeur TOTALE, exécutons un tas de fois, nous obtenons le résultat. Tout est très simple et banal.


La seule chose est qu'ils n'ont pas pris en compte une si petite fonctionnalité dans leur article, ou, peut-être, n'en ont pas parlé - il existe une chose telle que travailler dans un autre processus, et ils le font souvent afin de lutter contre la consommation de mémoire.

Qui pense que c'est bon pour Android Go? Et qui pense que c'est mauvais? Bravement.


Le problème est que, oui, c'est mauvais, car au final, la mémoire de votre application consommée est comptée dans tous les processus. Si nous faisons un tel processus vide sans rien et prenons des vidages de ce processus particulier, nous verrons qu'il faut 7 mégaoctets. 5-8 mégaoctets - c'est une telle surcharge de la création du processus. Par conséquent, lorsque nous nous battons pour que chaque mégaoctet comprenne tout en 50, une telle chose nous est très mal donnée. En particulier, supposons que Yandex possède la bibliothèque Yandex.Metrica la plus populaire, elle fonctionne également dans un processus différent, ce qui peut également nous faire mal.


Par conséquent, si certaines bibliothèques externes viennent à vous, par exemple, vous pouvez simplement dire: «Mec, veuillez travailler dans le processus principal. Je suis d'accord que cela peut être plus lent, mais cela ne consommera pas de mémoire inutile. » C'est donc aussi un point subtil.



Si nous parlons de consommation de mémoire, passons à cette plaque, qui est là. Nous prenons un projet vide, et exécutons ce dumpsys, démarrons cette entreprise, et nous voyons que 23 mégaoctets de 50 sont déjà pris. Vide "Bonjour, monde!" sans rien, il suffit d'activer avec le texte. Ça devient assez triste. Il devient encore plus triste de constater que nous pouvons influencer directement un paramètre tel que Java Heap, c'est-à-dire que ce sont directement nos objets Java que nous pouvons suivre explicitement, que nous pouvons supprimer, réduire et au moins interagir d'une manière ou d'une autre.

Et il est difficile d'interagir normalement avec tout cela, car il s'agit de tout code cadre et directement à partir de Java, vous n'avez tout simplement pas d'outils normaux pour comprendre comment tout cela est utilisé. Mais la bonne nouvelle est que nous pouvons influencer tout cela indirectement, alors parlons de ce qui existe.


Qu'est-ce que Java Heap est compréhensible. Ce qui est Native Heap est également assez logique à assumer. Ce sont les mêmes allocations, seulement positives. Ils proviennent du framework et de vos bibliothèques natives, des fichiers .so, etc.

Le code est directement lié au stockage de code. C'est la taille de votre .dex, c'est votre .so, ce sont les ressources, les fichiers mmap et tout ça. Autrement dit, moins il y a de code, mieux c'est. La vérité la plus simple qui fonctionne en général sur tout.

Stack est une pile de threads Java / C ++. C'est-à-dire que chaque thread a sa propre pile d'appels, donc chaque thread crée une zone de mémoire spécifique pour stocker tout cela.

Les graphiques sont un rendu d'interface utilisateur. Il y a des bitmaps partiellement stockés qui sont dessinés et ce qui y est lié.

Autre privé, Système - c'est quelque chose que nous ne pouvons pas influencer du tout, et, en fait, tout le reste qui n'est pas très catégorisable.



Si nous parlons de bibliothèques natives, alors, disons que vous pouvez prendre une application vide ... vous pouvez prendre l'application habituelle que nous avons et en prendre des dumpsys, voir que cela prend 146 mégaoctets. Et si vous allez couper quelque chose ... en particulier, j'ai pris et scié les deux plus grandes bibliothèques natives, dont nous avons un total de 15 mégaoctets, et prenez dumpsys après cela, vous pouvez facilement voir que nous avons perdu la consommation du tas natif et du code. Autrement dit, avec un geste si simple, nous nous sommes économisés environ 35 mégaoctets. Pas assez mal.



Streams. Faisons le test le plus simple. Il y a une application vide, et il y a la même application vide, où nous prenons et faisons une boucle qui fera le nouveau Thread (), dormira dedans pendant cinq secondes et démarrera ce thread. Vous pouvez voir que dans ce cas, la pile est considérablement reconstituée. Autrement dit, nous pouvons influencer tout cela, mais indirectement, en réduisant le nombre de threads dans le code Java. Autrement dit, grâce à des objets Java, y compris influencer tous ces emplacements qui se trouvent dans d'autres éléments.



Si vous continuez à parler des threads, vous pouvez facilement voir ce que vous avez pour les threads, ce qu'ils font dans l'application. Il existe différents outils. Vous pouvez utiliser le même systrace, vous pouvez simplement utiliser la console pour trouver l'id de votre processus et saisir ps par quels threads se trouvent dans le système.

Si vous vous débrouillez bien et utilisez toutes sortes de ThreadFactory pour nommer vos threads, alors vous pouvez comprendre ce que vous devriez avoir, ce qui ne devrait pas l'être, et ainsi réduire le tout, car avoir 100 threads dans l'application n'a pas de sens.

Que peut-on faire d'autre? Il existe un ensemble bien connu de conseils sur l'accordéon: surveillez les fuites, utilisez des pools, ne créez pas d'objets lorsque vous n'en avez pas besoin, et toutes ces bêtises, tout cela s'applique. Super.

Il existe une bonne corrélation entre la quantité de mémoire utilisée par votre application et sa taille. Autrement dit, plus votre application est grande, plus elle consommera de mémoire, donc, d'une manière simple, réduisez le poids de l'APK, réduisez le poids de .dex, réduisez .so, supprimez tout ce qui peut être supprimé.

. , , , . , ? — — , . , , . . — .


dumpsys, , , . , , View, WebView, Assets, .


, , , , , SharedPreference SQLite - , , , .



, , Assets. , , – . 1,5 . -, , . .


— WebView. , WebView, , dumpsys, 100 , . , , - , , 300 — . , WebView , . -.



Google . . WebView, Google, - . WebView. D'accord.



Google Go, Android Go-. , - layout , . , , , Chrome Tabs, Chrome . .

Android Go, ? , Android Go, .


Il y a plusieurs façons. -, , , Android Go . , , . , , , - build , - , , - . APK, , — uses-feature «low-memory», APK.

, , Android Go. Google. , , Go- .

, ? , , - , : «, - . ». . , , , , , - , , - . , , , , Google, Google , . , , , Android Go , , .

, , , -. .

, Google I/O: , - . , , , , , - , . , « , . ». . , . , .

? , . — , , 98% . , , , . . - Android Go-. , YouTube Go . YouTube , , , . . , Android Go , , , — . — Facebook Lite, Twitter Lite, . Lite, - . -, , . Facebook, . , , . , — , Android Go.

? Stack Overflow, 1000 . . , , , . , , — dumpsys.

, Android , 512 , Android 4.4. API , .

, . , . — , .

, : « ». : «». . — , . - 170 . . - . ? , , , , - . - — . 105 . .


. build- -. densitySplit, , resConfig, . , , — . ProGuard . , ProGuard , , , , , stacktraces.

. , , Android Go- .

- 64 . : «, ». 14 , 4 , 60 . , . . , . — , , , , . , , , Android Go, . 10 , APK , , . , , .

, — . , . , , - , , . . , , . .