캐싱이 된 다음에 캐시에서 제대로 읽어오지 못하는 것 같습니다.
2013.10.28 11:28
캐시 메모리 설정을 500M로 잡고
상태가 별로 안좋은 네트웍 드라이브에서
100M 짜리 zip 압축 파일(jpeg 포함됨. 압축 전 용량 105M 가량) 을 열어서 가만히 냅두면 캐시 채우느라 메모리가 쭉쭉 올라가는데...(트래픽도...)
캐싱이 완전히 종료된 상태(메모리/트래픽에 변화 없는 상태) 에서 페이지를 4~5장 넘기다 보면 일시적인 랙이 발생합니다.
그 다음에도 한 5페이지 정도 넘기면 또 랙이 발생하구요.
한번 랙이 발생한 구간을 페이지를 뒤로 돌렸다가 다시 넘길 시에는 이 현상이 발생하지 않는것으로 보아 캐싱이 된 다음에 어떤 문제로 인해 로딩이 발생하거나, UI에 락이 걸리는것으로 보입니다.
댓글 4
-
반디소프트
2013.10.28 17:11
-
Lyn
2013.10.28 19:43
어라... 그런가요? 그렇다고 보기엔 캐시 차는동안 CPU가 완전히 0% 고정이던데...
그래서 디코딩 되었다곤 생각을 못했네요.
캐시에 락을 걸고 대기하는게 아니라, 있는지 없는지 디코딩중인지 플래그 처리를 하고 주기적으로 읽어오는게 좋지 않나 싶네요 ...
그 중간에 로딩중 이라고 뱅글뱅글 돌아가기라도 하면 불편함이 덜할것 같습니다. -
반디소프트
2013.10.29 12:12
지금 구조를 살펴보니 현재 구조로는 개선이 힘들것 같습니다.
처음 만들때 여러가지 복잡한 상황을 고려하지 않고 만든 부분이 있어서 대 수술을 하지 않으면 개선되기 좀 힘들것 같네요. ^^
-
Lyn
2013.10.29 14:08
이런... 그렇군요. 꿀뷰 6을 기다려야겟네요.
아니면 ... ARC 라이브러리로 한번 만드는걸 시도해볼까 ㅡ.ㅡ;
아마도, 백그라운드로 이미지를 디코딩해서 캐시하고 있는 중에, UI쓰레드에서 캐시된 이미지를 가져오려고 하면
잠시 블러킹될수 있는데 아마도 이런 현상이 아닌가 싶습니다.
정확히 문제를 확인하고 해결하기 위해서는..... 느린 I/O 를 만들어 봐야 겠네요.
(만약 기본 구조를 크게 바꿔야만 한다면 문제 해결이 쉽지 않을듯 합니다.)
PS) 참고로 캐시 메모리 크기는 압축전의 데이타가 아니라 이미지 데이타의 디코딩이 완료된 비트맵 데이타에 대한 크기입니다.