iOS 시뮬레이터에서 낮은 메모리 조건을 "현실적으로"테스트하기위한 전략

Question

나는 didReceiveMemoryWarning 등을 구현하고있는 my little app의 개발 시점에 있습니다. 그러나 나는 최상의 결과를 잘 이해하지 못하고 있습니다. 내가 구현하고있는 것을 테스트하는 방법.

먼저 떨어져, 분명히 시뮬레이터, didReceiveMemoryWarning은 this question에 따라, 그 응용 프로그램이 포 그라운드로 다시 데려 때까지 전경 에없는 응용 프로그램에 대한 트리거되지 않습니다 - 사실, 내 자신의 경험과 일치 그러나 실제로 이해가되지 않기 때문에 나는 그것을 무시하는 경향이있었습니다. (전 포 그라운드로 다시 돌아올 때까지 내 메모리를 지우는 것을 지연하고 싶을 것입니다. 아마도이 데이터가 다시 필요할 것입니까?) 실제 하드웨어의 동작과 일치합니까? 그렇다면 didReceiveMemoryWarning 외에도 applicationWillEnterBackground에서 작업을 정리하는 것이 합리적입니까?

두 번째로 일반적으로 시뮬레이터의 "메모리 경고 시뮬레이션"메뉴 항목을 트리거하여 실제 하드웨어에서 발생할 수있는 방식으로 메모리 경고를 트리거하는 좋은 전략은 무엇입니까?

Answer 1

1 : 이것은 실제 하드웨어의 동작과 일치합니까?

• A : 예, 시뮬레이터와 실제 장치가이 점에서 같은 행동 (앱이 일시 중단하고 백그라운드 작업을 실행하지 않는 경우, 예를 들어, 그것은 applicationDidReceiveMemoryWarning을받지 않습니다).

Q2 :이 applicationWillEnterBackground에서 정리 작업에 의미가 있습니까?

• A1 : 앱이 완전히 다시 시작될 수 있도록 준비해야합니다. 앱이 일시 중지 된 상태에서 다른 앱으로 많은 일을하는 경우 앱이 완전히 언로드 될 수 있습니다. 앱이 계속 작업 전환기에 표시 될 수 있지만 사용자가 다음 번에 앱을 활성화하면 앱 대표가 application:didFinishLaunchingWithOptions: (이 아닌applicationWillEnterForeground:)을 받으십시오.
• A2 : 메모리 정리에 신경 쓰지는 않지만 applicationWillEnterBackground이 완료 될 때까지 사용자 기본 설정 및 기타 항목이 저장되므로 활성화되었을 때 다시 인식 할 수 있습니다. 다음 번에.

질문 3 : "시뮬레이션 메모리 경고"메뉴 항목을 트리거하는 좋은 전략은 무엇입니까?

• A1 : 모든 앱이 다르기 때문에 일반적인 전략을 세울 수 있는지 여부는 의심 스럽습니다.
• A2 : 특정 사례를 사용하는 방법 : 내 앱에서 앱의 applicationDidReceiveMemoryWarning을 사용하여 메모리 사용량을 줄이지 않고 대신 메모리 경고가 전송되면 iOS도 특정보기에서 viewDidUnload을 호출합니다. 사용하지 않는 컨트롤러. 따라서 일반적으로 메모리 경고 시뮬레이션을 사용하여 내 뷰 컨트롤러 'viewDidLoad 및 viewDidUnload의 균형이 올바르게 조정되었는지 테스트합니다.
• A3 : 구체적인 예 : 내 앱은 탭을 사용하므로 좋아하는 시나리오는 1) 테스트중인 뷰 컨트롤러 (VC)로 탭을 표시하는 것입니다. 2) 다른 탭으로 이동하십시오. 3) 메모리 경고를 시뮬레이션합니다 (iOS는 테스트중인 VC에서 viewDidUnload을 호출합니다). 4) 원래 탭으로 돌아갑니다 (iOS가 테스트중인 VC에서 viewDidLoad을 호출 함).
• A4 : 비슷한 접근법을 사용하려는 경우 iOS에서보기를 언로드 할 수있는 앱을 파악해야합니다. 내 (제한적) 경험에서 이들은 서로 다른 탭에 대한 견해와는 무관 한 견해가되는 경향이 있습니다.

Answer 2

여기에 두 번째 질문에 대한 내 대답은 - 그것은 또한 가지 첫 번째 질문에 답 : 나는 효과적으로 아이 뷰 컨트롤러가 그러한 충분한 메모리를 소모 문제를 재현하는 "메모리 경고를 시뮬레이션"기능을 사용했습니다

을 부모는 자원을 확보해야합니다.

예를 들어, 카메라/사진 라이브러리 (즉, UIImagePickerController)를 표시하는 하위보기 컨트롤러를 고려해보십시오. 이것은 상당한 양의 메모리를 사용합니다. 픽커 컨트롤러가 사용 가능한 것보다 많은 메모리를 소비하는 경우 부모의보기 컨트롤러가 언로드되고 부모 뷰 컨트롤러가 다시 표시되면 (자식이 팝업 될 때) 부모의 viewDidLoad가 다시 호출됩니다. 이는 viewDidLoad에 설정된 모든 변수가 잠재적으로 메모리 누수 또는 불량 포인터로 다시 설정된다는 것을 의미합니다.

"메모리 경고 시뮬레이션"은 이러한 문제를 찾는 데 도움이됩니다. 하위보기 컨트롤러로 가서 "메모리 경고 시뮬레이션"을 선택한 다음보기 컨트롤러를 열고 문제가 있는지 확인할 수 있습니다.

"didReceiveMemoryWarning"은 실제로 그 시점에서 메모리를 해제하려는 것보다 발생 사실을 알리는 것과 더 관련이 있습니다 (imho).