2016-07-20 9 views
3

Nachdem ich angefangen habe, UI-Elemente aus der Android-Support-Design-Bibliothek zu verwenden, ist die App Anfangsladezeit wirklich langsam geworden (ca. 8 Sekunden!) Und ich bin mir wirklich nicht sicher warum.Android App langsam anfängliche Startzeit

Ich lief Method Tracking während der meisten Start (Es braucht Zeit für Android Studio zu starten den CPU-Monitor laufen) und fand es 4 Sekunden auf: dalvik.system.DexFile.openDexFile, Ich bin nicht sicher, warum das so lange dauert.

Irgendwelche Ideen? (Ich habe keinen Code hinzugefügt, da es eine Menge Code in meiner App gibt und ich weiß nicht, wo das Problem herkommt ...)

+0

Ich erlebte eine höhere Geschwindigkeit beim Erstellen der Release-App anstelle der Debug-Version, die ich normalerweise ausführen. Vielleicht könntest du das testen. – miqueloi

+0

Wie mache ich das? – TomerZ

+0

@miqueloi Huh, Interessant, es hat funktioniert, weißt du warum? – TomerZ

Antwort

6

Ich erlebte eine höhere Geschwindigkeit beim Erstellen der Release-App anstelle der Debug-Version, die ich normalerweise ausführen.

Ich bin mir nicht sicher, warum es funktioniert, aber ich denke, dass es wegen der Art sein muss, wie der Compiler die ext-Bibliotheken in die apk verbindet. Ich habe mal ein Interview mit Chet Haase gesehen, der einer der Entwickler auf der Android-Plattform ist, der erklärte, wie sie versuchten, die erste Aktivität auf der App so schnell wie möglich zu zeigen, um einen langweiligen Startbildschirm zu vermeiden. Vielleicht ist diese Funktion im Release-Build-Prozess aktiviert.

EDIT: Die richtige Antwort wird unten von @Embydextrous geschrieben. Dies liegt an der Dexierung der App im Debug-Modus.

+1

Release Build verwendet Proguard und entfernt unerwünschte Methoden. Also, nur einzelne .dex-Datei wird gemacht. Versuchen Sie, den Release-Build und den Debug-Build zu extrahieren. Sie werden wahrscheinlich mehrere Klassen * .dex-Dateien im Debug-Build und nur einen im Release-Build sehen. Ich habe auch eine Antwort auf diese Frage gestellt. – Embydextrous

+0

Ja, du hast es verstanden. Macht Sinn. – miqueloi

+0

http://stackoverflow.com/a/38476244/3529873 - Link zu meiner Antwort. – Embydextrous

0

Wie der Name andeutet, ist openDexFile android Prozess, der Methode von Dex-Datei lädt, desto größer und je mehr Dateien, desto länger laden.

So ist meine Antwort auf Ihre Frage nur Anzahl von Methoden reduzieren Sie haben und lieber faul Last von Bibliotheken, anstatt sie in Anwendung

Anstatt also die Initialisierung Ihre Netto-lib in App.onCreate initialisieren es auf erstes Anfordern der Initialisierung Erstellen Sie Ihre Datenbank erst, wenn sie benötigt wird.

auch Android verwenden: windowBackground in Ihrer App thame Benutzer preloader zu zeigen, statt Weißbild :)

Wie bessere Methode zählt, um zu sehen:

In Android Studio unter Plugins installieren "Android Methoden Count", dass ist sehr einfach plugi, und ich denke, dass sein Name vorschlagen, was es tut :)

Jetzt geben Sie Ihr Know-how von Ihrem Projekt reduzieren, Anzahl der Bibliotheken, die Sie gerade verwenden, möchten Sie vielleicht grapel-> root verwenden -> Aufgaben-> Android-> AndroidDependencies, um zu sehen, welche zusätzlichen Bibliotheken zu Ihrem Projekt hinzugefügt werden.

Denken Sie auch daran, keine Kern-Play-Dienste und nur die Bibliotheken zu verwenden, die Sie tatsächlich verwenden.

4

Dies geschieht normalerweise mit Debug-Builds, kann aber auch mit Release-Builds passieren.

Bei mehreren Dex-Dateien. Die primäre dex-Datei (classes.dex) wird zuerst geladen, die dann andere dex-Dateien lädt.

Es wird normalerweise nicht in Release-Builds angezeigt, da proguard ungenutzte Methoden entfernt und die Anzahl der Methoden reduziert, sodass nur ein einzelner .dex erstellt wird. Im Debug-Build-Programm wird nicht verwendet, daher gibt es mehrere Dex-Dateien.

Allerdings gibt es in sehr großen Apps wie AirBnb, Facebook, Twitter usw. mehrere Dex-Dateien. Und damit App-Launch-Verzögerungen, die mit dex-Optimierern optimiert werden können.