Rregullimet e skriptit i mbledhin të gjitha. Optimizimi i bazës së të dhënave

Fjala e autorit:
Ky artikull është shkruar nga unë, d.m.th. , me përdorimin e , e cila nuk pretendon të jetë universale dhe zbulimi i "Amerikës", përkundrazi, është menduar për njohje dhe si shkëmbim të përvojës dhe reflektimeve personale, dhe pak për shkencën))))

Hyrje:
Këto skripte modifikimi për init.d janë krijuar për të përmirësuar performancën e Google Phone dhe për ta personalizuar atë për t'iu përshtatur nevojave tuaja.
Që rregullimet të funksionojnë, keni nevojë për mbështetje për init.d nga firmware-i i pajisjes tuaj, si dhe .
Megjithatë, mbështetja init.d mund të imitohet duke përdorur programe të tilla si ose duke aktivizuar artikujt e duhur në programe. Për më tepër, mcTweaker zbaton shumë ndryshime për pajisjen tuaj.
Më lejoni t'ju kujtoj se BusyBox mund të instalohet në firmware me porosi, dhe shumë ndryshime janë zbatuar tashmë!
Ju bëni gjithçka me rrezikun dhe rrezikun tuaj! Për manipulime ju duhet qasje në rrënjë!

Informacione të përgjithshme:
Skriptet e shkuljes duhet të vendosen në shtegun /system/etc/init.d/:

Për të redaktuar/shtuar/hequr skriptet, kam përdorur .
Nëse nuk keni një dosje init.d, atëherë skriptet nuk do të funksionojnë 100%!

Çdo skedar skripti fillon me rreshtin:

#!/system/bin/sh
Më pas, futni kodin e shkuljes, për shembull: echo "500" >
jehona "1000" >
Shembull i skedarit të skriptit

#!/system/bin/sh
echo "500" > /proc/sys/vm/dirty_expire_centisecs
echo "1000" > /proc/sys/vm/dirty_writeback_centisecs

Ne e emërtojmë skedarin e skriptit në çfarëdo mënyre, por në mënyrë që ne vetë t'i njohim ato, për shembull, Battery_tweak- shkulje e baterisë.

Rregullime:
1) Ndryshime të shpejtësisë së lidhjes në internet

echo "0" > /proc/sys/net/ipv4/tcp_timestamps;
echo "1" > /proc/sys/net/ipv4/tcp_tw_reuse;
echo "1" > /proc/sys/net/ipv4/tcp_sack;
echo "1" > /proc/sys/net/ipv4/tcp_tw_recycle;
echo "1" > /proc/sys/net/ipv4/tcp_window_scaling;
echo "5" > /proc/sys/net/ipv4/tcp_keepalive_probes;
echo "30" > /proc/sys/net/ipv4/tcp_keepalive_intvl;
echo "30" > /proc/sys/net/ipv4/tcp_fin_timeout;
echo "404480" > /proc/sys/net/core/wmem_max;
echo "404480" > /proc/sys/net/core/rmem_max;
echo "256960" > /proc/sys/net/core/rmem_default;
echo "256960" > /proc/sys/net/core/wmem_default;
echo "4096, 16384, 404480" > /proc/sys/net/ipv4/tcp_wmem;
echo "4096, 87380, 404480" > /proc/sys/net/ipv4/tcp_rmem;

2) Rregullime për menaxhimin e kujtesës së makinës virtuale

echo "4096" > /proc/sys/vm/min_free_kbytes
echo "0" > /proc/sys/vm/oom_kill_allocating_task;
echo "0" > /proc/sys/vm/panic_on_oom;
echo "0" > /proc/sys/vm/laptop_mode;
echo "0" > /proc/sys/vm/swappiness
echo "50" > /proc/sys/vm/vfs_cache_pressure
echo "90" > /proc/sys/vm/dirty_ratio
echo "70" > /proc/sys/vm/dirty_background_ratio

3) Rregullime të kernelit

echo "8" > /proc/sys/vm/page-cluster;
echo "64000" > /proc/sys/kernel/msgmni;
echo "64000" > /proc/sys/kernel/msgmax;
echo "10" > /proc/sys/fs/lease-break-time;
echo "500, 512000, 64, 2048" > /proc/sys/kernel/sem;

4) Rritja e jetëgjatësisë së baterisë

echo "500" > /proc/sys/vm/dirty_expire_centisecs
echo "1000" > /proc/sys/vm/dirty_writeback_centisecs

5) Rregulloni shpejtësinë e leximit të kartës SD (rritni cache-in e kartës)

echo "2048" > /sys/devices/virtual/bdi/179:0/read_ahead_kb;

6) Defragmentimi i skedarëve të bazës së të dhënave?

per une ne \
`find /data -inname "*.db"`
bëj\
sqlite3 $i "VACUUM;";
bërë

7) Çaktivizo regjistruesit (nuk do të shkruhen skedarë regjistrash)

rm /dev/log/main

8) Ne konfigurojmë pragjet në të cilat aplikacionet do të shkarkohen kur ka memorie të pamjaftueshme

echo "2048, 3072, 6144, 15360, 17920, 20480" > /sys/module/lowmemorykiller/parameters/minfree

9) Rregullime të menaxhimit të cache

LOOP=`ls -d /sys/block/loop*`;
RAM=`ls -d /sys/block/ram*`;
MMC=`ls -d /sys/block/mmc*`;
për j në $LOOP $RAM
bëj
echo "0" > $j/radhë/rrotullues;
echo "2048" > $j/queue/read_ahead_kb;
bërë

10) Rregullime të CPU-së?

SAMPLING_RATE=$(shp. kutia e zënë "cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_transition_latency" \* 750 / 1000)
echo 95 > /sys/devices/system/cpu/cpufreq/ondemand/up_threshold
echo $SAMPLING_RATE > /sys/devices/system/cpu/cpu0/cpufreq/ondemand/sampling_rate

11) Transferoni cache dalvik në seksionin cache për të lehtësuar seksionin e të dhënave

CACHESIZE=$(df -k /cache | bisht -n1 | tr -s " " | prerë -d " " -f2)
nëse [ $CACHESIZE -gt 80000 ]
pastaj
echo "U zbulua cache e madhe, duke lëvizur dalvik-cache në /cache"
nëse [! -d /cache/dalvik-cache ]
pastaj
busybox rm -rf /cache/dalvik-cache /data/dalvik-cache
mkdir /cache/dalvik-cache /data/dalvik-cache
fi

Busybox chown 1000:1000 /cache/dalvik-cache
busybox chmod 0771 /cache/dalvik-cache

# lidh montimin e dalvik-cache që të mund të nisim akoma pa kartën sd
busybox montoj -o lidh /cache/dalvik-cache /data/dalvik-cache
busybox chown 1000:1000 /data/dalvik-cache
busybox chmod 0771 /data/dalvik-cache
tjetër
echo "U zbulua cache e vogël, dalvik-cache do të mbetet në /data"
fi

12) Fshirja e cache-it, skedarëve tmp dhe mbeturinave të tjera

#remove cache, tmp dhe skedarë të papërdorur
rm -f /cache/*.apk
rm -f /cache/*.tmp
rm -f /data/dalvik-cache/*.apk
rm -f /data/dalvik-cache/*.tmp

nëse [ -e /data/system/userbehavior.db ]
pastaj
rm -f /data/system/userbehavior.db
fi

nëse [ -d /data/system/usagestats]
pastaj
chmod 400 /data/system/usagestats
fi

nëse [ -d /data/system/appusagestats]
pastaj
chmod 400 /data/system/appusagestats
fi

#fshi regjistrin kryesor
nëse [ -e /dev/log/main ]
pastaj
rm -f /dev/log/main
fi

13) Ndryshimi i prioritetit të proceseve - vetëm ato standarde. Këshillohet që të kontrolloni emrat e proceseve në pajisjen tuaj përpara përdorimit. Projektuar për të rritur funksionimin e qetë të pajisjes dhe për ta bërë përgjigjen më të këndshme)

renice -20 "pidof com.android.phone"
renice -19 "pidof com.android.inputmethod.latin"
renice -19 "pidof com.swype.android.inputmethod"
renice -17 "pidof com.android.systemui"
renice -9 "pidof com.android.settings"
renice -9 "pidof com.android.vending"
renice -6 "pidof com.sec.android.app.camera"
renice -6 "pidof com.sec.android.app.fm"
renice -6 "pidof com.google.android.apps.maps"
renice -4 "pidof com.google.android.apps.googlevoice"
renice -3 "pidof android.process.media"

p.s. E përsëris, të gjitha manipulimet me pajisjen tuaj janë në ndërgjegjen tuaj! Kur përdorni programe tweaker si mcTweaker, fshini skriptet e përdoruesve për të shmangur situatat e pakëndshme dhe gjithmonë bëni një kopje rezervë!
p.p.s. Artikulli do të përditësohet me informacione të reja sa më shpejt të jetë e mundur! Bëni pyetje në komente!

Skedari i bashkangjitur #1:

Kujdes! Ju nuk keni leje për të parë tekstin e fshehur.

Pjesa më e madhe e parametrave të sistemit Android të fshehura nga sytë e përdoruesit ruhet në një skedar të vetëm të quajtur build.prop. Ndryshimi i duhur i cilësimeve do t'ju ndihmojë të jepni një jetë të dytë në vegël: përmirësoni autonominë dhe performancën, optimizoni ndërfaqen. Në artikull do të tregojmë se si të modifikojmë lehtësisht build.prop dhe të japim shembuj të rregullimeve të dobishme, si dhe ato që enden nga artikulli në artikull në burime të ndryshme, por në fakt nuk funksionojnë.

Skedari build.prop funksionon si më poshtë: kur fillon smartphone, lexohet përmbajtja prej tij, e cila në një mënyrë ose në një tjetër ndikon në logjikën e kodit të sistemit operativ. Ndër këto cilësime të fshehura nga përdoruesi, ka të dyja ato thellësisht sistematike që lihen më mirë të paprekura dhe ato që mund të ndryshohen pa dhimbje. Për shembull, duke shtuar disa rreshta në build.prop, mund të shpejtoni ngarkimin e pajisjes, të hiqni vonesën për një telefonatë në hyrje ose të aktivizoni rrotullimin automatik të ekranit në ekranin e kyçjes. Tani do t'ju tregojmë se si ta bëni këtë.

Gjithçka që ju nevojitet për të bërë ndryshime është një redaktues skedari teksti dhe të drejtat e superpërdoruesit. Mund të mësoni se si të merrni qasje rrënjësore në forumin tonë në seksionin e firmuerit Android në temën kushtuar smartphone ose tabletit tuaj. Për të bërë ndryshime të drejtpërdrejta në skedar, mund të përdorni një redaktues të rregullt teksti - për ta bërë këtë, do t'ju duhet të gjeni në mënyrë të pavarur skedarin përgjatë rrugës /system/build.prop. Por është shumë më i përshtatshëm për të bërë ndryshime duke përdorur një program të specializuar, për shembull, Redaktori BuildProp.

Para se të filloni të eksperimentoni, duhet të bëni një kopje rezervë të skedarit. BuildProp Editor ruan automatikisht një kopje rezervë të origjinalit herën e parë që e nisni. Nëse vendosni të përdorni një redaktues të rregullt teksti, atëherë mos harroni të bëni një kopje manualisht. Nëse diçka shkon keq papritur, atëherë do t'ju duhet vetëm të zëvendësoni build.prop "të dëmtuar" me një kopje rezervë për të kthyer gjithçka në vendin e vet.

Përshpejtoni ngarkimin. Telefonat inteligjentë modernë shpesh kërkojnë pothuajse më shumë kohë për t'u nisur sesa PC-të e zakonshëm. Duke ndërhyrë pak me cilësimet në build.prop, mund ta rrisni lehtësisht shpejtësinë e ngarkimit të pajisjes me një e gjysmë deri në dy herë! Cilësimet e mëposhtme do të ndihmojnë me këtë:

debug.sf.nobootanimation=1

ro.config.hw_quickpoweron=e vërtetë

Pas bërjes së këtyre cilësimeve, modaliteti i mbylljes së pajisjes do të ndryshohet dhe animacioni i nisjes së zhvilluesit të firmuerit do të çaktivizohet gjithashtu. Si rezultat, kur nisni telefonin inteligjent, nuk do të shihni asgjë në ekran për ca kohë. Ju nuk duhet të keni frikë nga kjo: ishte falë çaktivizimit të animacioneve të panevojshme që telefoni inteligjent testues filloi të nisej në vetëm 30 sekonda në vend të 50 sekondave të mëparshme.

Përshpejtimi i punës së kujtesës. Si parazgjedhje, Android regjistron shumë veprime në një skedar të veçantë, por zhvilluesit u nevojiten vetëm për të korrigjuar aplikacionet. Ky regjistër nuk do të jetë i dobishëm për përdoruesit e zakonshëm, dhe për këtë arsye ia vlen ta çaktivizoni atë duke shtuar linjën te build.prop

logcat.live=çaktivizoj

Çaktivizimi i regjistrit do të zvogëlojë numrin e operacioneve të diskut, gjë që do të ketë një efekt pozitiv në performancën e memories së brendshme të smartphone. Vërtetë, ndryshimi do të jetë i dukshëm vetëm në pajisjet me lloje të ngadalta të memories: në rastin tonë, shpejtësia vijuese e shkrimit u rrit me 2 MB/s.

Përshpejtimi i rrjetit. Ky rregullim rrit madhësinë e buferëve TCP, gjë që do të ndihmojë në rritjen e shpejtësisë së një lidhjeje të ngadaltë në internet, veçanërisht kur përdorni rrjetet celulare. Epo, regjistrimi i serverëve DNS të Google në disa raste ju lejon të zvogëloni kohën e ping.

net.tcp.buffersize.default=4096,87380,256960,4096, 16384,256960

net.tcp.buffersize.wifi=4096,87380,256960,4096,16384,256960

net.tcp.buffersize.umts=4096,87380,256960,4096,16384,256960

net.tcp.buffersize.gprs=4096,87380,256960,4096,16384,256960

net.tcp.buffersize.edge=4096,87380,256960,4096,16384,256960

net.rmnet0.dns1=8.8.8.8

net.rmnet0.dns2=8.8.4.4

neto.dns1=8.8.8.8

neto.dns2=8.8.4.4

Për ne ndryshimi doli i dukshëm, por këtë nuk duhet ta harrojmë ndikimi më i madh Shpejtësia ndikohet nga ngarkesa vazhdimisht në ndryshim e stacioneve bazë.

Shkalla e transferimit të të dhënave me cilësimet standarde

Shpejtësia e transferimit të të dhënave pas redaktimit të build.prop

Fatkeqësisht, mrekullitë nuk ndodhin - një rritje e dyfishtë e autonomisë nuk mund të arrihet me asnjë ndryshim. Por është mjaft e mundur të shtoni 30-60 minuta shtesë në kohën e funksionimit të pajisjes.

Rritni intervalet e skanimit Wi-Fi. Si parazgjedhje, Android skanon rrjetet përreth Wi-Fi çdo 20-90 sekonda. Për më tepër, ai e bën këtë edhe kur Wi-Fi është i fikur, por kërkimi në sfond për rrjetet lejohet për të rritur saktësinë e përcaktimit të vendndodhjes. Për të zgjeruar këtë interval, duhet të shtoni rreshtin në skedarin build.prop:

wifi.supplicant_scan_interval=200

Këtu numri 200 është intervali i skanimit të rrjetit në sekonda.

Kurseni baterinë në LineageOS. Një rregullim i vogël që siguron menaxhim më efikas të modalitetit të gjumit kur përdorni CyanogenMod ose LineageOS në telefonat inteligjentë me çipa Qualcomm:

pm.sleep_mode=1

Mund të gjeni rregullime edhe më të dobishme në forumin 4PDA.

Përveç rregullimeve të vërteta që funksionojnë të dhëna në këtë artikull dhe në temën e forumit, ka shumë që janë shpërndarë gjerësisht në internet, por në fakt nuk kanë asnjë efekt në funksionimin e sistemit. Një studim përkatës u krye nga një nga përdoruesit e burimit xda. Ai analizoi kodin burimor të AOSP dhe CyanogenMod dhe zbuloi se shumë rregullime të njohura thjesht nuk përmendeshin në kodin burimor të Android. Midis tyre ka një sërë regjistrimesh.

Rregullime që nuk kursejnë baterinë:

ro.ril.çaktivizoj.fuqi.kolaps

ro.mot.eri.losalert.vonesa

ro.config.hw_fast_dormancy

ro.config.hw_power_saving

Rregullime që nuk përshpejtojnë punën:

windowsmgr.max_events_per_sec

këmbëngul.cust.tel.eons

ro.max.fling_shpejtësia

ro.min.shpejtësia_fluturuese
korrigjimi.performanca.akordim

video.përshpejtoj.hw

Rregullime të tjera të padobishme. Ato janë krijuar për të çaktivizuar kontrollin e bajtkodit Dalvik dhe për të ndaluar shkarkimin e lëshuesit nga RAM. Pasi ata me të vërtetë funksionuan, por janë krejtësisht të parëndësishme për versionet moderne të Android për shkak të ndryshimeve në arkitekturën e brendshme të OS:

dalvik.vm.verify-bytecode

Dhe disa rregullime të tjera të ndryshme që thjesht nuk funksionojnë:

ro.media.dec.jpeg.memcap

ro.config.nocheckin

profiler.force_disable_ulog

profiler.force_disable_err_rpt

persist.sys.shutdown.mode

ro.kernel.checkjni

Është interesante se ndërsa disa nga këto hyrje ishin të dobishme për versionet më të vjetra të Android, disa nuk funksionuan fare, duke qenë një lloj placebo. Dhe pse në radhë të parë lindi një mashtrim i tillë masiv tani është e pamundur të zbulohet. Megjithatë, bërja e shënimeve të tilla në build.prop nuk do ta përkeqësojë funksionimin e smartfonit - të gjitha hyrjet e pavlefshme thjesht do të shpërfillen.

Edhe pse shumë nga rregullimet e rekomanduara në forume dhe faqe të ndryshme të internetit nuk funksionojnë fare, skedari build.prop është ende një mundësi e mirë për të përmirësuar ndërfaqen dhe performancën e smartfonit tuaj. Pra, merrni të drejtat e superpërdoruesit, rezervoni cilësimet tuaja dhe ndjehuni të lirë të eksperimentoni!

Janë kaq të dashura për të gjithë dashamirët e Android. Çfarë mund të bëjnë ata? E bën telefonin tuaj tepër të zakonshëm dhe e forcon telefonin inteligjent duke ndryshuar veçoritë e tij të brendshme të cilat janë default nga kompania OS. Nëse keni provuar ndonjëherë disa , Jam i sigurt që e dini tashmë rëndësinë e Best Build.prop Tweaks dhe veçoritë e tyre në të cilat mund të keni akses pasi t'i aplikoni në pajisjen tuaj. Build Prop Tweaks mund të aplikohen në çdo Android që funksionon në Jellybean, Kitkat, Lollipop ose Marshmallow.

Për Dashamirët e Android, ne po ndajmë rregullimet më të mira të mbështetjes së ndërtimit për Android. Android është më i miri platformë për testimin e Tweaks & Trucks të reja të mrekullueshme mbi të. Nëse jeni i varur nga Android, atëherë mund t'ju pëlqejë gjithashtu ta dizajnoni atë me Launchers të ndryshëm dhe të gjitha dhe Build Props janë gjëja më e çmendur për ty.

Qasja në rrënjë është kërkesa kryesore për të bërë çdo gjë nën rrënjë në smartphone tuaj Android. Ne jemi në gjendje të përdorim në celularin tonë Rooted për të rritur performancën dhe kërkimin e tij. Rooting zhbllokon plotësisht telefonin tonë Android dhe ne jemi në gjendje të ndryshojmë çdo gjë në veçoritë tona të Android siç dëshirojmë. Ju jeni në gjendje dhe gjithashtu pas rooting pajisjen tuaj.

Shumë mjeshtër të Android-it pëlqejnë të testojnë rregullime të ndryshme të mrekullueshme në smartfonin e tyre. Ata instalojnë dhe testojnë stile të ndryshme në pajisjet e tyre Android për të ndryshuar pamjen e saj. Ata gjithashtu duan të testojnë ndryshime të ndryshme Build.prop në telefonat e tyre Android.

Pra, nëse ju pëlqen të instaloni lloje të ndryshme rregullimesh në smartphone tuaj, atëherë jeni në vendin e duhur. Këtu do të ndaj Ndërtoni rregullime mbështetëse për JellyBean, Kitkat, Lollipop & Marshmallow Versioni i telefonave inteligjentë Android për të rritur performancën e pajisjes suaj Android. Këto janë ndryshimet e reja më të fundit të Build prop me të cilat mund të ndryshoni shumë veçori të brendshme të pajisjes tuaj Android dhe të rritni performancën e pajisjes tuaj Android. Por ju duhet të ketë nevojë për të çrrënjosur pajisjen tuaj Android fillimisht për të instaluar këto rregullime në celularin tuaj. Le të shikoni nga lista e mëposhtme.

Duhet të kontrollohet:- | |

Build.prop është një skedar në pajisjen tonë Android i cili ruhet në /system/path të pajisjeve tona Android. Ai ruan të gjitha Specifikimet, Veçoritë dhe Cilësimet e celularit tonë Android. Është skedar shumë i rëndësishëm i pajisjes sonë Android, pa këtë skedar pajisja jonë Android nuk mund të funksionojë, as celulari juaj Android nuk mund të fillojë pa këtë skedar. Ky skedar është i padukshëm, prandaj nuk e kemi parë kurrë këtë skedar në celularin tonë. Por ne jemi në gjendje ta gjejmë këtë skedar pasi të kemi çrrënjosur pajisjen tonë Android. Dhe ne jemi gjithashtu në gjendje të ndryshojmë cilësimin e tij për të shkulur telefonin tonë Android. Root është i nevojshëm për të, sepse sistemi ynë operativ Android nuk mund të japë leje për të prekur funksionet e tij të brendshme, kështu që ne duhet të rrënjosim pajisjen tonë për t'i dhënë leje pajisjes Android.

Ju gjithashtu mund të shtoni disa ndryshime të tjera në pajisjen tuaj Android nga skedari Build.prop. Kështu që në këtë artikull do të ndaj disa rregullime Build.prop për telefonat e versionit Android JellyBean, Kitkat, Lollipop, Marhsmallow për të rritur performancën e pajisjes suaj. Gjithashtu përshkrova hapat për mënyrën e shtimit të ndryshimeve Build.prop në Android në fund të këtij artikulli.

Duhet lexuar: -

(Vlera e parazgjedhur është 240. Mos harroni të instaloni një treg të rregulluar pasi ta ndryshoni atë.)

(Nëse SMS/MMS nuk mund të dërgohej, riprovohet pas 2 sekondash në vend të 5 sekondave)

(Mund të jetë i paqëndrueshëm - më mirë ta aktivizoni)

Këto ishin disa nga modifikimet kryesore të Build Prop për pajisjet Android. Unë mendoj se kam mbuluar të gjitha ndryshimet e kategorizuara të build.prop për ju. Nëse kam humbur diçka, mos ngurroni të komentoni më poshtë. Vetëm në internet këto janë ndryshimet më të njohura që u argëtova, prandaj ndava vetëm këto.

Ndryshe nga iOS, Windows Phone dhe disa OS të tjera celulare, origjinale Kodi Androidështë e hapur, kështu që entuziastët mund të modifikojnë sistemin në çfarëdo mënyre që duan dhe t'i paketojnë modifikimet e tyre në formën e firmware-it të shpërndarë lirisht, si CyanogenMod, Paranoid Android dhe OmniROM. Një firmware i tillë përmban një numër të madh modifikimesh të dobishme, por jo të gjithë janë gati të rrezikojnë duke i instaluar ato. Për fat të mirë, ekziston një mënyrë për të marrë të gjitha përfitimet e porosisë në çdo firmware të aksioneve.

Jo shumë kohë më parë, ne zbuluam se sistemi Xposed ekzistonte për Android - një grup bibliotekash dhe aplikacionesh që, duke punuar së bashku, lejojnë aplikacionet e palëve të treta të përgjojnë thirrjet për çdo klasë Android Java dhe t'i zëvendësojnë ato me të tyret. E thënë thjesht, një analog i Cydia Substrate për iOS, me të cilin përdoruesi mund të ndryshojë sjelljen dhe pamjen e androidit.

Vetë Xposed ofron vetëm mjete për përgjim, ndërsa puna aktuale ndodh në aplikacione të veçanta të quajtura module. Aktualisht, ekzistojnë tashmë disa qindra module të tilla, dhe diapazoni i funksioneve të tyre shtrihet nga gjëra të vogla si shfaqja e fotografisë së një pajtimtari kur bën një telefonatë në ekran të plotë dhe imiton funksionalitetin e firmware-ve të tjerë, deri te motorët me tematikë dhe modulet shumëfunksionale "për të gjitha rastet". “. Pothuajse çdo funksion i çdo firmueri të palëve të treta sot mund të merret duke përdorur modulet Xposed në firmware të rregullt të aksioneve.

Shumica e moduleve nuk varen në asnjë mënyrë nga marka ose modeli i pajisjes dhe mund të funksionojnë në çdo Android duke filluar nga versioni 4.0. I vetmi kufizim serioz është nevoja për të marrë të drejtat rrënjësore, por sot kjo procedurë është e disponueshme edhe për një noob të plotë falë disponueshmërisë së aplikacioneve speciale për rrënjosje.

Xposed përbëhet nga dy komponentë kryesorë: një version i modifikuar i binarit /system/bin/app_process, i cili në Android është përgjegjës për lëshimin e makinës virtuale Dalvik, dhe një grup klasash Java XposedBridge.jar, i cili përmban kodin që mund të përgjojë thirrjet për çdo klasë Java dhe lëshojini atyre klasa të tjera.

Thelbi i metodës. Instaluesi Xposed zëvendëson procesin standard app_process me të tijin. Kur ngarkohet, sistemi operativ nis makinën virtuale duke përdorur një app_process të falsifikuar, i cili ngarkon automatikisht XposedBridge.jar. Ndërsa funksionon, sistemi krijon një makinë virtuale për çdo aplikacion Java që ekzekuton, duke përfshirë GUI-në dhe shumë komponentë të sistemit, në mënyrë që klasat XposedBridge të përfundojnë në secilën prej tyre.

Kur instalohet, moduli Xposed regjistrohet në XposedBridge si një mbajtës për disa klasa Java të këtyre aplikacioneve, gjë që i jep mundësinë t'i zëvendësojë ato me të tijat. Me fjalë të tjera, modulet Xposed nuk e ndryshojnë sistemin, por zëvendësojnë komponentët e tij me "fake", kështu që pas çaktivizimit të modulit ose të gjithë Xposed, sistemi do të kthehet automatikisht në gjendjen e tij origjinale.

Instalimi dhe konfigurimi i Xposed është mjaft i thjeshtë. Në thelbin e saj, kjo është një paketë e rregullt APK që
pas nisjes, ai vendos të gjithë komponentët e nevojshëm që sistemi Xposed të funksionojë në sistem. Mund ta merrni vetë paketën në faqen zyrtare të internetit (goo.gl/61rOz7). Nga rruga, ekziston gjithashtu një depo e moduleve atje, por nuk keni pse të shkarkoni module manualisht, pasi gjithçka mund të bëhet duke përdorur vetë aplikacionin.

Pasi të keni shkarkuar dhe instaluar paketën, shkoni te seksioni "Korniza" dhe klikoni butonin "Instalo/Përditëso", më pas kliko " Rindezje e shpejtë"në mënyrë që sistemi të marrë komponentët e instaluar Xposed herën tjetër që të nisni. Në shumicën e rasteve kjo do të ndodhë
mjafton për të përgatitur Android për instalimin e moduleve. Nëse po flasim për një smartphone me një ndarje të kyçur / sistemi (S-ON), metoda e instalimit do të duhet të ndryshohet në "Nga mënyra e rikuperimit" në menunë "Modaliteti i instalimit të kornizës". Në këtë rast, pas shtypjes
butonin "Instalo/Përditëso", sistemi do të rindizet dhe arkivi me komponentët Xposed do të ndizet automatikisht duke përdorur tastierën e rikuperimit.

Pas rindezjes, ekzekutoni përsëri instaluesin Xposed dhe shkoni te seksioni "Shkarko". Të gjitha modulet e disponueshme në depo shfaqen këtu, si dhe përditësimet për vetë Xposed. Për të instaluar modulin, thjesht zgjidhni atë që ju nevojitet dhe klikoni butonin "Shkarko" pranë versionit më të fundit. Për të aktivizuar modulin, shkoni te seksioni "Modulet", kontrolloni kutinë pranë asaj që keni instaluar dhe rindizni telefonin inteligjent.

Le të përpiqemi të instalojmë një nga modulet. Shiriti i statusit të ngjyrosur është një shembull i mirë. Ne e gjejmë atë, e instalojmë, e aktivizojmë në seksionin "Modulet" të instaluesit Xposed dhe rindizni telefonin inteligjent. Pas shkarkimit, ne përpiqemi të hapim aplikacione të ndryshme. Efekti që duhet të vihet re menjëherë është shiriti i statusit, i cili tani ndryshon ngjyrën në varësi të skemës së ngjyrave të vetë aplikacionit (ashtu si në iOS 7). Kjo është e gjitha, ne ndryshuam sjelljen e komponentit të sistemit pa instaluar firmware me porosi dhe modifikimet u ndezën
shërim!


Më tej, unë do të flas për modulet më interesante, të pazakonta dhe të dobishme Xposed, por së pari do t'ju paralajmëroj për disa nuanca që duhet të dini përpara se të filloni instalimin e tyre.

Së pari, ekzistojnë kryesisht dy lloje modulesh: ato që thjesht bëjnë punën e tyre dhe nuk shkëlqejnë askund, dhe ato që mund të personalizohen. Modulet e tipit të parë mund të ndryshojnë pamjen ose sjelljen e sistemit, por ato nuk mund të personalizohen; ose ato janë aktive në cilësimet Xposed ose janë të çaktivizuar (një shembull i një moduli të tillë është Masterkey Multi-fix). Modulet e llojit të dytë zakonisht nuk shfaqen as vetë, por krijojnë një ikonë në menunë e aplikacionit që siguron qasje në cilësimet e modulit. Me ndihmën e tyre, ju mund të aktivizoni funksione të caktuara të modulit dhe të ndryshoni sjelljen e tij (ka shumë shembuj të moduleve të tilla: Cilësimet e aplikacionit, GravityBox dhe shumë të tjerë).


Së dyti, jo të gjitha modulet janë të pajtueshme me të gjitha versionet e Android. Disa prej tyre janë krijuar për të punuar me lloje të caktuara të firmware-it të aksioneve (për shembull, me firmware nga Samsung ose HTC) dhe mund të sillen në mënyrë të paparashikueshme në firmware të tjerë (megjithëse ata nuk e rregullojnë telefonin inteligjent, natyrisht). Të tjerët janë krijuar për të punuar vetëm me një version specifik të Android. Për shembull, depoja ka dy module GravityBox, njëra prej të cilave është krijuar për të punuar në Jelly Bean (Android 4.1–4.3), tjetra në KitKat (4.4). Për të mos kapur defekte, kjo pikë gjithashtu duhet të merret parasysh. Duhet të keni kujdes edhe me tabletët e bazuar në Android 4.0–4.1, ata përdorin një ndërfaqe që është e papajtueshme me telefonin dhe shumë module nuk funksionojnë.

Firmware i personalizuar është një histori tjetër. Zakonisht nuk lindin probleme me ta, por ndodhin gjëra qesharake. Për shembull, pas instalimit të GravityBox në OmniROM, do të merrni dy tregues të baterisë. Kjo ndodh sepse ky firmware përdor mekanizmin e tij të papajtueshëm të treguesit të baterisë, për të cilin GravityBox nuk di asgjë. Për fat të mirë, problemi zgjidhet lehtësisht duke çaktivizuar treguesin ose në cilësimet e vetë firmuerit ose në GravityBox (vetëm një tregues do të mbetet).

Së treti, një modul mund të jetë jo thjesht një paketë e veçantë, por të jetë pjesë e një aplikacioni të rregullt Android. Nëse instaloni aplikacionin Greenify nga Play Store në smartphone tuaj, një modul përkatës do të shfaqet në Xposed. Në rastin e këtij aplikacioni, ai është opsional dhe nevojitet për të fituar më shumë kontroll mbi gjumin e aplikacionit. Shumë aplikacione të tjera përdorin gjithashtu Xposed për të zgjeruar funksionalitetin e tyre: BubbleUPnP për transmetimin e një transmetimi audio nga çdo luajtës, Cool Tool për shfaqjen e të dhënave të ndryshme në shiritin e statusit, etj.
Le të kalojmë te modulet. Lista ime e më të mirave përfshin më shumë se njëzet module për çdo shije dhe ngjyrë. Këtu janë ata:

GravityBox është një nga modulet më të famshme dhe më të njohura Xposed. Ai nuk ka ndonjë qëllim specifik, shumë të specializuar, por është një koleksion i një numri të madh ndryshimesh të ndryshme që synojnë kryesisht ndryshimin e pamjes së sistemit.

Moduli është në gjendje të personalizojë shiritin e statusit, të ndryshojë grupin dhe vendndodhjen e pllakave në perde, ju lejon të ndryshoni sjelljen e butonave të navigimit ose t'i çaktivizoni ato krejtësisht, zgjeron menynë e rindezjes (në mënyrën e firmuerit të personalizuar), përfshin implementimi i PIE nga Paranoid Android (analog me LMT Launcher), ju lejon të përdorni filtrat e ekranit, të ndryshoni sjelljen e butonave të harduerit, sjelljen e njoftimeve dhe karikimit të LED-ve dhe shumë, shumë më tepër.

Në fakt, GravityBox është një koleksion i veçorive më të mira nga ROM-et e palëve të treta me të cilat mund të ndryshoni Android-in tuaj. Të gjitha funksionet mund të rregullohen mirë, por ndryshe nga firmware-i i personalizuar, konfigurimi bëhet duke përdorur një meny të veçantë dhe jo shumë të përshtatshme, e aksesueshme përmes ikonës GravityBox në menynë e aplikacionit. Përveç GravityBox, në depo
Ju gjithashtu mund të gjeni "module kombinuese" të tjera, si Wanam dhe Xblast Tools, por ato janë inferiore në funksionalitet.

Një tjetër modul shumë i njohur dhe i dobishëm. Projektuar për të ndryshuar pamjen
dhe sjelljen e aplikacioneve individuale. Përfshin veçori të tilla si aftësia për të ndryshuar vlerën e DPI (ju lejon të rritni ose zvogëloni madhësinë e kontrolleve
aplikacionet), duke ndryshuar madhësinë e shkronjave, gjuhën e aplikacionit. Ju lejon të detyroni modalitetin e ekranit të plotë për çdo aplikacion ose të bllokoni zbrazjen e ekranit, të detyroni orientimin e peizazhit ose portretit (i dobishëm për aplikacionet që mund të funksionojnë vetëm në një modalitet, si p.sh. një numërues) dhe shumë të tjera. Një nga karakteristika interesante- aftësia për të shfaqur aplikacionin në krye të ekranit të kyçjes.

Përveç kësaj, moduli ka mekanizmin e tij për revokimin e lejeve të aplikacionit, duke punuar në mënyrë të pavarur nga sistemi AppOps, i cili u shfaq si një veçori e fshehur
në Android 4.3. Me ndihmën e tij, për shembull, mund të ndaloni një aplikacion të caktuar të lundrojë në internet ose të dërgojë SMS. Shumë i përshtatshëm kur keni të bëni me reklama të bezdisshme ose softuer të dyshimtë.

Një modul interesant që imiton një pjesë të funksionalitetit të sistemit të njoftimit Halo nga firmware-i Paranoid Android. Moduli ju lejon të hapni aplikacione të zgjedhura në një dritare lundruese, madhësia dhe transparenca e së cilës mund të ndryshohen sipas dëshirës tuaj. Si parazgjedhje, ai nuk shfaqet në asnjë mënyrë, dhe për të qenë në gjendje të hapni aplikacionin në një dritare lundruese, do të duhet ta shtoni atë në " Lista e bardhë» në menynë "Properties" në cilësimet e modulit. Pas rinisjes së aplikacionit, ai do të hapet në një dritare të veçantë.

Dobia aktuale e modulit nuk është aq e madhe, por është i përshtatshëm për ekzekutimin e aplikacioneve që kryejnë një funksion të thjeshtë dhe nuk kanë nevojë për të gjithë ekranin në parim (për shembull, Wifi ADB). Gjithashtu duhet të keni parasysh se jo të gjitha aplikacionet ndihen rehat me ndryshimet e vazhdueshme në madhësinë e ekranit (kështu imitohet një dritare lundruese) dhe mund të sillen në mënyrë të papërshtatshme.

Një tjetër zbatim i modalitetit me shumë dritare, këtë herë nga firmware OmniROM. Ndryshe nga moduli i përshkruar më sipër, ai nuk krijon një dritare të veçantë për aplikacionin, por e ndan ekranin në dy pjesë, të cilat shfaqin ndërfaqen e aplikacioneve të ndryshme. Kjo është shumë e ngjashme me veçorinë e integruar të firmuerit të Samsung, por vlen për çdo aplikacion, jo vetëm për një grup të kufizuar aplikacionet standarde firmware.

Punon menjëherë pas instalimit dhe rinisjes; një aplikacion i nisur nga desktopi do të hapet në modalitetin e ekranit të plotë, por nëse në momentin e nisjes ekrani tashmë është i zënë nga një aplikacion tjetër, ai do të ndahet në dysh. Ka të njëjtat probleme të përputhshmërisë si XHaloFloatingWindow, por është shumë më i dobishëm në vetvete. Nuk mbështet veçoritë private të Samsung, si p.sh. drag'n'drop ndërmjet aplikacioneve. Nga rruga, për momentin modaliteti me shumë dritare është hequr nga OmniROM (për shkak të dështimeve të disa aplikacioneve), kështu që mund ta përdorni këtë modul si zëvendësim.

Ky modul kryen një funksion të thjeshtë: ndalon që aplikacionet individuale të fillojnë automatikisht në fazën e nisjes së OS. Fakti është se si parazgjedhje Android nuk ju lejon të rregulloni fillimin e aplikacioneve, siç mund të bëhet në çdo OS desktop. Një aplikacion që ka lejen android.permission.RECEIVE_BOOT_COMPLETED do të niset automatikisht nga sistemi pas nisjes dhe asgjë nuk mund të bëhet për këtë.

Nëse kjo nuk ju duket si problem, atëherë unë rekomandoj të ekzekutoni çdo menaxher procesi (si një opsion vrasës detyrash) në një sistem të sapo ngarkuar. Aty do të shihni një telefon, një aplikacion për shkëmbim dhe SMS dhe një mori aplikacionesh të palëve të treta. BootManager ju lejon të zgjidhni këtë problem duke zgjedhur vetëm softuerin që është vërtet i nevojshëm menjëherë pas nisjes së telefonit inteligjent.

Po, e di që tashmë ka aplikacione në treg për të zgjidhur këtë problem, por BootManager ndryshon në mënyrë të favorshme prej tyre në atë që funksionon në nivelin më të ulët të sistemit dhe bllokon ngarkimin e aplikacionit saktë dhe shpejt.

Një nga modulet e mia të preferuara. Zëvendëson pllakën me rrëshqitësin e volumit, i cili
Parajsa shfaqet kur shtypni butonat e volumit dhe mbuloni informacionin në ekran me një rrëshqitës të hollë që shfaqet në krye të shiritit të statusit dhe zhduket shpejt. Për më tepër, ai përfshin një sërë opsionesh për ndryshimin e sjelljes së modulit, ndër të cilat mund të gjeni dy nga më të rëndësishmet: çaktivizimin e rregullimit automatik të volumit të njoftimit së bashku me ndryshimin e volumit të ziles dhe çaktivizimin e tingullit të bezdisshëm "bip" kur shtypni butonat e volumit.

E keqja e modulit është se ai paguhet. Si parazgjedhje, është instaluar një version provë dyjavor dhe për të blerë versionin e plotë do të duhet të paguani një dollar. Nga rruga, për të hyrë në rrëshqitësit e tjerë të volumit (vëllimi i medias dhe alarmit), duhet të tërhiqni poshtë shiritit të statusit ndërsa ky i fundit tregon rrëshqitësin kryesor.

Tre module për ndryshimin e sjelljes dhe pamjes së mesazheve që shfaqen në ekran gjatë ngjarjeve të caktuara (mesazh dolli).

Burnt Toast shton një ikonë të aplikacionit që e thirri atë në mesazh (me mundësinë e personalizimit). Jelly Toast zëvendëson stilin e meta të mesazheve të KitKat (me qoshe të rrumbullakosura dhe kufij të gjerë) me dizajnin e thjeshtë dhe të pastër të Jelly Bean.

EnhancedToast kombinon funksionet e dy moduleve të mëparshme dhe ju lejon të bllokoni mesazhet nga aplikacionet e zgjedhura (shumica prej tyre janë vërtet të padobishme), duke përfshirë aftësinë për të filtruar sipas regexp (vetëm ato mesazhe që përputhen me modelin do të shfaqen). Si një bonus shtesë, ofrohet mbështetje për Tasker, me të cilën mund të konfiguroni kontrollin automatik të funksioneve të modulit.

Moduli i dytë në listën time personale të më të dobishmeve (pas StatusbarVolume). Bën një gjë të thjeshtë - zgjeron automatikisht lidhjet e shkurtuara përpara se t'i hapë ato në aplikacion. Pse është e nevojshme kjo kur çdo shfletues do t'i vendosë ato vetë? Pastaj, lidhja që çon, për shembull, në youtube.com, play.google.com ose facebook.com, në situatën standarde nuk hapet në shfletuesin, por në aplikacionin përkatës, i cili është i saktë dhe shumë i përshtatshëm.

Sidoqoftë, nëse lidhja shkurtohet, sistemi nuk do të jetë në gjendje të kuptojë se kujt t'ia japë atë dhe do ta dërgojë atë në shfletuesin e paracaktuar, i cili do të shfaqet në ekran, do të zgjerojë lidhjen dhe vetëm atëherë ia jep klientit ( dhe kjo është në skenari më i mirë, në rastin më të keq, do të hapet brenda vetes).

CrappaLinks e zgjidh këtë problem duke përgjuar qëllimet që përmbajnë një lidhje me një burim HTTP dhe duke e zgjeruar automatikisht atë kur është e nevojshme. Kombinimi për këtë është një ngadalësim gjatë hapjes së lidhjeve, por është akoma më i shpejtë se nisja e një shfletuesi. Në përgjithësi, një modul i domosdoshëm për të gjithë ata që përdorin shpesh Twitter ose rrjete të tjera sociale.

Një bllokues mjaft standard i thirrjeve, ndryshimi nga implementimet e tjera është se funksionon në nivelin më të ulët të OS, ku informacioni transferohet nga rild daemon në dialer. Si rezultat, thirrësi i integruar nuk do të dijë as për thirrjen. Aplikacione të tjera të ngjashme funksionojnë në nivelin e përdoruesit dhe, në thelb, thjesht e mbyllin telefonin menjëherë pas një telefonate, pasi fikni zërin; Për shkak të kësaj, mund të përjetoni shumë defekte, të tilla si ndezja e ekranit për një kohë të shkurtër, tingulli i ziles për një kohë të shkurtër dhe ikona e thirrjeve të humbura që shfaqen. Disa funksione ofrohen vetëm pas blerjes së një çelësi: bllokimi i thirrjeve dalëse, bllokimi i telefonatave nga numrat privatë dhe të fshehur.

Një mur i thjeshtë zjarri që ju lejon të çaktivizoni transferimin e të dhënave për aplikacione individuale në varësi të llojit të rrjetit. Në fakt, është një analog i DroidWall me një zbatim më korrekt: nuk varet nga iptables, i cili nuk është i pranishëm në shumë firmware të aksioneve, ai aktivizohet edhe para se të fillojnë ngarkimi i përbërësve kryesorë të OS, për shkak të të cilit rrjedhjet përjashtohen ( DroidWall fillon pasi OS është ngarkuar plotësisht), rregullat janë gjithmonë aktive, në vend që të ricaktohen kur lidhja e rrjetit ndryshon.

Fatkeqësisht, nuk është e mundur të flitet në detaje për të gjitha modulet interesante në një artikull, kështu që unë do të rendis pjesën tjetër të atyre interesante me një përshkrim të shkurtër të secilit modul.

Sense 5/6 Toolbox - një grup modifikimesh dhe hakimesh për firmuerin e aksioneve nga HTC.
HTC One Tweaker - modifikime dhe hakime për HTC One.
MotoGuide - një koleksion modifikimesh dhe hakimesh për Moto X.
Skeda e re e Chrome - Bën që Chrome të hapë gjithmonë lidhje të reja në një skedë të re.
Phab7 - ju lejon të kaloni midis modaliteteve të telefonit dhe tabletit.
Ok Google për lëshuesit e palëve të treta - shton njohje automatike zërat në lëshuesit e palëve të treta.
Rregullimi i shumëfishtë i çelësit Master - mbyll defektin e famshëm të çelësit Master.
NetworkSpeedIndicator - shton një tregues të shpejtësisë së transferimit të të dhënave në shiritin e statusit.
CpuTemp në shiritin e statusit - tregon temperaturën e procesorit në shiritin e statusit.
Holo Themer - ju lejon të kaloni midis temave të aplikacioneve të lehta dhe të errëta gjatë fluturimit.
YouTube AdAway - bllokon reklamat në aplikacionin YouTube.
Lejo Youtube me ekran të plotë me HDMI - aktivizon modalitetin e vërtetë të ekranit të plotë kur shfaq imazhe nga luajtësi i YouTube përmes HDMI.
AppOpsXposed - siguron akses në funksionin AppOps (shih më lart).
Complete Action Plus - ju lejon të personalizoni dialogët e përzgjedhjes së skedarëve dhe aplikacioneve.
DitheredHoloBackground - e bën sfondin e aplikacioneve të vërtetë të zezë, pa gradient (i dobishëm për ekranet AMOLED).
DoubleTapToSleep - e dërgon telefonin inteligjent në gjumë pas prekjes dy herë në shiritin e statusit.
Komponenti i zgjeruar i përkthimit Xposed - përkthen automatikisht firmware MIUI në Rusisht.
Fshih aplikacionet Xposed - ju lejon të fshehni aplikacionet në menynë standarde të lëshuesit.
Shkarkuesi i Instagram - ju lejon të shkarkoni foto nga Instagram.
Vine Downloader - ju lejon të shkarkoni video nga Vine.
Mbështetje LG PIE - mbështetje për funksionin PIE për firmware nga LG.
Përdorues të shumëfishtë për telefonin - aktivizon modalitetin e shumë përdoruesve në smartphone tuaj.
neXus navbarz - ju lejon të ndryshoni pamjen dhe sjelljen e butonave të navigimit të softuerit.
ScreenOffAnimation - një grup animacionesh jashtë ekranit.
UnbelovedHosts - ju lejon të përdorni tuajin versionet e veta/etc/hosts skedari pa ndryshuar atë kryesor (për të bllokuar reklamat).
Fotografia e thirrjes me ekran të plotë Xposed - shfaq foton e telefonuesit në ekran të plotë (pa prerë në fund).
Cilësimet e Xposed GEL - personalizues për lëshuesin e Google Tani.

Duke u endur nëpër forume dhe lloje te ndryshme Në faqet e dedikuara për Android, vazhdimisht hasim këshilla se si të rrisim performancën e një smartphone. Disa rekomandojnë aktivizimin e shkëmbimit, të tjerë rekomandojnë shtimin e vlerave të veçanta në build.prop dhe të tjerë rekomandojnë ndryshimin e variablave të kernelit Linux. Ju mund të gjeni një numër të madh recetash të këtij lloji në versione të ndryshme, si në XDA ashtu edhe në w3bsit3-dns.com. Por a funksionojnë vërtet?

Duke përdorur një sërë sistemesh *nix gjatë dhjetë viteve të fundit, gjithmonë kam qenë i habitur se sa me këmbëngulje disa përdorues të smartfonëve në dukje të shkolluar përpiqen t'i nxisin idetë e tyre se si të konfigurojnë në mënyrë optimale Android dhe kernelin themelor Linux për publikun. Dhe do të ishte mirë nëse çështja do të kufizohej në akordimin e lehtë të nënsistemit të menaxhimit të kujtesës virtuale ose përfshirjen e opsioneve eksperimentale. Jo, zakonisht na kërkohet të përdorim skripta të gjata që ndryshojnë fjalë për fjalë çdo variabël të kernelit, rimontojnë sistemet e skedarëve me opsione të ndryshme të çuditshme, aktivizojnë shkëmbimin, aktivizojnë demonë të ndryshëm të sistemit dhe kryejnë miliarda operacione të tjera të ndryshme.

Jo, mirë, sigurisht që mund të supozoni se kerneli Linux, Android dhe firmware i pronarit për telefonat inteligjentë janë zhvilluar nga idiotë analfabetë, puna e të cilëve duhet të ribëhet rrënjësisht, por në praktikë për disa arsye rezulton se akordimi më i famshëm mjetet e publikuara në XDA nuk janë gjë tjetër veçse një grumbull i një numri të madh rekomandimesh të ndryshme, të shpikura nga dikush i panjohur dhe i panjohur pse. Absurditeti i situatës është se në këto mjete mund të gjeni linja të kopjuara të pandryshuara nga skriptet për të rritur performancën e një serveri Linux në kushte të ngarkesës së lartë (nuk po bëj shaka, shikoni përmbajtjen e skriptit të famshëm ThunderBolt!).

Në përgjithësi, situata është më shumë se konfuze. Të gjithë këshillojnë gjithçka, askush nuk këshillon asgjë, dhe ata që kuptojnë diçka ulen dhe duke pirë çaj, qeshin me farsën që po ndodh. Por le të përpiqemi të pastrojmë gjithë këtë rrëmujë.

Le të fillojmë me shkëmbimin - ideja më absurde që mund të mendoni për përdorim në telefonat inteligjentë. Qëllimi i tij është të krijojë dhe lidhë një skedar paging, i cili do të çlirojë hapësirë ​​të dobishme në RAM. Vetë ideja është, natyrisht, e shëndoshë, por vetëm nëse po flasim për një server që nuk ka asnjë problem me interaktivitetin. Në një telefon inteligjent, një skedar shkëmbimi i përdorur rregullisht do të çojë në vonesa jo iluzore që rezultojnë nga mungesa e cache - vetëm imagjinoni se çfarë do të ndodhë nëse një aplikacion përpiqet të shfaqë një nga ikonat e tij dhe ai përfundon në një shkëmbim që do të duhet të ngarkohet përsëri nga disku, pasi fillimisht liroi hapësirë ​​duke vendosur të dhënat e një aplikacioni tjetër në një shkëmbim. Tmerr.

Disa përdorues mund të argumentojnë se në fakt, pas aktivizimit të shkëmbimit, nuk lindin probleme, por për këtë duhet të falënderojmë mekanizmin lowmemorykiller, i cili rregullisht vret aplikacionet veçanërisht të fryra dhe të papërdorura prej kohësh. Falë tij, një pajisje me 1 GB memorie mund të mos ketë kurrë nevojë të hedhë të dhënat në shkëmbim. Kjo është edhe arsyeja pse, ndryshe nga një desktop Linux, shkëmbimi nuk është i nevojshëm në Android.

Verdikti: një ide shumë budalla, zbatimi i së cilës është i mbushur me vonesa serioze.

Shkëmbimi është me të vërtetë shumë i ngadalshëm, dhe madje edhe në një desktop ekzistenca e tij është shpesh e pajustifikuar, por çka nëse mashtroni sistemin? Le të krijojmë një disk virtual direkt në RAM me një funksion të integruar të kompresimit të të dhënave, ta lidhim atë si swap - dhe voila. Funksioni i kompresimit të të dhënave është mjaft i lirë edhe për procesorët modernë celularë, kështu që ne mund të zgjerojmë madhësinë e RAM-it pa humbje praktikisht të performancës.

Ideja është aq e mirë sa edhe Google rekomandon përdorimin e zRAM për pajisjet e bazuara në KitKat nëse kapaciteti RAM nuk i kalon 512 MB. E vetmja kapje është se metoda funksionon vetëm për pajisjet moderne moderne, domethënë pajisje të bazuara në procesorë buxhetor me shumë bërthama nga disa MTK dhe 512 MB RAM. Në këtë rast, rryma e kriptimit mund të zhvendoset në një bërthamë të veçantë dhe të mos shqetësohet fare për performancën.

Në pajisjet e vjetruara me një bërthamë të vetme, për të cilat "gurutë e forumit" rekomandojnë përdorimin e kësaj teknologjie, do të kemi përsëri vonesa, dhe në sasi mjaft të mëdha. E njëjta gjë, meqë ra fjala, vlen edhe për teknologjinë KSM (Kernel SamePage Merging), e cila ju lejon të bashkoni faqe identike memorie, duke liruar kështu hapësirën. Rekomandohet gjithashtu nga Google, por në pajisjet e vjetra çon në vonesa edhe më të mëdha, gjë që është mjaft logjike, duke pasur parasysh fillin bërthamor vazhdimisht aktiv, i cili vazhdimisht ecën nëpër kujtesë në kërkim të faqeve të kopjuara (a ka vërtet kaq shumë nga këto dublikatë? ).

Verdikti: Varet nga pajisja, ngadalëson sistemin në shumicën e rasteve.

Në një kohë, ky aplikacion shkaktoi shumë zhurmë dhe solli shumë analoge. Një numër i madh mesazhesh janë shfaqur në internet në lidhje me rritjen e supozuar fenomenale të performancës së smartphone pas instalimit të tij. Ndërtuesit e firmuerit me porosi të rritur në shtëpi filluan ta përfshinin atë në ndërtimet e tyre dhe autori u shpall shpëtimtar. Dhe e gjithë kjo përkundër faktit se Seeder nuk kreu asnjë hakim të ndyrë, por thjesht rregulloi një gabim budalla Android.

Shkurtimisht, defekti ishte se disa komponentë të nivelit të lartë të kohës së ekzekutimit të Android përdorën në mënyrë aktive skedarin /dev/random për të marrë entropinë/kripë. Në një moment, buferi /dev/random ishte bosh dhe sistemi u bllokua derisa të mbushej me sasinë e kërkuar të të dhënave. Dhe duke qenë se ishte e mbushur me atë që vinte nga sensorë, butona dhe sensorë të ndryshëm të smartfonit, kjo procedurë mori aq shumë kohë sa përdoruesi kishte kohë të vinte re vonesën.

Për të zgjidhur këtë problem, autori i Seeder mori daemon Linux rngd, e përpiloi për Android dhe e konfiguroi që të merrte të dhëna të rastësishme nga /dev/urandom shumë më të shpejtë (por edhe shumë më të parashikueshme) dhe t'i hidhte në /dev/random çdo herë. e dyta, pa lejuar që kjo e fundit të shterohet. Si rezultat, sistemit nuk i mungoi asnjëherë entropia dhe funksionoi në heshtje.

Ky gabim u mbyll nga Google përsëri në Android 3.0 dhe duket se nuk kemi nevojë të kujtojmë për Seeder. Por fakti është se aplikacioni është zhvilluar në mënyrë aktive që atëherë dhe madje edhe sot rekomandohet për përdorim nga shumë "ekspertë". Për më tepër, aplikacioni ka disa analoge (për shembull, sEFix), dhe shumë krijues të skripteve/veglave të përshpejtimit ende përfshijnë funksione të ngjashme në krijimet e tyre. Ndonjëherë është i njëjti rngd, ndonjëherë është daemon i kapur, ndonjëherë është thjesht një lidhje simbolike e /dev/urandom në /dev/random.

Të gjithë ata që e provuan duke konkurruar me njëri-tjetrin për efektivitetin e zgjidhjes, megjithatë, sipas Ricardo Cerqueira nga Cyanogen, versionet moderne Android /dev/random përdoret vetëm nga tre komponentë: libcrypto (për enkriptimin e lidhjeve SSL, gjenerimin e çelësave SSH, etj.), wpa_supplicant/hostapd (për gjenerimin e çelësave WEP/WPA) dhe disa biblioteka për gjenerimin e ID-ve të rastësishme gjatë krijimit të sistemeve të skedarëve ext2 /3/4.

Efektiviteti i aplikacionit në Android-in modern, sipas tij, nuk lidhet aspak me rimbushjen e grupit /dev/random, por me faktin se rngd vazhdimisht zgjon pajisjen dhe e detyron atë të rrisë frekuencën e procesorit, e cila ka një efekt pozitiv në performancë dhe një ndikim negativ në bateri.

Verdikti: placebo.

Firmware-i i aksioneve për telefonat inteligjentë është gjithmonë i klasifikuar. Kjo do të thotë që, së bashku me paketat standarde të aplikacioneve Android në formatin APK, drejtoritë /system/app/ dhe /system/priv-app/ (duke filluar me KitKat) përmbajnë gjithashtu skedarë me të njëjtin emër me shtesën odex. Ato përmbajnë të ashtuquajturin bytecode të aplikacionit të optimizuar, i cili tashmë ka kaluar nëpër verifikuesin dhe optimizuesin e makinës virtuale dhe është shkruar në një skedar të veçantë (kjo bëhet duke përdorur mjetin dexopt).

Pika e ekzistencës së skedarëve odex është të lehtësojë ngarkesën në makinën virtuale dhe në këtë mënyrë të përshpejtojë lëshimin e aplikacioneve (stokut). Nga ana tjetër, skedarët odex ndërhyjnë në modifikimet e firmuerit dhe krijojnë probleme me përditësimin, dhe për këtë arsye shumë ROM me porosi (përfshirë CyanogenMod) shpërndahen pa to. Ju mund të ktheni (më saktë, të gjeneroni) skedarë odex në mënyra të ndryshme, duke përfshirë përdorimin e shërbimeve/skripteve të thjeshta si Odexer Tool. Ato janë të lehta për t'u përdorur dhe shumë "ekspertë" rekomandojnë ta bëjnë këtë.

Problemi i vetëm është se ky është një placebo i pastër. Nëse nuk gjen skedarë odex në drejtorinë /system, vetë sistemi do t'i krijojë ato në nisjen tjetër dhe do t'i vendosë në drejtorinë /system/dalvik-cache/. Kjo është pikërisht ajo që ajo bën kur, kur ngarkon firmware-in e ri, mesazhi "Optimizimi i aplikacionit në progres..." shfaqet në ekran. Meqë ra fjala, kjo funksionon edhe për aplikacionet nga tregu. Por në fazën e instalimit të softuerit.

Verdikti: placebo.

Zbatimi i multitasking në Android është shumë i ndryshëm nga sistemet e tjera operative celulare dhe bazohet në model klasik. Aplikacionet mund të funksionojnë në heshtje në sfond, nuk ka kufizime në numrin e tyre në sistem dhe funksionaliteti nuk zvogëlohet kur kaloni në ekzekutimin e sfondit. Gjithçka është e njëjtë si në desktop, me përjashtim të një detaji: sistemi ka të drejtë të vrasë çdo aplikacion në sfond nëse nuk ka RAM të mjaftueshëm ose (duke filluar me KitKat) aplikacioni është tepër i pangopur për burime.

Ky mekanizëm, i quajtur lowmemorykiller, u shpik në mënyrë që, duke ruajtur veçoritë e një OS të plotë me shumë detyra, Android të mund të jetonte normalisht në kushte memorie të kufizuar dhe një ndarje shkëmbimi që mungon. Përdoruesi mund të nisë me siguri çdo aplikacion dhe të kalojë shpejt midis tyre, dhe vetë sistemi do të kujdeset për përfundimin e aplikacioneve që nuk janë përdorur për një kohë të gjatë dhe për të siguruar që pajisja të ketë gjithmonë memorie të lirë.

Në vitet e para të Android, qëllimi i këtij mekanizmi ishte i paqartë për shumë përdorues, kështu që të ashtuquajturat vrasës detyrash u bënë të njohura - aplikacione që zgjoheshin herë pas here dhe mbyllnin të gjitha aplikacionet në sfond. Fitimi në në këtë rast kishte një sasi të madhe RAM falas, e cila u perceptua si një plus, megjithëse, natyrisht, nuk kishte asnjë avantazh në këtë. Por kishte shumë disavantazhe në formën e ndërrimit më të gjatë midis aplikacioneve, rritjes së konsumit të baterisë dhe problemeve me zgjimin e pronarit në mëngjes (u vra edhe ora e ziles).

Me kalimin e kohës, erdhi një kuptim i parimeve të multitasking dhe vrasësit e detyrave u braktisën gradualisht. Sidoqoftë, ato u zëvendësuan shpejt nga një prirje tjetër - akordimi i vetë mekanizmit lowmemorykiller (për shembull, duke përdorur aplikacionin MinFreeManager). Ideja kryesore e metodës është të rrisë kufijtë e mbushjes së RAM-it, me arritjen e të cilave sistemi do të fillojë të vrasë aplikacionet në sfond. Një lloj metode "si për ne ashtu edhe për ju", e cila ju lejon të lironi pak memorie duke përdorur mjete standarde, pa shkelur idetë e multitasking Android.

Por çfarë çon në fund të fundit kjo? Le të themi vlerat standarde kufijtë e memories janë 4, 8, 12, 24, 32 dhe 40 MB, domethënë, kur memoria e lirë të arrijë 40 MB, një nga aplikacionet e ruajtura në memorie do të shkatërrohet (i ngarkuar në memorie, por nuk funksionon, ky është një optimizim i Android) , në 32 - Ofruesi i përmbajtjes, i cili nuk ka klientë, 24 - një nga aplikacionet e sfondit të përdorur rrallë, pastaj proceset e shërbimit të aplikacionit (për shembull, shërbimi i luajtësit të muzikës), i dukshëm në ekranin e aplikacionit dhe ai aktuali konsumohen aplikimi i ekzekutimit. Dallimi midis dy të fundit është se "aktual" është aplikacioni me të cilin po merret aktualisht përdoruesi dhe "i dukshëm" është diçka që, për shembull, ka një njoftim në shiritin e statusit ose shfaq disa informacione në krye të ekranit.

Në përgjithësi, e gjithë kjo do të thotë që telefoni inteligjent do të ketë gjithmonë 40 MB memorie të lirë, e cila është e mjaftueshme për të akomoduar një aplikacion më shumë, pas së cilës filli LKM do të zgjohet dhe do të fillojë pastrimin e kujtesës. Gjithçka është në rregull, të gjithë janë të lumtur. Sistemi përdor memorien në maksimum. Tani le të imagjinojmë se çfarë do të ndodhë nëse përdoruesi merr këshillën e një "eksperti" të rritur në shtëpi dhe i ngre këto vlera ​në mënyrë që këto të fundit të jenë, le të themi, 100 MB (zakonisht vetëm tre rriten vlerat e fundit). Në këtë rast, do të ndodhë një gjë e thjeshtë: përdoruesi do të humbasë 100 – 40 = 60 MB memorie të pajisjes. Në vend që të përdoret kjo hapësirë ​​për të ruajtur aplikacionet e sfondit, gjë që është e dobishme sepse redukton kohën e kalimit në to dhe jetëgjatësinë e baterisë, sistemi do ta lërë atë të lirë pa asnjë arsye të dukshme.

Për të qenë të drejtë, duhet thënë se akordimi LKM mund të jetë i dobishëm për pajisjet me një sasi shumë të vogël memorie (më pak se 512) dhe Android 4.X në bord ose për rritjen e përkohshme të pragjeve. Disa zhvillues të modifikimit rekomandojnë drejtpërdrejt përdorimin e cilësimeve "agresive" vetëm kur ekzekutoni softuer të rëndë si lojërat hi-end, dhe të qëndroni në cilësimet standarde pjesën tjetër të kohës. Kjo në fakt ka kuptim.

Verdikti: më mirë të mos prekni.

Në skriptet e publikuara në forume, shpesh mund të gjeni ndryshime në nënsistemin hyrës/dalës. Për shembull, në të njëjtin skenar ThunderBolt! ka linjat e mëposhtme:

Echo 0 > $i/radhë/rrotullues; echo 1024 > $i/queue/nr_kërkesat;

E para i bën të ditur planifikuesit I/O se ka të bëjë me një disk të gjendjes së ngurtë, e dyta rrit madhësinë maksimale të radhës së hyrjes/daljes nga 128 në 1024 (ndryshorja $i në komanda përmban shtegun për në pemën e pajisjes së bllokut në /sys, për shembull /sys/block/ mmcblk0/, skripti kalon nëpër to në një lak). Më tej në tekst mund të gjeni rreshtat e mëposhtëm në lidhje me planifikuesin CFQ:

Echo 1 > $i/queue/iosched/back_seek_penalty; echo 1 > $i/queue/iosched/low_latency; echo 1 > $i/queue/iosched/slice_idle;

Ajo që vijon janë disa rreshta të tjera që lidhen me planifikuesit e tjerë (nga rruga, kushtojini vëmendje pikëpresjes krejtësisht të panevojshme në fund të komandave). Çfarë nuk shkon me gjithë këto rreshta? Dy komandat e para janë të pakuptimta për dy arsye:

Tre të fundit janë të pakuptimta për arsyen e thjeshtë se për një smartphone, ku në fakt nuk ka ndarje të aplikacioneve në prioritete I/O dhe nuk ka disqe mekanike, programuesi më i mirë është noop, domethënë një radhë e thjeshtë FIFO - kushdo që ka akses në memorie. së pari merr akses. Dhe ky planifikues nuk ka ndonjë cilësim të veçantë. Prandaj, është më mirë të zëvendësoni të gjitha këto lista komandash me shumë ekrane me një lak të thjeshtë:

Për i në /sys/block/mmc*; bëj echo noop > $i/queue/scheduler echo 0 > $i/queue/iostats kryer

Përveç aktivizimit të programuesit noop, ai çaktivizon grumbullimin e statistikave të hyrjes/daljes për të gjithë disqet, gjë që duhet të ketë gjithashtu një efekt pozitiv në performancën (edhe pse kjo është vetëm një rënie në kovë dhe do të jetë krejtësisht e padukshme).

Një tjetër rregullim që shpesh mund të gjendet në skriptet e akordimit të performancës është rritja e vlerës së leximit për kartën e kujtesës në 2 MB. Mekanizmi i leximit është projektuar për të lexuar në mënyrë proaktive të dhëna nga media ruajtëse përpara se një aplikacion të kërkojë qasje në ato të dhëna. Nëse kerneli sheh që dikush po lexon të dhëna nga media për një kohë të gjatë, ai përpiqet të kuptojë se cilat të dhëna do t'i nevojiten aplikacionit në të ardhmen dhe ta ngarkojë atë në RAM paraprakisht, duke zvogëluar kështu kohën që duhet për t'i kthyer ato.

Duket bukur, por siç tregon praktika, algoritmi i leximit shumë shpesh bën gabime, gjë që çon në operacione të panevojshme I/O dhe konsum të RAM-it. Vlerat e larta të leximit (1–8 MB) rekomandohen për përdorim në grupet RAID, ndërsa në një desktop ose smartphone është më mirë të lini gjithçka ashtu siç është, domethënë 128 KB.

Verdikti: ju nuk keni nevojë për asgjë tjetër përveç noop.

Përveç nënsistemit I/O, është gjithashtu e zakonshme akordimi i nënsistemit të menaxhimit të memories virtuale. Shpesh, ndryshohen vetëm dy variabla të kernelit: vm.dirty_background_ratio dhe vm.dirty_ratio, të cilat ju lejojnë të rregulloni madhësinë e buferëve për ruajtjen e të ashtuquajturave të dhëna të pista, domethënë të dhëna që janë shkruar në disk nga aplikacioni, por janë ende në RAM dhe prisni derisa të shkruhen në disk.

Vlerat standarde për këto variabla në shpërndarjet desktop Linux dhe Android janë afërsisht si më poshtë:

* raporti vm.dirty_background = 10 * vm.ratio_dirty = 20

Kjo do të thotë që kur madhësia e tamponit të të dhënave "të pista" arrin 10% të sasisë totale të RAM-it, filli bërthamor pdflush do të zgjohet dhe do të fillojë të shkruajë të dhëna në disk. Nëse operacionet e shkrimit të të dhënave në disk janë shumë intensive dhe, edhe përkundër punës së pdflush, buferi vazhdon të rritet, atëherë kur të arrijë 20% të vëllimit të RAM-it, sistemi do të kalojë të gjitha operacionet e mëvonshme të shkrimit në modalitetin sinkron ( pa buferim paraprak) dhe puna e atyre që shkruajnë në aplikacionet e diskut do të bllokohet derisa të dhënat të shkruhen në disk (në terminologjinë Android kjo quhet vonesë).

Është e rëndësishme të kuptohet se, edhe nëse madhësia e tamponit nuk ka arritur në 10%, sistemi do të nisë disi transmetimin pdflush pas 30 sekondash. Çfarë na jep kjo njohuri? Në fakt, asgjë që ne mund të përdorim për qëllimet tona. Kombinimi 10/20% është mjaft i arsyeshëm dhe, për shembull, në një smartphone me 1 GB memorie është afërsisht 100/200 MB memorie, që është më se e mjaftueshme në kushtet e shpërthimeve të rralla të shkrimit, shpejtësia e të cilave është shpesh më e ulët se shpejtësia e shkrimit në kujtesën NAND të sistemit ose kartën SD (kur instaloni softuer ose kopjoni skedarë nga një kompjuter). Por krijuesit e skripteve të optimizimit, natyrisht, nuk pajtohen me këtë.

Për shembull, në skriptin Xplix mund të gjeni rreshta si kjo (në origjinal ato janë shumë më të gjata për shkak të kontrolleve për sasinë e RAM-it dhe përdorimit të BusyBox):

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

Këto komanda zbatohen për pajisjet me 1 GB memorie, domethënë, ato vendosin kufijtë e buferit të pista në (afërsisht) 500/900 MB. Të tillë vlera të larta absolutisht e pakuptimtë për një smartphone, pasi ato funksionojnë vetëm në kushte të regjistrimit intensiv të vazhdueshëm në disk, domethënë, përsëri, për një server shumë të ngarkuar. Në një situatë me një smartphone, ato nuk do të jenë më të mira se ato standarde. Nga rruga, në skenarin ThunderBolt! Përdoren vlera shumë më të arsyeshme (dhe afër standardit), por dyshoj se përdoruesi do të vërejë ndonjë ndryshim nga përdorimi i tyre:

Nëse [ "$mem" -lt 524288 ];atëherë sysctl -w vm.dirty_background_ratio=15; sysctl -w vm.raporti_i pistë=30; elif [ "$mem" -lt 1049776 ];pastaj sysctl -w vm.dirty_background_ratio=10; sysctl -w vm.raporti_i pistë=20; else sysctl -w vm.raporti_ndyrë_background=5; sysctl -w vm.raporti_i pistë=10; fi;

Dy komandat e para ekzekutohen në telefonat inteligjentë me 512 MB RAM, e dyta - me 1 GB, dhe e treta - me më shumë se 1 GB. Por në fakt, ekziston vetëm një arsye për të ndryshuar vlerat standarde - një pajisje me një memorie të brendshme shumë të ngadaltë dhe/ose kartë memorie (përshëndetje për kinezët). Në këtë rast, është e arsyeshme të ndani vlerat e variablave, domethënë të bëni diçka si kjo:

Sysctl -w vm.dirty_background_ratio=10 sysctl -w vm.dirty_ratio=60

Pastaj, gjatë shpërthimeve të papritura të operacioneve të shkrimit, sistemi, duke mos pasur kohë për të shkruar të dhëna në disk, nuk do të kalojë në modalitetin sinkron deri në minutën e fundit, gjë që do të zvogëlojë vonesat e aplikacionit gjatë shkrimit.

Verdikti: më mirë të mos prekni.

Ka një numër të madh optimizimesh më të vogla, duke përfshirë "akordimin" e grupit të rrjetit, ndryshimin e variablave të kernelit Linux dhe Android (build.prop), por 90% e tyre nuk kanë ndonjë efekt në performancën aktuale të pajisjes dhe pjesa tjetër 10% ose përmirësojnë disa aspekte të pajisjeve të sjelljes në dëm të të tjerëve, ose rrisin produktivitetin aq pak sa as nuk do ta vini re. Nga ajo që funksionon në të vërtetë, mund të vërehen sa vijon:

• Overclocking Një mbingarkesë e vogël mund të përmirësojë performancën dhe tensioni i ulët mund të kursejë pak jetëgjatësi të baterisë.
• Optimizimi i bazës së të dhënave. Unë dyshoj seriozisht se kjo do të japë një rritje të dukshme të shpejtësisë, por teoria na thotë se duhet të funksionojë.
• Zipalign. Është qesharake, por pavarësisht funksionit të përafrimin e përmbajtjes brenda skedarëve APK të integruar në Android SDK, mund të gjeni një sasi të madhe softuerësh në treg që nuk kanë kaluar përmes zipalign.
• Çaktivizimi i shërbimeve të panevojshme të sistemit, fshirja e sistemit të papërdorur dhe aplikacioneve të palëve të treta të përdorura rrallë (kam shkruar tashmë për këtë në një nga artikujt e mëparshëm).
• Kernel i personalizuar me optimizime për një pajisje specifike (përsëri, jo të gjitha kernelët janë njësoj të mirë).
• Programuesi i noop I/O i përshkruar tashmë.
• Algoritmi i ngopjes Westwood+ TCP. Ka prova që është shumë më efektiv në rrjetet pa tel sesa Kubiku i parazgjedhur i Android. E disponueshme në kernele të personalizuara.

LaraCraft304 nga forumet e Zhvilluesve XDA kreu kërkime dhe zbuloi se një numër mbresëlënës i cilësimeve /system/build.prop që "ekspertët" rekomandojnë për përdorim nuk ekzistojnë fare në teksti burimor AOSP dhe CyanogenMod. Këtu është lista e tyre:

• ro.ril.çaktivizoj.fuqi.kolaps
• ro.mot.eri.losalert.vonesa
• ro.config.hw_fast_dormancy
• ro.config.hw_power_saving
• windowsmgr.max_events_per_sec
• këmbëngul.cust.tel.eons
• ro.max.fling_shpejtësia
• ro.min.shpejtësia_fluturuese
• ro.kernel.checkjni
• dalvik.vm.verify-bytecode
• korrigjimi.performanca.akordim
• video.përshpejtoj.hw
• ro.media.dec.jpeg.memcap
• ro.config.nocheckin
• profiler.force_disable_ulog
• profiler.force_disable_err_rpt
• ersist.sys.shutdown.mode
• ro.HOME_APP_ADJ

Skript për optimizimin e bazave të të dhënave të cilësimeve të sistemit dhe aplikacionit. Natyrisht, root dhe BusyBox kërkohen për të punuar.

#!/system/bin/sh
per une ne \
`gjendja e kutisë së zënë /data -iname "*.db"`;
bëj\
/system/xbin/sqlite3 $i 'VACUUM;';
/system/xbin/sqlite3 $i 'REINDEX;';
bërë;