iOS 는 다 중 스 레 드 를 어떻게 효율적으로 사용 합 니까?

1.다 중 스 레 드 약술
스 레 드 는 프로그램 실행 흐름 의 최소 단위 입 니 다.하나의 스 레 드 는 고유 ID,프로그램 카운터(Program Counter),레지스터 집합,스 택 을 포함 합 니 다.같은 프로 세 스 는 프로 세 스 의 전역 변수 와 데 이 터 를 공유 할 수 있 습 니 다.
이 PC(Program Counter)는 현재 명령 주 소 를 가리 키 며,PC 업 데 이 트 를 통 해 프로그램 을 실행 합 니 다.한 스 레 드 는 같은 시간 에 하나의 명령 만 수행 할 수 있 습 니 다.물론 우 리 는 스 레 드 와 프로 세 스 가 모두 가상 개념 이라는 것 을 알 고 있 습 니 다.실제로 PC 는 CPU 핵심 에 있 는 레지스터 이 고 실제 존재 하기 때문에 하나의 CPU 핵심 이 같은 시간 에 하나의 스 레 드 만 실행 할 수 있다 고 할 수 있 습 니 다.
다 중 프로세서 장치 든 다 중 핵 장치 든 개발 자 는 CPU 의 핵심 수량 에 만 관심 을 가 져 야 하 며 물리 적 구성 에 관심 을 가 질 필요 가 없다.CPU 의 핵심 수량 은 유한 합 니 다.즉,한 장치 가 동시에 실행 하 는 스 레 드 수량 이 유한 합 니 다.스 레 드 수량 이 CPU 의 핵심 수량 을 초과 할 때 하나의 CPU 핵심 은 여러 스 레 드 를 처리 해 야 합 니 다.이 행 위 를 스 레 드 스케줄 이 라 고 합 니 다.
스 레 드 스케줄 링 은 쉽게 말 하면 하나의 CPU 핵심 이 돌아 가면 서 각 스 레 드 를 각각 한 동안 실행 하 게 하 는 것 이다.물론 이 중간 에는 복잡 한 논리 가 담 겨 있 으 니 나중에 다시 분석 하 자.
2.다 중 스 레 드 의 최적화 사고
모 바 일 개발 에서 시스템 의 복잡성 으로 인해 개발 자 들 은 모든 스 레 드 가 진정 으로 병행 되 기 를 기대 할 수 없 으 며 개발 자 들 도 XNU 가 언제 커 널 스 레 드 를 전환 하고 언제 스 레 드 스 케 쥴 링 을 하 는 지 잘 모 르 기 때문에 개발 자 들 은 스 레 드 스 케 쥴 링 의 상황 을 자주 고려 해 야 합 니 다.
1.스 레 드 전환 감소
스 레 드 수량 이 CPU 핵심 수량 을 초과 하면 CPU 핵심 은 스 레 드 스케줄 링 을 통 해 사용자 의 상태 스 레 드 를 전환 합 니 다.컨 텍스트 전환(레지스터 데이터,스 택 등)이 있 고 너무 많은 컨 텍스트 전환 은 자원 비용 을 가 져 옵 니 다.커 널 스 레 드 전환 이론 적 으로 성능 부담 은 아니 지만 개발 에 서 는 스 레 드 전환 을 최대한 줄 여야 한다.
2.스 레 드 우선 순위 평가
일반적으로 스 레 드 스케줄 링 은 윤전 법 을 제외 하고 우선 순위 스케줄 링 방안 도 있 는데 스 레 드 스케줄 링 을 할 때 높 은 우선 순위 의 스 레 드 가 더욱 일찍 실 행 됩 니 다.두 가지 개념 이 명확 해 야 한다.
4.567917.IO 밀집 형 스 레 드:자주 기다 리 는 스 레 드,기다 릴 때 시간 영 화 를 양보 합 니 다4.567917.CPU 밀집 형 스 레 드:기다 리 지 않 는 스 레 드 는 장시간 CPU 를 차지 하 는 것 을 의미한다.
특수 한 장면 에서 여러 개의 CPU 밀집 형 스 레 드 가 모든 CPU 자원 을 차지 하고 그들의 우선 순위 가 비교적 높 으 며 이때 우선 순위 가 낮은 IO 밀집 형 스 레 드 는 지속 적 으로 기다 리 고 스 레 드 가 굶 어 죽 는 현상 이 발생 할 것 이다.물론 스 레 드 가 굶 어 죽지 않도록 시스템 은'소외'스 레 드 의 우선 순 위 를 점차적으로 향상 시 킬 것 이다.IO 밀집 형 스 레 드 는 보통 CPU 밀집 형 스 레 드 보다 우선 순위 향상 을 얻 기 쉽다.
시스템 이 자동 으로 이런 일 을 하지만 이것 은 결국 시간 을 기다 리 게 하고 사용자 체험 에 영향 을 줄 수 있다.그래서 필 자 는 개발 자가 두 가지 측면 에서 우선 순위 문 제 를 평가 해 야 한다 고 생각한다.
4.567917.IO 밀집 형 스 레 드 우선 순위 가 CPU 밀집 형 스 레 드 보다 높 습 니 다4.567917.긴급 한 임 무 를 더욱 높 은 우선 순 위 를 가지 게 한다예 를 들 어 한 장면:대량의 그림 이 비동기 적 으로 압축 을 푸 는 작업,압축 을 푸 는 그림 은 사용자 에 게 즉시 피드백 할 필요 가 없 으 며,동시에 대량의 비동기 적 으로 디스크 캐 시 를 조회 하 는 작업 도 있 으 며,디스크 캐 시 작업 이 완 료 된 후에 사용자 에 게 피드백 해 야 한다.
그림 압축 해 제 는 CPU 밀집 형 스 레 드 에 속 하고 조회 디스크 캐 시 는 IO 밀집 형 스 레 드 에 속 하 며 후 자 는 사용자 에 게 더욱 긴급 하 게 피드백 해 야 하기 때문에 그림 압축 해제 스 레 드 의 우선 순 위 를 낮 추고 디스크 캐 시 를 조회 하 는 스 레 드 우선 순위 가 높 아야 합 니 다.
주의해 야 할 것 은 대량의 비동기 임 무 는 CPU 가 만부 하 연산 을 할 가능성 이 높다 는 것 을 의미한다.만약 에 CPU 자원 이 충분 한 상황 에서 우선 순위 문 제 를 처리 할 필요 가 없다 는 것 이다.
3.메 인 스 레 드 임무 의 최적화
일부 업 무 는 UI 류 구성 요소 의 초기 화 와 레이아웃 등 메 인 스 레 드 에 만 쓸 수 있 습 니 다.사실은 이 분야 의 최적화 가 비교적 많 습 니 다.업계 에서 말 하 는 성능 최적화 는 대부분이 메 인 스 레 드 의 압력 을 줄 이기 위해 서 입 니 다.다 중 스 레 드 최적화 의 범주 에서 벗 어 난 것 같 습 니 다.다음은 메 인 스 레 드 임 무 를 바탕 으로 하 는 관 리 를 대체적으로 몇 가지 나열 하 겠 습 니 다.
메모리 재 활용
메모리 복 구 를 통 해 메모리 개발 시간 소 모 를 줄 이 는 데 사 용 됩 니 다.이것 은 시스템 UI 류 구성 요소 에서 광범 위 하 게 응용 되 고 있 습 니 다.예 를 들 어 UITableViewCell 의 재 활용 입 니 다.또한 메모리 개발 을 줄 인 다 는 것 은 메모리 방출 을 줄 이 고 CPU 자원 을 절약 할 수 있다 는 것 을 의미한다.
게으름뱅이 로 딩 퀘 스 트
UI 구성 요소 가 주 스 레 드 에서 초기 화 되 어야 하 는 만큼 사용 할 때 초기 화 해 야 합 니 다.swift 의 쓰기 시 복사 도 비슷 한 사고 입 니 다.
미 션 분할 정렬 실행
Runloop 이 곧 끝 날 것 이라는 통 지 를 감청 함으로써 대량의 임 무 를 분리 하여 매번 Runloop 순환 주기 에 소량의 임 무 를 수행 합 니 다.사실은 이런 최적화 사 고 를 실천 하기 전에 임 무 를 비동기 스 레 드 에 놓 을 수 있 는 지 를 생각해 야 한다.이런 극단 적 인 최적화 수단 을 사용 하 는 것 이 아니 라.
메 인 코스 가 비어 있 을 때 임 무 를 수행 합 니 다

//         

`dispatch_async(dispatch_get_main_queue(), ^{

//            

});

자물쇠
다 중 스 레 드 는 스 레 드 안전 문 제 를 가 져 올 수 있 습 니 다.원자 작업 이 업 무 를 만족 시 키 지 못 할 때 각종'자물쇠'를 사용 하여 메모리 의 읽 기와 쓰기 안전 을 확보 해 야 합 니 다.
자주 사용 하 는 자 물 쇠 는 상호 배척 자물쇠,읽 기 쓰기 자물쇠,공전 자물쇠 가 있 습 니 다.일반적인 상황 에서 iOS 개발 에서 상호 배척 자물쇠 pthreadmutex_t、dispatch_semaphore_t,읽 기와 쓰기 자물쇠 pthreadrwlock_t 는 대부분의 수 요 를 만족 시 킬 수 있 고 성능 도 좋다.
잠 금 을 읽 는 데 실 패 했 을 때 스 레 드 는 두 가지 상태 가 있 을 수 있 습 니 다.

공전 상태:스 레 드 가 빈 작업 순환 을 수행 하고 자 물 쇠 를 사용 할 수 있 을 때 바로 자 물 쇠 를 가 져 옵 니 다

4

연결 상태:스 레 드 가 걸 려 있 고 잠 금 이 사용 가능 할 때 다른 스 레 드 가 깨 워 야 합 니 다

스 레 드 를 깨 우 는 데 시간 이 걸 립 니 다.스 레 드 공전 은 CPU 자원 을 소모 하고 시간 이 길 수록 소모 가 많 습 니 다.이 를 통 해 공전 은 소량의 작업 에 적합 하고 대량의 작업 에 적합 하 다 는 것 을 알 수 있 습 니 다.
실제로 상호 배척 자물쇠 와 읽 기와 쓰기 자 물 쇠 는 모두 공전 자물쇠 의 특성 을 가지 고 있다.그들 은 자 물 쇠 를 가 져 오 는 데 실 패 했 을 때 잠시 공전 한 후에 야 걸 리 고 공전 자물쇠 도 영원히 공전 하지 않 으 며 특정한 공전 시간 이 지난 후에 도 걸 리 기 때문에 보통 의도 적 으로 공전 자 물 쇠 를 사용 하지 않 아 도 된다.Casa Taloyum 은 블 로그 에서 상세 하 게 설명 했다.
1.OSSpinLock 우선 순위 반전 문제
우선 순위 반전 개념:예 를 들 어 두 개의 스 레 드 A 와 B,우선 순위 A2.자물쇠 피하 기
흔히 볼 수 있 는 장면 은 같은 스 레 드 에서 잠 금 으로 인 한 잠 금 을 반복 적 으로 가 져 오 는 것 입 니 다.이 경우 재 귀 잠 금 으로 처리 할 수 있 습 니 다.pthreadmutex_t 사용 pthreadmutex_init_recursive()방법 을 초기 화하 면 재 귀 자물쇠 의 특성 을 가 질 수 있 습 니 다.
pthread 사용mutex_trylock()등 자 물 쇠 를 가 져 오 는 방법 은 자 물 쇠 를 효과적으로 피 할 수 있 습 니 다.
3.잠 금 작업 최소 화
개발 자 는 업 무 를 충분히 이해 하고 잠 금 에 포 함 된 코드 영역 을 최대한 줄 여야 합 니 다.스 레 드 안전 문제 가 발생 하지 않 는 코드 는 잠 금 으로 보호 하지 마 십시오.그래 야 동시 잠 금 의 성능 을 향상 시 킬 수 있 습 니 다.
4.재 접속 불가 방법의 안전 에 항상 주의
한 가지 방법 이 다시 들 어 갈 수 있 을 때 안심 하고 대담 하 게 사용 할 수 있 습 니 다.만약 에 한 가지 방법 이 다시 들 어 갈 수 없다 면 개발 자 는 이 방법 이 여러 개의 스 레 드 에 접근 하 는 상황 이 있 는 지 주의해 야 합 니 다.있 으 면 성실 하 게 스 레 드 자 물 쇠 를 추가 해 야 합 니 다.
5.컴 파일 러 의 과도 한 최적화
컴 파 일 러 는 효율 을 높이 기 위해 변 수 를 레지스터 에 쓰기 위해 잠시 쓰 지 않 을 수도 있 습 니 다.다음 에 사용 하기에 편리 합 니 다.코드 한 마디 가 명령 으로 바 뀌 는 것 이 한 가지 가 아니 라 는 것 을 알 고 있 기 때문에 변 수 를 레지스터 에 기록 하 는 과정 에서 이 변 수 는 다른 스 레 드 에 의 해 읽 혀 졌 을 수도 있 습 니 다.컴 파일 러 역시 순서 와 무관 하 다 고 생각 하 는 명령 을 효율 적 으로 바 꾸 기 위해 순 서 를 바꾼다.
이상 은 자 물 쇠 를 합 리 적 으로 사용 하 는 곳 이 여전히 안전 하지 않 을 수 있 습 니 다.volatile 키 워드 는 이러한 문 제 를 해결 할 수 있 습 니 다.컴 파일 러 가 효율 적 으로 변 수 를 레지스터 에 캐 시 하고 제때에 쓰 지 않 는 것 을 막 을 수 있 고 컴 파일 러 가 volatile 수식 변 화 를 조작 하 는 명령 순 서 를 조정 하 는 것 도 막 을 수 있 습 니 다.
원자 자체 증가 함수 에 유사 한 응용 이 있다.
 6.CPU 난 서 실행
CPU 도 효율 성 을 높이 기 위해 명령 의 순 서 를 교환 하여 잠 금 코드 도 안전 하지 않 을 수 있 습 니 다.이런 문 제 를 해결 하려 면 메모리 장벽 을 사용 할 수 있 습 니 다.CPU 가 메모리 장벽 을 넘 으 면 레지스터 가 변수 에 대한 분 배 를 새로 고 칠 수 있 습 니 다.
이상 은 iOS 가 어떻게 효율 적 으로 사용 하 는 다 중 스 레 드 에 대한 상세 한 내용 입 니 다.ios 다 중 스 레 드 에 관 한 자 료 는 저희 의 다른 관련 글 에 관심 을 가 져 주 십시오!