간단히 정리
- 앱은 사용자의 관심을 항상 기다림
- 사용자가 앱을 실행하면,
- 시스템(iOS)은 이렇게 주목 받은 앱에게 리소스를 몰아줌
- 이렇게 사용자 관심을 받을때랑 못받을때랑, 앱의 상태가 포그라운드, 백그라운드로 변함
- 개발자는 이렇게 앱의 상태가 변경에 됨에 따라 대응 할수 있게 앱을 만들어주어야합니다.
- 그래서 앱의 라이프 사이클 이해가 중요함
앱의 라이프 사이클
-
Not Running - 앱이 꺼진 상태, 앱이 시스템에 의해 완전히 종료된 상태, 아직 실행되지 않았을 때
-
Inactive - 꺼짐에서 켜지면서 잠깐 거쳐감, 앱이 실행 중인 상태, 하지만 이벤트안 받음. Active 상태로 넘어가기 전에 앱은 반드시 이 상태를 거침. 알림창이 화면을 덮어서 앱이 event를 받지 못하는 상태.
-
Active - 앱이 켜진 상태, 앱이 실행 중이고 이벤트를 받을 수 있는 상태, Foreground 상태에 있는 앱들의 상태.
-
background - 홈으로 가면 inactive 상태 거쳤다가 백그라운드 상태가 된다. 앱 사용중에 다른 앱을 실행하거나 홈 화면으로 나갔을 때. 백그라운드에서 동작하는 코드를 추가하면 suspended 상태로 넘어가지 않고 백그라운드 상태를 유지함. 처음부터 background 상태로 실행되는 앱은 inactive 대신 background 상태로 진입합니다. 음악을 실행하고 홈 화면으로 나가도 음악이 나오는 상태가 이 경우에 해당됩니다.
-
suspended - 앱이 background 상태에서 추가적인 작업을 하지 않으면 일정 시간 후 suspended 상태로 진입함. 앱을 다시 실행할 경우 빠른 실행을 위해 메모리에만 올라와있음. 메모리가 부족한 상황이 되면 iOS는 suspended 상태에 있는 앱들을 메모리에서 해제시켜서 메모리를 확보합니다.
여러개 탭 볼때는 잠깐 inactive 상태인 것
라이프사이클
두개로 나눠짐
process Lifecycle
앱이 런치되고 종료되는 과정
UI Lifecycle
뷰가 foreground 상태로 들어가고, active 상태가 되는 과정
IOS 13이 나오면서 멀티 윈도우를 제공하게됨
이전에는 앱하나에 화면 하나였는데 아이패드 경우 앱 하나에 여러가지 뷰를 제공하는 경우가 생겼다.
원래는 앱 딜리게이트에서 프로세스 라이프사이클과 UI라이프사이클을 둘 다 관리했는데
점점 UI라이프사이클을 관리하는 뷰가 여러개가 되니까 scene 딜리게이트가 UI 딜리게이트를 담당하게 되었다.
앱을 켰을 때 scene이 앱에 커넥트 되고 씬이 foreground로 들어가고 백그라운드 갔을 때는 백그라운드로 갔다가 suspend됐을 때 씬이 disconnect 되고...
요런게 앱별로 여러개 관리가 될 수 있다!
개발자가 준비해야할 것
- 앱이 포그라운드 들어갈때
- 이니셜 UI 준비
- 사용자와의 인터랙션 준비
- 포그라운드를 떠날때
- 데이터 저장
- 앱의 작업을 최소화할 준비
- 백그라운드 들어갔을때
- 앱의 작업을 중단함
- 메모리 비우기
- 현재 상태를 저장해놓고 다음을 준비
