화면 전환과 프로세스 관리를 나눕니다
android-16.0.0_r1의 ActivityTaskManagerService는 Activity와 태스크를 관리합니다. ActivityManagerService는 앱 프로세스와 서비스·브로드캐스트 등의 실행을 관리합니다. 둘은 system_server 안에서 협력하지만 액티비티의 생명주기와 프로세스의 생명주기는 일대일 관계가 아닙니다.
먼저 실행 중인 앱 스레드가 있는지 봅니다
ActivityTaskSupervisor.startSpecificActivity는 해당 WindowProcessController와 앱 스레드가 있으면 realStartActivityLocked를 시도합니다. 정상적으로 시작하면 반환합니다. 프로세스가 없거나 연결이 끊겼다면 다른 검사 뒤 startProcessAsync로 이어질 수 있습니다. 이 함수의 호출마다 새 PID를 만든다는 해석은 틀립니다.
앱 스레드가 있음 → 기존 프로세스에서 Activity 시작 시도
새 프로세스가 필요함 → ATMS의 비동기 요청 → AMS
ProcessList의 조건별 생성 경로 → 앱 연결 후 실행
Zygote 경로도 하나로 고정하지 않습니다
ATMS의 startProcessAsync는 ActivityManagerInternal.startProcess 호출을 handler에 게시합니다. AMS는 HostingRecord와 실행 조건을 넘겨 프로세스 시작을 요청합니다. ProcessList에는 일반 Process.start뿐 아니라 WebView Zygote와 App Zygote 분기가 있습니다.
USAP는 미리 만들어 둔 특화 전 프로세스를 사용하는 선택적 구성입니다. “Activity 시작마다 그 자리에서 새 fork가 실행된다”는 단정은 피해야 합니다. 소스에서 분기를 확인했다고 해서 특정 기기에서 실제로 그렇게 실행되는지까지 추적한 것은 아닙니다.
ANR과 메모리 부족으로 인한 종료를 구분합니다
ANR은 응답 기한을 넘긴 상황이지 특정 함수 하나에 대한 원인 판정이 아닙니다. 당시 스레드, Binder 대기, 잠금과 실행 시간을 함께 봅니다. OomAdjuster의 프로세스 상태·oom adj·스케줄러 그룹 조정과 lmkd의 메모리 압박 판단도 구분합니다. lmkd 종료는 커널 OOM이나 Java 예외와 같은 사건이 아닙니다.
기기 빌드, 패키지·프로세스 이름, PID와 시각, 기존 프로세스 유무, 종료 이유를 함께 기록합니다. 이 글은 고정 소스와 공식 문서의 대조이며 특정 앱의 재시작 정책이나 실기기 부팅을 검증한 결과는 아닙니다.