Tādējādi daudzos all-in-one optimizācijas skriptos tiek izmantotas tās pašas metodes, no kurām dažas ilgtermiņā ir pilnīgi novecojušas vai kaitīgas. Apkopojot, lielākā daļa optimizēšanas skriptu “viss vienā” ir nekas cits kā vienreizēji ieteiktie pielāgojumi, bez skaidras idejas par to, kā vai kāpēc šīs optimizācijas darbojas - lietotāji pēc tam mirgo skriptus un apgalvo, ka viņu darbība pēkšņi ir ātrāka ( patiesībā, visticamāk, veiktspējas pieaugumu izraisīja ļoti vienkārša viņu ierīces pārstartēšana , jo viss ierīces RAM tiek iztīrīts) .
Šajā ekskluzīvajā rakstā mēs uzsvērsim dažus visbiežāk lietotos ieteikumus optimizēt ” Android veiktspēja un neatkarīgi no tā, vai tie ir vienkārši mīti, vai likumīgs ierīces veiktspējas uzlabojums.
Apmaini
Mītu saraksta augšdaļā ir Android mijmaiņas darījums - kas ir diezgan absurdi, ņemot vērā to, ka to uzskata par Android optimizāciju. Mijmaiņas galvenais mērķis ir izveidot un savienot peidžeru failu, kas atbrīvos vietu atmiņā. Tas izklausās saprātīgi uz papīra , bet tas patiešām ir piemērojams serveris , kurai gandrīz nav interaktivitātes.
Regulāri lietojot Android tālruņa mijmaiņas darījumu, tas novedīs pie nopietnām atpalicībām, kas rodas no lietām, kas paslīd garām kešatmiņai. Iedomājieties, piemēram, ja lietojumprogramma mēģina parādīt grafiku, kas tiek glabāts mijmaiņas darījumā, kuram pēc vietas atbrīvošanas tagad ir atkārtoti jāielādē disks, ievietojot datu apmaiņu ar citu lietojumprogrammu. Tas ir patiešām netīrs.
Daži optimizācijas entuziasti var teikt, ka mijmaiņa neradīja problēmas, taču tā nav mijmaiņa, kas uzlabo veiktspēju - tas ir iebūvētais Android mehānisms lowmemorykiller , kas regulāri nogalinās uzpūstos, augstas prioritātes procesus, kas netiek izmantoti. LMK tika izstrādāts tieši zemas atmiņas apstākļu apstrādei, tiek izsaukts no kswapd procesu un parasti nogalina lietotāja telpas procesus. Tas atšķiras no OOMkiller (slepkava ārpus atmiņas), bet tā ir pavisam cita tēma.
Lieta ir tāda, ka ierīce ar, piemēram, 1 GB operatīvās atmiņas, nekad nespēj sasniegt nepieciešamos veiktspējas datus mijmaiņas veidā, un tāpēc Android operētājsistēma nav absolūti nepieciešama. Tās ieviešana ir vienkārši pilna ar novēlošanos un noved pie a degradācija veiktspējā, nevis to optimizēt.
zRAM - novecojis un vairs nav efektīvs
zRAM ir pārbaudīta un efektīva metode ierīču optimizēšanai vecākas ierīces - domājiet par KitKat balstītām ierīcēm, kas darbojas tikai ar aptuveni 512 MB RAM. Fakts, ka daži cilvēki joprojām iekļauj zRAM kniebienus optimizācijas skriptos vai iesaka zRAM kā kaut kādu modernu optimizācijas kniebienu, ir piemērs tam, ka cilvēki parasti neievēro jaunākos darbības protokolus.
zRAM bija paredzēts sākuma līmeņa budžeta diapazona daudzkodolu SoC, piemēram, ierīcēm, kas izmanto MTK mikroshēmojumus un 512 MB RAM. Būtībā ļoti lēti ķīniešu tālruņi. Tas, ko zRAM principā dara, ir kodola atdalīšana, izmantojot šifrēšanas straumi.
Ja zRAM tiek izmantots vecākām ierīcēm ar a viens kodols , pat ja šādām ierīcēm ieteicams lietot zRAM, lielos daudzumos novirzes mēdz augt. Tas notiek arī ar KSM tehnoloģiju ( Kodols apvienojas vienā un tajā pašā lapā) kas apvieno identiskas atmiņas lapas, cenšoties atbrīvot vietu. Faktiski to iesaka Google, taču tas noved pie lielākiem novecojumiem vecākās ierīcēs, jo pastāvīgi aktīvās galvenās pogas nepārtraukti darbojas no atmiņas, lai meklētu dublētas lapas. Būtībā mēģinājumi izpildīt optimizācijas kniebienu, ironiski, vēl vairāk palēnina ierīci.
Sējmašīna - novecojusi kopš Android 3.0
Viens no visvairāk apspriestajiem optimizācijas padomiem starp Android izstrādātājiem ir ciedrs , un mēs esam pārliecināti, ka kāds varētu mēģināt pierādīt, ka esam nepareizi par šo tēmu, taču vispirms mums jāpārbauda sējmašīnas vēsture.
Sējmašīnas lietotne Android ierīcēm
Jā, ir liels skaits ziņojumu, kas paziņo par labāku Android veiktspēju pēc instalēšanas daudz vecākas Android ierīces . Tomēr cilvēki jebkura iemesla dēļ uzskata, ka tas nozīmē arī optimizējamu optimizāciju modernas Android ierīces , kas ir absolūti absurds. Fakts, ka Sējmašīna joprojām tiek uzturēta un piedāvāta kā mūsdienu ” kavēšanās samazināšanas rīks ir dezinformācijas piemērs - lai gan tas nav Seeder izstrādātāja vaina, jo pat viņu Play veikala lapā ir norādīts, ka Seeder pēc Android 4.0+ ir mazāk efektīva. Tomēr kāda iemesla dēļ Seeder joprojām parādās diskusijās par optimizāciju mūsdienu Android sistēmām.
Tas, ko Sējējs pamatā dara operētājsistēmai Android 3.0, ir novērst kļūdu, kurā Android runtime aktīvi izmantotu / dev / random / failu entropijas iegūšanai. / Dev / random / buffer kļūs nestabils, un sistēma tiks bloķēta, līdz tā aizpildīs nepieciešamo datu apjomu - padomājiet par tādām mazām lietām kā dažādi sensori un pogas Android ierīcē.
Seeder autors paņēma Linux dēmonu rngd un sastādīts Android inastroil, lai tas ņemtu nejaušus datus no daudz ātrāka un paredzamāka / dev / urandom ceļa un apvienotu tos dev / random / katru sekundi, neļaujot / dev / random / izsmelties. Tā rezultātā izveidojās Android sistēma, kurā nenotika entropijas trūkums, un tā darbojās daudz vienmērīgāk.
Google izjauca šo kļūdu pēc Android 3.0, tomēr kādu iemeslu dēļ Sējers joprojām tiek parādīts “Ieteiktie pielāgojumi” Android veiktspējas optimizācijas saraksti. Turklāt Seeder lietotnei ir daži analogi, piemēram, sEFix, kas ietver Seeder funkcionalitāti neatkarīgi no tā, vai tā tiek izmantota rngd vai alternatīva aizturēts vai pat tikai saikne starp / dev / urandom un / dev / random. Mūsdienu Android sistēmām tas ir absolūti bezjēdzīgi.
Iemesls tam ir bezjēdzīgs tāpēc, ka jaunākās Android versijās / dev / random / tiek izmantoti trīs galvenie komponenti - libcrypto , SSL savienojumu šifrēšanai, SSH atslēgu ģenerēšanai utt. WPA_supplication / hostapd, kas ģenerē WEP / WPA atslēgas, un visbeidzot, dažas bibliotēkas ID ģenerēšanai, veidojot EXT2 / EXT3 / EXT4 failu sistēmas.
Tad, kad Sējmašīna vai Seeder balstītie uzlabojumi ir iekļauti mūsdienu Android optimizācijas skriptos, kas galu galā notiek degradācija ierīces veiktspējā, jo rngd pastāvīgi modinās ierīci un izraisīs CPU frekvences pieaugumu, kas, protams, negatīvi ietekmē akumulatora patēriņu.
Odex
Akciju programmaparatūra Android ierīcēs gandrīz vienmēr ir odekss. Tas nozīmē, ka līdzās Android lietotņu standarta pakotnei APK formātā, kas atrodamas mapēs / system / app / un / system / priv-app /, ir vienādi failu nosaukumi ar paplašinājumu .odex. Oodex failos ir optimizētas baitkoda lietojumprogrammas, kas jau ir izietas caur validatoru un optimizētāja virtuālo mašīnu, pēc tam ierakstītas atsevišķā failā, izmantojot kaut ko līdzīgu dexopt rīks.
Tātad, odeksa faili ir domāti virtuālās mašīnas izkraušanai un piedāvā paātrinātu odeksētās lietojumprogrammas palaišanu - trūkums ir tas, ka ODEX faili novērš programmaparatūras modifikācijas un rada problēmas ar atjauninājumiem, tāpēc šī iemesla dēļ tiek izplatīti daudzi pielāgoti ROM, piemēram, LineageOS bez ODEX .
ODEX failu ģenerēšana tiek veikta dažādos veidos, piemēram, izmantojot Odexer rīku - problēma ir tā, ka tā ir tikai placebo efekts. Kad mūsdienu Android sistēma / system direktorijā neatrod odex failus, sistēma tos faktiski izveidos un ievietos direktorijā / system / dalvik-cache /. Tas notiek tieši tad, kad, piemēram, mirgo jauna Android versija, un tā uz brīdi dod ziņojumu “Aizņemts, lietojumprogrammu optimizēšana”.
Lowmemorykiller kniebieni
Daudzuzdevumu veikšana operētājsistēmā Android atšķiras no citām mobilajām operētājsistēmām ar to, ka tās pamatā ir klasisks modelis, kurā lietojumprogrammas darbojas klusi fonā, un fona lietotņu skaitam nav ierobežojumu ( ja vien tas nav iestatīts izstrādātāja opcijās, bet tas parasti nav ieteicams) - turklāt pārejas uz fona izpildi funkcionalitāte netiek pārtraukta, lai gan sistēma patur tiesības nogalināt fona lietotnes nepietiekamas atmiņas apstākļos ( skatiet, kur mēs šajā ceļvedī iepriekš runājām par zemu atmiņu slepkavu un ārpus atmiņas slepkavu) .
Lai atgrieztos pie lowmemorykiller mehānisms, Android var turpināt darboties ar ierobežotu atmiņas daudzumu un mijmaiņas nodalījuma trūkumu. Lietotājs var turpināt palaist lietojumprogrammas un pārslēgties starp tām, un sistēma klusi nogalinās neizmantotās fona lietotnes, lai mēģinātu atbrīvot atmiņu aktīviem uzdevumiem.
Tas bija ļoti noderīgs Android pirmajās dienās, lai gan nez kāpēc tas kļuva populārs uzdevumu slepkavas lietotņu veidā, kas parasti ir vairāk kaitīgi nekā izdevīgi. Task-killer lietotnes vai nu pamostas noteiktos laika intervālos, vai arī tās vada lietotājs, un šķiet, ka tā atbrīvo lielu daudzumu RAM, kas tiek uzskatīts par pozitīvu - vairāk brīvas RAM nozīmē ātrāku ierīci, vai ne? Tomēr tas nav precīzi Android gadījumā.
Patiesībā liela apjoma brīvas RAM pieejamība faktiski var kaitēt ierīces veiktspējai un akumulatora darbības laikam. Ja lietotnes tiek glabātas Android RAM, ir daudz vieglāk tās izsaukt, palaist utt. Android sistēmai nav jāpiešķir daudz resursu, lai pārslēgtos uz lietotni, jo tā jau atrodas atmiņā.
Tādēļ uzdevumu slepkavas patiesībā nav tik populāri kā agrāk, lai gan Android iesācēji nez kāpēc joprojām mēdz paļauties uz tiem ( informācijas trūkums, diemžēl) . Diemžēl uzdevumu slepkavas aizstājusi jauna tendence lowmemorykiller mehānisma regulēšana. Tas būtu, piemēram MinFreeManager lietotni, un galvenā ideja ir palielināt RAM pieskaitāmo daļu, pirms sistēma sāk nogalināt fona lietotnes.
Tā, piemēram, standarta RAM darbojas uz robežām - 4, 8, 12, 24, 32 un 40 Mb, un, kad ir aizpildīta 40 MB brīva atmiņas vieta, viena no kešatmiņā saglabātajām lietotnēm, kas tiek ielādēta atmiņā bet neskrien tiks izbeigts.
Tātad būtībā Android vienmēr būs pieejama vismaz 40 MB pieejamās atmiņas, kas ir pietiekami, lai iepriekš ievietotu vēl vienu lietojumprogrammu lowmemorykiller sāk tīrīšanas procesu - tas nozīmē, ka Android vienmēr darīs visu iespējamo, lai izmantotu maksimālo pieejamo RAM apjomu, netraucējot lietotāja pieredzi.
Diemžēl daži vietējā alus pagatavošanas entuziasti ieteica, ka pirms LMK sākuma vērtība tiek paaugstināta līdz, piemēram, 100 MB. Tagad lietotājs faktiski zaudēt RAM (100 - 40 = 60), tāpēc tā vietā, lai izmantotu šo vietu aizmugurējo lietotņu glabāšanai, sistēma saglabās šo atmiņas apjomu bez maksas , tam pilnīgi nav mērķa.
LKM tūnings var būt noderīga daudz vecākām ierīcēm ar 512 RAM, bet kam tās vairs pieder? 2 GB ir mūsdienu “budžeta diapazons”, pat 4 GB RAM ierīces mūsdienās tiek uzskatītas par “vidēja līmeņa” ierīcēm, tāpēc LMK pielāgojumi ir patiešām novecojuši un bezjēdzīgi.
I / O kniebieni
Daudzos Android optimizācijas skriptos jūs bieži atradīsit pielāgojumus, kas attiecas uz I / O apakšsistēmu. Piemēram, ļauj apskatīt ThunderBolt! Skripts, kas satur šīs rindas:
atbalss 0> $ i / rinda / rotācijas; echo 1024> $ i / queue / nr_requests;
Pirmajā rindā I / O plānotājam tiks dotas instrukcijas, strādājot ar SSD, bet otrajā rindas I / O rindas maksimālais lielums tiek palielināts no 128 līdz 1024 - jo mainīgais $ i satur ceļu uz bloķēto ierīču koku / sys, un skripts darbojas cilpā.
Pēc tam jūs atradīsit līniju, kas saistīta ar CFQ plānotāju:
atbalss 1> $ i / rinda / iosched / back_seek_penalty; atbalss 1> $ i / rinda / iosched / low_latency; atbalss 1> $ i / rinda / iosched / slice_idle;
Pēc tam seko vairāk rindu, kas pieder citiem plānotājiem, taču galu galā pirmās divas komandas ir bezjēdzīgas, jo:
Mūsdienu Linux kodols spēj saprast, ar kāda veida datu nesēju tas darbojas pēc noklusējuma.
Gara ievades un izvades rinda ( piemēram, 1024) ir bezjēdzīgi mūsdienu Android ierīcē, patiesībā tā ir bezjēdzīga pat uz darbvirsmas - to patiešām ieteicams lietot tikai lieljaudas serveri . Jūsu tālrunis nav lieljaudas Linux serveris.
Android ierīcē praktiski nav nevienas lietojumprogrammas, kas prioritizētas ievades-izvades režīmā, un nav mehāniska draivera, tāpēc labākais plānotājs ir noop / FIFO-rinda, tāpēc šāda veida plānotājs “ kniebiens ” nedara neko īpašu vai jēgpilnu I / O apakšsistēmai. Faktiski visas šīs vairāku ekrānu saraksta komandas labāk aizstāj ar vienkāršu ciklu:
i i / sys / block / mmc *; do echo noop> $ i / queue / plānotāja atbalss 0> $ i / queue / iostats done
Tas ļautu no diska plānotāja visiem diskiem no I / O statistikas uzkrāšanas, kam vajadzētu pozitīvi ietekmēt veiktspēju, kaut arī ļoti niecīgu un gandrīz pilnīgi nenozīmīgu.
Vēl viens bezjēdzīgs I / O kniebiens, kas bieži sastopams veiktspējas skriptos, ir palielinātas SD karšu nolasīšanas vērtības līdz 2 MB. Priekšlasīšanas mehānisms ir paredzēts datu agrīnai nolasīšanai no plašsaziņas līdzekļiem, pirms lietotne pieprasa piekļuvi šiem datiem. Tātad būtībā kodols mēģinās noskaidrot, kādi dati būs nepieciešami nākotnē, un iepriekš tos ielādē RAM, tādējādi samazinot atgriešanās laiku. Tas uz papīra izklausās lieliski, taču biežāk tiek izmantots iepriekš lasīšanas algoritms nepareizi , kas noved pie pilnīgi nevajadzīgām ieejas-izejas darbībām, nemaz nerunājot par lielu RAM patēriņu.
RAID blokos ir ieteicamas augstas nolasīšanas vērtības no 1 līdz 8 MB, bet Android ierīcēm vislabāk ir vienkārši atstāt noklusējuma vērtību 128 KB.
Virtuālās atmiņas pārvaldības sistēmas uzlabojumi
Vēl viena izplatīta “optimizācijas” tehnika ir virtuālās atmiņas pārvaldības apakšsistēmas pielāgošana. Parasti tas attiecas tikai uz diviem kodola mainīgajiem lielumiem - vm.dirty_background_ratio un vm.dirty_ratio, kas paredzēti bufera lieluma pielāgošanai “netīro” datu glabāšanai. Netīrs dati parasti ir dati, kas ir ierakstīti diskā, taču atmiņā vēl ir vairāk un gaida, kad tos ierakstīs diskā.
Gan Linux distros, gan Androis tipiskās pielāgošanas vērtības VM pārvaldības apakšsistēmai būtu šādas:
vm.dirty_background_ratio = 10 vm.dirty_ratio = 20
Tas, ko tas mēģina darīt, ir tas, ka tad, kad netīro datu buferis ir 10% no kopējā RAM apjoma, tas pamostas pdflush plūst un sāk rakstīt datus uz diska - ja darbība ar datu ierakstīšanu diskā būs pārāk intensīva , buferis turpinās pieaugt, un, sasniedzot 20% no pieejamās RAM, sistēma pārslēgsies uz nākamo rakstīšanas darbību sinhronā režīmā - bez iepriekšēja bufera. Tas nozīmē, ka darbs ar rakstīšanu uz diska būs bloķēta, līdz dati tiek ierakstīti diskā (AKA ‘lag’).
Jums vajadzētu saprast, ka pat tad, ja bufera lielums nesasniedz 10% , pēc 30 sekundēm sistēma automātiski ieslēgsies pdflush. 10/20 kombinācija ir diezgan saprātīga, piemēram, ierīcē ar 1GB RAM tas būtu vienāds ar 100 / 200MB RAM, kas ir vairāk nekā pietiekami, ņemot vērā sērijveida ierakstus, kur ātrums bieži ir zemāks par ātruma rekordu sistēmā NAND - atmiņa vai SD karte, piemēram, instalējot lietotnes vai kopējot failus no datora.
Nez kāpēc scenāriju autori mēģina šo vērtību paaugstināt vēl augstāk, līdz absurdiem rādītājiem. Piemēram, mēs varam atrast Xplix optimizācijas skripta līmenis ir pat 50/90.
sysctl -w vm.dirty_background_ratio = 50 sysctl -w vm.dirty_ratio = 90
Ierīcē ar 1 GB atmiņu tas nosaka netīrā bufera ierobežojumu līdz 500/900 MB, kas Android ierīcei ir pilnīgi bezjēdzīgi, jo tas darbotos tikai zem pastāvīga ierakstīšana diskā - kaut kas notiek tikai smagā Linux serverī.
ThunderBolt! Skripts izmanto saprātīgāku vērtību, taču kopumā tas joprojām ir diezgan bezjēdzīgs:
ja ['$ mem' -lt 524288]; tad sysctl -w vm.dirty_background_ratio = 15; sysctl -w vm.dirty_ratio = 30; elif ['$ mem' -lt 1049776]; tad sysctl -w vm.dirty_background_ratio = 10; sysctl -w vm.dirty_ratio = 20; else sysctl -w vm.dirty_background_ratio = 5; sysctl -w vm.dirty_ratio = 10; fi;
Pirmās divas komandas tiek izpildītas viedtālruņos ar 512 MB RAM, otrā - ar 1 GB un citas - ar vairāk nekā 1 GB. Bet patiesībā ir tikai viens iemesls, lai mainītu noklusējuma iestatījumus - ierīce ar ļoti lēnu iekšējo atmiņu vai atmiņas karti. Šajā gadījumā ir pamatoti izplatīt mainīgo vērtības, tas ir, izveidot kaut ko līdzīgu šim:
sysctl -w vm.dirty_background_ratio = 10 sysctl -w vm.dirty_ratio = 60
Tad, kad pārsprieguma sistēma uzraksta darbības bez nepieciešamības ierakstīt datus diskā, līdz pēdējam netiek pārslēgts sinhronais režīms, kas ļaus lietojumprogrammām samazināt ierakstu kavēšanos.
Papildu bezjēdzīgi pielāgojumi un veiktspējas pielāgojumi
Tur ir daudz vairāk 'optimizācijas', kas patiešām neko nedara. Lielākajai daļai no tām vienkārši nav nekādas ietekmes, bet citi var uzlabot daži veiktspējas aspekts, vienlaikus degradējot ierīci citos veidos ( parasti tas notiek līdz veiktspējai salīdzinājumā ar akumulatora iztukšošanos) .
Šeit ir dažas populāras papildu optimizācijas, kas var būt noderīgas vai var nebūt noderīgas atkarībā no Android sistēmas un ierīces.
- Paātrinājums - mazais paātrinājums, lai uzlabotu veiktspēju un nepietiekamu spriegumu, ietaupa nedaudz akumulatora.
- Datu bāzes optimizācija - teorētiski tas vajadzētu uzlabotu ierīces veiktspēju, taču tas ir apšaubāms.
- Zipalign - Ironiski, neskatoties uz iebūvēto Android SDK funkciju satura pielīdzināšanu veikala APK failā, jūs varat atrast, ka daudz programmatūras netiek pārsūtīta caur zipalign.
- Atspējojiet nevajadzīgos sistēmas pakalpojumus, noņemot neizmantoto sistēmu un reti izmantotās trešo pušu lietojumprogrammas. Būtībā bloatware atinstalēšana.
- Pielāgots kodols ar optimizāciju konkrētai ierīcei (atkal ne visi kodoli ir vienlīdz labi).
- Jau aprakstīts I / O plānotājs noop.
- Piesātinājuma algoritms TCP Westwood - efektīvāk izmantots noklusējuma Android Cubic bezvadu tīkliem, kas pieejams pielāgotos kodolos.
Bezjēdzīgi iestatījumi build.prop
LaraCraft304 no XDA izstrādātāju foruma ir veikusi pētījumu un atklāja, ka iespaidīgā skaitā /system/build.prop iestatījumu, kurus ieteicams izmantot “ekspertiem”, nav avotu AOSP un CyanogenMod. Šeit ir saraksts:
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. kernel.checkjni dalvik.vm.verify-bytecode debug.performance.tuning video.accelerate.hw ro.media.dec.jpeg.memcap ro.config.nocheckin profiler.force_disable_ulog profiler.force_disable_err_rpt.Pys.Pod.roTagi android Attīstība 12 minūtes lasītas
