Addressable 1.18.15 번들 갱신이 되는 특이한(?) 경우

 Addressable 1.18.15 번들 갱신이 되는 특이한(?) 경우

addressable 1.16.19 버전의 오류 때문에 1.18.15로 업데이트 후 매일 번들을 업데이트 하면서 테스트를 하면서 번들이 신기하게 갱신되는 경우가 있어서 포스팅을 하게 되었습니다.

-번들 기본 세팅-

준비물 : FBX파일과 해당 FBX의 mesh를 사용하는 prefab 하나를 각각 다른 번들에 위치 시켜 줍니다.

-번들 생성-

당연하게도 3개의 번들과 catalog가 나옵니다.

여기서 FBX파일의 번들위치를 옮겨보겠습니다.

-FBX에셋을 FBX번들에서 packed assets으로 이동-

화면 상에서는 FBX번들과 Packed Assets번들 두 번들에서의 수정만 있었으므로 2개의 번들이 새로 갱신 될줄 알았지만?

-결과-

??

신기하게 FBX파일의 mesh를 들고 있는 Prefab번들도 같이 갱신 됐습니다.

아마 연결된 에셋의 어드레서블 정보도 같이 저장하는게 아닐까 싶습니다.

-두번째 테스트-

두번째 테스트는 좀 더 신기합니다.

준비물 : mesh collider에 mesh를 넣고 프리팹화 하여 FBX파일과 다른 번들에 넣어 줍니다.

-번들 생성-

-수정 사항-

그 뒤에 해당 프리셋의 옵션을 변경 해주고 다시 재빌드를 하면?

당연히 프리팹만 갱신 될줄 알았지만

-결과-

???????

연결되어 있던 FBX파일의 번들또한 갱신되는 것을 확인 할 수 있었습니다.

이건 첫번째와 달리 왜 이렇게 되었는지 생각나는게 없네요

일단 두 경우 모두 그렇게 자주 있는 일은 아니여서 번들 관리는 블로그에 있는 툴로 여전히 파일 종류 별로 관리중입니다만

좀 더 갱신을 덜하고 싶으신분들은 참고 해볼 수 있을것 같습니다.

1.18.15 테스트를 좀 더 하게 될거같은데 이러한 일이 있을 때 추가로 올리도록 하겠습니다.

-----2021-08-18

Addressable에 등록하지 않은 스프라이트가 addressable에 등록되어 있는 아틀라스에 추가 되서 아틀라스가 갱신되면 해당 스프라이트가 있는 번들 또한 같이 갱신 됩니다.

Addressable 1.16.19 Bug

 Addressable 1.16.19 Bug

버그도 많이 잡혀서 잠잠해질 무렵 자사 게임의 번들이 업데이트하는것에 비해 더 많이 업데이트되어서 다운 받는다는 제보가 들어와서 조사에 들어갔습니다.

FBX파일을 모아둔 번들이 실제로 변경된 번들 수(2x)에 비해 더 많은 양(8x)이 변경되서 갱신되는걸 확인을 이것저것 해봤는데

그냥 addressable 버그였습니다;;

unity 2019.x 버전을 사용하시는 분들의 경우 기본 addressable의 버전이 1.16.19 이실겁니다.

-테스트용 번들-

테스트 방법은 이렇습니다.

FBX파일이 들어있는 번들하나와 해당 FBX의 mesh를 사용하는 프리팹을 다른 번들에 넣고 빌드를 합니다.

-테스트 결과-

정상적으로 catalog와 번들2개가 나온것을 확인 할 수 있습니다.

-테스트용 번들2-

그런데 이때 FBX번들이 들어가 있는 번들에 아무 에셋이나 하나 추가를 한다면?

예상되는 결과는 FBX그룹만 바뀌었으니 새로운 catalog와 해당 그룹만 새로 나와야합니다.

-테스트 결과2-

??

예상과 다르게 prefab번들 까지 갱신되어서 나오는 것을 확인 할 수 있습니다.

이것 말고도 애니메이션이 들어가 있는 FBX의 애니메이션을 사용하는 애니메이터를 다른 번들에 위치 시키고 FBX가 들어가 있는 번들에 리소스를 추가하거나 제거하면

애니메이터가 들어가 있는 번들까지 같이 갱신되는 것을 확인 할 수 있습니다.

아마 확인 하지 못한 케이스도 많을 것으로 예상 됩니다.

해당 버그의 수정 방법은 아직 업데이트 밖에 없는 것 같습니다.

가장 최신 버전인 1.18.15 버전에서 같은 테스트를 해봤습니다.

-1.18.15 버전에서 재 테스트-

정상적으로 FBX번들만 갱신되는 모습을 볼 수 있습니다.

다만 유니티에서 2019.x 버전에서 인증한 버전은 아직 1.16.19 버전까지 이므로 변경 후에 실제 apk에서 정상 동작하는지 테스트는 따로 해보셔야합니다.

GC Alloc를 줄이자

 GC Alloc를 줄이자

CPU 최적화를 최대한 해주기 위해서 GC Alloc를 최대한 줄일려고 노력을 한 적이 있었다.

그 중에서 GC Alloc를 천 단위로 계속 호출해서 프레임에도 심한 영향을 준 케이스와 백 단위로 계속 호출해서 약한 영향을 준 케이스가 2개 있어서 적어볼려고 한다.

첫번째 심했던 케이스는

-string 끼리 더하는 코드 예시-

-해당 코드 프로파일링 결과-

공부를 하다보면 누구나 한번쯤 들어봤을 string 끼리 더하는 코드였다.

발견 당시에 2년 넘게 개발중인 게임에서 이런 식의 코드가 있었다는게 좀 황당했던 기억이 남아있다.

형태에 따라 stringbuilder를 사용해도 상관없지만 당시에는 구조를 조금 바꿔서 아예 지워버렸던 것으로 기억한다.

의외로 별거 아니라고 생각하는 사람도 있는데 update문이나 자주 사용하는 함수의 for문등에 사용 할때는 문제가 될 수 있으므로 그냥 해당 형태를 최대한 피하는 것이 좋다.

두번째 케이스는 

-AddRange와 FindAll을 반복해서 사용 하는 형태-

-해당 코드 프로파일링 결과-

두번째도 마찬가지로 update문에서 돌아가는 코드였는데 addrange와 findall을 사용하는 형태였다.

사실 개인적으로 저것을 자주 사용하지 않아서 GC Alloc를 유발하는지 모르고 있었는데 프로파일링을 하다보니 알게 되었다.

해당 코드의 수정방법은 다소 무식하게 하면 간단하다.

-2중 For문과 if조건문으로 수정한 코드-

                                           -해당 코드 프로파일링 결과-

좀 코드가 길어지더라도 for문을 한번 더 사용해서 같은 결과만 나오게 해주면 해결된다 그리고 실제 코드에서 리스트 초기화하는 부분도 따로 빠져있지 않았어서 불편해서 수정했다.

회사에서 이렇게 프로파일링을 해서 코드들을 수정하고 나서부터는 이러한 것들이 한번 호출하고 끝나는 코드에서는 별 상관 없지만 습관이 생긴다고 평소에도 의식하면서 코드를 짜게 만들어 주었다.

혹시 이글을 보게 된다면 자신의 게임의 GC Alloc call을 한번쯤 확인해보는 것은 어떨까