안드로이드 개발을 하다보면 운영체제에 대한 궁금증이 계속 생기는 것 같다.
ART는 뭔지, 시스템 서비스는 뭔지, 결국 컴퓨터라는 물리적 구조체가 어떻게 어떤 원리로 동작하는지 궁금해지는 것 같다.
뭐든, 원리를 밑바닥까지 파는 걸 좋아하는 성향이라 공부를 하다보면 자꾸 넓게가 아니라 깊게 가게 된다.
어쩔 수 없는 성향이라 치고, 평소에 궁금했던 OS와 ART를 좀 깊게 파보려고 한다.
머리도 식힐 겸 정리를 좀 해야겠다고 생각했다.
private lateinit var auth: FirebaseAuth
<*> 파이어베이스는 내부적으로 SharedPreference를 사용해서 인증 정보를 저장한다. 이게 문제가 될 수 있다. 어떤 상황이였냐면 파이어베이스 에뮬레이터를 껐었는데도 앱은 여전히 자동 로그인을 처리하고 있었다. 자동 로그인이 사실 되지 않아야 한다. 서버가 지워졌으니까. 그런데 로컬에서 null이 아니여서 (이전에 저장된 사용자 정보가 있어서) 자동 로그인되게 처리되고 있었다. 현업에서 이럴 일은 없겠지만, 여하튼 로컬의 정보와 서버의 정보를 어떻게 비교하고 관리할 것인지는 여전히 생각해보아야 한다.
사실 시작은 여기였다. 이 단 한 줄의 코드를 이해하려고 엄청나게 많은 서치를 했다.
정리 좀 하자. 는 생각에 머리 식힐 겸 글을 쓰고 있다.
알아낸 사실은 다음과 같다.
결국 저 코드는 네트워크 통신을 하는 코드다.
파이어베이스라는 서비스를 사용하기 위해서는 당연히 네트워크 통신을 해야 한다.
서버 기능을 구현하기 위해서 파이어베이스 서비스를 이용하는 것이니까.
나는 어떻게 저 코드가 구체적으로 동작하는 지가 궁금했다.
머리 속이 복잡하다.
결국 코드라는 건 apk 파일이라는 형태로 플레이 스토어에 올라간다.
그리고 안드로이드 폰을 이용하는 유저들이 그 파일을 다운받게 된다.
사용자 입장에서는 결국 안드로이드 OS 그리고 ART를 사용해서 apk 파일에 뭔가 작용을 하는 구조다.
결론적으로 저 코드 하나의 동작을 이해하기 위해서는 안드로이드 OS와 ART 그리고 apk 파일에 대해서 알아야할 필요가 있다.
apk파일을 만드는 과정을 빌드라고 부르는 것 같다.
쉽게 얘기하면 내가 키보드로 친 내 코드들 -> apk 파일 이 과정을 빌드라고 부르는 것 같다.
빌드는 결국 어떤 프로그램의 작용이다.
그 어떤 프로그램이 Gradle인 것 같다. 내가 듣기로는 Gradle도 결국 자바로 만들어진 프로그램이라고 하더라.
Gradle에는 플러그인이라는 시스템이 있다.
Gradle은 조립을 할 수가 있다. 필요한 기능을 끼워서 자기만의 Gradle을 만들 수 있는 셈이다.
그리고 어떤 조각을 사용할지를 우리는 build.gradle 파일에 정의한다.
안드로이드 스튜디오라는 프로그램이 그 build.gradle 파일들을 gradle에 전해주는 것 같다.
-> 명확히 조사해봤더니 다음의 사실이 조사되었다.
01 안드로이드 스튜디오는 gradle을 설치한다.
02 gradle task라는 걸 백그라운드에서 실행시킨다. -> 앱을 빌드할 수 있고 실행시킬 수 있는 건 다 안드로이드 스튜디오 덕분임.
정확히 따지면 안드로이드 스튜디오는 gradle을 도와주는 역할이고, 실재적인 실행은 gradle이 하는 것 같다.
auth = Firebase.auth
이 코드가 실행될 때 벌어지는 일은
FirebaseAuth 인스턴스가 생성되거나 반환되는 것이다.
저 인스턴스는 싱글톤으로 생성되고, 생성하는 역할은 당연히 gradle에 정의된 firebase의존성 중 하나에 포함되어 있는 코드가 런타임에 생성한다.
이건 결국 gradle의 플러그인 중 하나가 프로젝트에 포함된 json 파일을 기반으로 리소스와 클래스들을 만들고,
firebase의존성에 포함된 코드가 런타임에 그 클래스들을 사용한 결과다.
저 인스턴스 자체가 json 파일에 저장된 정보들을 담고 있는 것이다.
google-services.json 파일 안에는 다음과 같은 정보가 있어:
- project_id: 어떤 Firebase 프로젝트인지
- mobilesdk_app_id: 이 앱이 Firebase에 등록된 고유 ID
- api_key: 이 앱이 Firebase 서버와 통신할 때 사용할 키
- firebase_url, storage_bucket: 사용할 서비스들의 엔드포인트 주소들
그렇단다.
결국 저 인스턴스 자체는 firebase에 등록된 id를 알고 있고 통신할 키도 있고 서비스들의 엔드포인트 주소들도 알고 있다는 것이다.
내가 이해한 바로는 이렇다.
로그인이라는 건 token을 서버로부터 받아오는 일이다.
이 token은 서비스를 이용해야할 때 반드시 있어야 하고 파이어베이스 sdk는 이걸 sharedPreferences로 로컬로 관리한다.
token에는 여러가지 정보가 담겨있는데, 만료 여부와 uid 같은 것들이 있다.
token은 한마디로 서비스를 사용해도 괜찮다는 증명서다.
서버 입장에서는 부적합한 사용자를 구분할 수 있고 서비스 이용을 허락할 수도, 거부할 수도 있게 된다.
refresh token이라는 것도 token을 받을 때 같이 받게 되는데,
이건 똑같이 증명서인데, token을 재발급받기 위해서 필요한 특별한 증명서다.
refresh token으로 token을 받아올 때도 refresh token을 또 발급받게 되는데
이는 sdk에서 내부적으로 비동기적으로 처리한다고 한다.
//
번외로 Context라는 것에 대해서 조금 더 생각해보았다.
갑자기 궁금해졌다. Context는 누가 만드는 걸까?
검색을 해보니 운영체제가 만든단다.
나는 ART나 운영체제 둘 중 하나가 Context를 만들 것이라고 예상했었다.
찾아보니까 ART는 구체적인 객체 생성 로직을 갖고 있지 않다고 한다.
결국 객체를 만드는 건 운영체제가 한다는 얘기다.
그럼 ART는 뭘까?
ART 자체는 코드의 로직을 해석하거나 실행한다고 한다.
계속 궁금증이 생기는 것 같다.
Android 프레임워크라는 말과 운영체제는 어떻게 다른지.
Zygote 프로세스란게 도대체 뭔지.
결국 context라는 객체는 운영체제가 만드는 것이고
앱의 실행 환경을 담은 객체다. 운영체제가 앱을 식별하고 관리하는 데 필요한 정보를 담아둔 객체란 뜻이다.
패키지 이름, 앱의 리소스 접근 경로, 파일 시스템 경로, 프로세스 UID, 테마와 스타일, 시스템 서비스 접근 기능 등이 context 객체 안에 있다.
그럼 뭘 보고 context를 만드나? 운영체제는 뭘 기반으로 저걸 만들지를 생각해보면 결국 ART와 apk 파일로 돌아가게 된다.
운영체제는 apk파일을 재료로 art라는 도구를 사용해서 context를 만들어낸다.
art도 결국 소프트웨어고 c++로 만들어졌다.
"ART는 안드로이드 운영체제 내부에 존재하는 앱 실행 전용 소프트웨어 컴포넌트다."
듣자하니 리눅스 커널이라는 것 위에 시스템 소프트웨어들이 작동하는 방식인 것 같다.
art는 프로세스일까?
결론부터 얘기하면 아니다. art는 라이브러리이다.
라이브러리는 정적인 코드 모음이고.
앱 프로세스가 art를 사용할 뿐이다.
Art 자체는 스스로 실행되지 않는다고 한다.
앱 프로세스가 호출할 뿐.
시스템 서버도 하나의 프로세스로 동작하고 시스템 서버 안에 있는 AMS, PMS 같은 것들은 객체다.
이들은 Binder 인터페이스로 접근이 가능한 객체들이다.
HAL도 결국 ART와 같은 정적 소스 모음이다.
다만 실행 주체인 프로세스가 앱이 아니라 시스템 서버다.
Binder는 조금 더 전체적인 개념인 것 같다.
오늘은 여기까지.
아직 모르는 것이 너무 많다.
아는 분은 댓글 달아주세요 ㅎㅎ.