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

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

Тамо је чак и мноштво „скрипти за оптимизацију“, све-у-једном флексибилни .зипови који обећавају значајно повећање перформанси, трајања батерије и других ствари. Неки подешавања могу заиста да функционишу, али већина је једноставно плацебо ефекат, или још горе, заправо има негативан утицај на ваш уређај.

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

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

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

Заменити

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

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

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

Поента је у томе што уређај са, на пример, 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 са КСДА Девелоперс форума је спровео истраживање и установио да импресиван број поставки /систем/буилд.проп који се препоручују за употребу „стручњацима“ не постоје у изворима АОСП и ЦианогенМод. Ево листе:

 ро.рил.дисабле.повер.цоллапсе ро.мот.ери.лосалерт.делаи ро.цонфиг.хв_фаст_дорманци ро.цонфиг.хв_повер_савинг виндовсмгр.мак_евентс_пер_сец персист.цуст.тел.еонс ро.мак.флинг_велоцити ро.мин.флинг_велоцити кернел.цхецкјни далвик.вм.верифи-битецоде дебуг.перформанце.тунинг видео.аццелерате.хв ро.медиа.дец.јпег.мемцап ро.цонфиг.ноцхецкин профил