4

그래서 내 앱에 메모리 문제가 있습니다. 이 응용 프로그램에는지도에 이미지를로드하는 MKOverlayRenderer가있는 MKMapView가 있습니다. 모든 것이 정상적으로 작동하지만 30-60 분 후에 메모리로 인해 앱이 다운됩니다.NSURLConnection은 계측기에서 성장하고 있습니다. NSURLCache입니까?

인스 트루먼 테이션을 통해 나는 NSURLConnection이 성장하고있는 것을 발견했고, (내가 이해하지 못하는 모든 종류의 것 이외에) 다른 것을 찾을 수 없기 때문에 나는 그것이 내 문제라고 생각한다. instruments after 12-13 minutes

이미지가 canDrawMapRect 방법으로 다음과 같이로드 및 저장됩니다 12~13분을 위해 실행 한 후

instruments NSURLConnection

스크린 샷 악기 :

스크린 샷 악기 1~2분에 대한 실행 해 후 tmp 폴더 (NSURLConnection이 높지 않게됩니다.)를 설정하면됩니다.

NSURLRequest *request = [NSURLRequest requestWithURL:[NSURL URLWithString:url]]; 
    [NSURLConnection sendAsynchronousRequest:request 
             queue:[OperationQueues sharedOperationQueue] 
          completionHandler:^(NSURLResponse *response, NSData *data, NSError *error) { 


           [data writeToFile:path atomically:YES]; 

그런 다음 drawMapRect 메소드에로드됩니다.

I는 다음과 같은 코드로이 정착 시도 :

AppDelegate에 :

int cacheSizeMemory = 4*1024*1024; // 4MB 
int cacheSizeDisk = 32*1024*1024; // 32MB 
NSURLCache *sharedCache = [[NSURLCache alloc] initWithMemoryCapacity:cacheSizeMemory diskCapacity:cacheSizeDisk diskPath:@"nsurlcache"]; 
[NSURLCache setSharedURLCache:sharedCache]; 

NSURLCache *URLCache = [[NSURLCache alloc] initWithMemoryCapacity:cacheSizeMemory 
                diskCapacity:cacheSizeDisk 
                 diskPath:nil]; 
[NSURLCache setSharedURLCache:URLCache]; 

의 ViewController :

- (void)didReceiveMemoryWarning 
{ 
    [[NSURLCache sharedURLCache] removeAllCachedResponses]; 
    [super didReceiveMemoryWarning]; 
} 

오른쪽 요청 후 [추가]

[[NSURLCache sharedURLCache] removeCachedResponseForRequest:request]; 

그러나 인스 트루먼 트에서 아무런 운이없이 볼 수 있습니다.

  1. 내 문제 일 수 있습니까?
  2. 성장중인 NSURLCache 또는 다른 것입니까?

으로 악기에서 더 두개의 스크린 샷을 요청 :

statistics enter image description here

+1

'+ [NSURLConnection _resourceLoadLoop]'옆에있는 삼각형을 클릭하여 호출 트리를 열 수 있습니까? – thelaws

+0

또한 이것이 NSURLCache와 관련이 있다고 생각합니까? – thelaws

+1

"콜 트리"보기 외에도 "통계"페이지를 보여줄 수 있습니까? 또한 좀비가 켜져 있지 않은 것으로 추측합니다 (메모리가 완전히 릴리스되지 않도록하기 때문에). 내 표준 접근 방식은 "통계"페이지에 초점을 맞추고, "기록 참조 횟수"가 인스트루먼트에서 켜져 있는지 확인하고 공개해야하지만 발행해야하는 광산 개체를 찾은 다음 참조 카운트 세부 정보를 조사하여 out of object (잘못된) 강한 참조가있는 곳. – Rob

답변

2

첫째, 1 분 400 개 네트워크 요청이 꽤 과도한 것 같다. 이러한 요청 중 일부는 아마도 중복되거나 불필요합니다. 통화량은 많은 정보를 분명히 다운로드하고 있으며 정리 작업에 많은 시간을주지 않습니다.

두 번째로 NSURLCache은 실제로 이상의 기본 캐시보다 메모리 공간을 제공합니다. 내 장치/시뮬레이터에서 테스트 한 결과 512MB의 기본 메모리 용량을 제공합니다. 캐시는 4 194 304 바이트로 초기화됩니다 (디스크의 경우 더 많음).

몇 가지 개선 사항을보기 위해 캐시 크기를 더 작게 설정하는 것이 좋습니다. 그러나 네트워크 요청의 양을 조사하면 장기간 혜택을 얻을 수 있습니다.

+1

400 요청을 지적 주셔서 고마워, 나는 뭔가를 발견했습니다 : 틸트와 MKMapCamera를 사용하여 각각의 zoomlevel에 대한 이미지가 필요하고 경사와 함께 diff에서지도를 볼 수 있기 때문에 이러한 많은 양의 원인이됩니다. 줌 레벨. 이제는 3D가 없으므로 훨씬 적습니다. 또한 가능한 빨리 버그를 재현하기 위해 1 초에 파일 캐싱을 했으므로 400은 실제 제품 번호가 아니 었습니다. 100m/s (360km/h)를 주행하면서 5 분 동안 500 번 요청합니다. 위치에 대한 첫 번째지도 확대는 이미 100 회의 요청을 발생시킵니다. –