진형아빠이야기


현재의 자료는 2012.01.09일 기준으로 번역한것임을 알려드립니다.
물론 번역 실력은 FOOT MODE로 번역 하였습니다.

안드로이드 기초

안드로이드 애플리케이션은 Java 프로그래밍 언어로 작성된다. 안드로이드 SDK 툴은 데이터와 리소스를 함께 컴파일 하여 하나의 안드로이드 패키지로 묶여지며, 이렇게 하나로 압축된 아카이브 파일에는 .apk접미사가 부쳐진다. 하나의 .apk 파일 안에 있는 모든 코드는 하나의 애플리케이션으로 간주되고 그파일은 안드로이드 디바이스에서 어플리케이션을 설치하는데 사용된다.

디바이스에 인스톨되고 나면 각 안드로이드 어플리케이션은 그 자신의 보안 sandbox에서 존속한다.

  • 안드로이드 OS는 각각의 어플리케이션이 다른유저인멀티유저 리눅스 시스템이다.
  • 기본적으로 시스템은 각각의 어플리케이션에 유니크한 리눅스 유저ID를 할당한다. 시스템은 어플리케이션에서 모든파일은 어플리케이션에 할당된 사용자들만 사용할 수 있도록 권한을 설정한다.
  • 각각의 프로세스는 자기 자신의 Java 가상머신을 가진다. 그러므로 애플리케이션 코드는 다른 모든 애플리케이션 코드와는 격리되어 실행된다.
  • 기본적으로 모든 어플리케이션은 리눅스 프로세스로 동작한다. 안드로이드는 어플리케이션의 컴포넌트가 실행이 되어야 할때 시작하며 종료 프로세스는 다른 어플리케이션을 위해서 메모리를 확보하거나 더이상 필요가 없어질대 프로세스를 종료한다.

이런 식으로 안드로이드 시스템은 the principle of least privilege(최소한의 원칙)을 구현한다. 즉, 각각의 어플리케이션은 기본적으로 작업을 하기 위해 필요한 컴포넌트에만 접근할수 있다. 이것은 응용프로그램이 권한을 부여 받지않은 시스템의 부분에 엑세스할 수 없는 매우 안전한 환경을 만들었다.

그럼에도 불구하고 애플리케이션간의 데이터를 공유할수 있는 몇가지 방법이 있다.

  • 두 개의 애플리케이션에 대해 동일한 유저user ID를 공유할 수 있도록 배치하는 것이 가능하다. 그런 경우에 두 개의 애플리케이션은 각자 다른 애플리케이션의 파일을 볼 수 있을 것이다. 시스템 자원을 절약하기 위해 동일한 ID를 가지는 애플리케이션은 또한 동일한 리눅스 프로세스 안에서 실행되도록 배치되며, 동일한 가상머신을 공유한다.
  • 애플리케이션은 연락처,SMS,Camera등의 데이터에 액세스 할 수 있는 권한을 요청 할 수 있다. 모든 애플리케이션 권한은 사용자의 설치시정에 인증이 된다.
안드로이드 응용 프로그램이 시스템 내에서 어떻게 존재하는지 대한 기본을 다룹니다. 이 문서의 나머지를 소개합니다.
 

  • 애플리케이션을 정의하기 위한 코어 프레임워크 컴포넌트
  • 애플리케이션을 위한 컴포넌트의 선언과 디바이스의 기능을 위한 manifest 파일
  • 애플리케이션 코드와 다양한 장치에서 최적화된 동작을 위한 Resources


애플리케이션 컴포넌트들

애플리케이션 컴포넌트는 안드로이드 애플리케이션의 필수적인 빌딩 블락입니다. 각각의 컴포넌트들은 애플리케이션에서 다른 목적을 가지고 사용되어집니다. 모든 컴포넌트의 실제 진입점은 사용자나 혹은 다른 컴포넌트에 의해서 입니다. 그러나 각각은 자신의 실체로 존재하며 각자의 역할이 있습니다. 각각은 전반적인 동작을 정의하는데 도움을 주는 유니크한 블락입니다.

여기 4가지 종류의 애플리케이션 컴포넌트들이 있습니다. 각각을 종류는 뚜렷한 목적과 어떻게 컴포넌트가 생성되며 소멸되는지에 관한 라이프사이클을 가지고 있습니다.

여기 4가지 종류의 애플리케이션 컴포넌트를 소개합니다.

액티비티
액티비티는 사용자 인터페이스의 한 화면을 나타낸다. 예를 들면 이메일 애플리케이션은 새 메일의 리스트를 보여주는 액티비티를 가질것이다. 다른 액티비티는 이메일을 쓰기 위해서, 다른 액티비티는 읽기 위해서 있다. 액티비티들은 이메일 애플리케이션에서 화합해서 함께 작동하지만, 각각은 다른것들로 부터 독립적이다. 다른 애플리케이션에서 이 액티비티들 중에 하나를 시작시킬수 있다. 예를 들어 이메일 애플리케이션에서 이메일에 사진을 첨부하기 위해서 카메라 애플리케이션을 시작 시킬수 있다.

액티비티는 Activity의 서브 클래스로서 구현이 되며 좀더 자세한 사항은 Activities 개발자 가이드를 참고하라.

서비스
서비스는 백그라운드에서 긴 시간 동안 수행되거나 사용자에게 UI를 제공하지 않는 컴포넌트이다. 사용자가 서비스를 스타트하면 사용자가 다른 어플리케이션을 실행시킨다고 해도 동작하게 된다. 예를 들면 네트워크 전송, 미디어 플레이어, 파일읽기등의 작업들이 있다. 서비스의 start를 위해서 UI가 없으므로 보통 Activity와 결합하여 많이 사용한다. 서비스를 구현하기 위해서는 Service 클래스를 상속한 서브클래스를 만들어야 한다.

콘텐트 프로바이더
Content Provider(이하 CP)는 애플리케이션 데이터의 공유 집합을 관리한다. 데이터를 파일 시스템, SQLite, Web 혹은 다른 persistent한 저장 위치에 있다고 해도 애플리케이션은 접근할수 있다. CP를 통해서 다른 애플리케이션들은 쿼리 또는 데이터를 수정할 수 있다. 예를 들면 안드로이드 시스템은 사용자 연락처 정보를 관리하기 위한 CP를 제공한다. 권한만 있다면 어떠한 애플리케이션이든 특정 사람에 관한 정보를 읽거나 쓰기 위한 CP의 부분을 쿼리 할수 있다.
CP는 또한 공유되지 않는 개인적인 데이터를 읽거나 쓸때 유용하다. 예를 들어 NotePad같은 어플은 데이터를 저장하기 위해서 CP를 사용하면 좋다.
CP는 ContentProvider의 서브클래서로서 구현이 되며 반드시 다른 애플리케이션이 트랜잭션을 수행할수 있도록 하는 APIs의 표준 집합을 구현해야한다. 좀더 자세한 사항은 Content Providers 개발 가이드를 참고하시라.

브로드캐스트 리시버
Broadcast Receiver(이하 BR)은 시스템의 방송을 청취하고 응답하는 컴포넌트이다. 많은 BR은 시스템으로 부터 유래되었다. 예를 들면 화면이 꺼지거나 배터리가 낮아지거나 사진을 찍거나 하는 등의 방송을 알린다. 애플리케이션 방송을 초기화 할수 있다. 예를 들어 다른 애플리케이션이 데이터를 디바이스에 다운받고 그것이 사용가능해짐을 알기 함이다. BR은 사용자 인터페이스에 나타나지는 않지만, 방송이 일어나면 status bar에 노티피케이션의 형태로 사용자에게 알려준다. 대게의 경우 BR은 단지 "gateway"이고 그것은 아주 최소한 만큼의 일만 할것이다. 그것은 이벤트에 기반해서 몇가지 일을 하기 위해서 서비스를 시작할수도 있다.
BR을 구현하기 위해서는 BroadcastReceiver 클래스를 상송한 서브클래스를 만들어야 하며 각각의 방송은 인텐트 오브젝트로서 배달되어질 것이다. 좀더 자세한 사항은 BroadcastReceiver 클래스를 봐라.

안드로이드 시스템의 독특한 점은 어떤 애플리케이션이든지 다른 애플리케이션의 컴포넌트를 시작할수 있다는 것이다. 예를 들어 디바이스 카메라로 사진을 캡춰하려고 할때 사진을 캡춰하는 부분을 개발하는 대신 이미 만들어져있는 다른 애플리케이션의 부분을 사용할수 있다. 일부러 포함할 필요가 없으며 링크조차 필요없다. 대신에 당신은 사진을 캡춰하는 애플리케이션의 액티비티를 스타트 시키면 된다. 작업을 마치고 나면 그 사진은 당신이 사용할수 있도록 당신의 애플리케이션으로 반환 될것이다. 유저들은 그 카메라 기능이 당신 애플리케이션의 부분이라고 생각할 것이다.

시스템이 컴포넌트를 시작할때 그것은 애플리케이션을 위한 프로세스의 시작과 컴포넌트를 위해 필요한 클래스들을 예시할것이다. 예를 들어 만약 당신 애플리케이션이 사진을 찍기 위한 카메라 애플리케이션의 액티비티를 시작한다고 할때 그 액티비티는 당신 애플리케이션의 프로세스가 아니라 카메라 애플리케이션에 속하는 프로세스에서 기동될것이다. 그러므로 다른 애플리케이션과 달리 안드로이드는 하나의 진입점을 가지고 있지 않다.

왜냐하면 시스템은 다른 애플리케이션의 접근을 막는 파일 퍼미션과 함께 분리된 프로세스에서 각각의 애플리케이션이 동작한다. 당신의 애플리케이션은 다른 애플리케이션의 컴포넌트를 직접적으로 활성화시킬수 없다. 그러나 안드로이드 시스템은 가능하다. 다른 애플리케이션의 컴포넌트를 활성화시키기 위해서 당신은 시스템에 지정된 Intent 메세지를 전달해야 한다. 그러면 시스템은 해당 컴포넌트를 활성화 시킬것이다.

컴포넌트 활성화
액티비티, 서비스,BR,CP등의 4가지 구성요소들은 intent라고 불리는 비동기 메세지에 의해서 활성화가 됩니다. Intent는 그 컴포넌트가 당신의 애플리케이션인지 다른 애플리케이션의 것인지 상관없이 런타임시 각각의 컴포넌트를 바인딩한다.

인텐트는 특정 컴포넌트나 컴포넌트의 타입을 활성화를 정의한 메세지를 담고 있는 인텐트 오브젝트를 생성한다. 인텐트는 명시적 인텐트와 암묵적 인텐트가 있다.

액티비티와 서비스를 위해서 인텐트는 수행하기 위한 액션을 정의하고 데이터 URI를 명시합니다. 예를 들면  인텐트는 이미지를 보여주거나 웹페이지를 오픈하기 위해 액티비티에 request를 전달할것 입니다. 몇몇 경우에는 결과를 받아서 액티비티를 시작합니다만 어떤 경우에는  액티비티는 인텐트의 결과를 반환하기도 합니다. (예를 들어 당신이 사용자의 연락처 정보를 가져오고 그것을 당신에게 반환하는것을 허럭하기 위해서 인텐트를 발행할수 잇다. - 반환되는 인텐트는 연락처를 접근하기 위한 URI 지점을 포함한다.)

BR을 위해서 인텐트는 방송알림을 간단히 정의한다.(예를 들어 디바이스 배터리가 낮은것을 알리기 위한 브로캐스트는 "battery is low"라고 하는 액션 문자열을 포함한다.)

다른 컴포넌트 타입들과 CP는 인텐트에 의해서 활성화 되지 않습니다. 이것들은 ContentResolver가 요청한것에 타겟팅되어 활성화 됩니다. Content Resolver는 CP와 함께 컴포넌트가 콘텐트 리졸버 오브젝트에서 메소드를 콜하는것을 대신하거나 필요하지 않도록 수행하는것을 위해 모든 직접적인 트랜잭션들을 처리합니다.
이 추상계층들은 컴포넌트와 CP사이의 보안을 위한 정보 요청을 한다.
여기 각각의 컴포넌트를 activiting하기 위한 몇개의 메소드가 있다.
startActivity() 혹은 startActivityForResult()를 사용하여 Intent를 전달함으로서 액티비티를 기동시킬 수 있다.
startService()로 Intent를 전달해서 시작하거나  bindService()를 통해 서비스를 바인드 시켜서 서비스를 기동시킬 수 있다.
sendBroadcast(), sendOrderedBroadcast(), sendStickyBroadcast()와 같은 메소드를 통해서 Intent를 전달하여 브로드 캐스트를 알릴수 있다.
ContentResolver에서 query()를 호출하여 CP의 쿼리를 수행할수 있다.
인텐트에 관한 좀더 자세한 정보는 Intents and Intent Filters 문서를 참고하라. 컴포넌트를 활성화하는 좀더 자세한 정보가 Activities, Services, BroadcastReceiver, Content Providers에 있다.


매니페스트 파일
애플리케이션을 시작시키기에 앞서 시스템은 AndroidManifest.xml을 통해서 컴포넌트의 존재를 인지해야만 한다. 애플리케이션은 반드시 모든 컴포넌트를 응용프로그램의 ROOT디렉토리에 존재하는 매니페스트 파일에 선언해야한다.
매니페스트가 애플리케이션의 컴포넌트의 선언을 추가하기 위한 몇가지 사항은 다음과 같다.
사용자의 연락처의 접근을 위한 Internet access나 read-access와 같은 애플리케이션에 필요한 어떤 권한들을 확인한다.
어떤 버전의 API를 사용하고 있는지 최소기준의 API 등급을 선언한다.
카메라, 블루투스 서비스, 멀티 스크린과 같은 애플리케이션에 의해서 필요하거나 사용되어지는 하드웨어, 소프트웨어 기능을 선언한다.
구글 맵스 라이브러이와 같은 애플리케이션을 위한 API 라이브러리들에 대응하는 링크가 필요하다.

컴포넌트 선언하기
매니페스트의 주요 업무는 애플리케이션의 컴포넌트를 시스템에 알리는것이다. 예를 들어 매니페스트 파일은 아래와 같이 액티비티를 선언할 수 있다.
<?xml version="1.0" encoding="utf-8"?>
<manifest ... >   
    <application android:icon="@drawable/app_icon.png" ... >       
        <activity android:name="com.example.project.ExampleActivity" android:label="@string/example_label" ... >       
        </activity>    
        ...   
    </application>
</manifest>

<application> 엘리먼트에서 android:icon 어트리뷰트는 애플리케이션을 나타내는 아이콘 리소스의 위치를 나타난다.
<activity> 엘리먼트에서 android:name 어트리뷰트는 사용자가 구현한 Activity subclass의 전체 파일명을 가리키며 android:label 어트리뷰트는 액티비티에서 유저에게 보여지는 string을 나타낸다.

모든 컴포넌트의 반드시 선언해야하는 것은 다음과 같다.
<activity> 엘리먼트는 액티비티
<service> 엘리먼트는 서비스
<receiver> 엘리먼트는 BR
<provider> 엘리먼트는 CP

당신의 코드에 포함되어있지만 매니페스트에 선언되지 않은 액티비티, 서비스, CP등은 시스템은 볼수 없으며 동작하지 않는다. 그러나 BR은 매니페스트 뿐만 아니라 자바코드에서도 동적으로 registerReceiver()을 호출하여 시스템에 등록할수 있다.
매니페스트에 대한 좀더 자세한 정보는 The AndroidManufest.xml file 문서를 보시라.


컴포넌트의 역할 선언
위의 내용에서 보듯 컴포넌트의 활성화에 관해서 논의하였듯이 당신은 액티비티, 서비스, BR을 시작하기 위해서 Intent를 사용할 수 있다. 이제 당신은 인텐트에서 타겟컴포넌트를 명쾌하게 이름지음으로서 사용할수 있다.
그러나 진정한 인텐트의 장점은 인텐트 액션의 컨셉에 있다. 인텐트 액션으로 당신이 수행하고자하는 액션의 종류와 액션을 수행하고 시작하기 위해 디바이스단에서 컴포넌트를 찾아 시스템에게 허가를 받는것을 간단하게 기술할 수 있다.
만약 인텐트에 의해서 수행할수 있는 액션을 기술한 다양한 컴포넌트가 있다면 사용자는 그것을 사용하기 위해서 선택할수 있다.

인텐트에 반응할수 있는 시스템이 컴포넌트들을 확인하는 방법은 디바이스에서 다른 애플리케이션들의 매니페스트파일에서 제공된 인텐트 필터를 받아서 비교함으로서 가능합니다.

매니페스트에 컴포넌트를 선언할때 추가적으로 다른 어플리케이션으로 부터 온 인텐트에 반응하기 위한 컴포넌트의 역할을 선언 하는 인텐트 필터를 포함할수 있습니다.
컴포넌트 선언 엘리면트의 자식 엘리먼트로서 <intent-filter> 엘리먼트의 추가로 애플리케이션의 인텐트 필터를 선언할 수 있습니다.

예를 들어 이메일 애플리케이션의 메일을 작성하기 위한 액티비티는 매니페스트 엔트리에 "send" 인텐트에 반응하는 인텐트 필터가 선어되었을 것이다.
애플리케이션에서 액티비티는 "send" 액션의 인텐트를 생성할수 있고, 시스템은 startActivity()를 포함하는 인텐트를 invoke 할때 알맞는 이메일 애플리케이션의 "send" 액티비티와 launches를 찾을 것이다.
인텐트 필터에 한 좀더 자세한 정보는 Intents and Intent Filters 문서를 보시라.

애플리케이션 필수요소 선언
안드로이드에 인증된 다양한 단말과 그것들 모두가 동일한 성능과 기능을 제공하지는 않는다. 애플리케이션에 필요한 부족한 성능을 가지고 있는 디바이스에 인스톨을 막기위해서, 매니페스트 파일에 소프트웨어 요구수준과 디바이스 종류를 명확하게 기술하는것이 중요하다.
이런 대부분의 선언들은 단순한 정보들이며 시스템은 그것들을 읽을 수 없습니다. 그러나 안드로이드 마켓과 같은 외부 서비스는 디바이스에서 애플리케이션을 할 때 유저를 위해서 필터링을 제공하기 위해서 그것들을 읽을 수 있습니다.

예를 들면 당신이 Android 2.1 API를 사용한 카메라 애플리케이션이 필요하다고 하면, 당신은 이러한 요구사항을 매니페스트에 선언해야 합니다. 즉, 카메라가 없거나 안드로이드 버전이 2.1보다 낮은 기기에서는 안드로이드 마켓에서 설치를 못하도록 할수 있습니다.

그러나 당신은 애플리케이션이 카메라를 사용을 선언할수 있습니다만, 필수적인것은 아닙니다. 이 경우 애플리케이션은 런타임시 해당 기기가 카메라가 있는지 카메라 사용을 위해서 비활성화 된 기능은 없는지등을 체크 합니다.

여기 당신이 애플리케이션을 디자인하고 개발할때 중요한 디바이스에서 중요한 몇몇 키워드들이 있습니다.
Screen size and density
그들의 스크린타입으로 분류하기 위해서 안드로이드는 각각의 디바이스를 위해서 2가지 문자를 정의하고 있다. 스크린 사이즈와 스크린 밀도가 그것이다. 스크린 설정의 모든 다른 종류를 간편화 하기 위해서 안드로이드 시스템은 타겟팅 하기 쉽도록 그룹으로 만들어서 그것들을 일반화하였다. 스크린 사이즈는 small, normal, large, extra large가 있으며 스크린 밀도는 low density, medium density, high density, extra density로 구분하였다. 

기본적으로 애플리케이션은 모든 화면 사이즈와 밀도에 호환이 된다. 왜냐하면 안드로이드 시스템은 UI 레이아웃과 이미지 리소스를 적절하게 수정할 수 있도록 만들어졌다. 그러나 당신은 매니페스트에서 <supports-screens> 엘리먼트를 사용해서 특정 화면 사이즈를 지원하는것을 선언함으로서 대안 레이아웃 리소스를  사용하여 특정 화면 사이즈에 맞는 레이아웃을 만들어야 하며 특정 밀도에 맞는 이미지들을 제공할수 있다.

좀더 자세한 정보는 Supporting Multiple Screen문서를 보라.

Input configurations

많은 디바이스들은 하드웨어 키보드, 트랙볼, 오방향 네비게이션 패드와 같은 많은 다른 종류의 입력 매커니즘을 제공한다. 만약 애플리케이션이 특정한 종류의 입력 하드웨어를 필요로 한다면 매니페스트에서 <uses-configuration> 엘리먼트를 선언해야한다. 그러나 특정 하드웨어를 요구하는 것과 같은 일은 거의 없을 것이다.

Device features

안드로이드 인증 디바이스는 카메라, 조도센서, 블루투스, 특정버전의 OpenGL, 정확한 터치스크린과 같은 존재할수도 있고 존재하지 않을수도 있는 많은 하드웨어 및 소프트웨어 특징이 있다. 모든 안드로이드 인증 디바이스에 특정한 기능이 동작할 거라고 예상해서는 안된다. 그래서 당신은 사용할 몇몇 기능을 위해서 애플리케이션에 <uses-feature> 엘리먼트를 선언해야 한다.

Platform Version

다른 종류의 안드로이드 인증 디바이스는 종종 안드로이드 1.6 이나 안드로이드 2.3과 같은 안드로이드 플랫폼의 다른 버전에서 동작한다. 각각의 성공적인 버전은 추가적인 API를 가지고 있으며 이전 버전에서는 사용할 수 없다. API집합이 유요함을 알리기 위해서 각 플랫폼 버전은 API 레벨을 명시한다. 만약 1.0 버전 이후의 플랫폼에 추가된 API를 사용한다면 당신은 <uses-sdk> 엘리먼트를 사용해서 API를 소개하는 최소 API 레벨을 선언해야한다.


애플리케이션을 위해서 모든 종류의 필수 요소를 선언하는것은 중요하다. 왜냐하면 안드로이드 마켓에 앱을 배포할 때 마켓은 각각의 디바이스에 애플리케이션이 유효한지를 필터하기 위해서 이런 종유의 선언들을 사용한다. 보통 당신 애플리케이션은 당신 애플리케이션의 요구사항에 부합하는 디바이스들에만 유효하게 될것이다.

필수요소를 기반으로 어떻게 안드로이드 마켓이 필터하는지를 좀 더 알기 위해서는 Market Filter 문서를 보라.


애플리케이션 리소스

안드로이드 애플리케이션은 코드 이상으로 구성되어있다. 그것은 이미지, 오디오 파일, 애플리케이션의 화면단과 관련된 것들로 소스코드로 부터 분리된 리소스를 필요로 한다. 예를 들어 애니메이션, 메뉴, 색깔, XML로 구성된 유저인터페이스 액티비티의 레이아웃등이다. 애플리케이션 리소스를 사용하는것은 대안 리소스를 제공함으로서 코드의 수정없이 애플리케이션의 다양한 문자들을 수정하는것을 가능하게 한며 다양한 단말 설정을 위해서 애플리케이션을 최적화하는것을 가능하게 한다.

안드로이드 프로젝트에 있는 모든 리소스들을 위해서 SDK빌드 도구는 애플리케이션 코드나 XML의 다른 리소스들의 참조를 사용할수 있는 유니크한 integer ID를 정의한다. 예를 들어 애플리케이션이 logo.png(/res/drawable 디렉토리에 저장되는)라는 이미지를 포함한다면 SDK 도구는 R.drawable.logo라고 불리는 유저 인터페이스에서 참조하고 사용할 수 있는 리소스 ID를 생성한다.

소스 코드로 부터 리소스 분리 제공의 중요한 면중 하나는 다른 디바이스 설정을 효과적으로 제공한다는 점이다. 예를 들어 XML로 UI string을 정의한다면 당신은 그 strings를 다른 언어로 번역하고 각각 분리된 파일로 저장 할 수 있다. 사용자의 언어 설정과 디렉토리 네임을 덧붙이기만 하여 언어 qualifier의 기초가 된다. 안드로이드 시스템은 당신의 UI에서 적절한 언어를 적용한다.

안드로이드는 대안 리소스를 위해서 많은 식별자들을 지원한다. 그 qualifier는 짧은 string이다. The qualifier is a short string that you include in the name of your resource directories in order to define the device configuration for which those resources should be used. 다른 예로 당신은 디바이스의 스크린 방향이나 사이즈에 따라 액티비티의 다른 레이아웃을 만들어야 합니다. 디바이스가 수직을 향할때는 당신은 버튼들이 수직으로 배치되길 원하지만 화면이 수평으로 위치할때는 버튼은 수평으로 배치되어야 합니다. 방향에 따라서 레이아웃을 변화하기 위해서 당신은 다른 종류의 레이아웃을 정의 하고 각각 레이아웃의 디렉토리 명을 가지는 적절한 식별자를 적용할수 있다. 그후 시스템은 자동적으로 현재 레이아웃의 방향에 따라서 적적한 레이아웃을 적용합니다.

좀더 자세한 정보는 Application Resources 개발자 가이드를 참고하세요.

신고

Comment +0

CT와 MRI, 그 가깝고도 먼 사이
병원에 가 단순히 외래진료 후 처방전을 받아들고 나온다면 큰 걱정은 없는 셈이다. 하지만 ‘정밀검사를 받아보시는 것이 좋겠습니다’라는 의사의 말이 떨어지는 순간, ‘무슨 큰 병이나 걸리지 않았나’하는 생각에 가슴이 콩알만해지기 십상이다. 병원에서는 환자의 상태를 보다 정확히 판단하기 위한 각종 검사들이 존재한다. 그중 우리들의 귀에 가장 친숙한 것이 바로 CT와 MRI. 하지만 이것만큼 우리들을 헛갈리게 하는 것 또한 없다. 알 듯 모를 듯 아리송한 CT와 MRI의 차이를 꼼꼼히 짚어보자.

두 가지의 일그러진 얼굴
병원을 들여다보면 두 가지의 극단적인 모습을 어렵사리 볼 수 있다. 의사가 필요에 의해 CT나 MRI 검사를 권하는데도 불구하고 ‘거, 받아서 뭐해’라는 식으로 검사를 거부하는 사람과 자신은 곧 죽어도 CT나 MRI 검사를 받아야겠다고 보채는 경우가 그것.
이러한 두 가지 풍경은 뭐니뭐니해도 돈에 기인하는 경우가 가장 많다. 즉 검사 자체가 경제적으로 부담이 되는 사람들은 필요한 검사를 거부하게 되고, 반면 상대적으로 여유가 좀 있는 사람들은 불필요한 검사도 하고 싶어한다.

두 번째로는 지나친 ‘건강염려증’이 작용한 탓이다. ‘혹시 병에 걸리지 않았을까’라는 건강에 대한 막연한 염려가 목적에 관계없이 검사를 요구하게 되는 것이다.마지막으로 CT나 MRI 등의 검사가 왜 필요하며, 어떤 경우에 유용한가라는 검사 자체의 진단적 가치나 기능에 대해 제대로 알지 못하기 때문이다. 이 모든 것이 불필요한 검사를 요구하게 되고, 필요한 검사를 거부하는 이유로 볼 수 있다.
그러면 어떠한 경우 CT나 MRI 등의 검사가 필요하며, 이들 검사의 차이에는 어떤 것들이 있을까?

짧은 시간에 비용도 저렴
CT(전산화 단층 촬영)의 출발은 X-Ray에서 시작한다. 물론 컴퓨터를 활용한다는 측면에서 X-Ray보다 한 단계 업그레이드 된 것이지만, CT 검사 또한 X-Ray를 이용한다는 점에서는 같다고 볼 수 있다.

CT 검사는 환자가 도우넛 모양의 기계에 누우면 커다란 X-Ray 튜브가 몸을 한바퀴 돈다. 이때 컴퓨터는 우리 몸을 단면으로 자른 영상을 만들어 낸다. 그리고 각 부위에서 X-Ray가 흡수한 수치의 차이로 질병을 찾아낸다. 이는 무에 바람이 들었는지 여부를 알아보기 위해 무를 단면으로 자르는 것과 같은 이치다. 사람을 X-Ray로 쏘아 컴퓨터로 검사 부위를 단면으로 잘라 숨어있는 질병을 찾는 것이다.

CT 검사는 일반 X-Ray 검사만으로는 뭔가 찜찜한 게 있을 때 시행하는 것이 보통이다. 일반 X-Ray가 한 면만을 찍을 수 있는데 비해 CT는 여러 각도에서 방사선을 쪼여서 그것을 컴퓨터를 통해 종합하여 입체적인 화면을 얻게 된다. X-Ray가 단순히 필름에 투영된 단면의 영상을 제공하는 반면 CT는 2차원이나 3차원으로 재구성할 수 있다는 얘기다.

때문에 CT 검사는 뇌의 이상이나 질병의 위치, 크기, 혈관계질환, 간, 소화기계 등 각각의 장기들을 빠른 시간 내에 광범위하게 검사할 수 있다는 장점을 갖고 있다. 또 CT는 X-Ray에 비해 뼈의 내부구조를 더욱 선명하게 볼 수 있으며, 디스크나 종양 등 연부조직이 신경을 누르는 질병의 관찰이 가능하다. CT는 단순 X-Ray 상에서 볼 수 없는 허리디스크 질병이나 척추관 협착증, 종양과 감염성 질병도 볼 수 있는 검사방법이다.

CT 검사는 MRI 검사와 비교했을 때 상대적으로 몇 가지의 장점을 갖고 있다.
우선 검사시간이 MRI에 비해 비교적 짧다는 것. 1시간 가량 소요되는 MRI의 절반 정도인 30∼45분 정도면 검사가 끝난다. CT 검사는 또 완전 밀폐되지 않은 공간에서 시행되므로 폐쇄공포증 환자의 검사에 용이하며, 척추관 협착증이나 뼈의 질환 같은 경우 MRI에 비해 더욱 선명하고 정확한 결과를 얻을 수 있다.

이밖에 허리뼈에 박혀 있는 금속이 있더라도 자기장의 간섭현상이 없어 촬영이 가능하며, 비용이 약 10만원대로 비교적 저렴하다. 질병이 확인될 경우에는 의료보험의 혜택도 누릴 수 있다. 단, 의사의 처방에 의한 경우가 아니라 개인의 의지에 의한 검사는 제외된다.

종과 횡, 어디든 잘라볼 수 있다
‘자기공명영상촬영’이라는 이름의 MRI는 자석과 수소가 핵심이다. CT가 방사선을 이용하는 것과는 달리 강력한 자기장과 전기장을 이용하는 것이다.

MRI 검사의 원리는 이렇다. 거대한 자석 안에 사람이 누우면 고주파가 나온다. 그러면 몸 속의 수소 분자들은 나란히 줄을 선다. 이처럼 자석의 힘에 따라 이쪽 저쪽 돌아다니며 분주히 줄을 서는 수소의 움직임으로 질병을 찾아내는 것이 바로 MRI 검사의 원리인 것이다.

MRI 검사는 사람 몸에 손끝 하나 대지 않고 몸 속을 3차원으로 속속들이 볼 수 있으며, 뼈나 공기의 영향을 받지 않아 CT 검사나 초음파 검사가 찾지 못하는 질병을 찾아내기도 한다. 횡단면, 종단면으로 세세하게 잘라 보지 않고는 발견하기 힘든 뇌질환이나 뇌혈관질환들이 여기에 해당한다. CT가 종단면을 촬영할 수 없는 것과는 달리 MRI는 종과 횡단면 모두 촬영이 가능해 보다 세밀한 검사가 가능한 것이다. 또 허리 뼈마디를 매우 선명하게 촬영할 수 있을 뿐만 아니라, 근육, 연골, 인대, 혈관 및 신경 등의 연부조직 또한 매우 뚜렷하게 촬영할 수 있다.

이처럼 MRI 검사는 세밀한 검사임에도 불구하고 몸에 어떠한 흔적도 남기지 않는다. 자장을 이용하기 때문에 검사로 인한 통증이나 위험, 불안감이나 불쾌감이 전혀 없으며, 방사선을 사용하지 않기 때문에 부작용이나 유해성에 대한 걱정도 없다.

하지만 MRI 검사를 받기 전에 반드시 주의해야 할 것이 있다. 금속물질이 그것.
검사실이나 준비실 근처에는 큰 자장이 형성되어 있기 때문에 깜빡하고 검사실에 들어갔다가는 소지품이 망가지거나 자석에 달라붙어 고생하기 십상이다. 목걸이, 반지, 귀걸이 등의 귀금속이나 틀니, 머리핀, 안경, 동전, 시계, 신용카드 등은 절대 근처에도 얼씬거리지 말아야 한다.

MRI는 CT에 비해 보다 세밀한 검사가 가능하고 매우 선명한 촬영을 할 수 있다는 등의 장점과는 달리 비용이 많이 든다는 단점을 갖고 있다. 1회 촬영비용이 40만원대로 CT 검사보다 약 3배 가량의 비용이 더 드는 것이다. 또 폐쇄된 공간 속에 들어가야 하므로 CT 검사와는 달리 폐쇄공포증이 있는 환자들은 촬영이 곤란하다. 이밖에 앞에서도 얘기한대로 검사실에는 큰 자기장이 형성되어 있기 때문에 허리에 금속이 들어있거나 심장질환으로 심장박동기를 장착한 사람은 촬영이 불가능하며, 환자가 움직일 경우 촬영이 어려워 약 40분에서 1시간 이상 환자가 꼼짝 못해야 하는 불편함도 있다.


요약 정리들어갑니다.!!!

CT 검사 : X-Ray를 이용해 단면으로 잘라보는 검사
              무를 자르듯 단면으로 잘라 평면의 단면사진만을 보여줌
              CT 검사는 10만원대의 비용이 소요
             
CT 검사는 복부검사에 좋음
MRI 검사: 자장을 이용해 종과 횡 등 여러 방향으로 잘라보는 검사
              종단면, 횡단면 사진을 입체적으로 보여주어 일반인들이 이해하기 쉽게 보여줌
              MRI 검사는 40만원대의 비용이 소요
              
MRI 검사는 뇌신경계, 척추검사에 좋음


마지막으로 ,.
정형외과 환자를 예로 들면 일반적으로 단순한 허리 통증만 있는 경우에는 CT나 MRI와 같은 정밀검사가 필요치 않다. 다만 오랫동안 허리 통증이 지속되거나 다리로 당기는 신경증상이 나타나는 경우 CT나 MRI를 찍어볼 수도 있겠지만 비용문제로 인해 쉽지만은 않은 것이 사실이다. 만일 허리문제로 CT나 MRI를 찍기를 원하고 어떠한 검사가 좋은 것인지 고민한다면 일단 비용과 효과면에서 생각해 봐야 한다.

보통 CT를 통해서도 충분히 디스크 등의 질병을 진단할 수 있기 때문에 증상이 심하게 있는 경우에도 불구하고 CT에서 발견되지 않을 경우 MRI촬영을 시행하는 순서로 검사하는 것이 비용과 효과면에서 유리할 수 있을 것이다.

- 출처 : 미디어 엠
신고

Comment +0

*번역은 마음대로 했습니다. ㅎㅎㅎ

안드로이드는 OS, 미들웨어, 핵심어플을 포함하는 모바일 디바이스를 위한 소프트웨어 스택입니다.
안드로이드 SDK는 JAVA를 사용하는 안드로이드 플랫폼에서 개발하기 위해 필요한 필수적인 tools와 API들을 제공합니다.


기능
어플리케이션 프레임워크
달빅 가상 머신
브라우저
그래픽
SQLite
미디어 서포트
GSM Telephony
블루투스, EDGE, 3G, WIFI
Camera,GPS,compass,accelerometer
강력한 개발환경

안드로이드 아키텍쳐
아래 그림은 안드로이드OS의 주요 구성을 보여줍니다. 각각의 설명은 아래 있습니다.

 


어플리케이션(Application)
안드로이드는 email client, SMS, calendar, maps, browser, contacts등의 필수 어플들을 탑재하였습니다. 모든 어플리케이션은 자바로 만들어집니다.

어플리케이션 프레임워크(Application Framework)
안드로이드 개발환경이 제공함에 따라 안드로이드는 개발자들에게 겁나 쉽고 혁신적으로 어플리케이션을 빌드 할수 있게 해줍니다. 개발자들은 디바이스 하드웨어, location정보의 접근, 백그라운드 서비스, 알람, 노티등의 많은 것들을 자유롭게 사용할수 있는 이점이 있습니다.

개발자들은 핵심 어플리케이션에 의해서 동일한 프레임워크 API에 완벽하게 접근할수 있습니다. 어플리케이션 아키텍트는 컴포넌트를 재사용하기 간단하고, 다른 어플리케이션을 배포할때 기능을 사용하기 쉽도록 설계가 되어있습니다. 이와 같은 매커니즘은 컴포넌트들이 개발자에 의해서 교체되는것을 허용합니다.

아래에 잇는 모든 어플리케이션은 시스템과 서비스의 집합니다.
  • Rich하며 Extendible한 뷰들(리스트, 그리드, 텍스트 박스, 버튼, 임베디드 브라우저)의 set은 어플리케이션을 Build할수 있습니다.
  • Content Provider는 어플리케이션이 다른 어플리케이션이나 그들만의 data를 접근할수 있도록 합니다.
  • Resource Manager는 코드없이 리소스(String,그래픽, 지역화,레이아웃등)에 접근 할수 있게 합니다.
  • Notification Manager는 모든 어플리케이션이 Status Bar에 알림을 할수 있도록 합니다.
  • Acticity Manager는 어플리케이션의 라이프사이클을 관리하고, 공통괸 navigation backstack을 제공합니다.

라이브러리들(Libraries)

안드로이드는 안드로이드 시스템의 다양한 컴포넌트의 사용을 통해서 C/C++등의 라이브러리를 포함합니다. 이러한 기능들은 안드로이드 프레임워크를 통해서 개발자들이 사용할수 있습니다. 핵심적인 몇몇 라이브러리는 아래에 열거 해놓았습니다.

  • System C library
  • Media Libraries
  • Surface Manager
  • LibWebCore
  • SGL
  • 3D libraries
  • Free Type
  • SQLite

안드로이드 런타임(Android Runtime)

안드로이드는 자바프로그래밍 언어의 핵심 라이브러리를 사용할수 있도록 제공하는 핵심 라이브러리 집합을 포함하고 있습니다. 

모든 안드로이드 어플리케이션은 달빅 가상머신의 자신의 인스턴스와 함께 그들만의 프로세스를 실행시킵니다.  달빅은 디바이스들이 다양한 화VMS에서 효과적으로 실행될수 있도록하기 위해서 만들어졌습니다. 달빅 VM은 적은 메모리를 차지하기 위한 최적화된 파일은 Dalvik Executabl format(.dex)의 파일을 실행시킵니다. 가상머신(VM)은 레지스터 기반이며 "dx" tool에 의헤서 .dex파일을 변환하여 자바 컴파일러에 의해서 class들을 기동시킵니다.

달빅 가상머신은 쓰레드처리나 low-memory 관리 와 같은 기능을 위해서 리눅스 커널에 의존합니다.

리눅스 커널(Linux Kernel)
안드로이드는 보안, 메모리 관리, 프로세스 관리, 네트워크 스택, 드라이버 모델 등과 같은 핵심 시스템 서비스를 위해서 리눅스 2.6에 기반합니다. 이 커널은 하드웨어등과 소프트웨어들 스택간의 추상화된 계층으로서 역할을 수행합니다.

신고

Comment +0

티스토리 툴바