원본 링크:https://www.coolapk.com/…

— 여러 게시물에서 종종 "메모리를 더 많이 쓰는 게 정상이야; 메모리는 사용하기 위해 만들어진 거야. 왜 스트림라인에 그렇게 많은 메모리가 남아 있지?"라는 댓글을 자주 볼 수 있어요. 이것이 그의 발언입니다. 이 진술들은 대체로 엄밀성이 부족합니다. 아래에서는 좀 더 간단한 설명을 사용해 여러분 자신을 감을 드리려고 합니다휴대전화的메모리 관리(주로 가상 기억) 기본적인 이해는 가지고 있고, 초보자를 위해 글을 쓰는 건 이번이 처음이에요대중 과학실수가 있으면 댓글란에 알려 주세요

————— 경계선인가요—————

참고: 이 글에서 언급된 모든 '메모리'는 일반적으로 사람들이 흔히 '실행 중인 메모리'라고 부르는 것, 즉 'RAM'을 의미하며, 저장 공간이 아닙니다!

————— 경계선인가요—————

먼저, 몇 가지 개념과 전문 용어를 알아봅시다

1. 가상 메모리:

가상 메모리는 현대 운영체제에서 흔히 사용되는 메모리 관리 방식의 한 종류입니다기술현재 일반적으로 사용되는 방법은 페이지 기반 가상 메모리 관리로, 보통 (보통)4KB) 메모리 할당, 재활용, 교환을 최소한의 세분화로 관리합니다.

2.SWAP:

SWAP은 가상 메모리 기술의 일부로, 하드 드라이브의 공간을 나누어 메모리 페이지를 스왑하는 방식입니다. 간단히 말해, 메모리에서 하드 드라이브로 데이터를 이동시켜 물리적 메모리를 확보하는 것입니다. 윈도우에는 "페이지네이티드 파일"이라는 유사한 기능도 있습니다. 하지만 리눅스와 달리 윈도우는 페이지 파일이 많이 의존하기 때문에 비활성화하면 이런 문제가 발생합니다큰 문제들자세한 내용은 이 기사 끝의 추가 장을 참조하세요.

3.ZRAM:

ZRAM은 SWAP의 또 다른 구현체입니다. 하드 디스크 공간을 사용하는 대신, LZ4/ZSTD와 같은 압축 알고리즘을 사용해 메모리 데이터를 압축하여 물리적 메모리를 확보하는 방식으로 메모리 공간을 직접 분할하여 스왑 페이지를 만듭니다.

4.ZRAM Writeback

ZRAM Writeback은 ZRAM의 확장 기능입니다. SWAP과 마찬가지로 하드 드라이브 공간에 스왑 파일을 생성하여 메모리 페이지를 스왑합니다. 차이점은 ZRAM Writeback이 압축된 메모리 데이터를 교환한다는 점입니다. Write Control 로직은 커널이 아닌 사용자 계층에서 실행되며, 구체적인 전략은 시스템 벤더가 결정하므로 이 글에서는 이에 대해 다루지 않습니다.

5. 직접 재활용 및 비동기 재활용

메모리 회수에는 두 가지 유형이 있습니다: 비동기 수집은 백그라운드 스레드에서 실행되며 현재 프로세스에 영향을 주지 않아 성능과 부드러움에 큰 영향을 미치지 않지만, 수집 속도는 느립니다; 직접 회수는 빠르지만 현재 프로세스를 차단하여 소프트웨어 인터페이스가 짧게(보통 매우 짧게) 멈추게 하여 성능과 부드러움에 큰 영향을 미칩니다.

————— 경계선인가요—————

먼저, 제목에 있는 질문에 답해봅시다: "메모리를 많이 사용할수록 더 좋은가?" 이 말이 맞나요? 네, 하지만 완전히는 아닙니다.

메모리는 실제로 사용되지만, 메모리는 운영체제와 사용자 소프트웨어뿐만 아니라 파일 캐싱이라는 점도 중요합니다. 거의 모든 운영체제에는 파일 캐싱 메커니즘이 있습니다. 하드 드라이브나 플래시 저장소에서 읽은 파일은 메모리에 캐시되므로, 다음에는 하드 드라이브나 플래시에서 읽지 않고 직접 파일 캐시를 호출해 처리 속도를 높이세요. 메모리가 부족할 때는 파일 캐시를 빠르게 해제하여 할당할 수 있어, 빠르게 복구된 메모리와 여유 메모리를 모두 커널에 의해 "사용 가능한 메모리"로 취급됩니다. 하지만 시스템 백엔드 인터페이스와 다양한 소프트웨어(예: DEV Check)에서 보는 것은 '자유 메모리'가 아니라 커널이나 소프트웨어 자체 알고리즘이 계산한 '가용 메모리'입니다.

사진에서 보듯이, 커널은 me에 속해 있습니다miNFO에서는 "사용 가능한 메모리"≠ "자유 메모리"를 의미합니다: "자유 메모리"는 실제로 어떤 프로세스나 파일도 차지하지 않은 할당되지 않은 메모리를 의미하며, "사용 가능한 메모리"는 할당 가능한 메모리를 의미합니다(이 크기는 주로 저수표 및 빠르게 복구 가능한 기타 메모리 항목 위의 파일 캐시와 여유 메모리 부분에 의해 추정됩니다)

자료 출처: /proc/meminfo

그래서 시스템 백그라운드나 여러 앱에 많은 메모리가 남아 있다고 해도, 그 메모리가 완전히 활용되고 있다는 뜻은 아닙니다. 대신 그들은 그것을 간소화했습니다최적화저와 같은 사람들을 위해 시스템 자체 메모리 사용량을 줄여 사용자에게 더 많은 메모리를 확보하는 것을 목표로 하고 있습니다적용이는 "더 많은 메모리를 사용하는 것이 정상이다; 메모리는 사용하기 위해 존재한다"는 관점과 충돌하지 않는다.

————— 경계선인가요—————

진격튜토리얼— 메모리 재활용 및 ZRAM 이니셔티브 통제:

빙의ROOT아래 커널 매개변수를 수정하여 메모리 회수와 ZRAM 활동을 제어할 수 있습니다.

1. vm.watermark_scale_factor：

메모리 수위 라인 간 간격을 조절하며, 조정 범위는 1~1000(전체 메모리 크기의 0.01%에서 10%에 해당)입니다. 값이 너무 낮으면 자주 직접 재활용이 촉발됩니다지연값이 너무 크면 메모리가 낭비됩니다. 100(전체 메모리의 1%)로 설정하는 것이 권장됩니다.

커널은 min/low/high의 세 가지 워터마크 라인을 정의합니다. 자유 메모리(참고: '사용 가능한 메모리'가 아닌 'free memory')가 낮은 워터마크 이하로 떨어지면, 커널은 kswap 상태로 깨어나 비동기적으로 메모리를 회수합니다(데이터를 ZRAM/SWAP으로 스왑하고 파일 캐시를 회수). 유휴 메모리가 최소 수위 이하로 떨어지면 직접 복구가 트리거됩니다. 최소 수위 선의 값은 전체 메모리 크기와 vm.min_free_kbytes 계산을 바탕으로 커널에 의해 계산됩니다. 이 매개변수를 수정하고 기본값을 유지하는 것은 권장되지 않습니다.

2. vm.extra_free_kbytes：

추가 예약 메모리는 최소 워터마크와 로우 워터마크 사이에 정해진 값을 가집니다. 값이 너무 낮으면 직접 회수(direct reclaimation)를 자주 트리거하여 지연이 발생하고, 너무 크면 메모리를 낭비합니다. 전체 메모리 크기의 1~2%(KB 단위)로 설정하는 것이 권장됩니다.

3. vm.swappiness：

커널 메모리가 부족할 경우(낮은 임계값 이하), 스왑 페이지와 ZRAM/SWAP 및 복구된 파일 캐시 간의 바이어스는 0~200, 구형 커널은 0~100까지 다양합니다. 값이 작을수록 파일 캐시를 수집할 가능성이 높고, 값이 클수록 ZRAM/SWAP을 사용할 가능성이 높아집니다.

위의 커널 매개변수는 사용 가능합니다Scene또한 루트 권한을 사용하여 다음과 같은 명령을 실행하여 수정할 수도 있습니다:

echo 100 >/proc/sys/vm/watermark_scale_factor

echo 131072 >/proc/sys/vm/extra_free_kbytes

echo 100 >/proc/sys/vm/swappiness

– 백엔드를 더 유지하고 싶다면 extra_free_kbytes와 watermark_scale_factor의 가치를 줄이고 스왑피니스의 가치를 적당히 높일 수 있습니다.

– 더 높은 부드러움을 원한다면 extra_free_kbytes값과 watermark_scale_factor 값을 높이면서 스왑 정도를 더 균형 잡힌 값으로 조정할 수 있습니다.

– 둘 다 원한다면 더 큰 메모리를 가진 휴대폰을 사세요

————— 경계선인가요—————

알려주세요 그리고 백스테이지 킬링:

안드로이드 9부터 구글은 내장된 LMK 커널을 버리고 LMKD로 전환하기 시작했으며, LMKD는 시스템의 데몬으로 실행됩니다. 따라서 백그라운드 앱 종료와 커널 자체는 각 제조사의 접근 방식과 거의 관련이 없습니다구성LMKD/다른 배경 제거 메커니즘을 도입했습니다. 이와 관련해MIUILMKD 구성 외에도, "배터리 및 성능"과 "프레임워크 시스템 프레임워크" 모두에 백그라운드 킬링 코드가 있습니다. 제조사에서 추가한 백그라운드 킬 메커니즘을 사용하고 싶지 않고 LMKD를 직접 설정하고 싶다면, 이 방법이 좋은 선택입니다LSPosed"AppRetention" 모듈은 벤더의 백그라운드 엔드 제거 메커니즘을 차단합니다.

그 다음, 구글 문서에 따라 LMKD를 구성하세요:링크 보기

————— 경계선인가요—————

추가 섹션 — Windows 페이징 파일 Pagefile.sys 및 가상 메모리 주소 할당에 관한 추가 지식:

Windows는 2단계 메모리 할당(예약 + 커밋)을 사용하며, 커밋 단계에서는 물리적 주소(물리적 메모리 또는 페이징 파일)의 매핑을 반드시 확인하는 것이 필수적입니다. 페이징 파일은 시스템의 제출 제한 중 하나이며, 시스템이 지원할 수 있는 가상 메모리 총 양을 직접 결정합니다(Windows 작업 관리자 메모리 카드 페이지에는 "커밋드"라는 데이터 항목이 있습니다; 슬래시의 왼쪽은 모든 프로그램 요청 메모리 크기의 합이고, 오른쪽은 전체 가상 메모리 크기로, 이 값은 = 물리적 메모리 크기 + 페이징 파일 크기이며, 이 경우 페이징 파일은 시스템에 의해 동적으로 분할됩니다).

Windows 작업 관리자용 메모리 정보

Windows에서 프로그램이 일정 메모리를 허용하면, 시스템이 해당 프로그램에 물리 주소 크기를 할당한다고 생각할 수 있습니다. 할당 후에는 다른 프로그램이 이 메모리 공간을 사용할 수 없고, 프로그램이 할당한 메모리는 일반적으로 실제 필요 메모리보다 많습니다. 따라서 페이징 파일을 닫을 때 물리 메모리가 많이 남아 있는데도 새 프로그램을 열어도 메모리가 부족하다는 메시지가 나타날 수 있습니다. 하지만 리눅스에는 이 문제가 없습니다. 리눅스는 지연 할당 전략을 사용하며, 프로세스가 실제로 메모리에 접근할 때만 물리적 메모리 주소를 할당합니다. 프로그램이 요청하는 메모리는 "실제" 가상 주소를 할당하며, 가상 메모리 주소의 한계는 "vm.overcommit_memory" 커널 파라미터에 의해 결정됩니다. 우리가 사용하는 안드로이드 폰에서는 가상 메모리 할당 제한이 "overcommit_memory"입니다. 기본값은 1로, 가상 메모리 제한을 무시하고 모든 물리적 메모리를 할당할 수 있습니다.

Scene의 SWAP 관리 페이지에서 제 휴대폰의 모든 프로세스가 최대 208GB의 메모리를 요청한 것을 볼 수 있습니다! 하지만 물리적 메모리가 다 쓰이지 않아서 새 소프트웨어를 열 수 있었어요.

왜 윈도우가 리눅스와 같거나 비슷한 메커니즘으로 바꾸지 않는지에 대해서는 저도 잘 모르겠습니다; 저는 윈도우가 너무 많은 역사적 부담을 지니기 때문이라고 생각합니다(WIN의 전설적인 호환성에 해당).

#HyperOS##HyperOS2##玩机技巧 #