По този начин много от всички скриптове за оптимизация използват същите методи, някои от които са напълно остарели или вредни в дългосрочен план. В обобщение, по-голямата част от оптимизираните скриптове „всичко в едно“ не са нищо друго освен препоръчани настройки, без ясна представа как и защо тези оптимизации „работят“ - потребителите след това мигат скриптовете и твърдят, че тяхната производителност изведнъж е по-бърза ( а всъщност най-вероятно много простият акт на рестартиране на устройството им е причинил повишаване на производителността , тъй като всичко в RAM на устройството се изчиства) .
В тази изключителна статия за Appuals ще изтъкнем някои от най-често срещаните препоръки за „ оптимизиране “ Ефективността на Android и дали те са просто мит или легитимно ощипване на производителността на устройството.
Размяна
На върха на списъка с митове е суапът на Android - което е доста абсурдно от гледна точка на това, че се смята за оптимизация на Android. Основната цел на суаповете е да създаде и свърже файла за пейджинг, което ще освободи място за съхранение в паметта. Това звучи разумно на хартия , но е наистина приложимо за a сървър , който почти няма интерактивност.
Когато използвате редовно суапа на телефона си с Android, това ще доведе до сериозни изоставания, произтичащи от нещата, които се изплъзват покрай кеша. Представете си например, ако дадено приложение се опита да покаже графика, която се съхранява в суапа, който сега трябва да презареди диска, след като освободи място, като постави суап на данни с друго приложение. Наистина е разхвърляно.
Някои ентусиасти на оптимизацията могат да кажат, че суапът не предлага проблеми, но това не е суап, което повишава производителността - това е вграденият механизъм за Android lowmemorykiller , което редовно ще убива подути, високоприоритетни процеси, които не се използват. LMK е проектиран специално за работа с условия с малко памет, се извиква от kswapd процес и обикновено убива потребителски пространствени процеси. Това е различно от OOMkiller (убиец без памет), но това е съвсем различна тема.
Въпросът е, че устройство с например 1GB RAM никога не може да достигне необходимите данни за производителност при суап, така че суапът абсолютно не е необходим в Android. Изпълнението му е изпълнено със закъснение и води до a деградация в производителността, вместо да я оптимизирате.
zRAM - Остарял и вече не е ефективен
zRAM е доказан и ефективен метод за оптимизиране на устройства, за по-стари устройства - помислете за устройства, базирани на KitKat, които работят само с около 512 MB RAM. Фактът, че някои хора все още включват ощипвания на zRAM в оптимизационните скриптове или препоръчват zRAM като някаква модерна промяна на оптимизацията, е пример за хора, които обикновено не следват най-новите оперативни протоколи.
zRAM е предназначен за многоядрени SoC от първостепенен бюджет, като устройства, използващи MTK чипсети и 512 MB RAM. По принцип много евтини китайски телефони. Това, което zRAM основно прави, е да отдели ядрото чрез криптиращия поток.
Когато zRAM се използва на по-стари устройства с едноядрен , дори ако zRAM се препоръчва на такива устройства, големи количества закъснения са склонни да се появяват. Това се случва и с технологията KSM ( Обединяване на същата страница на ядрото) който комбинира еднакви страници с памет в опит да освободи място. Това всъщност се препоръчва от Google, но води до по-голямо изоставане на по-старите устройства, тъй като постоянно активното ядро theads работи непрекъснато от паметта за търсене на дублирани страници. По принцип опитът да стартирате оптимизацията забавя още повече устройството, иронично.
Seeder - Остарял от Android 3.0
Един от най-обсъжданите съвети за оптимизация сред разработчиците на Android е кедър и сме сигурни, че някой може да се опита да ни докаже, че грешим по тази тема - но първо трябва да разгледаме историята на сеялката.
Приложение Seeder за Android
Да, има голям брой доклади, които декларират по-добра производителност на Android след инсталиране на много по-стари устройства с Android . Хората обаче по някаква причина вярват, че това означава, че това е и приложима оптимизация за модерни устройства с Android , което е абсолютно абсурдно. Фактът, че Seeder все още се поддържа и предлага като „ модерен ” инструментът за намаляване на закъснението е пример за дезинформация - макар че това не е вина на разработчика на Seeder, тъй като дори на страницата им в Play Store се отбелязва, че Seeder е по-малко ефективен след Android 4.0+. И все пак по каквато и да е причина, Seeder все още се появява в дискусиите за оптимизация на съвременните системи с Android.
Това, което Seeder основно прави за Android 3.0, е да отстрани грешка, при която Android Runtime активно ще използва файла / dev / random / за придобиване на ентропия. Буферът / dev / random / ще стане нестабилен и системата ще бъде блокирана, докато не запълни необходимото количество данни - помислете за малки неща като различните сензори и бутони на устройството с Android.
Авторът на Seeder взе Linux-демон rngd и компилиран за andstroil на Android, така че да вземе случайни данни от много по-бърз и по-предсказуем / dev / urandom път и ги обединява в dev / random / всяка секунда, без да позволява / dev / random / да се изчерпва. Това доведе до Android система, която не изпитва липса на ентропия и работи много по-гладко.
Google разби тази грешка след Android 3.0, но по някаква причина Seeder все още се появява „Препоръчителни ощипвания“ списъци за оптимизация на производителността на Android. Освен това приложението Seeder има няколко аналога като sEFix, които включват функционалността на Seeder, независимо дали се използва същата rngd или алтернативата хеджиран , или дори просто символна връзка между / dev / urandom и / dev / random. Това е абсолютно безсмислено за съвременните системи с Android.
Причината, поради която е безсмислена, е, че по-новите версии на Android използват / dev / random / в три основни компонента - libcrypto , за кодиране на SSL връзки, генериране на SSH ключове и др.
Така че, когато Сеялка или подобрения, базирани на Seeder, са включени в съвременните скриптове за оптимизация на Android, а това, което в крайна сметка се случва, е деградация в производителността на устройството, защото rngd постоянно ще събужда устройството и ще доведе до увеличаване на честотата на процесора, което, разбира се, се отразява негативно на консумацията на батерията.
Odex
Складният фърмуер на устройства с Android почти винаги е odex. Това означава, че заедно със стандартния пакет за приложения за Android във формат APK, намерен в / system / app / и / system / priv-app /, са с еднакви имена на файлове с разширението .odex. Файловете odex съдържат оптимизирани байтови приложения, които вече са преминали през валидатора и оптимизатора на виртуална машина, след което са записани в отделен файл, използвайки нещо като дексопт инструмент.
Така че файловете на odex имат за цел да разтоварят виртуалната машина и да предложат ускорено стартиране на приложението odexed - в долната част ODEX файловете предотвратяват модификации на фърмуера и създават проблеми с актуализациите, така че поради тази причина се разпространяват много персонализирани ROM като LineageOS без ODEX .
Генерирането на ODEX файлове се извършва по различни начини, като използването на Odexer Tool - проблемът е, че това е чисто плацебо ефект. Когато съвременната система Android не намери odex файлове в / системната директория, системата всъщност ще ги създаде и ще ги постави в директорията / system / dalvik-cache /. Точно това се случва, когато например мигате нова версия на Android и тя известява „Заето, оптимизиране на приложения“ за известно време.
Ощипвания на Lowmemorykiller
Многозадачността в Android се различава от другите мобилни операционни системи в смисъл, че се основава на класически модел, при който приложенията работят тихо във фонов режим и няма ограничения за броя на фоновите приложения ( освен ако не е зададен в Опции за разработчици, но това обикновено се препоръчва срещу) - освен това функционалността на прехода към фоново изпълнение не е спряна, въпреки че системата си запазва правото да убива фонови приложения в ситуации с малко памет ( вижте къде говорихме за lowmemorykiller и убиец без памет по-рано в това ръководство) .
За да се върнете към lowmemorykiller механизъм, Android може да продължи да работи с ограничен обем памет и липса на суап-дял. Потребителят може да продължи да стартира приложения и да превключва между тях, а системата безшумно ще убива неизползвани фонови приложения, за да се опита да освободи памет за активни задачи.
Това беше много полезно за Android в ранните дни, въпреки че по някаква причина стана популярно под формата на приложения за убийства на задачи, които обикновено са по-вредни, отколкото полезни. Приложенията, които убиват задачи, или се събуждат на зададени интервали, или се изпълняват от потребителя и изглежда освобождават големи количества RAM, което се разглежда като положително - повече безплатна RAM означава по-бързо устройство, нали? Това обаче не е точно така при Android.
Всъщност наличието на голямо количество безплатна RAM памет всъщност може да бъде вредно за работата на вашето устройство и живота на батерията. Когато приложенията се съхраняват в оперативната памет на Android, е много по-лесно да ги извикате, стартирате и т.н. Системата Android не трябва да отделя много ресурси за превключване към приложението, защото вече е там в паметта.
Поради това убийците на задачи всъщност не са толкова популярни, както някога, въпреки че начинаещите Android все още са склонни да разчитат на тях по някаква причина ( липса на информация, за съжаление) . За съжаление, нова тенденция замени убийците на задачи, тенденцията на lowmemorykiller механизми за настройка. Това би било например MinFreeManager приложение, а основната идея е да се увеличат режийните RAM, преди системата да започне да убива фонови приложения.
Така например, стандартната RAM работи на граници - 4, 8, 12, 24, 32 и 40 Mb, а когато се запълни свободното място за съхранение от 40 MB, едно от кешираните приложения, които се зареждат в паметта но не бяга ще бъде прекратено.
Така че основно Android винаги ще има поне 40 MB налична памет, което е достатъчно, за да побере още едно приложение преди lowmemorykiller започва своя процес на почистване - което означава, че Android винаги ще направи всичко възможно, за да използва максималното количество налична RAM, без да пречи на потребителското изживяване.
За съжаление, това, което някои ентусиасти от домашния език препоръчват, е да се повиши стойността, например, до 100 MB, преди LMK да влезе. Сега потребителят всъщност ще загуби RAM (100 - 40 = 60), така че вместо да използва това пространство за съхранение на приложения отзад, системата ще запази това количество памет Безплатно , без абсолютно никаква цел за това.
LKM настройка може да бъде полезно за много по-стари устройства с 512 RAM, но кой вече ги притежава? 2 GB е модерният „бюджетен диапазон“, дори 4 GB RAM устройства днес се възприемат като „среден диапазон“, така че LMK ощипванията са наистина остарели и безполезни.
I / O ощипвания
В много оптимизационни скриптове за Android често ще намерите ощипвания, които адресират I / O подсистемата. Например, нека да разгледаме ThunderBolt! Скрипт, който съдържа следните редове:
ехо 0> $ i / опашка / въртене; ехо 1024> $ i / queue / nr_requests;
Първият ред ще даде инструкции на I / O планировчика при работа със SSD, а вторият увеличава максималния размер на I / O на опашката от 128 на 1024 - защото променливата $ i съдържа път към дървото на блоковите устройства в / sys и скриптът работи в цикъл.
След това ще намерите линия, свързана с CFQ планировчика:
echo 1> $ i / queue / iosched / back_seek_penalty; echo 1> $ i / queue / iosched / low_latency; echo 1> $ i / queue / iosched / slice_idle;
Това е последвано от повече редове, които принадлежат на други проектанти, но в крайна сметка първите две команди са безсмислени, защото:
Съвременното ядро на Linux е в състояние да разбере с какъв тип носител за съхранение работи по подразбиране.
Дълга опашка за вход-изход ( като 1024) е безполезен на съвременно устройство с Android, всъщност е безсмислен дори на настолен компютър - наистина се препоръчва само на тежки сървъри . Вашият телефон не е тежък Linux сървър.
За устройство с Android на практика няма приложения с приоритет във вход-изход и няма механичен драйвер, така че най-добрият плановик е опашката noop / FIFO, така че този тип планировщик “ ощипвам ” не прави нищо специално или смислено за I / O подсистемата. Всъщност всички тези команди от многоекранен списък са по-добре заменени от обикновен цикъл:
за i in / sys / block / mmc *; do echo noop> $ i / queue / scheduler echo 0> $ i / queue / iostats done
Това би позволило на noop планировчика за всички устройства от натрупването на I / O статистика, което би трябвало да има положително въздействие върху производителността, макар и много малко и почти напълно незначително.
Друга безполезна настройка на I / O, често срещана в скриптове за производителност, е увеличените стойности за четене напред за SD карти до 2MB. Механизмът за предварително четене е за ранно четене на данни от носителя, преди приложението да поиска достъп до тези данни. Така че основно ядрото ще се опитва да разбере какви данни ще са необходими в бъдеще и ще ги зареди предварително в RAM, което по този начин трябва да намали времето за връщане. Това звучи чудесно на хартия, но алгоритъмът за четене напред е по-често погрешно , което води до напълно ненужни операции на вход-изход, да не говорим за голямо потребление на RAM.
В RAID-масивите се препоръчват високи стойности за четене между 1 и 8 MB, но за устройства с Android е най-добре просто да оставите стойността по подразбиране от 128 KB.
Ощипвания на системата за управление на виртуална памет
Друга често срещана техника за „оптимизация“ е настройването на подсистемата за управление на виртуална памет. Това обикновено е насочено само към две променливи на ядрото, vm.dirty_background_ratio и vm.dirty_ratio, които са за регулиране на размера на буфера за съхраняване на „мръсни“ данни. Мръсно данните обикновено са данни, които са записани на диск, но има още много в паметта и чакат да бъдат записани на диск.
Типичните стойности на ощипване както в дистрибуциите на Linux, така и в Androis за подсистемата за управление на VM ще бъдат като:
vm.dirty_background_ratio = 10 vm.dirty_ratio_ratio = 20
Така че това, което се опитва да направи, е, че когато мръсният буфер за данни е 10% от общото количество RAM, той се събужда pdflush поток и започва да записва данни на диска - ако операцията по запис на данни на диска ще бъде твърде интензивно , буферът ще продължи да расте и когато достигне 20% от наличната RAM, системата ще премине към последваща операция за запис в синхронен режим - без предварително буфер. Това означава, че работата по запис на дисково приложение ще бъде блокирани, докато данните бъдат записани на диск (AKA ‘изоставане’).
Това, което трябва да разберете е, че дори ако размерът на буфера не достига 10% , системата автоматично ще започне pdflush след 30 секунди. Комбинацията от 10/20 е доста разумна, например на устройство с 1GB 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; иначе 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 планиране noop.
- Алгоритъм за насищане TCP Westwood - По-ефективно се използва в Android Cubic по подразбиране за безжични мрежи, наличен в персонализирани ядра.
Безполезни настройки build.prop
LaraCraft304 от форума за разработчици на XDA проведе проучване и установи, че внушителен брой /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.Етикети android Развитие 12 минути четене
