Дебютира най-често срещаните митове за Android оптимизация

Има много ръководства за обучение, посветени на повишаване на производителността на Android и общи съвети за оптимизация. Някои от тях са законни, а други се базират само на теория или остарели оперативни методи в системата на Android, или са просто глупости. Това включва препоръки за размяна, стойности, добавени към build.prop, и променливи промени в Linux ядрото.

Има дори много „скриптове за оптимизация“, всичко, което може да се плаши. Zip, които обещават значително да увеличат производителността, живота на батерията и други неща. Някои от ощипването всъщност могат да работят, но мнозинството са просто плацебо ефект или по-лошо, всъщност имат отрицателно въздействие върху вашето устройство.

Това не означава, че хората пускат умишлено скритите скриптове - определено има фалшиви платени приложения в Play Store, но сценариите за оптимизация, пуснати на форумите за Android, обикновено са добронамерени, просто така се случва програмистът да бъде погрешно информиран, или просто експериментирате с различни настройки за оптимизация. За съжаление има тенденция да се наблюдава някакъв ефект на снежна топка, особено в сценариите за оптимизация „всичко в едно“. Една малка шепа ощипвания всъщност може да направи нещо, докато друг набор от ощипвания в скрипт може да не направи абсолютно нищо - все пак тези скриптове се предават като вълшебни куршуми, без никакво реално разследване на това, което работи и кое не,

По този начин много от всички скриптове за оптимизация използват едни и същи методи, някои от които са напълно остарели или вредни в дългосрочен план. В обобщение, по-голямата част от сценариите за оптимизация „всичко в едно“ не са нищо друго, освен препоръчани настройки, без ясна представа как или защо работят тези оптимизации - потребителите след това флаш скриптове и твърдят, че тяхната ефективност изведнъж е по-бърза ( когато всъщност най-вероятно е много простият акт на рестартиране на устройството им е довел до повишаване на производителността, тъй като всичко в RAM паметта на устройството се изчиства) .

В тази изключителна статия за Appuals ще изтъкнем някои от най-често срещаните препоръки за „ оптимизиране“ на работата на Android и дали те са просто мит или законна настройка за производителността на устройството.

Размяна

В горната част на списъка с митове е суап за Android - което е доста абсурдно от гледна точка на това да се мисли като за Android оптимизация. Основната цел на суаповете е да се създаде и свърже файл за пейджинг, което ще освободи място за съхранение в паметта. Това звучи разумно на хартия, но наистина е приложимо за сървър, който почти няма интерактивност.

Когато използвате суап телефона на вашия Android редовно, това ще доведе до тежки изоставания, които произтичат от нещата, които се изплъзват покрай кеша. Представете си например, ако приложението се опита да покаже графика, която се съхранява в суапа, която сега трябва да зареди отново диска, след като освободи място, като постави суап за данни с друго приложение. Наистина е разхвърлян.

Някои ентусиасти за оптимизация могат да кажат, че суапът не предлага проблеми, но това не е суап, което увеличава производителността - това е вграденият Android механизъм lowmemorykiller, който редовно ще убива подути, високоприоритетни процеси, които не се използват. LMK е създаден специално за обработка на условия с ниска памет, извиква се от процеса kswapd и като цяло убива процесите в потребителското пространство. Това е различно от OOMkiller (убиец извън паметта), но това е съвсем друга тема.

Въпросът е, че устройство с примерно 1 GB RAM никога не може да достигне необходимите данни за производителност при суап и затова суап абсолютно не е необходим в Android. Изпълнението му е просто изпълнено с изоставане и води до влошаване на производителността, вместо да се оптимизира.

zRAM - остарял и няма по-дълъг ефективен

zRAM е доказан и ефективен метод за оптимизация на устройства, за по-стари устройства - помислете за устройства, базирани на KitKat, които работят само на около 512 MB RAM. Фактът, че някои хора все още включват zRAM ощипване в сценарии за оптимизация или препоръчват zRAM като някакъв вид модерна настройка за оптимизация, е пример за хора, които обикновено не следват най-новите оперативни протоколи.

zRAM е предназначен за многоядрени SoC-ове от бюджета за входно ниво, като устройства, използващи MTK чипсети и 512 MB RAM. Много евтини китайски телефони, по принцип. Това, което zRAM основно прави, е да отдели ядрото чрез потока за криптиране.

Когато zRAM се използва на по-стари устройства с едно ядро, дори ако zRAM се препоръчва на такива устройства, големи количества изоставания са склонни да се появяват. Това се случва и с технологията KSM ( Kernel same Page Merging), която комбинира идентични страници с памет в опит да освободи място. Това всъщност се препоръчва от Google, но води до по-големи забавяния на по-старите устройства, тъй като постоянно активните основни глави се изпълняват непрекъснато от паметта до търсене на дублирани страници. По принцип, опитът да стартирате оптимизационната настройка забавя устройството още повече, по ирония на съдбата.

Seeder - остарял от Android 3.0

Един от най-обсъжданите съвети за оптимизация сред Android разработчиците е сеялката и сме сигурни, че някой може да се опита да ни докаже грешно по тази тема - но първо трябва да проучим историята на сеялката.

Да, има голям брой доклади, които декларират по-добра производителност на Android след инсталиране на много по-стари Android устройства . Хората по някаква причина обаче вярват, че това означава, че е приложима оптимизация и за съвременните Android устройства, което е абсолютно абсурдно. Фактът, че Seeder все още се поддържа и предлага като „ модерен“ инструмент за намаляване на изоставането, е пример за дезинформация - макар че това не е по вина на разработчика на Seeder, тъй като дори страницата им в Play Store отбелязва, че Seeder е по-малко ефективен след Android 4.0+. И въпреки това по някаква причина Seeder все още изскача в дискусиите за оптимизация за съвременните Android системи.

Това, което Seeder прави основно за Android 3.0, е адресиране на грешка, при която Android по време на работа активно ще използва / dev / random / файл за придобиване на ентропия. Буферът / dev / random / буфер ще стане нестабилен и системата ще бъде блокирана, докато не попълни необходимия обем данни - помислете за малки неща като различните сензори и бутони на устройството с Android.

Авторът на Seeder взе Rngd -демона на Linux и компилира за inastroil на 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 ключове и др. библиотеки за генериране на ID при създаване на файлови системи EXT2 / EXT3 / EXT4.

Така че, когато подобренията, базирани на Seeder или Seeder, са включени в съвременните скриптове за оптимизация на Android, това, което в крайна сметка се случва, е влошаване на производителността на устройството, защото rngd непрекъснато ще събужда устройството и ще доведе до увеличаване на честотата на процесора, което, разбира се, влияе негативно на консумацията на батерията,

ODEX

Основният фърмуер на устройства с Android почти винаги odex. Това означава, че наред със стандартния пакет за приложения за Android във формат APK, намиращ се в / system / app / и / system / priv-app /, са с еднакви имена на файлове с разширението .odex. Файловете odex съдържат оптимизирани приложения за байт-кодове, които вече са преминали през виртуалната машина на валидатора и оптимизатора, след което се записват в отделен файл, използвайки нещо като инструмент dexopt .

Така че odex файловете са предназначени за зареждане на виртуална машина и предлагат ускорено стартиране на odexed приложението - отдолу, ODEX файловете предотвратяват модификации на фърмуера и създават проблеми с актуализациите, така че поради тази причина много персонализирани ROM като LineageOS се разпространяват без ODEX .

Генерирането на ODEX файлове се извършва по много начини, като например използването на Odexer Tool - проблемът е, че неговият чисто плацебо ефект. Когато съвременната Android система не открива файлове odex в / системната директория, системата всъщност ще ги създаде и ще ги постави в директорията / system / dalvik-cache /. Точно това се случва, когато например флаш нова версия на Android и тя дава съобщението „Зает, оптимизиране на приложения“ за известно време.

Lowmemorykiller ощипвам

Многозадачността в Android се различава от другите мобилни операционни системи по смисъла на това, че се основава на класически модел, при който приложенията работят тихо във фонов режим и няма ограничения за броя на фоновите приложения ( освен ако не е зададено в Developer Options, но това е като цяло се препоръчва срещу) - освен това функционалността на прехода към изпълнение на заден план не е спряна, въпреки че системата си запазва правото да убива фонови приложения в ситуации с ниска памет ( вижте къде говорихме за убиец с ниска памет и убиец извън паметта по-рано в това водач) .

За да се върнем към механизма с ниска памет, Android може да продължи да работи с ограничено количество памет и липса на swap-дял. Потребителят може да продължи да стартира приложения и да превключва между тях, а системата безшумно ще убие неизползвани фонови приложения, за да опита и да освободи памет за активни задачи.

Това беше много полезно за Android в първите дни, въпреки че по някаква причина той става популярен под формата на приложения за убийство на задачи, които като цяло са по-вредни, отколкото полезни. Приложенията за убиец на задачи или се събуждат през определени интервали, или се управляват от потребителя и изглежда, че освобождават големи количества RAM, което се разглежда като положително - по-свободната RAM означава по-бързо устройство, нали? Не е точно така обаче при Android.

Всъщност наличието на голямо количество безплатна RAM памет всъщност може да бъде вредно за работата на устройството и живота на батерията. Когато приложенията се съхраняват в оперативната памет на Android, много по-лесно е да ги извиквате, да ги стартирате и т.н. Системата Android не трябва да отделя много ресурси за превключване към приложението, защото то вече има в паметта.

Поради това убийците на задачи всъщност не са толкова популярни, колкото някога, въпреки че новаците в Android все още са склонни да разчитат на тях по някаква причина ( липса на информация, за съжаление) . За съжаление, нова тенденция замени убийците на задачи, тенденцията за настройка на механизмите с ниски меморики убийци. Това ще бъде например приложението MinFreeManager, а основната идея е да увеличите режима на RAM, преди системата да започне да убива фоновите приложения.

Така например стандартната RAM работи на граници - 4, 8, 12, 24, 32 и 40 Mb, а когато се запълни свободното пространство за съхранение от 40 MB, едно от кешираните приложения, което се зарежда в паметта, но не работи ще бъде прекратено.

Така че в общи линии Android винаги ще има поне 40 MB свободна памет, което е достатъчно, за да побере още едно приложение, преди lowmemorykiller да започне процеса на почистване - което означава, че Android винаги ще направи всичко възможно, за да използва максималното количество налична оперативна памет, без да пречи на потребителски опит.

За съжаление, това, което някои ентусиасти на домашни любимци започнаха да препоръчват, е стойността да бъде повишена например до 100 MB, преди LMK да започне. Сега потребителят всъщност ще загуби RAM (100 - 40 = 60), така че вместо да използва това пространство за съхранение крайни приложения, системата ще запази това количество памет без абсолютно никаква цел за това.

LKM настройката може да бъде полезна за много по-стари устройства с 512 RAM, но кой вече притежава тези? 2GB е модерният „бюджетен диапазон“, дори 4GB RAM устройства се разглеждат като „среден клас“ в наши дни, така че настройките на LMK са наистина остарели и безполезни.

I / O ощипвам

В много скриптове за оптимизация за Android често ще намерите ощипвания, които адресират I / O подсистемата. Например, нека да разгледаме ThunderBolt! Скрипт, който съдържа тези редове:

 ехо 0> $ i / опашка / ротационен; echo 1024> $ i / queue / nr_requests; 

Първият ред ще даде инструкции на I / O планиращия при работа със SSD, а вторият увеличава максималния размер на входа / изхода на опашката от 128 на 1024 - защото променливата $ i съдържа път към дървото на блок устройства в / sys, а скриптът работи в цикъл.

След това ще намерите ред, свързан с CFQ планиращия:

 ехо 1> $ i / опашка / iosched / back_seek_penalty; ехо 1> $ i / опашка / iosched / low_latency; ехо 1> $ i / опашка / iosched / slice_idle; 

Следва още редове, които принадлежат на други планиращи, но в крайна сметка първите две команди са безсмислени, защото:

Съвременното ядро ​​на Linux е в състояние да разбере с какъв тип носител за съхранение работи по подразбиране.

Дългата опашка за вход-изход ( като 1024) е безполезна на модерно устройство с Android, всъщност е безсмислена дори и на работния плот - наистина препоръчвана само на сървъри с тежък режим . Вашият телефон не е тежък Linux сървър.

За устройство с Android практически няма приложения, които дават приоритет на входа-изхода и няма механичен драйвер, така че най-добрият планиращ е опашката на noop / FIFO, така че този тип „ настройване на планиращите програми“ не прави нищо особено или смислено за I / O подсистема Всъщност, всички тези команди на многоекранни списъци са по-добре заменени от обикновен цикъл:

 за i in / sys / block / mmc *; направи echo noop> $ i / queue / planer echo 0> $ i / queue / iostats направи 

Това ще даде възможност на програмиста на noop за всички дискове от натрупването на I / O статистики, което би трябвало да има положително въздействие върху производителността, макар и много мъничко и почти напълно пренебрежимо.

Друго безполезно ощипване на I / O, което често се среща в сценариите за ефективност, е увеличените стойности за четене за SD карти до 2MB. Механизмът за четене напред е за ранно четене на данни от медията, преди приложението да поиска достъп до тези данни. Така че по принцип ядрото ще се опитва да разбере какви данни ще са необходими в бъдеще и предварително ще го зарежда в оперативната памет, което по този начин би трябвало да намали времето за връщане. Това звучи чудесно на хартия, но алгоритъмът за четене напред е по-често грешен, което води до напълно ненужни операции на вход-изход, да не говорим за висока консумация на RAM.

Високите стойности за четене напред между 1 - 8 MB се препоръчват в RAID-масиви, но за Android устройства е най-добре просто да оставят стойността по подразбиране от 128 KB.

Системата за управление на виртуалната памет се настройва

Друга често срещана техника за „оптимизация“ е настройката на подсистемата за управление на виртуална памет. Това обикновено е насочено само към две променливи на ядрото, vm.dirty_background_ratio и vm.dirty_ratio, които са за регулиране на размера на буфера за съхранение на „мръсни“ данни. Мръсните данни обикновено са данни, които са записани на диска, но все още има памет и чакат да бъдат записани на диск.

Типичните стойности за настройване както в Linux, така и в Androis за подсистемата за управление на VM биха били:

 vm.dirty_background_ratio = 10 vm.dirty_ratio = 20 

Така че това, което се опитва да направи е, че когато мръсният буфер за данни е 10% от общото количество RAM, той пробужда pdflush поток и започва да записва данни на диска - ако операцията по записване на данни на диска ще бъде твърде интензивна, буферът ще продължи да расте и когато достигне 20% от наличната оперативна памет, системата ще премине към следващата операция на запис в синхронен режим - без предварително буфер. Това означава, че работата по запис на дисково приложение ще бъде блокирана, докато данните не бъдат записани на диск (AKA 'lag').

Това, което трябва да разберете е, че дори и размерът на буфера да не достигне 10%, системата автоматично ще стартира в pdflush след 30 секунди. Комбинация от 10/20 е доста разумна, например на устройство с 1 GB RAM, това би било равно на 100 / 200MB RAM, което е повече от достатъчно по отношение на записи за разрушаване, при които скоростта често е под записа на скоростта в системата NAND - памет или SD-карта, например при инсталиране на приложения или копиране на файлове от компютър.

По някаква причина сценаристите се опитват да издигнат тази стойност още по-високо, до абсурдни проценти. Например в скрипта за оптимизация на Xplix можем да намерим процент до 50/90.

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

На устройство с 1 GB памет, това определя ограничението на мръсен буфер до 500/900 MB, което е напълно безполезно за устройство с Android, тъй като би работило само при постоянно записване на диска - нещо, което се случва само на тежък Linux сървър.

Thunderbolt! Script използва по-разумна стойност, но като цяло, все още е доста безсмислено:

 ако ["$ 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; else sysctl -w vm.dirty_background_ratio = 5; sysctl -w vm.dirty_ratio = 10; Fi; 

Първите две команди се изпълняват на смартфони с 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 планова програма.
• Алгоритъм за насищане TCP Westwood - По-ефективно използван в Android Cubic по подразбиране за безжични мрежи, наличен в персонализирани ядра.

Безполезни настройки build.prop

LaraCraft304 от форума на XDA Developers проведе проучване и установи, че впечатляващ брой настройки /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 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 ersist.sys.odeys.Hys.shys.Hys.Hys.Hys