Android 성능 향상과 전반적인 최적화 팁을 전담하는 교육 가이드가 많이 있습니다. 그들 중 일부는 합법적이고 다른 일부는 이론에 근거하거나 Android 시스템의 구식 운영 방법이거나 그냥 단순한 말도 안됩니다. 여기에는 스왑 권장 사항, build.prop에 추가된 값, Linux 커널의 변수 변경 사항이 포함됩니다.
성능, 배터리 수명 및 기타 사항을 크게 향상시키는 올인원 플래시 가능 .zip인 "최적화 스크립트"도 많이 있습니다. 일부 일부 조정은 실제로 작동할 수 있지만 대다수는 단순히 플라시보 효과이거나 더 나쁜 것은 실제로 기기에 부정적인 영향을 미칩니다.
사람들이 의도적으로 악의적인 스크립트를 공개한다는 의미는 아닙니다. 확실히 가짜 유료 가 있습니다. Play 스토어에 앱이 있지만 Android 포럼에 출시된 최적화 스크립트는 일반적으로 좋은 의도를 가지고 있기 때문에 개발자가 잘못된 정보를 얻거나 단순히 다양한 최적화 조정을 실험할 수 있습니다. 불행히도, 특히 "올인원" 최적화 스크립트에서 일종의 눈덩이 효과가 발생하는 경향이 있습니다. 약간의 조정이 실제로 무언가를 수행할 수 있습니다. , 스크립트의 다른 조정 세트는 전혀 아무 것도 하지 않을 수 있지만 이러한 스크립트는 작동하는 것과 작동하지 않는 것에 대한 실제 조사 없이 마법의 총알처럼 전달됩니다.
따라서 많은 올인원 최적화 스크립트가 동일한 방법을 사용하고 있으며 그 중 일부는 완전히 구식이거나 장기적으로 유해합니다. 요약하면, 대부분의 "올인원" 최적화 스크립트는 함께 권장되는 조정에 불과하며 이러한 최적화가 "작동하는 방법 또는 이유 - 사용자가 스크립트를 플래시하고 성능이 갑자기 더 빨라졌다고 주장합니다. (실제로 기기를 재부팅하는 아주 간단한 작업이 성능을 향상시켰을 가능성이 큽니다. , 기기의 RAM에 있는 모든 항목이 지워짐) .
이 Appuals 독점 기사에서는 "최적화" 에 대한 가장 일반적인 권장 사항을 강조합니다. Android 성능, 그리고 단순히 신화에 불과한지 아니면 기기 성능에 대한 합법적인 조정인지 여부.
교체
신화 목록의 맨 위에는 Android 스왑이 있습니다. 이는 Android 최적화로 생각하는 측면에서 상당히 터무니없는 것입니다. 스왑의 주요 목적은 페이징 파일을 만들고 연결하여 메모리의 저장 공간을 확보하는 것입니다. 이것은 문서상 합리적으로 들립니다. , 그러나 서버에 실제로 적용 가능 , 상호 작용이 거의 없습니다.
Android 휴대전화의 스왑을 정기적으로 사용하면 캐시를 통과하는 항목으로 인해 심각한 지연이 발생합니다. 예를 들어 응용 프로그램이 스왑에 저장된 그래픽을 표시하려고 하면 다른 응용 프로그램과 데이터 스왑을 배치하여 공간을 확보한 후 디스크를 다시 로드해야 합니다. 정말 지저분합니다.
일부 최적화 애호가는 스왑이 문제가 없다고 말할 수 있지만 스왑이 성능을 향상시키는 것은 아닙니다. 내장된 Android 메커니즘 lowmemorykiller입니다. , 사용되지 않는 부풀려진 우선 순위가 높은 프로세스를 정기적으로 종료합니다. LMK는 메모리 부족 조건을 처리하기 위해 특별히 설계되었으며 kswapd 에서 호출됩니다. 프로세스를 수행하고 일반적으로 사용자 공간 프로세스를 종료합니다. 이것은 OOMkiller(메모리 부족 킬러) 와 다릅니다. 하지만 그건 전혀 다른 주제입니다.
요점은 예를 들어 1GB RAM이 있는 장치는 스왑에서 필요한 성능 데이터에 도달할 수 없으므로 Android에서는 스왑이 절대 필요하지 않습니다. 구현이 지연될 뿐 아니라 성능 저하 가 발생합니다. 성능을 최적화하기보다.
zRAM – 구식이며 더 이상 효율적이지 않음
zRAM은 오래된 기기의 기기 최적화를 위한 입증되고 효과적인 방법입니다. – 약 512MB의 RAM에서만 작동하는 KitKat 기반 장치를 생각해 보십시오. 일부 사람들이 최적화 스크립트에 여전히 zRAM 조정을 포함하거나 일종의 최신 최적화 조정으로 zRAM을 권장한다는 사실은 사람들이 일반적으로 최신 운영 프로토콜을 따르지 않는 예입니다.
zRAM은 MTK 칩셋 및 512MB RAM을 사용하는 장치와 같은 보급형 저예산 멀티 코어 SoC용으로 설계되었습니다. 기본적으로 매우 저렴한 중국 전화. zRAM이 기본적으로 하는 일은 암호화 스트림을 통해 커널을 분리하는 것입니다.
단일 코어가 있는 구형 기기에서 zRAM을 사용하는 경우 , 이러한 장치에 zRAM을 권장하더라도 많은 양의 지연이 발생하는 경향이 있습니다. 이는 KSM 기술(커널 동일 페이지 병합) 에서도 발생합니다. 여유 공간을 확보하기 위해 동일한 메모리 페이지를 결합합니다. 이것은 실제로 Google에서 권장하지만 지속적으로 활성인 코어 광고가 중복 페이지를 검색하기 위해 메모리에서 계속 실행되기 때문에 구형 장치에서는 더 큰 지연이 발생합니다. 기본적으로 최적화 조정을 실행하려고 하면 아이러니하게도 기기 속도가 더 느려집니다.
Seeder – Android 3.0 이후 구식
Android 개발자들 사이에서 가장 논쟁의 여지가 있는 최적화 팁 중 하나는 seeder입니다. , 그리고 우리는 누군가 이 주제에 대해 우리가 틀렸다는 것을 증명하려고 시도할 것이라고 확신합니다. 그러나 먼저 파종기의 역사를 조사해야 합니다.
예, 많은 구형 Android 기기에 설치한 후 더 나은 Android 성능을 선언하는 보고서가 많이 있습니다. . 그러나 사람들은 이유가 무엇이든 이것이 최신 Android 기기에도 적용 가능한 최적화라고 생각합니다. , 그것은 절대적으로 터무니없는 것입니다. Seeder가 여전히 "현대적" 으로 유지 및 제공된다는 사실 지연 감소 도구는 잘못된 정보의 예입니다. 이것은 Seeder 개발자의 잘못이 아니지만 Play 스토어 페이지에서도 Seeder가 Android 4.0+ 이후에 덜 효과적이라고 언급합니다. 그러나 이유가 무엇이든 Seeder는 여전히 최신 Android 시스템에 대한 최적화 토론에 등장합니다.
Seeder가 Android 3.0에서 기본적으로 하는 일은 Android 런타임이 /dev/random/ 파일을 적극적으로 사용하여 엔트로피를 획득하는 버그를 해결하는 것입니다. /dev/random/ 버퍼가 불안정해지고 시스템이 필요한 양의 데이터를 채울 때까지 차단됩니다. Android 기기의 다양한 센서 및 버튼과 같은 작은 것들을 생각해 보십시오.
Seeder의 작성자는 Linux 악마 rngd를 사용했습니다. , 그리고 Android의 inastroil을 위해 컴파일되어 훨씬 빠르고 예측 가능한 /dev/urandom 경로에서 임의의 데이터를 가져와 /dev/random/이 고갈되지 않도록 매초 dev/random/에 병합합니다. 그 결과 엔트로피 부족을 경험하지 않고 훨씬 더 원활하게 작동하는 Android 시스템이 탄생했습니다.
Google은 Android 3.0 이후 이 버그를 없앴지만 어떤 이유에서인지 Seeder는 여전히 "추천 조정" 에 나타납니다. Android 성능 최적화를 위한 목록입니다. 또한 Seeder 앱에는 동일한 rngd를 사용하는지 여부에 관계없이 Seeder의 기능을 포함하는 sEFix와 같은 몇 가지 유사점이 있습니다. 또는 대안 haveged 또는 /dev/urandom과 /dev/random 사이의 심볼릭 링크일 수도 있습니다. 이것은 최신 Android 시스템에서 절대적으로 무의미합니다.
무의미한 이유는 최신 Android 버전이 libcrypto의 세 가지 주요 구성 요소에서 /dev/random/을 사용하기 때문입니다. , SSL 연결 암호화, SSH 키 생성 등. WEP/WPA 키를 생성하는 WPA_supplication/hostapd, 마지막으로 EXT2/EXT3/EXT4 파일 시스템 생성 시 ID 생성을 위한 소수의 라이브러리
따라서 파종자가 또는 Seeder 기반 개선 사항이 최신 Android 최적화 스크립트에 포함되어 있으며 결국 성능 저하 가 발생합니다. rngd 때문에 기기 성능이 저하됨 지속적으로 장치를 깨우고 CPU 주파수를 증가시켜 배터리 소모에 부정적인 영향을 미칩니다.
오덱스
Android 기기의 기본 펌웨어는 거의 항상 odex입니다. 이는 /system/app/ 및 /system/priv-app/에 있는 APK 형식의 Android 앱용 표준 패키지와 함께 .odex 확장자를 가진 동일한 파일 이름을 가짐을 의미합니다. odex 파일에는 유효성 검사기 및 최적화기 가상 머신을 이미 통과한 후 dexopt와 같은 것을 활용하여 별도의 파일에 기록된 최적화된 바이트코드 응용 프로그램이 포함되어 있습니다. 도구.
따라서 odex 파일은 가상 머신을 오프로드하고 odexed 응용 프로그램의 빠른 실행을 제공하기 위한 것입니다. 단점으로 ODEX 파일은 펌웨어 수정을 방지하고 업데이트 문제를 생성하므로 LineageOS와 같은 많은 사용자 지정 ROM이 배포됩니다. ODEX 없이 .
ODEX 파일 생성은 Odexer 도구를 사용하는 것과 같은 여러 가지 방법으로 수행됩니다. 문제는 순전히 플라시보 효과라는 것입니다. 최신 Android 시스템이 /system 디렉토리에서 odex 파일을 찾지 못하면 시스템은 실제로 파일을 생성하여 /system/dalvik-cache/ 디렉토리에 배치합니다. 예를 들어 새 Android 버전을 플래시하면 잠시 동안 "Busy, Optimizing Applications"라는 메시지가 표시됩니다.
Lowmemorykiller 조정
Android의 멀티태스킹은 애플리케이션이 백그라운드에서 조용히 작동하고 백그라운드 앱의 수에 제한이 없다는 점에서 다른 모바일 운영 체제와 다릅니다(개발자 옵션에서 설정하지 않는 한, 그러나 이것은 일반적으로 권장되지 않습니다.) – 또한 시스템이 메모리가 부족한 상황에서 백그라운드 앱을 종료할 수 있는 권한을 보유하지만 백그라운드 실행으로 전환하는 기능은 중지되지 않습니다(이 가이드 앞부분에서 lowmemorykiller 및 메모리 부족 킬러에 대해 언급한 곳 참조 ) .
lowmemorykiller 로 돌아가려면 메커니즘을 통해 Android는 제한된 양의 메모리와 스왑 파티션 부족으로 계속 작동할 수 있습니다. 사용자는 계속해서 애플리케이션을 실행하고 애플리케이션 간에 전환할 수 있으며, 시스템은 사용하지 않는 백그라운드 앱을 자동으로 종료하여 활성 작업을 위한 메모리를 확보합니다.
이것은 초기에 Android에서 매우 유용했지만, 어떤 이유에서인지 일반적으로 유익한 것보다 해로운 작업 킬러 앱의 형태로 인기를 얻었습니다. 작업 킬러 앱은 설정된 간격으로 깨어나거나 사용자가 실행하고 많은 양의 RAM을 확보하는 것처럼 보입니다. 이는 긍정적인 것으로 보입니다. 여유 RAM이 많을수록 장치가 더 빨라집니다. 그렇죠? 그러나 Android의 경우는 그렇지 않습니다.
사실, 많은 양의 여유 RAM이 있으면 실제로 장치의 성능과 배터리 수명에 해로울 수 있습니다. 앱이 Android의 RAM에 저장되면 불러오고 실행하는 등이 훨씬 쉽습니다. Android 시스템은 이미 메모리에 있기 때문에 앱으로 전환하는 데 많은 리소스를 할애할 필요가 없습니다.
이 때문에 Android 초보자는 여전히 어떤 이유로(정보 부족, 슬프게도)에 의존하는 경향이 있지만 태스크 킬러는 예전만큼 인기가 없습니다. . 불행히도 새로운 경향이 작업 킬러를 대체했습니다. lowmemorykiller 메커니즘 튜닝. 예를 들어 MinFreeManager 앱이며 주요 아이디어는 시스템이 백그라운드 앱을 종료하기 시작하기 전에 RAM 오버헤드를 늘리는 것입니다.
예를 들어, 표준 RAM은 경계(4, 8, 12, 24, 32, 40Mb)에서 작동하며 40MB의 여유 저장 공간이 채워지면 메모리에 로드되는 캐시된 앱 중 하나가 하지만 실행되지 않음 종료됩니다.
따라서 기본적으로 Android에는 항상 최소 40MB의 사용 가능한 메모리가 있으며 이는 lowmemorykiller 전에 애플리케이션을 하나 더 수용하기에 충분합니다. 정리 프로세스를 시작합니다. 즉, Android는 사용자 경험을 방해하지 않고 사용 가능한 RAM의 최대량을 사용하기 위해 항상 최선을 다합니다.
슬프게도 일부 홈브류 애호가가 권장하기 시작한 것은 LMK가 시작되기 전에 값을 예를 들어 100MB로 올리는 것입니다. 이제 사용자는 실제로 잃게 됩니다 RAM(100 – 40 =60), 따라서 이 공간을 백엔드 앱을 저장하는 데 사용하는 대신 시스템이 이 메모리 양을 여유로 유지합니다. , 전혀 목적이 없습니다.
LKM 조정이 유용할 수 있습니다 RAM이 512개인 훨씬 오래된 장치의 경우 더 이상 누가 소유합니까? 2GB는 최신 "예산 범위"이며, 4GB RAM 장치도 요즘 "중간 범위"로 보고 있으므로 LMK 조정은 정말 구식이며 쓸모가 없습니다.
I/O 조정
Android를 위한 많은 최적화 스크립트에서 I/O 하위 시스템을 처리하는 조정을 종종 찾을 수 있습니다. 예를 들어 ThunderBolt! 다음 줄이 포함된 스크립트:
echo 0 > $i/queue/rotational; echo 1024 > $i/queue/nr_requests;
첫 번째 줄은 SSD를 처리하는 I/O 스케줄러 명령을 제공하고 두 번째 줄은 대기열 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-queue이므로 이러한 유형의 스케줄러는 "tweak" I/O 하위 시스템에 특별하거나 의미 있는 작업을 수행하지 않습니다. 사실, 이러한 모든 다중 화면 목록 명령은 간단한 주기로 대체하는 것이 좋습니다.
for i in /sys/block/mmc*; do echo noop > $i/queue/scheduler echo 0 > $i/queue/iostats done
이렇게 하면 I/O 통계의 누적에서 모든 드라이브에 대한 noop 스케줄러가 활성화되며, 이는 성능에 긍정적인 영향을 미치지만 매우 작고 거의 무시할 수 있는 것입니다.
성능 스크립트에서 자주 발견되는 또 다른 쓸모없는 I/O 조정은 SD 카드에 대해 최대 2MB까지 증가된 미리 읽기 값입니다. 미리 읽기 메커니즘은 앱이 해당 데이터에 대한 액세스를 요청하기 전에 미디어에서 초기 데이터 읽기를 위한 것입니다. 따라서 기본적으로 커널은 미래에 어떤 데이터가 필요할지 파악하고 RAM에 미리 로드하므로 반환 시간이 줄어듭니다. 이것은 문서상으로는 훌륭하게 들리지만 미리 읽기 알고리즘은 더 자주 잘못됩니다. , 이는 높은 RAM 소비는 말할 것도 없고 완전히 불필요한 입출력 작업으로 이어집니다.
RAID 어레이에서는 1~8MB의 높은 미리 읽기 값이 권장되지만 Android 기기의 경우 기본값인 128KB를 그대로 두는 것이 가장 좋습니다.
가상 메모리 관리 시스템 조정
또 다른 일반적인 "최적화" 기술은 가상 메모리 관리 하위 시스템을 조정하는 것입니다. 이것은 일반적으로 "더티" 데이터를 저장하기 위한 버퍼의 크기를 조정하기 위한 두 개의 커널 변수 vm.dirty_background_ratio 및 vm.dirty_ratio만을 대상으로 합니다. 더러운 데이터는 일반적으로 디스크에 기록된 데이터이지만 아직 메모리에 더 많은 데이터가 있고 디스크에 기록되기를 기다리고 있습니다.
VM 관리 하위 시스템에 대한 Linux 배포판과 Androis의 일반적인 조정 값은 다음과 같습니다.
vm.dirty_background_ratio = 10 vm.dirty_ratio = 20
따라서 이것이 하려는 것은 더티 데이터 버퍼가 총 RAM 양의 10%일 때 pdflush 흐름 및 디스크에 데이터 쓰기 시작 - 디스크에 데이터를 기록하는 작업이 너무 집중적인 경우 , 버퍼는 계속 증가하고 사용 가능한 RAM의 20%에 도달하면 시스템은 사전 버퍼 없이 동기 모드에서 후속 쓰기 작업으로 전환합니다. 즉, 디스크 응용 프로그램에 쓰는 작업은 데이터가 디스크에 기록될 때까지 차단됩니다. (일명 '지연').
버퍼 크기가 10%에 도달하지 못하더라도 이해해야 합니다. , 시스템은 30초 후에 자동으로 pdflush를 시작합니다. 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
1GB 메모리가 있는 기기에서 이것은 더티 버퍼에 대한 제한을 500/900MB로 설정합니다. Android 기기에서는 완전히 쓸모가 없습니다. 디스크에 지속적으로 기록할 때만 작동하기 때문입니다. – 무거운 Linux 서버에서만 발생하는 일입니다.
벼락! 스크립트는 더 합리적인 값을 사용하지만 전반적으로 여전히 상당히 의미가 없습니다.
if [ "$mem" -lt 524288 ];then sysctl -w vm.dirty_background_ratio=15; sysctl -w vm.dirty_ratio=30; elif [ "$mem" -lt 1049776 ];then 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;
처음 두 명령은 512MB RAM이 있는 스마트폰에서 실행되고, 두 번째 명령은 1GB, 나머지 명령은 1GB 이상입니다. 그러나 실제로 기본 설정을 변경해야 하는 이유는 매우 느린 내부 메모리 또는 메모리 카드가 있는 장치입니다. 이 경우 변수의 값을 퍼뜨리는 것, 즉 다음과 같이 만드는 것이 합리적입니다.
sysctl -w vm.dirty_background_ratio=10 sysctl -w vm.dirty_ratio=60
그런 다음 서지 시스템이 디스크에 데이터를 기록할 필요 없이 작업을 기록할 때 마지막까지 동기화 모드로 전환하지 않으므로 애플리케이션이 기록 시 지연을 줄일 수 있습니다.
쓸모없는 추가 조정 및 성능 조정
실제로 아무 것도 하지 않는 "최적화"가 훨씬 더 많습니다. 대부분은 아무런 효과가 없지만 일부는 일부 를 개선할 수 있습니다. 다른 방식으로 기기를 저하시키는 동안 성능 측면(일반적으로 성능 대 배터리 소모로 귀결됨) .
다음은 Android 시스템 및 기기에 따라 유용하거나 유용하지 않을 수 있는 인기 있는 몇 가지 추가 최적화입니다.
- 가속 – 성능 및 언더볼팅을 개선하기 위한 작은 가속 – 배터리를 약간 절약합니다.
- 데이터베이스 최적화 – 이론상 이것은 해야 기기 성능이 향상되지만 의심스럽습니다.
- Zipalign – 아이러니하게도 내장된 Android SDK 기능에도 불구하고 스토어에서 APK 파일 내 콘텐츠 정렬이 zipalign을 통해 전송되지 않는 소프트웨어가 많이 있음을 알 수 있습니다.
- 불필요한 시스템 서비스를 비활성화하고 사용하지 않는 시스템과 거의 사용하지 않는 타사 응용 프로그램을 제거합니다. 기본적으로 블로트웨어를 제거합니다.
- 특정 장치에 최적화된 맞춤형 커널(모든 핵이 동등하게 좋은 것은 아님).
- 이미 I/O 스케줄러에 대해 설명했습니다.
- 포화 알고리즘 TCP Westwood – 무선 네트워크용 기본 Android Cubic에서 보다 효율적으로 사용되며 맞춤 커널에서 사용할 수 있습니다.
쓸모없는 설정 build.prop
XDA 개발자 포럼의 LaraCraft304는 연구를 수행했으며 "전문가"에게 권장되는 인상적인 /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 ro.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.shutdown.mode ro.HOME_APP_ADJ