MySQL

MySQL 데이터 타입

MySQL 에서 사용하는 데이터 타입에 대해서 알아본다. 

  CHAR 데이터 타입

CHAR와 VARCHAR(VARiable length CHARacter string)은 모두 텍스트 문자열을 허용하고, 필드의 크기를 제한한다. 두 타입의 차이점은 CHAR 필드의 모든 문자열은 크기가 정해진다는 것. 즉 더 작은 문자열을 입력하면 공백으로 채워진다. 반면 VARCHAR의 경우, 텍스트를 채우지 않으며, 입력한 텍스트 크기에 맞게 가변적으로 크기를 가진다. 그러나, VARCHAR는 각 값의 크기를 추적할 수 있는 약간의 오버헤드가 필요하기 때문에 모든 데이터의 크기가 비슷하다면, CHAR가 더 효율적이다.

  BINARY 데이터 타입 

BINARY 데이터 타입은 관련된 문자 세트가 없는 문자의 전체 바이트를 저장하는데 사용된다. 예를 들면 GIF 이미지를 저장하는데 사용할 수 있다. 

  TEXT와 VARCHAR 데이터 타입

TEXT와 VARCHAR에는 작은 차이점이 있다. 

이것은, 만약 전체 내용을 검색할 때는 VARCHAR이 더 알맞고, 빠르다는 것이다.

  BLOB 데이터 타입

BLOB(Binary Large OBject)는 65535 바이트를 넘는 바이너리 데이터에 유용하며, 기본 값을 가질 수 없다. 

  숫자형 데이터 타입

출처: http://ra2kstar.tistory.com/82 [초보개발자 이야기.]

-- 결과 --

- 정리 

Foreach는 속도도 가장 느리고, GC도 24Byte를 남겼다.

Enumerator는 Foreach보다 빠르게 동작했으며,

For는 Enumerator의 2배나 빠르게 동작한다.

가끔 프로파일러의 변동이 있을 때도 있지만 평균적으론 위 성능을 보인다.

- 추가

Dictionary<int, string>

-- 소스코드 --

--  결과 --

foreach

enumerator

이 부분을 보이는게 더 명확할듯 하다.

foreach문의 경우 그래프가 깨지는 구간이 더 많이 존재 한다. (프레임이 끊길 수 있다)

enumerator는 foreach에 비해 안정적이다.

- 결론

For문으로 루프문을 작성하지 못할 경우, enumerator

For문으로 루프문을 작성할 수 있을 경우, for

2. Parse

C#에서 지원하는 Parse는 여러가지가 존재한다.

그 중에서 가장 많이 사용하는 자료형은 string을 다른자료형으로 변환하거나 그 반대로 다른자료형을 string으로 변환하는 일이 잦다.

이번 테스트는 변환방법에 따른 성능을 테스트해본다.

string은 특수한 자료형이지만

그 외 기본자료형들은 비슷한 속도를 낼 거라고 생각한다.

- 테스트과정

(루프 10만번 돌렸다가 폰이 죽었다...)

-- 소스코드 --

-- 결과 --

- 정리

int -> string은 사실 이 결과를 믿을 수 없다.

최대한 평균값을 뽑으려고 노력했으나 그냥 뒤죽박죽이다.

코드로 평균값을 뽑아도 오르락 내리락한다.

그냥 입맛에 따라 쓰면 될 것 같다.

string -> int는 의외의 결과다.

tryParse가 눈에 띄게 느리지 않다.

코드로 평균값을 뽑아보면 1000회당 0.01ms정도 느리다.

안전한 코드를 위해 tryParse를 쓰는게 좋을 듯 하다.

- 결론

int -> string은 작성자의 입맛에 따라, string -> int는 tryParse를 사용한다.

3. callback

c#은 간단한 방법의 callback을 제공한다.

그 중에 System.Action, System.Func<T>를 성능 테스트를 해본다.

- 테스트과정

System.Action을 인자로 받는 함수는 두가지 케이스로 나눈다.

인자가 null이면 실행하지 않는 함수

인자를 빈 delegate로 채우는 함수

System.Func는 그냥 콜하고 처리시간 정도만 알아본다.

-- 소스코드 --

-- 결과

- 정리

UseDelegateEmpty와 UseFunction은 순서가 자주 뒤바뀐다.

평균적으로 비슷한 속도를 뽑아낸다.

null 체크의 경우 약 3배 빠르다.

- 결론

빈 delegate를 작성하지 말자.

소스코드의 안정성과 속도를 위해 callback을 받는 부분에선 무조건 null체크를 하고, null을 인자로 작성한다.

4. transform caching

우리는 유니티에서 transform에 접근 하는 경우가 잦다.

하지만 transform에 접근하는 게 성능에 부담된다는 사실은 잘 모른다.

그리고, 이 성능의 부담은 caching으로 해결 할 수 있다.

- 테스트 과정

루프를 돌며 this.transform.localPosition을 가져오는 두개의 스크립트 작성

하나의 스크립트는 transform을 재정의한다.

-- 소스코드 --

-- 결과 --

- 정리

이 전에 정리된 사례들을 보면 어느정도 부담되는 지 감이 온다.

caching된 transform이 non-caching trnasform보다 2배정도 빠르다.

- 결론

transform에 자주 접근하게 되는 객체에선 caching은 선택이 아닌 필수다.

5. string compare

개발하다보면 유니티 뿐만 아니라 많은 어플리케이션에서 string을 비교할 일이 많다.

string을 비교하는 방법은 여러가지가 존재한다.

string 비교 방법이 많은 건 이유가 있으니, 찾아보길 권장한다.

현재 테스트는 길이가 1000~1999까지의 문자열을 비교한다.

테스트 조건을 명확히 알아야한다. 무조건 이게 빠르다. 라고 가정해버리면 안된다.

문자열의 성능은 여러가지 변수에 의해 좌우될 수 있다. 사실 이 이유로 인해 문자열 비교는 포스팅하지 않으려 했다.

모든 문자열이 길이가 4이고 비교했을때 이 방법이 가장 빨랐구나. 정도로 이해하면 된다.

조건에 대해서는 계속 명시한다.

- 테스트 과정

루프를 돌며 문자열을 비교하는 다섯가지의 스크립트 작성

1. string.Compare

2. string.CompareTo

3. Equals

4. Operator

5. Hash Operator

-- 소스코드 --

-- 결과 -- 

- 정리

위와 같은 조건일 때, 빠른 속도로 나열하자면

Operator, HashOperator, Equals, CompareTo, Compare

순이 된다.

- 결론

여러가지 경험을 비추어 봤을 때 문자열을 연산자 이용해서 비교하는 건 사실 권장하지 않는다.

bool string.Equals(string a, string b) 함수를 사용한다.

6. Debug.Log

개발하면서 많은 Debug.Log, Debug.LogWarning, Debug.LogError로 로그들을 남기면서 개발 했을거라고 예상된다.

프로파일링을 할때마다 Debug.Log가 눈에 거슬렸고, 그에 대한 성능 측정 결과 엄청난 비용을 차지하고 있었다.

그에 따른 이유는 검색으로 많은 이유들을 찾아 볼 수 있다.

내가 진행하던 프로젝트에서 Debug. 으로 검색하니 결과는 약 3천개

빌드전에 모든 로그들을 검색해서 지우기엔 시간이 오래걸릴 수 있다.

개발기간 1년, 2년간 쌓인 로그들 한번에 정리해보자.

그리고, 로그를 정리된 성능과 정리되지 않은 성능을 비교한다.

- 로그정리 구현과정

참조 : https://gist.github.com/kimsama/4123043

위 깃허브에 접속해보면 소스코드가 있다. 해당 소스코드를 수정해서 사용한다.

약 2년 전에 처음으로 깃허브에서 이 소스코드를 찾았다.

그 후, 깃허브에 올라오는 유니티 프로젝트에서 이 코드가 간간히 보이기 시작했다.

아직 로그를 그대로 노출시키는 프로젝트도 많다.

기존 소스코드는 유니티 에디터면 로그를 출력하고, 빌드버전에선 로그를 출력하지 않는다.

하지만 난 문제점 확인과 잘 돌아가는지 확인을 위해 로그를 출력하기 원하면 빌드버전에서도 보고 싶다.

그럼 소스코드를 편하게 사용할 수 있도록 수정해보자.

이렇게.

유니티에디터에선 무조건 로그를 출력한다.

빌드시에는 ENABLE_LOG를 정의했을 경우에 출력한다.

빌드세팅에서 Player Settings -> Other Settings -> Scripting Define Symbols 에 정의하면 된다.

- 테스트 과정

루프를 돌며 100번의 로그를 찍는 스크립트 작성

1. 로그를 출력하지 않는 빌드 프로그램으로 프로파일링 한다.

2. 로그를 출력하는 빌드 프로그램으로 프로파일링 한다.

테스트모바일은 갤럭시 노트3다.

-- 소스코드 --

-- 결과 --

(로그 출력O)

(로그 출력X)

- 정리

로그는 여러면에서 엄청난 비용을 차지한다.

GC, time ms...

- 결론

왠만한 소스코드들은 따라가지 못할 성능을 잡아먹는다.

아무리 소스코드를 최적화 신경써서 작성했다고 하더라도 로그를 많이 찍을 경우 다 무용지물일 것 이다.

그리고 다른 얘기를 해볼까 한다.

현재 마켓에서 다운받을 수 있는 프로젝트들도 몇몇개도 로그를 노출시키고 있다.

중요해 보이는 로그도 찍히는 경우가 있다.

보안상  노출시키지 않아야 하고,

프로그램 성능상 출력하지 말아야 한다.

배포되는 빌드에선 필수로 막아야한다. 

로그를 삭제 시키는 일은 선택이 아닌 필수다.

출처표기 : http://geekcoders.tistory.com/56

참고한곳 https://www.slideshare.net/agebreak/141206-42456391

코드 최적화

1. 유니티 객체들을 변수에 저장해서, 캐싱해서 사용하는것이 좋다.

2. FindObject 계열 함수들은 매우 느리다. (미리 찾아서 캐싱)

3. Instanitate 와 Destroy 함수를 이용한 프리팹의 생성/해제는 비용이 크다

- 활성화/비활성화를 활용 -> 오브젝트 풀링

4. Update 함수보다는 CoRoutine을 활용한다.

5. 나눗셈 보다는 곱셈이 몇 십 배 빠르다.

6. 박싱과 언박싱은 부하가 큰 작업이다.

7. magnitude 보다는 sqrMagnitude를 사용해서 비교한다. (제곱근 계산 x)

8. 삼각함수의 값은 상수로 저장하고, 사용하는 것이 좋다.

9. 문자열은 readonly 혹은 const 키워드를 사용하여, 가비지 컬렉션으로부터 벗어나도록 한다.

10. 가비지 컬렉터

- Mono의 동적 메모리 관리 때문에, 메모리 해제를 위해 GC가 자동 호출 된다.

- GC는 언제 일어날지 모른다.

- GC가 일어나면, 게임이 멈추는 현상(랙)이 발생하게 된다.

- 동적 메모리 해제가 가능한 일어나지 않도록 하는것이 GC 관리의 핵심

10.1 오브젝트 풀링

- 오브젝트(or 프리팹)의 동적 생성과 해제는 부하가 크다.

- 오브젝트가 해제되면, 언젠가는 GC가 동작하여 정리 한다 = 랙이 발생

- 오브젝트를 풀을 만들어 미리 많이 만들어 두고, 활성화/비활성화로 사용한다.

- 풀에서 가져와서 사용하고, 사용이 끝나면 비활성화 상태로 풀에 반환

- 오브젝트 풀링 사용은 선택이 아닌 필수!!

11. GC에게 먹이 주지 않기

11.1 문자열 병합은 StringBuilder

- 일반 String + String을 쓰면 임시 문자열이 생성됨

- StringBuilder.Append() 함수를 사용하여 병합

11.2 foreach 대신에 for문 사용

- 일반 array에 한해서...

- Foreach는 한번 돌때마다 24byte의 쓰레기 메모리를 생성

- 10번만 돌아도 240byte의 GC 수거 메모리를 남김

11.3 태그 비교에는 compareTag()를 사용

- if(go.tag == "enemy") 대신에 go.compareTag("enemy")를 사용

- 객체의 tag 프로퍼티를 호출하는것은 추가 메모리를 항당하고, 복사

11.4 데이터 타입에는 Class 대신 구조체 사용

- 구조체는 GC에 들어가지 않는다. Stack에 할당

11.5 즉시 해제할 때는 Dispose 수동 호출

- 오브젝트의 dispose를 수동으로 호출하여, 즉시 cleanup

11.6 임시 객체들을 만들어내는 API들을 조심

- Ex) GetComponents<T>, Mesh.Vertices, Camera.allCameras,  etc...

12. C++ <-> C# 오버 헤드

12.1 객체의 변경 사항을 캐싱

- 객체의 이동과 변형에 대한 처리를 캐싱하고, 매프레임에서 딱 한번만 처리한다.

- Ex) Move()

12.2 컴포넌트 참조를 캐싱

- GetComponent()는 한번만 호출하여, 객체를 캐싱해두고 사용한다.

12.3 빈 콜백 함수는 제거

-Start()나 Update()같은 콜백함수는 비어있어도 성능에 영향을 끼친다.

리소스 최적화

1. 권장 압축 텍스쳐 사용하기

- 아이폰(PowerVR) : PVRCT

- 안드로이드(Teger) : DXT

- 안드로이드(Adreno) : ATC

- 안드로이드 (공통) : ETC1

2. 텍스쳐

2.1 텍스쳐 사이즈는 무조건 2의 제곱이어야 한다.

- POT(Power of Tow)

- POT가 아닌경우 POT텍스쳐로 변환되어 로딩 된다.

- 900 x 900 -> 실제로는 1024 x 1024로 변환

2.2 텍스쳐 아틀라스를 활용 하라.

- 텍스쳐 아틀라스로 최대한 묶음

- UI 만이 아니라 같은 재질의 오브젝트들을 묶음

2.3 압축된 텍스쳐와 밉맵을 사용하자. (대역폭 최적화)

2.4 32bit가 아닌 16bit 텍스쳐 사용도 상황에 맞게 고려

오디오 최적화

1. 모바일에서 스테레오는 의미 없다.

- 모두 92kb, 모노로 인코딩

2. 사운드 파일을 임포트하면 디폴트로 3D 사운드로 설정

- 2D 사운드로 변경

3. 압축 사운드(mp3, ogg), 비압축 사운드(wav) 구별

- 비압축 사운드 : 순간적인 효과음, 이펙트 등

- 압축 사운드 : 배경음악

참조한 곳

http://snowting-mj.tistory.com/28

for(int i = 0; i < Dic.Count; i++)

{

Dic.Keys.ToList()[i];

또는

Dic.Values.ToList()[i];

}

참고한 곳 : http://infodbbase.tistory.com/113

string path = Application.dataPath + @"\text.txt";

string textValue = System.IO.File.ReadAllLines(path);

if(textValue.Length > 0)

{

for(int i = 0; i < textValue.Length; i++)

{

Debug.Log(textValue[i]);

}

}

텍스트 파일을 한줄씩 읽어와서 디버그로그에 찍는코드

문자열로 변수 불러오기

public int A = 10;

Debug.Log(this.GetType().GetField("A").GetValue(this));

출처: https://stackoverflow.com/questions/11122241/accessing-a-variable-using-a-string-containing-the-variables-name

문자열로 함수 부르기

public string A = "Test";

public void Test()

{

Debug.Log("Test");

}

this.GetType().GetMethod(A).Invoke(this, null);

출처: https://stackoverflow.com/questions/540066/calling-a-function-from-a-string-in-c-sharp

먼저 http://prosto.tistory.com/96 블로그에서 참고하였습니다.

private Touch tempTouchs;

private Vector3 touchedPos;

if(Input.touchCount > 0)//터치가 1개 이상이면.

{

for(int i = 0; i < Input.touchCount; i++) 

{

//UI 클릭시 터치 이벤트 발생 방지

if(EventSystem.current.IsPointerOverGameObject(i) == false)

{

tempTouchs = Input.GetTouch(i);

if(tempTouchs.phase == TouchPhase.Began) //해당 터치가 시작되었다면.

{

//터치 좌표값 가져오기

touchedPos = Camera.main.ScreenToWorldPoint(tempTouchs.position);

break; //한 프레임에는 하나만

}

}

}

}

입니다.

터치 상태 종류

Began(터치 시작)

Canceled(터치 취소)

Ended(터치 종료)

Moved(터치 후 움직임)

Stationary(터치 후 대기)

UI 클릭시 터치 이벤트 발생 방지 관련 주의할 점

Raycast Target이 체크가 되어있어야된다.

만약 체크가 풀려있으면 위의 코드는 상관없어진다.

유니티에서 지원하는 Scale With Screen Szie를 사용하면 여러 해상도에서 일정한 크기의 ui를 이용하실 수 있습니다.

하지만 코드상에서 프리팹을 가져와서 생성같은것을 하면 해상도에 따라 크기가 제각각으로 변할 수 있습니다.

저또한 그것으로 인해 인터넷을 뒤져본 결과

http://answers.unity3d.com/questions/1037474/prefab-does-not-scale-in-scale-with-screen-size-mo.html

저와 같은 증상의 사람을 발견하였으며 해결방법로 위의 링크에 있었습니다.!

방법은 go.transform.SetParent(parent.transform, false); 이라는 코드를 넣어주시면 됩니다.

들어가서 보았더니 월드 포지션을 유지할것인지 불값으로 정해주는 코드더군요

가장 마지막으로 순서 변경

Transform.SetAsLastSibling

가장 처음으로 순서 변경

Transform.SetAsFirstSibling

순서 설정(index 값)

Transform.SetSiblingIndex

현재 순서 반환(index 값)

Transform.GetSiblingIndex

유니티에 구글플레이 연동을 한뒤 로그인코드를 작성하여 폰에넣고 실행해봤는데 안된다면 여러가지 상황이 있습니다.

제가 검색해봐서 본것중 

1. 테스트 계정을 등록해야 하는것입니다.(테스트 일 경우)

2. 저장된게임을 활성화 하시면 EnableSavedGames() 이 코드를 추가하셔야 합니다. 만약 활성화를 안하셨으면 저 코드를 적으면 안됩니다.

3. API관리자에서 사용자 인증 정보를 추가하여야 합니다.(제가 해결한 방법입니다.)

먼저 제가 해결한 방법의 링크는 http://answers.unity3d.com/questions/1357666/google-play-games-services-authentication-fails.html 입니다.

1. Google Play Console -> 앱선택 -> 출시 관리 -> 앱 서명 -> 앱 서명 인증서 : SHA-1 복사

2. https://console.developers.google.com/ 을 열고 프로젝트 -> 자격증명 -> Oauth 2.0 클라이언트 ID -> OAuth 클라이언트 편집 -> 서명 인증서 지문 -> 이전 SHA1을 복사 된  SHA1로 바꾸기 -> 저장을 선택하십시오.

이것으로 저는 해결했습니다.