2016.01.14 22:33


[Android] EditText 키보드 엔터(Enter)키 기능 변경


안드로이드에서 EditText에 텍스트를 입력할 때 소프트 키보드의 엔터키가 상황에 따라 다르게 나타나는 것을 종종 볼 수 있습니다. 예를 들어 아래의 그림처럼 인터넷 브라우져 주소창이면 '이동' 또는 '검색' 으로, 검색창이면 '검색'으로, 정보 입력창이면 '완료' 등을 볼 수 있죠. 이렇게 소프트 키보드의 엔터키를 상황에 맞게 바꿔주는 방법에 대해서 알아보도록 하겠습니다.





엔터키를 변경하기 위해서는 우선 EditText가 존재하는 xml에서 imeOptions와 inputType 어트리뷰트를 설정해줍니다. 예시는 엔터키를 '검색'으로 바꾼 예입니다.


xml 코드 예시


<EditText

...

android:imeOptions="actionSearch"

android:inputType="text"

/>


Java 코드 예시


editText.setImeOptions(EditorInfo.IME_ACTION_SEARCH);

editText.setInputType(InputType.TYPE_CLASS_TEXT);


imeOptions 에 적용될 수 있는 어트리뷰트는 다음과 같습니다.


xml 코드


android:imeOptions="normal"     // 특별한 의미 없음

android:imeOptions="actionUnspecified"     // 특별한 의미 없음

android:imeOptions="actionNone"     // 특별한 의미 없음

android:imeOptions="actionGo"     // '이동'의 의미 (예 : 웹 브라우져에서 사용)

android:imeOptions="actionSearch"     // '검색'의 의미 (예 : 네이버 검색창)

android:imeOptions="actionSend"     // '보내기'의 의미 (예 : 메세지 작성시 사용)

android:imeOptions="actionNext"     // '다음'의 의미 (예 : 회원가입시 다음 필드로 이동시)

android:imeOptions="actionDone"     // '완료'의 의미 (예 : 정보 입력창)

android:imeOptions="actionPrevious"     // '이전'의 의미 (예 : 회원가입시 이전 필드로 이동시) - API11부터 가능


Java 코드


EditorInfo.IME_ACTION_NONE    // 특별한 의미 없음

EditorInfo.IME_ACTION_UNSPECIFIED    // 특별한 의미 없음

EditorInfo.IME_ACTION_GO     // '이동'의 의미 (예 : 웹 브라우져에서 사용)

EditorInfo.IME_ACTION_SEARCH     // '검색'의 의미 (예 : 네이버 검색창)

EditorInfo.IME_ACTION_SEND     // '보내기'의 의미 (예 : 메세지 작성시 사용)

EditorInfo.IME_ACTION_NEXT     // '다음'의 의미 (예 : 회원가입시 다음 필드로 이동시)

EditorInfo.IME_ACTION_DONE     // '완료'의 의미 (예 : 정보 입력창)

EditorInfo.IME_ACTION_PREVIOUS     // '이전'의 의미 (예 : 회원가입시 이전 필드로 이동시) - API11부터 가능


위와 같이 작성해주고 Java 코드 에서 EditText에 OnEditorActionListener 인터페이스를 연결해줘야합니다.


editText.setOnEditorActionListener(new OnEditorActionListener() { 

@Override

public boolean onEditorAction(TextView v, int actionId, KeyEvent event) {

switch (actionId) {

case EditorInfo.IME_ACTION_SEARCH:

Toast.makeText(getApplicationContext(), "검색", Toast.LENGTH_LONG).show();

break;

default:

Toast.makeText(getApplicationContext(), "기본", Toast.LENGTH_LONG).show();

return false;

}

return true;

}

});


여기까지 다 완료 해주면 소프트 키보드의 엔터키가 검색으로 바뀌고 클릭 되었을 때 이벤트를 받아 올 수 있습니다.





신고


Posted by injunech
2015.12.12 10:03


간단한 큐(Queue)의 구현


순환 큐가 가장 좋은 것으로 알고 있지만 

빠른 알고리즘의 구현을 할 경우에는 전체 큐의 범위를 넉넉하게 잡고 아래와 같은 방식으로 구현하였다.

큐는 BFS 알고리즘을 쓸때 주로 이용된다.


여기서 사용된 Front 와 Rear 의 용도는 다음과 같다.

값의 존재 기준으로 보면
Front 는 값이 존재하는 제일 앞에서 index 값이 -1 만큼인 값
Rear 는 값이 존재하는 제일 마지막에서 index 값이 +1 만큼인 값

값을 넣어야 하는 기준으로 보면
값을 꺼낼 때 Front 의 현재 index 에서 +1의 위치 값을 꺼내온다.
값을 넣을 때 Rear 의 index 위치에 값을 넣는다.

Queue에 Push 할때는 Rear 가 가리키는 Index 에 넣고 Rear 의 값을 +1 한다.
Queue에 있는 값을 Pop으로 꺼낼때는 Front 의 +1한 다음 Index 값이 Rear 와 같은 경우 Null 을 알려주고 그렇지 않은 경우 Front 값을 +1 하고 해당 위치에 값을 Return 한다.


#include <stdio.h>

#define SIZE 100

struct vertex{
	int x;
	int y;
}typedef vertext;

vertext queue[SIZE];
int front=-1;
int rear=0;

void push_rear(vertext a){
	queue[rear++] = a;
}

vertext pop_rear(){
	if (rear == front+1){
		// QUEUE NULL
		printf("QUEUE is NULL\n");
	}
	else{
		return queue[++front];
	}
}

void printQueue(){
	int i=front+1;
	printf("QUEUE : ");
	if (i < rear){
		do{
			printf("(%d, %d) ", queue[i].x, queue[i].y);
			i++;
		} while (i< rear);
	}
	printf("\n");

}

int main(){
	int i=0;
	int T=0;
	vertext value;
	int b,c,d,e,f,g;

	int a[10];
	
	while (1){
		printf("----------------\n");
		printf("1. Push 2.Pop\n");
		scanf("%d", &T);

		if (T == 1){
			scanf("%d %d", &value.x, &value.y);
			printf("%d %d", value.x, value.y);
			push_rear(value);

		}
		else if (T == 2){
			pop_rear();
		}

		printf("----------------\n");
		printQueue();
	}

	return 0;
}
 



신고


Posted by injunech
2015.12.06 19:23


Syntax Highlighter이 뭐냐면... 그냥 소스코드 예쁘게 뿌려주는거다. 이 글에서도 자주 쓰이니 알아서 판단하시고.

일단 티스토리는 Syntax Highlighter를 제공하지 않는다. 플러그인을 마음대로 설치할 수도 없으니 물건너간 줄 알았으나...
찾아보니까 된다 카더라 'ㅅ' 그러니까 스킨 뜯어고치면 된다.

소스 홈페이지 : http://alexgorbatchev.com/SyntaxHighlighter/ (오픈소스로 공개중이다. 감사하도록.)



1. 설치방법

설정 - 스킨 - HTML/CSS 편집 들어간 후, </body>와 </html> 사이에 다음 내용을 추가해 준다.


<link rel='stylesheet' type='text/css' href='http://alexgorbatchev.com/pub/sh/current/styles/shCore.css' />
<link rel='stylesheet' type='text/css' href='http://alexgorbatchev.com/pub/sh/current/styles/shThemeDefault.css' />
<script src='http://alexgorbatchev.com/pub/sh/current/scripts/shCore.js' type='text/javascript'></script>
<script src='http://alexgorbatchev.com/pub/sh/current/scripts/shBrushXml.js' type='text/javascript'></script>
<script src='http://alexgorbatchev.com/pub/sh/current/scripts/shBrushCpp.js' type='text/javascript'></script>
<script src='http://alexgorbatchev.com/pub/sh/current/scripts/shBrushPhp.js' type='text/javascript'></script>
<script type="text/javascript">
SyntaxHighlighter.all();
</script>


2. 사용방법

우선 편집기에서 소스를 쭉 작성한다. < 를 &lt; 로 작성해야 하는데, 이건 티스토리 편집기에서 자동으로 치환해 준다.
그리고 HTML 모드에서 위아래를 <pre> - </pre> 태그로 묶어주는데, 코드 종류에 따라 태그 클래스를 미묘하게 바꿔줘야 한다.


CPP 코드 : <pre class="brush: cpp"> - </pre>
HTML : <pre class="brush: html"> - </pre>
PHP : <pre class="brush: php"> - </pre>



정확하게는 위에서 추가해 준 브러시 타입만 사용할 수 있다. 저 위 소스 잘 보면 shBrush___.js 를 삽입하는걸 볼 수 있는데 이 부분.
다른쪽(Ruby라거나...) 쓰는 블로그라면 알아서 홈페이지 뒤져서 바꿔주면 되겠다.
(설마 코드 다루는 블로그 주인장이 저 정도 응용력도 없진 않겠지...)


파이어폭스 사용시, 코드 뒤에 <br /> 붙는건 지워줘야 한다. 아니면 아래처럼 소스에 한 줄 추가해주면 알아서 삭제하고 파싱해 준다.

<script type="text/javascript">
SyntaxHighlighter.config.stripBrs = true;
SyntaxHighlighter.all();
</script>


3. Include 부분은 아래와 같이 입력 해준다.

#include &lt;stdio.h&gt;



끝!

신고

'Programming > HTML' 카테고리의 다른 글

티스토리 Syntax Highlighter 설치  (0) 2015.12.06


Posted by injunech
2015.12.06 19:16


[BackTracking] 체스 여왕말 놓기 (N-Queen Problem)



되추적(Backtracking) 방법을 얘기 할 때 가장 많이 거론 되는 듯한 N-여왕말(N-Queen) 문제이다. 어떤 문제인가하면 서양 장기(Chess:이후 체스)의 여왕말(Queen:이후 퀸)을 서로가 서로의 이동경로가 아닌 위치에 있도록 최대한 많은 퀸을 체스판 위에 놓는 문제이다.


 원래 체스판은 8ⅹ8이지만 간단히 4ⅹ4일 경우에 좌측의 결과와 같이 되는 경우를 찾는 것이 바로 N-Queen 문제 이다.

 4ⅹ4일 경우에는 좌측과 같은 2가지의 경우만 나오지만 체스판이 커지면 커질수록 다양한 경우의 수가 나온다. 우선 정해진 것은 NⅹN의 체스판에 올라갈 수 있는 퀸의 최대 갯수는 언제나 N이 된다는 점이다.


 그렇다면 어째서 이것이 되추적(Backtracking) 방법이 되느냐 하는 것은

① 첫번째 퀸이 (1, 1) 위치에 오게 될 경우

② 두번째 퀸은 (2, 3) 과 (2, 4) 위치에 올 수 있다. 우선 (2, 3) 위치에 퀸을 놓는다면

③ 세번째 퀸을 놓을 수 있는 자리는 없어진다. 그러면 다시 ②로 돌아가서 두번째 퀸을 (2, 4) 위치에 놓게 되면

④ 세번째 퀸을 (3, 2) 위치에 놓을 수 있지만 이렇게 되면 네번째 퀸을 놓을 수가 없어진다. 그렇게 되면 이번엔 다시 ①로 돌아가서 첫번째 퀸을 (1, 2)에 놓고 다시 시작한다.


 위의 과정과 같이 결과값을 찾아가다가 그 방법이 아니라는 것을 알았을 때 이전 단계로 돌아가는 것이 바로 되추적 방법이다.


 N-Queen의 문제의 경우 참고 자료에 있는 책을 본다면 좀 더 쉽게 알 수 있을 것이다. 언제나와 같이 나는 참고자료에 있는 'Foundations of Algorithms.....' 책을 참고로 해서 프로그램을 작성하였다.

 N값을 입력 받아서 결과를 보여주는 N-여왕말 문제 알고리즘


참고자료 

알고리즘(Foundatations of Algorithms Using C++ Pseudocode) - Neapolitan, Naimipour 저 / 도경구 역

누워서 읽는 알고리즘 - 임백준 저



#include <stdio.h>
#include <malloc.h>
#include <math.h>

void queens(int i, int n, int col[]);   // n개 여왕말 알고리즘
void printqueen(int n, int col[]);      // n개 여왕말의 위치 출력
int promising(int i, int col[]);    // 유망한지 검사하는 함수

int main()
{
	int i;
	int n;
	int* col;

	printf("How many Columns or Rows?\n> ");
	scanf("%d", &n);
	getchar();

	// 여왕말이 해당행의 몇번째 열에 있는지 저장
	col = (int*)malloc(sizeof(int)*n);

	// 뿌리 노드(0)부터 탐색을 시작
	queens(0, n, col);

	free(col);

	return 0;
}

void queens(int i, int n, int col[])
{
	int j;

	if (promising(i, col)) // 유망한가?
	if (i == n) // n개의 여왕말 위치를 찾았나?
		printqueen(n, col); // 여왕말 위치 출력
	else
	for (j = 1; j <= n; j++) {    // (i+1)번째 행에 있는 여왕말을
		col[i + 1] = j;           // n개의 열에 놓을 수 있는지 각각
		queens(i + 1, n, col);    // 검사한다.
	}
}

void printqueen(int n, int col[])   // 보기 편하게 결과값을 출력
{
	int j, k;
	printf("    |");           // 상단 열의 갯수 출력 부분
	for (j = 1; j <= n; j++)
		printf("%3d |", j);
	printf("\n");

	for (j = 0; j <= n; j++)    // 행을 나누는 선 출력
		printf("----+");
	printf("\n");

	for (j = 1; j <= n; j++) {
		printf("%3d |", j);   // 행의 번호
		for (k = 1; k < col[j]; k++) {
			if (((k + j) % 2))
				printf("▩▩|");    // 여왕말이 없는 칸
			else
				printf("    |");    // 여왕말이 없는 칸
		}
		printf("QUEE|");      // 여왕말
		for (k = col[j]; k < n; k++){
			if (!((k + j) % 2))
				printf("▩▩|");    // 여왕말이 없는 칸
			else
				printf("    |");    // 여왕말이 없는 칸
		}
		printf("\n");

		for (k = 0; k <= n; k++)   // 행을 나누는 선 출력
			printf("----+");
		printf("\n");
	}
	printf("\n");

	printf("Press ENTER to continue");
	getchar();  // 결과 값이 많으므로 하나의 결과값마다 멈추도록
}

int promising(int i, int col[]) // 유망한지 판단하는 함수
{
	int k;
	int bSwitch;

	k = 1;
	bSwitch = 1;
	while (k < i && bSwitch) {
		/* col[i] == col[k] 는 같은 열에 있는지 판별한다
		* abs(col[i] - col[k]) == i - k의 경우는
		* 2개의 여왕말간의  행의 차와 열의 차의 절대값이 같으면
		* 같은 대각선상에 있다는 의미이다. */
		if (col[i] == col[k] || abs(col[i] - col[k]) == i - k)
			bSwitch = 0;
		k++;
	}
	return bSwitch;
}



출처 : http://egloos.zum.com/sakuragis/v/3468837 

신고


Posted by injunech
2015.11.29 22:36


startActivityForResult() 메서드를 실행시킬 경우 Activity로 돌아올 때 onResume() 메서드와 onActivityResult() 메서드의  우선순위는?

먼저 Activity의 생명 주기를 확인해보겠습니다.



사진 찍기 이후와 갤러리를 다녀오고 난 다음에 Activity로 돌아와 onActivityResult() 메서드가 실행되는 것을 로그로 찍어 봤는데 다음과 같은 경우가 있었습니다.

Case 1

onPause()
onStop()
————————— (갤러리나 사진을 찍으러 다녀옴)
onActivityResult()
onRestart()
onStart() ← Point View
onResume() ← Point View

Case 2

onPause()
onStop()
————————— (갤러리나 사진을 찍으러 다녀옴)
onRestart()
onActivityResult()
onStart() ← Point View
onResume() ← Point View

Case 3

onPause()
onStop()
onDestroy()
————————— (갤러리나 사진을 찍으러 다녀옴)
onCreate()
onStart() ← Point View
onActivityResult()
onResume() ← Point View

정리

뭔가 일정하지 않습니다. 하지만 정리해보면 아래와 같습니다.

onActivityResult() 메서드는

  1. onStart() 메서드 전·후로 실행 된다.
  2. onResume() 메서드 전에 꼭 실행 된다.

결론

onResume() 메서드는 Activity로 돌아올 경우 꼭 실행이 되는 메서드입니다. startActivityForResult() 메서드를 실행시킬 경우 Activity로 돌아올 때onResume() 메서드와 onActivityResult() 메서드 중 어떤 것이 우선순위가 있는 것인지 확인해보지 않고서는 헷갈리기 쉬운 부분 입니다.

로그를 찍어 확인해 봤으니 이젠 잊지 말아야겠네요. (잊을까봐 여기에 정리해놓습니다… 흑…)

startActivityForResult() 메서드가 먼저 실행되고 onResume() 메서드가 나중 실행된다!


신고


Posted by injunech
2015.10.14 00:53



Eclipse 상으로 Project 를 불러온 이후에 (시작하기02 참고) Visual Studio 나 다른 개발 Tool 을 이용하여 Project 의 Root 폴더상에 Classes 의 코드를 수정 한 이후에 .so build를 해주어 .so 파일 생성을 한다.

ProjectName/proj.android 폴더 상에 존재하는 build_native.py 파일을 실행. (해당 Script 를 이용하기 위해서는 python 환경 설정 되어 있어야 합니다.)


정상적으로 so 빌드가 되지 않는 경우 (couldnt find "libcocos2dcpp.so" 에러 발생)

ProjectName/proj.android/jni 폴더에 Android.mk 파일에 Build Script 에서 Classes 폴더의 모든 CPP 파일이 정상 빌드 되도록 수정하여 야합니다. (시작하기02 참고)





신고


Posted by injunech
2015.10.12 01:51


이 글에서는 이클립스를 사용한 Cocos2d-x 3.2 프로젝트 빌드 및 발견된 빌드 문제 해결 방법을 다룹니다


커멘드창을 이용하지 않고 이클립스를 사용하는 이유는 다음과 같습니다:

  • 세팅이 된 다음엔 빌드 및 스마트폰에의 실행이 아주 쉽다

  • 이클립스를 통해 디버깅이 가능

  • 이클립스를 통해 개발이 가능

  • 최신 버전의 서브시스템에 (ndk10...)에 간단히 대응

    • 굳이 최신 버전을 고집할 필요는 없지만(ndk9로 충분. 대부분은 ndk9를 사용하는 것 같습니다)

    • 그러나 최신 버전을 고집하면 프로젝트의 생명주기가 길어지죠.

  • 빌드에 사용될 cocos 라이브러리, 안드로이드 라이브러리를 언제든 쉽게 수정 가능



빌드 환경



  • Intel 64bit CPU
  • Windows7 64bit
  • Visual Studio 2013
  • Python 2.7
  • cocos2d-x 3.2
  • ndk10
  • ant1.9.4
  • Eclipse Luna
  • Android API 10 (2.3.3)
  • Java7



시작하기 전에



cocos2d-x 3.2를 안드로이드에 맞추어 빌드하는 과정은 굉장히 손이 많이 가는 작업입니다.

아래의 과정 중 단 하나라도 놓치면 빌드에 성공할 수 없습니다.

인내심을 가지고 아래의 과정을 하나하나 밟아가세요.





이클립스에 프로젝트 추가





File-Import-Existing Projects into Workspace를 선택하고

프로젝트 위치는 해당 게임 프로젝트\proj.android를 선택하면 됩니다.


Copy projects into workspace 옵션은 사용하지 마세요! 소스코드는 언제든지 변경 가능해야 하니까요.





프로젝트 설정



Import된 프로젝트는 기본적으로 설정이 맞게되어 있지 않습니다.

이클립스 환경에 맞게 프로젝트를 변경하도록 합니다.


1. cocos2d-x Andoird Library Project 추가

**이 1번 과정은 딱 한번만 하면 됩니다. 다른 게임 프로젝트를 다루게 되더라도 반복할 필요 없습니다.


File-Import-Existing Projects into Workspace를 선택하고


프로젝트 위치는 cocos2d-x 설치 디렉토리\cocos\platform\android\java를 선택하면 됩니다.

예) C:\cocos2d-x\cocos\platform\android\java


Copy projects into workspace 옵션을 선택하세요! 코코스 엔진 원본 소스코드는 건드려봤자 좋을게 없겠죠.




2. 프로젝트 설정 변경


여러분이 작성한 게임 프로젝트를 선택하고 Properties로 들어갑니다.

그리고 아래의 스크린샷을 따라서 라이브러리 설정을 고칩니다.








3. 문제 있는 소스코드 변경


3-1> 엔진 오타 수정


프로젝트/cocos2d/cocos/3d/CCBundleReader.h의 tell()함수 부분을

long int tell(); 에서

ssize_t tell(); 로 변경하세요


왜 그런지 모르겠지만 cocos2d-x 3.2자체에 문제가 있네요. 반환형이 잘못되어 있습니다 --;



3-2> 자동 CPP 소스파일 추적 및 추가

프로젝트/jni/Android.mk 파일을 수정합니다

LOCAL_SRC_FILES := hellocpp/main.cpp \
../../Classes/AppDelegate.cpp \
../../Classes/HelloWorldScene.cpp
부분을

FILE_LIST := $(wildcard $(LOCAL_PATH)/../../Classes/*.cpp)
LOCAL_SRC_FILES := $(FILE_LIST:$(LOCAL_PATH)/%=%)
LOCAL_SRC_FILES += hellocpp/main.cpp


로 변경합니다.


Classes폴더 안에 있는 모든 cpp파일을 자동으로 빌드 시에 포함시키도록 변경하는 것입니다.

물론 LOCAL_SRC_FILES부분을 늘려나가도 되겠지만 그런 바보같은 수고를 할 사람은 없겠죠.




4. 실행


에뮬레이터가 아닌 실제 안드로이드 스마트폰을 사용하시는 걸 추천합니다

Ctrl+B를 눌러 빌드하시고

프로젝트 우클릭->Run AS->Android Application을 누릅니다




5. 끝!


이제 여러분이 개발한 게임이 안드로이드에서 실행되는걸 볼 수 있습니다

끝없이 해결해야할 게임버그는 잠시 잊으시고 행복해 하셔도 좋습니다.





PLUS+

혹시 Visual Studio에서는 잘됐는데 다른 플랫폼에서 한글이 깨지거나

빌드 도중 error: format string is not a string literal (potentially insecure) [-Werror,-Wformat-security] 메시지가 발생하면

아래의 추가 문제 해결을 참조하세요




추가 문제 해결



1. 로그로 인해 발생하는 빌드 에러 해결

error: format string is not a string literal (potentially insecure) [-Werror,-Wformat-security] 에러 해결 방법입니다.


프로젝트/jni/Application.mk 파일의


APP_CPPFLAGS := -frtti -DCC_ENABLE_CHIPMUNK_INTEGRATION=1 -std=c++11 -fsigned-char

APP_LDFLAGS := -latomic

부분을


APP_CPPFLAGS := -frtti -DCC_ENABLE_CHIPMUNK_INTEGRATION=1 -std=c++11 -fsigned-char

APP_CPPFLAGS += -Wno-error=format-security

APP_LDFLAGS := -latomic

로 변경하세요


[문제가 생긴 이유]




2. 한글 깨짐 해결


Visual Studio에서는 잘만 출력되던 한글이 다른 플랫폼(안드로이드,IOS)에서 깨진다면

파일의 저장 형식이 잘못되었을 확률이 높습니다.


STEP1>

Visual Studio에서 한글이 들어있는 소스코드를 띄웁니다. 그리고 나서 파일->고급 저장 옵션을 열어

인코딩

유니코드(서명 있는 UTF-8)

줄 끝

Unix

로 설정하세요.



STEP2>

또한 이클립스 프로젝트의 Properties을 아래와 같이 설정합니다.



출처 : http://makerj.tistory.com/156



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



위 작업을 완료 한 뒤에 추가로 발생 하는 아래와 같은 에러는

다음 방법으로 해결 ㅎ


1) cannot find : cocod2d-x libcocos2dcpp.so

2) The import org.cocos2dx.lib cannot be resolved





1) cannot find : cocod2d-x libcocos2dcpp.so


NDK 빌드

일단 명령프롬프트(윈도우버튼 > 프로그램파일검색 창에서 cmd)를 엽니다. 다음과 같이 cd 명령을 수행해서 앞서 새로 만든 프로젝트의 proj.android폴더로 이동합니다.(역시 폴더 이름은 각자의 것에 맞게)

이제 NDK 빌드를 하기 위해 파이썬 스크립트를 수행합니다.

> build_native.py

그럼 컴파일이 쫙쫙쫙 수행됩니다. 빌드 후 메시지가 다음과 같이 나오며 proj.android\libs\armeabi에libcocos2dcpp.so 파일이 생성되면 NDK 빌드가 완료 된 것입니다.


설정 파일 변경

이제 libcocos2dcpp.so를 Java와 연결하고 빌드하여 APK 파일을 생성하면 됩니다. 그 전에 설정 좀 바꿔줘야 할 것이 있습니다.

일단 AndroidManifest파일의 수정이 필요합니다. 안드로이드 프로젝트의 속성 파일이라고 생각하시면 됩니다. proj.android 디렉터리에 있는 AndroidManifest.xml 파일을 문서편집기로 열어 다음과 같이 sdk 버젼이 9로만 되어 있는 것을 

<uses-sdk android:minSdkVersion="9"/>

다음과 같이 target을 14로, min을 10으로 바꾸어줍시다.

<uses-sdk android:minSdkVersion="10" android:targetSdkVersion="14"/>

여기서 가리키는 SdkVersion은 앞서 ADT에서 설치했던 API 레벨을 의미합니다. 수정 전에 입력되어 있던 9는 전설속에만 존재하는 API고, 우린 전설을 믿지 않으니 수정해 주는겁니다. 기왕이면 target SDK를 구글에서 권장하는 14레벨로 설정합니다. API14는 4.0 아이스크림샌드위치인데 그럼 그 이하 버젼은 지원을 안하는 것이냐!? 그건 걱정하지 맙시다. 하위 OS 호환성을 위해서 targetSdkVersion과 minSdkVersion이 따로 있습니다. 최소 지원 SDK 값을 10으로 지정해줘서 2.3.3 생강빵 이상에서 돌아가게 해줍니다. 사실상 현존하는 최소 버젼은 API8 2.2 프로요이긴 하지만 target을 14로 설정하면 8의 설정과 충돌나는 부분이 있어서 애석하게도 사용하지 못합니다. 2.2 프로요는 아직 점유율이 2.7%나 되서 버리기에는 조금 아깝긴합니다. 하지만 타겟을 4.0 아이스크림샌드위치로 설정해야 태블릿에서 검색 가능하기때문에 살을 내주고 뼈를 취하는게 낫습니다.



2) The import org.cocos2dx.lib cannot be resolved



proj.android/src 폴더에 들어가 보시면 org/cocos2dx   폴더가 있을겁니다 이 내부가 비어 있는건 아닌지 확인해 보세요.

원래 create-android-project.sh를 실행했을때 이부분이 자동으로 채워져야 하는데 생성이 되지 않는 경우가 있습니다. 이런경우엔 수동으로 복사해 주면 되는데요.

 cocos2d-x-3.6/cocos/platform/android/java/src/에 들어가보시면 같은 구조의 디렉토리가 존재합니다.   이안에 있는 org 폴더를 통채로 복사해서 proj.android/src/ 에 그대로 복사해 붙여 넣은후 eclipse 에서 f5버튼으로 reflash 한후에 다시 빌드


신고


Posted by injunech
2015.10.12 01:33


Cocos2D-x 3.2에는 파이썬 스크립트 project-creator가 사라졌습니다 ㅠㅠ

따라서 콘솔 명령으로 생성해야 합니다.


 > Project name : GAME01 

 > Package name : com.cij.game01

 > Project directory : C:\Workspace\COCOS2D_Proejct\

 

라고 가정하고 생성하는 예시입니다


C:\cocos2d-x-3.6\tools\cocos2d-console\bin>

위와 같이 cocos2d-x 설치한 폴더 경로 내에 consol 폴더 내부 bin 에서 커맨드 창 실행하고 다음과 같은 명령어로 프로젝트를 생성 합니다.

python cocos.py new GAME02 -p com.cij.game01 -l cpp -d C:\Workspace\COCOS2D_Proejct\


위 방법은 cocos 에서 제공하는 Python 스크립트를 이용하여 프로젝트 생성하는 방법이며 다음 방법으로도 생성 가능합니다. (cocos 설치 폴더 환경 설정 완료 이후.)

cocos new GAME01 -p com.cij.game01 -l cpp -d C:\Workspace\COCOS2D_Proejct\

 

# 명령어 의미

'cocos new 게임이름 ?p 패키지명 ?l 사용할언어 ?d 프로젝트저장경로'



에러가 발생하지 않았다면 새 프로젝트 생성에 성공한 것입니다.



프로젝트 폴더 내의 proj.win32안에 있는 Visual Studio Solution파일을 실행하면 이제 Visual Studio에서 제작이 가능해집니다.



신고


Posted by injunech
2015.09.20 15:23


안드로이드 앱을 만들 때 가장 많이 하는 일 중에 하나가 사진을 찍어서 올리거나 인터넷에 있는 사진을 받아다 사용자에게 보여주는 일입니다. 스마트폰이 가진 중요한 기능 중의 하나가 카메라가 내장되어 있다는 것이고 이것이 인터넷과 연결되어 다른 사용자들에게 쉽게 공유할 수 있다는 것이기 때문이죠. 그래서 모바일 앱의 주요 컨텐츠 생산이나 소비 형태도 사진으로 많이 이루어져 있습니다.

드로이드 개발자 공식 사이트에서도 상당히 앞쪽 부분에 사진을 다루는 비트맵에 대한 트레이닝 세션을 만들어 놓았습니다. 공부차 공식 사이트의 내용을 간단히 추려서 옮겨 봅니다. 원문과 샘플코드 다운로드는 Displaying Bitmaps Efficiently에서 보실 수 있습니다. 


출처: 안드로이드 개발 사이트(http://develper.android.com). 번역: 용현택


안드로이드에서 처음에 아무생각없이 Bitmap 오브젝트를 이용해 사진을 불러오려다. 

java.lang.OutofMemoryError: bitmap size exceeds VM budget

라는 메세지와 부딪히게 될 것이다. 당연히 메모리가 부족해서 나는 에러 이고 몇가지 이유가 있을 수 있는데 대강 다음의 이유로 뻗는 것이다. 

- 안드로이드 장비의 메모리는 무한정이 아니다. 안드로이드 장비가 하나의 앱에 허용하는 메모리는 16MB이하를 사용하도록 하고 있다. 대부분의 디바이스들에서는 16MB보다 높게 제한이 걸려있긴 하지만 이보다 작은 메모리를 사용하도록 최적화 해야 할 것이다. 따라서 이 제한을 넘게되면 에러가 난다. 

- 이미지는 메모리를 굉장히 많이 잡아 먹는다. 특히 요즘폰들은 화소가 높아서. 갤럭시 넥서스 같이 500만 화소 카메라로 찍게되면 2592*1936픽셀의 사진이 생겨나는데 ARGB_8888로 셋팅되어 있다면 한 픽셀당 4바이트를 사용해서 결과적으로 19MB를 차지하게 된다.한두장만 사용해도 장비의 메모리 제한은 가벼웁게 넘어버린다. 

- 여러개의 이미지를 한방에 로드하려는 경우가 많다. 예를들어 ListView나 GridView, ViewPager 같은 경우에는 한 화면에 여러개의 이미지를 보여주어야 하고 스크롤에 대비해서 미리 이미지들을 가지고 있어야 되는 경우도 많기 때문이다. 

그러면 큰 이미지를 어떻게 로드해서 화면에 보여주는게 효과적일지, 디스크나 인터넷으로 부터 비동기식으로 이미지를 받아와 처리하는 방법, 이미지를 캐싱하는 방법에 대해서 설명하도록 하겠다.

1. 큰 이미지를 (효율적으로)화면에 보여주자.

위에서도 얘기했지만 고해상도의 이미지를 불러와 그대로 메모리에 넣고 화면에 보여주는 것은 바로 OutOfMemory로 가는 지름길이다. 그러면 어떻게 할 것인가. 원래 이미지의 해상도와 상관없이 화면에 보여질 해상도 만큼 줄여서 읽어들이면 되지 않을까? 그러려면 원래 이미지의 해상도와 화면에 보이려는 ImageView의 해상도를 알아내어 품질을 떨어뜨리면 된다. 

읽어드리려는 이미지의 해상도를 알아내기 위해서는 BitmapFactory.Options의 inJustDecodeBounds = true로 셋팅해놓고 읽어 들이면 된다. 그러면 이미지를 메모리에 올려놓지 않고 해상도만 알아낼 수 있다. 다음의 코드를 보자. 

BitmapFactory.Options options = new BitmapFactory.Options();
options.inJustDecodeBounds = true;
BitmapFactory.decodeResource(getResources(), R.id.myimage, options);
int imageHeight = options.outHeight;
int imageWidth = options.outWidth;
String imageType = options.outMimeType;

이미지를 메모리에 로드하지 않고 크기만 알아내는 코드이다. 여기서 decodeResource 함수는 decodeFile처럼 BitmapFactory.decode* 메소드들로 바꾸어서 쓸 수 있다. 이제 BitmapFactofy.Options의 inSampleSize 파라메터를 이용해서 이미지의 해상도를 줄일 수 있다. inSampleSize는 이미지의 몇분의 1로 해상도를 줄일지를 나타낸다. 예를들어 inSampleSize를 4로 셋팅하면 2048x1536의 이미지를 읽어들일 때 512*384로 가로세로 1/4크기로 줄여들여 읽어들인다.(면적은 1/16로) 자 이제 다음 코드처럼 이미지를 보여줄 화면의 크기만큼 해상도를 떨어뜨려 읽을 수 있다. 

 // Get the dimensions of the View
int targetW = mImageView.getWidth();
int targetH = mImageView.getHeight();
  
// Get the dimensions of the bitmap
BitmapFactory.Options bmOptions = new BitmapFactory.Options();
bmOptions.inJustDecodeBounds = true;
BitmapFactory.decodeFile(mCurrentPhotoPath, bmOptions);
int photoW = bmOptions.outWidth;
int photoH = bmOptions.outHeight;
  
// Determine how much to scale down the image
int scaleFactor = Math.min(photoW/targetW, photoH/targetH);
  
// Decode the image file into a Bitmap sized to fill the View
bmOptions.inJustDecodeBounds = false;
bmOptions.inSampleSize = scaleFactor;
bmOptions.inPurgeable = true;
  
Bitmap bitmap = BitmapFactory.decodeFile(mCurrentPhotoPath, bmOptions);
mImageView.setImageBitmap(bitmap);

위와 같이 실제 이미지를 읽어들일 때는 inJustDecodeBounds를 false로 해둔다. inSampleSize의 경우 2의 배수로 사용할 경우 퍼포먼스가 가장 좋긴 하지만 퍼포먼스보다 메모리를 조금이라도 아끼는게 중요하니 2의 배수가 아니더라도 줄일 수 있으면 더 줄이는게 좋다. 

2. 멀티 쓰레드로 이미지를 읽어들이자. 

이미지를 디스크나 네트워크로 부터 읽어들일 때는 메인 UI 쓰레드에서 읽어들이면 안된다. 시간이 얼마나 걸릴지도 모르는 것이고 마냥 기다리게 되면 사용자가 터치를 해도 반응이 없어서 닫으려고 할 것이기 때문이다. 따라서 이미지를 읽어들이는 작업은 별도의 쓰레드에서 해야 하는데 가장 쉬운 방법은 AsyncTask를 이용하는 것이다. 

다음은 AsyncTask를 이용하여 이미지를 읽어들이는 예제이다. 

 class BitmapWorkerTask extends AsyncTask {
    private final WeakReference imageViewReference;
    private int data = 0;

    public BitmapWorkerTask(ImageView imageView) {
        // Use a WeakReference to ensure the ImageView can be garbage collected
        imageViewReference = new WeakReference(imageView);
    }

    // Decode image in background.
    @Override
    protected Bitmap doInBackground(Integer... params) {
        data = params[0];
        return decodeSampledBitmapFromResource(getResources(), data, 100, 100));
    }

    // Once complete, see if ImageView is still around and set bitmap.
    @Override
    protected void onPostExecute(Bitmap bitmap) {
        if (imageViewReference != null && bitmap != null) {
            final ImageView imageView = imageViewReference.get();
            if (imageView != null) {
                imageView.setImageBitmap(bitmap);
            }
        }
    }
}

별도의 쓰레드에서 진행되므로 작업중에 사용자가 다른창으로 이동하거나 할 수 있다. ImageView의 WeakReference를 가지고 있게하여 사용자가 다른창으로 이동하거나 하면 작업이 끝나지 않았더라도 ImageView가 가비지 콜렉팅되게 하였다. 다만 onPostExcute에서 WeakReference에서 ImageView를 가져와 ImageView가 아직 살아있는지 여부를 체크하게 하였다. 

이제 이미지를 별도의 쓰레드에서 비동기식으로 로딩하려면 다음과 같이 실행해주면 된다. 

public void loadBitmap(int resId, ImageView imageView) {
    BitmapWorkerTask task = new BitmapWorkerTask(imageView);
    task.execute(resId);
}

일반 뷰에서는 위와 같이 읽어 들이면 되지만 ListView나 GridView에서 사용하게 될 경우 문제가 발생하게 된다. ListView나 GridView는 메모리를 아끼기 위해 유저가 스크롤 하거나 할 때 이미 만들어 놓았던 뷰를 재활용하기 때문이다. 따라서 이미지 로딩 작업이 끝났을 때 업데이트 하려는 뷰가 이미 다른 이미지를 로딩하며 재활용된 뷰일 수도 있고 이미지 로딩이 언제 끝나느냐에 따라서 이미지를 업데이트 하는 작업이 꼬일 수도 있다. 

 Multithreading for Performance에서는 이 이미지 뷰를 가장 최근에 건드렸던 AsyncTask가 어떤 놈인지 기억해 두었다가 작업이 끝났을 때 그 AsyncTask가 가장 최근놈이 맞는지를 체크하는 방법으로 해결한다. 우리도 비슷한 방법으로 해결해 보자. 

아까 만들었던  workertask를 저장할 수 있는 Drawable클래스를 하나 만든다. 이경우에는 ImageView가 가지고 있는 BitmapDrawable을 사용할 거고 따라서 작업이 끝났을 때 ImageView는 자신이 갖고 있는 BitmapDrawable을 통하여 어느 workertask가 가장최근 놈인지 알 수 있다. 

static class AsyncDrawable extends BitmapDrawable {
    private final WeakReference bitmapWorkerTaskReference;

    public AsyncDrawable(Resources res, Bitmap bitmap,
            BitmapWorkerTask bitmapWorkerTask) {
        super(res, bitmap);
        bitmapWorkerTaskReference =
            new WeakReference(bitmapWorkerTask);
    }

    public BitmapWorkerTask getBitmapWorkerTask() {
        return bitmapWorkerTaskReference.get();
    }
}

그리고 BitampWorkerTask를 실행하기 전에, 타겟 ImageView를 가지고 있는 AsyncDrawable을 하나 만들거다. 

public void loadBitmap(int resId, ImageView imageView) {
    if (cancelPotentialWork(resId, imageView)) {
        final BitmapWorkerTask task = new BitmapWorkerTask(imageView);
        final AsyncDrawable asyncDrawable =
                new AsyncDrawable(getResources(), mPlaceHolderBitmap, task);
        imageView.setImageDrawable(asyncDrawable);
        task.execute(resId);
    }
}

여기서 cancelPotentialWork 메소드에서 이미 다른 task가 ImageView를 참조하고 있고 돌아가고 있는지를 체크할 수 있다. 그래서 아직 돌고 있는 놈이 있으면 새로운 task를 실행하기 전에 돌고 있는 task를 cancel시켜 버린다. 다음은 cancelPotentialWork의 구현이다. 

public static boolean cancelPotentialWork(int data, ImageView imageView) {
    final BitmapWorkerTask bitmapWorkerTask = getBitmapWorkerTask(imageView);

    if (bitmapWorkerTask != null) {
        final int bitmapData = bitmapWorkerTask.data;
        if (bitmapData != data) {
            // Cancel previous task
            bitmapWorkerTask.cancel(true);
        } else {
            // The same work is already in progress
            return false;
        }
    }
    // No task associated with the ImageView, or an existing task was cancelled
    return true;
}

위의 코드에서 getBitmapWorkerTask() 메소드는 이 이미지뷰를 업데이트하기 위해 아직 실행중인 task를 리턴하는 메소드이다. 

private static BitmapWorkerTask getBitmapWorkerTask(ImageView imageView) {
   if (imageView != null) {
       final Drawable drawable = imageView.getDrawable();
       if (drawable instanceof AsyncDrawable) {
           final AsyncDrawable asyncDrawable = (AsyncDrawable) drawable;
           return asyncDrawable.getBitmapWorkerTask();
       }
    }
    return null;
}

마지막으로 작업이 끝나면 BitmapWorkTask에서 이미 cancel됐는지 여부를 체크하고 그렇지 않을 때는 업데이트 하도록 한다. 

class BitmapWorkerTask extends AsyncTask {
    ...

    @Override
    protected void onPostExecute(Bitmap bitmap) {
        if (isCancelled()) {
            bitmap = null;
        }

        if (imageViewReference != null && bitmap != null) {
            final ImageView imageView = imageViewReference.get();
            final BitmapWorkerTask bitmapWorkerTask =
                    getBitmapWorkerTask(imageView);
            if (this == bitmapWorkerTask && imageView != null) {
                imageView.setImageBitmap(bitmap);
            }
        }
    }
}

이제 뷰를 재활용하는 ListView나 GridView에서  있더라도 이 샘플을 사용할 수 있게 되었다. 이제 loadBitmap을 getView()와 같은 곳에서 콜해서 이미지를 로드하면 된다. 

3. 이미지를 캐싱하자.

ListView나 GridView, ViewPager에서는 보통 여러장의 이미지를 동시에 로딩하게 된다. 그리고 사용자가 스크롤을 하게 되면 그 중에 화면에 보이지 않게 되는 이미지의 뷰는 재활용 될 것이고, 메모리가 별로 없기 때문에(이것들이 메모리를 많이 차지하는 작업들이라..)  예전에 로딩된 이미지는 곧 가비지 콜렉팅 될 것이다. 그럼 매번 다시 스크롤해서 올라가고 하면 하게 될 때마다 예전에 불렀던 이미지를 새로 다시 로드하고 하게 하는건 네트웍이 느린 안드로이드 폰에서는 뻘짓이다.  그래서 메모리나 디스크에 캐싱하는 방법을 사용한다. 

- 메모리 캐시를 사용해보자

안드로이드에서는 LruCache를 제공한다. LruCache는 LinkedHashMap을 사용하여 최근에 사용된 object의 strong reference를 보관하고 있다가 정해진 사이즈를 넘어가게 되면 가장 최근에 사용되지 않은 놈부터 쫓아내는 LRU 알고리즘을 사용하는 메모리 캐시다. 예전에는 bitmap cache에 SoftReference나 WeakReference를 사용하는 방식을 썼으나 안드로이드 2.3부터 가비지 콜렉터가 공격적으로 이놈들의 메모리를 가비지 콜렉팅하면서 몹쓸 방법이 됐다.  게다가 이 방법은 3.0이전 버전에서 메모리 해제를 제대로 못해 크래쉬문제도 있다. 

그러니 LruCache를 사용하자. LruCache의 캐시사이즈를 정하기 위해서는 다음 요소들을 고려해야 한다. 

  • 우리 앱에서 앞으로 메모리를 얼마나 써야 되는가. 
  • 얼마나 많은 이미지들이 한 화면에 보일 것인가. 얼마나 많은 이미지들이 다음에 보여주기 위해 준비되어야 하는가. 
  • 화면 해상도가 어떻게 되는가. 
  • 각 이미지마다 메모리를 얼마나 차지하는가. 
  • 이미지는 얼마나 자주 액세스 되는가. 
  • 질보다 양? 양보다 질? 어떤 경우에는 많은 양의 저해상도 이미지를 미리 보여주고 백그라운드로 고해상도 이미지를 로드하는 방법이 좋을 수도 있다. 

딱히 어느정도 캐시사이즈가 적당한지 공식은 없고 앱의 메모리 사용량을 측정해보면서 적당히 정해야 한다. 당연한 말이겠지만 너무 사이즈를 작게하면 괜히 오버헤드만 발생하게 되고 사이즈를 너무 크게했다가 OutOfMemory Exception을 보게 될거다. 아래는 LruCache를 사용한 예제이다.

private LruCache mMemoryCache;

@Override
protected void onCreate(Bundle savedInstanceState) {
    ...
    // Get memory class of this device, exceeding this amount will throw an
    // OutOfMemory exception.
    final int memClass = ((ActivityManager) context.getSystemService(
            Context.ACTIVITY_SERVICE)).getMemoryClass();

    // Use 1/8th of the available memory for this memory cache.
    final int cacheSize = 1024 * 1024 * memClass / 8;

    mMemoryCache = new LruCache(cacheSize) {
        @Override
        protected int sizeOf(String key, Bitmap bitmap) {
            // The cache size will be measured in bytes rather than number of items.
            return bitmap.getByteCount();
        }
    };
    ...
}

public void addBitmapToMemoryCache(String key, Bitmap bitmap) {
    if (getBitmapFromMemCache(key) == null) {
        mMemoryCache.put(key, bitmap);
    }
}

public Bitmap getBitmapFromMemCache(String key) {
    return mMemoryCache.get(key);
}

이 예제에서 앱에서 사용 가능한 메모리의 1/8을 캐시에 할당하였다. 일반적으로 hdpi 디바이스에서는 이 크기가 4MB(32/8)정도 된다. 800x480이미지가 1.5MB정도 되므로 GridView를 사용한다면 2.5 페이지의 이미지를 메모리에 캐싱할 수 있게 된다. 

이미지를 로드할 때 LruCache에서 먼저 찾아보고 있으면 그걸로 바로 업데이트 하고 아니면 백그라운드 쓰레드에서 로딩한다. 

public void loadBitmap(int resId, ImageView imageView) {
    final String imageKey = String.valueOf(resId);

    final Bitmap bitmap = getBitmapFromMemCache(imageKey);
    if (bitmap != null) {
        mImageView.setImageBitmap(bitmap);
    } else {
        mImageView.setImageResource(R.drawable.image_placeholder);
        BitmapWorkerTask task = new BitmapWorkerTask(mImageView);
        task.execute(resId);
    }
}

BitmapWorkerTask도 메모리 캐시를 사용하는 걸로 변경. 

class BitmapWorkerTask extends AsyncTask {
    ...
    // Decode image in background.
    @Override
    protected Bitmap doInBackground(Integer... params) {
        final Bitmap bitmap = decodeSampledBitmapFromResource(
                getResources(), params[0], 100, 100));
        addBitmapToMemoryCache(String.valueOf(params[0]), bitmap);
        return bitmap;
    }
    ...
}

- 디스크 캐시 이용하기

메모리 캐시는 빠르기는 하지만 메모리가 얼마 되지 않기 때문에 이것만 가지고는 부족하다. 그리고 전화가 오거나 하면 앱이 백그라운드로 가버리면서 캐시가 사라져 버리게 된다. 디스크 캐시를 사용하면 데이터가 지속적으로 남아있고 용량도 좀 더 많이 쓸 수 있다. 하지만 당연히 메모리 캐시보다 느리다. 그래도 네트웍에서 읽어들이는 것에 비하면 어딘가. 그리고 ContentProvider를 사용하는게 자주 액세스 되는 이미지를 캐시에 저장하기에 좋다. 아래 코드는 위의 메모리 캐시에 디스크 캐시를 추가한 버전이다. 

private DiskLruCache mDiskLruCache;
private final Object mDiskCacheLock = new Object();
private boolean mDiskCacheStarting = true;
private static final int DISK_CACHE_SIZE = 1024 * 1024 * 10; // 10MB
private static final String DISK_CACHE_SUBDIR = "thumbnails";

@Override
protected void onCreate(Bundle savedInstanceState) {
    ...
    // Initialize memory cache
    ...
    // Initialize disk cache on background thread
    File cacheDir = getDiskCacheDir(this, DISK_CACHE_SUBDIR);
    new InitDiskCacheTask().execute(cacheDir);
    ...
}

class InitDiskCacheTask extends AsyncTask {
    @Override
    protected Void doInBackground(File... params) {
        synchronized (mDiskCacheLock) {
            File cacheDir = params[0];
            mDiskLruCache = DiskLruCache.open(cacheDir, DISK_CACHE_SIZE);
            mDiskCacheStarting = false; // Finished initialization
            mDiskCacheLock.notifyAll(); // Wake any waiting threads
        }
        return null;
    }
}

class BitmapWorkerTask extends AsyncTask {
    ...
    // Decode image in background.
    @Override
    protected Bitmap doInBackground(Integer... params) {
        final String imageKey = String.valueOf(params[0]);

        // Check disk cache in background thread
        Bitmap bitmap = getBitmapFromDiskCache(imageKey);

        if (bitmap == null) { // Not found in disk cache
            // Process as normal
            final Bitmap bitmap = decodeSampledBitmapFromResource(
                    getResources(), params[0], 100, 100));
        }

        // Add final bitmap to caches
        addBitmapToCache(imageKey, bitmap);

        return bitmap;
    }
    ...
}

public void addBitmapToCache(String key, Bitmap bitmap) {
    // Add to memory cache as before
    if (getBitmapFromMemCache(key) == null) {
        mMemoryCache.put(key, bitmap);
    }

    // Also add to disk cache
    synchronized (mDiskCacheLock) {
        if (mDiskLruCache != null && mDiskLruCache.get(key) == null) {
            mDiskLruCache.put(key, bitmap);
        }
    }
}

public Bitmap getBitmapFromDiskCache(String key) {
    synchronized (mDiskCacheLock) {
        // Wait while disk cache is started from background thread
        while (mDiskCacheStarting) {
            try {
                mDiskCacheLock.wait();
            } catch (InterruptedException e) {}
        }
        if (mDiskLruCache != null) {
            return mDiskLruCache.get(key);
        }
    }
    return null;
}

// Creates a unique subdirectory of the designated app cache directory. Tries to use external
// but if not mounted, falls back on internal storage.
public static File getDiskCacheDir(Context context, String uniqueName) {
    // Check if media is mounted or storage is built-in, if so, try and use external cache dir
    // otherwise use internal cache dir
    final String cachePath =
            Environment.MEDIA_MOUNTED.equals(Environment.getExternalStorageState()) ||
                    !isExternalStorageRemovable() ? getExternalCacheDir(context).getPath() :
                            context.getCacheDir().getPath();

    return new File(cachePath + File.separator + uniqueName);
}

메모리 캐시에서의 로딩은 메인 쓰레드에서 진행된 반면 디스크 캐시는 백그라운드 로딩을 사용하였다. 디스크 작업은 언제 끝날지 모르므로 백그라운드를 사용하자. 그리고 이미지 프로세싱이 끝나면 메모리 캐시에도 업데이트를 해주었다.

=======================================================

이상입니다.  나머지 부분은 위에서 만든 코드를 실제 GridView나 ViewPager에 적용하는 내용인데 이건 직접 해보시면 될 것 같습니다. 사실 이 부분은 많이 쓰이는 부분이기 때문에 구글에서 검색하면 수많은 오픈소스를 만나실 수 있습니다.

오픈소스를 사용하셔도 되지만 위의 샘플코드를 가져다가 쓰는게 그렇게 어렵지 않고 또 이미 이해한 코드이기 때문에  커스터마이즈 하기도 좀더 수월하지 않을까 싶습니다. 또 위의 내용을 읽다보면 안드로이드가 이미지(비트맵)을 다루는 다양한 방식과 한계에 대해서도 이해하게 되는 부분이 있으리라고 생각합니다. 도움이 되셨길 바랍니다.

신고


Posted by injunech
2015.09.13 00:41


[Intro]

 

Android에서 사용하는 이미지는 Bitmap이라는 클래스에서 다~ 알아서 해줍니다.
그리고 이런 Bitmap Object를 쉽게 만들 수 있도록 도와주는 
BitmapFactory 클래스 라는 것도 있습니다.

 

BitmapFactory는 여러가지 소스로 부터 Bitmap Object를 만들어 주는 일을 하는데,
전부 static이며 decodeXXX 라는 이름을 가진 메소드들로 이루어져 있습니다.

XXX에는 어떤 것으로 부터 decode를 하여 
Bitmap Object를 만들어 낼지에 대한 말들이 들어 가겠죠.

 


[Decoding Methods]

 

BitmapFactory.decodeByteArray() 메소드는 Camera.PictureCallback 으로 부터 받은
Jpeg 사진 데이터를 가지고 Bitmap으로 만들어 줄 때 많이 사용 합니다.
Camera.PictureCallback에서 들어오는 데이터가 byte[] 형식이기 때문에
저 메소드를 사용 해야 하는 것이죠.

 

BitmapFactory.decodeFile() 메소드는 파일을 그대로 읽어 옵니다.
내부적으로는 파일 경로를 가지고 FileInputStream을 만들어서 decodeStream을 합니다.
그냥 파일 경로만 쓰면 다 해주는게 편리 한 것이죠.

 

BitmapFactory.decodeResource() 메소드는 Resource로 부터 Bitmap을 만들어 내며
BitmapFactory.decodeStream() 메소드는 InputStream으로 부터 Bitmap을 만들어 냅니다.
뭐 그냥 이름만 봐도 알 수 있는 것들이지요.

 


[OutOfMemoryError??]

 

보통 이미지 파일을 읽어서 Resizing을 해야 할 때가 있는데, 
그럴때는 BitmapFactory로 읽어서 Bitmap.createScaledBitmap() 메소드를 사용하여 줄이면

간단하게 처리 할 수 있습니다.

 

그런데 BitmapFactory를 사용할 때 주의해야 할 점이 있습니다.
아래의 예를 한번 보시죠.

Bitmap src = BitmapFactory.decodeFile("/sdcard/image.jpg");
Bitmap resized = Bitmap.createScaledBitmap(src, dstWidth, dstHeight, true);

이미지 파일로부터 Bitmap을 만든 다음에

다시 dstWidth, dstHeight 만큼 줄여서 resized 라는 Bitmap을 만들어 냈습니다.
보통이라면 저렇게 하는게 맞습니다.

 

읽어서, 줄인다.

 

그런데 만약 이미지 파일의 크기가 아주 크다면 어떻게 될까요?
지금 Dev Phone에서 카메라로 촬영하면
기본적으로 2048 x 1536 크기의 Jpeg 이미지가 촬영된 데이터로 넘어옵니다.
이것을 decode 하려면 3MB 정도의 메모리가 필요 할 텐데,

과연 어떤 모바일 디바이스에서 얼마나 처리 할 수 있을까요?

 

실제로 촬영된 Jpeg 이미지를 여러번 decoding 하다보면

아래와 같은 황당한 메세지를 발견 할 수 있습니다.

java.lang.OutOfMemoryError: bitmap size exceeds VM budget

네... OutOfMemory 입니다.
더 이상 무슨 말이 필요 하겠습니까...
메모리가 딸려서 처리를 제대로 못합니다.

 

이것이 실제로 decoding 후 메모리 해제가 제대로 되지 않아서 그런 것인지, 
하더라도 어디서 Leak이 발생 하는지에 대한 정확한 원인은 알 수 없습니다.
이것은 엔지니어들이 해결해야 할 문제 겠죠...

 

하지만 메모리 에러를 피할 수 있는 방법이 있습니다.

 


[BitmapFactory.Options.inSampleSize]

 

BitmapFactory.decodeXXX 시리즈는 똑같은 메소드가 두 개씩 오버로딩 되어 있습니다.
같은 이름이지만 Signature가 다른 메소드의 차이점은
BitmapFactory.Options를 파라메터로 받느냐 안받느냐의 차이죠.

BitmapFactory.Options를 사용하게 되면 decode 할 때 여러가지 옵션을 줄 수 있습니다.


여러가지 많지만 저희가 지금 사용할 것은 inSampleSize 옵션 입니다.

 

inSampleSize 옵션은,
애초에 decode를 할 때 얼마만큼 줄여서 decoding을 할 지 정하는 옵션 입니다.

 

inSampleSize 옵션은 1보다 작은 값일때는 무조건 1로 세팅이 되며,
1보다 큰 값, N일때는 1/N 만큼 이미지를 줄여서 decoding 하게 됩니다.
즉 inSampleSize가 4라면 1/4 만큼 이미지를 줄여서 decoding 해서 Bitmap으로 만들게 되는 것이죠.

 

2의 지수만큼 비례할 때 가장 빠르다고 합니다.
2, 4, 8, 16... 정도 되겠죠?

 

그래서 만약 내가 줄이고자 하는 이미지가 1/4보다는 작고 1/8보다는 클 때,
inSampleSize 옵션에 4를 주어서 decoding 한 다음에,

Bitmap.createScaledBitmap() 메소드를 사용하여 한번 더 줄이면 됩니다.

BitmapFactory.Options options = new BitmapFactory.Options();
options.inSampleSize = 4;
Bitmap src = BitmapFactory.decodeFile("/sdcard/image.jpg", options);
Bitmap resized = Bitmap.createScaledBitmap(src, dstWidth, dstHeight, true);

당연한 이야기 이겠지만,
내가 원하고자 하는 사이즈가 딱 1/4 크기라면

Bitmap.createScaledBitmap() 메소드를 쓸 필요가 없지요.

 

inSampleSize 옵션을 잘 활용하면 메모리 부족 현상을 대략적으로 해소 할 수 있습니다.
참고로 제가 저 옵션을 사용한 뒤로는 메모리 에러를 본적이 한~번도 없답니다.

 


[Appendix]

 

inSampleSize 옵션을 사용하면

SkScaledBitmapSampler Object (Library Level) 를 생성 하게 되는데,
Object를 만들때 정해진 SampleSize 만큼 축소하여 width와 height를 정한 뒤에 만들게 됩니다.
그러니까 애초에 축소된 사이즈로 이미지를 decoding 하는 것이죠.

 


[Outro]

 

Android의 기본 어플리케이션 소스를 분석 하다보면
상당히 테크니컬한 기법들을 많이 얻을 수 있습니다.
어떻게 이런 방법으로 만들었나 싶을 정도로 매우 정교하고 복잡하게 만들어져 있지요.
참 대단한 것 같습니다.





출처 - http://blog.naver.com/visualc98

신고


Posted by injunech

티스토리 툴바