많은 수의 요소가있는 UIPickerViews를 사용하면보기 전환이 복잡해질 것입니다.

Question

XCode의 유틸리티 응용 프로그램 프로젝트 템플릿으로 작성된 매우 간단한 응용 프로그램이 있습니다. 내 MainView에는 두 개의 UIPickerView 구성 요소와 두 개의 버튼이 있습니다. FlipSideView에는 또 다른 UIPickerView가 있습니다.

기본보기의 피커는 각각 4 개의 세그먼트가 있고 각 세그먼트에는 8 개의 행이 있습니다. 플립 측면의 선택 도구에는 8 개의 행이있는 단 하나의 세그먼트가 있습니다. 모든 선택 도구의 모든 행은 텍스트입니다.

그냥이 설정을 사용하면 애니메이션을 실제로 시작하기 전에 단추를 누르면보기가 앞뒤로 바뀝니다. 애니메이션이 실제로 필요한 것보다 빨리 움직이는 것처럼 보입니다. 잃어버린 시간.

인터페이스 빌더에서 픽커를 제거하고 휴대 전화에 앱을로드하면 애니메이션이 자연스러워 보입니다. 나는 또한 한 피커 (플립 사이드 하나)를 시도하고 것들이 여전히 정상적인 것. 그래서 현재의 이론은 기본보기에 관련된 객체의 수가 원인이라는 것입니다. 문제는 그것이 많은 것 (4 x 8 x 2 = 64)이라고 생각하지 않지만, 나는 완전히 틀릴 수 있습니다. 이것은 거의 내 첫 번째 애플 리케이션이다 그래서 어쩌면 내가 뭔가를 심하게 잘못하고있다, 또는 어쩌면 전화는 내가 생각했던 것보다 훨씬 제한된 처리가 있습니다.

pickerView : viewForRow : forComponent : reusingView를 사용하여 피커 뷰를 만들려고합니다.이 뷰가 더 잘 수행되는지 확인하려면이 시간이 낭비인지 확실하지 않습니다.

제안 사항? 3.1.2

Answer 1

에

감사 루이

P.S : 3 세대 휴대 전화에서 테스트 행과 구성 요소의 수는 피커 뷰 자체의 성능과 거의있다. 피커 뷰는 테이블처럼 작동하지만 실제로 메모리에 구성 요소와 행 수가 없습니다. 대신, 그들은 한 번에 화면에 표시되는 동일한 소수의 뷰를 바꿔 재사용합니다. 따라서 한 번에 5 개의 행을 표시하는 4 개의 구성 요소가있는 경우 각 구성 요소에 수백 개의 논리 행이 있더라도 피커 뷰에는 20 개 이상의 뷰가 저장되지 않습니다.

따라서 피커 뷰의 데이터 소스에있는 논리 요소의 수는 시각적 성능과 관련이 없습니다.

피커 뷰 및 전환과 함께 표시되는 내용이 확실치 않지만 선택기 뷰를로드하고 구성하는 사용자 지정 코드의 어딘가에서 덤프가 발생했을 가능성이 가장 높습니다. 중단 점/로그를 설정하여 전환하는 동안 시간을 ​​보내고 있는지 확인합니다.