성능을 위한 설계

*이 콘텐츠는 AI(베타)를 사용해 번역되었으며, 오류가 있을 수 있습니다. 이 페이지를 영어로 보려면 여기를 클릭하세요.

성능을 위한 디자인은 경험을 구축할 때 몇 가지 모범 사례를 따르는 것입니다 as you build 경험.개발 프로세스 후반에서 성능 문제를 찾아서 해결하는 것과 비교하여 성능을 일찍 디자인하면 많은 시간과 노력을 절약할 수 있습니다.

저가 장치

저급 장치, 특히 모바일 장치는 심각한 메모리 제한이 있으며 메모리 부족으로 인한 충돌에 취약합니다: Lower-end devices, particularly mobile devices, have severe memory limitations and are susceptible to crashes due to out of memory (OOM) errors:

  • 저급 장치를 지원하려면 최소 하나의 "기준" 장치를 선택하여 개발 프로세스 내내 경험을 테스트하고 프레임 속도와 메모리 사용량에 주의를 기울이십시오.경험에서 문제 영역을 찾으면 해당 영역을 사용하여 장치의 제한을 식별합니다.

    예를 들어, 렌더 ( ShiftF2 ) 및 요약 ( ShiftF2 ) 디버그 스탯을 활성화한 경험을 테스트할 수 있습니다.프레임 속도가 특히 복잡한 영역에서 떨어지기 시작하면 그리기 (장면) 숫자를 검사하고 기본 장치에서 경험이 원활하게 실행되려면 1,000개의 드로우 호출과 1,000,000개의 삼각형 아래에 유지해야 한다는 것을 확인할 수 있습니다.

    또는 개발자 콘솔( )을 살펴보고 메모리 사용량이 스트리밍을 활성화하지 않으면 조금 높다는 점을 알 수 있습니다.장치 제한에 대한 명확한 이해는 경험을 계속 구축함에 따라 그들 아래에 머물도록 도울 수 있습니다.

  • Roblox Studio의 디바이스 에뮬레이터는 측면 비율과 컨트롤을 확인하는 데 유용하지만 메모리 사용량에는 정확하지 않습니다; Studio에서 경험을 테스트할 때 서버와 클라이언트를 실행하므로 메모리 사용량이 크게 증가합니다.

일반적으로 다양한 장치에서 테스트하면 경험이 다양한 그래픽 품질 수준에서 시각적 및 성능 요구 사항과 일치하는지 확인할 수 있습니다.낮은 모바일 장치에서 경험을 최적화하는 방법에 대한 훨씬 자세한 예제는 실제 세계 빌딩 및 스크립트 최적화를 참조하십시오.

스트리밍 및 순간이동

  • 인스턴스 스트리밍 으로 Roblox는 3D 콘텐츠를 동적으로 로드하고 언로드하여 대부분의 장소, 특히 더 큰 장소에 큰 옵션입니다.스트리밍은 조인 시간을 개선하고, 메모리 발자국을 줄이고, 프레임 속도를 높입니다.자세한 내용은 성능 향상을 참조하십시오.

  • 큰 장소를 더 관리하기 쉬운 조각으로 분할하고 순간이동을 사용하여 플레이어를 서로 이동하십시오.이 접근법은 초기 조인 시간을 줄일 수 있지만, 플레이어가 장소에서 장소로 순간이동하면 추가 조인 시간을 부과합니다.메모리 사용 이점은 장소의 크기와 스트리밍을 활성화했는지에 따라 달라집니다.

    성능 고려 사항을 무시하더라도 여러 장소를 갖는 것이 경험에 새로운 콘텐츠를 정기적으로 추가하거나 더 큰 팀의 일부인 경우 개발 프로세스를 단순화하는 데 도움이 될 수 있습니다.

재료와 복제물

  • 기본 제공 재료는 사용자 지정 텍스처보다 훨씬 적은 메모리를 사용하지만 예술적 비전과 일치하지 않을 수 있습니다.경험에 중요한 텍스처의 메모리 예산을 절약하기 위해 가능한 한 자료를 사용하십시오.

  • 자산을 생성하면 패키지로 변환합니다.패키지를 워크플로우의 일부로 만드는 것은 성능에 영향을 줄 수 있는 다른 ID의 중복 자산 문제를 피하는 데 도움이 됩니다.

  • 메쉬와 텍스처를 추가할 때 복제본을 가져오는 대신 사용하고 재사용하십시오.크기 조정, 회전 및 겹치기를 통해 매우 적은 드로우 호출이 필요한 다양하고 풍부한 환경을 만들 수 있습니다.자세한 내용은 중복 텍스처 제거를 참조하십시오.

투명성

  • 0(가시성) 및 1(투명성) 이외의 투명도 값을 피하십시오.부분 투명도를 사용할 때는 특히 높은 투명도 오버드로를 피하도록 주의하십시오.

스크립팅

  • 가능하면 프레임마다 계산하는 대신 이벤트 드라이브 코드를 작성하십시오.60 FPS에서 각 프레임의 총 예산은 16.67밀리초(ms)입니다.겉보기에는 미미한 프레임별 계산도 예산의 상당 부분을 사용할 수 있습니다.

  • 긴 실행 코드를 관리 가능한 조각으로 분할하는 방법 찾기코드 조각이 실행하는 데 100ms가 걸리고 모든 프레임에서 실행하면 경험은 10 FPS로만 실행할 수 있습니다.일반적으로 60FPS로 실행되는 경험에서 코드를 한 번만 실행하기로 결정한 경우, 16.67ms 후에 59개의 프레임이 도착합니다...그리고 100ms 후 하나, 이는 격렬한 스터터를 일으킵니다.

    대신, 코드를 분할할 수 있는 방법을 조사하십시오.프레임당 5ms의 작업을 수행하고, task.wait() , 그리고 60 FPS를 유지하면서 20프레임마다 완료된 계산을 수행할 수 있습니다.멀티스레딩, 때로는 병렬 Luau라고 하는, 도움이 될 수도 있습니다.

  • 방법을 사용하여 다음에 이벤트가 발생할 때 불필요하게 함수가 호출되는 것을 중지합니다. Use the 방법을 사용하여 다음에 이벤트가 발생할 때 불필요하게 함수가 호출되는 것을 중지합니다. method to stop functions from being called unnecessarily the next time an event fires.

  • 값이 필요할 때마다 동일한 메서드를 호출하지 마십시오. 한 번 메서드를 호출하고, 값을 저장한 다음 필요에 따라 나중에 덮어씁니다.

  • 모든 것을 ReplicatedStorage에 저장하지 마십시오.클라이언트는 이 컨테이너에 있는 모든 것을 로드합니다.대신, 클라이언트가 액세스할 필요가 없는 모든 것에 대해 ServerStorage를 사용하십시오.