겨울 방학동안 7주차간 세미나를 하게되었습니다.
그래서 필요하다 생각되는 안드로이드에 대한 내용을 주제별로 나눠서 공부할 계획입니다.
처음에는 기초를 쌓아 올리는게 중요하다 생각되어서 한번 공부했던 내용이지만 복습을 하게 되었습니다.
이번 주차에서는 안드로이드 OS와 구성요소 그리고 생명주기에 대해 설명하겠습니다
안드로이드는 리눅스를 기반으로 만들어진 OS 입니다
개발은 주로 Java, Kotlin, Dart(Flutter) 언어를 이용해서 이루어집니다.
안드로이드 구조는 5계층으로 나뉘어지는데
순으로 이루어져 있고 각 계층에 구성요소는 사진을 참고 하시면 될 것 같습니다.
주로 소스 코드를 작성하면 중간코드로 컴파일되고 이를 다시 기계어로 변환해서 CPU에서 동작 됩니다.
하지만 CPU에 따라 기계어가 의미하는 명령어가 다릅니다.
EX) 001이 ADD 일 수 있고 SUB 일 수 있습니다.
하지만 자바가상머신(JVM)은 이를 해결할 수 있습니다.
.java 파일이 바이트 코드인 .class 파일로 컴파일 되며,
이를 자바가상머신에서 실행 가능한 형태의 기계어로 변환하여 동작합니다.
허나 안드로이드에서는 JVM보다 최적화된 ART를 사용하고 있습니다.
ART에는 두가지로 나뉘는데, 아래와 같은 특징이 있습니다.
AOT - 앱 설치 시 미리 기계어로 해석, 앱용량이 커지나 성능 개선
JIT(JVM) - 실행 중 컴파일, 메모리를 많이 차지
ㅎ 안드로이드에서는 AOT를 주로 사용하나 JIT도 섞어서 사용하고 있습니다.
안드로이드에는 여러 구성요소가 존재합니다만
그 중에서도 가장 근간이 되는 4대 기본 구성요소가 있습니다.
이들은 인텐트를 중심으로 상호작용이 이루어집니다.
액티비티는 안드로이드에서 UI를 담당하고 유저와 상호작용을 하는 컴포넌트 입니다.
즉 쉽게 생각하면 앱의 화면이 곧 액티비티라고 생각하셔도 좋을 것 같습니다.
안드로이드 앱은 하나 이상의 액티비티가 존재해야 하며,
또한 한 화면에는 액티비티가 하나만 있어야합니다.
이를 액티비티 하위개념인 프래그먼트로 해결이 가능합니다.
서비스는 안드로이드 백그라운드에서 돌아가는 프로세스 입니다.
음악을 재생하거나 걸음 수를 측정할 때는 앱 화면에 있지 않아도 되는 것을 생각하면 됩니다.
서비스는 인위적으로 중지하지 않는 이상 끝까지 동작하며,
별도의 화면은 존재하지 않습니다.
또한 서비스와 유사하게 비동기 스레드인 AsyncTask를 통해서도 구현이 가능합니다.
브로드캐스트 리시버는 이벤트를 감지하여 방송을 수신해주는 컴포넌트입니다.
배터리가 부족할 때, 와이파이 끊길 때, 문자 알림이 올 때 등에 특정 기능을 수행하고 싶다면 사용하면 됩니다.
가장 대표적으로는 스마트폰 앱에서 인증번호를 받으면 따로 입력해주지 않아도 입력 되는 앱들이 있습니다.
이는 브로드캐스트 리시버를 잘 활용한 예시라고 생각하시면 됩니다.
구현은 클래스를 상속하거나 익명클래스로 구현할 수 있고,
Manifest에 선언된 수신기나 Context에 등록된 수신기를 통해 수신 합니다.
콘텐트 프로바이더는 데이터들을 관리하고 제공하는 컴포넌트 입니다.
스마트폰에 저장된 연락처나 이미지, 파일을 불러올 때 사용하는 녀석입니다.
UI에서는 CursorLoader를 통해 백그라운드에서 비동기식 쿼리를 사용합니다.
4대 컴포넌트의 중심에 있는 인텐트 입니다.
간단히 작업을 요청할 때 사용하는 메세지 객체라고 생각하시면 됩니다.
인텐트는 명시적 인텐트와 암시적 인텐트로 나뉘는데,
이 둘의 차이는 대상을 명확히 제시하느냐의 차이 입니다.
특정 액티비티 화면으로 이동해라는 메세지를 보낼 때는 명시적 인텐트를 사용하는 것이고
"웹페이지를 띄울건데 이를 띄울 브라우저라는 녀석을 사용할거야"
라고 한다면 브라우저라는 항목에 속한 크롬이나 기본 인터넷 같은 녀석들 중 고르라고 물어볼겁니다.
이 항목은 앱에 Manifest 파일에 인텐트 필터에 명시할 수 있습니다.
크롬은 브라우저라는 내용을 인텐트 필터에 명시해놨을 겁니다.
생명주기에서는 가장 기본이 되는 액티비티를 먼저 보겠습니다.
기본적으로 7단계를 가지고 있습니다.
onCreate() 메소드는 처음생성시 호출 됩니다.
그 다음으로 on Start() 메소드가 호출 되며, 잇따라 onResume() 메소드가 호출 됩니다.
별 다른 일이 일어나지 않는 이상은 액티비티 동작 상태에 머물러있습니다.
그러다 앱에 변화가 생기면 상황에 따라 onPause() 메소드를 호출하고 다시 onResume() 메소드를 호출하여 돌아오거나
화면에 안보이게 되면 onStop() 메소드를 호출하게 됩니다.
이 때 유저가 액티비티로 돌아오면, onRestart() 메소드를 호출하고 onStart() 메소드로 돌아가고
메모리 부족해 메모리 최적화등으로 인해 앱 프로세스가 죽은 상태에서,
액티비티로 돌아오면 onCreate() 메소드로 가게됩니다.
만약 유저가 앱을 종료하면 onDestory() 메소드까지 호출하게 되며 앱은 꺼집니다.
허나 구성 변경으로 인해 액티비티가 파괴되어진거면 동일하게 onDestory()메소드는 호출하나,
새 액티비티 인스턴트를 생성하고, onCreate()를 호출해 새로운 액티비티를 초기화합니다.
이 때 onSaveInstanceState등에 담긴 데이터를 통해 데이터를 복구할 수 있습니다.
액티비티 생명주기에 있는 메소드들이 어떤 상황에 어떤 순서로 호출되는지 보기 위에 실습한 내용들 입니다.
어느 상황에서도 위에서 말한 순서를 지키는 것을 볼 수 있습니다.
특히 화면전환의 경우에는 구성요소를 파괴하고 새로운 액티비티를 만들어야하기 때문에
Destory 됬으나 바로 새로운 인스턴트를 생성하는 모습을 볼 수 있습니다.
생명주기는 액티비티에 하위 개념인 프래그먼트에서도 존재합니다.
액티비티의 생명주기가 큰 영향을 주며 큰차이는 없습니다.
뷰를 만들거나 파괴하는 과정이 더 생기고, 액티비티에 붙거나 떼는 과정이 더생겼습니다.
또한 새로운 선언형 UI 방식인 compose에서는 새로운 생명주기를 가집니다.
허나 되게 단순합니다.
컴포지션을 통해 UI가 만들어지면 컴포저블에서 리컴포지션이 0회이상 일어납니다.
이 때 상태가 변하거나하면 상태와 연관이 있는 부분만 리컴포지션이 일어나게 됩니다.
그리고 리컴포지션이 끝나면 컴포지션이 끝이 나게 됩니다.
내용은 해당 페이지를 참고했습니다. 감사합니다.
Architecture, Design, UI(세미나) (2) | 2024.01.29 |
---|---|
Android Studio 및 디버깅 도구 활용(세미나) (0) | 2024.01.18 |
안드로이드 공부를 위한 지침 (0) | 2023.12.28 |
안드로이드 문서 저장 방식에 대한 기록 (0) | 2023.07.13 |
data binding 실습 (단 방향, 양 방향 통신) (0) | 2023.07.04 |
댓글 영역