내 앱에서 다소 큰 문자열 크기 계산이 발생했습니다 (각 앱은 500ms 가량 소요되며 사용자가 내 앱에서 새로운 "페이지"로 스크롤하면 발생합니다 계산은 한 번만 실행하면되고 (동일한 데이터로 이후 실행을 위해 캐시 될 수도 있기 때문에) 페이지 당 한 번만 지연이 발생합니다.iPhone에서 백그라운드 스레드에서 문자열 크기 계산하기
어쨌든, 나는 여전히 차단하지 않습니다. 이 유형의 작업에 대한 UI, 그것은 스레드를 사용하여 비명을 지르지 만 UIKit은 다른 스레드에서 사용하도록되어 있지 않다는 것을 알고 있습니다. (NSString은 UIKit에 속하지 않지만 문자열 크기 조정 메서드는 UIKitAdditions의 일부입니다. ...)
So 어떻게해야합니까? UI를 차단하지 않고 안전하게하는 가장 좋은 방법은 무엇입니까?
내가 틀릴 수도 있지만 다른 스레드에서 UIKit을 사용하는 것을 금지하는 것이 GUI의 작동 (단일 스레드)과 관련이 있으며 일반적으로 GUI 자체가 영향을받는 상황에만 적용됩니다.
sizeWithFont: 메서드는 실제로 GUI에 영향을 미치지 않으므로 다른 스레드에서이 메서드를 호출 할 때 문제가 발생할 것이라고 생각하지 않습니다.
어쩌면이 방법이 장면에서 어떻게 작동하는지 더 많은 경험을 가진 iPhone 사용자가 내 생각을 확인하거나 나를 똑바로 세울 수 있습니다.
일부 호출은 멀티 스레드 호출을 제대로 처리하지 못하는 것일 수도 있습니다. 즉, 작업에서 시도해보고 어떤 일이 일어 났는지보고 반복적으로 반복적으로 테스트하여 어떤 방식 으로든 실패를 트리거하려고합니다 당신이 UI를 연습하는 동안 계산. –
Kendall의 덧글에 +1. UIKit 메서드는 단일 스레딩을 염두에두고 작성 되었기 때문에 멀티 스레딩을 제대로 처리하지 못할 수 있습니다. –
항상 셀 높이 등을 계산하기 위해 -sizeWithFont과 친구들을 백그라운드 스레드에서 사용했습니다. 정상적으로 작동했습니다. 그러나 iOS 6.0부터 간헐적으로 발생합니다 crashes. 백그라운드에서 UI 레이아웃을 계산하는 데 필수적인 성능 최적화이기 때문에 이러한 문제가 해결되기를 바랍니다.
예, 버그는 Apple Bugreporter에서 계속 열립니다. –
그리고 여전히 iOS 8에 존재합니다. - 난 그냥 내 앱에서 우연히 만났습니다. 수년간'-sizeWithFont'를 백그라운드 스레드에서 호출하는 것처럼 실행되었지만,'-sizeWithFont'라는 두 개의 스레드가 동시에 충돌하여 응용 프로그램이 손상되도록 타이밍을 맞췄습니다. –
이것은 일반적으로 스레딩 대신 제안 된 경로이지만 작업을 수행 할 위치, 주 대기열 또는 다른 대기열에 대한 질문은 다루지 않습니다. 주 대기열은 순차적이므로 올바르게 호출 한 경우 주 스레드에서 실행하는 것과 동일한 차단 영향을줍니다. –
필자는 개인적으로 사용하지 않았지만 적어도 문서에 따르면 반드시 차단하지는 않습니다. "NSOperation 클래스의 isConcurrent 메서드는 작업이 시작 또는 종료되는 스레드와 관련하여 동 기적으로 또는 비동기 적으로 실행되는지 여부를 알려줍니다 메서드가 호출되었습니다. 기본적으로이 메서드는 NO를 반환합니다. 즉 호출 스레드에서 작업이 동 기적으로 실행됨을 의미합니다. " –
죄송합니다. 사실 내 의견에 디스패치 대기열을 의미했습니다. 문제의 문제는 더 안전합니다 sizeWithFont를 호출하는 것이 안전합니다 : 주 스레드 이외의 다른 작업 큐 또는 디스패치 큐를 사용하여 스레딩을 수행해야하지만 주 스레드에 있어야하는지 여부는 문제가되지 않습니다. UI 스레드 또는 아닙니다. –