GCC (GNU Compiler Collection)는 다양한 프로그램 언어의 컴파일을 지원하는 컴파일러 시스템이며, 특히 C와 C++의 컴파일에 활용될 수 있습니다. 리눅스나 FreeBSD 등의 유닉스 계열 OS에서 매우 광범위하게 사용되어 오면서 뛰어난 성능을 검증받았습니다.

윈도의 경우, cygwin과 MinGW가 윈도로 포팅된 gcc의 양대산맥이라고 할 수 있는데, 둘의 성격은 꽤 다른 편입니다. cygwin의 경우 윈도에서 리눅스 환경을 느끼면서 코딩할 수 있도록 배려한 라이브러리가 포함되어 있으며, 주로 유닉스 계열에서 쓰이는 POSIX API 집합을 지원합니다. 따라서 cygwin으로 컴파일된 프로그램을 실행하기 위해서는 별도의 라이브러리(cygwin1.dll)가 필요합니다. (cygwin이 GPL 라이센스를 따르므로 라이브러리 사용시 일부 라이센스 문제가 있을 수 있습니다.)

한편 MinGW의 경우 MS에서 제공하는 C 런타임 라이브러리(msvcrt)를 기반으로 동작합니다. 따라서 cygwin과 달리 런타임 라이브러리는 필요하지 않으나, msvcrt가 C99의 기능들을 지원하지 않는 관계로 libmingwex라는 추가 라이브러리를 통해 해당 부분에 대한 지원을 시도하는 중입니다. (출처) 해당 문제점은 MinGW에서 갈라져 나온 새로운 가지인 MinGW-w64에서 해결되었는데, C99의 기능 뿐만 아니라 더 다양한 API, 64비트 윈도우 등에 대한 지원이 추가되었으며, 32비트용 컴파일 또한 지원합니다.

결론적으로, 기존에 리눅스 환경에서 실행되던 프로그램을 윈도로 포팅하는 경우에는 cygwin을 사용하고, 일반적인 윈도용 어플리케이션을 개발하기 위한 범용 컴파일러는 MinGW-w64를 사용하는 것이 좋을것 같습니다.

http://jscript.blog.me/220084163392 펌

MinGW은 이클립스 플러그인으로도 제공됩니다.

MinGW에 간단 사용기 : http://neuro.tistory.com/32

컴퓨터 공학 전공으로 졸업하고, 어언 6년이 지났건만.. 
아직 기초가 부족한 부분이 많은 것 같습니다.

학부 때는 단순히 윈도우 환경에서 Visual Studio나 Eclipse 프로그램을 사용하여
자연스런 컴파일 환경을 통해 프로그래밍 언어를 습득하기에만 정신이 없었고...

모바일 폰 개발 회사에서 재직하는 동안에도 선배들이 만들어놓은 개발 환경을 그대로 이용만 하여,
프로그래밍을 해왔기에..  개발 환경에 대해 제대로 개념을 익히는 시간이 거의 없었습니다..

학부 때 잠시나마 배웠던, 컴파일에 대한 개념도 가물가물 해졌습니다. ㅜㅜ (밑에 간단 정리..)

c언어 코딩 부터 실행파일까지의 기본 순서 : *.c -> *.s -> *.o -> *.exe or *.elf 등등

*compiler : 고수준코드(*.c)에서 목적 코드(*.o)로 옮기는 과정을 통합하여 수행하는 프로그램을 가리킨다.

*좁은 의미의 compiler : 고수준 코드(*.c)를 저수준 코드 (*.s)로 옮기는 과정을 수행하는 프로그램.

*assembler : 저수준 코드(*.s)를 목적 코드 (*o)로 옮기는 작업을 수행하는 프로그램.

*linker : 컴파일러가 만든 목적 코드 (*.o)와 library를 모아 기계어인 실행파일 (*.elf or *.exe)로 변환하는 프로그램.

사실 SW 개발자 입장에서 개발 환경은 한 번 셋팅 해놓으면, 크게 신경을 쓰지 않기에 지나치기 쉬운 것 같습니다.

임베디드 SW를 만드는 업을 해왔지만, 주로 윗단을 (Application 단 + Framework 단) 다루다가,
최근에 아랫단를 (펌웨어) 개발해야 할 기회가 왔기에.. 다시금 개발환경에 대해 파악해보려 합니다.

모바일 폰에 사용되는 칩셋(CPU)의 Core는 ARM을 이용합니다.

그리고 펌웨어 개발 환경은 대부분 리눅스 커널 환경을 사용하기에 이에 대해 잠시 집고 가볼까 합니다.

잘 정리해 주신 블로거님이 계시기에 아래에 퍼왔습니다.

일단 결론을 말씀드리자면, 아래와 같습니다.

1. 리눅스 환경에서 개발 시에는 거기서 제공하는 tool chain을 다운로드하여 사용
   (apt-get 툴을 이용해 필요한 버전의 툴 체인 설치)
2. 윈도우 환경에서 개발 시에는 주로 Cygwin(gcc 제공)을 이용하게 됩니다.

** ARM 타깃용 크로스 툴 체인 --> http://linaro.org 참조

우리가 윈도우즈 환경에서 리눅스 ARM 용 프로그램을 빌드하기 위해서는, 그에 맞는 바이너리를 생성해 줄 수 있는 환경( 컴파일러, API 등 )을 구성할 필요가 있다. 윈도우즈에서 이를 가능하게 해 주는 것이 POSIX 기반의 시그윈 개발 환경이다. 
--> Cygwin 에서는 Windows에서 사용가능한 리눅스 환경의 API들을 제공하고,
     tool chain (ARM용 gcc 크로스 툴 체인, git 등)을 제공합니다.

우리는  시그윈 환경을 이용해 리눅스 ARM 용 프로그램을 빌드하고, 그것을 안드로이드 장치로 복사하고 설치하게 된다. 이것이 윈도우즈와 리눅스 간의  크로스 플래폼 개발이다. 안드로이드 SDK 를 사용하게 되면 자바 바이트 코드( 플래폼에 독립적인 중간 코드 )를 생성하기 때문에 빌드 환경이 중요하지 않지만, 안드로이드 NDK 는 실제 리눅스 API 를 이용하고 기계어로 컴파일하기 때문에 반드시 올바른 환경에서 개발해야만 한다.

좀 더 자세한 내용은 아래 펌 참고...

http://lifeisforu.tistory.com/132  (안드로이드 NDK 개발환경 예시)

NDK 로 개발을 한다는 것이 의미하는 바가 무엇인지 생각해 볼 필요가 있다. 많이들 알고 있는 사실이겠지만, 어떤 프로그램이 어떤 머신에서 실행되기 위해서는 해당 머신에 맞는 실행가능한 파일( executable )을 만들어야만 한다. 그것이 소위 우리가 알고 있는 '컴파일'과 '링크'라는 작업이다. 이 컴파일 작업과 링크 작업을 합쳐서 '빌드'라고 표현한다.

우리가 열심히 코딩한 라인들은 어셈블리어로 변환되고, 이 어셈블리어들은 다시 기계어로 변환된다. 그리고 CPU 는 이 기계어를 마이크로 명령어로 나누어서 프로그램을 실행하게 된다. 그런데 이 CPU 가 어떠한 명령어 집합 구조( Instruction Set Architecture, ISA )를 제공하느냐에 따라서 다른 기계어를 만들어야 하기 때문에, 프로그램을 빌드할 때는 해당 CPU 에 맞는 구성을 만들어야 한다. 예를 들어 CPU 가 x86 ISA 를 제공한다면 x86 에 맞는 빌드 구성을 해야 하고, CPU 가 x86/64 를 제공한다면 거기에 맞는 빌드 구성을 만들어야 한다.

자 우리가 NDK 를 통해 만든 바이너리를 실행할 플래폼의 환경은 어떠한가? 일반적으로 현재 안드로이드 OS 가 돌아 가는 환경은 ARM 코어를 사용하는 리눅스 환경이다. 이는 어떠한 사실을 내포할까?

• 우리가 C/C++ 응용프로그램을 개발할 때 CreateFile() 과 같은 Win32 API 를 사용할 수 없다.

• Visual Studio 를 이용할 수 없다. --> VC++ 컴파일러를 사용할 수 없다.

사실 Visual Studio 의 컴파일러를 GCC( GNU Compiler Collection ) C++ 컴파일러로 연결해 놓고 개발할 수는 있을 것이다. 하지만 기본 환경 자체가 Win32 서브시스템과 x86 혹은 x86-64 아키텍처를 위한 개발에 최적화되어 있으므로 참 어려운 일이 될 것이다. 구글링을 해 보면 여러 가지 자료들이 나오기는 하는데 얼마나 편한 지는 잘 모르겠다. 어쨌든 우리는 리눅스 OS 를 기반으로 ARM ISA 에 맞춰서 빌드해야만 하는 상황이고, 윈도우즈 환경에서 이를 가능하게 만들 수 있는 방법을 찾아야만 한다. 

이때 우리에게 한 줄기 빛을 비춰주는 존재가 있으니, 그것이 바로 시그윈이다.

Cygwin 이란 무엇인가?

일단 시그윈 공식 사이트의 설명을 인용해 보도록 하겠다. 출처 : http://cygwin.com/index.html

시그윈은 :

• 윈도우즈를 위해 리눅스처럼 느껴지는 환경을 제공하는 도구들의 집합이다.

• 많은 리눅스 API 기능을 제공하는 리눅스 API 레이어로서 동작하는 DLL( cygwin1.dll )이다.

그리고 다음과 같이 착각하지 말라고 경고하고 있다.

시그윈은  :

• 윈도우즈 상에서 네이티브 리눅스 앱들을 실행하는 방법이 아니다. 당신이 윈도우즈 상에서 프로그램을 실행하기 원한다면, 소스로부터 앱들을 리빌드해야만 한다.
• signal, pty 등과 같은 유닉스 기능들을 인지하는 네이티브 윈도우즈 앱들을 마술처럼 만들어 주는 방법이 아니다. 다시 말하지만, 당신이 시그윈 기능의 이점을 취하기 원한다면, 소스로부터 앱들을 리빌드할 필요가 있다.

앞에서도 언급했지만 특정 CPU 아키텍처에 대해 리눅스용으로 빌드된 프로그램은 윈도우즈에서 실행될 수 없다. 당연히 윈도우즈 환경에 맞는 구성으로 다시 빌드해야만 한다. 시그윈은 크로스 플래폼 개발을 가능하게 해주는 환경일 뿐이지, 에뮬레이터가 아니라는 것을 명심해야만 한다.

Cygwin 의 작동 원리.

그렇다면 시그윈은 어떻게 해서 리눅스와 같은 개발 환경을 지원하게 되는 것일까?

여러분은 Visual Sutdio 를 통해 프로젝트 설정을 하다가 '서브시스템' 이라는 항목을 본 적이 있을 것이다. 윈도우즈는 여러 개의 서브시스템을 가지고 있는데, 우리가 주로 사용하는 것이 Win32 서브시스템이다. 아래 그림은 Windows NT 의 시스템 아키텍처에서의 POSIX 서브시스템을 보여 주고 있다.

윈도우즈 NT 시스템 아키텍처( 출처 : 위키피디아 )

이 POSIX 라는 것은 Portable Operating System Interface 의 약자로 IEEE 가 운영체제 간의 호환성을 유지하기 위해서 제정한 표준이다.

POSIX( 대충 '파직스'라고 발음됨 )는 "Portable Operating System Interface" 의 머리글자들이며, 운영체제 간의 호환성을 유지하기 위해서 IEEE 에 의해 제정된 표준 패밀리이다. POSIX 는 다양한 유닉스 및 다른 운영 체제들 간의 소프트웨어 호환성을 위해 응용프로그램 인터페이스( API )와 명령줄 쉘, 그리고 유틸리티 인터페이스들을 정의한다.

중략...

유닉스 같은 운영 체제 환경을 위한 POSIX 명세는 원래 코어 프로그래밍 인터페이스를 위한 단일 문서로 구성되어 있었지만, 결국에는 19 개의 분리된 문서로 늘어 났다( 예를 들면 POSIX1, POSIX2, 등 ). 표준화된 사용자 명령 줄과 스크립팅 인터페이스들은 Korn Shell 에 기반했다. awk, echo, ed 등을 포함하는 많은 사용자 수준 프로그램, 서비스, 유틸리티들도 표준화되었으며, 기본적인 I/O( 파일, 터미널, 네트웤 )을 포함하는 프로그램 수준 서비스들도 포함한다. POSIX 는 표준 스레딩 라이브러리 API 도 정의하는데, 이는 현대의 거의 대부분의 OS 에 의해서 지원된다. 요새는 대부분의 POSIX 파트들이 하나의 IEEE Std 1003. 1-2008 표준에 포하모디었으며, 이는 POSIX 1-2008 로 알려져 있다.

하략...

- 출처 : 위키피디아, POSIX

OS/2 라는 것은 MS 와 IBM 이 초기에 제작한 운영체제로 요새는 별로 의미가 없으므로 관심있는 분들은 위키피디아의 OS/2 라는 글을 따로 읽어 보기 바란다.

POSIX 를 지원하는 OS 리스트는 다음 링크의 'POSIX-oriented operating systems' 절에서 찾아 볼 수 있다 : 위키피디아, POSIX. GNU/Linux 같은 경우에는 POSIX 에 대해 '거의 대부분의 호환성' 을 가지고 있다. 시그윈은 POSIX 에 대해 '많은 호환성' 을 가지고 있다고 표현되고 있다. 즉 안드로이드 시스템의 기반이 되는 리눅스가 POSIX 를 거의 완벽하게 지원하고 있기 때문에, 우리는 윈도우즈 상에서 시그윈을 통해 거기에 맞는 환경을 구성할 수 있는 것이다.

위에서 윈도우즈의 POSIX 서브시스템에서 언급을 했는데 여기에서 윈도우즈의 POSIX 를 언급한 것은 그냥 예를 든 것 뿐이다. 시그윈이 윈도우즈의 POSIX 서브시스템의 레이어라는 이야기는 아니다. 왜 그럴까? 윈도우즈의 POSIX 서브시스템은 POSIX 표준을 제대로 지키고 있지 않기 때문이다. 

시그윈은 윈도우즈의 POSIX 와는 개별적으로 동작하는 개발환경이다. 시그윈 환경, 시그윈 서브시스템, 시그윈 플래폼 등의 용어를 사용해도 무방하지 않을까 싶다. 시그윈이 윈도우즈의 POSIX 서브시스템의 레이어로서 동작하지 않는 이유는 다음 글을 보면 좀 더 이해가 가지 않을까 싶다 : The Sad History of the Microsoft POSIX Subsystem. 아래에 일부만 인용해 보았다. 요약하면 윈도우즈 POSIX 가 허접(?)이란 것과 XP 부터는 POSIX 서브시스템을 지원하지 않는다는 것이다. 그 뒤의 이야기가 쭉 나오는데 다 읽어 보지는 못했다.

윈도우즈 NT 가 처음 개발되고 있었을 때, 목표 중의 하나는 커널을 프로그래밍 인터페이스와 분리하는 것이었다. NT 는 원래 OS/2 를 성공시키기 위한 것이었지만, 마이크로소프트는 윈도우즈 3.x 응용프로그램들을 실행하기 위한 호환성을 포함시키고, 방위산업 시장에 판매하기 위한 1980 년대 DoD( 국방성 ) Orange Book 과 FIPS 명세들을 만족시키기 원했다. 결과적으로 윈도우즈 NT 는 복잡한 자유재량에 의한 접근 제어 기능을 가진 멀티유저 플래폼으로서 개발되었으며, 하이브리드 마이크로커널 3 유저랜드¹ 환경들로서 구현되었다 :

• Windows( Win32 )
• OS/2
• POSIX

마이크로소프트는 Win32 문제를 가지고 IBM 과 다퉜으며, NT 프로젝트는 OS/2 와 갈라섰다. 팀의 초점은 Win32 로 이동했다. 그래서 Win32 API 를 호스트하는 Client Server Runtime Subsystem( CSRSS ) 은 의무적이 되었으며, OS/2 와 POSIX 서브시스템이 실제로 완료되지 않았음에도 불구하고 그것들은 윈도우즈 NT 부터 윈도우즈 2000 까지 5 개의 버전에 포함되었다. OS/2 서브시스템은 단지 OS/2 1.0 명령줄 프로그램들만을 실행할 수 있으며, presentation manager 에 대한 지원이 존재하지 않았다. POSIX 서브시스템은 POSIX.1 명세를 지원했지만, 모든 종류의 쉘이나 유닉스 같은 환경을 제공하지 않았다. Win32 가 윈도우즈 95 의 형태에서 성공하면서, OS/2 와 POSIX 서브시스템의 개발은 중단되었다. 그것들은 윈도우즈 XP 와 윈도우즈 서버 2003 에서 완전히 죽고 사라졌다.

반면에 Softway Systems 는 1996 년 쯤에 OpenNT 라고 불리는 유닉스-윈도우즈 NT 간 포팅 시스템을 개발했다. OpenNT 는 NT POSIX 서브시스템 상에서 빌드되었지만, 그것에 살을 붙여 이용할 수 있는 유닉스 환경을 제공했다. 이는 유닉스 시스템이 매우 비싸진 시점이었다. Softway 는 OpenNT 를 사용해서 US Federal agency 들을 위한 여러 유닉스 응용프로그램들을 윈도우즈 NT 로 변경했다. 1998 년에 OpenNT 는 Interix 라고 이름을 바꿨다. Softway Systems 는, 마이크로소프트 POSIX 서브시스템이 지원하지 않았던 시스템 호출을 구현하고, 풍부한 libc,  파일 시스템에 대한 single-rooted view, 그리고 실용적인 gcc 를 개발하기 위해, 최종적으로 NT POSIX 서브시스템에 대한 완전한 대체물을 만들었다.

하략...

위키피디아에 의하면 Windows Server 2003 R2 부터는 사실은 Interix 의 변형인 SUA( Subsystem for UNIX-based Applications )를 통해서 POSIX 를 지원하고 있다고 한다. 이것은 SFU( Windows Services for UNIX )라고 불리기도 한다. Windows Vista 및 Windows 7 의 Enterprise 에디션과 Ultimate 에디션도 SUA 를 포함하고 있다고 한다. 자세한 내용은 Windows Services for UNIX 를 참조하라.

결론.

우리가 윈도우즈 환경에서 리눅스 ARM 용 프로그램을 빌드하기 위해서는, 그에 맞는 바이너리를 생성해 줄 수 있는 환경( 컴파일러, API 등 )을 구성할 필요가 있다. 윈도우즈에서 이를 가능하게 해 주는 것이 POSIX 기반의 시그윈 개발 환경이다. 

우리는  시그윈 환경을 이용해 리눅스 ARM 용 프로그램을 빌드하고, 그것을 안드로이드 장치로 복사하고 설치하게 된다. 이것이 윈도우즈와 리눅스 간의  크로스 플래폼 개발이다. 안드로이드 SDK 를 사용하게 되면 자바 바이트 코드( 플래폼에 독립적인 중간 코드 )를 생성하기 때문에 빌드 환경이 중요하지 않지만, 안드로이드 NDK 는 실제 리눅스 API 를 이용하고 기계어로 컴파일하기 때문에 반드시 올바른 환경에서 개발해야만 한다.

이제 시그윈이라는 것의 정체에 대해 어느 정도 이해할 수 있게 되었을 것이라 생각한다. 그리고 시그윈을 통해 뭔가를 빌드한다는 것의 의미에 대해서 이해할 수 있게 되었을 것이라 생각한다.

센서 연구개발에 첫 발을 떼고 있습니다..

센서와 브레드보드(일명 빵판) 사이에는 I2C로 통신을 많이 하는 것으로 보여,
첫 관심사로 잡았습니다. ㅎㅎ

이미 블로그에 정리를 잘해주신 분들의 자료를 참고하려고 하며,
아래에 간단히 머리에 들어오는 블로그 링크 걸어 둡니다. ^^

* I2C통신으로 검색

http://blog.naver.com/jinoh9272/220578118650  <-- I2C 통신에 사용되는 SCL, SDA 와 레지스터들 기본 설명

http://cubloc.blog.me/220051675031  <-- I2C 통신 예시

http://blog.naver.com/gkf9876/220453341286 <-- MPU6050 가속-자이로 센서 +  ATmega128 PCB 예시
http://playground.arduino.cc/Main/MPU-6050 <-- MPU6050  아두이노 페이지

1. I2C 통신에는 Master가 되는 PCB와 Slave가 되는 것들 (센서 등)이 있다.
2. RS232에 비해 큰 장점이 1 : N 통신이 가능하다는 점이다. (1이 Master, N이 Slave)

Example.java

Views.java

출처 : https://gist.github.com/gelitenight/7999448

0. 들어가기 전에

 자바에서 String 문자를 더해가는건 큰 이슈가 있습니다. 보통 사람들은 String 에서 +를 이용하여 문자를 결합합니다. 이 방법은 작은 규모의 몇백자 정도로는 그렇게 큰 차이를 보이지 않을지도 모르지만 잘 모르고 쓴다면 작은 규모에서도 큰 차이를 보여줍니다. 이번에는 그 차이를 한번 따져보려고 합니다.  

1. 이론적인 차이

 1-1. String의 경우 

자바에서 String은 Immutable(불변의) 속성을 가지고 있습니다. 우리는 보통 String을 저장할 때 이렇게 합니다.

위와 같이 한다면 name에 있던 펭귄이라는 치킨으로 수정되는 것 처럼 보이지만 내부적으로는 수정되는 것이 아니라 새로운 메모리를 잡고 치킨이라는 값을 저장한 후 그 곳을 가리키는 방식이 됩니다.

 + 연산자로 더하는 작업도 마찬가지입니다.

새로운 메모리를 할당하여 그곳에 심해펭귄 이라는 글자를 저장하고 name이 그곳을 가리키게 한 후 기존의 펭귄이 저장된 메모리를 Garbage Collection이 제거해줍니다. 

단순히 문자를 몇개 더하는 경우도 이 과정을 거치지만 몇번 이내로 끝나는 횟수라면 굳이 다른 것을 쓰지 않으셔도 됩니다. (StringBuilder가 빠르지만 ns 단위의 차이입니다.) 다만 긴 문자를 몇 백번 이상 더할 경우에는 성능이 내려갈 수 있으므로 StringBuilder나 StringBuffer를 써주시는게 좋습니다. 

JDK5 이상의 버전부터는 String도 내부적으로 StringBuilder로 바꿔서 컴파일한다고는 하는데 막상 해보면 그다지 차이가 없습니다. 

1-2. StringBuilder와 StringBuffer의 경우

 StringBuilder와 StringBuffer는 String 과 다르게 가변의 속성을 가지고 있습니다. 그래서 할당된 공간에 계속 이어가는게 가능하며, append 메소드를 이용하여 문자를 추가합니다. 또한 할당된 공간이 오버플로우가 발생한 경우에는 자동으로 할당된 공간을 확장합니다. 

(이때 오버해드가 발생하여 속도가 약간 저하되는 듯 합니다.)

 StringBuilder의 경우 StringBuffer와 달리 동기화 된다는 보장을 하지 않지만 StringBuffer보다는 조금 빠른 속도를 보여줍니다.

만약 멀티 스레드를 사용하는 경우에는 동기화를 해야하는 경우가 생기는데  이 경우에는 StringBuffer를 이용하여야 합니다. StringBuffer는 멀티 스레드 작업에 대해서 안전하게 만들어져 있습니다. 하지만 일반적인 경우에는 멀티 스레드를 사용할 일이 별로 없으므로 StringBuilder를 사용하시면 되겠습니다.

2. 실제 속도 차이

속도를 계산하는 간단한 소스를 짜봤습니다. 글자수는 10자를 기준으로 하여 횟수를 조정하여 총 100자부터 10만자까지 더하도록 하겠습니다. 같은 시행횟수라도 시행때마다 값의 차이가 생깁니다. 하지만 그 차이는 그렇게 크지 않으며, 그 흐름 또한 일치하므로 오차가 조금 있을 수 있다 정도는 염두해 두시면 되겠습니다. 추출한 값은 ns로 추출하였지만 후반의 숫자가 매우 크므로 ms로 변환하여 표기하도록 하겠습니다.

10개자리 문자를 시행횟수만큼 더한 결과입니다.

문자를 10개 정도 더해도 String이 builder나 buffer보다 3-4배 정도 느린걸 알 수 있습니다. StringBuffer의 경우 처음 버퍼를 생성하는 시간 때문인지 첫 시행때 다소 시간이 걸립니다.

builder와 buffer가 속도가 느려졌다 빨라졌다 하는건 할당한 메모리가 다 차서 메모리를 늘려주는 작업을 하기 때문인 듯 합니다. 

시행횟수가 백번 이상으로 넘어가면 속도차이가 확연하게 벌어집니다. Builder와 Buffer는 그렇게 큰 차이가 나진 않지만 String과의 차이는 40배 이상으로 벌어졌습니다.

시행횟수가 1000이 넘어가면 String과의 격차는 몇백배 입니다.

시행횟수가 10만이 되면 String은 너무 느려서 쓸 수 없습니다. 1000ms = 1초인데 62000ms라면 62초나 걸리게 됩니다.

문자가 200만개가 되니 610000 ms가 걸렸습니다. 610초 즉 10분입니다.

덤으로 1개짜리 문자를 10000번 더하는 것이 100개짜리 문자를 100번 더하는것보다는 오래 걸리며, 100자짜리 문자를 100번 더하는 것이, 10자짜리 문자를 100번 더하는 것보다 오래 걸립니다.

펌 : http://blog.naver.com/platinasnow/220197411183

** CharSequences 인터페이스

CharSequences는 인터페이스로 String/StringBuffer/StringBuilder 세가지 클래스는 모두 

CharSequences 인터페이스를 상속받고 있습니다.

때문에 Charsequence에는 위 3가지 클래스를 모두 수용할 수 있습니다.(Up-casting)

또한 사용할 때에는 down-casting 해서 사용하시면 됩니다.

String/StringBuffer/StringBuilder 세가지 클래스를 매개변수로사용하는 함수라면 매개변수를 Charsequence로 해주는 좋겠죠?

펌 : http://blog.naver.com/tkddlf4209/220706609022

Collection Framework는 크게 3가지 형태로 분류할 수 있다.
  - Map  : key와 Value를 가지는 자료구조입니다. HashMap, Hashtable, TreeMap 등
  - List  : 순서가 있고 중복이 허용되는 자료구조입니다. ArrayList, LinkedList, Vector 등
  - Set   : 중복을 허용하지 않습니다.  HashSet, TreeSet 등

인터페이스에 대한 hierarchy관계를 이해하고 사용예제를 통해 각 인터페이스에 대한 특성을 확인해 보도록 한다.

[그림 3] Collection Interface 구성도

기본적으로 Collection의 경우 연속된 순서의 선형 자료형을 구현한 인터페이스이며, MAP은 Key, Value를 다루는 자료형을 구현한 인터페이스 이다. 기존에 구현된 Vector와 Hashtable의 경우, Synchronized를 지원하도록 설계되었기 때문에 다중 스레드 접근 시 병목현상을 유발할 수 있기 때문에 유의해서 사용하도록 한다.

** Collections Synchronized 

import java.util.*;

public class SynchronizedCollectionTest {
   public static void main(String[] args) {
       // create vector object
       List<String> list = new ArrayList<String>();

       // populate the list
       list.add("1");
       list.add("2");
       list.add("3");
       list.add("4");
       list.add("5");

       // create a synchronized list
       List<String> synlist = Collections.synchronizedList(list);
       System.out.println("list :"+synlist);
   }
}

참고 : http://rocksea.tistory.com/336
        http://whosnext.blog.me/100037993078

다양한 공식적인 프로그래밍 대회가 있지만

참고로 아시아권에서 펼쳐지는 프로그래밍 대회로 ACML 라는 게 있습니다.

그리고 코드포스 (code forces) 라는 (https://codeforces.com/)

프로그래밍 경시대회? 혹은 프로그래밍 올림피아드 같은 비공식 대회가 있습니다.

https://ironmask.net/279 에서 한번 간략히 소개를 했었네요 ㅋㅋ

저는 2016년에 가입을 햇었고 사내 프로그래밍 대회에 참여를 해보려는 심산이었죠 ㅎㅎ

생각보다 프로그래밍에 그렇게 취미를 붙이기는 쉽지 않아서

결국 2문제 도전 해보고 포기했네요 ㅜㅜ

그 중 처음으로 풀어서 문제 조건을 해결해낸 문제가 아래 문제입니다.

http://codeforces.com/contest/615/problem/A

보통 프로그래밍 대회에서 나올법한 문제들은,

대량의 연산을 요구하고, 이를 빠른 수행이 완료될 것을 요구합니다.

그리고 실제대회에서는 이러한 문제를 시간내에 풀어야 하죠 ㅜㅜ

사실 문제 풀 시간을 무한정 주더라도 문제 풀어내기가 힘든 레벨입니다. ㅋ

프로그래머를 직업으로 했던 저로서는 부끄러운 일 일지 모르겠습니다만,

원래 하던 코드만 만지다 보면 이런 코드 상당히 어렵습니다.

참고로, 국정원에 도전해본적이 있었는데,

실기 시험문제가 비슷한 방식의 문제들이었던 것 같네요.

아래는 해결했던 코드입니다.

사실 Java보다 C나 C++로 해야 더욱 빠른 해결 접근법이 가능합니다만,

이때부터 Java가 주력언어가 되어서 Java로 해결했습죠..

언젠가 다시..

프로그램 개발을 Job으로 하는 날이 올거라고 생각합니다..

물론 수준 높은 처우와 함께.. ^^

기초부터 쌓아올려서 다시금 이 때 레벨까지 올라가서

Codeforces를 재방문하는 날이 기다려지네요!

앞서 안드로이드 플랫폼에서 리소스에 따른 정책에 대해 공유드렸습니다.

이번엔 그러한 정책에 따른 해상도별 관리를 어떻게 하는 것이 좋을지에 대해 공유 드립니다.

이번에도 이미 잘 정리해놓으신 분들의 글을 좀 퍼왔습니다. (http://arabiannight.tistory.com/entry/293 펌)

아직 앱 개발 초보라 모르는 것이 많아서 ㅠㅠ..

사실 안드로이드 플랫폼을 탑재한 모든 기기(모바일 폰, 태블릿 등등)에 대해 해상도를 최적으로 맞추기는 불가능한 수준입니다. 그래서 최대한 여러 해상도를 커버하기 위한 방법에 대해 생각해보면 아래와 같습니다.

[범용 해상도 맞추는 법]

1) 해상도별 폴더를 만들어라.

-> 안드로이드 단말만 수천개 이상, 현실적으로 불가능.

-> 타겟 단말을 지정해서 개발 해라. 

[범용 해상도를 최대한 고려한 작업 방법]

1) match_parent를 잘 활용 하라.

2) weight를 사용하라.

3) RelativeLayout을 사용 하라.

-> align, parent, below, above 등의 속성를 사용하라.

4) dp값을 활용하라.

5) 나인패치를 활용하라.

6) 통이미지라면 큰 이미지를 사용해서 작은 화면에 적용 하라.

7) Scrollview를 잘 활용하라.

나인패치 관련
개념 :  http://blog.naver.com/purplestudiogames/220605836258 참고

적용 :  http://bcho.tistory.com/1059 참고

AndroidManifest.xml 파일에 속성 중에 리소스 identifier 와 비슷한 속성 설정이 있는데 아래와 같다.

android:configChanges 값이 아무것도 없을 때는 단말을 돌려서 단말 표시 모드가 portrait mode -> landscape mode 가 되면 위에서 설명된 것과 같이 기본 동작은 Activity 가 destroy 되었다가 다시 시작합니다.

android:configChanges = "orientation" 이 설정되면, portrait mode -> landscape mode 가 되어도, Activity는 destroy 되지 않습니다. 대신에 Activity에 override 된 onConfigurationChanged() 함수가 호출되며, 여기서 환경변화 ( config changes ) 에 대한 처리를 해줍니다.

 가장 흔하게 접할 수 있는 경우가 위에서 예를 든 orientation changes 경우입니다.

마찬가지로 흔하게 접할 수 있는 것이 keyboardHidden 입니다.
keyboardHidden 은 hardware keyboard가 보이냐 안 보이냐에 따라서 발생하는 변화입니다.

가장 대표적인 hardware keyboard를 갖춘 device인 옵티머스 Q를 보면, 슬라이드 형식으로 QWERTY 자판을 꺼냈다 숨겼다 할 수 있죠.
이 때 변화가 없어도 되는데 쓸데 없이 Activity 가 파괴되고 생성되면 안 되겠죠? 그래서 QWERTY 자판이 있을 경우는 거의 대부분 이 attribute 설정이 필요하게 됩니다.

그 외에도 configChanges 가 발생했을 때 단순한 Activity의 재시작 이외에 추가적 작업을 해 줄 때에도 사용됩니다.

먼저 configChanges에는 여러가지 값들을 '|' ( or ) 구분자를 통해서 함께 입력 가능합니다.

펌 : http://aroundck.tistory.com/36

- default 리소스와 hdpi 대체 리소스 -

아래 표는 어플리케이션이 가지고 있는(프로그래머가 제공해준, 어플이 제공해줄수 있는) 이미지 resource들과,

실제 디바이스(기기)의 환경입니다.

images	device configuration
drawable/ drawable-en/ drawable-fr-rCA/ drawable-en-port/ drawable-en-notouch-12key/ drawable-port-ldpi/ drawable-port-notouch-12key/	Locale = en-GB  Screen orientation = port  Screen pixel density = hdpi  Touchscreen type = notouch  Primary text input method = 12key

실제로 안드로이드는 아래의 플로우 차트를 통해 리소스를 찾아내고 매칭합니다.

1번. 기기 환경과 모순되는 것들 제거하기   Locale이 en-GB로 설정되어있기 때문에   drawable-fr-rCA/ 디렉토리를 제거합니다. drawable/ drawable-en/ drawable-fr-rCA/ drawable-en-port/ drawable-en-notouch-12key/ drawable-port-ldpi/ drawable-port-notouch-12key/  2번. MCC, MNC, Language,        그리고 나머지 순으로 Qualifier 확인하기  3번. 분기.       (qualifier 중 포함되어있는 디렉토리 찾기)          매칭되었으면 4번으로,         매칭되지 않았으면 2번으로 돌아가기  4번. 포함되어있지 않은 Qualifier 제거하기   lanuage qualifier 가 포함되어있지 않은 디렉토리 제거     drawable/ drawable-en/ drawable-en-port/ drawable-en-notouch-12key/ drawable-port-ldpi/ drawable-port-notouch-12key/  5번. 하나의 디렉토리로 매칭될때까지 계속하기   계속해서 2번, 3번, 4번의 스텝을 반복하게 되면,   결국에는 drawable-en-port 만 남게됩니다. drawable-en/ drawable-en-port/ drawable-en-notouch-12key/

퍼옴 : http://croute.me/323

원글 : http://developer.android.com/guide/topics/resources/providing-resources.html

응용 프로그램 리소스를 독립적으로 유지하기 위해, 코드에서 이미지와 문자열과 같은 리소스를 구체화해야 한다. 또한 특별한 이름이 붙여진 리소스 디렉토리들 내에서 그것들을 그룹화하여, 특정한 디바이스 구성(Configuration)을 위해 대안적인 리소스들을 제공해야한다. 안드로이드는 실행시간에 현재 구성에 바탕을 둔 적합한 리소스를 사용한다. 예를 들어 화면 크기에 따라 다른 UI 레이아웃을 사용하거나 셋팅된 언어에 따라 다른 문자열이 제공되기를 기대할 수 있다.

일단 응용 프로그램 리소스를 구체화하면, 프로젝트의 R 클래스 내에 만들어진 리소스 ID들을 사용하여 리소스에 접근이 가능하다. 응용 프로그램에서 리소스를 사용하는 방법은 Accessing Resources에서 확인할 수 있다. 이 문서는 어떻게 안드로이드 프로젝트 내의 리소스들을 그룹화 하고 특정 디바이스 구성을 위한 대안적인 리소스들을 제공하는지 보여준다.

리소스 유형 그룹화

프로젝트의 /res 디렉토리의 특정 하위 디렉토리에 각 타입의 리소스를 배치해야 한다.

MyProject/
    src/
        MyActivity.java  
    res/
        drawable/  
            icon.png  
        layout/  
            main.xml
            info.xml
        values/  
            strings.xml 

이 예에서 볼 수 있듯이, 하나의 이미지 리소스(icon.png), 두 개의 레이아웃 리소스(main.xml, info.xml), 하나의 스트링 리소스 파일들(strings.xml) 등 /res 디렉토리는 (하위 디렉토리들 안에) 모든 리소스를 포함한다. 리소스 디렉토리 이름은 중요하며 표 1에 설명되어 있다.  

표 1. 프로젝트 res/ 디렉토리 내에 지원되는 리소스 디렉토리

주의 : /res 디렉토리 내에 직접적으로 리소스 파일을 저장하지 않도록 한다. 이는 컴파일 에러의 원인이 된다.

리소스 타입들에 대한 더 많은 정보는, Resource Types 문서를 참조한다.

표 1에 정의된 하위 디렉토리들 내에 저장한 리소스들은 당신의 "디폴트" 리소스들이다. 즉 이 리소스들은 응용 프로그램의 기본 디자인과 컨텐츠를 정의한다. 그러나 다른 타입의 안드로이드 디바이스들은 다른 타입의 리소스들을 요구할지 모른다. 예를 들어 디바이스가 일반적인 화면보다 더 큰 화면을 졌다면, 추가 화면 공간을 용한 다른 레이아웃 리소스들을 제공해야 한다. 또 디바이스가 다른 언어로 셋팅되어있다면, 사용자 인터페이스에서 텍스트를 번역한 다른 스트링 리소스들을 제공해야 한다. 다른 디바이스 구성에 대해 다른 리소스들을 제공하기 위해, 디폴트 리소스뿐 아니라 대안적인 리소스들을 제공할 필요가 있다.

대안적인 리소스 제공

거의 모든 응용 프로그램은 특정 디바이스 구성을 지원하기 위해 대안적인 리소스들을 제공해야한다. 예를 들어, 다른 화면 밀도를 위해 대안적인 드로어블 리소스와 다른 언어를 위한 대안적인 스트링 리소스를 포함해야 한다. 실행 시간에 안드로이드는 현재 디바이스 구성을 발견하고 적합한 리소스들을 로드한다.

그림 1. 각각 다른 레이아웃 리소스를 사용하는 두 개의 다른 디바이스들 

리소스 셋에 대해 

1. <resources-name>-<config_qualifier> 내에 명명되어진 res/ 내에 새로운 디렉토리를 만들어라. 

ㅁ <resources_name>은 (표 1에 정의된)디폴트 리소스들에 대응하는 디렉토리 명이다. 

ㅁ <qualifier>는 (표 2에 정의된) 리소스가 사용되는 개인 컨피규레이션을 지정한 이름이다. 

대쉬로 각각 분리해서 <qualifier>를 하나 이상 추가할 수 있다. 

주의 : 다수의 한정자를 덧붙일 때, 표 2에 목록으로 만들어진 동일한 차수 내에서 그것들을 배치해야 한다. 한정자가 틀리게 지시받으면, 리소스들은 무시된다. 

2. 이 새로운 디렉토리 내에 각각의 대안 리소스들을 저장하라. 리소스 파일들은 디폴트 리소스 파일들과 정확히 동일한 이름을 지정해야 한다. 

예를 들어, 여기 디폴트 리소스와 대안 리소스가 있다: 

res/
    drawable/   
        icon.png
        background.png    
    drawable-hdpi/  
        icon.png
        background.png 

hdpi 한정자는 고밀도 스크린을 가진 디바이스에 대한 디렉토리 내의 리소스들을 나타낸다. 각 드로어블 디렉토리들 내의 이미지들은 특정한 스크린 밀도를 위해 크기에 따라 분류된다. 그러나 파일 이들들은 정확하게 동일하다. 이 방법으로, icon.png나 background.png 이미지를 참조하는데 사용하는 리소스 ID는 항상 동일하다. 그러나 리소스 디렉토리 이름 내에 한정자로 디바이스 구성 정보를 비교하며 안드로이드는 현재 디바이스와 가장 잘 맞는 리소스 버전을 선택한다. 

안드로이드는 몇몇의 구성 한정자를 제공하고 당신은 대쉬로 각 한정자를 분리시킴으로써 하나의 디렉토리 이름에 다수의 한정자를 추가할 수 있다. 표 2는 유효한 구성 한정자를 우선 순위 차례대로 목록으로 보여준다. 리소스 디렉토리에 대해 다수의 한정자를를 사용한다면, 그것들이 표에 리스트된 순서대로 디레곹리 이름에 그것들을 추가해야 한다. 

퍼옴 : http://blog.naver.com/PostView.nhn?blogId=mad_ai&logNo=130165607607

Primitive type과 Reference type 그리고 Object 클래스

Primitive type (원시타입)

● 자바 언어에 내장된 기본 유형 
● 자바는 정수, 실수, 논리, 문자 방식의 primitive type을 지원한다. 
● wrapper class는 각 primitive type을 클래스로 만든 것이다. 
● stack 메모리에 저장됨. 

■ byte 

• 8 비트 크기에 부호있는 정수
• 표현할 수 있는 범위는 -128 ~ 127
• 2의 보수로 메모리에 저장됨
• 기본값 : 0
• wrapper class : Byte

■ short 

• 16 비트 크기에 부호있는 정수
• 표현할 수 있는 범위는 -32,768 ~ 32,767
• 2의 보수로 메모리에 저장됨
• 기본값 : 0
• wrapper class : Short

■ int 

• 32 비트 크기에 부호있는 정수
• 표현할 수 있는 범위는 -2,147,483,648 ~ 2,147,483,647
• 2의 보수로 메모리에 저장됨
• 주로 사용
• 기본값 : 0
• wrapper class : Integer

■ long 

• 64 비트 크기에 부호있는 정수
• 범위는 -9,223,372,036,854,775,808 ~ 9,223,372,036,854,775,807
• 2의 보수로 메모리에 저장됨
• 기본값 : 0L
• wrapper class : Long

■ float 

• 32 비트 크기에 실수
• IEEE 754 표준을 따릅니다.
• 부동소수점 방식으로 메모리에 저장됨
• 화폐와 같이 정확한 값을 요하는곳에 double을 사용하면 안됨
• 기본값 : 0.0f
• wrapper class : Float

■ double 

• 64 비트 크기에 실수
• IEEE 754 표준을 따릅니다.
• 부동소수점 방식으로 메모리에 저장됨
• 화폐와 같이 정확한 값을 요하는곳에 double을 사용하면 안됨
• 기본값 : 0.0d
• wrapper class : Double

■ boolean 

• true와 false의 두 가지 값을 가지는 논리형
• 참 / 거짓 상태를 판별하기 위한 간단한 flag로 boolean을 사용합니다.
• 1bit의 정보를 표현하지만, 사용하는 메모리 크기는 정확히 정해져 있지 않습니다.
• 기본값 : false
• wrapper class : Boolean

■ char 

• 16 비트 유니 코드 문자
• 범위는 0 ~ 65,535 혹은 '\ u0000' ~ '\ uffff'
• 기본값 : ‘\u0000’
• wrapper class : Character

Reference type

• 클래스 타입(class type), 인터페이스 타입(interface type), 배열 타입(array type), 열거 타입(enum type)
• Ball 클래스의 참조형 변수를 선언 : Ball b; → Ball 클래스 인스턴스를 생성 후 참조형 변수에 할당 : b = new Ball(); → heap 메모리에 저장.
• 힙 메모리에 생성된 인스턴스는 메소드나 각종 인터페이스에서 접근하기 위해 JVM의 Stack 영역에 존재하는 Frame에 일종의 포인터(C의 포인터와는 다르다.)인 참조값을 가지고 있어 이를 통해 인스턴스를 핸들링한다.
• 그래서 참조형 클래스 사용 시 아래의 변수 할당 방식을 사용시 할당된 변수가 변경되는 원소스에 해당되는 변수도 같이 변형된다. 그래서 원소스에 해당되는 인스턴스와 별개로 할당 변수를 사용하기 위해서는 clone 내지 별개의 힙 메모리에 복사를 하여 사용하는 것이 안전하다.

• JVM과 메모리 구조 챕터에서 생성과 소멸 등의 과정 참조

Object Class

• 클래스 계층구조의 루트 클래스
• Primitive type이 아닌 모든 type(배열 포함)이 Object 클래스를 직접, 간접적으로 상속합니다.
• Object 클래스는 JVM(특히 Execute Engine / Garbage collector)에서 클래스 인스턴스의 생성과 소멸 등의 생명주기(life cycle)을 관리할 수 있게 한다.
• 클래스의 생성자 Object 클래스의 finalize(), wait() 등 대부분의 메소드가 JVM에서 클래스를 핸들링하기 위해 사용되는 메소드다.
• 참조형 변수(클래스)들은 기본적으로 Object를 상속하기 때문에 모든 클래스의 인스턴스의 라이프사이클을 관리할 수 있게 된다.

• Object 클래스의 메소드

String 클래스

• 문자열을 primitive type 처럼 사용할 수 있도록 String 클래스를 특별하게 처리함. 즉, String 클래스는 일종의 Primitive 타입(원시타입)처럼 사용 가능하지만 원시타입에는 속하지 않는다.
• String 클래스는 값이 변경되지 않으며, 값을 변경하는 함수가 있지만, 이 함수는 값이 다른 String 클래스 객체를 생성한다. (immutable object)
• String s = “aaa”; 와 같이 큰따옴표를 사용하여 생성자를 호출할 수 있다.
• String 클래스만이 + 연산자를 통해 문자열 연결
• String 비교시 equals() 함수 사용
• String class의 사용 예제 : 첨부 소스 참조

http://www.gliderwiki.org/wiki/79  펌

보통 안드로이드 프로젝트를 개발할 때는 git이란 형상관리도구를 사용합니다.

git에 소스를 반영할 때는 여러 사람이 반영하게 되므로, 보통 Code Rule을 몇 가지 정해놓고 반영하도록 하는데요..

그 중에 에러를 최소화하기 위해 tab 대신에 space로 반영하도록 하는 사항이 있습니다.

코드 가독성을 위해 tab으로 들여쓰기를 보통 사용하는데,

Eclipse에서 이 tab을 누르거나, 자동 들여쓰기 기능을 할 때, Space로 바꿔주는 기능이 있습니다.

아래 2가지 방법 중 1번으로 안될 경우, 2번까지 적용하시면 됩니다.

http://blog.naver.com/xinfra/80172458285

http://mainia.tistory.com/2006

http://blog.naver.com/rlawlss/80140113577

http://nekomimi.tistory.com/483

http://mainia.tistory.com/2052

http://taehoonkoo.tistory.com/132

안드로이드에는 BroadcastReceiver 라는 Callback 이벤트를 처리해주는 컴포넌트가 제공됩니다.

쉽게말해서, A라는 앱을 만들었는데, 

문자가 왔을 때 어떤 데이터를 받고 싶다던가 배터리가 50% 이하가 되었을 때 뭔가 변화를 주고 싶다고 한다면

SMS 앱이나 배터리체크 앱에서 어떤 이벤트를 데이터와 함께 날리게 되고,

A에서는 그 이벤트와 데이터를 받아서 원하는 기능을 처리하도록 할 수 있다는 것입니다.

위에서 언급한 이벤트처리를 복잡하지 않고 쉽게 처리해주는 녀석이 BroadcastReceiver 라는 컴포넌트 인 것입니다.

아래에 2가지 방법에 대한 예시를 올립니다.

1. BroadcastReceiver 클래스를 상속  (AppWidgetProvider 도 가능, 아마 BroadcastReceiver를 가지고 있겠지..)

   onReceive() 를 Override해서 기능 정의

   androidManifest.xml에 등록되어 있어야 함.

  * androidManifest 이용해서 등록하면, 명시적으로 해제해줄 수는 없다. (unRegisterReceiver 불가능)
    (onReceive() 메소드가 완료되면 가비지 컬렉션 대상이 되서 해지될지도... 언제 될지는 모름...)

2. Actvity, Service, ContentProvider에 registerReceiver() 내에서 등록한다. 

   * onDestory() 에서 this.registerReceiver() 해줬던것을 해제가능 (메모리 누수 방지 효과도 있음)