안드로이드 사용자 모임 게시판
(글 수 3,442)
현재 내장 메모리 문제가 이슈가 되고 있는게, 구글의 철학이나 이념 문제라는 의견도 있지만.. 전 뻘짓이라고 생각합니다.. 어떤 문제에 대해서 합리적인 결론에 도달할수 있을 만큼 구성 요소가 적절하게 배치되어 있다면 아.. 그런가보다 할수도 있겠지만, 안드로이드 파일 시스템에 관한한, 구글의 선택이 최적의 선택이라고 말할수 없을 만큼 허술한 구석이 너무나 많기 때문에, 그게 단순히 구현 철학의 문제라곤 생각할수가 없습니다.. 매일 밥 태우는 마누라에게, 그래.. 나에게 누룽지를 주기 위해서 밥을 태우는구나.. 라고 생각할수도 있겠지만.. 물조절을 잘 못한다고 생각할수도 있지 않을까요? 밥 말고도, 반찬도 태우고, 고기도 태우는데.. ^^
하여간, 안드로이드의 부팅 과정을 살펴 보겠습니다..
안드로이드의 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는 임시 파일이니까 굳이 저장하고 있을 필요도 없죠.. 어플이 빠져나가면서 자동으로 지우도록 만들던가.. 왜 꼭 유저가 가서 리셋을 해 줘야 하는지.. 특별히 힘든일도 아닐텐데 말입니다..
하여간, 안드로이드의 부팅 과정을 살펴 보겠습니다..
안드로이드의 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는 임시 파일이니까 굳이 저장하고 있을 필요도 없죠.. 어플이 빠져나가면서 자동으로 지우도록 만들던가.. 왜 꼭 유저가 가서 리셋을 해 줘야 하는지.. 특별히 힘든일도 아닐텐데 말입니다..
2010.03.17 09:10:11
저는 터치팟 유저일 때, 프로그램 설치 전부 디바이스 안에 있는 앱스토어에서 했어요. 플레이맵조차 ㅋㅋ
아이튠스에 앱 목록을 동기화시킨다고 하면,
새로운 PC환경에서 조금만 부주의했을 때 디바이스의 앱들이 날아가는 황당한 경우가 생기더라고요.
그래서 PC의 아이튠스에서는 오직 음악과 동영상만 관리했죠... 그것도 수동으로. iPhone OS 2.1 때부터요.
애플이 그런 가능성을 열었으니, 안드로이드도 제공해야겠죠.
앱 인스톨 및 업데이트시 다운로드된 apk를 삭제하고
apk의 서버업로드시각과 버전번호, 더한다면 해시값 정도 추가해서 관리하면 좋을 거 같아요.
정 아니라면, 인스톨 성공 최종화면에서 백업apk삭제 버튼이라도 만들어주면 좋을 거 같네요.
그것만 해도 여유공간이 두 배 이상 늘어날텐데 말이죠;
MS의 닷넷 프로그램들도 인스톨이나 업데이트 후에 백업파일 삭제 루틴이 꼭 들어가던데... 스마트한 구글, 쫌!
2010.03.17 09:54:28
여기 여러가지 찐돌님의 글들을 읽어보면
기술자이시면서도 매우 합리적인 시각이 많이 느껴집니다.
기술이 뛰어난 기술자나 개발자일수록 자기기술에 빠져 합리적인 시각을 갖기 어렵거든요.(제경험상)
개인적으로 잘모르지만 성공하실분이라고 생각됩니당...^^;
2010.03.17 10:39:30
달빅 문제는 어쩔수 없는 선택이었을 것입니다.
라이센스 문제가 컸으니까요. ^^
조금씩 개선되는 부분이 새로운 브랜치나 소식으로 보이고 있으니 기다리면 될듯하긴한데.
기다리기가 지루하네요 ㅎㅎ
나머지 파티션 관련 저장공간 불만은 공감 합니다.
정책적 변화가 필요해 보입니다.
변화를 하지 않으려면, 부분 변경이라도..ㅡ.ㅜ
아.. 캐시쪽은 데이터중 일부는 필요한 부분도 있습니다.
메모리가 에러나는 상황에서는 삭제해도 좋지만,
그렇지 않은 상황(어플 종료 시점 같은 경우)에서 지우면 어플의 UX가 훼손되는 경우도 있더군요.
이런건 커스텀하게 컨트롤 할 수 있으면 좋을 것 같은데.
아직은 구글 마인드가 조금 반영된듯. 심플. 심플. 심플. 몰라.. 몰라.. 몰라.. 쩝....
안드로이드 진영으로 유명 인사들이 속속 영입되고 있으니,
조만간 변화가 예상되긴 합니다.
^^
이런 재미가 안드로이드의 매력? ㅋㅋ
2010.03.17 11:24:33
cache 파티션에 대해서 말씀드리면
update가 그 존재 이유중의 하나같습니다
다양한 경로로(sdcard,OTA,usb...) update가 이루어 지는데 cache 파티션은 update를 위한 중간다리 역할을 하고있습니다.
1.6 -> 2.1로 업그레이드시 필요로 하는 공간이 있습니다. update data는 압축된 형태로 제공가능하여 실제 update 데이타의 70%(? 기억이 가물가물) 공간 확보가 권장이라 하더군요. 이에 다른 용도로 사용하지 않도록 별도의 파티션으로 구성한 듯 합니다.
메모리가 아깝다는 생각은 저도 하지만 update확장성을 고려한 처사라 생각됩니다.
2010.03.17 12:49:18
cache 를 평상시에는 다른용도로 활용하다가, update 시에 공간을 비우도록 안내를 해주면 좋을 것 같네요.
달빅이 성능이 심한가 보군요. 루팅해서 달빅을 다른 것으로 교체하는 시도도 있겠군요.
달빅이 성능이 심한가 보군요. 루팅해서 달빅을 다른 것으로 교체하는 시도도 있겠군요.
2010.03.17 13:12:22
제 생각에도 파티션을 나눈 것은 의아합니다.
/cache 파티션의 경우 그냥 놀고 있는 용량이 상당한데, 그냥 /data 와 같은 파티션으로 사용하다
/cache가 필요한 상황에는 용량 확인만 한 번 해주면 되는 것 아닌가 싶네요.
구글도 문제점을 느끼고 있을테니 다음 업데이트에는 고쳐지기를 바랄 뿐입니다.
/cache 파티션의 경우 그냥 놀고 있는 용량이 상당한데, 그냥 /data 와 같은 파티션으로 사용하다
/cache가 필요한 상황에는 용량 확인만 한 번 해주면 되는 것 아닌가 싶네요.
구글도 문제점을 느끼고 있을테니 다음 업데이트에는 고쳐지기를 바랄 뿐입니다.
2010.03.17 16:36:18
아~ 이런 상황이였군요.
지적하신 문제가 정말 아무 이유없는 오류라면
어여빨리 업그레이드되서
task manager를 누르는 제 손가락도 좀 쉬었으면 좋겠네요.T.T
2010.03.17 18:54:37
파티션을 나누고 합치고는 제조사에 충분히 바꿀 수 있습니다. (linux 파티션에 한해서...)
그러나, USB 스토리지 연결은 되는 장치들은 FAT 파티션을 사용하기 때문에
하나의 파티션으로 합칠 수 없는 문제가 있습니다.
내장 저장공간 (메모리) 의 문제는 파티션을 나누었기 때문에 생기는 문제는 아니랍니다.
그러나, USB 스토리지 연결은 되는 장치들은 FAT 파티션을 사용하기 때문에
하나의 파티션으로 합칠 수 없는 문제가 있습니다.
내장 저장공간 (메모리) 의 문제는 파티션을 나누었기 때문에 생기는 문제는 아니랍니다.
2010.03.17 23:45:06
아..이 글은 SD Card얘긴 아닙니다.. SD Card에 어플이나 데이터를 저장 못하는 문제점은 뭐.. 그렇다치고, 그럼 내부 메모리의 구조는 괜찮은가, 잘 사용되고 있는가에 대한 얘기입니다.. 외부 메모리까지 사용하지 않아도 될만큼 어플들의 용량이 적다.. 뭐.. 이것 저것 변명이 있었기 때문에, 자세히 살펴본 것입니다.. 그런데 내부 메모리도 잘 사용되고 있는것 같지는 않죠..
그리고 SD Card만 해도, 굳이 USB로 사용하지 않아도 되었을 겁니다.. 모토로이처럼 Phone Portal로 연결을 하게 되면, 꼭 FAT로 포맷되어야 할 필요는 없습니다. FAT서버 같은 어플이 PC에서 데이터를 받아서 대신 적어주는 것이니까요.. 만약 보안성을 걱정한다면, ext2나 yaffs2를 약간 변형해서 포맷을 하게되면 PC에서 SD Card를 읽어낼 방법이 없습니다. 왜냐.. 그 파일 시스템을 지원하는 OS가 없으니까요.. 그 방법이 훨씬 좋았을 겁니다. 현재의 방식은, USB로 Mount를 하면 PC로 SD Card쪽 제어를 H/W적으로 완전히 넘겨 버립니다.. 따라서 PC에서 포맷을 하던, 파티션을 나누던 다 할수 있습니다.. 이 방식도 장점이 있지만, 안드로이드 폰에서 데이터를 받아서 대신 적어주는 방식으로 처리를 할수도 있죠.. 중간에 레이어를 하나 더 두는 것입니다.. 보통 PMP들이 이런 방식 많이 씁니다.. 이렇게 하면 SD Card가 굳이 FAT여야 할 필요도 없고, 보안성 문제도 없습니다..
저도 전문가는 아닙니다만..
이해가 안가는 부분이 한둘이 아닙니다...
정확한 답변을 기다릴뿐..