iOS App 이 연속 으로 반 짝 일 때 crash 로 그 를 보고 하 는 방법 에 대한 자세 한 설명

머리말
iOS 프로그램 이 무 너 지면 시스템 은 crash 로 그 를 만들어 장치 에 저장 합 니 다.이 crash 로 그 는 프로그램 이 붕 괴 될 때의 정 보 를 기록 하고 있 으 며,일반적으로 모든 실행 스 레 드 의 스 택 호출 정보(저 메모리 플래시 로그 예외)를 포함 하여 개발 자 포 지 셔 닝 문제 에 도움 이 됩 니 다.
온라인 앱 의 사용자 체험 을 보장 하기 위해 저 희 는 보통 온라인 앱 의 crash 율 을 실시 간 으로 모니터링 합 니 다.spike 가 감지 되면 즉시 원인 을 조사 할 수 있 지만 이 모든 전 제 는 crash 로그 가 정확하게 보고 되 는 것 입 니 다.
crash 로그 에 두 가지 난점 이 있 습 니 다.

crash handler 설치 전 코드 는 절대적 으로 안정 적 이 어야 합 니 다.
로그 수집 기 가 시작 되 기도 전에 crash 가 시작 되면 아무 로그 도 수집 할 수 없습니다.이 점 은 많은 기술 이 없 기 때문에 handler 가 시작 하기 전에 실행 할 수 있 는 코드 를 엄 격 히 제한 할 수 밖 에 없다

App 무한 순환 crash 시 보고
crash 로 그 를 보고 할 때 네트워크 요청 을 보 냅 니 다.요청 이 성공 하기 전에 App 에 crash 가 발생 하면 어떻게 처리 해 야 합 니까?사용 자 는 무한 순환 의 crash 에 빠 질 수도 있다.
이 글 은 두 번 째 상황 이 발생 했 을 때 crash 일 지 를 어떻게 정확하게 보고 하 는 지 소개 한다.
우선,우 리 는 앱 이 시 작 될 때 지난번 에 시작 crash 가 발생 했 는 지 여 부 를 판단 할 수 있 는 비교적 믿 을 만 한 방법 이 필요 하 다.실행 가능 한 사 고 를 소개 하 다.
어떻게 연속 반 짝 임 을 검사 합 니까?
연속 섬 퇴 는 두 가지 원소,섬 퇴 와 연속 을 포함한다.이 두 요소 가 동시에 갖 춰 져 있어 야 로그 업로드 에 영향 을 줄 수 있 습 니 다.섬 퇴 의 정 의 는 간단하게
앱 충돌 시간-  app 시작 시간<=5s(또는 기타 threshold)
연속 적 으로 적어도 두 번 이상 연속 적 으로 나타 나 는 것 으로 정의 된다.보통 두 번 이면 충분 하 다.사용자 가 두 번 연속 반 짝 임 을 겪 으 면 시 도 를 포기 하 는 경우 가 많다.
우 리 는 몇 개의 특수 한 시간 대 timestamp 를 기록 함으로써 App crash 장면 에서 의 생명 주 기 를 복원 하려 고 할 수 있다.

App 시작 timestamp,launchTs 로 정의
App 이 시 작 될 때마다 현재 시간 을 기록 하고 시간 배열 을 기록 합 니 다

App crash timestamp,crashTs 로 정의
App 이 시 작 될 때마다 crash 채집 라 이브 러 리 를 통 해 지난번 crash report 의 시간 스탬프 를 가 져 와 시간 배열 에 기록 합 니 다

App 정상 종료 timestamp,terminateT 로 정의
앱 은 UIApplication WillTerminate Notification 알림 을 받 았 을 때 현재 시간 스탬프 를 기록 하고 시간 배열 을 기록 합 니 다.앱 종료 행위 의 시간 스탬프 가 정확하게 기록 되 지 않 는 경우 도 많 습 니 다

terminatets 를 기록 하려 는 이 유 는 사용자 가 App 을 시작 한 후 즉시 수 동 kill app 을 사용 하 는 특수 한 상황 을 제거 하기 위해 서 입 니 다.만약 우리 가 위의 세 개의 타임 스탬프 를 정확하게 기록 했다 면,우 리 는 App crash 행위 와 관련 된 타임 라인 을 얻 을 수 있 습 니 다.예 를 들 면:
launchTs => crashTs => launchTs => terminateTs
혹은
launchTs => launchTs => launchTs
혹은
launchTs => crashTs => launchTs => crashTs => launchTs
스스로 뇌 동 위의 세 가지 타임 라인 의 행동 특징 을 살 펴 보 세 요.세 번 째 타임 라인 은 두 번 연속 crash 로 보 이 는 것 이 분명 하 다.우 리 는 시간 간격 을 두 고 판단 하면 두 번 연속 으로 반 짝 이 는 지 아 닌 지 를 알 수 있다.두 crashTs 사이 에 terminateT 가 존재 한다 면 연속 적 인 반 짝 임 으로 여 겨 져 서 는 안 됩 니 다.검사 코드 가 비교적 간단 해서 나 는 붙 이지 않 겠 다.
이 타임 라인 은 crash 와 관련 된 App 시작 과 종료 행 위 를 기록 할 뿐 기록 되 지 않 은 특별한 시간 대도 많 습 니 다.예 를 들 어 App 이 프론트 데스크 에서 out of memory(FOOM)가 발생 하고 App 이 프론트 데스크 메 인 thread 에 걸 려 시스템 Watch Dog 에 의 해 죽 임 을 당 했 습 니 다.iOS 시스템 이 업그레이드 되 었 을 때 App 이 강 살 되 었 고 App 이 App Store 에서 업그레이드 되 었 을 때 강 살 되 었 습 니 다.이러한 특수 한 시간 대 는 기록 되 지 않 았 지만,이러한 것들 은 우리 의 앱 연속 플래시 검사 에 영향 을 주지 않 기 때문에 무시 할 수 있 습 니 다.
여기 서 주의 하 는 것 은 시작 할 때 disk 에서 타임 라인 기록 을 읽 어야 하기 때문에 디스크 읽 기와 쓰기 와 관련 되 어 앱 의 시작 시간 에 영향 을 줄 수 있 습 니 다.하나의 최적화 점 은 매번 기록 시간 에 비교적 오래된 timestamp 를 제거 하 는 것 입 니 다.예 를 들 어 최근 5 개의 시간 스탬프 만 기록 하 는 것 입 니 다.또는 crash 로 그 를 읽 지 못 했 을 때 연속 플래시 검사 의 전체 프로 세 스 를 시작 하지 않 아 도 됩 니 다.
다음은 연속 적 인 플래시 가 감지 된다 고 가정 하고 로 그 를 계속 올 리 는 방법 을 살 펴 보 자.
Crash 로그 업로드 동기 화
가장 직 설 적 인 방법 은 앱 의 코드 가 계속 실행 되 기 전에 로그 가 업로드 되 기 를 기다 리 는 것 입 니 다.
네트워크 요청 을 동기 화 할 까요?이것 은 UI 스 레 드 가 걸 리 고 네트워크 가 나 쁜 장면 에서 시스템 watch dog 에 의 해 강 살 될 수 있 으 며 분명 바람 직 하지 않 습 니 다.
우 리 는 여전히 비동기 네트워크 요청 을 유지 할 수 있 습 니 다.그러나 UI 스 레 드 의 프로 세 스 를 잠시 중단 하고 전체 App 을 UI 스 레 드 의 runloop 대기 중 에 있 게 합 니 다.네트워크 요청 이 성공 하면 UI 스 레 드 의 기 존 코드 프로 세 스 로 돌아 갑 니 다.
간단 한 실현 을 보면 서 몇 가지 세부 사항 에 주의해 야 한다.우선,우 리 는 App 상호작용 을 추가 해 야 합 니 다.runloop 대기 에 들 어가 면 loading 인터페이스 를 보 여 주 며 사용자 에 게 인내심 을 가지 고 기다 리 라 고 알려 야 합 니 다.그 다음 에 이 대기 시간 이 너무 길 어 서 는 안 됩 니 다.저 는 개인 적 으로 5s 를 초과 하지 않 는 것 을 권장 합 니 다.5s 를 초과 하면 crash 로그 에 올 린 request 가 성공 하 든 안 하 든 앱 의 원래 코드 프로 세 스 를 복원 합 니 다.5s 내 로 그 를 업로드 할 수 없 는 경 우 는 로그 파일 이 너무 크 지 않 는 한 작 아야 합 니 다.
이런 방법의 결함 도 뚜렷 하 다.첫째,변동 이 비교적 크다(기 존 코드 프로 세 스 를 수정 했다).둘째,새로운 UI 상호작용 을 늘 려 야 한다.셋째,사용자 의 대기 시간 을 연장 시 켰 다.
우 리 는 또 다른 교묘 한 방법 을 보 았 다.
배경 프로 세 스 를 사용 하여 Crash 로 그 를 업로드 합 니 다.
사실 가장 이상 적 인 로그 업 로드 는 업 로드 된 request 를 다른 프로 세 스 에 두 는 것 입 니 다.앱 이 또 반 짝 거 려 도 다른 프로 세 스 코드 의 실행 에 영향 을 주지 않 습 니 다.
문 제 는 iOS app 이 모두 Sandbox 환경 에 있 기 때문에 시스템 에서 코드 fork 의 새로운 프로 세 스 를 허용 하지 않 습 니 다.
다행히도 iOS 8 부터 NSURLSession 에 background session 기능 이 추가 되 었 습 니 다.이 기능 은 NSURLSession 이 네트워크 요청 을 단독 프로 세 스에 넣 어 실행 할 수 있 도록 합 니 다.저 는 개인 적 으로 이 특성 디자인 은 원래 일부 앱 배경 에서 음성 영상 을 다운로드 하 는 등 자원 의 체험 을 강화 하기 위해 서 라 고 생각 합 니 다.내 가 실제 테스트 를 해 보 니 다운로드 나 업로드 에 관 계 없 이 우 리 는 네트워크 요청 을 다른 프로 세 스에 넣 을 수 있다 는 것 을 알 게 되 었 다.코드 도 간단 합 니 다.예 를 들 어 제 가 다음 과 같은 테스트 코드 를 쓰 겠 습 니 다.

NSURLSessionConfiguration *config = [NSURLSessionConfiguration backgroundSessionConfigurationWithIdentifier:@"com.mrpeak.background.crashupload"];
NSURLSession *session = [NSURLSession sessionWithConfiguration:config delegate:self delegateQueue:[NSOperationQueue new]];
NSURL *url = [NSURL URLWithString:@"https://images.unsplash.com/photo-1515816949419-7caf0a210607?ixlib=rb-0.3.5&ixid=eyJhcHBfaWQiOjEyMDd9&s=f46b60857b4826e733da34993ec26a2f&auto=format&fit=crop&w=1534&q=80"];
NSURLSessionDownloadTask *task = [session downloadTaskWithURL:url];
[task resume];

exit(0);

실행 후,우 리 는 console 에서 다음 로 그 를 볼 수 있 습 니 다.

nsurlsessiond 프로 세 스 가 네트워크 요청 을 어떻게 해 주 는 지 똑똑히 볼 수 있 으 며,이상 하 게 종 료 된 앱 을 깨 우려 고 합 니 다.
물론 이런 가장 이상 적 인 방식 도 처리 해 야 할 세부 사항 이 있다.예 를 들 어 앱 의 어떤 crash 로그 가 업로드 되 었 는 지 알려 주 고 로 컬 에서 제거 하 는 방법 입 니 다.연속 적 으로 반 짝 이 는 앱 은 극도로 불안정 한 상태 이기 때문에 어떤 코드 논리 도 순조롭게 완성 되 지 못 한다.
저 는 개인 적 으로 배경 프로 세 스에 보 고 된 로그 에 특별한 flag 를 추가 한 다음 에 배경 에서 client request ID 와 이 flag 를 통 해 다시 정리 하 는 것 이 이상 적 이 라 고 생각 합 니 다.
온라인 앱 의 연속 적 인 반 짝 임 은 매우 열악 하고 무 서운 고장 이다.무 서운 점 은 대면 적의 연속 적 인 반 짝 임 이 발생 하고 감 시 를 받 지 못 할 때 당신 은 작은 곡 을 흥 얼 거 리 며 코드 를 두 드 리 고 있다 는 것 이다.사장 은 갑자기 자신의 핸드폰 에 앱 이 작 동 하지 않 는 다 는 것 을 알 게 되 었 다.앱 스토어 를 열 었 을 때 평가 가 쏟 아 지 는 것 을 발견 했다.주류 앱 이 라면 과학기술 뉴스 에 도 등장 할 수 있다.어두컴컴 한 큰 솥 이 모양 을 이 루 고 있 을 것 이 라 고 예상 하기 어렵 지 않다.다음 앱 업그레이드 안내 에는'파이 어 피 터'가 꼭 나 옵 니 다.
총결산
이상 은 이 글 의 전체 내용 입 니 다.본 논문 의 내용 이 여러분 의 학습 이나 업무 에 어느 정도 참고 학습 가치 가 있 기 를 바 랍 니 다.궁금 한 점 이 있 으 시 면 댓 글 을 남 겨 주 셔 서 저희 에 대한 지지 에 감 사 드 립 니 다.