Manifest

안드로이드 시스템이 앱의 코드를 실행하기 전에 확보해야 하는 앱에 대한 필수 정보를 시스템에 제공하는 목록

• 앱의 패키지 이름
• 앱에서 사용되는 컴포넌트(액티비티, 서비스, 브로드캐스트 리시버, 컨텐트 프로바이더)
• 권한(Permission)
• 앱에서 요구하는 하드웨어와 소프트웨어 특징

4대 컴포넌트

• Intent를 통해서 서로 상호 작용한다.

1. 액티비티(Activity)

• 안드로이드에서 화면을 관리하고 사용자가 발생시키는 다양한 이벤트를 처리하는 컴포넌트
• 안드로이드 어플리케이션은 반드시 하나 이상의 Activity를 가지고 있어야 합니다.
• 두개의 액티비티를 동시에 Display할 수 없습니다.
• 다른 어플리케이션의 액티비티도 불러낼 수 있습니다.
• 액티비티 내에는 프래그먼트(Fragment)를 추가하여 화면을 분할시킬 수 있습니다.

2. 서비스(Service)

• 화면에 존재하지 않고 백그라운드에서 실행되는 컴포넌트
• 서비스는 엄연히 메인 스레드에서 동작

1) 포그라운드 서비스
-알림을 표시해 놓고 사용자와 상호 작용하지 않아도 계속 실행되는 걸 말함

2) 백그라운드 서비스
-사용자가 직접 알지 못하는 작업을 수행할 때 사용

3) 바운드 서비스
-앱 내에서 서비스를 사용하여 간단한 클라이언트 - 서버 환경을 구성하는 것을 말함(특정 컴포넌트와 서비스간 상호작용)

3. 브로드캐스트 리시버(Broadcast Receiver)

• 단말기에서 발생하는 다양한 이벤트, 정보를 받고 반응하는 컴포넌트
• 디바이스에서 발생하는 일 중에서 어플리케이션이 알아야 하는 상황이 발생하면 알려줌
• 수신기를 통해 디바이스의 상황을 감지하고 적절한 작업을 수행
• 대부분 UI가 존재하지 않음

정적 리시버

-매니페스트에 등록하여 리시버를 구현하는 형태인데 한 번 등록하면 해제할 수 없는 방식이다.

동적 리시버

-클래스 파일에서 리시버를 등록, 해제할 수 있는 형태이기 때문에 앱에 부하를 줄 일 수 있다. 하지만 해제를 적절히 해주지 않는다면 메모리 릭이 발생할 수 있다.

4. 컨텐트 프로바이더 (Content Provider)

• 모든 app에서 접근하여 데이터를 저장하고 가져올 수 있도록 하는 컴포넌트
• 데이터를 관리하고 다른 어플리케이션 데이터를 제공해주는 컴포넌트
• 프로바이더는 데이터의 Read(읽기), Write(쓰기)에 대한 퍼미션이 있어야 애플리케이션에 접근이 가능

그래들(Gradle)

• 빌드 배포 도구

• 안드로이드 스튜디오는 코드의 편집만을 담당할 뿐, 빌드는 Gradle을 통해 모두 수행된다.(안드로이드 스튜디오와 빌드 시스템이 독립적)

SDK(Software Development Kit)

• 안드로이드 소프트웨어를 개발하기 위한 툴킷
• 안드로이드 API
• 안드로이드 응용프로그램 개발에 필요한 각종 도구들(컴파일러, 에뮬레이터 등)
• 샘플 코드
• 관련 문서

인텐트(Intent)

• 애플리케이션 컴포넌트(구성요소) 간에 작업 수행을 위한 정보를 전달하는 역할을 하며 통신수단

Activity 생명주기

onCreate() : 최초로 앱 실행 시 호출, 초기화 관련 작업
onStart() : 이 시점부터 사용자가 액티비티를 볼 수 있다.
onResume() : 액티비티가 실제 사용자와 상호작용이 가능한 포그라운드에 위치하면 호출된다, 액티비티 실행 중 상태

onPause() : 액티비티가 실행 중인 상태에서 사용자와 상호작용이 불가능한 상태, 즉 포커스를 잃은 상태가 되면 호출
onStop() : 액티비티가 더 이상 보이지 않을 때 호출
onDestroy() : 액티비티가 종료되거나 앱 프로세스 자체가 종료되면 호출

액티비티에서 액티비티로 이동할 때 LifeCycle 순서

1. 액티비티에서 문자가 왔을 경우(화면이 일부 가려졌을 때)

   -onCreate() ~ onResume() -> 문자옴 -> onPasue() -> 문자사라짐 -> onResume()

2. A 액티비티에서 B 액티비티로 이동

   -A onCreate() ~ onResume() -> 화면이동 클릭 -> A onPasue() -> B onCreate() ~ onResume() -> A onStop() .. onDestroy() (상황에 따라)

3. 액티비티에서 백그라운드로 갔다 다시 포그라운드로 복귀 시

   -onCreate() ~ onResume() -> 홈버튼(백그라운드) -> onPause() → onStop() -> 앱 복귀 -> onRestart() -> onStart() -> onResume()

Fragment 생명주기

• onAttach(Activity) -액티비티에서 프래그먼트가 호출될 때 최초 한번 호출되는 함수
  
• onCreate(Bundle) -프래그먼트가 생성될 떄 호출되는 함수
  
• onCreateView(LayoutInflater, ViewGroup, Bundle) -프래그먼트의 뷰를 생성하는 함수
  
• onActivityCreated(Bundle) -액티비티에서 onCreate()가 호출 된 프래그먼트에서 호출되는 함수
  
• onStart() -프래그먼트가 사용자한테 보여지기 직전 호출되는 함수
  
• onResume() -프래그먼트가 사용자와 상호작용할 수 있는 상태
  
• onPasue() -화면이 일부 가려졌을 때 호출
  
• onStop() -프래그먼트가 화면에 사라졌을 때 호출
  
• onDestroyView() -프래그먼트의 View가 사라질때 호출되는 함수
  
• onDestroy() -프래그먼트가 제거될 때 호출되는 함수
  
• onDetach() -프래그먼트가 액티비티와 연결이 종료될 때 호출되는 함수
  

FragmentManager

-프래그먼트를 추가, 삭제 또는 교체하고 백스택에 추가하는 등의 작업을 실행하는 클래스

-프래그먼트의 변경사항 집합을 트랜잭션이라고 한다.

FragmentTransaction

-각 트랜잭션은 수행하고자 하는 변경사항의 집합이다. 변경사항을 설정하려면 add(), remove(), replace()와 같은 메서드를 사용해야한다.

앱 배포 시

APK

일반적인 APK는 APK 파일 하나를 통해 많은 디바이스의 호환을 지원한다. 그렇다 보니 APK 자체에 여러개의 ABI(Android Binary Interface)를 포함하게 되며, APK 파일의 크기는 커질 수 밖에 없다.

AAB(Android App Bundle)

APK의 용량 문제를 해결하기 위해 개발
기존 통빌드(APK 하나로 전부 해결하는) 혹은 다중 APK를 통해 사용자에게 앱을 지원하는 방식을 사용했다면, 현재는 AAB를 통해 좀 더 경량화된 앱을 제공할 수 있다.

Context

• 안드로이드 시스템이 어플리케이션이나 컴포넌트 등을 관리하기 위한 것

Context가 없으면 액티비티를 시작할 수도, 브로드캐스트를 발생시킬 수도, 서비스를 시작할 수도 없다. 리소스에 접근할 떄도 Context를 통해서만 가능하다. Context는 여러 컴포넌트의 상위 클래스이다.

Context는 추상 클래스인데 메서드 구현이 거의 없고 상수 정의와 추상 메서드로 이루어진다. Context를 직접 상속한 것은 ContextWrapper이고 ContextWrapper를 상속한 것은

Activity, Service, Application이다. (BroadCastReceiver와 ContentProvider는 Context를 상속한 것이 아님)

Application Context(애플리케이션 컨텍스트)

• 애플리케이션 자체의 생명 주기(라이프사이클)에 영향을 받는다.
  싱글톤 객체로 존재한다.
• Activity에서 getApplicationContext라는 함수를 통해 접근할 수 있다.
• 애플리케이션 컨텍스트는 현재의 컨텍스트와 분리된 라이프사이클을 가진 컨텍스트가 필요할 때나 액티비티의 범위를 넘어서 컨텍스트를 전달할 때에 사용합니다.

Activity Context(액티비티 컨텍스트)

• 액티비티의 라이프사이클과 연결되어 있다.
• Activity에서 사용가능하다.
• 액티비티의 범위 내에서 컨텍스트를 전달하거나, 라이프사이클이 현재의 컨텍스트에 붙은 컨텍스트가 필요할 때(need the context whose lifecycle is attached to the current context) Activity 컨텍스트를 사용합니다.
• 예를 들어 Activity에서 사용되는 Dialog, Toast 등 UI 작업에 필요한 Context는 Activity Context를 사용하면 된다.

Activity vs Fragment

1. 액티비티는 독립적으로 활용할 수 있다.
2. 프래그먼트는 액티비티에 종속되어 있다.
3. 액티비티는 전체화면을 차지하지만 프래그먼트는 전체 화면이 아니여도 되며 디자인에 많은 유연성을 가지고 있다.
4. 액티비티는 자동적으로 스택에 넣어지고 프래그먼트는 트랜잭션을 통해서 요청해야 한다.

LayoutInflater

• XML에 정의된 Resource(자원)들을 View의 형태로 반환해 준다. 자바코드에서 View, ViewGroup을 사용하거나 Adapter의 getView() 등 배경화면이 될 Layout을 만들어 놓고 View 형태로 반환받아 Activity, Fragment에서 실행하게 된다.

Retrofit

• Retrofit은 REST API 통신을 위해 구현된 라이브러리이다. 백그라운드에서 실행되며 callback을 통해 메인스레드에서의 UI 업데이트를 간단하게 할 수 있도록 제공하고 있다.

안드로이드의 통신 라이브러리

초기에 안드로이드 통신은 HttpClient를 사용했다. HttpClient에는 몇 가지 버그가 있어서 HttpUrlConnection이 권장되고 나서 쭈욱 사용하다 복잡했던 사용법으로 인해 Volley라는 녀석이 나와 표준 라이브러리로 사용되었다. (Square의 OkHttp도 인기가 높고 많이 사용됨)

하지만 안드로이드 5.1에서 HttpClient가 Deprecated된 후, HttpClient에 의존하던 Volley도 Deprecated되었다. Square에서 만들어진 라이브러리인 OkHttp와 그 래퍼인 Retrofit은 하나의 선택처럼 필수?가 되어버렸다.

Retrofit을 사용해야 하는 이유는?

서버와 통신을 하려면 HTTP 통신을 해야한다. 기본적으로 HttpUrlConnection을 이용하면 매번 connection 설정 등 반복적인 작업이 발생한다. 이것을 도와주는 라이브러리가 OkHttp이다.

Retrofit의 장점은 속도, 편의성, 가독성이 있다. OkHttp는 사용시 대개 Asynctask를 통해 비동기로 실행하게 되는데 성능상 느리다는 이슈가 있었다. Retrofit은 Asynctask를 사용하지 않고 자체적인 비동기 실행과 스레드 관리를 통해 속도를 훨씬 빠르게 끌어 올렸다.

(Retrofit은 request, response 설정 등 반복적인 작업을 라이브러리에서 넘겨서 처리하므로 작업량이 줄어들고 사용하기 굉장히 편리하다)

String과 StringBuffer의 차이는?

1. String : 불변, 문자를 수정하려면 지우고 다시 생성(new) → 문자열 연산이 많으면 기능이 떨어짐
2. StringBuffer : 가변, 한번 만들고 필요할 떄 크기를 변경하여 문자를 변경(append()와 같이)
3. StringBuilder : 동기화 지원x, 멀티스레드 환경에 부적합 → 싱글 스레드에서 StringBuffer보다 좋음

View and ViewGroup

View

• 안드로이드 화면의 구성요소이다. 화면에 보이는 모든 것은 View 이다.
• View는 자신이 화면 어디에 배치되어야 하는지에 대한 정보가 없다. * * * View만으로 화면에 나타날 수 없다.
• View를 화면에 배치하기 위해서는 반드시 무언가가 필요하다.
• 그것이 바로 ViewGroup 혹은 View Container이다.

ViewGroup

• n개의 View를 담을 수 있는 Container이다. ViewGrop 또한 View를 상속받아 만든 클래스 또 다른 말로는 Layout이라고도 한다.

• ViewGroup은 View만 배치가능하며 ViewGroup조차 View로 다룬다.

그래서 자식 ViewGroup을 배치할 수 있다.

List View와 Recycler View의 차이

• 리스트뷰와 리사이클러뷰는 모두 스크롤 가능한 리스트 형식의 레이아웃을 구현할 때 사용.
• 리스트뷰는 스크롤할 때 나오는 아이템을 끊임없이 새로 만들어 메모리 성능에 부담이 갈 수 있음.
• 반면, 리사이클러뷰는 처음 만들어지는 아이템의 개수는 정해져있고, 뷰홀더를 통해 들어가는 뷰의 재사용을 가능하게 함.

ANR

• 키 이벤트인 볼륨, 메뉴, 백 키의 경우는 눌리고서 5초 이상 지연 시 바로 ANR을 발생

MVC 패턴

• 모델, 뷰, 컨트롤러로 이루어진 디자인 패턴

1) 모델: 애플리케이션의 데이터인 데이터베이스, 상수, 변수 등을 뜻한다.
뷰에서 데이터를 생성하거나 수정하면 컨트롤러를 통해 모델을 생성하거나 갱신한다.

2) 뷰: 사용자 인터페이스 요소. 모델을 기반으로 사용자가 볼수 있는 화면을 뜻함. 모델이 가지고 있는 정보를 따로 저장하지 않아야 하며 화면에 표시하는 정보만 가지고 있어야 함. 변경이 일어나면 컨트롤러에 이를 전달해야함

3) 하나 이상의 모델과 하나 이상의 뷰를 잇는 다리 역할을 하며 이벤트 등 메인 로직을 담당한다. 모델과 뷰의 생명주기도 관리하며, 모델이나 뷰의 변경 통지를 받으면 이를 해석하여 각각의 구성 요소에 해당 내용을 알려준다.

MVVM 패턴

MVC의 C에 해당하는 컨트롤러가 뷰모델로 바뀐 패턴

뷰모델은 뷰를 더 추상화 한 계층이며, MVVM 패턴은 MVC 패턴과는 다르게 커맨드와 데이터 바인딩을 가지는 것이 특징이다. 뷰와 뷰모델 사이의 양방향 데이터 바인딩을 지원하며 UI를 별도의 코드 수정 없이 재사용할 수 있고 단위테스팅하기 쉽다는 장점이 있음

MVC 와 MVVM의 차이점

MVC 패턴은 모델, 뷰, 컨트롤러로 이루어진 디자인 패턴.
앱의 구성 요소를 세 가지 역할로 구분하여 개발 프로세스에서 각각의 구성 요소에만 집중해서 개발할 수 있다는 점과 재사용성과 확장성이 용이하다는 장점이 있고, 애플리케이션이 복잡해 질수록 모데로가 뷰의 관계 또한 복잡해지는 단점이 있음 .

MVVM패턴은 컨트롤러가 뷰모델로 바뀐 패턴. 뷰모델은 뷰를 더 추상화 한 계층이며, 커맨드 바인딩을 가지는 것이 특징. 뷰와 뷰모델 사이의 양방향 데이터 바인딩을 지원하고 UI를 별도의 코드 수정 없이 재사용 할수 있고 단위 테스팅 하기 쉽다는 장점이 있다.

AAC

1.Lifecycles
Lifecycles는 라이브러리 이름 답게 생명주기 모니터링을 돕습니다. 크게 2가지로 구성되어 있습니다.

Lifecycle Owner

Activity,Fragment에서 생명주기를 분리하여 Lifecycle 객체에 담습니다.
Lifecycle 객체를 통해 다른 곳에서 해당 화면의 생명주기를 모니터링 할 수 있는데 자신의 생명주기를 담은 Lifecycle 객체가 Lifecycle Owner입니다.

Lifecycle Observer

생명주기를 Wrapping한 Lifecycle Owner 객체를 통해 화면 밖에서도 모니터링이 가능하지만, 생명주기에 따른 동작은 여전히 화면에서만 정의할 수 있습니다. 화면 밖에서도 생명주기에 따른 동작을 정의하기 위해서는 원하는 클래스에 LifecycleObserver 인터페이스를 구현하고 넘겨받은 Lifecycle Owner객체에 구현한 LifecycleObserver를 등록해야 합니다. Lifecycle Observer를 구현한 클래스는 onResume()등의 생명주기 메소드를 정의할 수 있습니다. 이 메소드들은 등록한 Lifecycle Owner가 해당 생명주기 상태가 되면 자동으로 수행되면서, 객체가 화면과 동일한 생명주기를 가진 것처럼 행동합니다.

2. LiveData
   LiveData는 Observable 형태로 사용하며, 안드로이드 Lifecycle에 따라 데이터를 관리합니다. Activity, Fragment의 라이프 사이클을 따르기에 활동에 대한 처리를 알아서 관리해줍니다.

Android 공식문서에서는 다음과 같은 장점을 확인할 수 있습니다.

LiveData는 observable 패턴을 사용하기에 데이터의 변화를 구독한 곳으로 통지하고, 업데이트 한다.

메모리 누수 없는 사용을 보장한다.

Lifecycle에 따라 LiveData의 이벤트를 제어한다.

항상 최신 데이터를 유지한다.

기기 회전이 일어나도 최신데이터를 처리할 수 있도록 도와준다. (AAC-ViewModel과 함께 사용시)

LiveData의 확장을 지원한다.

3. ViewModel
   수명주기를 고려하여 UI관련 데이터를 저장하고 관리하도록 설계되었습니다. ViewModel 클래스를 사용하면 화면전환과 같이 구성을 변경할 때도 데이터를 보존할 수 있습니다.

AAC ViewModel이 데이터의 보존이 가능한 이유로는 ViewModel이 Activity의 경우 LifecycleEventObserver()로 Fragment에서는 FragmentStateManager로 View의 Lifecycle을 관찰하다 View가 종료되었을 때 Clear()를 하기때문에 종료가 되지 전까지 데이터가 보존되는 것입니다.
4. Room
SQLite 개체 매핑 라이브러리 입니다. Room을 사용하여 사용구 코드를 피하고 SQLite 테이블 데이터를 자바 객체로 쉽게 변환할 수 있습니다. Room은 SQLite 문의 컴파일 시간 확인을 제공하며 RxJavam, Flowable, LiveData, Observable을 반환할 수 있습니다.

Room의 구성요소
데이터베이스 : 데이터베이스는 앱에 저장되어 있는 로컬 데이터에 대한 액세스 포인트를 제공해주는 역할
DAO(Data Access Object) : DAO는 앱에서 데이터베이스의 데이터를 추가, 삭제, 업데이트 작업을 할 수 있는 메소드를 제공해주는 역할, 그 외에도 다양한 쿼리 사용가능
Entity : 데이터베이스 내에 존재하는 테이블을 가리킵니다.
5. Paging
페이징 라이브러리를 사용하면 로컬 저장소에서나 네트워크 를 통해 대규모 데이터세트의 데이터 페이지를 로드하고 표시할 수 있습니다. 이 방식을 사용하면 앱에서 네트워크 대역폭과 시스템 리소스를 모두 더 효율적으로 사용할 수 있습니다.

6. Databinding
   선언형 형식으로 Data를 UI에 쉽게 Binding하기 쉽게 해주며 findViewById에 의한 객체 획득 번거로움을 제거해주는 라이브러리 입니다.

7. Navigation
   사용자가 앱 내의 여러 콘텐츠를 Navigation(탐색)하고 그곳에 들어갔다 나올 수 있게 하는 상호작용을 의미합니다.
   또한 View의 흐름을 직관적으로 보여주기 때문에 앱의 동작흐름을 파악하는데도 도움이 됩니다.

8. WorkManager
   WorkManager는 지속적인 작업에 권장되는 솔루션입니다. 앱이 다시 시작하거나 시스템이 재부팅될 때 작업이 예약된 채로 남아있으면 그 작업은 유지됩니다. 대부분의 백그라운드 처리는 지속적인 작업을 통해 가장 잘 처리되므로 WorkManager는 백그라운드 처리에 권장하는 기본 API입니다.

RXJava

• Reactive Extensions의 JVM 구현체
• 상태 변화를 관찰하고 있다가 능동적으로 동작하는 프로그램을 작성할 수 있게 해줌 → 반응형 프로그래밍
• 복잡한 비동기 에러 처리를 간단히 처리할 수 있게 해줌
• 다양한 플랫폼과 언어를 지원함 → 크로스 플랫폼

[출처: https://velog.io/@bye9/%EC%95%88%EB%93%9C%EB%A1%9C%EC%9D%B4%EB%93%9C-%EA%B8%B0%EB%B3%B8%EA%B0%9C%EB%85%90#1-activity%EC%95%A1%ED%8B%B0%EB%B9%84%ED%8B%B0]