Откривени су најчешћи митови о оптимизацији Андроид-а

Дакле, пуно све-у-једном скрипти за оптимизацију користе исте методе, од којих су неке потпуно застареле или дугорочно штетне. Укратко, већина оптимизационих скрипти „све у једном“ нису ништа друго доли препоручена подешавања, без јасне идеје о томе како и зашто те оптимизације „функционишу - корисници затим пребацују скрипте и тврде да су њихове перформансе одједном брже ( док је у ствари највероватније врло једноставан чин поновног покретања њиховог уређаја проузроковао повећање перформанси , пошто се све у РАМ-у уређаја очисти) .

У овом ексклузивном чланку за Аппуалс издвојићемо неке од најчешћих препорука за „ оптимизација ” Андроид перформансе и да ли су они само мит или легитимна промена у погледу перформанси уређаја.

Замените

На врху листе митова налази се замена Андроида - што је прилично апсурдно у смислу да се на њу мисли као на Андроид оптимизацију. Свапс-ова главна сврха је стварање и повезивање страничне датотеке, што ће ослободити простор за складиштење у меморији. Ово звучи разумно на папиру , али је заиста применљиво на а сервер , који готово да нема интерактивност.

Када редовно користите замену Андроид телефона, то ће довести до великих заостајања која проистичу из ствари које промичу испред кеш меморије. Замислите, на пример, ако нека апликација покуша да прикаже графику која се чува у замјени, која сада мора поново учитати диск након што ослободи простор постављањем замјене података у другу апликацију. Заиста је неуредно.

Неки ентузијасти у оптимизацији могу рећи да замена не нуди проблеме, али то није замена која повећава перформансе - то је уграђени Андроид механизам ловмеморикиллер , који ће редовно убијати надуте процесе високог приоритета који се не користе. ЛМК је дизајниран посебно за руковање условима са мало меморије, позива се из ксвапд процес и обично убија процесе корисничког простора. Ово се разликује од ООМкиллер (убица без меморије), али то је сасвим друга тема.

Поента је у томе што уређај са, на пример, 1 ГБ РАМ-а никада не може доћи до потребних података о перформансама у замјени, тако да свап апсолутно није потребан у Андроиду. Његова примена је једноставно заостала и доводи до а деградација у перформансама, уместо да га оптимизује.

зРАМ - Застарио и више није ефикасан

зРАМ је доказана и ефикасна метода за оптимизацију уређаја за старији уређаји - помислите на уређаје засноване на КитКат-у који раде на само око 512 МБ РАМ-а. Чињеница да неки људи још увек укључују подешавања зРАМ-а у скриптама за оптимизацију или препоручују зРАМ као неку врсту модерног подешавања оптимизације, пример је да људи углавном не следе најновије оперативне протоколе.

зРАМ је био намењен основним СоЦ-има прорачуна опсега прорачуна, као што су уређаји који користе МТК чипсете и 512 МБ РАМ-а. У основи врло јефтини кинески телефони. Оно што зРАМ у основи ради је одвајање кернела путем тока шифровања.

Када се зРАМ користи на старијим уређајима са једно језгро , чак и ако се зРАМ препоручује на таквим уређајима, велике количине заостајања имају тенденцију да се појаве. То се такође дешава са КСМ технологијом ( Спајање исте странице кернела) који комбинује идентичне меморијске странице у жељи да ослободи простор. То Гоогле у ствари препоручује, али доводи до већих заостајања на старијим уређајима, јер стално активно језгро тхеадс непрекидно ради из меморије у потрази за дупликатима страница. У основи, покушај покретања оптимизације успорава уређај још више, иронично.

Сеедер - Застарео од Андроид 3.0

Један од најпопуларнијих савета за оптимизацију међу Андроид програмерима је кедар , и сигурни смо да би неко могао да покуша да нам докаже да нисмо у праву у вези са овом темом - али прво морамо да испитамо историју сејалице.

Апликација сејачица за Андроид

Да, постоји велики број извештаја који проглашавају боље Андроид перформансе након инсталације на много старијих Андроид уређаја . Међутим, људи из било ког разлога верују да то значи да је то и применљива оптимизација савремени Андроид уређаји , што је апсолутно апсурдно. Чињеница да се Сеедер и даље одржава и нуди као „ модеран' алат за смањење заостајања пример је погрешних информација - иако ово није грешка програмера Сеедер-а, јер чак и њихова страница Плаи продавнице примећује да је Сеедер мање ефикасан након Андроид-а 4.0+. Ипак, из било ког разлога, Сеедер се и даље појављује у дискусијама о оптимизацији модерних Андроид система.

Оно што Сеедер у основи ради за Андроид 3.0 јесте уклањање грешке у којој би Андроид извршавање активно користило / дев / рандом / датотеку за стицање ентропије. / Дев / рандом / бафер би постао нестабилан и систем би био блокиран док не напуни потребну количину података - размислите о малим стварима попут различитих сензора и дугмади на Андроид уређају.

Аутор Сеедер-а узео је Линук-демон рнгд и компајлиран за Андроид-ов инстројл тако да узима случајне податке са много бржег и предвидљивијег / дев / урандом пута и спаја их у дев / рандом / сваке секунде, не дозвољавајући да се / дев / рандом / исцрпи. То је резултирало Андроид системом који није искусио недостатак ентропије и радио је много углађеније.

Гоогле је разбио ову грешку након Андроид-а 3.0, али из неког разлога, Сеедер се и даље појављује „Препоручена подешавања“ листе за оптимизацију перформанси Андроид-а. Поред тога, апликација Сеедер има неколико аналога попут сЕФик-а који укључују функционалност Сеедер-а, било да се користи иста рнгд или алтернативу хасгед , или чак само симболична веза између / дев / урандом и / дев / рандом. Ово је апсолутно бесмислено за савремене Андроид системе.

Разлог њеног бесмисла је тај што новије верзије Андроид-а користе / дев / рандом / у три главне компоненте - либцрипто , за шифровање ССЛ веза, генерисање ССХ кључева, итд. ВПА_супплицатион / хостапд који генерише ВЕП / ВПА кључеве, и на крају, прегршт библиотека за генерисање ИД-а у стварању система датотека ЕКСТ2 / ЕКСТ3 / ЕКСТ4.

Па кад Сејачица или су побољшања заснована на Сеедер-у укључена у модерне скрипте за оптимизацију Андроид-а, а оно што се на крају дешава је деградација у перформансама уређаја, јер рнгд ће стално будити уређај и проузроковати повећање фреквенције процесора, што наравно негативно утиче на потрошњу батерије.

Одек

Основни фирмвер на Андроид уређајима је углавном увек одек. То значи да су заједно са стандардним пакетом за Андроид апликације у АПК формату, које се налазе у / систем / апп / и / систем / прив-апп /, истог имена датотека са екстензијом .одек. Одек датотеке садрже оптимизоване апликације бајт кода које су већ прошле кроз валидатор и оптимизатор виртуелне машине, а затим снимљене у засебну датотеку користећи нешто попут декопт оруђе.

Дакле, одек датотеке су намењене за растерећење виртуелне машине и нуде убрзано покретање одекед апликације - с доње стране, ОДЕКС датотеке спречавају модификације фирмвера и стварају проблеме са исправкама, па се из тог разлога дистрибуирају многи прилагођени РОМ-ови попут ЛинеагеОС без ОДЕКС-а .

Генерирање ОДЕКС датотека врши се на више начина, као што је коришћење алатке Одекер - проблем је у томе што је то чисто плацебо ефекат. Када савремени Андроид систем не пронађе одек датотеке у директоријуму / систем, систем ће их заправо створити и сместити у директоријум / систем / далвик-цацхе /. Управо се то дешава када, на пример, трепнете новом верзијом Андроида и она неко време даје поруку „Заузете, оптимизујуће апликације“.

Подешавања Ловмеморикиллер-а

Мултитаскинг у Андроиду разликује се од осталих мобилних оперативних система у том смислу што се заснива на класичном моделу где апликације раде тихо у позадини и нема ограничења у броју позадинских апликација ( осим ако није постављен у опцијама за програмере, али ово се обично препоручује) - штавише, функционалност преласка на извршавање у позадини није заустављена, иако систем задржава право да убија позадинске апликације у ситуацијама са мало меморије ( погледајте где смо раније у овом водичу разговарали о убици са ниским меморијским средствима и убицама без меморије) .

Да се ​​вратим на ловмеморикиллер механизам, Андроид може наставити да ради са ограниченом количином меморије и недостатком свап-партиције. Корисник може да настави да покреће апликације и пребацује се између њих, а систем ће нечујно убијати неискоришћене позадинске апликације како би покушао да ослободи меморију за активне задатке.

Ово је било веома корисно за Андроид у раним данима, иако је из неког разлога постало популарно у облику апликација за убијање задатака, које су углавном више штетне него корисне. Апликације које убијају задатке или се буде у одређеним интервалима или их покреће корисник и чини се да ослобађају велике количине РАМ-а, што се сматра позитивним - више слободног РАМ-а значи бржи уређај, зар не? Међутим, ово није баш случај са Андроидом.

У ствари, постојање велике количине бесплатне РАМ меморије заправо може бити штетно за перформансе вашег уређаја и трајање батерије. Када се апликације чувају у Андроид-овој РАМ меморији, много их је лакше позвати, покренути итд. Андроид систем не треба да посвети много ресурса за прелазак на апликацију, јер она већ постоји у меморији.

Због тога, убице задатака заправо нису толико популарне као некада, иако се Андроид почетници из неког разлога и даље ослањају на њих ( недостатак информација, нажалост) . Нажалост, нови тренд је заменио убице задатака, тренд ловмеморикиллер подешавања механизама. Ово би било на пример МинФрееМанагер апликација, а главна идеја је повећати РАМ меморију пре него што систем почне да убија позадинске апликације.

Тако, на пример, стандардни РАМ ради на границама - 4, 8, 12, 24, 32 и 40 Мб, а када се попуни слободни простор од 40 МБ, једна од кешираних апликација која се учитава у меморију али не и трчање биће укинута.

У основи, Андроид ће увек имати најмање 40 МБ доступне меморије, што је довољно за смештај још једне апликације раније ловмеморикиллер започиње свој поступак чишћења - што значи да ће Андроид увек учинити све да искористи максималну количину доступне РАМ меморије без ометања корисничког искуства.

Нажалост, оно што су неки љубитељи хомебрева започели препоручује се да се вредност повећа на, на пример, 100 МБ пре него што ЛМК почне. Сада ће корисник заправо изгубити РАМ (100 - 40 = 60), па ће систем, уместо да користи овај простор за складиштење позадинских апликација, задржати ову количину меморије бесплатно , без апсолутно никакве сврхе за то.

ЛКМ подешавање може бити корисно за много старије уређаје са 512 РАМ-а, али ко их више поседује? 2 ГБ је савремени „буџет“, чак и 4 ГБ РАМ уређаја данас изгледају као „средње класе“, тако да су ЛМК подешавања заиста застарела и бескорисна.

И / О подешавања

У многим скриптама за оптимизацију за Андроид често ћете пронаћи подешавања која се односе на И / О подсистем. На пример, хајде да погледамо ТхундерБолт! Скрипта која садржи ове редове:

ецхо 0> $ и / ред / ротација; ецхо 1024> $ и / куеуе / нр_рекуестс;

Прва линија ће дати И / О планеру упутства за рад са ССД-ом, а друга повећава максималну величину И / О реда са 128 на 1024 - јер променљива $ и садржи путању до стабла блоковских уређаја у / сис, а скрипта се покреће у петљи.

Након тога ћете пронаћи линију повезану са ЦФК планером:

ецхо 1> $ и / куеуе / иосцхед / бацк_сеек_пеналти; ецхо 1> $ и / куеуе / иосцхед / лов_латенци; ецхо 1> $ и / куеуе / иосцхед / слице_идле;

Након тога следи још редова који припадају другим планерама, али на крају, прве две команде су бесмислене јер:

Савремени Линук кернел је у стању да разуме са којим типом медија за складиштење подразумевано ради.

Дуг улазно-излазни ред ( као што је 1024) је бескористан на модерном Андроид уређају, заправо је бесмислен чак и на радној површини - заиста се препоручује само на њему тешки сервери . Ваш телефон није тешки Линук сервер.

За Андроид уређај, практично нема апликација којима је приоритет дато на улазу-излазу и нема механичког покретачког програма, тако да је најбољи планер нооп / ФИФО-ред, па овај тип планера „ штипање' не ради ништа посебно или значајно за И / О подсистем. У ствари, све те команде листе са више екрана боље је заменити једноставним циклусом:

за и ин / сис / блоцк / ммц *; до ецхо нооп> $ и / куеуе / планер ецхо 0> $ и / куеуе / иостатс доне

То би омогућило нооп планер за све погоне из акумулације И / О статистике, што би требало да има позитиван утицај на перформансе, иако врло мали и готово потпуно занемарљив.

Још једно бескорисно подешавање У / И које се често налази у скриптама перформанси је повећана вредност читања унапред за СД картице до 2 МБ. Механизам читања унапред служи за рано читање података са медија, пре него што апликација затражи приступ тим подацима. У основи, кернел ће покушати да схвати који ће подаци бити потребни у будућности и унапред их учитава у РАМ, што би на тај начин требало да смањи време повратка. Ово звучи сјајно на папиру, али алгоритам читања унапред је чешћи погрешно , што доводи до потпуно непотребних операција улаз-излаз, а да не говоримо о великој потрошњи РАМ-а.

Високе вредности читања унапред између 1 и 8 МБ препоручују се у РАИД низовима, али за Андроид уређаје најбоље је оставити подразумевану вредност од 128 КБ.

Подешавања система за управљање виртуелном меморијом

Још једна уобичајена техника „оптимизације“ је подешавање подсистема за управљање виртуелном меморијом. Ово обично циља само две променљиве језгра, вм.дирти_бацкгроунд_ратио и вм.дирти_ратио, које служе за прилагођавање величине међуспремника за чување „прљавих“ података. Прљаво подаци су обично подаци који су записани на диск, али још их има у меморији и чекају да буду записани на диск.

Типичне вредности подешавања у Линук дистрибуцијама и Андроису за подсистем управљања ВМ биле би попут:

вм.дирти_бацкгроунд_ратио = 10 вм.дирти_тратио_ратио = 20

Дакле, оно што се покушава учинити је да се, када прљави бафер података чини 10% укупне количине РАМ-а, пробуди пдфлусх проток и почиње да записује податке на диск - ако ће бити операција снимања података на диск преинтензивно , бафер ће наставити да расте, а када достигне 20% доступне РАМ меморије, систем ће се пребацити на наредну операцију писања у синхроном режиму - без претходног бафера. То значи да ће посао писања на диск бити рад блокиран, све док се подаци не упишу на диск (АКА „заостајање“).

Оно што би требало да схватите је да чак и ако величина бафера не достиже 10% , систем ће аутоматски покренути пдфлусх након 30 секунди. Комбинација 10/20 је прилично разумна, на пример, на уређају са 1 ГБ РАМ-а то би било једнако 100/200 МБ РАМ-а, што је више него довољно у погледу бурст записа где је брзина често испод записа брзине у систему НАНД -сећање или СД-картица, на пример приликом инсталирања апликација или копирања датотека са рачунара.

Из неког разлога, писци сценарија покушавају да повећају ову вредност још више, до апсурдних стопа. На пример, можемо наћи у Ксплик оптимизација скрипта стопа до 50/90.

сисцтл -в вм.дирти_бацкгроунд_ратио = 50 сисцтл -в вм.дирти_ратио = 90

На уређају са 1 ГБ меморије, ово поставља ограничење прљавог бафера на 500/900 МБ, што је потпуно бескорисно за Андроид уређај, јер би то функционисало само под константно снимање на диску - нешто што се дешава само на тешком Линук серверу.

ТхундерБолт! Скрипта користи разумнију вредност, али у целини је и даље прилично бесмислена:

ако ['$ мем' -лт 524288]; онда сисцтл -в вм.дирти_бацкгроунд_ратио = 15; сисцтл -в вм.дирти_ратио = 30; елиф ['$ мем' -лт 1049776]; затим сисцтл -в вм.дирти_бацкгроунд_ратио = 10; сисцтл -в вм.дирти_ратио = 20; елсе сисцтл -в вм.дирти_бацкгроунд_ратио = 5; сисцтл -в вм.дирти_ратио = 10; фи;

Прве две команде покрећу се на паметним телефонима са 512 МБ РАМ-а, друге - са 1 ГБ, а друге - са више од 1 ГБ. Али у ствари постоји само један разлог за промену подразумеваних подешавања - уређај са врло спором интерном меморијом или меморијском картицом. У овом случају је разумно ширити вредности променљивих, односно направити нешто попут овог:

сисцтл -в вм.дирти_бацкгроунд_ратио = 10 сисцтл -в вм.дирти_ратио = 60

Тада, када систем за пренапонски протокол упише операције, без потребе за снимањем података на диск, до последњег се неће пребацити у синхрони режим, што ће дозволити апликацијама да смање заостајање приликом снимања.

Додатне бескорисне промене и подешавања перформанси

Постоји много више „оптимизација“ које заиста не раде ништа. Већина њих једноставно нема никакав ефекат, док се други могу побољшати неки аспект перформанси, док се уређај погоршава на друге начине ( обично се своди на перформансе у односу на пражњење батерије) .

Ево неколико додатних популарних оптимизација које могу, али не морају бити корисне, у зависности од Андроид система и уређаја.

• Убрзање - Мало убрзање за побољшање перформанси и поништавање - штеди мало батерије.
• Оптимизација базе података - у теорији ово требало би дају побољшање перформанси уређаја, али је несумњиво.
• Зипалигн - Иронично, упркос уграђеном Андроид СДК поравнавању садржаја унутар АПК-датотеке у продавници, можете пронаћи да се пуно софтвера не преноси путем зипалигн-а.
• Онемогућите непотребне системске услуге уклањањем неискоришћених системских и ретко коришћених независних апликација. У основи, деинсталирање блоатваре-а.
• Прилагођено језгро са оптимизацијама за одређени уређај (опет, нису сва језгра подједнако добра).
• Већ описан И / О планер нооп.
• Алгоритам засићења ТЦП Вествоод - ефикасније се користи у подразумеваном Андроид Цубиц-у за бежичне мреже, доступан у прилагођеним језгрима.

Бескорисна подешавања буилд.проп

ЛараЦрафт304 са форума КСДА Девелоперс спровео је студију и открио да импресиван број поставки /систем/буилд.проп који се препоручују за употребу „стручњака“ не постоји у изворном АОСП и ЦианогенМод. Ево листе:

ро.рил.дисабле.повер.цоллапсе ро.мот.ери.лосалерт.делаи ро.цонфиг.хв_фаст_дорманци ро.цонфиг.хв_повер_савинг виндовсмгр.мак_евентс_пер_сец персист.цуст.тел.еонс ро.мак.флинг_велоцити ро.мин.флинг_велоцити. кернел.цхецкјни далвик.вм.верифи-битецоде дебуг.перформанце.тунинг видео.аццелерате.хв ро.медиа.дец.јпег.мемцап ро.цонфиг.ноцхецкин профилер.форце_дисабле_улог профилер.форце_дисабле_ерр_рпт ерсист.сАП.АДС.ЈПГ.ХАДС.ХАД.ХАД