가장 흔한 안드로이드 최적화 오해

따라서 많은 올인원 최적화 스크립트가 동일한 방법을 사용하고 있으며 그중 일부는 완전히 구식이거나 장기적으로 유해합니다. 요약하면, 대부분의 '올인원'최적화 스크립트는 이러한 최적화가 '작동하는 방법 또는 이유에 대한 명확한 이해없이 함께 권장되는 조정에 불과합니다. 사용자는 스크립트를 플래시하고 성능이 갑자기 더 빨라진다'고 주장합니다. ( 사실, 성능 향상을 초래 한 것은 장치를 재부팅하는 매우 간단한 작업이었을 가능성이 큽니다. , 기기의 RAM에있는 모든 것이 정리됨에 따라) .

이 Appuals 독점 기사에서는 ' 최적화” Android 성능 및 단순한 신화인지 아니면 기기 성능에 대한 합법적 인 조정인지 여부.

교환

신화 목록의 맨 위에는 Android 스왑이 있습니다. 이는 Android 최적화로 간주된다는 점에서 매우 어리석은 일입니다. Swaps의 주요 목적은 페이징 파일을 만들고 연결하여 메모리의 저장 공간을 확보하는 것입니다. 현명한 소리 종이에 ,하지만 실제로는 섬기는 사람 , 거의 상호 작용이 없습니다.

Android 휴대 전화의 교체를 정기적으로 사용하면 캐시를 통과하는 사물로 인해 심각한 지연이 발생합니다. 예를 들어, 응용 프로그램이 스왑에 저장된 그래픽을 표시하려고하는데, 이제 다른 응용 프로그램과 데이터 스왑을 배치하여 공간을 확보 한 후 디스크를 다시로드해야한다고 상상해보십시오. 정말 지저분 해요.

일부 최적화 애호가는 스왑이 아무런 문제가 없다고 말할 수 있지만 성능을 향상시키는 스왑이 아니라 내장 된 Android 메커니즘입니다. lowmemorykiller , 사용되지 않는 비대하고 우선 순위가 높은 프로세스를 정기적으로 종료합니다. LMK는 메모리 부족 상태를 처리하기 위해 특별히 설계되었으며 kswapd 일반적으로 사용자 공간 프로세스를 종료합니다. 이것은 OOMkiller (메모리 부족 킬러), 하지만 그것은 완전히 다른 주제입니다.

요점은 예를 들어 RAM이 1GB 인 기기는 스왑에서 필요한 성능 데이터에 도달 할 수 없으므로 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 스토어 페이지에서도 Android 4.0 이상 이후 Seeder의 효과가 떨어 졌다고 지적하기 때문입니다. 그러나 어떤 이유로 든 Seeder는 최신 Android 시스템에 대한 최적화 토론에서 여전히 팝업됩니다.

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

Seeder의 저자는 Linux 악마를 가져갔습니다. rngd , Android의 재앙을 위해 컴파일되어 훨씬 빠르고 예측 가능한 / dev / urandom 경로에서 임의의 데이터를 가져 와서 / dev / random /이 고갈되지 않도록 초당 dev / random /으로 병합합니다. 그 결과 엔트로피가 부족하지 않고 훨씬 더 원활하게 수행되는 Android 시스템이 탄생했습니다.

Google은 Android 3.0 이후에이 버그를 박살 냈지만 어떤 이유에서인지 Seeder가 계속 나타납니다. '권장 조정' Android 성능 최적화를위한 목록입니다. 또한 Seeder 앱에는 동일한 사용 여부에 관계없이 Seeder의 기능을 포함하는 sEFix와 같은 몇 가지 유사 기능이 있습니다. rngd 또는 대안 헤지 또는 / dev / urandom과 / dev / random 사이의 심볼릭 링크 일 수도 있습니다. 이것은 최신 Android 시스템에서는 절대적으로 의미가 없습니다.

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

그렇게 할 때 파종기 또는 Seeder 기반 개선 사항이 최신 Android 최적화 스크립트에 포함되어 있습니다. 하락 장치 성능에서 rngd 지속적으로 장치를 깨우고 CPU 주파수를 증가시켜 배터리 소모에 부정적인 영향을 미칩니다.

Odex

Android 기기의 재고 펌웨어는 거의 항상 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 버전을 플래시하고 잠시 동안 'Busy, Optimizing Applications'라는 메시지를 표시 할 때 이러한 상황이 발생합니다.

Lowmemorykiller 조정

Android의 멀티 태스킹은 애플리케이션이 백그라운드에서 조용히 작동하는 클래식 모델을 기반으로하고 백그라운드 앱 수에 제한이 없다는 점에서 다른 모바일 운영 체제와 다릅니다 ( 개발자 옵션에 설정되어 있지 않으면 일반적으로 권장되지 않습니다.) – 또한 시스템이 메모리 부족 상황에서 백그라운드 앱을 종료 할 수있는 권한을 보유하더라도 백그라운드 실행으로 전환하는 기능은 중지되지 않습니다 ( 이 가이드의 앞부분에서 lowmemorykiller 및 out-of-memory 킬러에 대해 언급 한 부분을 참조하십시오.) .

돌아가려면 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 튜닝 유용 할 수있다 512 RAM이있는 훨씬 오래된 장치의 경우 더 이상 누가 소유합니까? 2GB는 현대적인 '예산 범위'이며, 심지어 4GB RAM 장치도 요즘 '중간 범위'로 간주되므로 LMK 조정은 정말 구식이고 쓸모가 없습니다.

I / O 조정

많은 Android 용 최적화 스크립트에서 종종 I / O 하위 시스템을 해결하는 조정을 찾을 수 있습니다. 예를 들어, 벼락! 다음 줄을 포함하는 스크립트 :

에코 0> $ i / 대기열 / 회전; 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이므로 이러한 유형의 스케줄러 ' 비틀기' I / O 하위 시스템에 특별하거나 의미있는 작업을 수행하지 않습니다. 사실, 이러한 모든 다중 화면 목록 명령은 간단한 주기로 대체하는 것이 좋습니다.

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

이렇게하면 I / O 통계가 누적되어 모든 드라이브에 대해 noop 스케줄러가 가능해집니다. 이는 성능에 긍정적 인 영향을 주지만 매우 작지만 거의 완전히 무시할 수있는 수준입니다.

성능 스크립트에서 흔히 볼 수있는 또 다른 쓸모없는 I / O 조정은 SD 카드의 미리 읽기 값이 최대 2MB까지 증가한 것입니다. 미리 읽기 메커니즘은 앱이 해당 데이터에 대한 액세스를 요청하기 전에 미디어에서 데이터를 일찍 읽습니다. 따라서 기본적으로 커널은 미래에 어떤 데이터가 필요한지 알아 내고이를 RAM에 미리로드하여 반환 시간을 줄여야합니다. 이것은 서류 상으로는 훌륭하게 들리지만 미리 읽기 알고리즘은 더 자주 잘못된 , 이는 높은 RAM 소비는 말할 것도없고 완전히 불필요한 입출력 작업으로 이어집니다.

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

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

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

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

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]; 그런 다음 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 – 아이러니하게도, 내장 된 Android SDK 기능에도 불구하고 상점의 APK 파일 내에서 콘텐츠 정렬 기능이 있음에도 불구하고 많은 소프트웨어가 zipalign을 통해 전송되지 않음을 알 수 있습니다.
• 불필요한 시스템 서비스를 비활성화하여 사용하지 않는 시스템과 거의 사용하지 않는 타사 응용 프로그램을 제거합니다. 기본적으로 블로 트웨어를 제거합니다.
• 특정 장치에 최적화 된 사용자 지정 커널 (다시 말하지만 모든 핵이 똑같이 좋은 것은 아닙니다).
• 이미 설명한 I / O 스케줄러 noop.
• 포화 알고리즘 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