Xcode 및 기기 내 감지를 사용하여 중단 추적

♪ 부드러운 힙합 음악 ♪ ♪ 겨안녕하세요, John Crowson입니다 여기 애플의 성능 도구 팀에서 소프트엔지니어로 일하고 있죠 이번 강의에서는 여러분께 Xcode로 앱 정지를 추적하는 여러 가지 새로운 도구와 기기 내 정지 감지 기능을 알아볼게요 앱 개발의 여러 단계를 살펴보고 각 단계에서 어떤 도구가 적합한지 여러분께 안내해 드리겠습니다 이 강의는 네 가지 섹션으로 나뉩니다 먼저 정지의 정의를 설명할게요 그다음엔 정지를 발견하고 진단하는 데 앱을 개발하는 동안 도움이 되는 도구를 소개할게요 베타 테스트를 할 때와 출시한 이후에도요 시작할까요? 우리 팀이 개발하는 새 앱 얘기를 해 보죠 '푸드 트럭'이에요 푸드 트럭 운영 앱입니다 도넛을 파는 푸드 트럭이죠 제가 만든 도넛 유형을 소개해 드릴게요

도넛 목록을 스크롤하는 데 엄청 오래 걸렸네요 응답이 느려졌고 제 터치에 반응을 안 했어요 애플에서는 응답이 없는 순간을 '정지'라고 부릅니다 앱의 메인 스레드는 사용자의 조작을 처리하고 뷰 콘텐츠를 업데이트하는 역할을 합니다 앱 정지가 보고되는 건 메인 스레드가 작업 수행 중이거나 다른 스레드 혹은 시스템 리소스를 대기 중이라서 뷰 콘텐츠 업데이트가 최소 250밀리초간 지연될 때입니다 또 정지가 해결될 때까지 메인 스레드는 새로운 사용자 조작을 처리할 수 없습니다 사용자에겐 앱이 완전히 멈춘 것으로 보이죠 앱의 응답성을 높이는 건 긍정적인 사용자 경험을 제공하는 데 매우 중요합니다 지속적으로 응답이 없는 앱은 사용자가 앱 사용을 중단하거나 다른 앱으로 갈아타는 결과를 불러오죠 경우에 따라서는 여러분의 앱을 삭제하고 부정적인 리뷰를 남길지도 몰라요 따라서 앱의 정지를 추적하는 건 여러분의 사용자층을 구축하고 유지하는 데 중요합니다 앱이 응답하는 경험을 제공할 때 사람들이 앱 사용을 즐길 수 있으니까요

정지에 대한 더 많은 정보와 정지의 원인 여러분의 코딩에서 정지를 없애는 전략은 '앱 정지를 이해하고 제거하기' 강의가 WWDC21 영상에 있으니 확인해 보세요 앱 개발 과정은 세 가지 단계로 나눌 수 있습니다 먼저 Xcode를 사용해서 최신 앱 버전을 개발합니다 다음은 베타 환경에서 앱을 테스트하고 피드백을 수집하는 단계입니다 예를 들면 여러분 기기에 있는 개발자 서명 앱이나 TestFlight을 통해 배포한 앱을 말하는 거죠 마지막 단계는 App Store에 최신 앱 버전을 내놓는 겁니다 사전 대비가 철저한 개발자라고 해도 새로운 정지 문제는 어느 단계든 나타날 수 있어요 따라서 각 단계에서 문제를 해결할 도구를 파악하는 게 중요합니다 iOS 16과 Xcode 14 이전에는 앱의 정지를 발견하고 진단하는 도구를 두 가지 제공했어요 MetricKit는 베타 앱 또는 공개 출시 앱의 개별 사용자한테서 집계되지 않는 정지율 메트릭과 진단 보고서 수집을 지원하는 프레임워크입니다 Xcode Organizer는 앱을 공개 출시한 후 사용자에게서 집계된 정지율 메트릭을 제공하죠 이 도구들에는 다룰 수 없는 공백이 있어요 특히 앱을 개발 중이거나 출시된 앱의 어떤 소스 코드가 정지율 메트릭을 증가시켰는지 파악하려고 할 때 말이죠 iOS 16과 Xcode 14에서 도움이 되는 새로운 도구 몇 가지를 소개했습니다 자세하게 들여다보기 전에 먼저 각 도구를 간단하게 소개할게요 Xcode의 스레드 성능 검사는 앱을 디버깅하는 동안 능동적으로 추적하지 않고도 정지를 일으키는 스레드 문제를 알립니다 Xcode의 탐지기는 앱을 추적할 때 정지를 감지하고 표시하죠 기기 내 정지 감지 기능은 Xcode를 사용하지 않거나 추적하지 않을 때도 정지 감지 기능을 제공하고 개발자 서명 앱을 사용하거나 TestFlight 앱을 사용할 때 실시간 정지 알림과 진단을 지원합니다 마지막으로 Xcode의 Organizer에서는 정지 리포트를 지원합니다 사용자로부터 집계된 정지 진단을 제공하죠 이제 정지의 개념을 배웠고 다양한 단계에서 일어난다는 것도 알았으니 Xcode로 앱을 개발하는 과정에서 정지를 어떻게 추적하는지 다뤄 보겠습니다 Xcode 14의 새로운 스레드 성능 검사 도구는 Xcode Issue Navigator에서 우선 순위 역전이나 메인 스레드의 비 UI 작업을 감지해서 알려 줍니다 둘 다 정지의 일반적 원인이죠 이제 Xcode로 돌아와서 푸드 트럭 앱에서 제가 만든 도넛을 스크롤할 때 나타났던 정지 현상을 진단하려고 합니다 앱을 빌드, 실행하고 사용자 조작을 반복했을 때 스레드 성능 검사 도구가 우선 순위 역전으로 인한 정지 위험을 경고했습니다 우선 순위가 높은 스레드가 우선 순위가 낮은 스레드와 동기화를 시도했다는 뜻입니다 즉 우리가 발견한 정지는 메인 스레드가 우선 순위가 낮은 다른 스레드 뒤에서 대기하면서 발생했다는 것을 보여 줍니다 앱의 메인 스레드에서 우선 순위 역전과 비 UI 작업을 탐지하려면 테스트 계획의 진단 섹션에서 스레드 성능 검사 도구를 활성화하세요 스레드 성능 검사 경고로 앱 정지의 잠재적 원인을 찾았어요 그런데 더 자세한 분류를 위해 정지한 시간 동안 다른 스레드가 뭘 했는지 알고 싶습니다 다른 도구를 사용해서 더 깊이 들여다보죠 Instrument의 Time Profiler는 호출 스택을 제공하면서 앱의 각 스레드가 시간에 따라 뭘 하고 있었는지 알 수 있습니다 Xcode 14에 추가된 기능으로 Time Profiler는 정지를 감지하고 해당 프로세스 트랙에 표시합니다 푸드 트럭 앱에서 저는 Time Profiler를 사용해 도넛을 스크롤할 때 발생한 정지 현상이 메인 스레드의 우선 순위 역전으로 발생했는지 확인하고 메인 스레드를 대기하게 만든 낮은 우선 순위 스레드가 어떤 건지 파악할 겁니다 Xcode의 Product 메뉴에 있는 Profile로 갑니다 앱을 릴리스용으로 빌드하고 앱을 대상으로 이미 설정한 Instruments를 실행됩니다 전 Time Profiler 템플릿을 실행하고 푸드 트럭 앱에서 문제가 되었던 사용자 조작의 추적 과정을 녹화하기 시작하죠

정지 현상이 감지되고 타임라인에 표시된 걸 봅니다 정지가 지속된 시간은 문제의 심각성을 평가하는 데 도움이 되기도 하죠 그다음 정지 간격을 세 번 클릭하면 정지 지속 시간에 대한 시간 필터가 생성되고 하단의 상세 화면에서 선택된 시간 간격 동안 발생하는 사건만을 필터링합니다 또 다른 트랙에서 이 기간에 무슨 일이 있었는지도 쉽게 확인할 수 있죠 처음 깨달은 건 정지 사이의 간격 동안 메인 스레드의 CPU 사용량이 거의 없다는 거예요 즉 메인 스레드가 응답하지 않은 건 너무 많은 작업을 수행해서가 아니라 다른 스레드를 대기했기 때문이란 거죠 이건 아까 보여 드린 스레드 성능 검사 도구의 우선 순위 역전 경고와도 일치합니다 다음은 정지된 동안 CPU 사용량이 많은 스레드가 보입니다 이게 메인 스레드가 대기하고 있던 스레드겠죠 다음 단계는 정지된 동안 작업자 스레드가 뭘 했는지 확인하고 우선 순위 역전을 해결하는 겁니다 Instruments의 정지 감지 및 표시 기능은 앱의 정보를 수집하는 동안 발생하는 모든 정지 현상을 표면화하는 좋은 방법이에요 기본적으로 Time Profiler와 CPU Profiler를 통해 확인할 수 있어요 따로 새롭게 나와 있는 정지 추적 도구도 있는데요 어떤 추적 파일이든 추가하면 다른 측정 도구와 조합해서 정지 현상을 드러낼 수 있어요 정지 감지 및 표시 기능 이외에도 정지 지속 시간의 임계값을 설정해서 특정 비응답 기간을 찾을 수 있습니다 지금까지 Xcode를 사용해서 정지 현상을 발견하고 진단하는 법을 배웠습니다 개발 중 넓은 범위의 테스트를 진행해도 베타 및 공개 출시 환경에서는 생각지 못한 코드 경로에서 정지 현상이 발견되기 쉬워요 다음은 앱이 베타 환경으로 배포됐을 때 정지 현상을 추적하는 법을 소개할게요 이제 App Store Connect를 통해 푸드 트럭 앱의 빌드를 TestFlight에 올렸고 개인 기기에 다운로드했어요 도시 곳곳에서 도넛을 팔면서 앱을 테스트할 거예요 평소에 네트워크 연결이 잘 안 되는 곳도 포함해서 말이죠 그런데 Xcode에 장치가 연결되어 있지 않은데 정지 현상을 어떻게 발견하고 진단할까요? 이런 조건에서 정지 현상을 계속 모니터링하기 위해 iOS 16은 개발자 설정에 기기 내 정지 감지 기능을 도입해 실시간 정지 알림과 진단 정보를 제공합니다 이 기능은 개발자 서명 앱이나 TestFlight 앱에서 가능합니다 이제 판매 주문을 받기 시작할 차례예요 현재 주문을 열어서 확인하려고 할 때 기기 내 정지 감지 도구의 알림을 받았어요 앱이 정지됐다는 거죠 이번에는 3초가 넘었죠 Xcode로 개발할 때는 왜 이 정지 현상을 못 찾았을까요? 자세한 내용을 알아보려면 정지 감지 도구가 제공하는 진단 정보를 활용해야겠죠 앱이 개발용으로 설정되어 있으면 이 기능을 사용하기 위해 설정 > 개발자 > 정지 감지를 열고 스위치를 켜세요 정지 임계값 설정을 사용해 감지할 최소 정지 시간을 설정할 수 있습니다 최소 정지 임계값은 250밀리초이고 500밀리초나 그 이상으로 값을 올릴 수 있어요 정지 시간이 길수록 사용자에게 큰 영향을 미치지만 짧은 정지도 경험을 방해할 수 있습니다 상황에 따라 다른데 특히 연속적으로 일어나면 더 심각하죠 앱을 설치하고 나면 모니터링되는 앱 목록에 앱이 뜰 겁니다 마지막 섹션에는 알림을 받은 정지 현상의 시간 순으로 사용 가능한 로그가 표시됩니다 성능 오버헤드를 최소화하려고 이런 진단은 백그라운드에서 낮은 우선 순위로 처리돼요 즉 처리 시간이 오래 걸릴 수 있다는 거죠 특히 시스템을 사용 중일 때는요 다행히 새 진단을 확인할 수 있게 되면 나타났다 사라지는 알림을 볼 수 있습니다 감지된 행의 진단을 볼까요? 아까 도시 곳곳에서 도넛을 팔면서 주문을 눌렀을 때 정지가 발생했었죠 문자 기반의 정지 로그와 tailspin 파일이 동시에 제공됩니다 문자 기반의 정지 로그엔 정보가 덜 담겨 있지만 정지 현상에 대한 정보를 한눈에 파악할 수 있죠 더 자세하게 조사하려면 Instruments에서 tailspin을 열고 프로세스 내에서 스레드의 상호 작용을 보거나 시스템 리소스 사용을 구별하는 등의 활동을 할 수 있어요 우선 공유 버튼으로 문자 기반의 정지 로그를 Mac으로 보낼게요 Mac에선 기호화하고 더 큰 화면으로 볼 수 있죠 전송하고 기호화한 문자 기반 정지 로그에서 발췌한 부분을 보면 정지된 동안 네트워크에 대한 동기 요청을 수행한다고 알고 있는 메인 스레드의 메서드를 호출합니다 Xcode가 깔려 있고 네트워크 연결이 강한 컴퓨터에서 앱을 테스트하면 네트워크에 데이터를 요청할 때 지연이 전혀 발생하지 않을 수 있죠 하지만 네트워크 연결이 제한된 곳에서 앱을 테스트하면 요청이 길어지고 정지가 발생합니다 이렇게 다양하고 현실적인 조건에서 앱의 베타 버전을 테스트하는 게 중요해요 기기 내 정지 감지 도구로 기기만 사용해서 정지 여부를 모니터링할 수 있죠 이제 개발 단계와 베타 버전 단계에서 가능한 도구를 활용해 정지를 발견하고 진단했어요 이제 App Store 고객들에게 푸드 트럭 앱을 보여 줄 준비가 됐죠 이제 앱이 고객의 손에 들어갔을 때 다양한 OS 버전 및 기기와 이전에 실행한 테스트에서 재현할 수 없었던 현실 환경에서 정지 현상을 추적하는 방법을 알려 드리겠습니다 Xcode 14에서부터는 Xcode Organizer에서 정지 리포트를 지원해 고객의 기기로부터 정지 현상 진단을 집계해 전달받을 수 있죠 앱 분석 공유에 동의한 고객으로부터 수집한 데이터엔 정지 현상의 원인이 된 메인 스레드 스택의 추적 정보가 포함돼 있습니다 정지 리포트는 Xcode Organizer의 왼쪽 탐색 메뉴에서 확인할 수 있습니다 유사한 스택 추적을 수집하면 그룹이 되어 하나의 특징으로 묶입니다 목록에서 이 특징들은 사용자에게 끼친 영향을 기준으로 정렬됩니다 각 특징에서 정지 로그의 몇 가지 샘플을 볼 수 있죠 각 로그에는 메인 스레드 스택의 추적 정보가 있는데요 그 안엔 정지 원인이 되는 코드와 정지 지속 시간 로그를 보낸 기기 및 OS 버전이 포함되어 있습니다 또 특징마다 집계 통계를 제공하는데 그 특징에 속한 정지 로그 개수와 해당 로그의 OS 버전 및 기기별 분류가 나와 있습니다 고객에게 가장 큰 영향을 미친 정지 현상을 알아보려면 가장 위에 있는 특징을 자세히 살펴보세요 이 경우에는 가장 위에 있는 특징이 이번에 출시된 앱의 정지 시간의 21%를 차지합니다 App Store에 앱을 제출할 때 기호 정보를 함께 제출했기 때문에 정지 리포트는 소스 코드에 있는 함수 이름을 그대로 보여 줍니다 메인 스레드 호출 스택의 함수를 조사해 보니 메인 스레드에서 디스크 파일을 동시에 읽으면서 정지 현상이 발생했다고 추론할 수 있었습니다 상당한 시간 동안 차단됐다고 나와 있죠 고객에게 미치는 영향이 가장 큰 성능 문제를 해결하는 건 매우 중요합니다 Organizer는 이런 문제를 식별하기 좋은 도구죠 앱을 공개할 때마다 이 데이터를 확인해서 전에 일어난 정지 현상이 해결됐는지 확인하고 새로 나타날 수 있는 정지 문제를 해결하세요

App Store Connect의 REST API를 통해 동일한 정지 리포트 데이터를 검색할 수도 있습니다 이걸로 성능 데이터를 여러분의 시스템과 통합하거나 추가 분석을 실행할 수도 있죠 강력 추천 하는 영상이 하나 있는데요 'Power and Performance API로 추세 식별'이란 영상을 통해 해당 API를 사용하는 법을 자세히 배워 보세요 전원 및 성능 메트릭을 모니터링할 때 Xcode 13.2부터 앱에서 알림을 받을 수 있어요 Xcode Organizer의 Regressions 화면에서 오른쪽 상단에 있는 알림 버튼을 클릭해 알림을 활성화하는 걸 권할게요 이렇게 하면 앱의 정지율이 급상승할 때 경고를 보냅니다 '앱에서 전력 및 성능 저하 진단'이란 영상을 보고 성능 저하에 대해 더 자세히 알아보세요 2021년 강의 영상입니다 Xcode Organizer를 더 편리하게 활용하려면 앱을 빌드하고 App Store에 제출할 때 기호 정보를 같이 제출하는 걸 강력히 추천할게요 기호 정보가 있으면 여러분 앱의 함수 이름이 Xcode Organizer 보고서에 추가될 겁니다 그러면 스택 추적을 훨씬 쉽게 이해할 수 있겠죠 또 스택 추적의 함수 이름을 한 번만 클릭하면 Xcode 소스 편집기의 함수 정의를 탐색할 수 있어요 추출되는 정보는 함수와 메서드 소스 코드 파일의 경로와 이름 줄 번호 정보로만 제한되죠 제한된 기호 정보는 안전하게 저장되고 절대 공유되지 않는다는 걸 알아 두세요 잘됐죠? 이제 개발 과정의 각 단계에서 정지 현상을 발견하고 진단하는 법을 배웠습니다 앞으로는 개발 과정의 최대한 초기 단계에서 정지 현상을 발견, 진단하고 해결해 보세요 가능한 도구를 사용하세요 Instruments로 새 기능에 대한 정보를 사전에 수집할 수도 있죠 스레드 성능 검사 도구와 기기 내 정지 감지 기능을 꼭 활성화하세요 릴리스할 때마다 Xcode Organizer로 고객에게 가장 큰 영향을 미치는 정지 문제를 해결하고 이전 앱 버전의 정지 문제가 해결됐는지 확인하세요 성능 저하 알림을 켜서 저하된 성능에 관한 메트릭을 사전에 알아보세요 전력 및 성능 문제의 첫 징후일 수도 있으니까요 마지막으로 앱을 빌드하고 App Store에 제출할 때 기호 정보를 함께 제출하세요 Xcode Organizer를 더 유용하게 쓸 수 있습니다 이 단계를 따라가 보면 앱의 성능이 더 향상되어 최상의 사용자 환경을 제공할 수 있을 거예요 WWDC에 참여해 주셔서 감사합니다 ♪