나는 MKMapView를 플레이 필드로 사용하는 iPhone 게임을하고있다. 몇 분만 플레이하면 필연적으로 메모리가 부족하여 앱이 부진 해 결국 충돌이 발생합니다. 범인을 파고 들자지도보기가 끊임없이 더 많은 기억을 요구하는 것 같다. 게임은지도의 확대/축소와 패닝을 많이 요구하므로지도의 캐시가 메모리가 부족해질 때까지 계속 증가한다고 가정 할 수 있습니다. 지도보기에 타일 캐시를 플러시하거나 메모리 소비량을 포함하도록 강제로 설정할 수있는 방법이 있습니까?MKMapView의 타일 캐시를 지우시겠습니까?
* 참고 :이 답변은 iOS 4.1 이하에서만 관련이 있습니다. 이 대답에 설명 된 문제는 대부분 iOS 4.2 *에서 수정되었습니다.
내 앱이지도를 사용하며 높은 RAM을 필요로하는 다른 기능을 가지고 있기 때문에이 부분을 파고 들었습니다.
답변을 찾지 못했지만 해결 방법이 있습니다. MKMapView의 메모리 요구 사항은 영역을 가까이서 확대하고 확대 된 영역 내에서 팬을 돌릴수록 기하 급수적으로 확대됩니다.
두 가지 수준의 MKMapView 타일 캐시가 있습니다. 하나는 Instruments에서 Malloc ~ 196kb로 나타나고 다른 하나는 다양한 크기의 NSData (저장소)입니다.
Malloc은 사용중인 타일로 보입니다. 할당 할 수있는 타일 수는 제한적입니다. 내 애플 리케이션에서 숫자가 16, UIView 크기를 기반으로하지 않는 경우 확실하지 않습니다. 이러한 할당은 엄격하게 관리되는 것으로 보이며 메모리 경고에 응답합니다.
어쨌든 타일의 크기를 고려할 때 대륙 수준 (대다수의 북미 지역을 iPad 화면에 맞추기에 충분)이라면 어느 정도의 확대/축소 수준에서 캐싱의 두 번째 수준까지 도달하지 않아도됩니다 NSData (Store))를 사용하여지도를 완성합니다. 모든 것이 선명하고 깨끗합니다. 액티브 메모리에 많은 외부 이미지를로드하면 타일이 자르다. 굉장해!
캐싱의 두 번째 레벨에 도달하면 문제가 발생합니다. 이것은 줌인 할 때 일어납니다. 갑자기 16 개의 타일 대신 갑자기 전체 평면을 보여주기 위해 로스 앤젤레스에서 과시하기 위해 16 개의 타일이 필요합니다. 그런 오래된 타일을 덤핑하는 대신에 주위를 돌면서 NSData (저장소) 할당은 결코 해방되지 않는 것처럼 보입니다.
이 NSData (저장소)는 기본적으로 메모리에만 존재하는 NSURLConnectionCache입니다. 이 캐시는 기본 공유 캐시 (이미 시도한 캐시가 아니기 때문에)에 액세스 할 수 없습니다.
그래서 여기다 붙어 있습니다.
불만족스러운 대답은지도 확대/축소를 사용 중지하고 적당히 넓은 확대/축소 수준으로 수정하면이 문제를 완전히 피할 수 있지만 분명히 일부 앱은 이것을 필요로한다는 것입니다.
나는이 어리석은 캐시를지도에 대해 어떤 방식 으로든 공개 할 수 있는지를 알기 위해 애플에게 지원 티켓을 제출했다. (나는 활성 메모리에 할당 된 RAM의 50+ megs를 자연스럽게 크랭크 할 수 있었다) .
희망이 도움이됩니다.
편집
다음 아이폰 OS 버전이 무한 캐시 문제를 해결 한 것으로 보인다. 이제 MKMapView는 캐시 된 타일 데이터를 적극적으로 제거합니다. 기쁘게 하다! 악기 할당 프로그램에 의해보고 된
당신이 말했듯이 상황을 고치지는 못하지만, 적어도 그것은 꽤 좋은 진단을 제공합니다. 파기와 결과를 공유해 주셔서 감사합니다 – Mattia
안녕하세요 Mattie, 편집을 추가했습니다 ... iOS의 다음 출시가이 문제를 수정합니다. –
주석보기에서 재사용 식별자를 설정하고 있습니까? 즉, 시스템에서 이러한보기를 분리하고 한 번에 메모리에서 적은 수의보기 만 유지하면 스크롤하면 분리 된보기가 다시 사용되므로 스크롤 성능이 향상됩니다. 재사용 가능 :
- (MKAnnotationView *)dequeueReusableAnnotationViewWithIdentifier:(NSString *)identifier
응답 해 주셔서 감사합니다. 주석보기에 재사용 식별자를 실제로 사용하고 있으므로 문제가 아니어야합니다. 그러나 다시 확인해야합니다. – Mattia
그냥 mapkit 768x1024의 (아이 패드 크기)의 뷰 크기의 응용 프로그램을 작성하는 경우는 응용 프로그램은 쉽게 "라이브 바이트"의 30 + 이상 MB를 소비 할 수 있습니다. 이것은 iPad iOS v3.2.2 (다음 주까지 4.2 버전으로 출시 될 때까지 최신 버전)에서 실행되는 것으로 나타났습니다. 필자의 연구 결과에 따르면, 대부분의 개발자가 15-25MB 정도의 레벨 1 메모리 경고를 받았다고보고하고 그 수준 이후에 충돌이 발생하는 단일 응용 프로그램의 경우이 양의 메모리가 많은 것으로 보입니다.
Mattia와 똑같은 문제가 있습니다. 모두가 "ololol지도 핀, 누출"이라고 말하고 싶어합니다. 그러나 아닙니다. MKMapView는 실제로 엄청난 양의 RAM을 중얼 거치며 다양한 줌 레벨로 인해 더 나빠집니다. 지금 당장 문제를 해결하면서 뭔가 발견되기를 바랍니다. –