[번역] 위쳇 미니게임을 개발할 때 디버깅이 얼마나 중요한가요?

역자의 말

글로벌 IT 기업 텐센트는 중국 심천에 본사를 두고 있습니다.

Wechat(웨이신)이라는 메신저는 이제 중국인들의 삶과 분리해서 볼 수 없는 슈퍼앱의 지위에 거의 근접 했죠. (한국으로 보면 카카오톡?) 사실 텐센트는 카카오는 물론 국내 많은 IT 기업의 대주주 지위에 있다고 볼 수 있습니다. 아무튼... 소개하고자 하는 것은 위쳇 미니게임 인데요! 유니티 차이나에서 제공하는 독자적인 유니티 엔진 버전에는 텐센트 미니게임 플레폼 직접 빌드 라이브러리를 지원 하고 있습니다. 위쳇 미니게임은 하루 활성화 유저가 정말 어마어마 한데요. 우리나라 인구의 절반이 넘는 일일 활성 유저를 보유하고 있다고 봐도 되겠네요. 위쳇 미니게임은 한 마디로 설치가 필요 없는 웹3 게임과 유사합니다. 유니티로 개발하고 미니게임으로 빌드 하면 더 이상 설치가 필요 없고 바로 폰에서 실행이 됩니다. 텐센트는 위쳇 미니게임을 수년 전부터 밀고 있었는데요. 년간 엄청난 매출을 견인 하고 있는 게임 플레폼이 되었어요. 중국 소규모게임퍼블리셔들도 이 미니게임 플레폼 비즈니스에 나섰습니다. 한국 인디 게임 개발자 분들도 위쳇 미니게임 플렛폼에 관심을 갖어 볼만 합니다. 인디 게임 개발자에게 스팀과 안드로이드 마켓만 존재 하는게 아니거든요. 모두 화이팅 하시구요~

WeChat Mini Game development: prerequisites, set-up, and how-to

 

Working Together to Build a Weixin Mini Game Ecosystem | Weixin public doc

 

---

 

이 시리즈의 첫 번째 포스팅에서는 학습 가치가 높은 URP 예시 프로젝트인 유니티의 BoatAttack 프로젝트를 사용하여 WeChat 미니 게임 플랫폼을 셸브하는 방법을 시연했습니다. 이전에 본 적이 없다면 먼저 읽어보시기 바랍니다(클릭하여 이동). 대상 플랫폼이 WeChat 미니 게임 플랫폼으로 변경되었기 때문에 프로젝트는 많은 수수료 성능 효과가 있으며, 디버깅이 대상 플랫폼에서 제대로 실행되지 않으면 프로젝트 선택에서 개발 팀이 디버깅 작업을 시작하고 예상 평가 전에 다음과 같은 디버깅이 필요할 수 있습니다.

  메모리가 너무 많은 플래시백

엔진과 프로젝트 코드가 와즘으로 변환된 후 와즘 코드를 컴파일하고 실행하면 브로틀리 압축 와즘 파일 크기의 약 10배가 소모됩니다. 따라서 UnityHeap에 남는 메모리 공간이 제한됩니다. 따라서 wasm 파일의 크기를 최대한 줄인 다음에는 리소스 메모리와 관리 메모리를 최적화해야 합니다. 부적절한 텍스처 압축 포맷, 리소스 중복, 셰이더 배리언트 등으로 인한 메모리 낭비를 방지할 수 있습니다.

  랙

와즘 코드의 실행 효율은 네이티브 코드보다 약 3배 정도 느리기 때문에 작은 게임 플랫폼에서는 원래의 작은 지연이 증폭되므로 작은 게임이 원활하게 실행되도록 지연 지점을 디버깅하고 최적화해야 합니다.

https://webassembly.org/

WebAssembly

 

  과도한 시작 시간

게임을 처음 실행할 때 게임의 첫 번째 패키지를 CDN에서 다운로드해야 하고, 네이티브 앱에 비해 와즘의 실행 효율이 낮기 때문에 게임 실행 시간이 너무 길어집니다. 따라서 게임을 디버깅하여 시작에 가장 큰 영향을 미치는 요소를 찾아 최적화해야 합니다.

디버깅을 시작하기 전에

각 프로젝트는 해결해야 할 많은 문제를 개발 중이지만 게임 개발 분야에서 눈으로 보는 것이 반드시 사실이 아니기 때문에 경험을 사용하여 결정하지 마십시오. 가장 신뢰할 수있는 방법은 소프트웨어를 사용하여 디버그하고 문제를 실제로 배제하기 위해 신뢰할 수있는 데이터를 얻는 것입니다.

우선, 첫 번째 단계는 먼저 플랫폼을 WeChat 소형 게임 플랫폼으로 전환 한 다음 전체 개발 프로세스에서 디버깅 패키지를 재생하여 패키징 소프트웨어에서 정해진 시간을 개발하여 디버깅 보고서를 내보내고 문제를 분석하여 해결할 수없는 주요 문제가 발생하는 단계를 최종적으로 완료하지 않도록합니다. 디버깅을 위해 Unity 프로파일러와 Unity 메모리 프로파일러를 사용하는 경우 빌드 설정에서 개발 빌드 및 자동 연결 프로파일러를 체크해야 합니다(WeChat 게임 패키징 페이지도 체크되어 있음).。

打包支持调试的包体

빌드를 클릭하여 패킹하려면 패킹 프로세스가 광범위하게 포함되므로 이번 호의 내용에는 포함되지 않으며, 패킹 프로세스에 문제가 있는 경우 패킹에 대한 공식 동영상 자습서(사이트 B: Unity 공식)를 참조하시기 바랍니다.

첫 번째 디버깅 도구는 게임의 총 메모리 및 CPU 사용량을 확인하는 데 사용되는 도구입니다. iOS는 작은 게임에 대해 엄격한 메모리 제한이 있으며 메모리가 너무 많으면 일정 시간이 지나면 게임이 플래시백될 수 있으므로 일반적으로 메모리를 1GB 이내로 유지해야 안전성을 확보할 수 있습니다. CPU 사용량이 너무 높으면 휴대폰이 빠르게 전력을 소모하고 과열되어 CPU 다운클럭이 트리거되어 게임 프레임 속도가 떨어집니다.

소규모 게임 성능 분석 도구

  iOS - 인스트루먼트

WeChat 게임을 실행하는 iPhone을 Mac과 연결한 후, 계측기를 열고 활동 모니터 템플릿을 선택한 다음 왼쪽 상단의 빨간색 점을 클릭하여 녹화를 시작합니다. 잠시 후 com.apple.Webkit.WebContent 프로세스의 메모리 사용량과 CPU 사용량을 확인할 수 있습니다.

  Android adb

안드로이드 기기에서 WeChat 미니 게임을 실행할 때, adb 명령어를 사용하여 총 메모리 사용량을 확인할 수 있습니다. 먼저 개발자 옵션과 USB 디버깅을 켜고 PC에 연결한 후 명령줄에서 다음 명령을 실행하면 현재 미니 게임의 총 메모리가 총 Pss가 됩니다.

adb shell dumpsys meminfo com.tencent.mm:appbrand1

소규모 게임의 총 메모리는 주로 비교 분석에 사용됩니다. 예를 들어, 주요 게임 업데이트 또는 엔진 버전 전환 후 전후 데이터를 비교하여 새 버전에서 다른 문제가 발생하지 않았는지 확인할 수 있습니다.

  Unity Profiler

패키징 시 개발 빌드 및 자동 연결 프로파일러를 체크한 다음 동일한 LAN에서 게임을 실행하면 Unity 프로파일러에 자동으로 연결되며, Unity 프로파일러는 다음과 같은 결과를 얻을 수 있습니다:

- 각 프레임의 CPU 런타임과 특정 함수 호출 시간을 확인하여 성능 핫스팟을 발견할 수 있습니다;

- 렌더링된 드로우콜, 정적/동적 배치의 수를 확인합니다;

- 메모리 사용량, 프레임당 GC 메모리 할당량을 확인하고 소요 시간을 확인할 수 있습니다.

每帧 CPU 时间

drawcall 和合批

메모리 및 GC

CPU 성능 최적화는 주로 프레임 속도, 지연 및 발열 문제를 해결하기 위한 것으로, Unity 프로파일러를 사용하면 CPU, 메모리 및 렌더링의 Unity 부분에 대한 대략적인 아이디어를 얻을 수 있습니다. 문제를 더 자세히 분석해야 하는 경우 다음 툴을 사용하여 더 심층적으로 분석할 수 있습니다:

- CPU:

위챗 패키징 페이지에서 프로파일링-펀스 옵션을 제공하며, 이 옵션을 선택하면 런타임에 성능 데이터 파일을 생성하여 PC로 가져온 후 분석할 수 있습니다. 자세한 내용은 Android CPU 프로파일러 성능 튜닝 사용 문서를 참조하세요.

使用Android CPU Profiler性能调优 | 微信小游戏团结/Unity快适配

 

- 메모리:

Unity 메모리 프로파일러

WeChat 패키징 페이지에서 메모리 할당 콜 스택을 중심으로 wasmHeap 하단 할당 세부 정보를 분석하는 ProfilingMemory 옵션을 제공합니다.

- 렌더링:

Unity 프레임 디버거

  Unity . 메모리 프로파일러

Unity 메모리 프로파일러는 소규모 게임의 메모리를 최적화하는 데 유용한 툴입니다. Unity 프로파일러와 마찬가지로 게임을 패키징하고 LAN에서 실행할 때 개발 빌드 및 자동 연결 프로파일러를 확인해야 합니다.

메모리 프로파일러는 메모리를 세 가지 범주로 나눕니다:

- 그래픽 메모리: 메모리 사용량, 주로 텍스처, 모델 및 렌더 텍스처, 이 부분이 너무 높으면 릴리스되지 않은 렌더 텍스처가 있는지, 텍스처 크기 및 압축 형식이 적절한지 확인해야 합니다.

• 네이티브 메모리: 엔진 및 리소스의 메모리 사용량입니다. 너무 많은 리소스, AB 또는 너무 많은 C# 코드(il2cpp VM 메모리 사용량)를 로드하면 이 메모리 사용량이 높아질 수 있습니다.

- 관리되는 메모리: 주로 문자열, 배열, 사전 및 기타 데이터 구조에 대한 C# 코드의 메모리 사용량입니다.

메모리를 너무 많이 차지하는 리소스의 경우 오른쪽의 세부 정보를 사용하여 리소스 설정(읽기 및 쓰기 가능, 압축 형식) 등이 올바른지 확인할 수 있습니다.

Unity 오브젝트 페이지에서 이름이나 크기별로 정렬하여 중복된 리소스를 빠르게 찾을 수 있습니다. 오른쪽의 레퍼런스를 비교하여 중복의 원인을 분석할 수 있습니다. 예를 들어 아래 이미지에는 AB와 씬에 중복된 TMP 텍스처가 두 개 있습니다. 씬과 AB의 UI는 동일한 TMP 폰트 리소스를 동시에 참조하므로 패킹 구조를 조정하여 이 중복 문제를 해결할 수 있습니다.

  Frame Debugger

유니티 엔진은 위챗 미니 게임 플랫폼에서 프레임 디버거 기능을 지원합니다. 게임 렌더링 오류 또는 GPU 인스턴싱이 예상대로 작동하지 않는 경우 프레임 디버거를 사용하여 원인을 확인할 수 있습니다.

예를 들어, 동일한 머티리얼을 사용하는 두 개의 메시 렌더러에서 프리팹이 서로 다른 AB에 패킹되어 있고 AB에서 로드한 후 배치가 실패하는 경우입니다. 프레임 디버거 기능을 사용하면 "다른 머티리얼이 사용됨"이라는 배치 원인이 표시되며, 그 이유는 머티리얼을 지정하지 않고 AB를 다른 AB에 패킹했기 때문에 각 AB에 머티리얼 인스턴스가 있기 때문입니다.

디버깅이 얼마나 중요한가요?

디버깅은 매우 중요하지만 이것은 늦게 개발하는 대부분의 개발 팀이 일을 할 때만 디버깅 도구 사용에 익숙하고 전문가이며 소규모 개발 팀은 일반적으로 인력이 부족하여 디버깅 프로세스가 없으며 종종 개발 및 선반에있는 게임도 프로젝트에서 찾을 수 없습니다 게임 콘텐츠가 좋더라도 프로젝트 지연 또는 충돌 문제를 해결할 수 없지만 선반 후 충돌은 프로젝트의 실패로 인한 문제를 해결할 수없는 경우 초기 또는 중기부터 개발이 계속 실행되는 디버깅 프로세스는 고정 시간 건강 검사와 같으면 더 빠르게 대응할 수 있습니다. 개발 초기 또는 중반부터 디버깅 프로세스를 계속 실행하면 정기적인 건강 검진을 받는 것과 같아서 프로젝트에 문제가 발생했을 때 더 빠르게 대응할 수 있습니다. 디버깅 프로세스는 또한 몇 가지 상황 시뮬레이션을 통해 이해할 수 있는 잘못된 판단 문제를 해결해 줍니다.

  2D 배치 게임의 상황 시뮬레이션에서 테스터들은 각 전투 장면의 몬스터 수가 20개 이상일 때 프레임 속도가 떨어지기 시작할 때 프로그래머가 몬스터를 테스트하기 위해 경험 법칙에 따라 회의에서 프로그래머가 한 번 이상의 지연을 느낄 것이라는 사실을 발견했습니다! 회의 중에 프로그래머들은 그리드의 몬스터 수가 너무 많기 때문이라고 판단했습니다. 출시 시기가 다가오면서 아티스트들은 모든 몬스터의 기준을 수정할 수 없었고, 프로젝트 매니저는 결국 전투 중 최대 몬스터 수를 20마리로 고정하기로 결정했고, 결국 전투 성능이 저하되었습니다. 사실: 인스트루먼트의 GPU를 실시간으로 모니터링한 결과, 전투 시작부터 전투가 끝날 때까지 전체 화면이 계속 다시 그려지는데, 이 과정에서 필드에 있는 몬스터 수가 20마리 정도에 도달하면 GPU의 드로잉 압력이 100%에 달해 프레임 속도가 떨어지고 결국 전투가 끝나면 재생하기 쉽도록 처음에 화면에 전체 화면 불꽃 애니메이션을 로드하여 배치하는 것을 발견했습니다. 이 애니메이션은 재생 편의를 위해 처음 시작할 때 화면에 로드되며, 첫 프레임은 완전히 투명하여 아무도 이 애니메이션의 존재를 알아채지 못하며, 전체 화면 투명성으로 인해 전체 화면이 매 프레임마다 다시 그려져 성능 문제가 발생하지만 불꽃놀이 애니메이션을 제외하면 문제를 해결할 수 있습니다.

   상황 시뮬레이션 2 3D 액션 어드벤처 게임, 아트 품질 표준, 아름다운 장면 아름다운, 원래 프레임 속도는 60fps로 유지해야하지만 휴대 전화의 가장 상단 외에 실제 테스트는 45fps 만 가능하며 휴대 전화는 전력 소비를 가열하기 매우 쉽습니다. 회의에서 프로젝트 관리자는 예술의 품질 표준을 유지하기를 원했기 때문에 프로그래밍 팀에 현장에서 실행되는 모든 코드를 간소화하도록 요청했고, 마침내 팀은 기본 레이어를 JobSystem으로 완전히 가져오고 작업을 여러 작업으로 나누어 표준을 충족하는 데 1.5 개월이 걸렸습니다. 사실: Unity 프로파일러와 프레임 디버거의 보고서에 따르면 많은 씬 오브젝트가 오클루전 컬링에서 제외되지 않아 씬 오브젝트에 많은 구멍으로 인해 보이지 않는 모델도 렌더링되는 경우가 많았습니다. 아티스트가 최소 홀 수 설정을 조정하고 모델 디자인도 수정한 후 잡시스템을 임포트한 결과, 최종 결과물은 시퀀스 기간보다 훨씬 좋아졌습니다.

 .  상황 시뮬레이션 32D 카드 게임, 게임 개발의 개발 팀은 모든 개발 표준을 매우 느슨하게 당겼으며, 예를 들어 상품에 10 초 이하의 로딩 시간, 상품에 지연없이 게임 30 프레임, 그래서 전체 프로젝트가 특별한 문제가없는 개발이 끝나고 선반에 준비되었습니다! 게임이 출시 될 준비가되었습니다. 팩트: Unity 프로파일러 데이터를 보면 처음에 에셋 번들을 로딩할 때의 성능 그래프가 U자 모양으로 표시되는데, 이는 로딩에 10초가 걸린다면 1초와 10초만 더 스트레스를 받고 나머지 8초는 로딩된 오브젝트가 매우 작고 일찍 로딩이 완료되어 다음 프레임을 기다리고 있다는 것을 의미합니다. 이 문제는 AB 크기를 균등하게 재할당하면 개선할 수 있지만, 결국 개발팀은 AB가 로드되었는지 판단하고 아직 시간이 남으면 다음 패킷을 계속 로드하는 코드를 작성하기로 결정하고 최종 로딩 시간을 기존 10초에서 5초로 변경했습니다. 

또한 Unity 프로파일러를 통해 다양한 메뉴 UI를 켤 때마다 1초의 활성화 시간이 발생하는 것도 확인했습니다. 팀에서는 왜 바로 켜지 못하는지 모르겠다고 했지만 프로젝트 매니저는 괜찮다며 대수롭지 않게 여겼습니다. 결국 그 이유는 각 UI가 켜지면 Active로, 꺼지면 Deactive로 설정되어 있어 UI를 켜고 끌 때마다 성능이 소모된다는 것을 알게 되었습니다. 결국 개발팀은 모든 UI를 Active로 설정하고 모든 UI를 멀리 떨어진 좌표에 일렬로 정렬한 후 렌더링되는 모든 UI가 동일한 배치로 렌더링되도록 동일한 Z축을 설정하여 다른 UI를 켤 때 다음과 같이 하면 되도록 했습니다. 다른 UI를 열 때 해당 UI에서 사용하는 카메라를 해당 UI로 이동하면 카메라 범위 내에 있지 않은 UI 렌더링은 시스템이 자동으로 제외합니다. 메모리 사용량은 높아지지만, UI가 바로 열리는 효과와 더불어 성능도 향상됩니다.

이 사례 연구를 통해 이 글의 서두에서 언급한 "보이는 것이 전부는 아니다"가 개발에 미치는 영향을 이해할 수 있을까요? 프로젝트의 품질뿐만 아니라 일정에 대한 압박에도 영향을 미치고 아티스트와 프로그래머 간의 갈등을 유발할 수도 있기 때문에 프로젝트 관리자가 잘 이해해야 하는 개발 프로세스입니다.

디버깅이 어렵다고 생각되면 유니티에서 제공하는 온라인 디버깅 리포트 서비스를 통해 지정된 패키지를 설치한 후 패키징하여 공식 UPR 서비스에 업로드하면 확인 보고서를 출력할 수 있습니다!

UPR - Unity 프로페셔널 퍼포먼스 최적화 툴:

https://upr.unity.cn

UPR - Unity专业性能优化工具