Unity JIT Spike (JIT 강제로 컴파일 하기) Just In Time

[방법.1]

var preJitCompile =typeof(MyComponent).GetMethod("MethodName");

//preJitCompile != null 체크 생략

preJitCompile.MethodHandle.GetFunctionPointer();

[방법.2]

using System.Reflection;

var method = typeof(A).GetMethod("MethodName", BindingFlags.NonPublic | BindingFlags.Instance);

회사 프로젝트를 최적화 하던 중 몇몇 함수에서 메모리 할당이나 테이블 로드등의 

http://lab.gamecodi.com/board/zboard.php?id=GAMECODILAB_Lecture&page=1&sn1=&divpage=1&sn=off&ss=on&sc=on&select_arrange=hit&desc=asc&no=421

using UnityEngine;
using UnityEditor;

public class SimpleRecorder : EditorWindow {
    string fileName = "FileName";

    string status = "Idle";
    string recordButton = "Record";
    bool recording = false;
    float lastFrameTime = 0.0f;
    int capturedFrame = 0;

    [MenuItem ("Example/Simple Recorder")]                       //상단 메뉴 툴바에 Example 서브 메뉴로 Simple Recorder 메뉴가 생김
    static void Init () {
        SimpleRecorder window =
            (SimpleRecorder)EditorWindow.GetWindow(typeof(SimpleRecorder));
    }

    void OnGUI () {
        fileName = EditorGUILayout.TextField ("File Name:", fileName);//File Name 레벨 과 파일명 얻어옴

        if(GUILayout.Button(recordButton)) {                           //Record 버튼 생성 및 이벤트 가져옴
            if(recording) { //recording
                status = "Idle...";
                recordButton = "Record";
                recording = false;
            } else { // idle
                capturedFrame = 0;
                recordButton = "Stop";
                recording = true;
            }
        }
        EditorGUILayout.LabelField ("Status: ", status);             //Status: 라벨 추가
    }

    void Update () {
        if (recording) {
            if (EditorApplication.isPlaying && !EditorApplication.isPaused){
                RecordImages();
                Repaint();                                          //에디터 custom window 에 변경 사항이 생길경우 다시 그려주는 작업
            } else
                status = "Waiting for Editor to Play";
        }
    }

    void RecordImages() {
        if(lastFrameTime < Time.time + (1/24f)) { // 24fps
            status = "Captured frame " + capturedFrame;
            Application.CaptureScreenshot(fileName + " " + capturedFrame + ".png");        //현재 실행화면 캡쳐
            capturedFrame++;
            lastFrameTime = Time.time;
        }
    }
}

https://docs.unity3d.com/ScriptReference/EditorWindow.OnGUI.html

http://memocube.blogspot.kr/2014/04/blog-post.html

유니티 예약 폴더이름 

유니티 에셋 폴더의 예약된 이름들

유니티에서 몇몇 폴더 이름은 특별한 속성을 가지고 있다.

숨겨진 폴더들

점(.)으로 시작하는 폴더(예. “.UnitTests/”, “.svn/”)는 유니티에 의해 무시된다. 이 폴더에 들어 있는 어떠한 에셋도 임포트되지 않으면 어떠한 스크립트도 컴파일되지 않는다. 또한 프로젝트 뷰에서도 보이지 않는다.

“Standard Assets”

이곳에 위치한 스크립트들은 항상 가장 먼저 컴파일된다. 스크립트는 언어에 따라 Assembly-CSharp-firstpass, Assembly-UnityScript-firstpass, Assembly-Boo-firstpass 중의 하나로 출력된다.

Standard Assets 폴더의 스크립트들은 다른 스크립트들보다 먼저 컴파일 된다. 그로므로 스크립트를 Standard Assets 폴더에 두는 것은 C# 스크립트가 .js 스크립트에 접근할 수 있게 하거나 또는 .js 스크립트가 C# 스크립트에 접근할 수 있게 하기를 위한 한 방법이다.

“Pro Standard Assets”

Standard Assets과 같지만 이곳의 파일들은 Pro 버전에서만 의미가 있다. 이는 여기에 있는 에셋들은 Render Texture나 Screen-space 효과 등과 같은 Pro-only 기능에서만 사용된다는 것을 의미한다.

이 곳의 스크립트들은 먼저 컴파일되며, Pro Standard Assets 폴더 밖의 다른 스크립트(어떠한 언어라도)에서 접근이 가능하다.

“Editor”

Editor는 여러분이 작성한 스크립트가 유니티 에디터 스크립팅 API에 접근할 수 있도록 허가해주는 특별한 폴더 이름이다. 만약 여러분의 스크립트가 UnityEditor 네임스페이스의 클래스나 기능을 사용한다면, Editor라는 폴더 안에 위치해야 한다.

Editor 폴더 안의 스크립트들을 게임 빌드에는 포함되지 않을 것이다. 오직 유니티 에디터에서만 사용된다. 프로젝트에 여러개의 Editor 폴더가 존재해도 된다.

주의: 특수 폴더에 위치하지 않은 Editor 폴더는 프로젝트 어디에서 위치/포함 될 수 있다. 하지만 “Standard Assets”, “Pro Standard Assets”, “Plugins” 안에 위치할 경우, 이 폴더들의 직접적인 자식이어야 한다. 그렇지 않으면 정상적으로 처리되지 않는다. 예를 들어 “My Entension/Scripts/Editor”는 OK이다. 하지만 특수 폴더에 위치할 경우 반드시 ‘Standard Assets/Editor/MyExtension/Scripts”, 또는 “Pro Standard Assets/Editor/My Extension/Scripts”, 또는 “Plugins/Editor/My Extension/Scripts”이어야 한다.

“Plugins”

“Plugin” 폴더는 스크립트에서 접근하기를 원하는 네이티브 플러그인들이 위치하는 곳이다. 이것들은 자동으로 빌드에 포함될 것이다. 이 폴더는 어떠한 다른 폴더 안에 들어가 있으면 안된다( Assets 폴더 최상위에 위치해야 한다)

Windows에서는 네이티브 플러그인들이 .dll 파일들로 존재한다. Mac OS X에서는 .bundle 파일들로 존재한다. Linux에서는 .so 파일들로 존재한다. Standard Assets 폴더와 같이 이 곳의 스크립트들은 먼저 컴파일되며, Plugins 폴더 밖의 스크립트(어떠한 언어라도)에서 접근이 가능하다.

“Plugins/x86”

만약 32-bit나 유니버셜(32와 64 bit 모두) 플랫폼으로 빌드를 하고, 이 하위 폴더가 존재한다면, 이 폴더의 모든 네이티브 플러그인 파일들이 자동으로 빌드에 추가 될 것이다. 만약 이 폴더가 존재하지 않는다면, 유니티는 대신 부모인 Plugin 폴더에서 네이티브 플러그인들을 찾을 것이다.

“Plugins/x86_64”

만약 64-bit이나 유니버셜(32와 64 bit 모두) 플랫폼으로 빌드를 하고, 이 하위 폴더가 존재한다면, 이 폴더의 모든 네이티브 플러그인 파일들이 자동으로 빌드에 추가 될 것이다. 만약 이 폴더가 존재하지 않는다면, 유니티는 대신 부모인 Plugin 폴더에서 네이티브 플러그인들을 찾을 것이다.

만약 유니버셜 빌드를 생성한다면, x86과 x86_64 하위 폴더를 모두 만드는 것을 권장한다. 그리고 32-bit와 64-bit 버전의 네이티브 플러그 인을 적절한 하위 폴더에 넣어 준다.

“Plugins/Android”

Java-based 플러기인에 사용될 안드로이드 프로젝트에 포함시키고 싶은 Java .jar 파일들을 이곳에 위치시킨다. 모든 .so 파일(Android NDK-based 플러그인들)도 역시 포함될 것이다. See http://docs.unity3d.com/Documentation/Manual/PluginsForAndroid.html

“Plugins/iOS”

생성된 Xcode 프로젝트에 어떠한 .a, .m, .mm, .c 또는 .cpp 파일들을 자동으로 (심볼릭 링크로써) 추가하는 제한적이고 간단한 벙법이다. See http://docs.unity3d.com/Documentation/Manual/PluginsForIOS.html

만약 Xcode 프로젝트에 자동으로 파일들을 추가하는 방법에 대해 더 많은 제어를 하고 싶다면, PostprocessBuildPlayer 기능을 사용해야 한다. 이렇게 하는 것은 파일들을 Plugins/iOS 폴더에 위치시키지 않아도 된다. See http://docs.unity3d.com/Documentation/Manual/BuildPlayerPipeline.html

“Resources”

Resources 폴더는 스크립트에서 일반적인 (그리고 권유하는) 직접 참조 (유니티 에디터에서 드래그&드롭하는 스크립트의 변수 등) 하는 대신 파일 경로나 이름으로 에셋들에 접근할 수 있게 해주는 특수 폴더이다.

이러한 이유로 사용할 때 주의 사항이 있다. Resources 폴더의 모든 에들은 비록 사용되지 않더라도 여러분의 빌드에 포함된다. 그 이유는 이 에셋들은 스크립트에 의해 사용되기 때문에 유니티는 리소스 기반의 에셋들이 사용되는지 사용되지 않는지 판단할 수 없기 때문이다.

프로젝트에 여러개의 Resources 폴더를 가질 수 있다. 한 Resources 폴더의 어떠한 이름을 가지는 에셋을 넣어두고 또 다른 Resources 폴더에 같은 이름을 가지는 에셋을 넣어두는 것은 추천하지 않는다.

게임이 한번 빌드되고 나면 모든 Resources 폴더의 모든 에셋들이 에셋을 위한 아카이브로 패킹된다. 이는 기술적으로 최종 빌드에서는 더이상 Resources 폴더가 존재하지 않는 다는 것을 의미한다. 비록 여러분의 코드에서 이들을 마치 프로젝트에 존재하던 경로를 통해 접근하긴 하지만 말이다.

에셋들이 MonoBehavior 스크립트의 변수로 접근될 경우, 이 에셋들은 MonoBehaviour 스크립트가 Instantiate될 때 (즉, 게임 오브젝트나 프리팹이 씬에 존재하게 될 때) 메모리에 한번에 로드 된다는 것을 주목하자. 만약 에셋이 너무 크고 이것이 메모리에 로딩될 때 여러분이 이에 대한 더 많은 제어를 하고 싶다면 이렇게 동작하기를 원치 않을 것이다.

그럴 경우 큰 에셋들을 Resources 폴더에 넣고 Resources.Load를 통해 불러오는 것을 고려해보자. 에셋이 더 이상 사용되지 않을 경우에는 오브젝트에 대해 Object.Destory를 호출한 후 Resources.UnloadUnusedAsset를 호출함으로써 메모리를 해제할 수 있다.

“Editor Default Resources”

이 폴더는 Resources 폴더와 유사하지만 에디터 스크립트들 에서만 의미를 가진다. 만약 에디터 플러그 인에 에셋들(예를 들어 아이콘, GUI 스킨 등)을 로드해야 하지만 빌드에는 포함되어야 하지 않다면 이 폴더를 사용해라 (이러한 파일들은 그냥 Resources 폴더에 넣는다면 빌드에도 포함된다는 것을 의미한다).

에디터 스크립트들은 MonoBehavior 스크립트가 아니기 때문에 에셋에 접근하는 일반적인 방법(즉, 인스펙터를 통한 드래그 & 드랍)을 사용할 수 없다. “Editor Default Resources”는 이를 위한 편리한 방법이다.

“Editor Default Resources”안에 위치한 에셋들에 접근하기 위해서는 EditorGUIUtility.Load를 사용해야 한다.

Resources.Load와 달리 EditorGUIUtility.Load는 로드 하려고 하는 에셋의 파일 이름 확장자를 명시할 필요가 있다. 그러므로 “myPlugin/mySkin” 대신 “myPlugin/mySkin.guiskin”이어야 한다.

EditorGUIUtility.Load에 의해 사용된 메모리를 해제하기 위해서는 오브젝트에 대해 Object.Destroy를 호출한 후 EditorUtility.UnloadUnusedAssets를 호출하라.

알고 있는 바로는 오직 하나의 “Editor Default Resources” 폴더만이 존재할 수 있으며, Assets 폴더 바로 아래에 위치해야 한다.

“Gizmos”

Gizmos.DrawIcon에 사용되는 모든 텍스쳐/아이콘들을 가지는 폴더. 이 폴더의 텍스쳐 에셋들은 이름으로 불려질 수 잇으며, 에디터에서 기즈모로써 화면에 그려진다.

“WebPlayerTemplates”

웹 빌드에 사용되는 디폴트 웹페이지를 교체하기 위해 사용된다. 여기에 위치하는 스크립트들은 전혀 컴파일 되지 않을 것이다. 이 폴더는 Assets 폴더의 최상위에 위치해야 한다.

“StreamingAssets”

이곳에 위치한 파일들은 어떠한 변경도 없이 빌드 폴더에 복사된다(최종 빌드 파일에 포함되어야 하는 모바일과 웹빌드는 제외). 이들의 경로는 플랫폼 마다 다를 수 있으며 Application.streamingAssetsPath((http://docs.unity3d.com/Documentation/ScriptReference/Application-streamingAssetsPath.html))를 통해 접근할 수 있다. Also see http://docs.unity3d.com/Documentation/Manual/StreamingAssets.html

link # 1 : http://wiki.unity3d.com/index.php/Special_Folder_Names_in_your_Assets_Folder

link # 2 : http://www.devbb.net/viewtopic.php?f=37&t=1191

일정 loop 에 대한 시간을 측정 한다고했을 경우 JIT 컴파일은 

첫 실행에서만 효과를 누릴 수 있는 만큼 평균치에선 효과가 드러나지 않는다

JIT 컴파일(just-in-time compile) 또는 동적 번역(dynamic translation)은 프로그램을 실제 실행하는 시점에 기계어로 번역하는 컴파일 기법이다. 이 기법은 프로그램의 실행 속도를 빠르게 하기 위해 사용된다.

전통적인 입장에서 컴퓨터 프로그램을 만드는 방법은 두가지가 있는데, 인터프리트 방식과 정적 컴파일 방식으로 나눌 수 있다. 이 중 인터프리트 방식은 실행 중 프로그래밍 언어를 읽어가면서 해당 기능에 대응하는 기계어 코드를 실행하며, 반면 정적 컴파일은 실행하기 전에 프로그램 코드를 기계어로 번역한다.

JIT 컴파일러는 두 가지의 방식을 혼합한 방식으로 생각할 수 있는데, 실행 시점에서 기계어 코드를 생성하면서 그 코드를 캐싱하여, 같은 함수가 여러 번 불릴 때 매번 기계어 코드를 생성하는 것을 방지한다.

최근의 자바 가상 머신에서는 JIT 컴파일을 지원한다. 즉, 자바 컴파일러가 자바 프로그램 코드를 바이트코드로 변환한 다음, 실제 바이트코드를 실행하는 시점에서 가상 머신이 바이트코드를 기계어로 변환한다.

http://linuxism.tistory.com/258

좀 더 Jit 에 대한 자세한 설명

1. 닷넷의 이해, 컴파일과 실행

1.1 닷넷 (.NET)

​1.1.1 C#이란

▣ Visual Basic

​  ◈ 프로그램을 쉽고 빠르게 할 수 있었다.

​  ◈ 문제점

    - 완벽한 객체지향을 지원해주지 않았다.

    - 다른 언어와의 호환성 지원이 미흡했다.

​▣ C#의 가장 큰 이슈

  ​◈ 더 쉽고 빠르게 프로그램하는 것이다.

​  ◈ C#에서 할 수 없는 것을 완벽하게 지원해주자는 것이다.

​​▣ C#의 파워

  ​◈ 2줄이면 C언어로 만들어진 함수 라이브러리를 사용할 수 있다.

​▣ 변화​

  ​◈ 많은 개발자들이 C#을 이해하지 못하고 있었기에 C#에 대한 혼돈 상태에 있었다.

  ◈ C#을 이해하기 시작하면서 C#은 MS의 대체 언어가 되고 있으며, 개발자의 주 개발 언어가 되고 있다.

​

1.1.2 닷넷의 의미와 특징

​▣ 닷넷이란(프로그래머 입장)

  ◈ 모든 것을 포괄하고 있는 이상적인 개발환경

▣ 이상적인 개발환경

  ◈ 닷넷은 개발에 필요한 개발 언어, 개발 툴, 라이브러리, 기반 기술 등을 제공하는 이상적인 개발환경이다.​

​​▣ 개발환경의 통일

  ◈ 개발자는 닷넷 환경하에서 다양한 언어로 개발

▣ 실행환경의 통일

  ◈ 다양한 언어로 개발된 프로그램을 하나의 방식으로 번역한 후 닷넷에서 하나의 방식으로 동작

▣ C#​​

  ◈ 닷넷을 대표하는 언어

​

1.1.3 닷넷 프레임웍(.NET Framework)

1.1.4 닷넷의 특징

▣ 플랫폼 독립성(Platform Independent)

  ◈ 닷넷 프레임웍만 설치되어 있다면 어떠한 운영체제에서도 닷넷 애플리케이션이 동작할 수 있다.

▣ 다양한 언어의 지원

  ◈ 개발자는 다양한 언어로 개발, 닷넷에서 하나의 방식으로 동작

  ◈ CLS(Common Language Specification)

    - 닷넷 프레임웍에서 동작하기 위해서 언어들이 지켜야 하는 표준 스펙

▣ 상호 운용성(Interoperability)

  ◈ 서로 다른 언어끼리의 호환성

    - C#에서의 COM 사용

    - C#에서의 Win32 API 사용

  ◈ 닷넷 지원 언어들끼리의 호환성

​

1.2 ​닷넷 언어의 핵심

​1.2.1 중간언어

​

​

1.2.2 동적 컴파일러

​▣ 중간언어(Intermediate Language)

  ◈ 기계어로 변환하기 쉬운 상태의 중간 단계의 언어

  ◈ 닷넷에서 번역되고 실행되기 위해서는 중간언어 형태로 컴파일되어야 한다. 

▣ 중간언어의 단점

  ◈ 완전한 기계어가 아니기 때문에 언젠가는 완전한 기계어로 번역해야 한다.

  ◈ 속도가 느리다.​

▣ 중간언어의 장점

  ◈ 중간언어를 기계어로 번역하는 번역기만 제공된다면 어떠한 플랫폼에서도 실행 가능하다.​

▣ 중간언어와 동적 컴파일​​​ 

  ◈ 중간언어

     - C#의 최종 결과물(컴파일한 결과파일)

  ◈ 재컴파일

     - 중간언어는 완벽한 기계어로 컴파일되어야만 실행될 수 있다.

  ◈ JIT(Just In Time Compiler)

     - 중간언어를 동적으로 컴파일하는 컴파일러

1.2.3 CLR

1.2.4 컴파일과 실행

​▣ 닷넷의 컴파일과 실행

  ◈ 컴파일

    - 중간언어(IL) 형태로 만든다.

  ◈ 실행

    - .NET 환경의 CLR은 IL형태의 언어를 JIT가 재컴파일한 후 시행시킨다.

​▣ C#의 어셈블리

  ◈ 중간언어 형태의 .exe나 .dll파일들을 C#에서는 어셈블리(Assembly)라고 한다.

​▣ 어셈블리의 종류 ​

  ◈ 사설 어셈블리

    - Copy & Paste 개념의 프로그램

    - 복사해서 사용하면 된다.

  ◈ 공용 어셈블리

    - 레지스터 개념에서 발전된 형태

    - 공용 어셈블리를 등록하는 것은 레지스터와 동일하다.

    - 버전별로 독립적으로 관리하며 복사버젼을 보관한다.

    - CLSID 대신 디지털 서명 방식으로 관리한다.   ​

​

1.3 .NET과 언어​

1.3.1 .NET과 C#

▣ .NET과 C#의 호환

  ◈ .NET을 위해서 새롭게 만들어진 언어

  ◈ .NET의 특징은 곧 C#의 특징이다.

▣ C#언어의 특징

  ◈ 기존 언어들의 장점만을 살려서 만든 언어

  ◈ C#은 C++의 문법을 표준화하고 정리하고 발전시킨 언어이다.

  ◈ C#에서 C문법을 사용할 수 있다. (포인터)

  ◈ C#에서 기존의 COM 컴포넌트를 사용할 수 있다.

▣ C#의 라이브러리​

  ◈ XML.NET

  ◈ ADO.NET

  ◈ ASP.NET

  ◈ XML Web Services

​1.3.2 C#과 자바

[출처] [C#] 1.닷넷의 이해, 컴파일과 실행

VSync는 모니터의 화면 갱신에 맞추는 것인데

이게 생각외로 프로세스를 잡아 먹는다

첫번째 사진은 VSync옵션을 킨 상태인데 

보시다시피 대부분의 프로세스를 VSync가 사용하고 있다.

두번째 사진은 VSync옵션을 끈 상태인데

FPS가 2배로 오르고 그래프자체도 더 보기 편해졌다.

 

이제 이 옵션을 끄는 방법인데

Edit > ProjectObtion > QualitySetting 을 눌러보면

아래쪽에 VSync Count라는 항목이 있는데 Dont Sync로 바꿔주면 된다

아이폰의 경우 VSync를 기기에서 자체적으로 해주기 때문에

처음부터 Dont Sync를 해주면 되고

안드로이드의 경우 자체적으로 해주지 않아서 

키던 안 키던 그건 개발자가 결정하면 될듯 하다

참고로 이 옵션을 끄게 되면 베터리 소모가 많아 진다고 한다 ㅇㅇ

깨알팁 

- 맨위 옵션도 최적화에 도움이 되는 건데 그냥 텍스쳐의 질을 결정하는 거라 보면 된다.

출처: http://unityindepth.tistory.com/14 [UNITY IN DEPTH]

출처: http://unityindepth.tistory.com/12 [UNITY IN DEPTH]

출처: http://unityindepth.tistory.com/10 [UNITY IN DEPTH]

DontDestroyOnLoad 사용시 주의 점 

전부터 저 함수를 자식 오브젝트에 사용하면 장면이 교체되어도 자식 포함해서 부모까지 전부 남는 건지 궁금했었는데 당장 사용하질 않아서 당시에는 그냥 넘기고 잊고 있다가 이번에 ios로 테스트하려니 켜자마자 그냥 죽길래 뭐가 문제인가 찾아보다가 이것 때문인 걸 알게 되어서 몇 자 적습니다.

5.3버전부터 경고를 했었나 보네요. DontDestroyOnLoad only work for root GameObjects or components on root GameObjects. 라고 뜨는데요. 말 그대로 최상위 게임오브젝트나 최상위 게임오브젝트에 붙어있는 컴포넌트에서만 작동한다는 경고 메시지입니다. 그런데 이 메시지를 저만 그런지는 모르겠으나 에디터에서는 안 띄워주고 빌드 했을 때만 띄워줘서 전혀 모르고 있다가 게임 내 콘솔 창을 만들어서 띄우고 윈도우즈에서 테스트할 때 알았습니다. 경고로만 뜨고 플레이에 전혀 문제가 없어 큰 문제 아니구나 하고 알고만 있고 넘어갔는데 ios에서는 빌드해서 보니 유니티 스플래시 뜨기도 전에 켜자마자 바로 죽네요.

xcode 로그가 딱 저렇게만 나오는데 놓치고 있는 부분이 있는지 모르겠지만 봐도 어디가 문제인지는 알 수가 없어서 뭐를 잘못했을까 생각하다가 문득 저 경고가 생각나서 메시지 말대로 최상위가 아닌 얘들한테 사용하는 곳을 찾아 수정하고 빌드를 해서 보니 문제없이 잘 됩니다. (그런데 며칠 전까지도 같은 코드를 사용하고 있었는데 그때는 왜 잘 됐었을까요 ?ㅁ?)

5.3버전 넘어가면서 내부적으로 어디가 바뀌어서 그런 건지 정확히 원인이 이것인지 이것으로 인해 사이드 이펙트가 생기는 건지는 모르겠지만, 관련이 된 것은 맞는 것 같네요. 혹시 ios 테스트하시다가 그냥 죽는 경우가 생기면 이쪽도 한 번 봐보시기 바랍니다. 조금 불만인 것은 변경 점이나 이런 문제가 생길 수 있으면 레퍼런스에 적어 놓았으면 좋을 텐데 저 경고에 해당하는 부분은 내용이 아직 없네요. 함수도 UnityEngine.Object 형을 인자로 받고 있어서 넣을 수 있으면 다 되는 줄 알고 머티리얼에 사용하고 있었는데 원래라면 사용하면 안 되는 거였군요. 저처럼 사용자가 실수할 수 있는 부분인데 UnityEngine.GameObject나 UnityEngine.Component 형만 넣을 수 있게 했으면 더 좋지 않았을까 합니다.

여담으로 파괴되지 않아야 하는 해당 오브젝트가 자식인 경우에는 해당 오브젝트의 transform.root.gameObject를 인자로 넣어서 함수를 실행시키면 자신을 포함하는 최상위 오브젝트가 효과를 받아 밑으로 있는 자식까지 파괴되지 않습니다.

참고 - http://answers.unity3d.com/questions/996282/wierd-console-errors.html

출처 : https://fetchinist.com/blogs/?p=2061

리소스 로딩하기

• 특별한 이름의 폴더
• Resources.Load와 Resources.LoadAll
• 제네릭컬렉션으로 캐쉬하기
• 로딩하기와 캐쉬에서 꺼내기
• 캐쉬를 메모리에서 삭제
• 간단한 샘플
• 결론

유니티IDE의 Assets 안 에는 수 많은 객체를 정의해 둘 수 있습니다. 이미지나 사운드를 비롯하여 스크립트와 프리펩까지 모두 들어갑니다.

이러한 에셋은 컴파일타임에 특정 게임오브젝트와 바인딩되지만 런타임에 스크립트를 통해 사용하려면 리소스를 로딩하는 과정을 거쳐야 합니다.

특별한 이름의 폴더top

유니티의 Assets 폴더 밑에는 서브폴더를 자유롭게 만들 수 있지만 미리 지정된 이름으로 폴더를 만들면 특별한 작동을 합니다.

http://wiki.unity3d.com/index.php/Special_Folder_Names_in_your_Assets_Folder

위 목록에서 다양한 특수 폴더명을 볼 수 있습니다. 대소문자는 구별하지 않습니다. 이 중 이번 포스팅에서 눈여겨 볼 폴더명은 Resources 입니다.

Assets/resources

에셋폴더 밑에 일단 resoureces 라는 이름으로 폴더를 만들면 이 폴더를 기준으로 여러 에셋을 런타임에 로딩하여 사용할 수 있게 됩니다.

예를들어 프리펩을 만들어 로딩하고 싶다면 다음과 같은 구조로 서브폴더를 만들어봅시다.

resources/block 폴더 안에 들어있는 R1~R5까지의 프리펩을 런타임에 불러오려면 어찌 해야할까요?

Resources.Load와 Resources.LoadAlltop

각각의 자원을 부르는 방법은 Resources.Load를 사용하는 것입니다.

귀찮기 때문에 그저 서브폴더만 넘겨주면 전부 처리해주는 LoadAll을 제공합니다.

LoadAll의 경우는 as GameObject[] 로 형 변환할 수 없습니다. 하지만 개별 요소에 대해서는 형변환할 수 있으므로 큰 문제는 없습니다.

제네릭컬렉션으로 캐쉬하기top

일단 로딩한 후에는 해당 객체를 반복해서 사용하는 경우가 많습니다. 예를 들어 R1(녹색큐브)를 10개 복제한다고 하면 GameObject.Instantiate를 사용하기 위해 개별 객체를 인식해두지 않으면 안됩니다.

로딩된 배열을 해시테이블(HashTable)로 잡아두면 편리하게 사용할 수 있지만 제네릭 타입으로 정리하면 형변환도 필요없게 되므로 더욱 안정적이고 간단히 사용할 수 있을 것 입니다.

일단 제네릭컬렉션을 사용하려면 네임스페이스를 불러와야겠죠.

다음은 RSC클래스에 간단히 정적 필드로 캐쉬 공간을 만들어 둡시다.

로딩하기와 캐쉬에서 꺼내기top

그럼 이제 서브폴더를 로딩하는 함수를 일반화하여 캐쉬에 곧장 넣어버리죠.

그럼 그 뒤로는 캐쉬에서 직접 꺼내가던가 아니면 인스턴스를 반환하는 함수를 생각해 볼 수 있습니다. 우선 간단히 가져가는 함수는 다음과 같습니다.

인스턴스를 직접 반환받고 싶다면 다음과 같은 함수로 편리하게 사용합시다.

캐쉬를 메모리에서 삭제top

메모리 절약을 위해 다양한 리소스를 로딩하려면 필요없는 리소스는 다시 삭제해줘야합니다. params인자를 통해 간단히 삭제하는 함수를 구현합시다.

이를 통해 간단히 메모리에서 몇 개라도 한꺼번에 삭제할 수 있게 되었습니다[1. 참고로 GameObject의 경우 Resources.UnloadAsset 으로 삭제되지 않고 더 이상 사용되지 않으면 GC가 될 뿐입니다.]

간단한 샘플top

이상의 내용을 바탕으로 간단히 큐브를 화면에 채워봅시다.

다음과 같은 화면이 된다면 정상입니다.

결론top

이번 포스팅에서는 간단히 런타임 에셋로딩을 알아봤습니다. 실제 소스는 거의 GameObject 로딩 중심으로 가볍게 설명했으나 이를 바탕으로 다양한 에셋로더를 구현하는 것은 또 다른 기회에 해보겠습니다(과연..)

종합 소스는 아래에 있습니다만, resources/block 폴더를 만들고 R1~R5까지의 색깔별 큐브를 프리펩으로 만들지 않으면 실행되지 않습니다.

using UnityEngine;
using System.Collections;
using System.Collections.Generic;

public class bside002 : MonoBehaviour {
	
	static private Dictionary<string,GameObject> _cache = new Dictionary<string,GameObject>();
	
	static public void Load( string subfolder ){
		object[] t0 = Resources.LoadAll( subfolder );
		for( int i = 0 ; i < t0.Length ; i++ ){
			GameObject t1 = (GameObject)(t0[i]);
			_cache[t1.name] = t1;
		}
	}
	static public GameObject Get( string key ){
		return _cache[key];
	}
	static public GameObject Instance( string key, string name, float x, float y, float z ){
		GameObject t0 = (GameObject)(GameObject.Instantiate( _cache[key], new Vector3( x, y, z ), Quaternion.identity ));
		t0.name = name;
		return t0;
	}
	static public void Remove( params string[] arg ){
		for( int i = 0 ; i < arg.Length ; i++ ){
			string key = arg[i];
			_cache.Remove( key );
		}
	}

	void Start () {
		Load ("block");
		for( int i = 0 ; i < 10 ; i++ ){
			for( int j = 0 ; j < 10 ; j++ ){
				Instance( "R" + Random.Range( 1, 6 ), i + "_" + j, i - 5, j - 5, 0 );
			}
		}
		Remove( "R1", "R2" );
	}
}

http://www.bsidesoft.com/?p=215

아래 내용을 구글링 하다가 알게된 것인데

유니티를 지우지 않고 유니티를 끈 상태에서 C:ProgramData/Unity 경로에 폴더를 제외한 

ulf  및  기타 라이센스 파일들을 지운다 (약 3개 정도 인가 있음)

그런 후 다시 유니티를 키면 제인증 하는 화면이 나타남

Give the steps below a try. The files may be hidden so ensure you show hidden files.

1. Uninstall Unity.

2. Delete This file:

• WinXP/Vista: C:/Documents and Settings/All Users/Application Data/Pace Anti-Piracy/License Files

• Win7: C:/ProgramData/PACE Anti-Piracy/License Files

• Mac: HD/Library/Application Support/PACE Anti-Piracy/License Files

• Windows: C:ProgramData/Unity

• Mac: Library/Application Support/Unity

  1. Restart

  2. Download Unity again from the website, since your original install might be corrupt.http://unity3d.com/unity/download

  3. Reinstall and test

http://answers.unity3d.com/questions/516259/license-information-is-invalid-.html

check Player setting => Resolution => (Run In Background) 

OnApplicationPause/OnApplicationFocus has been all over the place for me. In the Editor, it seems to be different on PC and MAC. On MAC it seems to get called on press Play. On PC it doesn't. On iOS it seems like one of them doesn't work. Can somebody tell me the different scenarios that they work?

And can somebody explain what they mean in each scenario? Editor? Standalone? iOS? Android? (like does OnApplicationFocus fire when you minimize or when you just click on another window in the Editor)

I know about the documentation, I read the documentation. But the behavior doesn't match it. It's ridiculous. If somebody has figured it out I'd greatly appreciate it.

---

Since this UnityAnswer is one of the first (if not the first) to be returned on a search for OnApplicationFocus/Pause & iOS, an important update in Unity 4.6.1 has changed the behavior for iOS.

As of 4.6.1, both OnApplicationFocus and OnApplicationPause will be called in iOS.

The order is :

App initially starts:

• OnApplicationFocus(true) is called

App is soft closed:

• OnApplicationFocus(false) is called

• OnApplicationPause(true) is called

App is brought forward after soft closing:

• OnApplicationPause(false) is called

• OnApplicationFocus(true) is called

Hope that helps

http://answers.unity3d.com/questions/496290/can-somebody-explain-the-onapplicationpausefocus-s.html

*Start와 Awake와 OnEnable

기본은 유니티 매뉴얼(https://docs.unity3d.com/Manual/ExecutionOrder.html ) 과동일한 순서라고 생각하면 됨.

Awake는 게임오브젝트가 유니티 내부에서 Instantiate될때 첫 호출되고, Start는 모든 오브젝트의 Instantiate가 마무리된 후에 호출된다.

그런데, 오브젝트 풀링 등을 이용하기 시작하면서 헷갈리는 문제가 발생하기 시작함.

오브젝트 풀링은 보통 gameObject.setActive(true) 와 setActive(false)를 이용하여 필요한 오브젝트를 여러번 Instantiate 하지 않고 재활용하는게 요점인데,

여기서부터 Awake, Start, OnEnable, OnDisable 호출 순서가 점점 골치아파지기 시작하는거지.

------------------------------------

본론으로 들어가기 전에 확실하게 짚고 넘어가야 하는 부분은 이거임.

1. gameObject.SetActive(false)

2. this.enabled = false

는 완전히 다르다는 점이다!

뭐가 다른 것인가 하면

gameObject.SetActive와 this.enabled는 위 캡쳐의 1번 2번 각각에 대해 대응된다고 생각하면 됨.

게임 오브젝트 자체를 disable시키느냐, 게임오브젝트 속의 스크립트 컴포넌트 하나를 disable시키느냐의 차이라고 이해하자.

그럼 이게 Awake, Start, OnEnable과 무슨 상관일까?

-----------------------------------------

경우 1) 게임오브젝트가 Disabled 상태일때

위 스샷의 1번 체크박스를 Disable시켜둔 프리팹, 또는 씬 속의 게임오브젝트가 있다고 치자. 

예를 들어 이펙트를 씬에다 갖다놓고, disable 상태로 게임을 시작했다가, 플레이어가 적을 히트하는 등의 특정 행동에 다다르면 이펙트를 enable시켜서 재생하는 경우를 생각할 수 있겠다.

이 경우에는 게임오브젝트가 활성화되지 않은 것으로 간주, Awake가 호출되지 않는다. 즉, Awake는 게임오브젝트의 활성화 여부에 따라 호출된다.

게임 오브젝트가 애초에 비활성화 상태니, 그 하위 컴포넌트들의 초기화 함수인 Start 역시 호출되지 않는다. 

즉, 

A) 게임오브젝트를 비활성화한 상태로 게임을 시작하면, 또는

B) 프리팹 설정에서 1번 체크박스를 꺼놓은 프리팹을 게임 중에 Instantiate(prefab) 으로 생성할 경우,

Awake도, Start도, OnEnable도 모두 호출되지 않는다.

경우 2)게임오브젝트가 Enabled지만 컴포넌트는 Disabled 상태일때

위 스샷의 1번 체크박스는 켜져 있지만, 2번 체크박스는 꺼진 상태를 뜻한다.

이 경우 일단 게임오브젝트 자체는 활성화되어 있기에, Awake는 호출된다.

그러나 OnEnable() 과 Start()는 호출되지 않는다. 이 두 함수는 컴포넌트의 활성화 여부에 따라 호출된다.

게임이 돌아가는 도중에 체크박스를 켜거나 GetComponent<Component>().enabled = true 설정을 하면, 그 이후 OnEnable과 Start가 호출되게 된다.

전체적으로 재정리하면 다음 그림과 같다.

http://blog.naver.com/1mi2/220928872232 중에서

Unity를 C#으로 개발하다보면 “리플렉션”, 즉 reflection 이라는 단어를 종종 듣는다. 이는 C/C++에서 넘어온 개발자들이라면 다소 생소한 단어일 수 있다. Java는 java.lang.reflection 이라는 패키지로 reflection을 지원하고, C#에서는 System.reflection 네임스페이스를 통해서 지원한다.

Reflection의 한글 뜻은 “거울에 비친 상” 이라는 뜻이다. Language에서 “상” 이라는 의미가 뭘까 라고 떠올렸을 때 언뜻 잘 떠오르지 않는 것이 Reflection 개념에 대한 1차 Hurdle이다.

Programming Language에서 Reflection이라는 말은 Runtime 시에 Object 객체의 형태나 타입에 대한 정보를 읽어 내는 것을 말한다. C++에서도 제한적이지만 RTTI(Run-time type information) 메커니즘을 통해서 Reflection 기능을 제공하고 있다. C++ RTTI 메커니즘 중 대표적인 것이 dynamic_cast와 typeid 이다. 아래는 dynamic_cast의 예를 보자. (Refrence)