십자성군의 비밀의 방

○스트림 : 데이터를 운반하는데 사용되는 연결통로

기반스트림 : 보조스트림의 부모가 되는 클래스

○보조스트림

-주 스트림의 기능을 보완하기 위한 스트림

-실제 데이터를 주고받는 스트림은 아님

-스트림의 기능을 향상시키거나 새로운 기능을 추가

사용법 : 주 스트림을 먼저 생성한 다음 이를 이용하여 보조스트림 생성

ex)

1. 기반스트림 생성

FileInputStream fis = new FileInputStream("test.txt");

2. 보조스트림 생성

BufferedInputStream bis = new BufferedInputStream(fis);

3. 보조스트림 사용

bis.read();

종류

○문자기반 스트림

-바이트 기반 스트림은 1byte를 기반으로 하므로 java와 같이 문자가 2byte기반인 언어에서는 문자를 처리하는데 어려움이 있다. 문자데이터를 입출력 할 때는 문자기반 스트림을 사용하는 것이 유리하다.

바이트기반 스트림과 문자기반 스트림

바이트기반 보조스트림과 문자기반 보조스트림

응용. singleton 패턴과 volatile---DCL(Double Checking Locking)

간단한 싱글톤 예제를 작성하겠다

public class Singleton{

private static Singleton uniqueInstance;

private Singleton() {}

public static synchronized Singleton getInstance(){

if(uniqueInstance == null){

uniqueInstance = new Singleton();

}

return uniqueInstance;

}

}

위 타입의 인스턴스는 유일하게 하나만 존재해야 한다. 그러나 synchronized가 없을 경우, 다수의 쓰레드에서 인스턴스 생성/접근을 시도했을 때, 다수의 인스턴스가 발생할 가능성이 있다.

ex)

1. Thread1 에서 if(uniqueInstance == null) 에 접근

2. Thread1 이 다은 행을 이행하기 전에 Thread2에서 if(uniqueInstance == null) 실행

3. Thread1, 2에서 각각 new Singleton() 실행

synchronized를 적용하면 한 스레드가 메소드 사용을 끝내기 전까지 다른 스레드는 기다려야 한다.

그러나 이 경우 접근에 너무 제한이 들어 동시에 접근이 일어났을 때 처리가 늦어진다.(비용이 너무 크다)

따럿 아래와 같은 double checking locking 기법을 사용한다.

public class Singleton{

private static Singleton uniqueInstance;

private Singleton() {}

public static Singleton getInstance(){

if(uniqueInstance == null){

synchronized (Singleton.class){

if(uniqueInstance == null){

uniqueInstance = new Singleton();

}

}

}

return uniqueInstance;

}

}

설사 Thread2가 객체생성 전에 첫번째 checking에 진입하여도 synchronized에 걸리게 된다.

이미 객체가 생성되어있을 경우 synchronized에 걸릴것 없이 바로 객체를 받게된다.

그러나 아래와 같은 low-level 문제가 발생할 수 있다.

public class Singleton{

private static Singleton uniqueInstance;

private Singleton() {}

public static Singleton getInstance(){

if(uniqueInstance == null){

synchronized (Singleton.class){

if(uniqueInstance == null){

some_memory_space = aloocate space for Singleton object;

uniqueInstance = some_memory_space;

create a real object in some_memory_space;

}

}

}

return uniqueInstance;

}

}

new를 사용하여 객체를 생성할 때, 메모리 공간의 확보-변수에 메모리 공간 링크-해당 메모리에 오브젝트 생성 순으로 작업이 이루어진다. 이 때 아래와 같은 문제가 발생할 수 있다.

1. Thread1은 '변수에 메모리 공간 링크'만 된 상태

2. Thread2가 첫번째 if문에 걸림. 오브젝트가 생성되었다고 착각

3. Thread2가 getInstance()함수를 탈출, 해당 메모리 공간(오브젝트가 아직 미생성) 으로 작업을 하려고 함.

4. 오브젝트가 생성되지 않았기 때문에 에러 발생

이것이 재배치(reordering)과정에 의해 발생하는 문제이다.

public class Singleton{

private volatile static Singleton uniqueInstance;

private Singleton() {}

public static Singleton getInstance(){

if(uniqueInstance == null){

synchronized (Singleton.class){

if(uniqueInstance == null){

uniqueInstance = new Singleton();

}

}

}

return uniqueInstance;

}

}

volatile이 적용된 코드이다. volatile을 적용시켰기 때문에 오브젝트 생성/메인메모리에 배치까지 바로 업데이트가 되어 재배치 문제가 해소된다.

그러나 1.5 미만의 버전의 경우, 변수 자체(uniqueInstance)에만 업데이트 해주도록 되어있다. uniqueInstance = some_memory_space라는 대입과정이 메인 메모리에 실행만 하면 되기 때문에 오브젝트 생성전에 앞선 문제가 발생할 수 있다.

1.5 이상의 버전의 경우 모든 값(상태)가 업데이트가 된다. 즉, 재배치를 스킵하고 오브젝트 생성까지 진행되고 메인 메모리에 업데이트가 되기 때문에 문제가 발생할 소지가 없다는 것이다.

 참고 : http://blog.naver.com/jwmoon74/100157579221

1. volatile 을 사용하지 않은 변수 : 최적화가 될 수 있다. 재배치(reordering) 될 수 있다.

2. volatile 을 사용한 변수(1.5 미만) : 그 변수 자체에 대해서는 최신의 값이 읽히거나 쓰여진다.

3. volatile 을 사용한 변수(1.5 이상) : 변수 접근까지에 대해 모든 변수들의 상황이 업데이트 되고, 변수가 업데이트 된다.

1.

위와 같은 순서로 프로그램이 실행된다고 할 때(ready는 false로 초기화) volatile이 미적용된 상태에서 예상할 수 있는 문제는

1. answer와 ready의 최적화

2. 실행시간에 캐쉬된 값들이 바로 메인 메모리에 업데이트 되지 않을 수 있음

2번 문장이 실행되었는데 캐쉬만 업데이트 한 뒤, mail memory에 적용되지 않고 3번이 실행되었다면 3번에서 ready가 false로 읽어질 수 있다.

2.(1.5미만)

ready에 volatile이 적용될 경우, ready가 읽혀지거나 쓰여질 때마다 바로 업데이트 된다.

따라서 3번 문장에서 문제가 발생하지 않는다.

answer에 대하여 volatile이 적용되지 않았기에 최신의 answer(2)가 4번 문장에 전달되지 않았을 수 있다.

3.(1.5이상)

ready에 volatile이 걸렸을 경우, ready의 값이 읽혀지거나 쓰여질 때마다, 그 때까지의 쓰레드의 '모든 상태'가 업데이트 된다.

즉, thread 1의 ready가 true로 쓰여질 때,

같은 쓰레드에 있던 answer도 메인메모리에 업데이트 된다.

따라서 3번, 4번도 제대로 값이 읽어지게 된다.

본 자료는...

volatile이라는 정의의 의미

1.특정 최적화에 주의해라

2,.멀티 쓰레드 환경에서 주의해라

주로 C,C++이나 MCU의 레지스터를 다룰 때 1번의 의미로 사용되곤 하며

Java에서는 2번의 의미로 사용되곤 한다.

1.

옵티마이즈 기능에 의한 최적화를 시키지 않는다.

ex)

위와 같이 된다. foo에 volatile을 적용하면

위와 같이 최적화에 의한 생략과정이 발생하지 않는다.

permission까지 다 설정했는데 액티비티 안에 Google Maps의 View를 배치하고 Google로고가 들어가는 뷰까지 떴는데, 지도는 안뜰 경우

-코드구조적인 문제라기 보다는 사용자 인증에서 설정한 package경로와 메니페스트에서 설정한 package경로가 다른겁니다.

혹시 TabhostFragment를 쓰고계시지는 않으신지요? google Maps를 위한 클래스가 들어있는 패키지는 사용자 인증에서 설정한 패키지와 같을지라도 실제로 내용이 들어가는 container는 다른 패키지일지도 모릅니다. 사용자 인증에서 설정해야하는 경로는 container의 경로입니다.

앞서 다룬 리니어레이아웃 외에도 다양한 레이아웃이 존재한다. 여기서는 리니어레이아웃과 함께 자주쓰이는 렐러티브레이아웃(Relative layout)을 다루도록 한다.

리니어레이아웃은 기본이 '순서대로 차곡차곡 배치'한다는 것이다. 렐러티브레이아웃의 배치는 ~의 위에, 아래에 배치하는 상대배치이다. 즉, 뷰와 부모 또는 뷰 끼리의 위치관계를 지정하여 배치하는 것이다.

아래는 렐러티브레이아웃의 배치속성이다.

렐러티브레이아웃의 배치를 위해서는 비교대상이 먼저 정의되어 있어야한다는 사실에 주의해야한다.

가령 A와 B라는 뷰가 있는데 레이아웃상에 B를 A의 아래에 배치하고 싶다면 A가 먼저 정의되고 배치되어야 한다.

또한 논리에 맞지 않는 정의는 당연히 불가능하다.

가령 A를 B의 위에, B를 A의 위에 같은 정의는 불가능하다.

◎레이아웃 :

앞서 확인햇듯이 레이아웃은 ViewGroup으로부터 파생된다. 따라서 텍스트나 버튼 등의 기본 위젯들이 차일드로 포함된다. 즉 여러 기본 위젯들이 모여서 하나의 레이아웃을 구성하고 이들이 모여 액티비티 화면이 완성된다.

◎리니어 레이아웃(Linear layout) :

Linear라는 이름 그대로 차일드 뷰를 일렬로 배치한다. 배치방법을 수평으로 일렬로 하거나 수직으로 일렬로 배치하는것을 기본으로 한다.

위는 버튼, 텍스트를 배치하는 사진이다. orientation(방향)이 horizontal(수평)으로 되어있기 때문에 뷰를 수평으로 배치한 것이다.

◈함수:

orientation : 레이아웃의 배치방향을 선택할 수 있다.

layout_width/layout_height : 레이아웃 내부의 해당 뷰의 크기를 지정한다. 수치로 크기를 정하거나 규칙으로 지정할 수 있다.

위의 사진은 텍스트 2개, 버튼 한개를 배치한 상태에서 Hello world 텍스트 뷰의 layout_width를 레이아웃의 크기에 맞추었기 때문에 옆에있던 두개 뷰가 화면 오른쪽 바깥으로 밀려난것이다. wrap_content는 뷰의 내용물의 크기에 맞춰 뷰의 크기가 정해진다.

gravity : 뷰의 내용물을 정렬한다. '|'를 이용하여 정렬조건을 조합할 수 있다.

위처럼 폭에 대해 match_parent로 뷰의 폭을 액티비티 가득히 만들고 가운데 정렬을 해보았다.

layout_gravity : gravity가 뷰의 내용물을 정렬한다면 layout_gravity는 뷰를 부모에 대해서 정렬한다. 명령의 내용은 gravity와 동일하다.

수직리니어라는 가정하에 첫번째 그림을 보자. 위와같은 수직정렬은 수직리니어에서 무시된다. 수직정렬 자체가 무시된다. 리니어레이아웃은 기본적으로 뷰를 순서대로 차곡차곡 빈틈없이 배치하는 것이기 때문에 첫째 뷰 위에 두번째 뷰가 위차할 수 없다. 다만 오른쪽 그림과 같이 수평정렬은 가능하다. 반대로 수평리니어에서는 수평정렬이 무시된다.

background : 

baselineAligned : 뷰가 아닌 레이아웃에 적용하는 속성으로, 수평리니어에서만 적용되며 수직리니어에서는 무시된다. 기능은 나란히 배치된 높이가 서로다른 뷰들의 수직정렬을 위로 맞출것인지 아래로 맞출것인지를 정한다.

baselineAligned 속성의 default는 true로 오른쪽 그림과 같이 아래쪽 베이스가 가지런히 정렬된다. false로 할 경우 왼쪽 그림과 같이 된다.

layout_weight : 부모의 남은 공간에 대한 차지비율을 정하는 속성으로 weight는 중요도를 의미한다. 부모안에 있는 뷰들의 모든 weight총합에 대한 비율에 따라서 남은 공간이 배분된다. default는 0이다.

위 그림은 버튼의 weight를 각각 1과 2로 지정한 것이다.

위 사진은 2번 버튼의 weight만 1로 지정한 것이다. 다른 뷰는 모두 0으로 지정되어있기 때문에 2나 3으로 설정해도 같을 것이다.

패딩/마진

레이아웃에 뷰들을 배치할때, 기본적으로 다닥다닥 붙어있다. 물론, 이들간의 간격을 조절할 수 있는데 이것이 padding과 margin이다.

layout_margin : 뷰와 부모사이의 간격을 지정. 주위에 형제 뷰가 있으면 형제 뷰와의 간격에도 적용(상하좌우 4면에 개별적으로 지정 가능)

padding : 뷰와 내용물간의 간격을 지정(상하좌우 4면에 개별적으로 지정 가능)

레이아웃의 화면방향은 

xml에서 android:orientation="vertical" 이나 "horizontal"로 설정할 수 있다.

일부의 레이아웃이 아니라 앱 자체의 화면을 가로로 하려면 AndroidManifest.xml에 설정을 추가해준다

<activity

...

...

android:screenOrientation="landscape" >