Finebe

64-Bit Windows

From a cmd.exe window, run these commands:

cd "C:\Program Files (x86)\Git\git-cheetah"
regsvr32 /u git_shell_ext64.dll

32-Bit Windows

From a cmd.exe window, run these commands

cd "C:\Program Files\Git\git-cheetah"
regsvr32 /u git_shell_ext.dll

경로가 다르다면 경로만 수정하면 됩니다.

Crash Reporting System

 모바일 서비스를 하게 되면 다양한 환경(제한된 램, 불안정한 네트워크, 저장공간부족등)에서 플레이가 되다 보니 크래시가 빈번하게 일어납니다. 예를 들어 모바일게임을 하는 유저가 자기 폰에서 크래시가 난다고 항의했을 시 개발사에서는 그 사람 계정을 복제하여 플레이한다고 해서 반드시 크래시가 나지 않습니다. 이런 문의를 받으면 참 난감합니다. 당당하게 크래시 안 나니깐 유저발 버그라고 할 수도 있고.....크래시 지레짐작하여 허송세월을 보내기도 합니다. 물론 크래시 덤프가 존재한다고 해서 크래시를 항상 완벽하게는 대응하지 못합니다. 하지만 더 빠르고 더 정밀한 대응을 할 수 있습니다.

 그래서 크래시 덤프를 외부 서버로 전송을 해서 클라이언트 개발자가 분석을 할 수 있게 만들어야 합니다. 이 것이 크래시 레포팅 시스템입니다. 

왜 외부서버이냐?

개발자만큼 플랫폼을 잘 알고 거기다가 매우 친절한 유저가 많으면 이런거 안 만들어도 됩니다. 그 사람들이 친절하니깐 크래시덤프를 메일로 보내줄수도 있으니..

일반적인 사용자가 크래시가 나서 보고서를 제출하겠냐고 하는 문구에 확인을 누르는 사람은 1000명 중에 한명꼴이라는 통계를 본적이 있습니다. 그래서 크래시가 나면 크래시 레포팅시스템에 의해서 개발사가 준비해놓은 서버로 전송해야 합니다. 

이걸 다 개발해야 되는건 아닙니다. 이런 서비스를 무료로 제공하는 곳도 있고 유료도 있습니다.

대부분 크래시 로그 및 분석 등이 제공됩니다.

아래는 여러가지의 크래시레포팅서비스를 제공하는 곳입니다.

-Crashlytics

• https://try.crashlytics.com/
• 무료
• iOS, Android(NDK는 제공하지 않음. 하지만 추후에 제공할 것이라고 함. 20141224 현재 미지원) 지원
• 직관적인 사이트UI
• 설정하기 편함(NDK를 하지 않기 때문이기도 함)
• 알림시스템: 크래시가 발생하면 메일이 날라옴
• 트위터가 인수한 회사
• http://sjava.net/?p=479
• http://blog.naver.com/trick14/100203246433

-HockeyApp

• http://hockeyapp.net/features/
• 유료
• iOS, Android(NDK 제공)
• 모바일 어플도 있어서 설정하면 알림을 받을 수 있음.
• 조금 어려울수도 있는 설정이지만 많이 사용하는 hockeyApp
• HockeyApp기반 라이브러리도 있음. 
• Google breakpad를 이용해서 Android용 Cocos2d-x 게임 크래쉬 리포트를 HockeyApp에 전송하기

-Crittercism

• http://www.crittercism.com/
• 유료
• iOS, Android(NDK 제공)
• 기능은 충실함.
• 좀 비쌈.
• How do I integrate Cocos2d-x with Crittercism?
• http://blog.naver.com/is_the/130178731339

• https://code.google.com/p/google-breakpad/
• Android NDK 크래시 덤프를 만들고 분석하기 위한 라이브러리
• Android NDK을 제공하는 다른 서비스도 breakpad를 이용한 것임.
• 안드로이드 설정 - https://code.google.com/p/google-breakpad/source/browse/trunk/README.ANDROID

레지스터기반 머신(Register-based Machine)

 CPU는 피 연산자를 저장하는 위치에 따라 레지스터 기반 프로세서(register-based processor)와 스택 기반 프로세서(stack-based processor)로 나눌 수 있다. 레지스터 기반 프로세서는 레지스터를 사용하여 연산하는 방식이고 스택 기반 프로세서는 피 연산자를 스택에 저장하고 나서 연산을 수행하면 피 연산자를 꺼내어 연산 후에 그 결과를 다시 스택에 넣는 방식이다.

임베디드 시스템에서 자주 사용되는 스택 기반 프로세서는 함수 호출 시 인자를 스택에 넣어줘야 하는 레지스터 기반 프로세서와 달리 이미 스택에 인자가 저장되어 있기 때문에 추가적인 작업이 필요하지 않다. 또한 컨텍스트 스위치(context switch)가 일어날 경우 레지스터 기반 프로세서는 모든 레지스터의 상태를 저장해 줘야 하지만, 스택 기반 프로세서는 각 프로세스마다 스택을 할당하기 때문에 단지 스택만 변경시킴으로써 간단히 해결할 수 있다.

반면 레지스터 기반 프로세서의 가장 큰 장점은 속도가 매우 빠르다는 것이다. 레지스터가 CPU 내에 존재하기 때문에 레지스터의 참조가 무척 빠른 반면 스택 기반 프로세서는 대부분의 스택을 메모리에 두기 때문에 값을 읽고 쓰기 위해선 메모리를 액세스해야 한다. 또한 레지스터 기반 프로세서는 인스트럭션이 가독성이 있으므로 디버깅에 유리하다.

레지스터 기반 프로세서의 대표적인 예는 인텔 x86이 있고, 스택 기반 프로세서는 RTX32P가 있다.

원본 위치 <http://scotthan.tistory.com/75> 

2.1.5버전 갤럭시s2(4.0.4)에서 버그가 발생합니다..

이유는 TTFLabel생성시 ""이면 제대로 텍스쳐를 생성을 못하여 Null값으로 들어가는 문제가 있습니다.. 이는 아주 작은 Rawdata를 생성하여 임시로 넣어주어 해결했습니다. 

-cocos2d-x 3.x에는 추가된 사항입니다.

static unsigned char cc_2x2_white_image[] = {

    // RGBA8888

    0xFF, 0xFF, 0xFF, 0xFF,

    0xFF, 0xFF, 0xFF, 0xFF,

    0xFF, 0xFF, 0xFF, 0xFF,

    0xFF, 0xFF, 0xFF, 0xFF

};

#define CC_2x2_WHITE_IMAGE_KEY  "cc_2x2_white_image"

void Sprite::setTexture(Texture2D *texture)

{

    // If batchnode, then texture id should be the same

    CCASSERT(! _batchNode || texture->getName() == _batchNode->getTexture()->getName(), "CCSprite: Batched sprites should use the same texture as the batchnode");

    // accept texture==nil as argument

    CCASSERT( !texture || dynamic_cast(texture), "setTexture expects a Texture2D. Invalid argument");

    if (NULL == texture)

    {

        // Gets the texture by key firstly.

        texture = TextureCache::getInstance()->textureForKey(CC_2x2_WHITE_IMAGE_KEY);

        // If texture wasn't in cache, create it from RAW data.

        if (NULL == texture)

        {

            Image* image = new Image();

            bool isOK = image->initWithRawData(cc_2x2_white_image, sizeof(cc_2x2_white_image), 2, 2, 8);

            CCAssert(isOK, "The 2x2 empty texture was created unsuccessfully.");

            texture = TextureCache::getInstance()->addUIImage(image, CC_2x2_WHITE_IMAGE_KEY);

            CC_SAFE_RELEASE(image);

        }

    }

    if (!_batchNode && _texture != texture)

    {

        CC_SAFE_RETAIN(texture);

        CC_SAFE_RELEASE(_texture);

        _texture = texture;

        updateBlendFunc();

    }

}

원본 위치 <http://discuss.cocos2d-x.org/t/cceditbox-crash-on-android-tablet/7670/15> 

1. 안드로이드
• breakpad
• https://code.google.com/p/google-breakpad/
• 윈도우즈 환경에서 breakpad사용하기 http://yardbirds.tistory.com/107
• http://rein.kr/blog/archives/2438
• http://www.reddit.com/r/androiddev/comments/28hvzf/whats_the_best_crash_reporting_service_for_android/
2. ios/안드로이드
1. crashlytics
1. https://try.crashlytics.com/
2. 깔끔한 ui와 간단한 사용법이 매력임
3. 무료.
4. 2014년 11월 24일 현재 ndk는 미지원.
2. hockeyapp
1. http://hockeyapp.net/features/
2. 유료
3. ndk지원함.
3. crittercism
1. http://www.crittercism.com/
2. 유료

요즘 자바 대신 C계열 언어를 익히고 있는데 배우면서 드는 생각은
프로그래밍에서도 등가교환의 법칙이 있구나 하는 생각입니다.

자바는 가비지컬렉션이라는 넘이 있습니다. 개발자를 편하게 해주는 거죠~
그 반면에 C계열에는 가비지컬렉션이 없습니다.

프로그램을 돌리기 위해서는 메모리에 올리고 지우고 올리고 지우고 올리고 지우고를 반복하면서

 실행되게끔합니다. 모바일에서 지우지 않고 계속 올리기만 하면 강제종료됩니다. 올리고 지우고..

이게 말이 쉽지 "도대체 언제 지워서 없애야지 하는지"라는 고민을 하게 됩니다. 프로그래밍에서

고민이 하나 늘어난다는 것은 그 고민이 다른 고민들과 엮이게 되어서 고민들이 더더더 커질 수도

있습니다. 때에 따라서 멘붕도 찾아옵니다.
---여기서 포인트는 프로그래머의 고민증가

그럼 가비지컬렉션이 멀까요. 말 그대로 쓰레기를 수집하는 넘입니다. 내가 메모리에 올리고 지우지

않아도 지울때 되면 알아서 버려줍니다. 오토인거죠. 완전 편합니다. 메모리 지우는 걸 까먹고 있어도

 쓰레기 수집가가 수집해가서 앞에서 말한 강제종료를 어느정도 막아줍니다. 하지만 쓰레기 수집가도

하나의 큰 작업입니다. 쓰레기를 수집하기 위해서는 그게 쓰레기인지 아닌지 cpu가 체크를 계속 해줘야합니다.
---여기서 포인트는 가비지컬렉션는 또하나의 큰 작업임~

말을 종합해보면 자바는 개발자를 편하게 해주지만 퍼포먼스는 C계열보다 못합니다.(기기가 월등해야지 비슷함)
하지만 자바는 개발자의 고민을 덜어주죠..

반대로 C계열은 퍼포먼스는 좋지만 가끔 개발자를 힘들게 합니다.

여기서 내가 얻는 그 가치에 맞게 다른 것(대가)을 교환하는 등가교환이 생깁니다.

편하고 쉬울 것을 선택하면 그만큼 불이익이 생길 수도 있는 거죠.

간단한 예를 하나 더 들자면 자동차를 볼 수 있습니다. 수동과 오토, 앞에서 말한 가비지컬렉션의 유무와 비슷한 조건입니다.

수동은 배우기 어렵고 힘들지만 연비효율이 좋아집니다.

오토는 배우기 쉽고 다루기 쉽지만 그만큼 연비효율은 떨어집니다.

말이 너무 길었네요. 제가 하고 싶은 말은 배우는 게 힘든 만큼 그 만큼의 플러스 등가교환이 일어난다는 것입니다.