아무리 안드로이드를 들여다 봐도, 별로 구글 답지 않은 모습때문에 굉장히 실망입니다.. 그냥 대학원생들이 텀 프로젝트 하듯이 만든것 같다는 느낌이랄까요.. 일단, 안드로이드의 파티션과 구조에 대해서 대강 설명해 보겠습니다.. 

/system
/cache
/data
/sdcard

가 주요 디렉토리입니다.. /system이 시스템 커넬과 펌웨어가 깔려 있는 핵심입니다.. 이 파티션은 Read only로 설정되어 있어서, 어떻게 부술 방법이 없습니다.. 그게 한 140메가 됩니다.. 라이브러리라던가 이것 저것 여기 다 깔려 있습니다.. 

/cache디렉토리는, 업데이트 할때 update.zip을 다운받는 용로로 사용됩니다. 시스템 캐쉬 운운하는 글들을 찾으실수 있는데, 뻥입니다.. 이 파티션이 제일 맘에 안 듭니다. 크기가 90메가나 되는데, 사용이 안됩니다.. 물론 90메가나 되는 이유는 update.zip을 문제없이 받을수 있도록 하기 위해서랍니다.. (2.0.1에서 2.1로 가거나 3.0으로 가는것 같이)

/data에 유저 인스톨 어플과, 실행 데이터, 그리고 dalvik-cache가 들어갑니다.. 여기서 유저 앱은 /data/app에 들어가고, 실행 데이터는 /data/data디렉토리에 들어갑니다.. 여기서 각각의 어플은 독자적으로 디렉토리를 만드는데, 예를 들면 gmail은 com.google.android.gm이란 서브 디렉토리를 만듭니다. 이때 각각의 어플 디렉토리는 유저 아이디와 그룹 아이디가 달라서, Super User권한을 가진 어플이 아닌한, 다른 어플의 데이터를 건드릴수 없습니다.. 기본적인 보안이 유지되는 이유죠.. 

어플 디렉토리는 대게, cache, databases, lib그리고 files등의 디렉토리를 공통적으로 가집니다.. cache가 캐쉬고, databases는 메일의 메일함 같은겁니다.. 모든 어플들이 별도로 cache디렉토리를 데이터 파티션에 가지고 있습니다. /cache를 사용하는게 아닙니다.. 

dalvik-cache는 Dalvik VM이 실행하기 위해서 사용하는 바이너리입니다.. apk에 비해서, index를 사용하여 메모리 액세스 하는걸 시간을 줄이기 위해서, 절대 번지 액세스 방식으로 바꾼것이라고 합니다.. 대충 apk와 비슷한 용량을 가집니다.. 이 Dalvik cache파일인 obex때문에, 1메가짜리 어플을 깔면 2메가를 잡아먹습니다.. 하지만 런처가 어플을 표시할때 정보를 apk에서 읽어옵니다.. 뭐.. 하나로 통일해서 용량을 줄이던가, 실행할때 사용할것도 아니면서 용량만 잡아먹습니다.. 이 디렉토리에는 유저가 깐 어플의 cache만 들어가는게 아닙니다.. 시스템 어플의 vm도 들어가죠.. /data파티션이 256MB인데, 실제 256MB가 안되는건 시스템 어플에서 비롯된 dalvik cache때문입니다.. 

그래서, 안드로이드를 사용하기 시작하면, 두가지 방식으로 용량을 잡아먹는데요, dalvik cache가 용량을 키우고, 어플에서 생성하는 데이터와 캐쉬가 용량을 먹기 시작합니다.. 그리고, 플래시 메모리의 특성상, 용량이 작아지면 질수록 퍼포먼스가 기하급수적으로 떨어집니다.. 100메가남아있을때랑 20메가 남아 있을때의 성능이 다릅니다.. 

자, 요즘 이슈가 되는 SKAF같은 경우, System 파티션에 깔면 됩니다.. 2.0.1기준으로 한 50메가쯤 남아 있으니, 20메가짜리 SKAF가 깔린다고 별 무리가 있을리 없습니다.. 여전히 30메가나 남아 있죠.. 

그리고, 요즘 SD로 App을 깔수 있게 구글이 해결해 줄것으로 기대하는데, FAT32로는 안됩니다.. FAT32에선 퍼미션을 제대로 지원하지 않기 때문에, 기본적인 보안성을 유지할수 없습니다. 해커가 특정 코드를 집어 넣어서 다른 어플의 디렉토리를 뒤지는것, 예를 들면, Personal Assistant같이 금융 정보를 저장하는 어플을 건드리게 되는걸 막을수가 없습니다.. 결국, ext2로 동작하는 가상 파티션을 만들거나, 아니면 SD를 Linux FS로 포맷해야 하는데, 그걸 리콜하지 않고, update.zip안에 들어있는 스크립트로 하기엔 너무 위험 부담이 큽니다.. 데이터를 임시 저장고로 옮기고, 포맷하고 이런 복잡한 과정을 실행하다 잘못해서 데이터 날아가면, 유저들의 그 원성을 어떻게 감당할수 있겠습니까.. 가상 파티션을 만들거나, 포맷을 새로 하거나, 다이나믹하게 용량을 변경할수 있는건 아니라서, 1기가로 잡던 2기가로 잡던 결국 용량 제한은 또 생깁니다.. 

기술적으로 힘든건 아니지만, 깔끔한 해결책도 없습니다.. 그리고, OMAP이란 걸출한 CPU를 제대로 사용도 못하고 있는 안드로이드를 보자면.. 아키텍쳐를 150% 깔끔하게 사용하는 애플이랑 경쟁하는게, 회사원이랑 고등학생이랑 싸움하는 느낌이랄까요.. 열정에 가득차고, 숫자가 많은 고등학생이긴 하지만, 일처리가 깔끔하지 못하는건 아마추어라서 그런가 느끼고 있습니다..

 400메가 짜리 DSP를 놀리고 있는데, AAC Encoding이나, JPEG Encoder그리고, Video Encoding/Decoding하는 데 밖에 사용안합니다.. 이걸 Audio playback하는데 사용했었어야죠.. 그러면 ARM이 무슨 짓을 하던 음악이 끊기는것 따위의 어설픈 결점은 안 나왔을 겁니다.. 지금은 플래시를 액세스 하거나, ARM의 클럭을 변경하거나등, ARM이 시간내에 응답할수 없는 어떤 Task를 실행하는 경우, Audio Codec에 데이터를 줄수 없으니 여지없이 음악이 끊어집니다.. 뭐.. 10~20MIPS만 있으면 되는 Mp3이긴 하지만.. 그래도 사람귀가 소리에 얼마나 민감한데요. 영상은 중뇌가 대강 pre processing해서 대뇌로 보내기 때문에 속이기 쉽지만, 소리는 대뇌가 직접 처리하기 때문에 아주 아주 민감한 감각중 하나입니다.. 애플은, 별도 DSP쓰는걸로 압니다.. 제가 안드로이드 만들었다면 이렇게는 안했을것 같은게 너무 많아요.. 
이 게시물을