18개의 앱을 업데이트 해야 한다면
1 다운 - 1 업데이트 -2 다운 - 2 업데이트...
이런 식인데
업데이트는 업데이트대로, 다운은 다운대로 따로 놀면 안되나요? 정책이 왜 이런지 모르겠는데
1업데이트 - 2업데이트 - 3업데이트
1다운 - 2다운 - 3다운 - 4다운
업데이트 하면서 다운까지 하면 system io가 못 버티나요...?
인터넷 / 소프트웨어
:
윈도우즈, 리눅스, 기타 운영체제, 각종 어플리케이션, 프로그램, 소프트웨어, 인터넷, 인터넷 서비스에 대한 이야기, 소식, 테스트, 정보를 올리는 게시판입니다.
질문
2017.05.20 22:05
안드로이드 업데이트는 왜 다운받고-업뎃 패치하고-다시 다운받고 할까요.
조회 수 1063
댓글 16
-
?
-
?
동시에 다운로드와 설치는 같이 못해도
다 다운받고 다운끝나면 한번에 설치하지
라는 생각은 해봤는데 그 다운받은거 램에 저장하면 딸려서...? -
혹은 여러개 동시에 업데이트 하다가 꼬이면 골치아파지기 때문일지도 모르죠!
아니면 그냥 구현하기 귀ㅊ..읍읍 -
아마 앞의 패키지가 적용되어야 뒤의 패키지를 설치할 수 있단던가 그런거 아닐까요? 아니면 문제생겼을때 롤백의 용이성을 위해 그렇게 한다던가... -
다시보니 시스템 업데이트가 아니라 플레이스토어 였군요.
구형인 갤럭시 그랜드 맥스나 지프로에서 업데이트시 Ui가 버벅이던데 아마 이런 저성능 기기를 위해 하나하나 업데이트 하려는 걸까요?... 잘 모르겠네요. -
그거 플레이스토어만 그래요. 원스토어 같은데는 말씀하신대로 하지요 -
?
17년 1월 기준 플레이스토어 앱 평균 크기가 37MB더라구요. 스토리지나 CPU 리소스 때문은 아닌 것 같고...
제가 말씀드린건 동시에 여러개 설치가 아니라, 설치 하는 중에 다른 앱의 업뎃 내용을 미리 다운받자는 거니까 의존성 문제도 아닐 것 같고요.
동방의빛 말씀하신 것처럼 원스토어도 그렇고, 아마존 스토어도 다운은 concurrent하게 받는다 하네요. ㅡ..ㅡ -
저도 아쉽게 생각 되더군요..?
업데이트때 하나하나 되니 시간이 오래걸리더군요. -
?
못할 거 없습니다. 그냥 엄청 불편하지는 않으니 옛날방법 그대로 굴러가는 것일 뿐..
사양이 엄-청 구리면 병렬다운로드가 도움이 안 될수도 있는데 요즘 스마트폰 사양은 괴물같으니 동시에 다운 좀 받는다고 (결과적인) 처리속도가 저하될 일은 없죠.. -
?
아이들링 2017.05.21 17:33
이클레어 프로요때까진 그렇게 하다가 진저쯤 해서 1개씩하는걸로 바뀐거같은데
이게 맞는지 모르겠네요 -
?
바뀐게 맞습니다
NAND/SD/eMMC I/F 가 데이터버스 공유하는 반이중 방식이라 읽기 쓰기 동시동작하면 겁나 느려집니다.
sata/ufs/nvme 붙어있는 장치 아니면 읽기 쓰기 동시는 무리죠. -
?
근데 요즘 맛폰은 램이 깡패라 엔간히 큰 바이너리 아니면 그냥 램에다 받도록 설계하면 될 일이라서요..
-
?
그렇게 하려면 PackageManager 서비스 건들어야되는데 앱 제조사에선 불가능하죠.
거기다가 파일에 일단 저장해 놓으면 생명주기에 따라서 죽는 경우에도 resume 가능한데 램에 받으면 불가능합니다. 데이터 쿼타만 소비 할 수도 있는거고요.
어차피 지금도 OS 파일시스템 캐싱 있어서 파일 쓰기 동작이 바로 파일시스템에 커밋 되지도 않고요. -
?
네, 근데 다른 스토어 이야기도 나오긴 했지만 기본적으로는 안드로이드 업데이트 이야기니까요. 앱 제조사가 아닌 구글 입장이라면 못할 것도 없는 이야기입죠. 손이 좀 간다 뿐이지.. 데이터야 처리도중에 핵심 서비스만 안 꺼지면 되는 일이고요. ( 가물가물해서 틀렸을 수 있긴 한데 어차피 구글 플레이가 앱을 받을 때도 /tmp에다 받지 않던가요? 물론 램에 저장하는것보다야 오래 살아있을 수는 있지만 리붓 등의 트리거로 tmp가 비워지면 날아가는 건 마찬가지..)
안드로이드 폰들 드라이브 캐시 폴리시가 어떻게 되는지는 잘 모르겠네요. write back이면 도중에 전원 나가면 곤란하지 않나 싶긴 한데 뭐 그렇게 치면 노트북도 그렇긴 하고. 근데 write back이면 그 캐시가 날아가기 전까지는 더욱 병렬 다운로드가 힘을 쓸 수 있는 거 아닌가요 (..) 요즘 폰 램 용량이면 앱으로 메모리가 꽉차가는 상태만 아니면 리눅스가 자동으로 잡아주는 캐시 크기만 해도 수백 메가/수 기가 단위로 나오지 싶은데요.
심지어 반이중으로 동시에 읽기/쓰기를 해야 하는 경우에도 일단 네트워크 속도가 큰 병목으로 작용하는 상황에서는 가능한 한 다운로드를 멈추지 않는 것이 성능에 좋다고 봅니다. 뭐 요즘의 고성능 무선망은 사정이 다를 것도 같습니다만.. 네트워크가 좀 느린 상태라면 여전히 동시 다운로드에 의해 절약된 다운로드 시간이 드라이브 I/O에 의해 느려진 설치시간보다 클 수가 있지요. -
?
답변 감사합니다. UFS 적용된 폰을 쓰고 있으니까 이 점을 간과했네요.
하기사 RAM 수준이 아니면 R/W 동시에 하면 뭐든지 퍼포먼스 하락이 크긴 한데... -
다양한 환경과 사양때문에 최저 사양에 맞춰서 한게 아닐까요..?
작성된지 4주일이 지난 글에는 새 코멘트를 달 수 없습니다.
대부분의 데스크탑 마켓과 프로그램도 똑같이 1다운 1설치인데
리소스를 하나에 몰아서 효율을 높일려는거 아닐까요
나누면 다 같이 느려져 버리니