Ranking

Jest możliwość poprawienia wydajności Redmi 1S. Wydajności ogólnej i na baterii. Z racji tego, że nie używam Redmi to moje testy nie byłyby wiarygodne. Dlatego tym tematem chciałem (dla chętnych!) pokazać kilka rzeczy, które można przetestować u siebie i jeśli się sprawdzą to dodam wtedy te poprawki do romu. Poniższe poprawki są tylko dla tych którzy wiedzą jak modyfikować build.prop czy inne pliki. Nie wyjaśniam jak to robić ponieważ to wiedza do nabycia w google czy na forum gdzie opisywałem już te kwestie nie raz. Renderowanie na GPU Renderowanie na GPU: zauważyłem ostatnio, że renderowanie UI na GPU sprawdza mi się na MI3. Telefon dłużej trzyma na baterii bo w renderowaniu wyglądu system nie wchodzi CPU. Płynność nie jest jakaś lepsza czy gorsza ale wydaje mi się, że z baterią jest na +. W MIUI od zawsze jest: debug.composition.type=c2d Czyli renderowanie powłoki jest raczej dynamiczne, trochę CPU a trochę GPU. Poprawka jaką proponuję to gpu czyli w build.prop należy zamienić powyższą linijkę na: debug.composition.type=gpu Dodatkowo można jeszcze dołożyć poniższe linijki do build.prop: com.qc.hardware=true debug.qctwa.statusbar=1 debug.qctwa.preservebuf=1 Z tym, że nie wiem czy te wpisy mają jakieś działanie. To są parametry od Qualcomma ale nigdzie nie mogłem znaleźć dokumentacji. Po nazwach można jedynie przypuszczać, że włącza się tu sprzętowe renderowanie paska statusu i jakiś bufor. Prawdopodobnie w MIUI nie ma tutaj zastosowania ale można sprawdzić tak z ciekawości. Tweak dalvika Po wyczyszczeniu cache dalvika system ponownie optymalizuje aplikacje i weryfikuje zgodność klas w plikach DEX. I to jak system przeprowadzi te optymalizacje zależy od działania systemu, zajętości pamięci ram czy szybkości ładowania aplikacji. Teoretycznie. W praktyce jest różnie ale to można przetestować. W MIUI nie ma w sumie nigdzie ustawionych parametrów dla dalvik.vm.dexopt-flags także sami to możemy ustawić. Nie wiem czy MIUI nie wprowadza samemu takich parametrów w kernelu. W zasadzie ciężko to sprawdzić. Może kiedyś sprawdzę to w ramdisku w MI3. W każdym razie linijki do dopisania w build.prop: dalvik.vm.dexopt-flags=v=n,o=v,m=y,u=n (można tu zmieniać te parametry: v(weryfikacja): n/y, m(mapowanie): y/n. u(uniprocessor) nie warto zmieniać na y ponieważ n oznacza korzystanie z wielu rdzeni. Po zmianie tego trzeba wyczyścić dalvik cache: adb shell rm -f /data/dalvik-cache/* Lub ręcznie z recovery. Teoretycznie ta poprawka spowoduje zwolnienie większej ilości pamięci ram. Inne: Rzuciło mi się w oko jeszcze jedno w build.prop dla redmi: # set hidden apps ro.sys.fw.bg_apps_limit=10 Nie ma tego normalnie w lepszych Xiaomi. Nie wiem co to dokładnie robi ale ja sobie to tłumaczę jako: background (bg) apps limit czyli limit aplikacji w tle (lub coś podobnego). Może większa lub mniejsza ilość coś tu zmieni w tym czy i kiedy ubijane są aplikacje przez brak pamięci ram? Tylko teoretyzuję. Warto sprawdzić.

Lol. Z poprzedniego zdania wynika jednoznacznie o czym mowa. No przecież nie o Note... Nie wiem. Może kiedyś jak będę miał chwilę. Niechętnie. Czemu? A bo MTK. W starym redmi uruchomiłem init.d więc łatwo tam dać tweaki. W Note znowu trzeba init.d a tego mi się nie chce robić. Przynajmniej na razie. No i nie ma jak przeprowadzić testów. init.d trzeba dać do ramdiska, jak się pomylę, to będzie bootloop na logo. A chwilowo nie ma chyba recovery dla Note by bawić się w odzyskiwanie po bootloopie. W Qualcommach jest super łatwo. Jest init.qcom.post-boot.sh i wio z tweakami. Choć temu Note nic nie pomoże dopóki MIUI nie poprawi wydajności samego MIUI w MTK.

Tak seria 60 jest też głośna Wysłane z mojego MI 3W