Οι συσκευές Android έχουν πολλούς πυρήνες, οπότε η σύνταξη ομαλών εφαρμογών είναι μια απλή εργασία για όλους, σωστά; Λανθασμένος. Καθώς τα πάντα στο Android μπορούν να γίνουν με πολλούς διαφορετικούς τρόπους, η επιλογή της καλύτερης επιλογής μπορεί να είναι δύσκολη. Αν θέλετε να επιλέξετε την πιο αποτελεσματική μέθοδο, πρέπει να ξέρετε τι συμβαίνει κάτω από την κουκούλα. Ευτυχώς, δεν χρειάζεται να βασίζεστε στα συναισθήματά σας ή στην αίσθηση της όσφρησης, καθώς υπάρχουν πολλά εργαλεία εκεί έξω που μπορούν να σας βοηθήσουν να βρείτε σημεία συμφόρησης, μετρώντας και περιγράφοντας τι συμβαίνει. Οι σωστά βελτιστοποιημένες και ομαλές εφαρμογές βελτιώνουν σημαντικά την εμπειρία χρήστη και εξαντλούν επίσης λιγότερη μπαταρία.
Ας δούμε πρώτα μερικούς αριθμούς για να εξετάσουμε πόσο σημαντική είναι η βελτιστοποίηση. Σύμφωνα με ένα Θέση Nimbledroid , Το 86% των χρηστών (συμπεριλαμβανομένου μου) έχουν απεγκαταστήσει εφαρμογές αφού τις χρησιμοποιούν μόνο μία φορά λόγω κακής απόδοσης. Εάν φορτώνετε κάποιο περιεχόμενο, έχετε λιγότερο από 11 δευτερόλεπτα για να το εμφανίσετε στον χρήστη. Μόνο κάθε τρίτος χρήστης θα σας δώσει περισσότερο χρόνο. Μπορεί επίσης να λάβετε πολλές κακές κριτικές στο Google Play εξαιτίας αυτού.
Ο έλεγχος της υπομονής των χρηστών σας είναι μια συντόμευση για απεγκατάσταση. Τιτίβισμα
Το πρώτο πράγμα που παρατηρεί κάθε χρήστης ξανά και ξανά είναι η ώρα έναρξης της εφαρμογής. Σύμφωνα με μια άλλη ανάρτηση Nimbledroid , από τις 100 κορυφαίες εφαρμογές, 40 ξεκινούν σε λιγότερο από 2 δευτερόλεπτα και 70 ξεκινούν σε λιγότερο από 3 δευτερόλεπτα. Επομένως, εάν είναι δυνατόν, θα πρέπει γενικά να προβάλλετε κάποιο περιεχόμενο το συντομότερο δυνατό και να καθυστερείτε λίγο τους ελέγχους και τις ενημερώσεις στο παρασκήνιο
Να θυμάστε πάντα, η πρόωρη βελτιστοποίηση είναι η ρίζα όλων των κακών. Επίσης, δεν πρέπει να χάνετε πάρα πολύ χρόνο με μικρο βελτιστοποίηση. Θα δείτε το μεγαλύτερο όφελος από τη βελτιστοποίηση κώδικα που εκτελείται συχνά. Για παράδειγμα, αυτό περιλαμβάνει το onDraw() λειτουργία, η οποία τρέχει κάθε καρέ, ιδανικά 60 φορές ανά δευτερόλεπτο. Το σχέδιο είναι η πιο αργή λειτουργία εκεί έξω, οπότε δοκιμάστε να σχεδιάσετε μόνο ό, τι έχετε. Περισσότερα για αυτό θα έρθουν αργότερα.
Συμβουλές απόδοσης
Αρκετή θεωρία, εδώ είναι μια λίστα με μερικά από τα πράγματα που πρέπει να λάβετε υπόψη εάν η απόδοση έχει σημασία για εσάς.
1. String εναντίον StringBuilder
Ας υποθέσουμε ότι έχετε μια χορδή και για κάποιο λόγο θέλετε να προσθέσετε περισσότερες χορδές σε αυτήν 10 χιλιάδες φορές. Ο κωδικός θα μπορούσε να μοιάζει κάπως έτσι.
String string = 'hello'; for (int i = 0; i <10000; i++) { string += ' world'; } Μπορείτε να δείτε στις οθόνες του Android Studio πόσο αναποτελεσματική μπορεί να είναι η συνένωση String. Υπάρχουν τόνοι συλλογών απορριμάτων (GC).
Αυτή η λειτουργία διαρκεί περίπου 8 δευτερόλεπτα στη αρκετά καλή συσκευή μου, η οποία διαθέτει Android 5.1.1. Ο πιο αποτελεσματικός τρόπος επίτευξης του ίδιου στόχου είναι να χρησιμοποιήσετε ένα StringBuilder, όπως αυτό.
StringBuilder sb = new StringBuilder('hello'); for (int i = 0; i <10000; i++) { sb.append(' world'); } String string = sb.toString(); Στην ίδια συσκευή αυτό συμβαίνει σχεδόν αμέσως, σε λιγότερο από 5ms. Οι οπτικοποιήσεις CPU και Memory είναι σχεδόν εντελώς επίπεδες, οπότε μπορείτε να φανταστείτε πόσο μεγάλη είναι αυτή η βελτίωση. Παρατηρήστε, ωστόσο, ότι για να επιτύχουμε αυτήν τη διαφορά, έπρεπε να προσθέσουμε 10 χιλιάδες χορδές, τις οποίες μάλλον δεν κάνετε συχνά. Σε περίπτωση που προσθέσετε μόνο δύο χορδές μία φορά, δεν θα δείτε καμία βελτίωση. Παρεμπιπτόντως, εάν κάνετε:
String string = 'hello' + ' world'; Μετατρέπεται εσωτερικά σε StringBuilder, οπότε θα λειτουργήσει μια χαρά.
Ίσως αναρωτιέστε, γιατί ο συνδυασμός Strings με τον πρώτο τρόπο είναι τόσο αργός; Προκαλείται από το γεγονός ότι οι χορδές είναι αμετάβλητες, οπότε μόλις δημιουργηθούν, δεν μπορούν να αλλάξουν. Ακόμα κι αν νομίζετε ότι αλλάζετε την τιμή μιας συμβολοσειράς, δημιουργείτε πραγματικά μια νέα συμβολοσειρά με τη νέα τιμή. Σε ένα παράδειγμα όπως:
String myString = 'hello'; myString += ' world'; Αυτό που θα λάβετε στη μνήμη δεν είναι το 1 String «hello world», αλλά στην πραγματικότητα 2 Strings. Το String myString θα περιέχει το “hello world”, όπως θα περίμενε κανείς. Ωστόσο, η αρχική συμβολοσειρά με την τιμή 'γεια' είναι ακόμα ζωντανή, χωρίς καμία αναφορά σε αυτήν, περιμένει να συλλεχθούν σκουπίδια. Αυτός είναι επίσης ο λόγος για τον οποίο πρέπει να αποθηκεύετε κωδικούς πρόσβασης σε μια συστοιχία char αντί για ένα String. Εάν αποθηκεύσετε έναν κωδικό πρόσβασης ως συμβολοσειρά, θα παραμείνει στη μνήμη σε μορφή αναγνώσιμη από τον άνθρωπο μέχρι το επόμενο GC για απρόβλεπτο χρονικό διάστημα. Πίσω στο αμετάβλητο που περιγράφηκε παραπάνω, το String θα παραμείνει στη μνήμη ακόμα και αν του αντιστοιχίσετε άλλη τιμή μετά τη χρήση του. Εάν, ωστόσο, αδειάσετε τον πίνακα char μετά τη χρήση του κωδικού πρόσβασης, θα εξαφανιστεί από παντού.
2. Επιλογή του σωστού τύπου δεδομένων
Πριν ξεκινήσετε να γράφετε κώδικα, θα πρέπει να αποφασίσετε ποιοι τύποι δεδομένων θα χρησιμοποιήσετε για τη συλλογή σας. Για παράδειγμα, θα πρέπει να χρησιμοποιήσετε ένα Vector ή ένα ArrayList; Λοιπόν, εξαρτάται από το usecase σας. Εάν χρειάζεστε μια συλλογή ασφαλούς νήματος, η οποία θα επιτρέπει μόνο ένα νήμα να δουλεύει μαζί του, θα πρέπει να επιλέξετε ένα Vector, καθώς είναι συγχρονισμένο. Σε άλλες περιπτώσεις πιθανότατα θα πρέπει να κολλήσετε σε ένα ArrayList, εκτός εάν έχετε πραγματικά συγκεκριμένο λόγο να χρησιμοποιήσετε διανύσματα.
Τι γίνεται με την περίπτωση όταν θέλετε μια συλλογή με μοναδικά αντικείμενα; Λοιπόν, πιθανότατα θα πρέπει να επιλέξετε ένα Set. Δεν μπορούν να περιέχουν αντίγραφα από το σχεδιασμό, οπότε δεν θα χρειαστεί να το φροντίσετε μόνοι σας. Υπάρχουν πολλοί τύποι σετ, οπότε επιλέξτε ένα που ταιριάζει στη θήκη χρήσης σας. Για μια απλή ομάδα μοναδικών αντικειμένων, μπορείτε να χρησιμοποιήσετε ένα HashSet. Εάν θέλετε να διατηρήσετε τη σειρά των αντικειμένων στα οποία εισήχθησαν, επιλέξτε ένα LinkedHashSet. Α TreeSet ταξινομεί τα στοιχεία αυτόματα, οπότε δεν θα χρειαστεί να καλέσετε μεθόδους ταξινόμησης σε αυτό. Θα πρέπει επίσης να ταξινομήσετε τα στοιχεία αποτελεσματικά, χωρίς να χρειάζεται να το σκεφτείτε αλγόριθμοι ταξινόμησης .
- 5 κανόνες προγραμματισμού του Rob Pike
Η ταξινόμηση ακέραιων ή χορδών είναι αρκετά απλή. Ωστόσο, τι γίνεται αν θέλετε να ταξινομήσετε μια τάξη με κάποια ιδιότητα; Ας υποθέσουμε ότι γράφετε μια λίστα με τα γεύματα που τρώτε και αποθηκεύετε τα ονόματα και τις χρονικές τους σφραγίδες. Πώς θα ταξινομούσατε τα γεύματα με χρονική σήμανση από το χαμηλότερο στο υψηλότερο; Ευτυχώς, είναι πολύ απλό. Αρκεί να εφαρμόσετε το Comparable διεπαφή στο Meal τάξη και παράκαμψη του compareTo() λειτουργία. Για να ταξινομήσετε τα γεύματα με τη χαμηλότερη χρονική σήμανση στο υψηλότερο, θα μπορούσαμε να γράψουμε κάτι σαν αυτό.
@Override public int compareTo(Object object) { Meal meal = (Meal) object; if (this.timestamp meal.getTimestamp()) { return 1; } return 0; } 3. Ενημερώσεις τοποθεσίας
Υπάρχουν πολλές εφαρμογές εκεί έξω που συλλέγουν την τοποθεσία του χρήστη. Θα πρέπει να χρησιμοποιήσετε το API υπηρεσιών τοποθεσίας Google για το σκοπό αυτό, το οποίο περιέχει πολλές χρήσιμες λειτουργίες. Υπάρχει ένα ξεχωριστό άρθρο σχετικά με τη χρήση του, οπότε δεν θα το επαναλάβω.
Θα ήθελα απλώς να τονίσω ορισμένα σημαντικά σημεία από την άποψη της απόδοσης.
Πρώτα απ 'όλα, χρησιμοποιήστε μόνο την πιο ακριβή τοποθεσία όπως χρειάζεστε. Για παράδειγμα, εάν κάνετε κάποια πρόβλεψη καιρού, δεν χρειάζεστε την πιο ακριβή τοποθεσία. Η απόκτηση μιας πολύ τραχιάς περιοχής με βάση το δίκτυο είναι ταχύτερη και πιο αποδοτική μπαταρία. Μπορείτε να το επιτύχετε ορίζοντας την προτεραιότητα σε LocationRequest.PRIORITY_LOW_POWER.
Μπορείτε επίσης να χρησιμοποιήσετε μια συνάρτηση LocationRequest ονομάζεται setSmallestDisplacement(). Εάν ορίσετε αυτό σε μετρητές, η εφαρμογή σας δεν θα ειδοποιηθεί για αλλαγή τοποθεσίας εάν ήταν μικρότερη από τη δεδομένη τιμή. Για παράδειγμα, εάν έχετε έναν χάρτη με κοντινά εστιατόρια γύρω σας και ορίσετε τη μικρότερη μετατόπιση στα 20 μέτρα, η εφαρμογή δεν θα υποβάλει αιτήματα για έλεγχο εστιατορίων εάν ο χρήστης περπατάει σε ένα δωμάτιο. Τα αιτήματα θα ήταν άχρηστα, καθώς ούτως ή άλλως δεν θα υπήρχε νέο κοντινό εστιατόριο.
Ο δεύτερος κανόνας είναι να ζητάτε ενημερώσεις τοποθεσίας τόσο συχνά όσο τις χρειάζεστε. Αυτό είναι αρκετά αυτονόητο. Εάν δημιουργείτε πραγματικά αυτήν την εφαρμογή πρόγνωσης καιρού, δεν χρειάζεται να ζητάτε την τοποθεσία κάθε λίγα δευτερόλεπτα, καθώς πιθανότατα δεν έχετε τέτοιες ακριβείς προβλέψεις (επικοινωνήστε μαζί μου εάν το κάνετε). Μπορείτε να χρησιμοποιήσετε το setInterval() λειτουργία για τον καθορισμό του απαιτούμενου διαστήματος στο οποίο η συσκευή θα ενημερώνει την εφαρμογή σας σχετικά με την τοποθεσία. Εάν πολλές εφαρμογές συνεχίζουν να ζητούν την τοποθεσία του χρήστη, κάθε εφαρμογή θα ειδοποιείται σε κάθε νέα ενημέρωση τοποθεσίας, ακόμη και αν έχετε υψηλότερη τιμή setInterval() σειρά. Για να αποτρέψετε την ειδοποίηση της εφαρμογής σας πολύ συχνά, φροντίστε να ορίζετε πάντα ένα ταχύτερο διάστημα ενημέρωσης με setFastestInterval().
Και τέλος, ο τρίτος κανόνας ζητά ενημερώσεις τοποθεσίας μόνο αν τις χρειάζεστε. Εάν εμφανίζετε κάποια κοντινά αντικείμενα στο χάρτη κάθε x δευτερόλεπτο και η εφαρμογή πηγαίνει στο παρασκήνιο, δεν χρειάζεται να γνωρίζετε τη νέα τοποθεσία. Δεν υπάρχει λόγος ενημέρωσης του χάρτη εάν ο χρήστης δεν μπορεί να τον δει ούτως ή άλλως. Φροντίστε να σταματήσετε να ακούτε για ενημερώσεις τοποθεσίας όταν χρειάζεται, κατά προτίμηση σε onPause(). Στη συνέχεια, μπορείτε να συνεχίσετε τις ενημερώσεις στο onResume().
4. Αιτήματα δικτύου
Υπάρχει μεγάλη πιθανότητα η εφαρμογή σας να χρησιμοποιεί το Διαδίκτυο για λήψη ή μεταφόρτωση δεδομένων. Εάν είναι, έχετε πολλούς λόγους να προσέξετε χειρισμός αιτημάτων δικτύου . Ένα από αυτά είναι τα δεδομένα κινητής τηλεφωνίας, τα οποία περιορίζονται σε πολλά άτομα και δεν πρέπει να τα σπαταλάτε.
Το δεύτερο είναι η μπαταρία. Τόσο τα δίκτυα WiFi όσο και τα δίκτυα κινητής τηλεφωνίας μπορούν να καταναλώνουν πολλά από αυτά, εάν χρησιμοποιούνται υπερβολικά. Ας υποθέσουμε ότι θέλετε να κατεβάσετε 1 kb. Για να υποβάλετε αίτημα δικτύου, πρέπει να ενεργοποιήσετε το ραδιόφωνο κινητής τηλεφωνίας ή WiFi και, στη συνέχεια, μπορείτε να πραγματοποιήσετε λήψη των δεδομένων σας. Ωστόσο, το ραδιόφωνο δεν θα αποκοιμηθεί αμέσως μετά τη λειτουργία. Θα παραμείνει σε αρκετά ενεργή κατάσταση για περίπου 20-40 ακόμη δευτερόλεπτα, ανάλογα με τη συσκευή και τον φορέα σας.
Λοιπόν, τι μπορείτε να κάνετε για αυτό; Σύνολο παραγωγής. Για να αποφύγετε να ξυπνάτε το ραδιόφωνο κάθε δύο δευτερόλεπτα, προωθήστε τα πράγματα που μπορεί να χρειαστεί ο χρήστης τα επόμενα λεπτά. Ο σωστός τρόπος παρτίδας είναι εξαιρετικά δυναμικός ανάλογα με την εφαρμογή σας, αλλά αν είναι δυνατόν, θα πρέπει να κατεβάσετε τα δεδομένα που μπορεί να χρειαστεί ο χρήστης τα επόμενα 3-4 λεπτά. Κάποιος θα μπορούσε επίσης να επεξεργαστεί τις παρτίδες παρτίδας με βάση τον τύπο διαδικτύου του χρήστη ή την κατάσταση φόρτισης. Για παράδειγμα, εάν ο χρήστης είναι συνδεδεμένος με WiFi κατά τη φόρτιση, μπορείτε να προβάλετε πολύ περισσότερα δεδομένα από ό, τι εάν ο χρήστης είναι σε κινητό Διαδίκτυο με χαμηλή μπαταρία. Η λήψη όλων αυτών των μεταβλητών μπορεί να είναι ένα δύσκολο πράγμα, το οποίο μόνο λίγοι άνθρωποι θα το έκαναν. Ευτυχώς όμως, υπάρχει το GCM Network Manager για τη διάσωση!
Ο διαχειριστής δικτύου GCM είναι μια πολύ χρήσιμη τάξη με πολλά προσαρμόσιμα χαρακτηριστικά. Μπορείτε εύκολα να προγραμματίσετε επαναλαμβανόμενες και μεμονωμένες εργασίες. Κατά την επανάληψη εργασιών μπορείτε να ορίσετε το χαμηλότερο, καθώς και το υψηλότερο διάστημα επανάληψης. Αυτό θα επιτρέψει την ομαδοποίηση όχι μόνο των αιτημάτων σας, αλλά και των αιτημάτων από άλλες εφαρμογές. Το ραδιόφωνο πρέπει να ξυπνά μόνο μία φορά ανά κάποια περίοδο και ενώ είναι σε λειτουργία, όλες οι εφαρμογές στην ουρά κατεβάζουν και ανεβάζουν ό, τι πρέπει. Αυτός ο Διαχειριστής γνωρίζει επίσης τον τύπο δικτύου και την κατάσταση φόρτισης της συσκευής, ώστε να μπορείτε να προσαρμόσετε ανάλογα. Μπορείτε να βρείτε περισσότερες λεπτομέρειες και δείγματα στο αυτό το άρθρο Σας παρακαλώ να το ελέγξετε. Ένα παράδειγμα εργασίας μοιάζει με αυτό:
Task task = new OneoffTask.Builder() .setService(CustomService.class) .setExecutionWindow(0, 30) .setTag(LogService.TAG_TASK_ONEOFF_LOG) .setUpdateCurrent(false) .setRequiredNetwork(Task.NETWORK_STATE_CONNECTED) .setRequiresCharging(false) .build(); Παρεμπιπτόντως, από το Android 3.0, εάν κάνετε αίτημα δικτύου στο κύριο νήμα, θα λάβετε ένα NetworkOnMainThreadException. Αυτό σίγουρα θα σας προειδοποιήσει να μην το κάνετε ξανά.
5. Αντανάκλαση
Ο προβληματισμός είναι η ικανότητα των τάξεων και των αντικειμένων να εξετάζουν τους δικούς τους κατασκευαστές, πεδία, μεθόδους και ούτω καθεξής. Χρησιμοποιείται συνήθως για συμβατότητα προς τα πίσω, για να ελέγξει εάν μια συγκεκριμένη μέθοδος είναι διαθέσιμη για μια συγκεκριμένη έκδοση λειτουργικού συστήματος. Εάν πρέπει να χρησιμοποιήσετε την αντανάκλαση για το σκοπό αυτό, φροντίστε να αποθηκεύσετε προσωρινά την απόκριση, καθώς η χρήση προβληματισμού είναι αρκετά αργή. Ορισμένες ευρέως χρησιμοποιούμενες βιβλιοθήκες χρησιμοποιούν επίσης το Reflection, όπως το Roboguice για ένεση εξάρτησης. Αυτός είναι ο λόγος για τον οποίο προτιμάτε το στιλέτο 2. Για περισσότερες λεπτομέρειες σχετικά με τον προβληματισμό, μπορείτε να ελέγξετε ξεχωριστή ανάρτηση .
πλαίσιο εφαρμογής web node js
6. Αυτόματο κιβώτιο
Το αυτόματο κιβώτιο και η αποσύνδεση είναι διαδικασίες μετατροπής ενός πρωτόγονου τύπου σε τύπο αντικειμένου ή αντίστροφα. Στην πράξη σημαίνει τη μετατροπή ενός int σε έναν ακέραιο. Για να το επιτύχει αυτό, ο μεταγλωττιστής χρησιμοποιεί το Integer.valueOf() λειτουργούν εσωτερικά. Η μετατροπή δεν είναι απλώς αργή, τα αντικείμενα παίρνουν επίσης πολύ περισσότερη μνήμη από τα πρωτόγονα ισοδύναμά τους. Ας δούμε έναν κώδικα.
Integer total = 0; for (int i = 0; i <1000000; i++) { total += i; } Ενώ αυτό διαρκεί κατά μέσο όρο 500 ms, η επανεγγραφή του για να αποφευχθεί η αυτόματη αποστολή θα επιταχύνει δραστικά.
int total = 0; for (int i = 0; i <1000000; i++) { total += i; } Αυτή η λύση τρέχει περίπου στα 2ms, δηλαδή 25 φορές πιο γρήγορα. Εάν δεν με πιστεύετε, δοκιμάστε το. Οι αριθμοί θα είναι προφανώς διαφορετικοί ανά συσκευή, αλλά θα πρέπει να είναι πολύ πιο γρήγορα. Και είναι επίσης ένα πολύ απλό βήμα για βελτιστοποίηση.
Εντάξει, πιθανώς δεν δημιουργείτε συχνά μια μεταβλητή τύπου Integer. Τι γίνεται όμως με τις περιπτώσεις που είναι πιο δύσκολο να αποφευχθούν; Όπως σε χάρτη, όπου πρέπει να χρησιμοποιήσετε αντικείμενα, όπως Map? Κοιτάξτε τη λύση που χρησιμοποιούν πολλοί άνθρωποι.
Map myMap = new HashMap(); for (int i = 0; i <100000; i++) { myMap.put(i, random.nextInt()); } Η εισαγωγή 100k τυχαίων ints στο χάρτη διαρκεί περίπου 250ms. Τώρα κοιτάξτε τη λύση με το SparseIntArray.
SparseIntArray myArray = new SparseIntArray(); for (int i = 0; i <100000; i++) { myArray.put(i, random.nextInt()); } Αυτό διαρκεί πολύ λιγότερο, περίπου 50ms. Είναι επίσης μια από τις ευκολότερες μεθόδους για τη βελτίωση της απόδοσης, καθώς δεν πρέπει να γίνει τίποτα περίπλοκο και ο κώδικας παραμένει επίσης αναγνώσιμος. Κατά την εκτέλεση μιας σαφούς εφαρμογής με την πρώτη λύση πήρα 13MB της μνήμης μου, χρησιμοποιώντας πρωτόγονα ints πήρε κάτι κάτω από 7MB, οπότε μόνο το μισό από αυτό.
Το SparseIntArray είναι μόνο μία από τις υπέροχες συλλογές που μπορούν να σας βοηθήσουν να αποφύγετε την αυτόματη εμφύτευση. Ένας χάρτης όπως Map θα μπορούσε να αντικατασταθεί από SparseLongArray, καθώς η τιμή του χάρτη είναι τύπου Long. Αν κοιτάξετε το πηγαίος κώδικας από SparseLongArray, θα δείτε κάτι πολύ ενδιαφέρον. Κάτω από την κουκούλα, είναι βασικά ένα ζευγάρι συστοιχιών. Μπορείτε επίσης να χρησιμοποιήσετε ένα SparseBooleanArray ομοίως.
Εάν διαβάσετε τον πηγαίο κώδικα, μπορεί να έχετε παρατηρήσει μια σημείωση που να λέει ότι SparseIntArray μπορεί να είναι πιο αργό από το HashMap. Έχω πειραματιστεί πολύ, αλλά για μένα SparseIntArray ήταν πάντα καλύτερη τόσο στη μνήμη όσο και στην απόδοση. Υποθέτω ότι εξαρτάται από εσάς που επιλέγετε, πειραματιστείτε με τις περιπτώσεις χρήσης σας και δείτε ποια σας ταιριάζει περισσότερο. Σίγουρα έχετε το SparseArrays στο μυαλό σας όταν χρησιμοποιείτε χάρτες.
7. OnDraw
Όπως είπα παραπάνω, όταν βελτιστοποιείτε την απόδοση, πιθανότατα θα δείτε το μεγαλύτερο όφελος στη βελτιστοποίηση κώδικα που εκτελείται συχνά. Μία από τις λειτουργίες που εκτελούνται πολύ είναι onDraw(). Μπορεί να μην σας εκπλήσσει το γεγονός ότι είναι υπεύθυνο για την προβολή προβολών στην οθόνη. Καθώς οι συσκευές λειτουργούν συνήθως στα 60 fps, η λειτουργία εκτελείται 60 φορές ανά δευτερόλεπτο. Κάθε πλαίσιο έχει 16 ms για πλήρη διαχείριση, συμπεριλαμβανομένης της προετοιμασίας και του σχεδιασμού του, οπότε θα πρέπει πραγματικά να αποφεύγετε τις αργές λειτουργίες. Μόνο το κύριο νήμα μπορεί να τραβήξει στην οθόνη, οπότε θα πρέπει να αποφύγετε να κάνετε ακριβές λειτουργίες σε αυτό. Εάν παγώσετε το κύριο νήμα για αρκετά δευτερόλεπτα, ενδέχεται να εμφανιστεί ο διάσημος διάλογος Application Not Responsing (ANR). Για αλλαγή μεγέθους εικόνων, εργασίας βάσης δεδομένων κ.λπ., χρησιμοποιήστε ένα νήμα φόντου.
Έχω δει μερικούς ανθρώπους να προσπαθούν να συντομεύσουν τον κώδικά τους, πιστεύοντας ότι θα είναι πιο αποτελεσματικό με αυτόν τον τρόπο. Αυτό σίγουρα δεν είναι ο τρόπος να πάει, καθώς ο συντομότερος κώδικας δεν σημαίνει ταχύτερος κώδικας. Σε καμία περίπτωση δεν πρέπει να μετράτε την ποιότητα του κωδικού με τον αριθμό των γραμμών.
Ένα από τα πράγματα που πρέπει να αποφύγετε στο onDraw() εκχωρεί αντικείμενα όπως το Paint. Προετοιμάστε τα πάντα στον κατασκευαστή, ώστε να είναι έτοιμο κατά τη σχεδίαση. Ακόμα κι αν έχετε onDraw() βελτιστοποιημένο, θα πρέπει να το καλείτε όσο συχνά πρέπει. Τι είναι καλύτερο από την κλήση μιας βελτιστοποιημένης λειτουργίας; Λοιπόν, δεν καλεί καθόλου λειτουργία. Σε περίπτωση που θέλετε να σχεδιάσετε κείμενο, υπάρχει μια αρκετά καλή λειτουργία βοηθού που ονομάζεται drawText(), όπου μπορείτε να καθορίσετε πράγματα όπως το κείμενο, τις συντεταγμένες και το χρώμα του κειμένου.
8. ViewHolders
Ίσως το γνωρίζετε αυτό, αλλά δεν μπορώ να το παραλείψω. Το μοτίβο σχεδίασης Viewholder είναι ένας τρόπος για να κάνετε ομαλότερες τις κυλιόμενες λίστες. Είναι ένα είδος προβολής προσωρινής αποθήκευσης, το οποίο μπορεί να μειώσει σοβαρά τις κλήσεις προς findViewById() και διογκώνοντας τις προβολές αποθηκεύοντάς τις. Μπορεί να μοιάζει κάπως έτσι.
static class ViewHolder { TextView title; TextView text; public ViewHolder(View view) { title = (TextView) view.findViewById(R.id.title); text = (TextView) view.findViewById(R.id.text); } } Στη συνέχεια, μέσα στο getView() λειτουργία του προσαρμογέα σας, μπορείτε να ελέγξετε εάν έχετε μια χρήσιμη προβολή. Εάν όχι, δημιουργείτε ένα.
ViewHolder viewHolder; if (convertView == null) { convertView = inflater.inflate(R.layout.list_item, viewGroup, false); viewHolder = new ViewHolder(convertView); convertView.setTag(viewHolder); } else { viewHolder = (ViewHolder) convertView.getTag(); } viewHolder.title.setText('Hello World'); Μπορείτε να βρείτε πολλές χρήσιμες πληροφορίες σχετικά με αυτό το μοτίβο στο Διαδίκτυο. Μπορεί επίσης να χρησιμοποιηθεί σε περιπτώσεις όπου η προβολή λίστας περιέχει πολλούς διαφορετικούς τύπους στοιχείων, όπως ορισμένες κεφαλίδες ενότητας.
9. Αλλαγή μεγέθους εικόνων
Οι πιθανότητες είναι ότι η εφαρμογή σας θα περιέχει μερικές εικόνες. Σε περίπτωση που κάνετε λήψη ορισμένων JPG από τον Ιστό, μπορεί να έχουν πραγματικά τεράστιες αναλύσεις. Ωστόσο, οι συσκευές στις οποίες θα εμφανίζονται θα είναι πολύ μικρότερες. Ακόμα και αν τραβήξετε μια φωτογραφία με την κάμερα της συσκευής σας, πρέπει να μειωθεί το μέγεθος πριν από την εμφάνιση, καθώς η ανάλυση της φωτογραφίας είναι πολύ μεγαλύτερη από την ανάλυση της οθόνης. Η αλλαγή μεγέθους των εικόνων πριν από την προβολή τους είναι σημαντικό. Εάν προσπαθήσετε να τις εμφανίσετε σε πλήρεις αναλύσεις, θα εξαντλήσατε τη μνήμη αρκετά γρήγορα. Εκεί είναι γραμμένο πολύ για την αποτελεσματική εμφάνιση bitmap στα έγγραφα Android, θα προσπαθήσω να το συνοψίσω.
Έχετε λοιπόν ένα bitmap, αλλά δεν γνωρίζετε τίποτα γι 'αυτό. Υπάρχει μια χρήσιμη σημαία των Bitmaps που ονομάζεται inJustDecodeBounds στην υπηρεσία σας, η οποία σας επιτρέπει να μάθετε την ανάλυση του bitmap. Ας υποθέσουμε ότι το bitmap σας είναι 1024x768 και το ImageView που χρησιμοποιείται για την εμφάνισή του είναι μόλις 400x300. Θα πρέπει να συνεχίσετε να διαιρείτε την ανάλυση του bitmap με 2 έως ότου είναι ακόμα μεγαλύτερο από το δεδομένο ImageView. Εάν το κάνετε, θα υποδείξει το bitmap με συντελεστή 2, δίνοντάς σας ένα bitmap 512x384. Το bitmap κάτω του δείγματος χρησιμοποιεί μνήμη 4x λιγότερη, η οποία θα σας βοηθήσει πολύ να αποφύγετε το περίφημο σφάλμα OutOfMemory.
Τώρα που ξέρετε πώς να το κάνετε, δεν πρέπει να το κάνετε. … Τουλάχιστον, όχι εάν η εφαρμογή σας βασίζεται σε μεγάλο βαθμό στις εικόνες και δεν είναι μόνο 1-2 εικόνες. Αποφύγετε σίγουρα πράγματα όπως το μέγεθος και την ανακύκλωση εικόνων με μη αυτόματο τρόπο, χρησιμοποιήστε μερικές βιβλιοθήκες τρίτων για αυτό. Τα πιο δημοφιλή είναι Πικάσο από την πλατεία, Φορτωτής καθολικής εικόνας , Δροσερός από το Facebook ή το αγαπημένο μου, Γλιστρώ . Υπάρχει μια τεράστια ενεργή κοινότητα προγραμματιστών γύρω από αυτήν, ώστε να μπορείτε να βρείτε πολλά χρήσιμα άτομα στην ενότητα ζητημάτων στο GitHub επίσης.
10. Αυστηρή λειτουργία
Το Strict Mode είναι ένα πολύ χρήσιμο εργαλείο για προγραμματιστές για το οποίο δεν γνωρίζουν πολλά άτομα. Συνήθως χρησιμοποιείται για τον εντοπισμό αιτημάτων δικτύου ή προσβάσεων δίσκου από το κύριο νήμα. Μπορείτε να ορίσετε τι θέματα Η αυστηρή λειτουργία πρέπει να αναζητηθεί και ποια ποινή πρέπει να προκαλέσει. Ένα δείγμα google μοιάζει με αυτό:
public void onCreate() { if (DEVELOPER_MODE) { StrictMode.setThreadPolicy(new StrictMode.ThreadPolicy.Builder() .detectDiskReads() .detectDiskWrites() .detectNetwork() .penaltyLog() .build()); StrictMode.setVmPolicy(new StrictMode.VmPolicy.Builder() .detectLeakedSqlLiteObjects() .detectLeakedClosableObjects() .penaltyLog() .penaltyDeath() .build()); } super.onCreate(); } Αν θέλετε να εντοπίσετε κάθε πρόβλημα που μπορεί να εντοπίσει η Αυστηρή λειτουργία, μπορείτε επίσης να χρησιμοποιήσετε το detectAll(). Όπως με πολλές συμβουλές απόδοσης, δεν πρέπει να προσπαθήσετε να διορθώσετε τυφλά όλες τις αναφορές αυστηρής λειτουργίας. Απλώς διερευνήστε το και αν είστε βέβαιοι ότι δεν είναι πρόβλημα, αφήστε το μόνο. Επίσης, βεβαιωθείτε ότι χρησιμοποιείτε το Strict Mode μόνο για εντοπισμό σφαλμάτων και να το απενεργοποιείτε πάντα σε παραγωγικές εκδόσεις.
Απόδοση εντοπισμού σφαλμάτων: Ο Pro Way
Ας δούμε τώρα μερικά εργαλεία που μπορούν να σας βοηθήσουν να βρείτε σημεία συμφόρησης ή τουλάχιστον να δείξετε ότι κάτι δεν πάει καλά.
1. Οθόνη Android
Αυτό είναι ένα εργαλείο ενσωματωμένο στο Android Studio. Από προεπιλογή, μπορείτε να βρείτε το Android Monitor στην κάτω αριστερή γωνία και μπορείτε να κάνετε εναλλαγή μεταξύ 2 καρτελών εκεί. Logcat και οθόνες. Η ενότητα Οθόνες περιέχει 4 διαφορετικά γραφήματα. Δίκτυο, CPU, GPU και Μνήμη. Είναι αρκετά αυτονόητα, οπότε θα τα περάσω γρήγορα. Ακολουθεί ένα στιγμιότυπο οθόνης των γραφημάτων που έχουν ληφθεί ενώ αναλύεται κάποιο JSON κατά τη λήψη του.
Το τμήμα δικτύου δείχνει την εισερχόμενη και εξερχόμενη κίνηση σε KB / s. Το τμήμα CPU εμφανίζει τη χρήση της CPU σε ποσοστό. Η οθόνη GPU εμφανίζει τον χρόνο που απαιτείται για την απόδοση των πλαισίων ενός παραθύρου διεπαφής χρήστη. Αυτή είναι η πιο λεπτομερή οθόνη από αυτά τα 4, οπότε αν θέλετε περισσότερες λεπτομέρειες σχετικά με αυτό, διάβασε αυτό .
Τέλος έχουμε το Οθόνη μνήμης , το οποίο πιθανότατα θα χρησιμοποιήσετε περισσότερο. Από προεπιλογή, δείχνει την τρέχουσα ποσότητα ελεύθερης και εκχωρημένης μνήμης. Μπορείτε επίσης να αναγκάσετε μια συλλογή απορριμμάτων μαζί της, για να ελέγξετε εάν η ποσότητα της χρησιμοποιημένης μνήμης μειώνεται. Έχει ένα χρήσιμο χαρακτηριστικό που ονομάζεται Dump Java Heap, το οποίο θα δημιουργήσει ένα αρχείο HPROF το οποίο μπορεί να ανοίξει με το HPROF Πρόγραμμα προβολής και αναλυτής . Αυτό θα σας επιτρέψει να δείτε πόσα αντικείμενα έχετε εκχωρήσει, πόση μνήμη καταλαμβάνεται από αυτό και ίσως ποια αντικείμενα προκαλούν διαρροές μνήμης. Η εκμάθηση του τρόπου χρήσης αυτού του αναλυτή δεν είναι το πιο απλό έργο εκεί έξω, αλλά αξίζει τον κόπο. Το επόμενο πράγμα που μπορείτε να κάνετε με το Memory Monitor είναι να κάνετε κάποια χρονομέτρηση Allocation Tracking, την οποία μπορείτε να ξεκινήσετε και να σταματήσετε όπως θέλετε. Θα μπορούσε να είναι χρήσιμο σε πολλές περιπτώσεις, για παράδειγμα κατά την κύλιση ή την περιστροφή της συσκευής.
2. Υπέρβαση GPU
Αυτό είναι ένα απλό βοηθητικό εργαλείο, το οποίο μπορείτε να ενεργοποιήσετε στις Επιλογές προγραμματιστή μόλις ενεργοποιήσετε τη λειτουργία προγραμματιστή. Επιλέξτε Debug GPU overdraw, 'Show overdraw area' και η οθόνη σας θα έχει μερικά περίεργα χρώματα. Είναι εντάξει, αυτό πρέπει να συμβεί. Τα χρώματα σημαίνουν πόσες φορές μια συγκεκριμένη περιοχή υπερέβη. Το αληθινό χρώμα σημαίνει ότι δεν υπήρχε υπερανάληψη, αυτό πρέπει να στοχεύσετε. Το μπλε σημαίνει μία υπέρβαση, το πράσινο σημαίνει δύο, το ροζ τρία, το κόκκινο τέσσερα.
Ενώ το αληθινό χρώμα είναι το καλύτερο, θα βλέπετε πάντα κάποιες υπερβολές, ειδικά γύρω από κείμενα, συρτάρια πλοήγησης, διαλόγους και άλλα. Επομένως, μην προσπαθήσετε να το ξεφορτωθείτε πλήρως. Εάν η εφαρμογή σας είναι μπλε ή πρασινωπή, πιθανότατα είναι εντάξει. Ωστόσο, εάν δείτε πολύ κόκκινο σε ορισμένες απλές οθόνες, θα πρέπει να ερευνήσετε τι συμβαίνει. Μπορεί να είναι πάρα πολλά στοιβαγμένα στοιβαγμένα, αν συνεχίσετε να τα προσθέτετε αντί να τα αντικαθιστάτε. Όπως ανέφερα παραπάνω, το σχέδιο είναι το πιο αργό μέρος των εφαρμογών, οπότε δεν έχει νόημα να σχεδιάζετε κάτι εάν θα έχουν σχεδιαστεί περισσότερα από 3 επίπεδα. Μη διστάσετε να ρίξετε μια ματιά στις αγαπημένες σας εφαρμογές. Θα δείτε ότι ακόμη και οι εφαρμογές με πάνω από ένα δισεκατομμύριο λήψεις έχουν κόκκινες περιοχές, οπότε απλώς πάρτε το εύκολο όταν προσπαθείτε να βελτιστοποιήσετε.
3. Απόδοση GPU
Αυτό είναι ένα άλλο εργαλείο από τις επιλογές προγραμματιστή, που ονομάζεται Απόδοση GPU προφίλ . Μόλις το επιλέξετε, επιλέξτε 'Στην οθόνη ως μπαρ'. Θα παρατηρήσετε μερικές χρωματιστές ράβδους να εμφανίζονται στην οθόνη σας. Δεδομένου ότι κάθε εφαρμογή έχει ξεχωριστές γραμμές, περίεργα η γραμμή κατάστασης έχει τις δικές της, και σε περίπτωση που έχετε κουμπιά πλοήγησης λογισμικού, έχουν και τις δικές τους γραμμές. Τέλος πάντων, οι γραμμές ενημερώνονται καθώς αλληλεπιδράτε με την οθόνη.
Οι μπάρες αποτελούνται από 3-4 χρώματα και, σύμφωνα με τα έγγραφα του Android, το μέγεθός τους έχει σημασία. Όσο μικρότερο, τόσο το καλύτερο. Στο κάτω μέρος έχετε μπλε, το οποίο αντιπροσωπεύει τον χρόνο που χρησιμοποιείται για τη δημιουργία και την ενημέρωση των λιστών προβολής της προβολής. Εάν αυτό το τμήμα είναι πολύ ψηλό, αυτό σημαίνει ότι υπάρχει πολύ προσαρμοσμένο σχέδιο προβολής ή ότι έχει γίνει πολλή δουλειά στο onDraw() λειτουργίες. Εάν έχετε Android 4.0+, θα δείτε μια μοβ γραμμή πάνω από την μπλε. Αυτό αντιπροσωπεύει το χρόνο που αφιερώνεται για τη μεταφορά πόρων στο νήμα απόδοσης. Έπειτα έρχεται το κόκκινο μέρος, το οποίο αντιπροσωπεύει το χρόνο που αφιερώνει ο 2D renderer του Android, εκδίδοντας εντολές στο OpenGL για σχεδίαση και επανασχεδιασμό λιστών. Στην κορυφή βρίσκεται η πορτοκαλί γραμμή, η οποία αντιπροσωπεύει το χρόνο που η CPU περιμένει την GPU να ολοκληρώσει την εργασία της. Εάν είναι πολύ ψηλό, η εφαρμογή κάνει πολύ δουλειά στο GPU.
Εάν είστε αρκετά καλοί, υπάρχει ένα ακόμη χρώμα πάνω από το πορτοκάλι. Είναι μια πράσινη γραμμή που αντιπροσωπεύει το όριο των 16 ms. Καθώς ο στόχος σας θα πρέπει να εκτελεί την εφαρμογή σας στα 60 fps, έχετε 16 ms για να σχεδιάσετε κάθε καρέ. Εάν δεν το καταφέρετε, ορισμένα πλαίσια ενδέχεται να παραλειφθούν, η εφαρμογή θα μπορούσε να γίνει σπασμένη και ο χρήστης σίγουρα θα το προσέξει. Δώστε ιδιαίτερη προσοχή στις κινούμενες εικόνες και την κύλιση, εκεί είναι που έχει μεγαλύτερη σημασία η απαλότητα. Ακόμα κι αν μπορείτε να εντοπίσετε κάποια παραλειφθέντα καρέ με αυτό το εργαλείο, δεν θα σας βοηθήσει πραγματικά να καταλάβετε πού ακριβώς βρίσκεται το πρόβλημα.
4. Πρόγραμμα προβολής ιεραρχίας
Αυτό είναι ένα από τα αγαπημένα μου εργαλεία εκεί έξω, καθώς είναι πραγματικά ισχυρό. Μπορείτε να το ξεκινήσετε από το Android Studio μέσω Εργαλεία -> Android -> Android Device Monitor, ή είναι επίσης στο φάκελο sdk / εργαλεία ως 'monitor'. Μπορείτε επίσης να βρείτε ένα αυτόνομο hierarachyviewer εκτελέσιμο εκεί, αλλά καθώς έχει καταργηθεί θα πρέπει να ανοίξετε την οθόνη. Ωστόσο, ανοίγετε το Android Device Monitor, μεταβείτε στην προοπτική Hierarchy Viewer. Εάν δεν βλέπετε εφαρμογές που εκτελούνται στη συσκευή σας, εκεί είναι μερικά πράγματα που μπορείτε να κάνετε για να το διορθώσετε. Δοκιμάστε επίσης να κάνετε check out Αυτό θέμα νήματος, υπάρχουν άνθρωποι με όλα τα είδη των θεμάτων και κάθε είδους λύσεις. Κάτι πρέπει να δουλέψει και για εσάς.
Με το Hierarchy Viewer, μπορείτε να πάρετε μια πολύ τακτοποιημένη επισκόπηση των ιεραρχιών προβολής (προφανώς). Εάν βλέπετε κάθε διάταξη σε ξεχωριστό XML, ενδέχεται να εντοπίσετε εύκολα άχρηστες προβολές. Ωστόσο, εάν συνεχίζετε να συνδυάζετε τις διατάξεις, μπορεί εύκολα να προκαλέσει σύγχυση. Ένα εργαλείο σαν αυτό το καθιστά εύκολο να εντοπίσετε, για παράδειγμα, κάποιο RelativeLayout, το οποίο έχει μόνο 1 παιδί, ένα άλλο RelativeLayout. Αυτό κάνει ένα από αυτά αφαιρούμενο.
Αποφύγετε την κλήση requestLayout(), καθώς προκαλεί διάβαση ολόκληρης της ιεραρχίας προβολής, για να μάθετε πόσο μεγάλη πρέπει να είναι κάθε προβολή. Εάν υπάρχει κάποια σύγκρουση με τις μετρήσεις, η ιεραρχία μπορεί να διασχίζεται πολλές φορές, κάτι που αν συμβεί κατά τη διάρκεια κάποιου animation, σίγουρα θα κάνει ορισμένα πλαίσια να παραλειφθούν. Αν θέλετε να μάθετε περισσότερα σχετικά με τον τρόπο με τον οποίο το Android αντλεί τις απόψεις του, μπορείτε διάβασε αυτό . Ας δούμε μια προβολή όπως φαίνεται στο Hierarchy Viewer.
Η επάνω δεξιά γωνία περιέχει ένα κουμπί για μεγιστοποίηση της προεπισκόπησης της συγκεκριμένης προβολής σε αυτόνομο παράθυρο. Κάτω από αυτό μπορείτε επίσης να δείτε την πραγματική προεπισκόπηση της προβολής στην εφαρμογή. Το επόμενο στοιχείο είναι ένας αριθμός, που αντιπροσωπεύει πόσα παιδιά έχει μια δεδομένη προβολή, συμπεριλαμβανομένης της ίδιας της προβολής. Εάν επιλέξετε έναν κόμβο (κατά προτίμηση τον ριζικό) και πατήσετε 'Λήψη χρόνων διάταξης' (3 έγχρωμοι κύκλοι), θα έχετε συμπληρώσει 3 ακόμη τιμές, μαζί με χρωματιστούς κύκλους που φέρουν ετικέτα μέτρησης, διάταξης και σχεδίασης. Μπορεί να μην είναι σοκαριστικό το γεγονός ότι η φάση μέτρησης αντιπροσωπεύει το χρόνο που χρειάστηκε για να μετρηθεί η δεδομένη προβολή. Η φάση διάταξης αφορά τον χρόνο απόδοσης, ενώ το σχέδιο είναι η πραγματική λειτουργία σχεδίασης. Αυτές οι τιμές και τα χρώματα είναι σχετικά μεταξύ τους. Πράσινο σημαίνει ότι η προβολή αποδίδεται στην κορυφή 50% όλων των προβολών στο δέντρο. Το κίτρινο σημαίνει απόδοση στο πιο αργό 50% όλων των προβολών στο δέντρο, το κόκκινο σημαίνει ότι η δεδομένη προβολή είναι μία από τις πιο αργές. Καθώς αυτές οι τιμές είναι σχετικές, θα υπάρχουν πάντα κόκκινες. Απλά δεν μπορείτε να τα αποφύγετε.
Κάτω από τις τιμές που έχετε το όνομα κλάσης, όπως 'TextView', ένα εσωτερικό αναγνωριστικό προβολής του αντικειμένου και το android: id της προβολής, το οποίο ορίσατε στα αρχεία XML. Σας παροτρύνω να δημιουργήσετε μια συνήθεια να προσθέτετε αναγνωριστικά σε όλες τις προβολές, ακόμα κι αν δεν τα αναφέρετε στον κώδικα. Θα κάνει τον εντοπισμό των προβολών στο Hierarchy Viewer πολύ απλό και σε περίπτωση που έχετε αυτοματοποιημένες δοκιμές στο έργο σας, θα κάνει επίσης τη στόχευση των στοιχείων πολύ πιο γρήγορα. Αυτό θα εξοικονομήσει χρόνο για εσάς και τους συναδέλφους σας να τα γράψουν. Η προσθήκη αναγνωριστικών σε στοιχεία που προστίθενται σε αρχεία XML είναι αρκετά απλή. Τι γίνεται όμως με τα δυναμικά προστιθέμενα στοιχεία; Λοιπόν, αποδεικνύεται επίσης πολύ απλό. Απλώς δημιουργήστε ένα αρχείο ids.xml μέσα στο φάκελο τιμών σας και πληκτρολογήστε τα απαιτούμενα πεδία. Μπορεί να μοιάζει με αυτό:
setId(R.id.item_title)Στη συνέχεια, στον κώδικα, μπορείτε να χρησιμοποιήσετε το LinearLayouts. Δεν θα μπορούσε να είναι πιο απλό.
Υπάρχουν μερικά ακόμη πράγματα που πρέπει να προσέξετε κατά τη βελτιστοποίηση της διεπαφής χρήστη. Γενικά, πρέπει να αποφεύγετε τις βαθιές ιεραρχίες ενώ προτιμάτε ρηχά, ίσως και ευρεία. Μην χρησιμοποιείτε διατάξεις που δεν χρειάζεστε. Για παράδειγμα, μπορείτε πιθανώς να αντικαταστήσετε μια ομάδα ένθετων RelativeLayout με είτε a TableLayout, ή a LinearLayout. Μη διστάσετε να πειραματιστείτε με διαφορετικές διατάξεις, μην χρησιμοποιείτε πάντα RelativeLayout και
|_+_|. Επίσης, δοκιμάστε να δημιουργήσετε ορισμένες προσαρμοσμένες προβολές όταν χρειάζεται, μπορεί να βελτιώσει σημαντικά την απόδοση εάν γίνει καλά. Για παράδειγμα, γνωρίζατε ότι το Instagram δεν χρησιμοποιεί TextViews εμφάνιση σχολίων ;
Μπορείτε να βρείτε περισσότερες πληροφορίες σχετικά με το Hierarchy Viewer στο Ιστότοπος προγραμματιστών Android με περιγραφές διαφορετικών παραθύρων, χρησιμοποιώντας το εργαλείο Pixel Perfect κ.λπ. Ένα ακόμη πράγμα που θα ήθελα να επισημάνω είναι η καταγραφή των προβολών σε ένα αρχείο .psd, το οποίο μπορεί να γίνει με το κουμπί 'Λήψη επιπέδων παραθύρων'. Κάθε προβολή θα βρίσκεται σε ξεχωριστό επίπεδο, επομένως είναι πολύ απλό να το αποκρύψετε ή να το αλλάξετε στο Photoshop ή στο GIMP. Ω, αυτός είναι ένας άλλος λόγος για να προσθέσετε ένα αναγνωριστικό σε κάθε προβολή που μπορείτε. Θα κάνει τα επίπεδα να έχουν ονόματα που πραγματικά έχουν νόημα.
Θα βρείτε πολύ περισσότερα εργαλεία εντοπισμού σφαλμάτων στις επιλογές προγραμματιστή, επομένως σας συμβουλεύω να τα ενεργοποιήσετε και να δείτε τι κάνουν. Τι θα μπορούσε ενδεχομένως να πάει στραβά;
Ο ιστότοπος προγραμματιστών Android περιέχει ένα σύνολο βέλτιστες πρακτικές για απόδοση . Καλύπτουν πολλούς διαφορετικούς τομείς, συμπεριλαμβανομένης της διαχείρισης μνήμης, για τους οποίους δεν έχω μιλήσει πραγματικά. Το αγνόησα σιωπηλά, γιατί ο χειρισμός μνήμης και η παρακολούθηση διαρροών μνήμης είναι μια εντελώς ξεχωριστή ιστορία. Η χρήση μιας βιβλιοθήκης τρίτων για την αποτελεσματική προβολή εικόνων θα βοηθήσει πολύ, αλλά εάν εξακολουθείτε να έχετε προβλήματα μνήμης, ρίξτε μια ματιά Διαρροή καναρίνι φτιαγμένο από το Square, ή διαβάστε Αυτό .
Τυλίγοντας
Λοιπόν, αυτά ήταν τα καλά νέα. Το κακό νέο είναι, βελτιστοποιώντας Android οι εφαρμογές είναι πολύ πιο περίπλοκες. Υπάρχουν πολλοί τρόποι να κάνετε τα πάντα, οπότε θα πρέπει να είστε εξοικειωμένοι με τα πλεονεκτήματα και τα μειονεκτήματά τους. Συνήθως δεν υπάρχει λύση ασημένιας σφαίρας που έχει μόνο οφέλη. Μόνο με την κατανόηση του τι συμβαίνει πίσω από τα παρασκήνια θα μπορείτε να επιλέξετε την καλύτερη λύση για εσάς. Ακριβώς επειδή ο αγαπημένος προγραμματιστής σας λέει ότι κάτι είναι καλό, δεν σημαίνει απαραίτητα ότι είναι η καλύτερη λύση για εσάς. Υπάρχουν πολύ περισσότεροι τομείς που πρέπει να συζητηθούν και περισσότερα εργαλεία δημιουργίας προφίλ που είναι πιο προηγμένα, οπότε ενδέχεται να τους φτάσουμε την επόμενη φορά.
Βεβαιωθείτε ότι έχετε μάθει από τους κορυφαίους προγραμματιστές και κορυφαίες εταιρείες. Μπορείτε να βρείτε μερικές εκατοντάδες ιστολόγια μηχανικής στο αυτός ο σύνδεσμος . Προφανώς δεν είναι μόνο πράγματα που σχετίζονται με το Android, οπότε αν σας ενδιαφέρει μόνο το Android, πρέπει να φιλτράρετε το συγκεκριμένο ιστολόγιο. Θα συνιστούσα ανεπιφύλακτα τα blogs του Facebook και Ίνσταγκραμ . Ακόμα κι αν το UI Instagram σε Android είναι αμφισβητήσιμο, το ιστολόγιο της μηχανικής τους έχει μερικά πραγματικά ωραία άρθρα. Για μένα είναι φοβερό που είναι τόσο εύκολο να δούμε πώς γίνονται τα πράγματα σε εταιρείες που χειρίζονται εκατοντάδες εκατομμύρια χρήστες καθημερινά, οπότε η ανάγνωση των ιστολογίων τους φαίνεται τρελή. Ο κόσμος αλλάζει πολύ γρήγορα, οπότε αν δεν προσπαθείτε συνεχώς να βελτιώσετε, να μάθετε από άλλους και να χρησιμοποιήσετε νέα εργαλεία, θα μείνετε πίσω. Όπως είπε ο Mark Twain, ένα άτομο που δεν διαβάζει δεν έχει κανένα πλεονέκτημα έναντι ενός ατόμου που δεν μπορεί να διαβάσει.
