가장 일반적인 안드로이드 최적화 신화

안드로이드 성능 향상과 전반적인 최적화 팁에 대한 많은 지침 안내서가 있습니다. 그중 일부는 합법적이며 다른 일부는 이론적이거나 Android 시스템의 오래된 운영 방법을 기반으로하거나 무의미합니다. 여기에는 스왑 권장 사항, build.prop에 추가 된 값 및 Linux 커널의 변수 변경 사항이 포함됩니다.

성능, 배터리 수명 및 기타 사항을 크게 향상시킬 수있는 올인원 플래시 .zip은 수많은“최적화 스크립트”도 있습니다. 일부 조정은 실제로 작동 할 수 있지만 대부분은 단순히 위약 효과이거나 더 나쁜 것은 실제로 장치에 부정적인 영향을 미칩니다.

사람들이 의도적으로 악의적 인 스크립트를 공개한다고 말하는 것은 아닙니다. Play 스토어에는 가짜 유료 앱이 있지만 Android 포럼에서 출시 된 최적화 스크립트는 일반적으로 잘 의도 된 것입니다. 개발자가 잘못 알고있을 수 있습니다. 또는 단순히 다양한 최적화 조정을 실험 해보십시오. 불행히도, 특히“올인원”최적화 스크립트에서 일종의 눈덩이 효과가 발생하는 경향이 있습니다. 약간의 조정은 실제로 무언가를 할 수 있지만, 스크립트의 또 다른 조정은 전혀 아무 것도 할 수 없습니다. 그러나이 스크립트는 실제로 작동하는 것과 작동하지 않는 것에 대한 실제 조사없이 마법의 총알로 넘어갑니다. .

따라서 많은 올인원 최적화 스크립트가 동일한 방법을 사용하고 있으며 그 중 일부는 장기적으로 완전히 구식이거나 유해합니다. 요약하자면, 대부분의 "올인원"최적화 스크립트는 이러한 최적화가 어떻게 또는 왜 "작동하는지 – 사용자가 스크립트를 플래시하고 성능이 갑자기 더 빠르다"는 이유를 모른 채 권장되는 튜닝 일뿐입니다. ( 실제로, 장치의 RAM에있는 모든 것이 지워짐에 따라 성능을 향상시키는 매우 간단한 장치 재부팅 작업 일 가능성이 큼) .

이 Appuals 독점 기사에서는 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에서는이를 권장하지만, 지속적으로 활동하는 핵심 thead는 메모리에서 중복 페이지를 검색하기 위해 지속적으로 실행되기 때문에 구형 장치에서 더 큰 지연을 초래합니다. 기본적으로 최적화 조정을 실행하면 장치가 더욱 아이러니하게 느려집니다.

시더 – 안드로이드 3.0 이후로 구식

안드로이드 개발자들 사이에서 가장 논란의 여지가있는 최적화 팁 중 하나는 시더 (seeder) 이며, 우리는 누군가이 주제에 대해 우리를 잘못 증명할 수 있다고 확신하지만, 우선 시더의 역사를 조사해야합니다.

예, 훨씬 더 오래된 Android 기기 에 설치 한 후 더 나은 Android 성능을 선언하는 많은 보고서가 있습니다 . 그러나 어떤 이유로 든 사람들은 이것이 최신 Android 기기에 적용 가능한 최적화라는 것을 의미한다고 믿습니다. Seeder가 여전히 " 현대적인" 지연 지연 도구로 유지되고 제공된다는 사실은 잘못된 정보의 예입니다. 그러나 Play Store 페이지에서도 Seeder가 Android 4.0 이상 이후에는 효과가 떨어진다고 지적하기 때문에 Seeder 개발자의 잘못이 아닙니다. 그럼에도 불구하고 Seeder는 최신 Android 시스템에 대한 최적화 토론에서 여전히 나타납니다.

Seeder가 Android 3.0에서 기본적으로하는 일은 Android 런타임이 엔트로피를 얻기 위해 / dev / random / 파일을 적극적으로 사용하는 버그를 해결하는 것입니다. / dev / random / 버퍼가 불안정 해지고 시스템이 필요한 양의 데이터를 채울 때까지 차단됩니다. Android 기기의 다양한 센서 및 버튼과 같은 것은 거의 생각하지 마십시오.

Seeder의 저자는 Linux-demon rngd를 가져 와서 안드로이드의 inastroil을 위해 컴파일되어 훨씬 빠르고 예측 가능한 / dev / urandom 경로에서 임의의 데이터를 가져 와서 / dev / random을 허용하지 않고 매 초마다 dev / random /에 병합합니다. / 지친다. 이로 인해 엔트로피 부족이 발생하지 않은 Android 시스템이 훨씬 매끄럽게 수행되었습니다.

구글은 안드로이드 3.0 이후이 버그를 박살 냈지만, 어떤 이유로 든 Seeder는 여전히 안드로이드 성능 최적화를위한 “추천 된 조정” 목록에 나타납니다. 또한 Seeder 앱에는 sEFix와 같은 몇 가지 아날로그가 있습니다. 여기에는 동일한 rngd를 사용하든 대안을 사용 하든 / dev / urandom과 / dev / random 사이의 심볼릭 링크를 사용하든 Seeder의 기능이 포함되어 있습니다. 이것은 현대 안드로이드 시스템에서 절대적으로 의미가 없습니다.

의미가없는 이유는 최신 Android 버전이 SSL 연결 암호화, SSH 키 생성 등의 세 가지 주요 구성 요소 인 libcrypto 에서 / dev / random /을 사용하기 때문입니다. WEP_Wupkey / hostapd는 WEP / WPA 키를 생성하며, 소수의 EXT2 / EXT3 / EXT4 파일 시스템 작성시 ID를 생성하기위한 라이브러리.

따라서 최신 Android 최적화 스크립트에 Seeder 또는 Seeder 기반 향상 기능이 포함되면 rngd 가 지속적으로 장치를 깨우고 CPU 주파수를 증가시켜 배터리 소비에 부정적인 영향을 미치기 때문에 장치 성능이 저하 됩니다. .

오 덱스

안드로이드 장치의 주식 펌웨어는 거의 항상 odex입니다. 이는 / system / app / 및 / system / priv-app /에있는 APK 형식의 Android 앱용 표준 패키지와 확장자가 .odex 인 파일 이름과 동일하다는 것을 의미합니다. odex 파일에는 유효성 검사기 및 최적화 프로그램 가상 머신을 이미 통과 한 후 dexopt 도구와 같은 것을 사용하여 별도의 파일로 기록 된 최적화 된 바이트 코드 응용 프로그램이 포함되어 있습니다.

따라서 odex 파일은 가상 시스템을 오프로드하고 odexed 응용 프로그램의 빠른 시작을 제공합니다. 단점은 ODEX 파일이 펌웨어 수정을 방지하고 업데이트 관련 문제를 생성하므로 LineageOS와 같은 많은 사용자 정의 ROM은 배포 되지 않고 배포 됩니다 ODEX .

ODEX 파일 생성은 Odexer Tool 사용과 같은 여러 가지 방법으로 수행됩니다. 문제는 순전히 위약 효과라는 것입니다. 최신 Android 시스템이 / system 디렉토리에서 odex 파일을 찾지 못하면 시스템에서 실제로 파일을 작성하여 / system / dalvik-cache / 디렉토리에 배치합니다. 예를 들어, 새로운 Android 버전을 플래시하고 잠시 동안 "응용 프로그램 최적화 중"이라는 메시지가 표시 될 때 발생하는 상황입니다.

메모리 부족 킬러 조정

Android의 멀티 태스킹은 백그라운드에서 애플리케이션이 조용히 작동하는 클래식 모델을 기반으로한다는 점에서 다른 모바일 운영 체제와 다릅니다. 백그라운드 옵션 의 수에는 제한이 없습니다 ( 개발자 옵션에서 설정하지 않은 경우). 시스템은 메모리 부족 상황에서 백그라운드 앱을 종료 할 수있는 권한을 보유하지만 백그라운드 실행으로의 전환 기능은 중지되지 않습니다 ( 이 부분의 앞부분에서 메모리 부족 킬러 및 메모리 부족 킬러에 대해 이야기 한 위치 참조) 가이드) .

메모리 부족 방지 메커니즘으로 돌아 가기 위해 Android는 제한된 양의 메모리와 스왑 파티션이없는 상태에서 계속 작동 할 수 있습니다. 사용자는 계속해서 응용 프로그램을 시작하고 응용 프로그램간에 전환 할 수 있으며 시스템은 사용하지 않는 백그라운드 응용 프로그램을 자동으로 종료하여 활성 작업을위한 메모리를 확보합니다.

이것은 초기에 Android에 매우 유용했지만 어떤 이유로 든 태스크 킬러 앱의 형태로 인기를 얻었지만 일반적으로 이익보다 더 해 롭습니다. 작업 킬러 응용 프로그램은 설정된 간격으로 깨어나거나 사용자가 실행하며 많은 양의 RAM을 비우는 것처럼 보입니다. 양의 RAM은 양이 많은 것으로 보입니다. 더 많은 RAM은 더 빠른 장치를 의미합니까? 그러나 이것은 Android의 경우에는 해당되지 않습니다.

실제로 많은 양의 여유 RAM이 있으면 실제로 장치의 성능과 배터리 수명에 해로울 수 있습니다. 앱이 Android의 RAM에 저장되어 있으면 앱을 불러오고 실행하는 것이 훨씬 쉽습니다. Android 시스템은 메모리에 이미 있기 때문에 앱으로 전환하는 데 많은 리소스를 소비 할 필요가 없습니다.

이로 인해 안드로이드 초보자는 여전히 어떤 이유로 ( 슬프게도) 정보 에 의존하는 경향이 있지만 태스크 킬러는 예전만큼 인기가 없습니다. 불행히도, 새로운 메모리 트렌드는 메모리 킬러 메커니즘 튜닝의 추세 인 태스크 킬러를 대체했습니다. 예를 들어 MinFreeManager 앱이 될 것이며 시스템에서 백그라운드 앱을 종료하기 전에 RAM 오버 헤드를 늘리는 것이 좋습니다.

예를 들어 표준 RAM은 4, 8, 12, 24, 32 및 40Mb의 경계에서 작동하며 40MB의 여유 저장 공간이 채워지면 메모리에로드 되었지만 실행되지 않는 캐시 된 앱 중 하나 종료됩니다.

따라서 기본적으로 Android에는 항상 40MB 이상의 사용 가능한 메모리가 있습니다. 이는 메모리 부족이 정리 프로세스를 시작하기 전에 하나 이상의 응용 프로그램을 수용하기에 충분 합니다. 즉, Android는 항상 사용 가능한 최대 RAM 용량을 사용하여 사용자 경험.

안타깝게도 일부 가정용 맥주 애호가들이 권장 한 바에 따르면 LMK가 시작되기 전에 100MB로 값을 올립니다. 이제 사용자는 실제로이 공간을 사용하여 다시 저장하는 대신 RAM (100 – 40 = 60)을 잃게됩니다. 최종 앱의 경우 시스템은이 메모리 용량을 아무 용도로도 사용하지 않고 유지합니다.

LKM 조정 은 RAM이 512 개인 훨씬 더 오래된 장치에 유용 할 수 있지만 누가 더 이상 소유하고 있습니까? 2GB는 최신 "예산 범위"이며, 요즘 4GB RAM 장치도 "중간 범위"로 인식되므로 LMK 조정은 실제로 구식이되고 쓸모가 없습니다.

I / O 조정

Android 용 많은 최적화 스크립트에서 종종 I / O 하위 시스템을 다루는 조정이 있습니다. 예를 들어 ThunderBolt! 다음 줄이 포함 된 스크립트 :

 에코 0> $ i / 큐 / 회전; 에코 1024> $ i / queue / nr_requests; 

첫 번째 줄은 SSD를 다루는 데 I / O 스케줄러 명령을 제공하고 두 번째 줄은 대기열 I / O의 최대 크기를 128에서 1024로 증가시킵니다. $ i 변수에는 블록 장치 트리에 대한 경로가 포함되어 있기 때문입니다 / sys 및 스크립트는 루프에서 실행됩니다.

그런 다음 CFQ 스케줄러와 관련된 행을 찾습니다.

 에코 1> $ i / queue / iosched / back_seek_penalty; 에코 1> $ i / queue / iosched / low_latency; 에코 1> $ i / queue / iosched / slice_idle; 

그 뒤에 다른 플래너에 속하는 더 많은 행이 있지만 궁극적으로 처음 두 명령은 의미가 없습니다.

최신 Linux 커널은 기본적으로 어떤 유형의 저장 매체를 사용하는지 이해할 수 있습니다.

1024와 같은 긴 입출력 대기열은 최신 Android 기기에서는 쓸모가 없습니다. 실제로 데스크톱에서도 의미가 없습니다. 실제로 서버 에서만 권장됩니다. 휴대 전화는 헤비 듀티 Linux 서버가 아닙니다.

안드로이드 장치의 경우, 입력-출력에서 우선 순위가 지정된 응용 프로그램이없고 기계적인 드라이버가 없기 때문에 가장 좋은 플래너는 noop / FIFO-queue입니다. 따라서 이러한 유형의 스케줄러 " tweak" 는 특별하거나 의미있는 작업을 수행하지 않습니다. I / O 서브 시스템. 실제로 이러한 모든 다중 화면 목록 명령은 간단한 주기로 대체하는 것이 좋습니다.

 / sys / block / mmc *에서 i의 경우; echo noop> $ i / queue / scheduler echo 0> $ i / queue / iostats 완료 

이렇게하면 I / O 통계가 누적되어 모든 드라이브에 대해 noop 스케줄러를 사용할 수 있습니다. 이는 매우 작고 거의 무시할 수있는 성능이지만 성능에 긍정적 인 영향을 미칩니다.

성능 스크립트에서 종종 발견되는 또 다른 쓸모없는 I / O 조정은 SD 카드의 미리 읽기 값이 2MB까지 증가한 것입니다. 미리 읽기 메커니즘은 앱이 해당 데이터에 대한 액세스를 요청하기 전에 미디어에서 조기에 데이터를 읽는 것입니다. 따라서 기본적으로 커널은 향후 어떤 데이터가 필요한지 파악하고이를 RAM에 미리로드하여 반환 시간을 줄여야합니다. 이것은 종이에서는 훌륭하게 들리지만 미리 읽기 알고리즘이 더 자주 잘못되어 높은 RAM 소비는 말할 것도없이 입력 출력의 불필요한 동작을 초래합니다.

RAID 배열에서는 1 ~ 8MB 사이의 높은 미리 읽기 값이 권장되지만 Android 장치의 경우 기본값 인 128KB를 그대로 두는 것이 가장 좋습니다.

가상 메모리 관리 시스템 조정

또 다른 일반적인 "최적화"기술은 가상 메모리 관리 서브 시스템을 조정하는 것입니다. 이는 일반적으로 "더티 (dirty)"데이터를 저장하기위한 버퍼 크기를 조정하기위한 두 개의 커널 변수 (vm.dirty_background_ratio 및 vm.dirty_ratio) 만 대상으로합니다. 더티 데이터는 일반적으로 디스크에 기록 된 데이터이지만 더 많은 메모리가 남아 있고 디스크에 기록되기를 기다리고 있습니다.

Linux 배포 및 Androis의 VM 관리 하위 시스템에 대한 일반적인 조정 값은 다음과 같습니다.

 vm.dirty_background_ratio = 10 vm.dirty_ratio = 20 

따라서 더티 데이터 버퍼가 총 RAM 양의 10 % 일 때 pdflush 흐름을 깨우고 디스크에 데이터 쓰기를 시작합니다. 디스크에 데이터를 기록하는 작업이 너무 강하면 버퍼는 계속 커지고 사용 가능한 RAM의 20 %에 도달하면 시스템은 사전 버퍼없이 동기 모드에서 후속 쓰기 작업으로 전환합니다. 이는 데이터가 디스크에 기록 될 때까지 디스크 응용 프로그램에 기록하는 작업이 차단됨 을 의미합니다 (일명 'lag').

버퍼 크기 가 10 %에 도달하지 않아도 30 초 후에 시스템이 자동으로 pdflush로 시작된다는 것을 이해해야합니다. 10/20의 조합은 상당히 합리적입니다. 예를 들어 RAM이 1GB 인 장치의 경우 이것은 100 / 200MB의 RAM에 해당합니다. 이는 시스템 NAND에서 속도가 종종 속도 기록보다 낮은 버스트 기록 측면에서 충분합니다. -메모리 또는 SD 카드 (예 : 앱을 설치하거나 컴퓨터에서 파일을 복사 할 때)

어떤 이유로 스크립트 작성자는이 값을 부당한 비율로 더 높이려고합니다. 예를 들어 Xplix 최적화 스크립트에서 50/90의 높은 속도를 찾을 수 있습니다.

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

1GB의 메모리가있는 장치에서이 기능은 더티 버퍼에 대한 제한을 500 / 900MB로 설정합니다. 이는 디스크 에서 지속적으로 기록 할 때만 작동하기 때문에 안드로이드 장치에는 전혀 쓸모가 없습니다. 리눅스 서버.

벼락! 스크립트는보다 합리적인 값을 사용하지만 전반적으로 여전히 의미가 없습니다.

 [ "$ 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; 

처음 두 명령은 512MB의 RAM이있는 스마트 폰에서 실행되고, 두 번째 명령은 1GB 이상, 다른 명령은 1GB 이상입니다. 그러나 기본 설정을 변경해야하는 이유는 내부 메모리 나 메모리 카드가 매우 느린 장치입니다. 이 경우 변수의 값을 분산시키는 것, 즉 다음과 같이 만드는 것이 합리적입니다.

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

그런 다음 서지 시스템이 디스크에 데이터를 기록 할 필요없이 작업을 쓰면 마지막까지 동기화 모드로 전환되지 않으므로 기록 할 때 응용 프로그램이 지연을 줄일 수 있습니다.

쓸모없는 추가 조정 및 성능 조정

실제로 아무것도하지 않는 훨씬 더 많은 "최적화"가 있습니다. 이들 중 대부분은 단순히 효과가 없으며, 다른 것들은 성능의 일부 측면을 향상시키는 한편 다른 방법으로 장치를 저하시킬 수 있습니다 ( 일반적으로 배터리 소모와 성능 비교) .

다음은 Android 시스템 및 기기에 따라 유용하거나 유용하지 않을 수있는 추가 최적화입니다.

• 가속 – 성능 및 저전압을 개선하기위한 작은 가속 – 배터리를 약간 절약합니다.
• 데이터베이스 최적화 – 이론적으로 이것은 장치 성능을 향상 시켜야 하지만 의심 할 여지가 있습니다.
• Zipalign – 아이러니하게도 상점의 APK 파일에 내장 된 Android SDK 기능 컨텐츠 정렬에도 불구하고 많은 소프트웨어가 zipalign을 통해 전송되지 않습니다.
• 불필요한 시스템 서비스를 비활성화하여 사용하지 않는 시스템 및 거의 사용하지 않는 타사 응용 프로그램을 제거하십시오. 기본적으로 bloatware 제거.
• 특정 장치에 대한 최적화 기능을 갖춘 사용자 지정 커널 (다시 말해 모든 핵이 똑같이 좋은 것은 아닙니다).
• I / O 스케줄러 noop에 대해서는 이미 설명했습니다.
• 포화 알고리즘 TCP Westwood – 무선 네트워크 용 기본 Android Cubic에서보다 효율적으로 사용되며, 맞춤형 커널로 ​​제공됩니다.

쓸모없는 설정 build.prop

XDA Developers 포럼의 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 프로파일 러 .force_disable_err_rpt ersist.sys.shutdown.mode ro.HOME_APP_ADJ