Οι περισσότεροι συνηθισμένοι μύθοι βελτιστοποίησης Android Debunked

Υπάρχουν πολλοί οδηγοί διδασκαλίας έξω εκεί αφιερωμένοι στην αύξηση της απόδοσης Android, καθώς και γενικές συμβουλές βελτιστοποίησης. Ορισμένα από αυτά είναι νόμιμα και άλλα βασίζονται μόνο στη θεωρία ή σε ξεπερασμένες λειτουργικές μεθόδους στο σύστημα Android, ή είναι απλά ανοησίες. Αυτό περιλαμβάνει συστάσεις για εναλλαγή, τιμές που προστέθηκαν στο build.prop και μεταβλητές αλλαγές στον πυρήνα του Linux.

Υπάρχει ακόμη ένας τόνος "scripts βελτιστοποίησης" εκεί έξω, all-in-one flashable .zips που υπόσχονται να αυξήσουν σημαντικά την απόδοση, τη διάρκεια ζωής της μπαταρίας και άλλα πράγματα. Ορισμένα από τα τσιμπήματα μπορούν πραγματικά να λειτουργούν, αλλά η πλειοψηφία τους είναι απλώς φαινόμενο placebo ή, χειρότερα, έχει αρνητικό αντίκτυπο στη συσκευή σας.

Αυτό δεν σημαίνει ότι οι άνθρωποι εκτοξεύουν σκοπίμως δέσμες ενεργειών - υπάρχουν σίγουρα ψευδείς εφαρμογές που καταβάλλονται στο Play Store, αλλά τα σενάρια βελτιστοποίησης που κυκλοφορούν στα φόρουμ του Android είναι εν γένει καλές προθέσεις, συμβαίνει ακριβώς ότι ο προγραμματιστής μπορεί να είναι άστοχα ενημερωμένος, ή απλώς πειραματίζοντας με διάφορα βελτιωτικά βελτιστοποίησης. Δυστυχώς, ένα είδος φαινόμενου χιονοστιβάδας τείνει να συμβεί, ειδικά σε σενάριο βελτιστοποίησης "all-in-one". Μια μικρή χούφτα τσίμπημα μπορεί στην πραγματικότητα να κάνει κάτι, ενώ ένα άλλο σενάριο τσίμπημα σε ένα σενάριο μπορεί να κάνει απολύτως τίποτα - όλα αυτά τα σενάρια μεταβιβάζονται ως μαγικές σφαίρες, χωρίς καμία πραγματική έρευνα για το τι λειτουργεί και τι δεν κάνει .

Έτσι, πολλά σενάρια βελτιστοποίησης all-in-one χρησιμοποιούν τις ίδιες μεθόδους, μερικές από τις οποίες είναι εντελώς ξεπερασμένες ή επιβλαβείς μακροπρόθεσμα. Εν ολίγοις, η πλειονότητα των σεναρίων βελτιστοποίησης "όλα σε ένα" δεν είναι παρά συνιστώμενες συνιστώσες, χωρίς σαφή ιδέα για το πώς ή γιατί αυτές οι βελτιστοποιήσεις "εργάζονται" χρήστες τότε αναβοσβήνουν τα σενάρια και ισχυρίζονται ότι η απόδοσή τους είναι ξαφνικά ταχύτερη ( όταν στην πραγματικότητα ήταν πολύ πιθανό η πολύ απλή πράξη επανεκκίνησης της συσκευής τους που προκάλεσε αύξηση της απόδοσης, καθώς όλα τα μέσα της μνήμης RAM της συσκευής καθαρίζονται) .

Σε αυτό το αποκλειστικό άρθρο Appuals, θα επισημάνω μερικές από τις συνηθέστερες συστάσεις για τη " βελτιστοποίηση" της απόδοσης Android και αν είναι απλά ένας μύθος ή ένα νόμιμο τσίμπημα για την απόδοση της συσκευής.

Ανταλαγή

Στην κορυφή της λίστας μυθών είναι το Android swap - το οποίο είναι αρκετά παράλογο από την άποψη ότι θεωρείται ως βελτιστοποίηση Android. Ο κύριος σκοπός του Swaps είναι να δημιουργήσει και να συνδέσει το αρχείο σελιδοποίησης, το οποίο θα ελευθερώσει χώρο αποθήκευσης στη μνήμη. Αυτό ακούγεται λογικό σε χαρτί, αλλά είναι πραγματικά εφαρμόσιμο σε ένα διακομιστή, ο οποίος έχει σχεδόν καθόλου διαδραστικότητα.

Όταν χρησιμοποιείτε την ανταλλαγή του τηλεφώνου σας Android τακτικά, αυτό θα οδηγήσει σε σοβαρές καθυστερήσεις που προέρχονται από τα πράγματα που γλιστρούν πέρα ​​από την κρυφή μνήμη. Φανταστείτε, για παράδειγμα, εάν μια εφαρμογή προσπαθεί να εμφανίσει ένα γραφικό, το οποίο είναι αποθηκευμένο στο swap, το οποίο τώρα πρέπει να φορτώσει εκ νέου τον δίσκο μετά την απελευθέρωση του χώρου τοποθετώντας την ανταλλαγή δεδομένων με μια άλλη εφαρμογή. Είναι πραγματικά βρώμικο.

Ορισμένοι λάτρεις της βελτιστοποίησης μπορούν να πουν ότι η ανταλλαγή δεν προσέφερε κανένα πρόβλημα, αλλά δεν είναι η ανταλλαγή των επιδόσεων - είναι ο ενσωματωμένος μηχανισμός Android lowmemorykiller, ο οποίος θα σκοτώνει τακτικά φουσκωμένες διαδικασίες υψηλής προτεραιότητας που δεν χρησιμοποιούνται. Το LMK σχεδιάστηκε ειδικά για το χειρισμό των συνθηκών χαμηλής μνήμης, χρησιμοποιείται από τη διαδικασία kswapd και γενικά σκοτώνει τις διεργασίες του χώρου του χρήστη. Αυτό είναι διαφορετικό από το OOMkiller (φονιάς εκτός της μνήμης), αλλά αυτό είναι ένα διαφορετικό θέμα εντελώς.

Το σημείο είναι ότι μια συσκευή με, για παράδειγμα, 1GB μνήμης RAM δεν μπορεί ποτέ να επιτύχει τα απαραίτητα δεδομένα απόδοσης σε μια ανταλλαγή, οπότε η ανταλλαγή δεν είναι απολύτως απαραίτητη στο Android. Η εφαρμογή του είναι απλώς γεμάτη με καθυστέρηση και οδηγεί σε υποβάθμιση της απόδοσης παρά στη βελτιστοποίηση της.

zRAM - ξεπερασμένη και δεν είναι πλέον αποτελεσματική

Το zRAM είναι μια αποδεδειγμένη και αποτελεσματική μέθοδος για βελτιστοποίηση συσκευών, για παλαιότερες συσκευές - σκέφτεστε συσκευές με KitKat που λειτουργούν με μόνο περίπου 512 MB μνήμης RAM. Το γεγονός ότι μερικοί άνθρωποι εξακολουθούν να περιλαμβάνουν zRAM tweaks σε σενάρια βελτιστοποίησης ή συνιστούν το zRAM ως ένα είδος σύγχρονης βελτιστοποίησης βελτιστοποίησης, είναι ένα παράδειγμα ανθρώπων που γενικά δεν ακολουθούν τα τελευταία επιχειρησιακά πρωτόκολλα.

Το zRAM προοριζόταν για πολλαπλών πυρήνων SoCs, όπως συσκευές με χρήση chipset MTK και 512 MB μνήμης RAM. Πολύ φτηνά κινεζικά τηλέφωνα, βασικά. Αυτό που κάνει βασικά το zRAM είναι να διαχωρίσει τον πυρήνα μέσω της ροής κρυπτογράφησης.

Όταν το zRAM χρησιμοποιείται σε παλαιότερες συσκευές με έναν μόνο πυρήνα, ακόμη και αν συνιστάται η χρήση zRAM σε τέτοιες συσκευές, οι μεγάλες ποσότητες καθυστέρησης τείνουν να εμφανίζονται. Αυτό συμβαίνει επίσης με την τεχνολογία KSM ( Kernel Same Page Merging), η οποία συνδυάζει πανομοιότυπες σελίδες μνήμης σε προσφορά για ελεύθερο χώρο. Αυτό στην πραγματικότητα συνιστάται από την Google, αλλά οδηγεί σε μεγαλύτερες καθυστερήσεις σε παλαιότερες συσκευές, επειδή οι συνεχώς ενεργοί core theads τρέχουν συνεχώς από τη μνήμη για να αναζητήσουν διπλές σελίδες. Βασικά, η προσπάθεια να τρέξει το tweak βελτιστοποίησης επιβραδύνει τη συσκευή ακόμη περισσότερο, ειρωνικά.

Seeder - ξεπερασμένη από το Android 3.0

Μια από τις πιο συζητημένες συμβουλές βελτιστοποίησης μεταξύ του Android devs είναι ο μηχανισμός σποράς και είμαστε βέβαιοι ότι κάποιος θα μπορούσε να προσπαθήσει να μας αποδείξει λάθος σε αυτό το θέμα - αλλά πρώτα πρέπει να εξετάσουμε το ιστορικό του σπαρτικού.

Ναι, υπάρχει ένας μεγάλος αριθμός αναφορών που δηλώνουν καλύτερη απόδοση Android μετά την εγκατάσταση σε πολύ μεγαλύτερες συσκευές Android . Ωστόσο, οι άνθρωποι για οποιοδήποτε λόγο πιστεύουν ότι αυτό σημαίνει ότι είναι επίσης μια εφαρμόσιμη βελτιστοποίηση για τις σύγχρονες συσκευές Android, η οποία είναι απολύτως παράλογη. Το γεγονός ότι ο Seeder εξακολουθεί να διατηρείται και προσφέρεται ως ένα " σύγχρονο" εργαλείο μείωσης καθυστέρησης είναι ένα παράδειγμα παραπληροφόρησης - αν και αυτό δεν είναι λάθος του προγραμματιστή του Seeder, καθώς ακόμη και η σελίδα του Play Store σημειώνει ότι ο Seeder είναι λιγότερο αποτελεσματικός μετά το Android 4.0+. Ωστόσο, για οποιονδήποτε λόγο, ο Seeder εξακολουθεί να εμφανίζεται σε συζητήσεις βελτιστοποίησης για σύγχρονα συστήματα Android.

Αυτό που κάνει ο Seeder βασικά για το Android 3.0 είναι η αντιμετώπιση ενός σφάλματος όπου το runtime του Android θα χρησιμοποιήσει ενεργά το / dev / random / αρχείο για να αποκτήσει την εντροπία. Το / dev / random / buffer θα γίνει ασταθές και το σύστημα θα μπλοκαριστεί μέχρι να γεμίσει την απαιτούμενη ποσότητα δεδομένων - σκεφτείτε μικρά πράγματα όπως οι διάφοροι αισθητήρες και κουμπιά στη συσκευή Android.

Ο συγγραφέας του Seeder πήρε το Linux-demon rngd και συντάχθηκε για το inastrolicil του Android ώστε να πάρει τυχαία δεδομένα από μια πολύ ταχύτερη και πιο προβλέψιμη / dev / urandom διαδρομή και να τα συγχωνεύσει σε dev / random / κάθε δευτερόλεπτο, χωρίς να επιτρέψει / dev / random / να εξαντληθεί. Αυτό είχε ως αποτέλεσμα ένα σύστημα Android που δεν αντιμετώπιζε έλλειψη εντροπίας, και έκανε πολύ πιο ομαλή.

Η Google έσπασε αυτό το σφάλμα μετά το Android 3.0, αλλά για κάποιο λόγο, ο Seeder εξακολουθεί να εμφανίζεται στις λίστες "συνιστώμενες τροποποιήσεις" για τη βελτιστοποίηση της απόδοσης του Android. Επιπλέον, η εφαρμογή Seeder έχει μερικές αναλογίες όπως το sEFix, οι οποίες περιλαμβάνουν τη λειτουργικότητα του Seeder, είτε χρησιμοποιούν το ίδιο rngd είτε το εναλλακτικό hasged, ή ακόμα και μόνο ένα σύμβολο μεταξύ των / dev / urandom και / dev / random. Αυτό είναι απολύτως άχρηστο για τα σύγχρονα συστήματα Android.

Ο λόγος που είναι άσκοπος είναι επειδή οι νεότερες εκδόσεις Android χρησιμοποιούν / dev / random / σε τρία βασικά στοιχεία - libcrypto, για κρυπτογράφηση συνδέσεων SSL, δημιουργία κλειδιών SSH κλπ. WPA_supplication / hostapd που δημιουργεί κλειδιά WEP / WPA και τέλος μια χούφτα βιβλιοθήκες για τη δημιουργία αναγνωριστικού για τη δημιουργία συστημάτων αρχείων EXT2 / EXT3 / EXT4.

Έτσι, όταν οι βελτιώσεις που βασίζονται σε Seeder ή Seeder περιλαμβάνονται στα σύγχρονα σενάρια βελτιστοποίησης Android, αυτό που συμβαίνει είναι η υποβάθμιση της απόδοσης της συσκευής, επειδή το rngd θα αφυπνίσει συνεχώς τη συσκευή και θα προκαλέσει αύξηση της συχνότητας CPU, η οποία φυσικά επηρεάζει αρνητικά την κατανάλωση μπαταρίας .

Odex

Το υλικολογισμικό αποθεμάτων στις συσκευές Android είναι σχεδόν πάντα Odx. Αυτό σημαίνει ότι παράλληλα με το πρότυπο πακέτο για εφαρμογές Android σε μορφή APK που βρίσκονται στο / system / app / and / system / priv-app /, έχουν τα ίδια ονόματα αρχείων με την επέκταση .odex. Τα αρχεία odex περιέχουν βελτιστοποιημένες εφαρμογές bytecode που έχουν ήδη περάσει από την εικονική μηχανή επικύρωσης και βελτιστοποίησης και στη συνέχεια καταγράφονται σε ξεχωριστό αρχείο που χρησιμοποιεί κάτι σαν το εργαλείο dexopt .

Έτσι, τα αρχεία ODX έχουν ως στόχο να αποφορτίζουν την εικονική μηχανή και να προσφέρουν μια γρήγορη εκτόξευση της εφαρμογής demed - από την άλλη, τα αρχεία ODEX εμποδίζουν τις τροποποιήσεις στο firmware και δημιουργούν προβλήματα με τις ενημερώσεις, γι 'αυτό και πολλά προσαρμοσμένα ROM όπως το LineageOS διανέμονται χωρίς ODEX .

Η δημιουργία αρχείων ODEX γίνεται με διάφορους τρόπους, όπως η χρήση του Odexer Tool - το πρόβλημα είναι ότι το καθαρά εικονικό αποτέλεσμα. Όταν το σύγχρονο σύστημα Android δεν εντοπίσει αρχεία Odx στον κατάλογο / system, το σύστημα θα τα δημιουργήσει και θα τα τοποθετήσει στον κατάλογο / system / dalvik-cache /. Αυτό είναι ακριβώς αυτό που συμβαίνει όταν, για παράδειγμα, αναβοσβήνει μια νέα έκδοση Android και δίνει το μήνυμα "Busy, Optimizing Applications" για λίγο.

Χαρακτηριστικά Lowmemorykiller

Το Multitasking στο Android διαφέρει από άλλα λειτουργικά συστήματα κινητών με την έννοια ότι βασίζεται σε ένα κλασσικό μοντέλο όπου οι εφαρμογές λειτουργούν ήσυχα στο παρασκήνιο και δεν υπάρχουν περιορισμοί στον αριθμό των εφαρμογών στο παρασκήνιο ( εκτός αν έχει οριστεί σε Επιλογές προγραμματιστή, αλλά αυτό είναι εν γένει συνιστάται) - επιπλέον, η λειτουργία της μετάβασης σε εκτέλεση υποβάθρου δεν σταματάει, αν και το σύστημα διατηρεί το δικαίωμα να σκοτώσει εφαρμογές φόντου σε καταστάσεις χαμηλής μνήμης ( βλ. όπου μιλήσαμε σχετικά με το lowmemorykiller και τον φονέα εκτός μνήμης νωρίτερα σε αυτό οδηγός) .

Για να επιστρέψετε στο μηχανισμό lowmemorykiller, το Android μπορεί να συνεχίσει να λειτουργεί με περιορισμένη μνήμη και έλλειψη διαμερισμάτων ανταλλαγής. Ο χρήστης μπορεί να συνεχίσει να εκκινεί εφαρμογές και να αλλάζει μεταξύ τους και το σύστημα θα σιωπά σιωπηλά τις μη χρησιμοποιούμενες εφαρμογές φόντου για να προσπαθήσει να απελευθερώσει μνήμη για ενεργές εργασίες.

Αυτό ήταν πολύ χρήσιμο για το Android στις πρώτες μέρες, αν και για κάποιο λόγο έγινε δημοφιλές με τη μορφή εφαρμογών-δολοφόνων, οι οποίες είναι γενικά πιο επιβλαβείς από ευεργετικές. Οι εφαρμογές δολοφόνων είτε ξυπνούν σε καθορισμένα χρονικά διαστήματα είτε εκτελούνται από το χρήστη και φαίνεται να απελευθερώνουν μεγάλες ποσότητες μνήμης RAM, κάτι που θεωρείται θετικό - η πιο ελεύθερη μνήμη RAM σημαίνει ταχύτερη συσκευή, σωστά; Αυτό δεν συμβαίνει ακριβώς με το Android, ωστόσο.

Στην πραγματικότητα, η κατοχή μεγάλου όγκου ελεύθερης μνήμης RAM μπορεί να είναι πραγματικά επιβλαβής για την απόδοση της συσκευής σας και τη διάρκεια ζωής της μπαταρίας. Όταν οι εφαρμογές αποθηκεύονται στη μνήμη RAM του Android, είναι πολύ πιο εύκολο να τις καλέσετε, να τις εκκινήσετε κλπ. Το σύστημα Android δεν χρειάζεται να αφιερώσει πολλούς πόρους για να μεταβείτε στην εφαρμογή, επειδή υπάρχει ήδη στη μνήμη.

Εξαιτίας αυτού, οι δολοφόνες δεν είναι τόσο δημοφιλείς όσο ήταν κάποτε, αν και οι αρχάριοι του Android εξακολουθούν να τείνουν να βασίζονται σε αυτά για κάποιο λόγο ( έλλειψη πληροφοριών, δυστυχώς) . Δυστυχώς, μια νέα τάση έχει αντικαταστήσει τις δολοφόνες εργασίας, την τάση των συντονισμών μηχανισμού χαμηλής ταχύτητας . Αυτό θα ήταν για παράδειγμα η εφαρμογή MinFreeManager και η κύρια ιδέα είναι να αυξηθεί η RAM πριν από το σύστημα ξεκινήσει να σκοτώνει εφαρμογές στο παρασκήνιο.

Έτσι, για παράδειγμα, η τυπική μνήμη RAM λειτουργεί στα σύνορα - 4, 8, 12, 24, 32 και 40 Mb και όταν συμπληρωθεί ο ελεύθερος χώρος αποθήκευσης των 40 MB, μία από τις αποθηκευμένες εφαρμογές που φορτώνονται στη μνήμη αλλά δεν εκτελούνται θα τερματιστεί.

Έτσι, βασικά, το Android θα έχει πάντα τουλάχιστον 40 MB διαθέσιμης μνήμης, το οποίο είναι αρκετό για να φιλοξενήσει μια ακόμη εφαρμογή πριν το lowmemorykiller ξεκινήσει τη διαδικασία εκκαθάρισης - πράγμα που σημαίνει ότι το Android θα καταβάλει πάντα τα δυνατά του για να χρησιμοποιήσει το μέγιστο διαθέσιμο RAM χωρίς να παρεμβαίνει εμπειρία χρήστη.

Δυστυχώς, αυτό που κάποιοι λάτρεις του homebrew άρχισαν να συνιστώνται είναι ότι η αξία θα αυξηθεί, για παράδειγμα, 100 MB πριν το LMK ξεκινήσει. Τώρα ο χρήστης θα χάσει πραγματικά RAM (100 - 40 = 60), οπότε αντί να χρησιμοποιήσετε αυτόν τον χώρο για να αποθηκεύσετε back- end εφαρμογές, το σύστημα θα κρατήσει αυτό το ποσό της μνήμης δωρεάν, χωρίς απολύτως κανένα σκοπό για αυτό.

Ο συντονισμός LKM μπορεί να είναι χρήσιμος για πολύ παλιότερες συσκευές με μνήμη RAM 512, αλλά ποιος είναι ο ιδιοκτήτης αυτών; Το 2GB είναι το μοντέρνο "φάσμα προϋπολογισμού", ακόμη και οι συσκευές 4GB RAM βλέπουν ως "μεσαία σειρά" αυτές τις μέρες, οπότε τα τσιμπήματα LMK είναι πραγματικά ξεπερασμένα και άχρηστα.

I / O τσιμπήματα

Σε πολλά σενάρια βελτιστοποίησης για Android θα βρείτε συχνά τροποποιήσεις που αφορούν το υποσύστημα I / O. Για παράδειγμα, μπορείτε να ρίξετε μια ματιά στο ThunderBolt! Script, που περιέχει αυτές τις γραμμές:

 echo 0> $ i / ουρά / περιστροφή. ηχώ 1024> $ i / ουρά / nr_requests; 

Η πρώτη γραμμή θα δώσει τις οδηγίες του I / O χρονοπρογραμματιστή για την αντιμετώπιση ενός SSD και το δεύτερο θα αυξήσει το μέγιστο μέγεθος της ουράς I / O από 128 σε 1024 - επειδή η μεταβλητή $ i περιέχει μια διαδρομή προς το δέντρο των συσκευών μπλοκ στο / sys και το σενάριο τρέχει σε βρόχο.

Μετά από αυτό, θα βρείτε μια γραμμή που σχετίζεται με τον προγραμματιστή CFQ:

 ηχώ 1> $ i / ουρά / iosched / back_seek_penalty; echo 1> $ i / ουρά / iosched / low_latency; ηχώ 1> $ i / ουρά / iosched / slice_idle; 

Αυτό ακολουθείται από περισσότερες γραμμές που ανήκουν σε άλλους σχεδιαστές, αλλά τελικά, οι δύο πρώτες εντολές είναι άσχετες επειδή:

Ένας σύγχρονος πυρήνας του Linux είναι σε θέση να καταλάβει τι είδους μέσο αποθήκευσης εργάζεται από προεπιλογή.

Μια μακρά ουρά εισόδου-εξόδου ( όπως το 1024) είναι άχρηστη σε μια σύγχρονη συσκευή Android, στην πραγματικότητα χωρίς νόημα της, ακόμη και στην επιφάνεια εργασίας - η οποία συνιστάται μόνο σε διακομιστές βαρέων επαγγελματικών υπηρεσιών . Το τηλέφωνό σας δεν είναι διακομιστής Linux βαρέως τύπου.

Για μια συσκευή Android, δεν υπάρχουν ουσιαστικά εφαρμογές προτεραιότητας στην είσοδο-έξοδο και κανένα μηχανοκίνητο πρόγραμμα οδήγησης, οπότε ο καλύτερος σχεδιαστής είναι η noop / FIFO-ουρά, οπότε αυτός ο τύπος προγραμματιστή " tweak" δεν κάνει τίποτα Υποσύστημα I / O. Στην πραγματικότητα, όλες αυτές οι εντολές λίστας πολλαπλών οθονών αντικαθίστανται καλύτερα από έναν απλό κύκλο:

 για i in / sys / block / mmc *. κάνουμε echo noop> $ i / ουρά / χρονοδιακόπτης echo 0> $ i / queue / iostats γίνει 

Αυτό θα επέτρεπε στον προγραμματιστή noop για όλους τους δίσκους από τη συσσώρευση στατιστικών I / O, η οποία θα έπρεπε να έχει θετικό αντίκτυπο στις επιδόσεις, αν και είναι πολύ μικρή και σχεδόν εντελώς αμελητέα.

Μια άλλη άχρηστη βελτιστοποίηση εισόδου / εξόδου που βρίσκεται συχνά στα σενάρια απόδοσης είναι οι αυξημένες τιμές ανάγνωσης για κάρτες SD μέχρι 2MB. Ο μηχανισμός ανάγνωσης είναι για τα πρώτα δεδομένα που διαβάζονται από τα μέσα, πριν η εφαρμογή ζητήσει πρόσβαση στα δεδομένα αυτά. Έτσι, βασικά, ο πυρήνας θα προσπαθήσει να καταλάβει ποια δεδομένα θα χρειαστούν στο μέλλον και τα φορτώνει εκ των προτέρων στη μνήμη RAM, πράγμα που θα πρέπει να μειώσει τον χρόνο επιστροφής. Αυτό ακούγεται υπέροχο σε χαρτί, αλλά ο αλγόριθμος ανάγνωσης είναι πιο συχνά λανθασμένος, πράγμα που οδηγεί σε εντελώς περιττές ενέργειες εισόδου-εξόδου, για να μην αναφέρουμε την υψηλή κατανάλωση μνήμης RAM.

Υψηλές τιμές ανάγνωσης από 1 έως 8 MB συνιστώνται σε συστοιχίες RAID, αλλά για συσκευές Android, το καλύτερο για να αφήσετε την προεπιλεγμένη τιμή των 128 KB.

Εικονική διαχείρηση συστήματος διαχείρισης μνήμης

Μια άλλη κοινή τεχνική "βελτιστοποίησης" είναι η ρύθμιση του υποσυστήματος διαχείρισης εικονικής μνήμης. Αυτό συνήθως στοχεύει μόνο δύο μεταβλητές πυρήνα, vm.dirty_background_ratio και vm.dirty_ratio, οι οποίες είναι για την προσαρμογή του μεγέθους του buffer για την αποθήκευση "βρώμικων" δεδομένων. Τα βρώμικα δεδομένα είναι συνήθως δεδομένα που έχουν γραφτεί στο δίσκο, αλλά υπάρχουν ακόμα περισσότερα στη μνήμη και περιμένουν να εγγραφούν στο δίσκο.

Οι τυπικές τιμές τσίμπημα τόσο στις διανομές Linux όσο και στο Androis στο υποσύστημα διαχείρισης VM θα ήταν όπως:

 vm.dirty_background_ratio = 10 vm.dirty_ratio = 20 

Έτσι, αυτό που προσπαθεί να κάνει είναι ότι όταν το buffer των βρώμικων δεδομένων είναι 10% της συνολικής μνήμης RAM, ξυπνάει ροή pdflush και αρχίζει να γράφει δεδομένα στο δίσκο - αν η λειτουργία εγγραφής δεδομένων στο δίσκο είναι πολύ έντονη, το buffer θα συνεχίσει να αναπτύσσεται και όταν φτάσει το 20% της διαθέσιμης μνήμης RAM, το σύστημα θα μεταβεί στην επόμενη λειτουργία εγγραφής σε σύγχρονη λειτουργία - χωρίς προ-buffer. Αυτό σημαίνει ότι το έργο γραφής στην εφαρμογή δίσκου θα μπλοκαριστεί, έως ότου τα δεδομένα εγγραφούν στο δίσκο (AKA 'lag').

Αυτό που πρέπει να καταλάβετε είναι ότι ακόμα και αν το μέγεθος του buffer δεν φτάσει το 10%, το σύστημα θα κλωτσήσει αυτόματα σε pdflush μετά από 30 δευτερόλεπτα. Ένας συνδυασμός 10/20 είναι αρκετά λογικός, για παράδειγμα σε μια συσκευή με 1GB μνήμης RAM, που θα ισοδυναμούσε με 100 / 200MB μνήμης RAM, η οποία είναι περισσότερο από αρκετή όσον αφορά τα αρχεία έκρηξης όπου η ταχύτητα είναι συχνά χαμηλότερη από την εγγραφή ταχύτητας στο σύστημα NAND -memory ή κάρτα SD, όπως κατά την εγκατάσταση εφαρμογών ή την αντιγραφή αρχείων από υπολογιστή.

Για κάποιο λόγο, οι συγγραφείς σεναριογραφίας προσπαθούν να ωθήσουν αυτή την αξία ακόμα υψηλότερα, σε παράλογους ρυθμούς. Για παράδειγμα, μπορούμε να βρούμε στο σενάριο βελτιστοποίησης Xplix ένα ποσοστό τόσο υψηλό όσο 50/90.

 sysctl -w vm.dirty_background_ratio = 50 sysctl -w vm.dirty_ratio = 90 

Σε μια συσκευή με μνήμη 1 GB, αυτό θέτει όριο σε ένα βρώμικο buffer σε 500/900 MB, το οποίο είναι εντελώς άχρηστο για μια συσκευή Android, επειδή θα λειτουργούσε μόνο υπό συνεχή καταγραφή στο δίσκο - κάτι που συμβαίνει μόνο σε ένα βαρύ Διακομιστή Linux.

Κεραυνός! Το σενάριο χρησιμοποιεί μια πιο λογική αξία, αλλά συνολικά, το ακόμα αρκετά χωρίς νόημα:

 αν ["$ mem" -lt 524288], τότε sysctl -w vm.dirty_background_ratio = 15; sysctl -w vm.dirty_ratio = 30; elif ["$ mem" -lt 1049776] και στη συνέχεια sysctl -w vm.dirty_background_ratio = 10. sysctl -w vm.dirty_ratio = 20; αλλιώς sysctl -w vm.dirty_background_ratio = 5; sysctl -w vm.dirty_ratio = 10; fi, 

Οι δύο πρώτες εντολές τρέχουν σε smartphones με 512 MB μνήμης RAM, η δεύτερη με 1 GB και άλλα με περισσότερους από 1 GB. Αλλά στην πραγματικότητα υπάρχει μόνο ένας λόγος για να αλλάξετε τις προεπιλεγμένες ρυθμίσεις - μια συσκευή με πολύ αργή εσωτερική μνήμη ή κάρτα μνήμης. Σε αυτή την περίπτωση είναι λογικό να διαδοθούν οι τιμές των μεταβλητών, δηλαδή να γίνει κάτι τέτοιο:

 sysctl -w vm.dirty_background_ratio = 10 sysctl -w vm.dirty_ratio = 60 

Στη συνέχεια, όταν ένα σύστημα υπερχείλισης γράφει λειτουργίες, χωρίς να χρειάζεται να καταγράφει δεδομένα στο δίσκο, μέχρι το τελευταίο δεν θα μεταβεί σε σύγχρονη λειτουργία, πράγμα που θα επιτρέψει στις εφαρμογές να μειώσουν την καθυστέρηση κατά την εγγραφή.

Πρόσθετες άχρηστες τροποποιήσεις και ρυθμίσεις απόδοσης

Υπάρχουν πολύ περισσότερες "βελτιστοποιήσεις" εκεί έξω που πραγματικά δεν κάνουν τίποτα. Οι περισσότεροι από αυτούς απλά δεν έχουν καμία απολύτως επίδραση, ενώ άλλοι μπορεί να βελτιώσουν κάποια πτυχή της απόδοσης, ενώ υποβαθμίζουν τη συσκευή με άλλους τρόπους ( συνήθως βράζει κάτω από την απόδοση έναντι της αποστράγγισης της μπαταρίας) .

Ακολουθούν μερικές πρόσθετες δημοφιλείς βελτιστοποιήσεις που μπορεί να είναι χρήσιμες ή όχι, ανάλογα με το σύστημα και τη συσκευή Android.

• Επιτάχυνση - Η μικρή επιτάχυνση για τη βελτίωση της απόδοσης και την υποβρύχυνση - εξοικονομεί λίγη μπαταρία.
• Βελτιστοποίηση Βάσεων Δεδομένων - Θεωρητικά, αυτό θα πρέπει να βελτιώσει την απόδοση της συσκευής, αλλά αμφισβητήσιμη.
• Zipalign - Ειρωνικά, παρά την ενσωματωμένη ευθυγράμμιση περιεχομένου χαρακτηριστικών Android SDK στο αρχείο APK στο κατάστημα μπορείτε να βρείτε πολλά λογισμικά που δεν μεταδίδονται μέσω zipalign.
• Απενεργοποιήστε τις περιττές υπηρεσίες συστήματος, αφαιρέστε το μη χρησιμοποιημένο σύστημα και σπάνια χρησιμοποιούμενες εφαρμογές τρίτων κατασκευαστών. Βασικά, απεγκαταστήστε bloatware.
• Προσαρμοσμένος πυρήνας με βελτιστοποιήσεις για μια συγκεκριμένη συσκευή (και πάλι, δεν είναι όλοι οι πυρήνες εξίσου καλά).
• Έχει ήδη περιγραφεί ο προγραμματιστής I / O noop.
• Αλγόριθμος κορεσμού TCP Westwood - Χρησιμοποιείται αποτελεσματικότερα στο προεπιλεγμένο σύστημα Android Cubic για ασύρματα δίκτυα, διαθέσιμο σε προσαρμοσμένους πυρήνες.

Άχρηστες ρυθμίσεις build.prop

Το LaraCraft304 από το XDA Developers forum διεξήγαγε μια μελέτη και διαπίστωσε ότι ένας εντυπωσιακός αριθμός ρυθμίσεων /system/build.prop που συνιστώνται για χρήση "εμπειρογνωμόνων" δεν υπάρχουν στην πηγή AOSP και CyanogenMod. Εδώ είναι ο κατάλογος:

 ro.ril.disable.power.collapse ro.mot.eri.losalert.delay ro.config.hw_fast_dormancy ro.config.hw_power_saving windowsmgr.max_events_per_sec persist.cust.tel.eons ro.max.fling_velocity ro.min.fling_velocity ro. kernel.checkjni dalvik.vm.verify-bytecode debug.performance.tuning video.accelerate.hw ro.media.dec.jpeg.memcap ro.config.nocheckin profiler.force_force_disable_ulog profiler.force_force_disable_err_rpt ersist.sys.shutdown.mode ro.HOME_APP_ADJ