Optimization guide

memory zepeto is structured to preload resources used in the world into memory based on 1 7 0 in the world, the lowest specification devices are iphone 8 (2gb ram) and galaxy s8 (4gb ram) therefore, we need to make it so that it does not exceed 2gb the minimum specification equipment may be changed later in the case of a multiplayer world, the memory should be managed considering the maximum number of people because each character has memory how to check performance indicators how to check performance indicators in a mobile environment please use the official runtime profiler officially provided by zepeto 📘 please refer to the following guide \[ runtime profiler docid vesygmgrkbtl8t1yl1dv ] how to check performance indicators for world multiplayer servers in your local development environment if you are using vs code as a script editor, you can check various performance indicators such as cpu usage, memory usage, and more for your local development environment server through the plugin 📘 please refer to the following guide on how to set up vs code as a script editor in unity \[ https //code visualstudio com/docs/other/unity\ https //code visualstudio com/docs/other/unity\ ] 1\) search for and install flame chart visualizer for javascript profiles in the \[extension] panel on the left side of the vscode screen the performance indicators of the local development environment checked by the plugin may differ from the actual service environment please use it to understand the approximate performance trends and potential performance issues of the world multiplayer server logic if vs code's working directory is not set to the world project, the plugin will not work correctly be sure to select the correct project folder in the \[explorer] panel 2\) go to the \[run and debug] panel in vs code and change the debugging type to zepeto multiplay script 3\) press the play button on the unity screen to run the world, and press the \[start debugging] button in vs code to start runtime debugging you can check the performance indicators of the multiplayer server in real time in the \[run and debug] panel 👍 tip you can add the following performance indicators by clicking the toggle visible performance charts button in the \[run and debug] panel cpu usage heap used heap total resident set size external memory arraybuffer memory recommended optimization guidelines please optimize according to the following criteria to ensure the world released operates on the minimum specifications minimum specification device (with 2gb ram) crashes when runtime profiler > allocated memory exceeds 550mb on average when the world is actually running, not only the world resources but also various processes are running in memory, so it is recommended to leave some space in the allocated memory for multiplayer worlds, there is a memory allocation per character, so you need to manage memory based on the maximum number of players average memory per zepeto character 35mb if you use a mannequin of the zepeto character type, it occupies the same memory as when one zepeto character enters for optimization purposes, we recommend using the simple type of mannequin if possible average of 280mb when up to 8 people enter these are average figures; please test your allocated memory by actually having the maximum number of people enter before launch, if possible fps (frames per second) the maximum fps limit is 30fps capacity package capacity is limited to up to 1gbyte with the cross world movement feature provided by world 1 8 0, you can indirectly resolve the capacity part optimization method please refer to the information related to unity optimization https //docs unity3d com/kr/2019 4/manual/mobileoptimizationpracticalscriptingoptimizations html https //docs unity3d com/kr/2019 4/manual/mobileoptimizationpracticalscriptingoptimizations html what can be improved about the resources please delete unused package folders and unused files as well please adjust the number of objects in the project and the number of trees/pools in the terrain what can be improved about the code using coroutines yield doesn't produce garbage, but making new waitforseconds will produce garbage therefore, create and use the objects in update ( ), the parts that do not need to be called every frame are replaced so that they can be called every n frame avoid calling heavy logic functions in awake( ) onenable( ) start( ) avoid leaving update ( ) and lateupdate ( ) even for empty functions avoid adding components at runtime if necessary, it is more efficient to instantiate the prefab gameobject find, gameobject getcomponent, and camera main are expensive, so do not call from update() but call from start() if necessary instantiate and destory produce garbage and garbage collections to slow down the process instead, try to reuse it with pools renderer material uses renderer sharedmaterial whenever possible to access the bound object's material since it is too expensive to make a new copy and return it what can be improved about the ui depending on the purpose, divide the canvas and set the canvas that is not used as invisible limit the graphicraycasters and clear the raycast target erase the graphicraycaster from the canvas and insert the graphic raycaster separately into individual elements, such as buttons if you don't need raycast target in text or images, delete it avoid using layout groups unless it is a dynamic ui use the anchor to organize it large list and grid views are expensive, so avoid using them when using the full screen ui, hide everything except this canvas it eliminates the need for the camera to render the 3d scene it also hides unnecessary canvases lower the application targetframerate because you do not need to update every 60 fps when using the full screen ui don't leave a blank space for the render camera of the canvas that uses world space, and fill it in with the camera you use if you leave a blank, unity will automatically fill in the camera main what can be improved about the audio change the sound clip to mono enables the use of wav file any compressed music file will be decompressed and then re compressed during the build time the quality of the music file is degraded during this process compress the clip and lower the compression bit rate use most of the files with vorbis, and change the short sound to adpcm do not exceed 22,050 hz select the appropriate load type for music files with size 200 kb or less, decompress on load for music files with size 200 kb or more, remain compressed in memory set large file and background music to set to streaming muted music files do not end by simply changing the volume to zero, so make sure that they are destroyed