ReStart 프로그래밍

1.스마트폰 해상도 정리

1.1.         해상도 개요도

1.2 해상도 및 크기 사례

주1) 밀도는 (dpi : dot per inch, density per inch,  ppi : pixel per inch)

가로, 세로 1인치 내의 점의 갯수를 말한다.

주2) 갤럭시 탭 AVD 생성 시

 - 스킨 사이즈 : 600*1024

 - density를 240으로 설정

    - 버튼이 안 보이므로.. 단축키 사용

2. 스마트폰 해상도 주의사항

2.1 가로/세로 값 

this.getWindowManager().getDefaultDisplay().getWidth();

this.getWindowManager().getDefaultDisplay().getHeight();

context.getResources().getDisplayMetrics().widthPixels
context.getResources().getDisplayMetrics().heightPixels

context.getResources().getDisplayMetrics.density

2.2 주의 사항

가. 3요소가 일치해야 한다

<uses-sdk android:minSdkVersion="8" />... .

프로젝트 만들때 Build target설정에서 Platform 2.2버젼...

스마트폰의 안드로이드 OS 버젼(2.2)...

나. 스마트폰이나 에뮬의 버젼이 제일 최신버젼이어야 한다

스마트폰의 안드로이드 OS 버젼을

최대기준으로 볼 때 uses-sdk와 Build target이 적거나 같아야 한다.

다. 결론

일반적으로 대부분의 스마트폰 해상도는 480*800아나, 위의 두 가지 조건이 맞지 않으면 320*533으로 나올 것이다. 예를 들어 스마트폰은 2.2버젼인데 새로나온 2.3버젼인 9API로 프로젝트를 만들면 해상도는 320*533으로 나올 것이다.

2.3 해상도 테스트

1)    AndroidManifet 상에

<supports-screens android:largeScreens = ”true” android:normalScreens = ”true”

android:smallScreens = ”true” android:anyDensity = ”true”/>

2)    글자의 크기는 XML상에 px가 아닌 sp로 할 것.

3)    Widget의 크기 및 padding은 dip로 사용할 것.

4)    Layout은 LinearLayout 이나 RelativeLayout 등을 사용할 것

5)    안드로이드 에뮬레이트 안의 AVD manager를 Add해서 해상도를 여러 개 적용하여 테스트하면 도움이 될 것임.

참조) http://www.kandroid.org/guide/practices/screens_support.html#range

3.첨부

첨부1) 표준 디스플레이 해상도는 다음을 포함한다 (wikipedia자료)

• QVGA 0.077 메가픽셀 = 320×240
• VGA 0.3 메가픽셀 = 640×480
• SVGA 0.5 메가픽셀 = 800×600
• XGA 0.8 메가픽셀 = 1024×768 (XVGA라고 함)
• WXGA 1.0 메가픽셀 = 1280×800
• SXGA 1.3 메가픽셀 = 1280×1024
• WXGA+ 1.3 메가픽셀 = 1440×900
• SXGA+ 1.4 메가픽셀 = 1400×1050
• WSXGA+1.7 메가픽셀 = 1680×1050
• UXGA 1.9 메가픽셀 = 1600×1200
• WUXGA 2.3 메가픽셀 = 1920×1200
• QXGA 3.1 메가픽셀 = 2048×1536
• WQXGA 4.1 메가픽셀 = 2560×1600
• QSXGA 5.2 메가픽셀 = 2560×2048
• WQSXGA 6.6 메가픽셀 = 3200×2048
• QUXGA 7.7 메가픽셀 = 3200×2400
• WQUXGA 9.2 메가픽셀 = 3840×2400
• WUQSXGA 11.3 메가픽셀 = 4200×2690

그림1) http://en.wikipedia.org/wiki/Graphic_display_resolutions

첨부2) 국내 출시된 안도로이드 목록

 펌) http://blog.daum.net/miriya/15601204

그동안 변한 점을 꼽자면, 모토로라의 방수 스마트폰인 Defy가 나왔고, HTC의 대화면 스마트폰인 디자이어 HD가 출시되었으며, KT Tech가 테이크를 출시했습니다. 그 뒤로는 LG가 새 기함인 옵티머스 2x와 옵티머스 마하를 준비하고 있고, Dell의 스트릭과 베뉴가 KT를 통해 나올 예정입니다. 펜텍의 베가는 AMOLED 수급 문제로 인해 단종되었고, 대신에 베가 Xpress라는 모델이 LCD 액정을 달고 KT와 LG U+로 나올 예정입니다. 소니에릭슨에선 X10 mini에 키보드만 달린 pro 버전이 출시 예정이구요, 옵티머스 시크라고 옵티머스원 마이너 업데이트 버전이 저가형으로 나오네요.

역시나 이번에도 해상도의 절대 다수는 480x800이고, 일부 외산폰이 480x854로, 저가형 기종은 320x480 해상도로 나오고 있습니다. 어플리케이션을 개발할때 염두해야 할 기종은 요 두가지 정도가 되겠네요. 이 두가지 해상도가 마켓상의 절대 다수를 점하고 있습니다. 95% 이상. 달리 말하면 240x320 해상도 사용하는 몇몇 기종 샀다간 큰일난다는 말이 됩니다. 어플리케이션들이 거의 호환되지 않을테니까요. 기왕이면 240x320 해상도의 기종은 그만좀 나왔으면 합니다.. 그리고 거기 더해 앞으로 우르르 쏟아져나올 안드로이드 태블릿을 위해 1024x600 해상도도 염두해야겠습니다. 이번 2.3 진저브레드부터는 이런 대화면 해상도를 위해 extra large screen이 추가되었고, 레티나 디스플레이 같은 초고밀도 액정을 위해 extra high density 항목이 추가되었으니 참조하시구요. 표에는 대각선 px의 수와 그에 따른 ppi, 해당되는 안드로이드 OS의 dpi 항목도 적어놨습니다.

그 외에 중요한 부분은 역시 OS 버전이죠. 2.2 버전으로 출시되었거나, 2.2 버전으로 업데이트가 완료된 폰은 노란 바탕에 검정 글씨로 확 눈에 띄게 강조했습니다. 모토로이 등 이번달 내로 업데이트 될 것이 확실한 기종은 파란 글씨로, 내년 이후에나 업데이트 될 예정인 애들은 회색 글씨로 적어놨습니다. 재미있게도 삼성과 HTC, 팬텍이 가장 빠릿하게 업데이트를 해주고 있고, 최근에 일정이 연기된 LG는 그 다음, 모토로라가 좀 늦고.. 소니 에릭슨이 제일 심각하네요. X10의 2.1 업데이트가 근래에 있었으니 2.2는 언제나 될지 참 묘연하기만 합니다. 모토로라의 경우 모토믹스를 출시하면서 2.1로 끝낸다고 딱 못을 박아버리는군요. 왜 출시했는지 모르겠습니다. 사면 바로 버려진다는 뜻이죠. 공짜폰의 운명..

해상도별로 테스트폰을 구입하게 된다면, hdpi용으로 국내에서 가장 많이 팔리고 있는 갤럭시S, 그리고 mdpi용으로 저가형 옵티머스원이면 딱 좋겠군요. 그 외에 돈 더 된다면 TFT LCD로 나온 옵티머스 2x가 좋겠네요. 듀얼코어 테그라2 달고 나왔고 하니 성능도 굉장하고.. 갤럭시S가 워낙에 변태같이 만들어졌다보니 대조구로 넥서스원을 두면 좋겠군요. 240x320은 고려하지 않는게 좋을것 같습니다.

길 찾기 알고리즘, A* 알고리즘, A Star라고 발음한다. 상당히 오래 전에 만들어진 알고리즘이다. 게임 제작에서 가장 기본적으로 가르치는 방법이라서 외국 글을 읽어 단순히 번역하지 않고 다시 정리해서 올린다. 유사한 방법에 Dijkstra[다익스트라]라는 사람이 만든 방법이 있다고 한다. 발음법이 특이한 것은 네덜란드 사람이라서 그렇다. 약간 독일어를 닮은 언어다. 아마 A*의 원형일 것이다. 컴퓨터 공학과에선 가르치는 것 같다. 우린 모르지만...

 <그림 : 기본 개념>

먼저 알아야 할 것부터 정리하면 이렇다. 컴퓨터는 봉사에 귀머거리다. 그래서 화면 전체를 볼 수 없다. 비유를 하면 봉사 슈퍼 개미가 빛의 속도로 화면을 돌아다니며 더듬어서 길을 찾는 것이다. 일을 간단하게 만들기 위해서 지도를 바둑판 형태로 나눈다. 이것을 격자(Grid)라고 부른다. 그래서 하나의 사각형, 육각형, 삼각형 안에서 다른 것 안으로 이동하거나 또는 바둑판처럼 하나의 교차점에서 다른 교차점으로 이동하는 형태로 생각한다. 사각형, 육각형, 삼각형은 평면을 알뜰하게 나누어 사용할 수 있는 도형이다. 주로 사각형을 많이 쓰지만 뭐를 써도 가능하다. 그렇게 구역을 나누고 각 구역은 뭔가 기억할 수 있는 능력이 있다고 하자! 즉, 각 바둑판 사각형이나 십자 교차점은 컴퓨터에서 말하는 2차원 배열이 된다. 다시 말하면 길을 찾기 위해 지도에 뭔가 표시할 수 있도록 하는 것이다! 여하튼 움직임은 연속적이지 않고 계단식으로 간격을 두고 움직인다! 그리고 그 지점에 뭔가 표시를 한다. 이런 것을 Node[노우드](마디)라고 부른다. 이 말은 원래 나무 형태의 구조에서 가지가 갈라지는 부분을 부르는 말이다. 이런 이름이 붙은 이유는 바둑판에 표시한 길을 보면 마치 나무 가지 형태를 하게 되기 때문이다. 보통 Node가 나오면 List가 따라 나온다. Linked List(연결 목록)이란 것은 배열이다. 그런데 서로 누가 먼저 누가 나중인지 연결된 정보를 가지고 있다. 그래서 순서를 자유롭게 바꾸고, 삽입과 삭제가 쉽다. 지도에 표시하는 대신 이 Linked List를 사용하여 길을 기억하는데 이 연결 상태를 그려보면 나무(Tree) 모양이 된다. 그래서 Node라고 부른다.(^^) 우리의 봉사 슈퍼 개미는 바로 옆의 8개 점만 검사할 수 있다. 그래서 8방향 탐색이다!(^^) 이 8방향에서 또 각자 다음 주변 8방향으로 물결처럼 퍼져나간다. 그런데 이렇게 무조건 8방향으로 퍼져나가면 좀 문제가 있다. 하나만 선택해서 계속 깊게 나가야 한다. 우린 넓이 우선 탐색을 하는 것이 아니라 깊이 우선 탐색을 하는 것이다. A 스타는 깊이 우선 탐색 + 넓이 우선 탐색이다. 처음엔 계속 가능성이 높은 것 하나를 선택해서 깊게 나간다. 그러다 막히면 나머지 가능성 중에서 하나를 선택해서 넓게 나간다. 그 가능성 높은 방향을 선택하는 방법이 바로 A 스타 알고리즘이다.

 <그림 : 유사 방법>

<그림 : 진짜 방법>

A*란 8방향을 탐색해야 하며 8방향 중에 어느 하나를 선택하는 방법으로 이미 왔던 거리와 목표까지 예상 거리의 합을 사용해야 하는 것이다. 그렇지 않다면 A*라고 부르기 어렵다. 이 가장 기본적이고 가장 실용적이게 보이는 방법도 문제가 많다.(^^) 아주 긴 장벽을 넘는 것이 어렵게 보인다. 또한 호랑이 입이나 항아리 구조 같은 지형에서도 시간 소모가 많다. 가장 짧은 거리를 선택한다는 것은 말 그대로 Sorting을 한다는 것이고 그러면 시간이 많이 소모된다. 또한 검토할 지점과 이미 검토한 지점을 목록(Linked List)에 잘 저장해서 찾아야 한다. 다만 책에 이름이 자주 거론되니 궁금해서 공부했을 따름이다. 좀 더 간단하고 효과적인 방법이 있다. 이쪽에서 저쪽으로 가는 길을 찾는 것은 복잡하지만 반대로 저쪽에서 이쪽으로 오는 길을 찾는 것은 쉬울 수 있다. 항상 반대로 생각해 봐야 한다. 그래서 양방향 탐색을 한다. 또한 우리가 산 속에서 또는 사막에서 또는 초원에서 또는 바다에서 길을 잃었다고 하자! 그럼 제일 먼저 찾는 것이 뭔가? 산 속에선 계곡의 물줄기다. 따라가면 큰 강이 나온다. 사막이나 초원에선 강을 찾거나 산맥을 찾아야 한다. 바다에선 육지를 찾아야 한다. 모두 경계라는 특징이 있다. 마찬가지로 갈 수 있는 길과 갈 수 없는 장애물 사이의 경계가 바로 따라가야 할 길이다. 장애물이 없다면 무조건 목표 방향을 향해 직진하는 것이 빠르다. 실제 게임에서 Unit들의 움직임을 보면 장애물을 만나기 전까지는 일직선으로 이동한다. 장애물을 만나면 벽을 따라 이동하는 것을 알 수 있다. 물론 이 길을 찾는 방법을 개발해야 하지만 별로 어렵지 않다. 아래 그림을 봐라!

<그림 : 기타 방법>

A*와 유사한 결과를 내지만 더 간단하다. 이 방법은 내가 고민하다가 기억해 낸 것이다. 인터넷에 찾아 보면 우선법/좌선법(우수법/좌수법!? 뭐라고 하든 무슨 상관이냐?)이라는 벽 타기 기법이 유사하다는 것을 느낄 것이다. 미로에서 오른 손이나 왼 손을 벽에 붙이고 계속 가면 출구가 나온다는 그런 이야기다. 이 방법은 계속 벽에 붙어 있기 때문에 벽에서 떨어지는 상황에 대응한 위의 방법과는 다르다. 어느 경험 많은 프로그래머에게서 오래 전에 들은 이야기다. 당시 게임 제작에 대한 막연한 호기심으로 질문을 했었다. 그 사람들 경험으로는 게임 제작은 엄청 골치 아픈 분야라고 한다. 컴퓨터를 생각하도록 만드는 작업은 정말 어렵다. 이런 길 찾기는 아주 쉬운 편에 속한다고 한다. 한 참 후에 세월이 흘러 직접 게임 제작에 관한 글을 쓰다가 궁리 끝에 뭔가 아이디어가 떠올랐는데 알고 보니 옛날에 누군가에게 들은 것이었다.(^^) 진짜 실력이 있는 프로 게임 제작자들은 이미 답을 알고 있었다! 컴퓨터 공학과나 수학과에서 다루는 분야이니까! 컴퓨터는 컴퓨팅(계산)하는 장치이니 수학과와 친하다. 우리 아마추어만 모르고 있었다! 내가 게임 업체의 비밀 알고리즘을 하나 듣게 된 것이었다. 어디 가서 말하지 말라고 했지만 내가 게임 제작자가 될 수도 없는 입장에서 세월은 흘러 이미 늙어 버렸으니 내겐 더 이상 감출 비밀이 아닌 것 같다! 어린 학생들 좋은 꿈 꾸라고 이렇게 글을 올린다. 한국 게임 업체의 비밀은 외국 게임 업체에 비하면 비밀도 아니니까!(^^) 게임 분야는 너무 경쟁이 심하다. 장래 희망이라면 잘 고려해 보길 바란다!

Allman 식 이클립스 Java 코딩 스타일 프로파일

어떤 자바 코딩 스타일을 쓰시고 계신가요?

특별히 선호하는 스타일이 없으시다면 아마도 자바 코딩 규약을 따르시겠죠?

코딩 스타일이라고 하면 여러 가지가 고려할 것들이 있습니다. 들여쓰기를 어떻게 하는지, 블럭 지정은 어떻게 하는지, 언제 줄을 나눌 것인지, 띄어쓰기, 코멘트, 배열 초기화, 심지어 이름 정하는 규칙까지......

이런 여러 요소가 있지만 보통 코딩 스타일을 분류할 때에는 들여쓰기와 블럭 표현 방법을 주로 봅니다. 아마도 이 두 가지가 코딩 스타일의 외형에 가장 큰 영향을 주기 때문인 듯합니다. 몇몇 대표적인 블럭 표현 방법에는 따로 부르는 이름까지 붙어 있지요.

제가 프로그래밍을 배우기 시작할 때에는 베이식, 어셈블리, 포트란, 코볼 같은 언어들을 주로 사용했기 때문에 요즘과는 다른 코딩 스타일을 썼었습니다. 언어 구조가 좀 다르니까요. 제가 배운 베이식은 서브루틴 같은 것도 없었거든요. ^^

처음으로 배운 구조적 언어는 Pascal입니다. Apple II에서 돌아가는 UCSD Pascal이 있었는데 p-System이라는 가상 머쉰 위에서 p Code라는 중간 코드로 컴파일 되는 언어입니다. 지금 우리가 쓰는 자바 가상 머쉰과 비슷한 놈이었죠. 좀 다른 것은 JVM은 OS 위에서 돌아갔지만 p-System은 OS까지 포함하고 있습니다. 그다음에는 CP/M이라는 OS에서 Turbo Pascal로 프로그래밍을 했었고요.

좌우간 이런 이유로 Pascal처럼 블럭의 시작과 끝이 명시적인 Allman 스타일의 블럭 표현 방법을 선호하게 되었나 봅니다. K&R 스타일은 블럭의 시작 기호와 끝 기호를 신경 써서 주목하지 않으면 찾기가 힘들더라고요. 물론 요즘은 IDE를 쓰기 때문에 자동으로 찾아주기는 하지만 최근까지 VI로 개발했었기 때문에 이 스타일이 아니면 코드를 전혀 보지 못하는 지경입니다.

대표 Indent Style

말을 시작했으니 대표적인 코딩 스타일을 몇 가지 적어볼까요? 마침 위키 백과에 잘 정리가 되어 있군요.

K&R 방식

for (int i = 0; i < 10; i++) {
    s = s + i;
    if (s > 10) {
         ......
    } else {
         ......
}

자바 코딩 규약에서 사용하는 방식입니다. 우리나라에서는 이것이 가장 일반적인 듯합니다. C를 만든 커닝핸과 리치씨의 "The C Programming language"라는 책에 사용된 코딩 스타일이지요. 이 책 한 권씩 안 사본 사람이 없을 듯한데 요즘은 모르겠군요. 제가 처음으로 산 원서 같기도 하고...... 들여쓰기는 원래 8칸이지만 요즘은 4칸을 주로 씁니다.

이것의 변형으로 BSD KNF Style이 있다네요. 보통 kernel style이라고 부르는 놈입니다. 저는 이것과 K&R이 같은 것인 줄 알았는테 텝이 조금 다르군요. 하드 탭(탭문자)는 8칸으로 보이게 설정하고 소프트 탭(어이지는 공백 여러개로 탭을 표현)은 공백 4개로 설정합니다. 밑에 제 스크린샷 중 첫번째에서 Tab Policy를 Mixed로 하고 Use tabs only for leading indentations를 체크한 후에 블럭 들여쓰기 할 때에 tab을 두번 치면 비슷해질 듯 하네요.

이렇게 탭을 설정하고는 블럭을 들여쓸 때에는 하드탭으로 이어지는 줄을 들여쓸 때에는 소프트탭으로 처리한다고 합니다.

Allman 방식

for (int i = 0; i < 10; i++)
{
    s = s + i;
    if (s > 10)
    {
         ......
    }
    else
    {
         ......
    }
}

Sendmail과 많은 BSD 유틸리티들을 만든 Eric Allman의 코딩 스타일입니다. BSD Style이라고도 불렀었습니다. 원래는 들여쓰기를 공백 8칸으로 하는데 요즘은 4칸으로 합니다.

보시면 알겠지만 블럭의 시작과 끝이 명확합니다. 가독성이 높지요. 코드 한 줄씩 정확히 볼 수 있습니다. 단 한 화면에 보이는 코드 양이 많지 않아서 스크롤을 더 해야 하는 단점도 있습니다. 그래서 Cut & Paste 방식의 프로그래밍을 방해해서 저는 좋은데 다른 분들은 모르겠군요.

C에서는 가장 많이 사용하는 방식이라고 합니다.

Whitesmith 방식

for (int i = 0; i < 10; i++)
    {
    s = s + i;
    if (s > 10)
        {
         ......
        }
    else
        {
         ......
        }
    }


Whitesmith C라고 한참 잘 팔리던 C 컴파일러의 코딩 방식입니다. 저는 이 방식으로 코딩하는 사람을 한 번도 못 봤지만 Whitesmith C로 장난질을할 때에 잠깐 접해 보기는 했습니다. 어떻게 보이시나요? Allman 방식에 눈이 익어서 처음에는 적응하기 어렵지만 금방 적응이 되더군요.
이 방식 역시 원래 8칸이었지만 요즘은 4칸을 씁니다.
Allman 방식과 거의 비슷한 수준으로 많이 쓴다고 합니다.

GNU 방식

for (int i = 0; i < 10; i++)
  {
    s = s + i;
    if (s > 10)
      {
         ......
      }
    else
      {
         ......
      }
 }

GNU에서 사용하는 방식입니다. 아마도 리처드 스톨만의 방식이겠죠? Allman과 Whitesmith의 중간형으로 보입니다. 나름의 이유가 분명히 있겠지만 솔직히 전 이 방식을 별로 좋아하지 않습니다.  이렇게 작은 들여쓰기가 반복되면 가독성이 떨어지더군요. 눈이 어지럽습니다. 보통 2칸씩 두 번 들여씁니다.

위키 백과에는 pico 방식과 banner 방식도 설명하고 있는데 이것들은 그렇게 많이 쓰이지 않으므로 넘어가겠습니다.

이클립스 자바 코드 스타일 프로파일

좌우간 제가 이 글을 쓴 이유는 이런 방식 중에 제가 쓰는 allman 방식의 이클립스용 코딩 스타일 프로파일을 공개(?)하려는 것입니다.
혹시 allman 방식을 좋아하시는 분이 있다면 받아서 쓰세요. 제가 쓰던 것을 약간 손 봐서 올립니다.

allman.zip

이 파일을 내려 받아 압축을 푼 후에 이클립스의 자바 코드 스타일 프로파일로 등록 하십시오.

Window > Preferences > Java > Code Style > Formatter 에서 Import 하시면 됩니다.

설정 내용

간단히 설정 화면 갈무리한 것을 올려보겠습니다.

들여쓰기

들여쓰기는 공백 4칸입니다. 탭을 4칸으로 표시되도록 하는 방식은 다른 에디터에서 보면 다르게 보이기 때문에 탭은 8칸으로 보이게 했습니다.
저는 에디터를 고를 때에 들여쓰기를 탭 문자가 아닌 공백으로 처리할 수 있는지를 꼭 확인합니다.

대괄호

이 부분에서 Allman 방식의 대표 특징을 부여합니다.

빈 줄 삽입

널찍널찍한 코드가 가독성이 좋지요. ^^
가독성이 떨어지면 코드를 통제하기 힘들어지고 버그도 많이 생깁니다. cut & paste 해 놓고 "잘 돌아가던 코드인데 왜 안 돌아가지?" 하는 사람 많이 봤지요. 프로그래머는 코드 한 줄에 책임을 져야 하는 거라고 생각합니다. "네가 만들어 놓은 코드를 가져다 썼는데 작동 안 되니 네가 책임져"라고 말하는 프로그래머 보면 참 답답합니다. 자기가 제다이인 줄 알고 감으로 프로그래밍하죠.

줄 나누기

자바 코딩 규약과 비슷합니다. (아마도... ㅡ.ㅡ);

제어 코드

이 부분도 기본은 널찍널찍...

긴 줄 나누기

80칸에 맞춰서 긴 줄을 나누게 설정했습니다. 요즘은 화면이 넓으니 화면 가득한 크기로 에디터를 키우고 프로그래밍하는 사람들이 많습니다. 요즘 같은 시대에 누가 터미널을 쓴다고 80칸에 맞추느냐고 말하는 분들 많지요. 자바 코딩 규약에 쓰여 있는 것처럼 다양한 환경에서도 같은 모습을 유지하려면 80 칸에 맞추는 관례를 지키는 것이 좋기는 하지요.
저는 조금 다른 이유로 여전히 80칸에 맞춰서 코딩합니다. 가로로 길게 늘여 놓으면 눈에 잘 안 들어오기 때문입니다. 눈알을 이리저리 계속 굴려야 하거든요. 제가 노안이라서 그런가요? :-)
한번 해보세요. 진짜 코드에 대한 장악력이 높아집니다. 제 생각에 80칸 규칙을 에디터가 제한하도록 설정하는 것은 별로 좋은 것 같지는 않습니다. 어떤 줄은 이름이 너무 길다거나 해서 80칸을 넘는 것이 오히려 나을 수도 있으니까요. 그냥 기준선만 표시하고 프로그래머가 그런 습관을 지키도록 하는 것이 좋다고 생각되는데 일단 이 프로파일에서는 강제로 줄 나누기 하도록 했습니다.

주석 처리

이 부분은 그냥 제가 좋은 쪽으로 했는데 뭘 고쳤는지 모르겠네요.  ㅡ.ㅡ;

따~라 라~라 랄랄랄라 랄랄랄라~
따라라 라~라~ 라~
[출처] http://gyumee.egloos.com/1306012

이클립스 속도 향상 (eclipse.ini 수정)

최근 이클립스가 버벅대서 오랜만에 이클립스 속도 향상 정보를 정리해본다.

eclipse.ini 수정

  1) Before

-startup

plugins/org.eclipse.equinox.launcher_1.1.0.v20100507.jar

--launcher.library

plugins/org.eclipse.equinox.launcher.win32.win32.x86_1.1.1.R36x_v20100810

-product

org.eclipse.epp.package.jee.product

--launcher.defaultAction

openFile

--launcher.XXMaxPermSize

256M

-showsplash

org.eclipse.platform

--launcher.XXMaxPermSize

256m

--launcher.defaultAction

openFile

-vmargs

-Dosgi.requiredJavaVersion=1.5

-Xms40m

-Xmx512m

  2) After

-vmargs

-Dosgi.requiredJavaVersion=1.6

-Xverify:none

-XX:+UseParallelGC

-XX:-UseConcMarkSweepGC

-XX:+AggressiveOpts

-XX:PermSize=128M

-XX:MaxPermSize=128M

-XX:MaxNewSize=128M

-XX:NewSize=128M

-Xms512m

-Xmx512m