Android2011.03.06 10:00
크리에이티브 커먼즈 라이선스
Creative Commons License

지난 글에서 init process 에 대해서 정리를 하였다.
처음 시작이었던 booting process 에서 간략히 여러 부분에 대해 적었으며,
init process 에서 init process 가 하는 역할 그리고 중요한 init.rc 에 대해 적었다.

사실 처음 이 쪽 공부에 관심을 갖게 된 이유가 zygote process 때문이었다.
자주 가는 스마트폰 커뮤니티 인 맛클에서 zygote 라는 것이 있다는 것을 알았으며, zygote 가
무엇인지를 그 커뮤니티 안에서 찾아보려 했으나 그 쪽으로는 글이 전무하였다.
그래서 구글링을 통해서 간략히 어떠한 역할을 하는것인지를 알게되었고, 그 관심이 좀 더 커져서
지금처럼 블로그에 안드로이드에 대해서 글을 쓰게 된것이다.

처음에 kernel build 에 관심이 있어서 kenel 에 관한 강좌를 보고 따라하며 zImage 를 추출하는 것까지는
하였으나, 그 이후 좀 더 근본적인 부분에 대한 궁금증이 생겨서 그 쪽 관련한 실제적인 적용 및 결과물 도출은
하고있지 않은 상태이다. 그 쪽으로 계속 관심을 가지고 있었던 사람들은 지금 kernel 을 짜집기하여 본인이
원하는 performance 를 만들어 내고, 순정 kenel 에 init.rc 를 수정하고 원하는 file 을 설치하는 등
한 단계씩 앞으로 나가는것 같다. 빨리 결과물을 만들어 내고 나만의 custom kernel 을 만든다던지,
application 을 만들어 보고 싶은 욕구가 강하지만... 지금은 참고 있다.
하고 있는 이론이나 구조에 대한 공부를 더 완벽히 한 후 실습적인 부분에 착수를 할 생각이다.

*. JNI (java native interface)
여러번 앞서 적었던 글에 적었듯이 안드로이드의 platform 은 java 로만 구성되어 있는것이 아니다.
java 와 C/C++ 기반 module 이 계층별로 구성되어 있다. 하나의 application 을 구동하기 위해서는 java 와 C/C++ 간의
정보 교환
이 필요하다. 간단히 GPS 를 예로 들면, GPS 정보를 요구하는 application 의 경우 이 application 은 java 로
짜여져 있다. 하지만 직접적으로 GPS 정보를 구할 수 있는것이 아니다. 이 application 은 application framework 의
location manager 가 제공하는 java API 를 호출해서 GPS 정보를 얻을 수 있게 되는 것이다. API 의 호출은 framework 
내부의 GPS library 를 통해 GPS device driver 에 연결된다. 그렇기 때문에 java 와 C/C++ layer 간에 서로 통신을
가능하게 만들어 주는 무엇인가가 필요하게 된다. 이 때 나오는 개념이 JNI 이다.
즉, java layer 와 C/C++ layer 를 상호 연결하여 정보 교환이 가능하도록 만들어 주는 매개체가 JNI 라는 것이다.
일반적으로 우리가 마켓에서 다운을 받아 사용하는 application 은 android SDK 를 토대로 만들어져 있으며, 이러한
application 은 모두 Dalvik Virtual Machine 위에서 동작하는 java 기반의 program 이다. 일반적으로 java 기반의 program 은
C/C++ 과 같은 native language 로 짜여진 program 보다 처리 속도 등이 느린 단점을 내포하고 있다고 한다. 그래서 
일반적이고 공통적으로 사용할 수 있는 driver 등은 모두 nitive language 인 C/C++ 로 짜여져 있으며, API 호출을 통하여
java 기반의 application 에서 사용할 수 있도록 만들어 놓은 것이다.
관련 서적에서는 JNI, NDK 에 대해 아주 상세히 적어 놓았다. source code 를 모두 분석해 놓았으며, java 에서 C library 함수를
호출하여 사용하는 방법까지 기술해 놓았다. 하지만 아직 이쪽으로 지식이 충분하지 못해 완벽히 이해하긴 힘들다.
그래서 이번 글에서는 JNI 의 개념에 대해서만 적는다. 나중에 source code 분석에 익숙해 지고, SDK 로 java 기반의 
application 을 간단히나마 짤 수 있을 정도가 되면 그때 글을 업데이트 하던 새로운 글을 적을 생각이다. 

*. zygote process
가장 스마트 폰에 대한 기술적인 부분을 다루는 커뮤니티 에서도 기재되어 있는 상세한 내용의 zygote 의 개념을 찾을 수가
없었다. 물론 구글링을 한다면 쉽게 그 개념을 알 수 있다. android system 에서 application 을 실행하면 zygote process 와
결합하여 구동이 된다는 것이 결론이다. zygote 자체에 대해 간단히 짚고 넘어가면 그 개념은 다음과 같다.
zygote 란 application 을 빠르게 구동하기 위하여 미리 fork 되어 있는 process 이다. system 에서 exec() 호출을
통해 특정 application 을 실행하고자 하기 전까지는 중립적인 상태를 유지하며 대기하고 있는 process 이다. 뭐 미리 공통적으로
필요한 libraries 를 탑재한 상태로 반쯤 생성이 되어 application 의 실행에 대비하고 있다는 것이다. 반쯤 생성된 process 에
실제 핵심이 되는 application 의 logic 을 태워 구동시키기 때문에 application 의 구동 속도가 빨라지는 것이다.
이제 zygote process 에 대해 좀 더 자세히 적어보겠다.
zygote process 는 init process 에 의해 구동되어 진다. init process 가 system 구동에 필요한 각 daemon 을 실행하고 나서
실행시키는 process 이다. 그리고 init process 에서 zygote process 가 실행되어지고 난 이후에는 android service 및 
application 은 zygote process 를 통해 실행되어 진다. 그리고 여기에서 booting process 에 대한 글에서 적었던 
PID 와 PPID 의 개념이 필요하다. adb 로 shell 접속하여 ps 명령을 하면 PID 와 PPID number 를 눈으로 확인할 수 있다.
그 number 의 관계를 통하여 init process 가 생성시킨 process 들과 zygote process 가 생성시킨 process 를 확인할 수 있다.
zygote process 를 통함으로 인해 application 의 구동속도가 빨라지는 내용은 위에 간략하게 적었다. 미리 fork 되어 있으면서
공통의 libraries 등을 탑재하고 있기 때문이라 했는데, 이 부분에 대해 조금 더 자세히 적으면 아래와 같다.
zygote process 가 실행이 되면, Dalvik VM 을 실행시키게 된다. 그런 이후 classes 와 resources 를 preloading 한 상태로 application 의 logic 을 기다리고 있는 것이다. 만약 zygote 의 개념이 없다면 application 은 구동 시에 필요한 모든 classes 와
resources 를 찾아야 하는 delay 가 발생하게 될것이다. 이 부분에서 zygote process 의 필요성이 나타난다.
그리고 zygote 는 java 로 작성된 process 이다. android system 에서 java process 를 실행하기 위해서는 Dalvik VM 이 
필요하다. init process 에서 zygote process 를 실행하기 위해서 zygote process 가 생성시키는 Dalvik VM 이외에 별도의 
zygote process 용 Dalvik VM 이 필요하다는 것이다. 간단히 서적에 보면 init process 중에 app_process 라는 service 가
존재하며 이 app_process 를 통해 Dalvik VM 을 실행시킨 후 zygote 를 만들어 낸다. 

JNI 와 zygote process 의 경우는 좀 더 자세히 적고 싶지만 아직은 지식이 부족한 듯 하다.
source code 를 좀 더 쉽게분석할 수 있게 되었을 때 다시 적어야겠다. 지금은 단지 그 개념에 대해서만 정리를 하였다.
booting process 를 기반으로 이해를 한 후 새부적인 process 로 접근을 하니 개념에 대한 이해는 쉽게 되는 듯 하다.
하지만 역시 자세한 내용을 분석하고 구동 원리를 파악하는 데는 한계가 존재한다...

당분간은 글을 적는것 보다는 서적을 보는데 집중해야 겠다.
여기 까지 적은것이 아마도 개념정리를 하는 부분까지는 마지막을 듯 하며, 앞으로 공부하게 될 내용들은 지금 까지
적은 개념들에 대한 상세내용이 될것 같아서 이다.
이제부터는 하나의 글을 적기 위해서는 많은 노력이 필요해지는 시점이므로 조급하게 마음을 먹지 않으려한다.

그리고 이 글과는 무관하지만 
over clocking 의 효과에 대해 어제 생각을 해봤다.
능력 있는 개발자들 사이에서는 over clocking 의 효과나 안정성에 대한 의견이 엇갈리는 듯 하다.
몇일 정도 over clocking kernel 을 사용하며 체감 및 기타 비교를 해본 결과는 차이를 잘 느끼지 못하겠다는 것이다.
1.3 OC 까지 적용을 해서 구동을 시켜보았지만 크게 성능에서 빨리짐을 느끼지 못했다. 일부 사람들 처럼
cpu 가 견디지 못하는 등의 문제는 전혀 없었지만 성능의 엄청난 증대 효과를 느끼지도 못했다.
그래서 그냥 다시 over clocking kernel 을 내렸다. 앞으로도 over clocking kernel 을 이용한 성능 증대를 기대하지는
않을것 같다. 뭐 커뮤니티의 글을 보면 확실히 차이를 느끼는 사람들도 많은 것 같지만, 사용자 환경에 따라 천차만별로
느끼는 듯 하다. 더욱이 난 게임이라곤 하나도 없고 스마트 폰을 이용하여 용량이 큰 application 을 구동하지 않기때문에
더욱 더 느끼지 못하는 듯도 하다.

그리고 오늘은 nilfs2 file format 에 대해 좀 공부를 해볼 생각이다. 생각보다 구글링을 해보니 참고할 만한 자료들이
많았다. 진저브레드 운영체제로 업그레이드 되기 전까지 nilfs2 file format 을 /data 에 적용하여 사용하려고 하기 때문에
주변 지식을 넓히기 위함이다. 

그리고 사진 투척~!!!!



지난번에 올린 사진이다.
아주아주 인상깊은 사진이었다.
실제 이 그림의 크기는 건물 한 층의 높이에 달한다.
한동안 글을 올리지 않을것 같아서 가장 좋아하는 사진을 타이틀에 
두기 위해 올린다. +_+
 
저작자 표시 비영리 변경 금지
신고
Posted by Bulldozer121

티스토리 툴바