Neue Wege für die Entwicklung einer bereits bekannten Plattform - es ist immer interessant. Einerseits erweitern Sie den Kundenstamm, andererseits investieren Sie nicht in die Erstellung von Software von Grund auf neu, sondern nutzen vorhandene Entwicklungen. Aber wenn die Richtung wirklich neu ist, mit ihren eigenen Besonderheiten, dann wird es nicht möglich sein, mit sehr wenig Blut auszukommen. Beim nächsten Treffen der Mosdroid-Community in unserem Büro sprach der Entwickler Arthur
Vasilov Arturka über die Anpassung der Yandex-Anwendung an das Android Go-System.
Wenn Sie keinen Taschenrechner, keinen Wecker usw. schreiben, sind Sie im Durchschnitt entweder sehr cool, gut gemacht und haben alles gut gemacht, oder Ihre Anwendung benötigt 150 bis 170 Megabyte.
- Mein Name ist Arthur, ich bin ein Android-Entwickler und arbeite an der Yandex-Anwendung. Heute werde ich Ihnen eine Geschichte darüber erzählen, wie wir uns an Android Go angepasst haben. Ich werde Ihnen sagen, auf welche Art von Rechen wir gestoßen sind, was für uns nicht funktioniert hat und wie alles funktioniert, warum es benötigt wird.
Ein kleiner Exkurs darüber, worum es geht. Android Go ist eine spezielle Version von Android für kostengünstige Geräte. Sie kosten 60-100 Dollar und sind daher sehr schwach, langsam und verlangsamt. Deshalb hat Google beschlossen, ein eigenes System zu erstellen, damit sie zumindest irgendwie normal funktionieren. Es wurde 2017 bei Google I / O angekündigt, dh ein Jahr und mehrere Monate sind vergangen. Als der Mitap angekündigt wurde, wurde daher eine logische Frage aufgeworfen: "Lebst du noch oder was?" Ich sagte dann, dass alles in Ordnung ist, alles in Ordnung ist, werde ich sagen. Und jetzt, als typischer Internet-Held, werde ich nachträglich antworten, warum es passiert ist.
Was genau ist passiert? Google sagte: "Wir machen ein solches System." Dann sagte er: "Okay, wir brauchen Zeit, um fertig zu werden" und das alles. Danach haben Anbieter immer eine gewisse Verzögerung bei der Anpassung dieser Version für sich. Und die neue Version bei uns wird bereits frühestens ein Jahr später veröffentlicht, daher gibt es hier nichts Überraschendes. Außerdem mussten sie sich entscheiden, ob sie so etwas tun sollten: Sie sprechen von billigen Geräten, und es ist nicht klar, ob sie davon profitieren werden oder nicht. Darüber hinaus muss dieses Gerät neu sein, es muss gemacht werden, lernen, wie man verkauft, verstehen, wie es funktionieren wird.
Das erste Smartphone mit Android Go erschien vor nicht allzu langer Zeit. Irgendwann im April begannen die Verkäufe wahrscheinlich oder vielleicht im Mai. Dies ist Nokia 1, es wird überall verkauft. Ich liege hier herum. Meiner Meinung nach gibt es derzeit nur neun solcher Smartphones auf dem Markt, aber bis Ende des Jahres versprechen sie mehr als hundert. Und im Prinzip hat keiner der großen Player wie Huawei, Samsung und andere sein Wort gesagt, also werden sie noch etwas hinzufügen, sie werden sich nicht von einem so großen Markt fernhalten können.
Vor dem Bericht ging ich zur Android Go-Seite und sah, dass sie die Android Pie Go Edition erstellt haben. Aber sie haben dort nichts getan, sie haben einfach die Anzahl der installierten Anwendungen und ihr Gewicht im Voraus reduziert. Sie sagten: "Sie haben jetzt doppelt so viel freien Speicherplatz." Und die Standardausreden: Fehlerbehebung, Leistungsverbesserung, alles. Aber zumindest haben sie angerufen, was bedeutet, dass sie nicht vergessen haben.
Was sind speziell die Einschränkungen dieser Geräte? Erstens haben sie 512 Megabyte oder 1 Gigabyte RAM, 8 oder 16 Gigabyte Speicher. Es ist klar, dass sie unter solchen Bedingungen extrem gehemmt sind und alle normalen Anwendungen auf ihnen ungefähr auf die gleiche Weise funktionieren. Damit Anwendungen mit minimaler Angemessenheit funktionieren, sagte Google: "Lassen Sie uns die folgenden Anforderungen einführen." Sie sind ziemlich logisch, folgen Sie dem, was auf der vorherigen Folie war.
Zuallererst ist es abstrakt gute Leistung. Ihre Anwendung sollte auf einem solchen Gerät gut und schnell ausgeführt werden können. Wir sind: „Großartig. Wir arbeiten. “
Darüber hinaus gibt es bereits bestimmte Zahlen, denen wir entsprechen müssen. Der belegte Speicherplatz nach dem Auspacken und Installieren des APK beträgt nicht mehr als 40 Megabyte. Manchmal ist dies ein Problem, weil jemand und die APK alle 80 Megabyte wiegen. Es wird weh tun. Darüber hinaus kann dies nicht angemessen erfasst und gemessen werden. Das heißt, Sie können nicht sagen: "Ich weiß, dass meine APK so viel wiegt, sodass die Anwendung nach der Installation so viel kostet." All dies hängt sehr stark vom Hersteller, der Version des Geräts, Android usw. ab. Wenn Ihre APK jedoch 10 Megabyte benötigt, ist im Prinzip alles in Ordnung und Sie werden diese Anzahl niemals überschreiten.
Und jetzt die unterhaltsamste und coolste Anforderung: Der verbrauchte Arbeitsspeicher während der Arbeit mit der Anwendung sollte 50 Megabyte nicht überschreiten.
Wer weiß, wie viel RAM seine Anwendung während des Betriebs durchschnittlich benötigt? Wer hat sich jemals über dieses Problem gewundert? Gibt es jemanden mit weniger als 100 Megabyte? Schön. Aber vielleicht lügst du. Wenn Sie im Durchschnitt keinen Taschenrechner, keinen Wecker usw. schreiben, sind Sie entweder sehr cool, gut gemacht und haben alles gut gemacht, oder Ihre Anwendung benötigt 150-170 Megabyte. Es ist sehr schwierig, es auf 50 Megabyte zu bringen. Daher werden wir den Rest der Zeit darüber sprechen, wie man den Globus in eine Eule verwandelt usw.
Was beinhaltet unser Erinnerungsgespräch? Es ist direkt notwendig zu verstehen, was genau wir messen und wie es am besten gemessen werden kann. Auch für Android Go-Geräte gibt es eine Besonderheit, die berücksichtigt werden muss, und wir werden auch darüber sprechen. Und ich werde Ihnen auch einige allgemeine Dinge erzählen, allgemeine Tipps, die Sie vielleicht nicht erraten haben, die aber wirklich viel Gedächtnis von Ihnen essen können.
Im Jahr 2018, nachdem Google I / O durchlaufen wurde, müssen Sie die Geschichte über das Gedächtnis mit einem Verweis auf
diesen Bericht beginnen . Wer hat es gesehen?
Großartig. Alle verbleibenden 180 Personen wissen, was in naher Zukunft zu tun ist. Meiner Meinung nach ist dies einer der besten Berichte bei Google I / O. Dude sagte unglaublich coole Dinge. Er erzählte alles in den Regalen, gut und mit vielen tiefen Details. Diejenigen, die es gesehen haben und sich gut daran erinnern, werden wahrscheinlich bemerken, dass ich einige Dinge von dort kopiert habe, weil es sonst unmöglich ist, er hat alles erzählt, also werde ich es wiederholen.
Was messen wir? Es gab so etwas wie PSS (Proportional Set Size). Das heißt, der RAM in Android wird durch etwa 40-Kilobyte-Blöcke dargestellt, und diese Blöcke können entweder vollständig zur Anwendung gehören oder zwischen Prozessen und Anwendungen stöbern.
Und die Frage ist: Wie genau kann man verstehen, auf welche Anwendung dieser gemeinsame Speicher bezogen werden soll? Es gibt verschiedene Ansätze, sie sind ziemlich logisch. PSS sagt, wenn Speicher zwischen N Prozessen fummelt, gehen wir davon aus, dass Ihre Anwendung 1 / N dieses Speichers besitzt. Und genau so gibt es die Residential Set Size und die Unique Set Size, die besagen, dass „keiner der gemeinsam genutzten Speicher mir gehört“ und „Alles gehört“. Im Prinzip ist PSS hier am logischsten.
Wie genau können Sie den verbrauchten Speicher messen? Hier ist alles einfach. Entweder ist es ein Profiler in Android Studio oder es ist dumpsys. Es gibt natürlich auch andere Tools. Sie können Ihnen detailliertere Ergebnisse liefern, etwas komplizierteres, aber das Problem ist, dass es sehr, sehr schwierig ist, ihre Ergebnisse zu verstehen und sie alle zu verwenden. Oft benötigen Sie entweder root oder einen benutzerdefinierten Build von Android. Und im Großen und Ganzen brauchen Sie sie nicht, die ersten beiden Werkzeuge reichen aus.
Ich werde nicht über den Profiler in Android Studio sprechen, ich denke, viele Leute haben ihn verwendet. Wer nicht benutzt hat, muss unbedingt stupsen. Insbesondere habe ich den folgenden Link bereitgestellt - nur ein guter Artikel aus der Dokumentation mit Video, wie man es benutzt, mit Demos. Und im Prinzip ist alles klar. Es zeigt, wohin Ihr Gedächtnis geht, zeigt es in Echtzeit. Das Einzige, woran man sich erinnern muss, ist, dass es dennoch bestimmte Fehler auferlegt, die sich aus der Tatsache ergeben, dass wir dieses Gedächtnis ständig messen. Sie liegen jedoch innerhalb akzeptabler Grenzen.
Dumpsys ist eine einfache Konsolensache, die nichts von Ihnen erfordert, nur ein verbundenes Telefon und ADB. Und Sie können diesen Befehl ausführen: Rufen Sie dumpsys meminfo auf, übergeben Sie das Paket an es, und es gibt Ihnen so etwas zurück. Und wenn wir daran interessiert sind, wie viel unsere Anwendung verbraucht, können wir uns speziell TOTAL ansehen, das besagt, dass "Ihre Anwendung ungefähr 168 Megabyte verbraucht". Viel, aber was tun?
Es zeigt Ihnen auch eine genaue Aufschlüsselung, wie viel Speicher in diesem Speicher benötigt wird. Es gibt hier verschiedene Abschnitte, sie sind komplex, wir werden weiter darüber sprechen, aber jetzt können wir die Hauptsache bemerken - dies sind Java Heap, unsere Java-Objekte, und alles weitere ist komplizierter.
Was ist sonst noch wichtig? Das Gedächtnis ist eine sehr empfindliche Sache für alle Arten von Tests und alle Arten von äußeren Bedingungen. Das heißt, alle Tests müssen Sie so oft wie möglich unter den gleichen Bedingungen durchführen. Es ist klar, dass dies idealerweise ein Gerät sein sollte, da der Speicher von der Version von Android abhängt. Es reicht aus, sich an die Unterschiede zwischen den Vieren und Fünfern zu erinnern. Dies hängt von der Größe oder Auflösung des Bildschirms ab. Je größer der Bildschirm, desto mehr Inhalte werden eingebrochen, desto mehr Speicher wird benötigt, um alles zu zeichnen. Je größer die Auflösung, desto mehr Pixel belegt Ihre Bitmap und desto mehr Speicher wird zum Speichern benötigt.
Das Anwendungsszenario wirkt sich auch auf die Tests aus. Sie können den Text lesen oder mit einer Reihe von Bildern durch die Galerie scrollen. Und es ist klar, wo es mehr Speicher geben wird.
Ein weiterer wichtiger Punkt ist die Belastung des Geräts. Das heißt, Sie können alles gleich haben, aber in einem Fall ist Ihre Anwendung die einzige, die für Sie funktioniert, und in dem anderen Fall haben Sie eine Reihe von Anwendungen, die etwas im Hintergrund tun, etwas herunterladen, löschen, im Vordergrund arbeiten Gleichzeitig wird Ihr Speicher einfach gelöscht, da Sie ihn anderen Anwendungen zur Verfügung stellen müssen. Daher ist es im Idealfall besser, alle anderen funktionierenden Anwendungen zu übernehmen und zuerst zu beenden, nicht Ihre. Alles, was Sie erreichen und dann töten können. Nur in diesem Fall, und PSS wird es Ihnen auf jeden Fall danken, da es nicht erforderlich ist, den Speicher zwischen den Prozessen zu durchsuchen.
Sie können beispielsweise die aktuellen Informationen zum freien Speicherplatz und zum belegten Speicher abrufen und anzeigen. Er wird Ihnen so etwas wie ein Schild bringen, auf dem steht: "Hier habe ich so viel freien Speicher, so viel zwischengespeicherten Speicher, so viel belegten Speicher." Und wenn Sie 200-250 Megabyte freien Speicher für Ihre Geliebte dort haben, dann ist dies wahrscheinlich gut, dann wird nichts Ihre Tests beeinflussen.
Vielleicht hat jetzt jemand die Frage "Warum brauche ich das alles?" Dies ist so ein Breaker, in dem ich zusätzlich die Motivation für all das sagen werde.
Erstens, selbst wenn Sie unter Android Go jetzt nichts unternehmen und denken, dass es tot ist, kann es sich durchaus entwickeln, zu Ihnen kommen, und irgendwann müssen Sie sich mit all dem befassen.
Das zweite, was ich für sehr wichtig halte, ist, dass Sie nur Regressionstests aus dem Gedächtnis durchführen können. Das heißt, Sie können einfach ein Skript schreiben, das die Anwendung ausführt, dumpsys ausführt, solche Messungen durchführt und beobachtet, wie sich diese Indikatoren zwischen den Releases ändern. Ein solches Skript kann in ein paar Stunden geschrieben werden, die Infrastruktur kann für eine längere Zeit konfiguriert werden, aber es scheint mir, dass dies eine gute Sache ist.
Wenn wir über die Besonderheiten von Android Go sprechen - unseren dritten Punkt im Kampf gegen das Gedächtnis - dann gibt es einige gute Neuigkeiten. Erstens verlangt niemand wirklich, dass Sie diese Einschränkungen befolgen. Das heißt, Sie können die Anwendung so verwenden, wie sie ist, sie mit Android Go auf das Gerät stellen und alles ist in Ordnung. Das Problem ist, dass der Benutzer Sie sehr wahrscheinlich entfernt, weil Sie viel Platz beanspruchen. Auch Ihre Anwendung läuft möglicherweise langsam und hat eine Menge Speicher, ja. Aber bisher hat es niemand verboten, denn sonst hätte es auf Android Go keine andere Anwendung als Google Apps gegeben. Aber wenn sich dieses Ding weiterentwickelt, werden sich viele an solche Bedingungen anpassen, und am Ende kann Ihre Anwendung einfach in der Android Go-Ausgabe gesenkt werden oder sagen, wie der Benutzer die Anwendung auf seinem Android Go-Smartphone installiert, sie können ihm Alarm anzeigen : "Alter, die App funktioniert nicht gut mit Android Go. Vielleicht wirst du es nicht sagen? "
Es gibt noch einen weiteren Punkt: Sie können Android Go-Geräte manuell von Google Play ausschließen, dh, die Anwendung kann nicht auf Android Go-Geräten installiert werden. Es erschien vor nicht allzu langer Zeit.
Google ist auch schlau genug, und die 50 Megabyte, die im Titel des Berichts erklangen, sind keine feste Zahl, sondern hängen von der Auflösung des Geräts, der Bildschirmgröße und darüber hinaus von der Art der Anwendung ab. Zum Beispiel werden Spiele meiner Meinung nach mehr als 115 Megabyte zugewiesen. Dies ist grundsätzlich verständlich.
Was ist, wenn wir direkt über diesen Test sprechen? Es gibt noch einen Punkt, der uns besonders beschäftigt - die Arbeit mit Presets. Wenn Anbieter ein neues Telefon herstellen, stellen sie häufig einige vorinstallierte Anwendungen bereit. Insbesondere sind wir sehr daran beteiligt, und das Problem ist, dass dort Dinge wie die Compatibility Test Suite ausgeführt werden. Dies sind Google-Tests, sie führen sie aus. Und dort, wenn Ihre Anwendung nicht diesen 50 Megabyte entspricht, ist alles schlecht und Ihre Anwendung kann auf einem solchen Gerät nicht vorinstalliert werden.
Leider stammen die Tests, die Google durchführt, nicht aus Open Source. Ich kann ihnen nicht sagen, dass sie unter der NDA stehen, aber gute Entwickler von Google haben einen solchen Artikel über Android Go geschrieben, und dort gibt es im Prinzip Empfehlungen, die gut genug sind
Das heißt, alles ist banal. Wir starten die Anwendung. Wir warten 5 Sekunden, bis alles geladen ist. Wir machen dumpsys, schreiben den TOTAL-Wert, führen einige Male aus, wir erhalten das Ergebnis. Alles ist sehr einfach und alltäglich.
Das einzige ist, dass sie ein so kleines Merkmal in ihrem Artikel nicht berücksichtigt oder vielleicht auch nicht darüber gesprochen haben - es gibt so etwas wie die Arbeit in einem anderen Prozess, und sie tun es oft, um zu kämpfen, einschließlich des Speicherverbrauchs.
Wer glaubt, dass dies gut für Android Go ist? Und wer findet das schlecht? Tapfer.
Das Problem ist, dass dies schlecht ist, da am Ende Ihr verbrauchter Anwendungsspeicher über alle Prozesse hinweg gezählt wird. Wenn wir einen solchen leeren Prozess ohne irgendetwas machen und dumpsys von diesem bestimmten Prozess nehmen, werden wir sehen, dass es 7 Megabyte dauert. 5-8 Megabyte - dies ist ein solcher Aufwand bei der Erstellung des Prozesses. Wenn wir also um jedes Megabyte kämpfen, um alles auf 50 zu bringen, wird uns so etwas sehr schlecht gegeben. Nehmen wir insbesondere an, Yandex hat die beliebteste Yandex.Metrica-Bibliothek, sie funktioniert auch in einem anderen Prozess, und dies kann uns auch Schmerzen bereiten.
Wenn zum Beispiel einige externe Bibliotheken zu Ihnen kommen, können Sie einfach sagen: „Alter, bitte arbeiten Sie im Hauptprozess. Ich bin damit einverstanden, dass dies zwar langsamer ist, aber keinen unnötigen Speicherplatz verbraucht. “ Das ist also auch ein subtiler Punkt.
Wenn wir über den Speicherverbrauch sprechen, gehen wir zu dieser Platte über, die dort ist. Wir nehmen ein leeres Projekt und führen dieses Dumpsys aus, starten dieses Geschäft und sehen, dass 23 Megabyte von 50 bereits vergeben sind. Leere "Hallo Welt!" ohne irgendetwas einfach mit dem text aktivieren. Es wird ziemlich traurig. Es wird noch trauriger, wenn wir erkennen, dass wir einen Parameter wie Java Heap direkt beeinflussen können, dh wir können direkt unsere Java-Objekte explizit verfolgen, die wir löschen, reduzieren und zumindest irgendwie interagieren können.
Und es ist schwierig, normal mit dieser ganzen Sache zu interagieren, da dies ein beliebiger Framework-Code ist und Sie direkt aus Java einfach keine normalen Tools haben, um zu verstehen, wie all dies verwendet wird. Aber die gute Nachricht ist, dass wir diese ganze Sache indirekt beeinflussen können, also lassen Sie uns darüber sprechen, was da ist.
Was ist Java Heap ist verständlich. Was Native Heap ist, ist auch ziemlich logisch anzunehmen. Dies sind die gleichen Zuweisungen, nur positive. Sie stammen aus dem Framework und aus Ihren nativen Bibliotheken, .so-Dateien und mehr.
Code steht in direktem Zusammenhang mit der Codespeicherung. Dies ist die Größe Ihrer .dex, dies ist Ihre .so, dies sind die Ressourcen, mmap-Dateien und all das. Das heißt, je weniger Code, desto besser. Die einfachste Wahrheit, die im Allgemeinen über alles funktioniert.
Stapel ist ein Stapel von Java / C ++ - Threads. Das heißt, jeder Thread hat seinen eigenen Aufrufstapel, sodass jeder Thread einen bestimmten Speicherbereich erstellt, um das Ganze zu speichern.
Grafik ist ein UI-Rendering. Es werden teilweise gespeicherte Bitmaps gezeichnet und was damit verbunden ist.
Private andere, System - das ist etwas, das wir überhaupt nicht beeinflussen können, und in der Tat alles andere, was nicht sehr kategorisierbar ist.
Wenn wir über native Bibliotheken sprechen, nehmen wir an, Sie können eine leere Anwendung verwenden ... Sie können die übliche Anwendung verwenden, die wir haben, und dumpsys daraus entnehmen, um festzustellen, dass 146 Megabyte erforderlich sind. Und wenn Sie etwas schneiden ... insbesondere habe ich die beiden größten nativen Bibliotheken, die wir insgesamt 15 Megabyte haben, genommen und gesägt und danach Dumpsys genommen. Sie können leicht erkennen, dass wir den Verbrauch aus dem Native Heap und verloren haben vom Code. Das heißt, mit einer so einfachen Geste haben wir uns etwa 35 Megabyte gespart. Nicht schlimm genug.
Streams. Lassen Sie uns den einfachsten Test machen. Es gibt eine leere Anwendung, und es gibt dieselbe leere Anwendung, in der wir eine Schleife erstellen, die einen neuen Thread () ausführt, fünf Sekunden darin schläft und diesen Thread startet. Sie können sehen, dass in diesem Fall der Stapel stark aufgefüllt wird. Das heißt, wir können diese ganze Sache beeinflussen, aber indirekt, indem wir die Anzahl der Threads im Java-Code reduzieren. Das heißt, durch Java-Objekte, einschließlich der Beeinflussung all dieser Positionen, die sich in anderen Elementen befinden.
Wenn Sie weiterhin über Threads sprechen, können Sie leicht sehen, was Sie für Threads haben und was sie in der Anwendung tun. Es gibt verschiedene Werkzeuge. Sie können dieselbe Systrace verwenden. Sie können einfach die Konsole verwenden, um die ID Ihres Prozesses zu ermitteln und ps anhand der Threads im System abzurufen.
Wenn Sie gut abschneiden und alle Arten von ThreadFactory verwenden, um Ihre Threads zu benennen, können Sie verstehen, was Sie haben sollten, was nicht, und so das Ganze reduzieren, da es besonders bedeutungslos ist, 100 Threads in der Anwendung zu haben.
Was kann man noch tun? Es gibt eine Reihe bekannter Akkordeon-Tipps: Achten Sie auf Lecks, verwenden Sie Pools, erstellen Sie keine Objekte, wenn Sie dies nicht benötigen, und all dieser Unsinn, all dies gilt. Großartig.
Es besteht eine gute Korrelation zwischen dem Speicherbedarf Ihrer Anwendung und ihrer Größe. Das heißt, je größer Ihre Anwendung ist, desto mehr Speicher wird verbraucht. Reduzieren Sie also auf einfache Weise das Gewicht der APK, reduzieren Sie das Gewicht von .dex, reduzieren Sie .so, entfernen Sie alles, was entfernt werden kann.
. , , , . , ? — — , . , , . . — .
dumpsys, , , . , , View, WebView, Assets, .
, , , , , SharedPreference SQLite - , , , .
, , Assets. , , – . 1,5 . -, , . .
— WebView. , WebView, , dumpsys, 100 , . , , - , , 300 — . , WebView , . -.
Google . . WebView, Google, - . WebView. .
Google Go, Android Go-. , - layout , . , , , Chrome Tabs, Chrome . .
Android Go, ? , Android Go, .
Es gibt verschiedene Möglichkeiten. -, , , 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 , , . , , .
Die beste Lösung ist also die zweite Anwendung. Allerdings werden nur wenige Menschen Ressourcen dafür ausgeben, während der tatsächliche Gewinn nicht klar ist. Vielleicht wird deine Geschichte nicht so traurig sein, denn ich hätte noch ein wenig Mühe, ich wäre geklettert, aber ich war schon unerträglich. Aber so eine Geschichte. In diesem relativ positiven Sinne können Sie es wahrscheinlich beenden. Danke an alle.