🤓 2021~ 안드로이드 취직 대비 공부 기록터 📖

[공부할거야! 시리즈 모음]

사용자가 앱을 탐색하고, 나가고, 다시 들어올 때 등등의 상태 변화에 따라서 이를 앱에서 알아차릴 수 있게 제공하는 Callback.

1. onCreate : Activity가 최초 생성되고, 필요한 작업의 초기화를 수행하기 위해 호출됨

만약 A - > B 갔다가 다시 B -> A 로 이전 stack으로 돌아오는 activity일 경우, onCreate 대신 onRestart가 호출됨

2. onStart : Activity가 보여지기 위한 모든 작업들의 초기화(onCreate)가 끝났고, 상호작용 하기 전에 호출됨
3. onResume : Activity가 사용자와 상호작용이 시작됐을 때 호출됨
4. onPause : 다른 Activity가 보여져서 현재의 Activity가 가려졌을 때(보이지 않을 때) 호출됨
5. onStop : Activity가 더 이상 보여지지 않을 떄 호출됨

이는 메모리가 부족하여 종료될 시에는 호출되지 않을 수 있음
또한 이는 다른 Activity들의 생명주기 작업이 끝나야 호출됨
마지막으로 이 상태에서 onSaveInstanceState()가 호출됨

6. onDestroy : 시스템 리소스 자원(CPU, 메모리 등등)이 부족해져 앱이 종료되거나, finish() 코드를 실행했을 때 호출됨

현재 Activity 밖에서 실행되는 것

현재 Activity 안에서 다른 작업과 동시에 뒤에서 실행되는 것

onPause 상태가 됨

onStart 호출 전에, 가려진 Activity가 다시 보여질 때 호출됨

1. onCreate: 다른 클래스들이 실행되기 전에 제일 먼저 호출됨
2. onLowMemory: 안드로이드의 메모리가 부족할 때 호출됨
3. onTrimMemory: 앱이 잘 실행되고 있는데, 안드로이드가 메모리가 부족하여 필요없는 메모리의 정리가 필요할 때 호출됨
4. onTerminuate: 안드로이드 에뮬레이터 환경에서만 실행되며, 에뮬레이터가 꺼졌을 때 호출됨
5. onConfigurationChanged: 안드로이드 구성요소가 변경되었을 때 호출됨

1. onAttachedToWindow : View가 Window에 연결되면 호출됨

Drawing할 표면을 알고있는 단계 -> listener 설정 가능

2. measure
3. onMeasure : View의 Size를 확인하기 위해 호출됨

ViewGroup일 경우 계속해서 Child View에 대한 Size 측정을 하고, 그에 대한 결과로 자신의 Size를 결정

4. layout
5. onLayout : View의 Size를 측정하여 position 설정 후 호출됨
6. dispatchToDraw
7. draw
8. onDraw : View가 그려질 준비가 되었을 때 호출됨

onDraw는 여러번 호출되므로, 여기서는 객체를 만들면 안됨
Canvas는 무엇을 그릴지를 담당하고, Paint는 어떻게 그릴지를 담당함

View가 Window에서 분리될 때 호출됨

더 이상 Drawing할 View가 없음을 알림 -> 모든 작업들을 정리해야 하는 시기

View 전개가 끝난 후 호출됨

Layout일 경우, 모든 Child View가 추가 된 후에 호출됨

MeasureSpec은 parent에서 child으로 전달되는 Layout들의 요구 사항을 캡출화함

Parent View가 Child View의 정확한 Size를 결정함.

Child View의 Size에 관계없이 무조건 정해진 Size로 설정함

Child View는 지정된 Size까지의 원하는 만큼 Size를 정할 수 있음

Parent View가 Child View의 Size에 대해 제한을 두지 않음

Child View는 원하는 만큼의 Size를 정할 수 있음

measure부터 Layout을 재호출

dispatchToDraw()부터 Layout을 재호출

1. onAttach : Fragment가 Activity에 attach될 때

argument로 Context가 들어옴

2. onCreate : Fragment가 생성될 때 호출되며 사용자 interface 초기화에 사용됨

UI 초기화는 할 수 없음

3. onCreateView : Layout을 inflate하는 곳

UI 초기화를 할 수 있음

4. onActivityCreated : Activity의 Fragment의 View가 모두 생성된 상태

UI 변경 작업을 하는 곳

5. onStart : Fragment가 보여지기 바로 전에 호출됨
6. onResume : Fragment가 사용자와 상호 작용하기 바로 전에 호출됨
7. onPause : 다른 Activity가 보여질 때 호출됨

Fragment의 Parent Activity가 아닌 다른 Activity가 ForeGround로 나오게 될 때 호출됨
또한 BackStack으로 들어감

8. onStop : 다른 Activity가 화면을 완전히 가림
9. onDestroyView : Fragment와 관련된 View들이 제거될 때 호출됨
10. onDestroy : Fragment가 소멸될 때 호출됨
11. onDetach : Fragment가 Activity로 부터 해제되어질 때

Inflate를 최소화 하기 위해서 View들의 각 요소에 바로 접근할 수 있게 저장해두고 사용하기 위한 객체

ListView는 ViewHolder 사용이 선택임

1. getView 에서 convertView가 null 일 때만 최초 한 번 inflate하고 ViewHolder룰 생성해 각 요소를 findViewById로 연결시켜 저장하고 convertView에 tag로 저장시킴
2. 그리고 다음부터는 ViewHolder를 convertView의 tag로 불러와서 재사용함

ListView와는 달리, RecyclerView는 ViewHolder의 사용이 필수임

1. createViewHolder에서 새로운 View를 생성함과 동시에 ViewHolder를 만들고 return함
2. onBindViewHolder에서 paramater로 제공받은 ViewHolder의 value를 변경함

Stack 형식으로 차곡차곡 쌓이는 Activity들의 집합

만약 이 task에 쌓이지 않게 activity를 만들고 싶다면, manifest에 다음과 같이 추가하면 된다.

android:excludeFromRecents="true"

Activity 실행 시 신규 task에 만들 경우, 지정할 task의 이름
이때 Custom Affinity의 이름에는 최소 한 개 이상의 .가 들어가야 한다.

Component(Activity, Service, Broadcast Receiver)간에 통신을 하기 위한 메시지

1. Explicit Intent : 시작할 component의 class-name을 지정

명시적 인텐드
일반적으로 본인이 만든 component를 실행할 때 사용

EX) Intent(context, MainActivity::class.java)

2. Implicit Intent : 특정 component의 class-name 없이 어떠한 작업을 수행할지만 선언함

암시적 인텐드
해당 Intent를 처리할 수 있는 component를 system이 필터링하여 수행하거나, 사용자에게 선택하도록 함

EX) 클릭

이 데이터가 어떤 형식의 데이터인지 설명하는 명칭

더 많은 정보) [방문]

다른 Process(Application)에서 권한을 허가하여 가지고 있는 Intent를 본인 Process에서 실행하는 것 처럼 해주는 것

EX) Notification으로 작업을 수행할 때 PendingIntent를 사용한다.
Notification은 NotifcationManager라는 다른 process에서 실행되기 때문.

함수의 호출 방식

함수에 값을 복사해서 전달하는 방식

함수의 인자로 전달되는 변수를 함수의 매개변수로 복사해서 실행함.
즉, 함수에 사용되는 매개변수들은 별도의 scope를 가지며 함수의 매개변수를 바꿔도 함수로 전달한 원래 변수의 값은 바뀌지 않음.

함수에 값의 주소값을 전달하는 방식

함수에 인자로 전될되는 변수를 변수의 주소값으로 바꿔서 함수의 매개변수로 전달함.
즉, 함수로 전달되는 매개변수들과 원래의 변수들과 동일 scope를 가져서 함수의 매개변수 값이 바뀌면 원래 변수의 값도 바뀜.

전달되는 객체에 따라 참조방식이 결정되는 방식

Mutable Object는 CbR을 따르고, Immutable Object는 CbV를 따른다.

Call by Value를 따릅니다.

1. Boolean Type
    * boolean
   
2. Numeric Type
    2-1. Integral Type
       * Integer Type : short, int, long
       * Floating Type : float, double
    2-2. Character Type : char
   

자료형의 길이가 항상 고정적임
비객체 타입 -> 즉 null을 가질 수 없음.

1. Class Type
    * String Class
    * Wrapper Class
       * void의 Wrapper Class는 Void
   
2. Interface Type
   
3. Array Type
   
4. Enum Type
   
5. etc...
   

기본적으로 Object를 상속받으면 Reference Type이 됨
또한 선언한 자료형이 Primitive Type이 아니면 Reference Type이 됨

기본적으로 immutable(불변)이다.
즉, 값이 바뀌게 되면 새로운 메모리영역을 가르키는 새로운 변수를 만든다.
값이 바뀌기 전 이전 변수는 Garbage로 남아있다가 GC(Garbage Collection)에 의해 사라지게 된다.
그리고 쓰레드 동기화가 가능하다.

문자열 연산이 적고 멀티쓰레드일 경우 사용

기본적으로 mutable이다.
그리고 쓰레드 동기화가 가능하다.

문자열 연산이 많고 멀티쓰레드 환경일 경우 사용

기본적으로 mutable이다.
그리고 쓰레드 동기화가 불가능하다.

문자열 연산이 많고 단일쓰레드 이거나, 동기화를 고려하지 않는 환경일 때 사용

안드로이드 4대 컴포너트는 Intent 속성에 포함된다.

Manifest(매니페스트)는 Application에 대한 각종 정보를 기록하는 파일이다.

XML에 정의되있는 View를 실제 View 객체로 만드는 역할을 수행한다.

ByteCode -> interpret -> 각 OS에 맞는 기계어로 번역 -> 실행

장점 : OS에 구애받지 않고, 해당 OS에 맞는 기계어로 번역됨
단점 : Native언어들에 비해 속도가 느림

dex-file을 Dalvik Machine 위에 올리는 방식

ByteCode -> interpret -> 실행 -> Native코드로 변환(JIT-compile)
License 문제로 JVM 대신 Java코드를 이용할 수 있게 개발됨

장점 : OS에 구애받지 않고, 해당 OS에 맞는 기계어로 번역됨
단점 : 성능과 배터리에 안좋음, JIT-compile된 코드가 메모리에 올라가 메모리 사용량이 높음

실행시점에 소스코드를 번역함
따라서 설치는 빠르지만, 실행시점에 느리게 됨
또한 번역한 정보를 메모리에 올려야 하기 때문에 실행 시 메모리를 많이 먹음

Machine 위에서 OAT-file을 돌리는 방식
VM이 아닌 runtime시 사용됨

앱을 설치할 때 완전히 native코드로 변환되어 설치됨(AOT-compile)

장점 : 코드 interpret 및 JIT-compile을 제거하여 성능이 향상됨
단점 : 설치시점에 코드를 번역하여 설치가 느리고, 파일을 따로 저장하기 때문에 용량이 커짐

설치시점에 소스코드를 번역함
따라서 설치는 느리고, 번역된 소스코드를 따로 파일로 저장하기 때문애 용량을 많이 먹음
하지만 실행시점에 미리 번역한 파일을 실행하므로 실행속도는 빠름

DVM 사용

DVM에서 ART로 컴파일 방식을 바꾸기 시작함

Dalvik에서 돌아가는 앱들이 ART에서 죽는 현상이 발생함

ART가 기본 runtime이 됨

AOT-compile 방식과 JIT-compile 방식을 조합해서 사용하기 시작함

ART-compile 방식의 많은 개선이 이뤄져 많은 문제들 해결

Flowable은 Backpressure Buffer가 기본적으로 내장되어 있지만, Observable은 Backpressure Buffer가 기본적으로 내장되어있지 않다. (따라서 직접 추가해서 등록해줘야 한다)

소비되는 데이터에 비해 생산되는 데이터의 양이 너무 많을 경우 OutOfMemory 같은 exception이 발생 할 수 있기 때문에, 생산되는 데이터의 양을 소비되는 데이터의 양에 비례해서 조절해주는 역할을 해 준다.

Representational State Transfer

자원의 이름으로 구분하여 해당 정보를 주고 받는 모든 것
웹의 장점을 최대한 활용할 수 있는 아키텍처 스타일

Create : 생성 (POST)
Read : 조회 (GET)
Update : 수정 (PUT)
Delete : 삭제 (DELETE)

장점 : Server와 Client의 역할을 명확하게 구분한다.
단점 : REST는 설계 가이드일 뿐이라, 표준이 존재하지 않는다.

REST 기반으로 서비스 API를 구현한 것

Application Programming Interface

데이터와 기능의 집합을 제공하여 컴퓨터 프로그램간 상호작용을 촉진하며, 서로 정보를 교환 가능 하도록 해주는 것

• 도큐먼트 : 객체 인스턴스와 비슷한 개념
• 컬렉션 : 서버에서 관리하는 디텍터리 저장소
• 스토어 : 클라이언트에서 관리하는 리소스 저장소

1. URI의 정보는 자원을 표현해야 한다.
   
2. 자원에 대한 행위는 CRUD Operation으로 표현한다.
   
3. /는 계층 관계를 나타내는데 사용한다.
   
4. URI 마지막 문자로 /를 포함하지 않는다.
   
5. 파일 확장자는 URI에 포함시키지 않는다.
   
6. _는 URI에 사용하지 않는다.
   

REST 원리를 따르는 시스템

전체 주소

EX) https://test.com/test.pdf?index=5

파일의 위치(구분자)를 표시하는 주소

EX) https://test.com/test.pdf?index=5

https://test.com/test.pdf?index=5
https://test.com/test.pdf?index=15

위와 같은 주소는 같은 URL을 가지지만 URI는 서로 다름

URL은 URI 안에 있음

실행중에 있는 프로그램
프로그램을 실행하면, 실행하기 위해서 메모리 할당이 이루어지고, 할당된 메모리 공긴으로 바이너리 코드가 올라간다. 이 순간부터 process라고 불린다.

1. Code 영역 : 프로그램을 실행시키는 소스코드들이 올라간다.
   
2. Data 영역 : 전역변수, static 변수들이 할당된다.
   
3. Heap 영역 : 동적할당을 위한 메모리 영역이다.
   
4. Stack 영역 : 지역변수와 인자들을 위한 메모리 영역이다.
   

Process의 CPU 할당 순서 및 방법을 결정하는 일

Process 내부의 작업 단위

1. Thread는 한 process에서 최소 하나 이상 존재한다.
   
2. Multi-Thread에서 각 thread끼리는 서로 process의 메모리 영역을 공유한다.

Thread가 하나의 process안에서 여러개가 존재하는걸 Multi-Thread라고 한다.

Thread를 미리 만들어놓는것

서로 다른 thread간의 통신을 위한 장치

MessageQueue로부터 message를 꺼내와서 해당 message와 연결된 handler를 호출하는 역할을 함

Message를 Queue 형태로 저장하여 관리하는 객체이다.

FIFO(First In First Out) 방식으로 동작하기 때문에, message는 queue에 들어온 순서에 따라 차례대로 저장됨

그리고 가장 먼저 들어온 message 객체부터 차례대로 처리됨

Thread로 전달할 데이터를 한 곳에 저장할 객체이다.

필요한 데이터를 받거나 쓰기 위해 데이터 형태를 설정해 주는 역할을 함

Primitive Type에 대한 클래스 표현이라고 할 수 있다.

View.post()는 handler와는 달리 View가 attach 되지 않으면 post된 모든 runnable들을 View가 attach 될 때 까지 연기한다.

// TODO

Singleton을 이용하거나 intent를 사용한다.

1. 어플리케이션이 설치되는 순간 firebase 서버에 key 휙득을 위한 요청을 보냄
   
2. Firebase 서버에서 key를 만들어서 어플리케이션으로 전달함
   
3. 어플리케이션으로 전달된 key를 google server에 전송함
   
4. Google server에서 이 key를 database에 저장함
   

1. Google server에서 어플리케이션으로 데이터를 전달하기 위해 key를 얻음
   
2. Key와 데이터를 firebase server로 보냄 (http 통신이 이용됨)
   
3. Firebase server에서 받은 key로 어떤 어플리케이션인지 구분 후, 데이터를 notification으로 호출함
   

Application Binary Interface

Runtime에 시스템과 앱의 머신코드가 어떻게 상호작용할지를 기술한 인터페이스.

2009년 : Android 발표, HttpClient, 아파치의 DefaultHttpClient 사용
2011년 : Google Developer 블로그에서 HttpUrlConnection 사용 권장
이후 : Volley나 OkHttp의 등장으로 HTTP 통신이 쉬워짐
2014년 : HttpClient가 Deprecated되면서 이를 베이스로 하는 Volley도 같이 Deprecated됨
이후 : OkHttp와 그 wrapper인 Retrofit이 등장하여 인기를 가짐

Client 부분과 Callback 형식들을 플러그로 설정 할 수 있기 때문

새로 생성된 객체에서 지금 어떤 일이 일어나고 있는지 알 수 있게 해줌
또한 resource, database, preferences 등에 접근을 제공해줌

Context는 기본적으로 gc에 의해 수집되지 않음

Singleton-instance 이며, application life-cycle과 연결되어 있음

현재의 context와 분리된 life-cycle을 가진 context나, activity의 범위를 넘어서 context를 전달할 때 사용함

Activity에서 사용가능하며, activity life-cycle과 연결되어 있음

Activity 범위 내에서 context를 전달하거나 lifecycle이 현재의 context에 붙은 context가 필요할 때 사용함

activity context를 반환한다.

View.getContext()와 같은 역할을 한다.

application context를 반환한다.

자신의 context가 아닌 다른 context에 접근할 때 사용된다.
Context를 생성할 때 만들어지는 context들의 기본 context를 반환한다.

이미지를 확대하여 보여주는 기능을 구현할 때 이미지 파일을 drawable에 넣으면 이미지 자체가 확대되서 이미지가 손상되지만, 이미지 파일을 mipmap에 넣어주게 되면 확대됐을때 적당한 크기를 가지는 이미지 파일을 보여준다.

대부분의 operator의 기본값

Stream의 전과 후를 연결만 시켜준다.
Observer가 등록되야 작동을 시작한다.

Stream에서 값을 계속 발생시킨다.
Observer가 등록되있지 않아도 작동된다.

비동기로 동작하면서 여러가지의 값을 반환하는 Coroutines Builder 이다.

[stackoverflow]
추후 정리 예정

기존 Android 지원 라이브러리의 성능을 크게 개선시킨 것
support라이브러리와 AppCompoat 라이브러리들이 androidx로 하나로 합쳐졌다.
AndroidX 패키지는 기존 Android 지원 라이브러리의 동일한 기능을 제공하여 기존 라이브러리를 완전히 대체한다.