현재 내장 메모리 문제가 이슈가 되고 있는게, 구글의 철학이나 이념 문제라는 의견도 있지만.. 전 뻘짓이라고 생각합니다.. 어떤 문제에 대해서 합리적인 결론에 도달할수 있을 만큼 구성 요소가 적절하게 배치되어 있다면 아.. 그런가보다 할수도 있겠지만, 안드로이드 파일 시스템에 관한한, 구글의 선택이 최적의 선택이라고 말할수 없을 만큼 허술한 구석이 너무나 많기 때문에, 그게 단순히 구현 철학의 문제라곤 생각할수가 없습니다.. 매일 밥 태우는 마누라에게, 그래.. 나에게 누룽지를 주기 위해서 밥을 태우는구나.. 라고 생각할수도 있겠지만.. 물조절을 잘 못한다고 생각할수도 있지 않을까요? 밥 말고도, 반찬도 태우고, 고기도 태우는데.. ^^

하여간, 안드로이드의 부팅 과정을 살펴 보겠습니다..

안드로이드의 Booting이 시작되면 Boot ROM코드를 읽어와서, 하드웨어를 초기화하고, Kernel을 읽어들이기 시작합니다. 이게 Linux kernel이죠..  여기서 kernel은 boot image 끝단에 위치한 이미지를 풀어서 ramdisk를 만들고, startup script를 실행합니다.. 이 startup script에서는 /data, /system, /dev, /cache등등의 디렉토리를 만들고, 퍼미션을 정한 다음 플래시 메모리의 각각 파티션을 마운트 합니다..

내장 메모리가 파티션이 되어 있기 때문에, 용량이 정해지고, 한쪽이 가득차도, 다른 파티션은 비어 있는 등의 문제점이 생기게 됩니다.. 그렇다면 부팅 과정이 항상 이렇게 밖에 될수 없느냐 하면.. 그렇진 않습니다..

파티션을 하나로 만들어도 됩니다.. 리눅스를 PC에 깔면서 파티션을 여러개 만들진 않죠.. root partition하나만 만들고 맙니다..

/system파티션과 다른 파티션과의 차이는 /system은 Read only입니다.. 따라서 수정을 할순 없죠.. 근데, read only로 퍼미션을 셋팅하면 수정할수 없는 건 마찬가지입니다.. ^^ 만약 파티션을 같이 쓴다고 문제가 되었다면 전세계 워크 스테이션은 다 보안 이슈가 있어야겠죠..

만약 파티션 하나로 합쳤다면 오늘날과 같이 /cache파티션이 놀고 있다던지 하는 문제점은 없었을 겁니다.. iphone파티션이 하나인 걸로 압니다.. wiki를 봤더니, 초기 안드로이드 개발 보드에선 이런 파티션을 나누지 않더군요.. 그냥 하나의 파티션으로 부팅합니다.. 왜 나눴는지 알수가 없네요.. 하나의 가정이, update때문인데, 이 update도 굳이 폰으로 하게 하지 말고, PC에 연결되게 해서, PC에서 update과정을 통제하도록 한다면 굳이 내장 메모리로 update image를 받을 필요도 없습니다.. 그게 더 안전하기도 하고..

두번째, 어플리케이션 용량 문제..

여러번 글을 올린적 있는데, apk파일이라던지, 리소스 문제라던지, library문제라던지, 그중에서 하이라이트는 유료앱같이 어플리케이션이 3개의 카피를 만드는, 그런 경우 까지 있습니다.. 무슨 초등학생이 코딩하는것도 아니고..

Dalvik이, 용량 문제때문에 무척 compact하게 만들어져 있습니다.. 그 compact함 때문에 속도가 많이 느립니다.. Sun이 제공하는 JIT Java VM에 비해서 최대 20배 느립니다.. Sun의 Java VM을 사용했다면 G1이 Nexus One의 속도로 돌고 있었을 거라는 말입니다.. 그렇게 고생 고생해서 Dex파일 포맷도 정하고, Dalvik도 힘들게 만들고, 그러면서 어플리케이션 카피를 3개씩 만든다? 누군지 몰라도, 안드로이드 Project Manager 욕 엄청 들어먹어야 됩니다.. 이런게 뻘짓이죠..

세번째, cache관리 문제인데요.. /cache파티션 사용안하는건 뭐.. 워낙 언급을 많이 해서 제껴두고, 내부 메모리 에러가 날만큼 최악인 상황에서 캐쉬는 왜 안 지우는지 의문입니다.. 그런거 자동으로 되어야 하는거 아닌가요.. cache는 임시 파일이니까 굳이 저장하고 있을 필요도 없죠.. 어플이 빠져나가면서 자동으로 지우도록 만들던가.. 왜 꼭 유저가 가서 리셋을 해 줘야 하는지.. 특별히 힘든일도 아닐텐데 말입니다..