Support Library version 4를 이용해서 호환을 함.

NotificationCompat.Builder

5.0 material design의 영향으로 해당 버전에서는 약간 다르다.

Creating a Notification

NotificationCompat.Builder

NotificiationCOmpat.Builder.build() => notification object

NotificationManager.notify() // notification object will be passed to the system by calling that function.

Required notification contents

setSmallIcon() // A small icon 

setContentTitle() // a title

setContentText() // Detail text

그밖에도 많은 options들이 API를 보면 나와 있다.

Notification actions

하나 이상의 action은 반드시 정의 되어함.

특정 activity로 이동하는 action을 의미한다.

두개 이상의 action을 수행하기 위해서는 4.1 이상이 되어야함.

snoozing alarm 또는 send a text 등과 같은 것들이다.

PendingIntent

setContentIntent()

Notification Priority

priority를 통해서 notification이 언제 어떻게 보일지를 설정 할 수 있다.

NotificationCompat.Builder.setPriority()

PRIORITY_MIN (-2)

PRIORITY_MAX (2)

PRIORITY_DEFAULT (0)

Creating a simple notification

눌렀을 때 어떤 activity가 실행 되는 간단한 코드는 아래와 같다.

TaskStackBuilder는 간단히 PendingIntent를 생성 하는 것이다.

NotificationCompat.Builder mBuilder =
        new NotificationCompat.Builder(this)
        .setSmallIcon(R.drawable.notification_icon)
        .setContentTitle("My notification")
        .setContentText("Hello World!");

// Creates an explicit intent for an Activity in your app
Intent resultIntent = new Intent(this, ResultActivity.class);

// The stack builder object will contain an artificial back stack for the
// started Activity.
// This ensures that navigating backward from the Activity leads out of
// your application to the Home screen.
TaskStackBuilder stackBuilder = TaskStackBuilder.create(this);

// Adds the back stack for the Intent (but not the Intent itself)
stackBuilder.addParentStack(ResultActivity.class);

// Adds the Intent that starts the Activity to the top of the stack
stackBuilder.addNextIntent(resultIntent);
PendingIntent resultPendingIntent =
        stackBuilder.getPendingIntent(
            0,
            PendingIntent.FLAG_UPDATE_CURRENT
        );
mBuilder.setContentIntent(resultPendingIntent);
NotificationManager mNotificationManager =
    (NotificationManager) getSystemService(Context.NOTIFICATION_SERVICE);
// mId allows you to update the notification later on.

mNotificationManager.notify(mId, mBuilder.build());

1) 간단히 object를 생성

2) 눌렀을 때 시작되는 intent를 생성

3) Back forward 했을때 문제를 막기 위해서 home screen을 보장하는 intent를 생성

4) 시스템에 등록

5) notify를 통해서 최종적으로 시스템에 등록

Applying an expanded layout to a notification

4.1 이상에서만 지원

Handling Compatibility

파편화로 인해서 당연히 이러한 부분도 고려를 해야함.

Managing Notifications 

2015년 5월 29일 한국시간으로 새벽 1시 30분에 열린 Google I/O 2015의 Keynote에서 등장한 주요 내용을 다루도록 한다.

이번 구글 I/O 2015에서 다루는 것은 크게 두가지이다.

첫 번째는 어떻게 구글이 컴퓨팅 플랫폼과 모바일을 혁신하는지에 대한 것과

어떻게 구글이 모바일 사용자 경험(UX)를 혁신 하는지에 대한 것이다.

Android M Preview

안드로이드 M은 다시 기본으로 돌아가서, Policy와 safety 그리고 Quality에 그 초점을 맞춘다.

작년에 출시된 안드로이드 L의 경우 많은 변화를 가져왔지만, 안드로이드 M은 그러한 큰 변화는 없다.

안드로이드 M의 발표자는 아래와 같다.

안드로이드 M의 변화는 아래와 같다.

App Permissions

기존의 permission들을 몇개의 중요한 케테고리로 통합함으로써 사용자들의 이해를 높였다.

설치할 때 permission을 물어 보는것이 아닌 실행 할 때 permission을 물어보게 만들었다.

또한 App permission을 App별로 다시 재조정할 수 있게 되었다.

한층더 보안을 신경 썻다고 할 수 있다. 

Web Experience

웹 앱을 개발자가 개발하려고 할 때 선택할 수 있는 옵션은 크게 두가지였다.

첫 번째는 Browser를 이용해서 앱을 실행 하는 것이고 두 번째는 Web View 를 이용하는 것이다,

두 번째는 Web View를 이용하는 것이다.

하지만 이제 새롭게 나온 방법인 Chrome custom taps을 이용하면 된다.

이것을 이용해서 ahead of time에 prefetch하는 작업을 할 수 있다.

통합 디자인을 설계할 수 있게 된다.

App Links 

앱을 실행해서 다른 앱과 연결을 하려고 할때 이제 선택을 하지 않고도 자동으로 연결 되어지게 할 수 있다.

개발자가 특별히 설정을 해주면 사용자의 선택 없이도 자동으로 연결 되어 진다.

Mobile Payments

To pay in store, users can do using NFC.

No need to lunch certain app.

Can use debit card or credit card.

700 hundred stores.

결제를 인증하기 위해서 사용자의 지문이 사용 될 수 있다.

온라인 구매에서도 사용자의 지문이 사용 될 수 있다.

이것으 매우 편리하며 간단하게 결제를 진행 할 수 있게 해준다.

단순히 스마트폰의 잠금화면을 푸는것을 이용해서 결제를 진행 할 수 있게 되기 때문이다.

안드로이드는 Doze라고 불리우는 새로운 파워 메니지먼트 시스템을 도입 했다.

해당 기능은 사용자의 패턴을 사용해서 최적화를 진행 하게 된다. 

예를 들면, 사용자는 항상 테블릿을 영화나 책을 읽이 위해서 저녁에만 사용 했다고 하자.

이럴경우 사용패턴을 인지해서 네트웍 전력소비를 강하게 제한 할 수 있다.

아래는 데이터 동기화 화면이다.

사용이 발생 되어지지않는 저녁 시간에는 주기적으로 발생하는 동기화를 극히 제한하게 된다.

이를통해서 전력소비를 그렇기 않을때 보다 실험결과 2배까지 절약했다고 한다.

충전 기술의 경우 구글은 USB type C charger를 도입 했다.

이를 통해서 좀 더 빠른 충전을 달성 할 수 있다.

약간의 사용자 편의성 향상

Easy word selection and Floating clipboard toolbar

Direct share 기능

Simplified volume controls

Android Wear

Android Wear의 발표자는 아래와 같다.

최근 일년간 안드로이드 웨어는 아래와 같이

4개의 OS와 7개의 웨어 제품군을 출시해 왔다.

상호작용 기능의 향상

Android Wear의 기능향상의 초점은 Phone과의 상호작용 기능 향상이다.

이중 가장 흥미로웠던 것은 Emoji recognizer로써 그림을 그려서 메시지를 응답하는 기능이었다.

다양한 센서들의 활용

안드로이드 웨어기기에 작창된 센서의 종류는 계속해서 늘어나고 있다.

아래의 그림과 같이 많은 센서들이 현재 장착된 상황이다.

이러한 센서 데이터를 이용해서 사용자들의 행동을 인지하게 된다.

즉 걷기, 달리기, 자전거 타기, 팔굽혀펴기, 골프 스윙 등을 인지 하게 된다.

Google Fit 앱의 운동정보 인지 내용

팔의 가속도를 인지해서 골프 스윙을 알아냄.

그 밖에도 스마트홈의 집 온도 인지

노래 재생

노래 가사 인식을 통한 음악 이름 알아내기

자동차 주행거리 파악 등이 있다.

현재 마켓에 등록된 웨어러블 앱은 4,000개 이상

Google의 Internet of Things

구글에서도 IoT를 장학하기위한 전략을 발표 했다.

그들이 생각하는 중점은 User Experience, Communications, Operating System 이렇게 3가지 이다.

Operating System

구글은 이를 위해서 Brillo라는 새로운 OS project를 발표 했다.

Communication

Google은 Cross Platform에서 개발자들이 편하게 앱을 개발할 수 있는 API를 제공한다.

이 프로젝트의 이름은 WEAVE 이다.

User Experience

사용자들은 여러개의 장치에서 하나의 UX를 경험 할 수 있다.

이를 위해서 Brillo와 WEAVE가 사용된다. 이 둘을 이용해서 마치 하나의 장치를 쓰는것과 같은 경험을 할 수 있게 된다.

Brillo와 Weave는 각각 아래와 같이 공개 된다고 한다.

User Experience의 통합 

Android wearable 2.0이 출시 되었다.

스마트 가젯 기기를 사용해 보기위해서

LG 어베인을 구입 했다.

약 2주간 사용해본 경험을 이야기 하겠다. 

스마트 시계의 종류 (2015.5월 기준)

• LG G watch
• LG G watch R (세계최초 원형 디자인)
• LG G watch Urbane (필자가 구매)
• LG G watch Urbane lte
• Sony Smartwatch 3
• Asus ZenWatch 
• Motorola Moto 360
• Samsung Gear Live

• Apple Watch

이렇게 많은것들 중 urbane을 선택한 이유는 아래와 같다.

1) Android Wear 탑제

삼성과 LG의 경우 자체적인 OS를 탑제하는 경향이 있다.

삼성은 타이젠을, LG는 LG Wearable Platform을 탑제 한다.

하지만, 이것은 좋지 않다. 앱도 많이 없고 해당 플랫폼이 활성화 될수는 없다.

2) 디자인

현재까지 나온 스마트 워치중에서 가장 시계다우며 디자인이 이쁘다.

3) LTE를 고르지 않은 이유

월 11,000원 내고 전화기를 2대 들고 다니고 싶지 않다.

LTE 탑제는 발열 문제를 야기 시킨다.

배터리가 410mAh -> 710mAh로 늘어나면서 무거워 졌다.

Android Wear가 아닌 LG Wearable Platform을 쓴다 (가장 안좋은 이유).

제품 가격이 비싸다.

Watch의 쓰임

TED에서 구글 공동창업자인 세르게이 브린과 Google I/O 2014에서 선더 피차이 수석 부사장이 이미 웨어러블 기기의 철학을 이야기 했었다.

스마트 시계와 안경의 근본적인 철학은 사용자들이 더이상 스마트폰을 처다보며 인생을 낭비하지 않게 하기 위함이다.

우리는 눈앞에 친구와 연인 가족이 있음에도 의미 없는 유리조각 따위를 습관적으로 문지르며 소중한 시간을 놓치고 있다. 

이러한 행동을 바꾸기 위해서 

언제든지 필요하다면 즉각적으로 몸에 부착되어서 알림이 오는 웨어러블 기기의 쓰임을 강조 했다.

아래의 그림은 Google I/O 2014 Keynote에서 사용된 자료이다.

보통 스마트폰을 사용했을 때 알림이 오면, 사람들은 폰을 보고 그상황에서 폰을 보는 지속시간을 나타낸다.

빈도는 적지만 일단 폰을 보게되면 실제 삶과 단절되는 시간이 길어진다.

하지만 웨어러블 기기를 사용하게 되면 빈도는 늘어나지만 짧게 확인하고 바로 현실로 돌아 오게 된다.

웨어러블 기기의 쓰임과 철학은 바로 이것이다.

더 즉각적으로 가상세계와 연결되며 좀 더 실제 삶을 살가게 하는것.

실제 사용 경험

일단 필자는 지샥 전자시계를 항상 차고 다녀서 항상 막강한 기능의 시계를 갈망 했었다.

따라서 만족 한다.

아래는 필자가 사용하는 시계 화면이다.

실제로 마켓에는 N가지의 시계 배경들이 있고 모두 멋진화면을 제공한다.

아래의 앱은 InstaWeather라는 앱이다.

첫번째 화면은 행동이 없을때 Ambient Mode로 저전력 상태에서 보여주는 화면이고

두번째 화면은 팔을 움직였을때의 Active Mode일 떄의 화면이다.

보여주느 정보는 아래와 같다.

• 시간별 날씨
• 시계 배터리
• 폰 배터리
• 지역

그밖에 좋은 어플은

Audio Recorder: 음성 메모

Sleep: 수면 상태 분석

Wear Aware: 스마트폰과 멀어지면 자동 알림 (폰불실 방지)

Google Fit: 운동 상태 체크, 걸음수, 심장박동 (BPM), 활동량 등

단점

솔직히 말하면 아래와 같은 단점이 있다.

정신 사납다

앞서서 철학이 실제 삶에 더 충실하게 만들어 준다고 했지만

사실 시계를 참으로써 기존에는 인지 하지 않았던 수많은 Notification들을 인지하게 된다.

매번 스팸 처리하지만 계속해서 새로운 것들이 Vibration를 통해서 알림이 온다.

그렇다고 아에 Mute 모드로 쓰게 되면 기존에 스마트폰만 쓸때와 다를께 없게 된다.

철학은 사람들을 distract 하게 하지 않는 것이지만 

실제로 쓰면 스마트폰만 쓸때 보다 더 실제 삶과 단절 된다. 

시계가 가지는 사획적인 의미

사실 시계를 처다본다는 것은 스마트폰을 처다보는것과는 다른 사회적인 압박이 있다.

바로 회의중에 시계를 자꾸 처다보면 발표자로 하여금 발표를 빨리 끝내라는 뉘양스를 주게 된다.

실제로 회의중에 쓸때없는 스팸으로 시계를 몇번 쳐다 보았다가 발표자가 말을 빨리 했고 그결과 회의가 더 빨리 끝나는 경험을 했다.

즉, 시계를 자주 보는것은 타인에게 그다지 좋은 영향을 주지 않는다.

스마트폰 배터리 소모

스마트 시계는 항상 스마트폰과 페어링(동기화) 된 상태에서 동작한다.

따라서 스마트 시계를 쓰면 스마트폰이 배터리가 더 소모되는 기이한 경험을 한다.

실제로 멀티미터기로 전류소모를 측정해본결과

Bluetooth 4.0과 Processor에 의해서 소모되는 에너지소모는 무시할 수 없었다.

더욱이 먼거리에서 Wi-Fi로 두 장치가 페어링 된다면 더 에너지소모가 가중 된다.

요즘들어서 삼성도 일체형 배터리로 갤럭시 s6 출시하면서 일체형 배터리의 강세가 이어지고 있다.

딱 봐도 불편해 보이는 embedded battery (non-removable battery) 왜, 어째서 제조사들은 이것을 채택 하는 것일 까? 

그 장점에 대해서 알아보자.

교체형 배터리의 장점 (Advantage of removable battery)

1) 배터리 교체가능

2) wear-out (마모) 즉, degradation 됬을때 쉽게 교체 가능

3) freezing 되었을 때 배터리 제거를 통해 쉽게 reset 가능.

일체형 배터리의 장점 (Advantage of embedded battery)

1) 디자인과 공간의 절약

배터리에 분리막과 커버를 제거할 수 있다. 또한 connector도 필요 없다. 

이러한 부가적인 요소들의 제거는 제품의 디자인 향상에 매우 큰 도음을 준다.

아래의 그림은 직접 Nexus 5를 Teardwon 해서 배터리 커버를 확인한 결과이다.

아래와같이 Kapton Film으로 제작된 커넥터로 스마트폰 기판과 직접 연결된다. 

그리고 보호 compartment도 없다

추가로 배터리 교체가 없기 때문에 스마트폰의 소재를 다양하게 가져갈 수 있다.

즉 플라스틱과 같이 탄성이 좋지 않으면 교체형 배터리의경우 사용할 수 없다. 왜냐하면 커버를 자주 열면 금속 소재는 금방 휘기 때문이다. 디자인과 공간 절약 면에서 일체형 배터리를 많이 선호하게 된다.

2) 환경보호

배터리는 서비스센터에서 대부분 교체되므로 적절히 분리수거 된다.

또한 무분별한 배터리 교체를 억제함으로써 적은수의 배터리 사용을 유도한다.

3) 배터리 용량 추정의 정확도 향상 (배터리 용량 지시자의 성능향상)

배터리를 하나만 쓰기 때문에 embedded fuel gauge의 성능이 좋다. 

항상 하나의 배터리와 동기화 되기 때문이다.

배터리를 교체 했을때, 노화를 고려해서 게이지를 설정하는것은 Challenge이다. 

매번 Calibration을 새로 해줄 필요가 없다.

4) 안전성이 높은 배터리의 사용 

중국발 저가 배터리 사용을 어느정도 소비자가 하기 어렵기 때문에 저품질 배터리가 사용될 가능성이 적다. 

따라서 안전성이 올라간다고 한다.

참고사이트: http://shadowgadgetreview.blogspot.kr/2012/10/sentiments-about-trending-embedded.html

앱 개발을 위해서 이제는 Android Studio를 사용 해야함.

Android Studio의 장점을 요약하면 아래와 같다.

1) interface design 지원이 강력하다.

2) Build 시스템을 Gradle로 변경 했다.

이부분이 문제이다. 많은 것들이 Gradle에 걸려있기 떄문에, Eclipse를 사용할 때와 다르게 Gradle을 새로 배워야 한다.

요즘 뜨는 강력한 Build 도구라고 하니 이참에 배워야 할것 같다.

단축키 모음

실행 , 환경설정

- Ctrl + Alt + S : 환경설정

- shift + F10 : Build & Run

찾기 관련 

- Ctrl + Shift + N : 전체 검색

- Ctrl + Alt + L : 정렬

- Shift * 2 (Shift 2번) : 전체 찾기

변경, 삽입, 삭제

- Shift + F6 : 태그 동시 변경 (빨간 네모)

- Ctrl + y : 한줄 삭제

- Alt + i : getter, setter 삽입

- Ctrl + i : 인터페이스 

- Ctrl + o : 메소드 오버라이딩

주석, 정렬

- Ctrl + / : 주석

- Ctrl + Alt + L : 코드라인 정렬

이동 

- Alt + 1,6,7 : 익스플로어, 로그켓

- Alt + 좌,우 : 탭 이동

- Ctrl + b : 선언부로 이동

디버그

- Shift + F9 : 디버그 모드

- Ctrl + F2 : 디버그 모드 종료

- F9 : 다음 중단점 까지 실행

- F7 : 멈춘 라인에 메소드 속으로 들어감

- F8 : 한줄만 실행

- Alt + F9 : 커서 있는 곳까지 실행

- Ctrl + Alt + F9 : 강제로 커서까지 실행

- Ctrl + Shift + F8 : 설치된 중단점 모두 보기 

사용하지 않는 Import 정리 

- Ctrl + Alt + o

자동 완성 / 수정 

- Alt + Enter

이름 바꾸기

- Shift + F6

코드 정렬

- Ctrl + Alt + L

메소드 오버라이드(Override method)

- 상위 클래스 내에 잇는 오버라이드 가능한 메소드의 목록 보여주고, 

 선택한 항목을 자동으로 코드에 추가한다. 

- Ctrl + O 

인터페이스 구현 

- Ctrl + I

문서보기 

- F1

매개변수 정보

- Ctrl + P

선언부로 이동

- Ctrl + B

통합검색

- Shift + Shift (Double Shift) 

참고사이트

http://www.developerphil.com/android-studio-tips-tricks-moving-around/

IntelliJ IDEA shortcut manual 

Custom ROM에는 GAPPS이라고 알려진 Google 관련 응용프로그램들이 포함되어 있지 않다.

이러한 Google에서 개발한 App들은 GAPPS이라 불리우는 zip파일 형태의 묶음으로 설치 할 수 있다.

편하게 설치하기 위해서 CWM과 같은 Custom recovery 모드가 있으면 편하다.

1단계: CWN과 GAPPS 다운 받기

PA gapps for android 5.1.x Lollipop Link

ROM Manager (CWM) Link

Gapps의 경우 여러 버전이 있지만, 통상 모든 Google service app들이 포함 되어있는 Stock 버전을 받는다.

아래 표를 참조해서 각각의 차이점을 숙지 하자.

2단계 설치하기

우선 다운받은 Gapps.zip파일을 phone의 외장 메모리에 넣는다.

그다음 CWM (Custom recvoery 설치)을 설치 한다.

정상적으로 CWM recovery mode로 진입하면

볼룸 업 다운키로 gapps.zip 파일을 찾아간다음 설치한다.

그다음 재부팅을 하면 정상적으로 Google app들이 바탕화면에 있는것을 볼 수 있다.

기본 특성

우선 Lithium-ion battery의 특성에 대해서 간단히 알아보자.

Nickel-cadmiu과 다르게 memory effect가 없다.

언제든지 충전해도 상관 없다. 정말 그런것일까? 논문과 책을 통해서 검증 해보자.

리튬이온 배터리의 수명은 300~500회 충방전 사이클이라고 한다.

그 이상이되면 기존 용량대비 40% 정도를 잃어버리고 업계에서는 그 지점을 폐기해야할 배터리 시점으로 본다.

하지만 이 충방전 사이클이라는 것을 정확히 정의하기란 쉽지 않다. 왜냐면 일상생활에서의 충방전의 깊이는 모두 다르기 때문이다.

즉, 10%쓰고 충전한 것을 1사이클로 볼 것인가? 아니면 100%까지 다 쓰고 충전한 것을 1 사이클로 볼 것인가?

대부분 100%까지 다쓰고 충전한것을 충방전 사이클로 본다. 정확하지 않겠지만 10%씩 10번 충방전하면 1번의 충방전 사이클로 다룬다.

그렇다면, 어느 정도 까지 쓰고 충전해야 좋은 것일까? 그 부분에 대해서도 데이터를 가지고 확실히 다루겠다.

Lithum-ion의 분명한 단점은 아래와 같다.

폭발 위험이 크다. 그나마 요즘은 구멍이 좀 생겨도 터지지는 않는다. 하지만 구멍난 상태에서 전원을 인가하면 화제가 발생한다.

사용하지 않아도 노화가 발생한다[1]. 따라서 배터리 구입할 때 제조년과 월을 꼭 확인하자. 새제품이라고 하여도 오래된것은 노화된 것이다.

출력이 방전 패턴과 온도와 같은 물리적 요소에 많이 의존적이다[1].

노화를 발생시키는 요소는 크게 4가지이다.

T: Temperature

DCR: Discharge Current Rate

CV: Charge Voltage

DOD: Depth of Discharge

결국.

$$CycleLife (ShelfLife) = F(T, DCR, CV, DOD)$$

라는 공식이 나오게 된다.

아래글을 간단히 요약해서 리튬이온 배터리 특성에 맞춘 적절한 사용 방법은 아래와 같다.

1) 조금만 쓰고 바로바로 충전해라. 깊게 쓰고 충전하는것은 안좋다.

2) 온도에 매우 민감하니 20~30도 사이에서 쓰는것이 적당하다.

3) 방전률이 높으면 안좋으니, 갑자기 스마트폰을 full 가동 시키는것은 좋지않다. 

4) 방전을 요동치며 하면 좋지 않으니, 가급적 일정하게 사용해라.

5) 100% 충전된 상태에서 스마트폰을 충전기에 꽂고 있어도 대기전력 낭비 이외에는 큰 문제는 없다.

6) 스마트폰을 충전기에 꽂고 쓰는 상태가 배터리 노화 예방에 더 좋다.

7) 리튬이온 배터리는 쓰지 않아도 노화가 발생하니, 아끼지말고 쓰자.

방전 사이클당 리튬이온 배터리의 노화정도[2]

11개의 Li-polymer 배터리 1500mAh의 배터리에 대해서 실험했다.

실험과정

1) 1C/4.2v로 풀충전

2) 0.05C로 포화 충전

3) 1C/3.0V로 방전하며, Depth of Discharge(DoD)는 100% 이다.

4) 위 과정을 반복 했다.

관찰점

방전 사이클이 0인 지점에도 Cadex C7400 배터리 분석기로 분석한 결과 초기 Capacity는 88~94%를 가지는 것을 알 수 있다. 100%가 아니다.

그리고 이것이 250번 사이클 반복할 경우 73~84%까지 용량이 줄어듬을 알 수 있다.

DOD 100%가 아닌, 좀더 낮은 DoD를 수행할 경우 배터리 수명(shelf life)는 늘어 난다.

DOD의 영향은 아래에서 더 자세히 다루겠다.

온도와 방전 전압에 따른 노화 정도 분석[1,2]

아래 그림과 같이 온도가 20도이고 방전 전압이 4.1v 일때가 기간에 따른 노화정도가 가장 적었다.

즉, Li-ion은 좀 더 낮은 전압과 온도에서 사용성이 좋은것을 알 수 있다.

각각의 온도에서 방치했을 경우, capacity loss가 아래와 같이 발생 한다.

즉 배터리가 높은 온도에 있는 상태에서 충방전을 장시간 반복할경우 기본적인 충방전일때 보다 스트레스를 더 많이 받아서 노화가 심하게 잃어 나게 된다.

방전 전류량(C-rate) 및 패턴에 따른 노화 (Discharge Current Rate)[3,4]

xOver-discharge를 허용하지 않는다.

모두 충전했다가 방전하는 것을 Discharge/Charge cycle이라 한다.

제조사는 80%만 방전하고 20%는 남겨 놓는 것을 선호 하나.

There are no standard definitions to define what constitutes a discharge cycle. 

Smart battery에서는 70% 이상의 DOD 만을 cycle count로 고려한다.

아래의 그래프와 같이, 2C로 땡기면 3.2Ah 중에서 2.3Ah만 사용이 가능하게 된다.

아래의 그래프는 journal of power source[4]에서 인용한 것이다.

다음 실험은 일정한 방전과 pulsed 방전과의 관계를 따져본 실험이다.

충전 전압과 노화와의 관계 (charge voltage)[1,4]

아래 그래프는 방전 cycle에 따른 노화정도를 나타낸것이다.

같은 전압과 전류로 같은 횟수 만큼 방전을 수행해도 

더 높은 전압으로 충전할경우 노화가 빨리 진행 되는 것을 알 수 있다.

아래와 같이 충전 전압을 서로 다르게 했을 때의 충방전 사이클의 감소를 볼 수 있다.

충전 전압이 높을 경우 더 적은 수의 충방전 사이클로도 노화의 기준인 70% 용량에 도달하는 것을 알 수 있다.

재미있는 사실은 고전압일 수록 용량 충전률이 높은것을 알 수 있다.

저전압이면 수명은 늘어나지만, 완전 충전이 안되는 것을 알 수 있다.

충방전 사이클에 따른 용량 감소를 그래프로 표기한 것이다. 해당 그래프는 journal of Power Source 논문에서 인용된 것이다[4].

결국 충전 전압은 노화에 매우 중요한 요소이며, 안전성에도 매우 중요한 요인이다.

따라서 배터리 팩에는 반드시 관전압 방지 MOSFET이 들어 있다.

스마트폰 같은경우 TI나 Qualcomm사에서 PMIC 칩을 만들어서 스마트폰에서 과전압을 방지한다. 거의 나노레벨에서 차단이 된다고 하니 걱정은 없다.

스마트폰과 같이 배터리가 상대적으로 저렴하고 교체가 용이한 장치는 고전압으로 충전해서 용량을 100%까지 맞춘다.

하지만, Satellite(인공위성) 그리고 전기 자동차의 경우 longevity가 훨씬 더 중요하다. 따라서 완전 충전은 못하더라도 수명을 늘릴수 있는 저전압으로 충전을 수행하게 된다.

충전 전류와 노화외의 관계 [4]

충전 전류를 서로 다르게 했을 때의 노화 정도를 나타낸 것이다.

1C의 의미는 1시간동안 100% 방전 했다는 의미 이다.

방전 깊이와 노화와의 관계 (Depth of Discharge)[1]

최대한 깊이 방전하는 것을 피하는것이 절대적으로 배터리 노화를 막는다.

아래 실험은 서로 다른 DoD 레벨로 수행한 실험이다.

서로 다른 DoD 레벨로 방전을 시키고 

어느 정도 충방전 사이클을 반복해야 용량이 70%에 도달하는지를 조사 했다. 

충전 전압, 온도, 방전 전류의 양은 모두 평균적으로 같게 만들었다.

실험 결과대로 DoD가 낮으면 낮을 수록 새배터리 용량 대비 70%까지의 Capacity에 도달하게 하는

충방전 사이클이 커지는것을 알 수 있다.

따라서,100%DoD는 오로지 소프트웨어적인 배터리 잔존 용량 예측 향상을 위한 Calibration을 위해서만 수행한다.

즉, 더 정확한 배터리 눈끔을 보장하기 위함이다. 한달에 1번 정도면 충분하다.

그외에는 Partial discharge가 배터리 수명 연장을 위해서 절대적으로 좋다.

충전 깊이와 노화와의 관계 (Shallow Charge)[5]

결론 부터 말하면, 살짝 살짝 충전한다고해서 급격하게 Capacity Degradation이 발생하지 않는다.

약간의 구조상의 전기적 변화가 있겠지만, 이러한 문제는 거의 미미 하다고 할 수 있다.

찔금 찔금 충전해도 상관 없다는 말이 되겠다.

구지 매번 풀 차징을 하지 않아도 된다.

기타

과충전의 위험

일단 거의 없다.

TI 사의 PMIC 칩 Datasheet 설명에 따르면 75nA로 차단된다고 한다.

보호회로가 이중으로 되어있는 스마트폰의 경우 완충되도 충전기를 꽂는 다고해서 문제될것은 없다.

대기전력 문제

이부분은 확실히 있다.

스마트 플러그와같이 완전 대기전력 차단 플러그를 사용하지 않는 이상 대기전력을 발생한다.

로렌스 버클리 랩에 의하면 대기전력을 충전중 전력 소모의 60%를 차지 한다고 한다. 무시못할 양이다.

하지만 이쪽도 연구가 오래 진행 되었으니 조사하면 답은 분명히 엄청 많을 것이다.

참고 문헌

[1] Battery Power Management for Portable Devices, Yevgen Barsukov, Jinrong Qian, BOOK.

[2] Battery University: How to Prolong Lithium-based Batteries

[3] Battery University Basics About Discharging

[4] [J. of Power Source, IF:5.2, 8/83] Factors that affect cycle-life and possible degradation mechanisms of a Li-ion cell based on LiCoO2, Samsung SDI

Battery Current 정보를 알아내는 위치

Nexus 4의 경우 Qualcomm PM 8921 

Nexus 5의 경우 Qualcomm PM 8941

Nexus 5x의 경우 Qualcomm PMI8994 Power Management IC (Also found in LG G4, HTC One M9, and OnePlus Two)

https://www.ifixit.com/Teardown/Nexus+5X+Teardown/51318

위 두개의 Internal Charge Controller Circuit이 존재하기 떄문에

Linux Kernel을 통해서 Current drain 정보 획득이 가능 하다.

획득된 정보의 단위는 mA 이다.

양수면 충전 중이고

음수면 방전 중이다.

아래의 오픈 소스 앱을 이용해도 대고

코드를 분석하면 앱도 만들 수 있다.

https://code.google.com/p/currentwidget/

Stack over flow 사이트

http://stackoverflow.com/questions/2439619/getting-the-battery-current-values-for-the-android-phone

GPU 정보

1. 언어 업데이트

System Setting -> Language Support -> 언어 업데이트

언어 업데이트를 통해서 Korean을 설치 해야함.

버그가 있으니, 'Install / Remove Languages.." 를 여러번 해준다.

2. ibus-setup

콘솔 창에 아래 명령어를 타이핑 한다.

Select an Input method 을 선택해서 한글을 선택해 준다.

요가소  Hangul 이라는 iBus를 선택 해야한다. 다른것은 잘 안된다.

3. 단축키 설정

System Setting에서 Text Entry 유틸을 실행 한다.

여기서 플러스 버튼으로 한글을 추가해주고

그리고 단축키를 설정해준다.

나는 보통 코드 자동 완성 기능 때문에

Shift + Space 를 선호 한다.

4. 입력 테스트

아래와 같이 정상적으로 태극기 모양으로 변경 되면서, 한글이 입력되는 것을 볼 수 있다.

잘 변경이 안된다면, 16.04 부터는 아래와 같이 상단 입력기가 ibus-hangle로 변경 시킨 상태에서 

한글과 영문이 변경 될 수도 있다.

참고사이트

http://ngee.tistory.com/326 

1. 환경설정

Ubuntu 14.04

sudo apt-get install bison g++-multilib git gperf libxml2-utils make zlib1g-dev:i386 zip

2. 소스코드 다운 받기

android-5.1.0_r3 (LMY47I) 가 Nexus 5용 최신 branch 이다.

option 'j'의 의미는 동시에 받는 저장소의 갯수이다. 네트웍 환경에따라 늘릴수 있다.

3. 저작권 있는 바이너리 획득

Google Binaries for Nexus series 

위 사이트에서 LM471용을 다운 받았다.

각자 알맞게 다운 받는다.

AOSP root 디렉터리에 받은 3개의 파일을 압축 풀어 준다.

각각을 실행 하면 저작권 메시지가 나온다.

I ACCEPT를 타이핑하면 아래와 같이 정상적으로 제조사별 드라이버 파일들이 추출 되는것을 알 수 있다.

남은 2개의 .sh 파일에 대해서도 모두 같은 작업을 수행 한다.

4. 빌드

빌드 스크립트를 읽어 온다.

어떤 타입으로 빌드 할지를 선택 한다.

최종적인 빌드 성공시 나오는 결과는 아래와 같다.

4. Flash

Smartphone 상태 변경

bootloader 상태로 이동 시킨다.

OEM Unlock 상태여야 한다.

이동

전부다 업로드 할 것이라면 아래 명령어를 이용 한다.

정상적으로 성공하면 아래와 같은 메시지를 볼 수 있다.

기타 정보

fastboot의 위치

AOSP의 아래에 있다.

out/host/linux-x86/bin

Android Build system은 그 어떤 전통적인 Build System과도 닮아 있지 않다.

이렇게 거대한 Open source Project는 존재하지 않았기 때문이다.

make는 사용하지 않는다.

Linux kernel 컴파일시 항상 보았던, menu-config도 없다. 

따라서 이해를 위해서 기존의 임베디드 개발에 익숙한 사람들도 시간을 좀 들여야 한다.

Android Build System은 Android.mk 파일에 의해서 어떻게 동작할지가 기술 된다.

이것들의 갯수는 아래와 같다.

2.3.7 Gingerbread, 1,143

4.2 Jelly Bean 2,037

5.1.0_r3 Lollipop 3849

기존 커널 빌딩은

정적이지만, 안드로이드는 동적이다. envsetup.sh 와 lunch를 통해서 동적으로 사용자와 반응 하게된다.

그리고 조정가능한 요소들이 매우 제한적이다.

Build system은 Objet 파일을 만들어 내지 않는다.

중간 결과 따위가 없다.

대신 out/ 디렉터리에 중간 결과물들이 있다. 이것은 .o 파일 따위가 아니다.

마지막으로 아주 심하게 GNU-make 기능에 의존적이다. 다시말하면 정확히 3.81 version에 의존적이다.

3.82는 패치 없이는 동작하지 않는다.

즉, define, include, ifndef 같은 것들이다.

왜 구글이 Recursive Make를 안쓰는지는

"Recursive Make Considered Harmful", Peter Miller를 확인하자.

여기서 single global makefile 이 왜 좋은지를 알 수 있다.

구글은 module-provided .mk file을 가지고 단일 makefile로 컴파일을 한다.

Architecture

<그림 안드로이드 빌드 시스템의 구조>

build/core 디렉터리에서 main.mk를 찾을 수 있다.

각각의 mk 파일들이 모여서 엄청나게 거대한 단일 makefile로 만들어 지며, 이것은 각각의 작은 프로젝트들을 모두 컴파일 한다.

다시한번 말하지만 여러개의 makefile이 재귀적으로 호출되는 구조가 아니다.

Android system을 make해보면

어느정도 긴시간을 아무것도 출력하지 않는것을 알 수 있다.

도대체 그 시간에 무엇을 하고 있는 것일까?

그 시간에 Android.mk들이 서로 조합되는 시간일 것이다. 이것을 실제로 보고 싶은 경우

build/core/main.mk를 수정 하면 된다.

Configuration

빌드를 configure하는 방법은

envsetup.sh 과 lunch cmmand를 이요하는 것이다.

buildspec.mk 파일은 가능한 요건들을 출력 한다.

TARGET_PRODUCT

generic: 기본적인 것

full: 대부분의 앱들이 가능한 버전이다.

full_crespo: full과 같지만, crespo (nexus S)를 위한것

full_grouper: full과 같지만, grouper (nexus 7)을 위한것

sim: simulator를 위한것 하지만 2.3 (gingerbread)에서만 가능 했다.

sdk: 

TARGET_BUILD_VARIANT

eng: user, debug, eng를 포함한다.

userdebug: user, debug를 포함한다.

user: user를 포함한다.

TARGET_BUILD_TYPE

release 아니면 debug 

TARGET_TOOLS_PREFIX

기본적으로 prebuild에 있는 cross development toolchain을 사용 한다.

다른 toolchain을 사용하고 싶으면 새로 설정하면 된다.

OUT_DIR

모든 결과물을 out 디렉터리에 넣는다.

다른 디렉터리를 설정하면 다르게 할 수 있다.

BUILD_ENV_SEQUENCE_NUMBER

Output

host와 target을 위해서 각각 컴파일을 진행 

Overview

AOSP에 포함된 Git repository의 전체 리스트는

android.googlesource.com (Git Web Interface) 

에서 확인 가능하다. 

약 100개가 넘는 repository가 있다. 

Git 명령어로 하나씩 pulling 하는것은 매우 지루한 일이다.

그래서 구글에서는 Repo 유틸리티를 제공한다, 

Repo를 이용하면 이것들을 통합해서 git repositories들이 다운 받아 진다.

Repo는 manifest.xml 파일에 정의된 사항에 따라 Git repository를 받아오게 된다.

각각의 Git repository는 독립적인 Project로 관리 된다.

Repo 명령어의 사용 방법: https://source.android.com/source/using-repo.html#sync

Repo Init

repo init을 통해서 어떤 branch를 가져올지를 정하게 되는데,

https://android.googlesource.com/platform/manifest

platform/manifest 이 부분에 모든 branch들이 정의가 되어 있다.

repo init 뒤의 branch를 생략하게 되면 master branch를 다운 받아지게 된다.

master branch는 진행중인 project이므로 Google Developer들의 주석이나 팁들이 많이 포함되어 있다.

그리고 일반 개발자들이 기여한 코드들도 들어 있다.

따라서 정상적인 동작을 보장하지는 않는다.

이러한 branch들의 확인을 위해서 Git web site에서 직접 봐도 되고 git 명령어를 이용해도 된다.

위 두 명령어를 이용해서 세부적인 리스트를 확인할 수 있다.

그리고 각 Branch 마다 지원하는 Device model과 특성이 다르가. 그것을 이해하기 위해서는

Codenames, Tags, and Build Numbers

세부 사용법

Repo를 현재 작업 디렉터리에 설치

.repo 디렉터리를 생성함.

이것은 Repo 소스코드를 위한 Git 저장소와 표준 안드로이드 manifest 파일을 가지고 있다.

manifest.xml 이라는 심볼링 링크도 있다. 이것은 .repo/manifests/directory를 가리킨다.

Repo Sync

-j 뒤의 숫자는 병렬로 repository를 읽어올 숫자이다.

현재 network 상황에 맞추어 option을 줄 수 있다.

시도 리스트

Android 5.0.0_r6 프로젝트에

Android 51.0_r3을 repo init와 sync로 받았더니, 그냥 모두 덮어 씌어져 버렸다.

Ubuntu 리눅스가 VMware에서 돌아가고 있다면

1. 메뉴 VM -> Settings 를 실행

2. Options 탭 선택

3. Shared Folders 선택

4. 오른쪽 창 위쪽에서 'Always enabled'를 선택

5. 아래에 공유할 폴더를 추가

6. OK

7. 아래의 디렉터리로 접근 하면 된다.

/mnt/hgfs/E Drive

Gene Amdahl에 의해서 만들어진 법칙이다.

어떤 시스템의 P만큼 부분을 S만큼 개선하면

전체 시스템에서의 최대 성능 향상은 아래의 식을 따른다.

즉, 이것을 병렬처리에 적용하면 아래와 같다.

S만큼 개선이라는 말은 CPU 갯수를 의미한다. 2개면 2배, 3개면 3배이다.

P만큼 부분이라면 CPU를 늘렸을때 향샹되는 것이기 때문에 병렬화가 가능한 Instruction의 수이다.

예를들어, P가 40%로 0.4이고 S가 2배 향상되어 2라면 아래와 같다.

이러한 Amdahl's law는 병렬 컴퓨팅에서의 멀티 프로세서에 따른 성능향상을 설명할때 사용 된다.

위의 그림과 같이 병렬 컴퓨팅에서 멀티프로세서를 사용할 때 프로그램의 성능향상은 프로그램의 순차적인 부분에 의해 제한된다. 예를 들면, 프로그램의 95%가 병렬화 할 수 있다면 이론적인 최대 성능 향상은 아무리 많은 프로세서를 사용하더라도 최대 20배로 제한된다.

Git: 두개의 Commit 사이에서 변경된 코드 수 알기

--stat 옵션을 사용 하면 된다.

git diff --stat <commit-ish> <commit-ish>

좀 더 복잡한 방법

http://stackoverflow.com/questions/2528111/how-can-i-calculate-the-number-of-lines-changed-between-two-commits-in-git

19) Loop Transformations

데이터 의존성 까지 고려 하는 것이다.

Loop variables

-induction variable

변수에서의 모든 변화가 단지 증가 또는 감소가 constant value로 발생 하는 경우

-Basic induction variable

루프당 딱 1번 변화하는 것을 발한다. 1번 루푸당 1번씩 변화하는것

Primary induction variable

basic induction variable이 loop를 제어하면 그것이 Primary induction variable이 된다.

Derived induction variable

its value is decided with a linear function of the basic induction variable

Induction Variable Substitution

필요 없는 것을 loop에서 제거 해버린다.

Before and after induction-variable substitution of KI in the inner loop

KI를 제거 하자.

Before and after induction-variable substitution of KI in the outer loop

Before and after constant propagation of KI and INC

Loop Merge

Improve locality

Reduce loop overhead

- 첫번쨰 루푸의 생산결과가 다음 루프에서 바로 사용될 질경우, 이 둘을 병합하면, 지역성을 높일 수 있다.

merge의 가능성을 높이는 기법으로는

enablers, bump, extend/reduce, split, reverse 가 있다.

Tools [1] - loop Bump

Loop extend /reduce

Loops and Data Dependence

Dependency Types

3가지 종류의 의존성이 존재함.

S1: A=B+C

S2: D=A+2

S3: A=E+F

- Flow Dependence (true dependence)  S1S2

새로 어사인된 변수가 다음 구문에서 바로 이용될 때

- Anti-dependence  S2  S3

사용되어 지는 변수가 다음 번에 바로 어사인 되어 버릴때

- Output dependence S1 S3

새로 어사인된 변수가 다음번 구문에서 재차 어사인 되었을때

Dependency Types - LOOP

for k < m

= : k번쨰 인터레이션이 그것의 것에 의존 할때

m 이라는것이 k에 의존할때

k가 m에 의존 할떄

Distance Vector

for ( i =3; i<=7; i++)

for(j=6; j >=2; j=j-2)

Z[i,j] = Z[i, j+2] + 1

for( i =0; i<=4; I++)

for(j = 0; j<=2; J++)

i+3, j*-2+6 = Z [i+3, j*-2+8] + 1

Cf. Affine Functions.

어떤 변수들이 i1, i2, i3, i4, i5, i6 이러하 연속 성을 가지고,

1) 상수 들의 합

2) 변수 곱하기 상수 한 것들의 합

Formal Definition of Loop-Carriedness 의존성 문제

▣GCD = 최대공약수

루프 간의 의존성으 공약수로 나눠지 냐 안 나눠지냐로 알 수 있다.

나눌수 없으면 확실히 의존성이 없는 것이며, 나눌수 있다고해서 의존성이 있는 것은 아니다.

Advanced Compilers Reuse Optimization

Reuse Optimization 

Types of reuse optimization

- vn(value numbering)

- cse(common subexpression elimination)

- pre (partial redundancy elimination)

Value Numbering

Determines that two computations are equivalent and eliminates one of them.

Local Value Numbering

Idea

각각의 변수 표현 상수는 unique number로 어사인 된다.

변수, 표현 상수 들이 어떤 숫자로 이미 지정되어져 있었다면,

그것들을 그 상수로 사용한다.

그렇지 않다면 그것을 새로운 숫자로 사용한다.

같은 number는 같은 변수이다.

Loca의 경우는 별다른 어려움 없이 된다.

Global Value Numbering

두가지 기법이 있다.

Pessimistic

어떤 변수도 일치하지 않는다로 가정 한다.

지속적을 일치하는 것을 합쳐 나간다.

Optimistic (Slower but better results)

확실히 다른것이 아니면 모두 같다고 생각한다.

Pessimistic Global Value Numbering

Comparisons 

Constant propagation 또는 ( partial)  redundancy elimination은 두개의 expression이 동일하다면,그것이 constant인지 아닌지 결정 할 수 없다.

read a 이런게 있으면 불가능 하다.

Constant propagation은 b와 d가 7이라는 것을 알수 있다.

하지만 value numbering은 알 수 없다.

Purpose of memory alignment

http://stackoverflow.com/questions/381244/purpose-of-memory-alignment

참고사이트: click

AOSP을 가지고 Custom rom을 제작하다가 실패할경우, 이곳에서 제공하는 Factory Image를 이용해서 복구할 수 있다.

To flash a system image

1. 위 참고사이트에서 nexus 5용 Factory Image를 다운 받는다.

2. Factory Image에는 GMS와 각종 제조사별 드라이버가 포함되어있다. 이것을 디컴파일 또는 리버스 엔지니어링으로 추출해서 재배포할경우 법적 책임을 물을 수도 있다.

3. 기본적으로 스크립트 사용을 위해서 fastboot를 환경 설정 해주어야 한다.

4. oem unlock (이미 했다면 무시)

5. Factory Image를 압축 푼다음, flash-all 스크립트를 실행 한다.

   이때 target phone은 bootloader 상태에 있어야 한다.

6. 실행 결과

Android_preview 올릴때와 다르게, radio를 비롯해서, 상당히 많은 데이터가 올라가는 것을 알 수 있다.

이것을 기반으로 Device properties를 extraction해서 AOSP를 Build하는 법을 다음번에 다루 겠다.

Android New Runtime

The ART Manifesto

Developers should not work around the runtime

Code should be fast

garbage collection should help, not hinder

The runtime should scale

Performance (Better living through compilation)

ART garbage collection

Faster overall gc

single, short pause

less fragmentation

less memory usage

64-bit support (Supporting the future)

Advantages

Increased address space as Android usage diversifies

Increased performance from 64-bit instruction sets and cores

Full support for existing 32-bit apps

ART의 소개

Process VM

Binary translation - it attempts to amortize the fetch and analysis costs by translating a block of source instructions to a block of target instructions and saving the translated code for repeated use.

guest state를 host state로 맵핑 시키는 것.

memory addressing architecture를 emulation 시키는 것.

instruction emulation

exception을 emulation

operating system call을 에뮬레이션

추가로 성능 향상을 위해서, code cache management 기술이 있다.

VM의 개발

loader는 게스트 코드 데이터를 게스트에 할당된 메모리 이미지에다가 쓰기를 한다. 또한 런타임 코드들도 기록 한다.
이것은 게스트 코드와 데이터이지만, 결국 이것 자체는 실행되어질수 없기 대문에 런타임을 포함하는 것이라고 할 수 있다.

이러한 코드들은 결국 interpretation 또는 binary translation의 루틴에서의 인풋이라고 볼 수 있다.

Loader는 initialization block을 한다. 이것은 Code cache를 위한 메모리 공간을 할당하며 process 에뮬레이션을 위한 테이블 공간을 위한 메모리 공간도 할당하게 된다.

추가로, initialization 과정에서는 해당 시스템에서 발생할수 있는 모든 signal에 대한 handler를 생성하기위해서 Host OS를 호출하게 된다. initialization 다음에 에뮬레이션 과정이 시작되게 된다.

Emulation Engine은 Binary Translator 또는 intepreter에 의해서 동작 하게 된다. 

Code cache manager는 Code cache를 관리함.

Profile Data는 최적화를 위해서 사용됨.

OS call Emulator는 시스템 콜을 에뮬레이션 해준다.

Runtime은 반드시 Guest에서 발생할 수 있는 인터럽트에 대해서 핸들을 해줘야한다. 번역된 코드에 있는 Trap을 유발하는 코드에대해서 반드시 처리를 해줘야한다. Runtime은 이것을 처리하기 위해서 exception emulator를 가지게 된다. 이것을 처리해줄때 반드시 Guest의 state를 보장해줘야한다. program counter 또는 register value, trap condition 같은 것들을 말이다.

Side table은 translation 절차에 의해서 만들어 지는 것이다. 이것의 중요한 사용처중 하나는 exception model을 정확하게 동작시키기 위함이다. 즉 source ISA를 정확하게 매칭 시킨다. 

보충 자료

 JIT의 정의 : JIT는 일반적인 뜻으로 'Just-in-time'의 약어로 ‘즉시’라는 뜻입니다.

 JIT 컴파일은 Java, C#등에서 제공하는 ‘실시간’ 컴파일 방식입니다. 자바 가상 머신 실현 방법의 하나입니다. 가상 머신의 실현 방법으로는 현재 3종류가 있습니다. 이 JIT 컴파일러는 자바의 중간 코드인 바이트코드를 실행하는 컴퓨터 운영 체계(OS)와 중앙 처리 장치(CPU)에 맞춘 2진 코드로 일괄 변환한 후에 실행합니다. 자바 해석기 방식의 10~20배의 성능을 얻을 수 있습니다. 다시말해 JIT는 JIT Compiler라 하고 자바 프로그램의 실행 속도를 향상 시키기 위해서 개발된 기술입니다. 일반적인 자바 프로그램 실행은 byte code 가 native code(JVM이 실행중일 OS가 이해할 수 있는 code)로 변환 후 실행 되게 합니다. 이때 JIT는 byte code loading시 변환된 native code의 주소를 v-table에 표기하고 이후 실행시에는 곧바로 native code를 실행 하는 방식으로 속도를 향상 시킵니다. 이것은 기존의 interpreter방식의 단점을 보완한 방법으로 특정 메쏘드를 지속적으로 호출할 때 더 빠른 성능을 보입니다. 하지만 이로 인해 일부 프로그램의 경우 오히려 성능 저하를 가져 올 수 있습니다. (반복 적인 메소드 호출이 없는 경우에는 지속적인 bytecode->machine code 로의 컴파일이 발생 하기 때문에 성능 저하가 발생 합니다.) 이를 보완 하기 위한 compile 방식으로 AOT(ahead-of-time)방식이 있습니다. 이 AOT방식은 실행 전에 미리 컴파일 하는 방식으로 성능 향상에 도움이 됩니다.

좀 더 쉽게 요약

AOT(Ahead of Time) - 실행 시간 이전에 이루어지는 컴파일 방식이며 (실행시점이 아닌 설치시점에 미리 이루어진다는 뜻),

컴파일 타임에 중간언어로 번역한 다음 가상 머신 코드(중간 언어)를 최종 기계어로 번역한다.

JIT(Just In Time) - 실행 시간 이전에 컴파일 한 내용을 미리 가상 머신 코드(중간 언어)로 저장해놓고

                        컴포넌트 사용시 (매번 실행시 마다)에 가상 머신 코드를 최종 기계어로 바꾸어 명령어가 실행되도록 한다.

JIT 컴파일러의 경우 바이트코드를 재실행하는 경우 네이티브 코드를 다시 사용한다.

이 NativeCode의 단위는 class단위가 아니고 method단위이다.

JIT 컴파일러는 byte코드를 최적화한다.

AOT 컴파일러의 경우

- JIT와 동일하게 ByteCode->NativeCode로 컴파일한다. 

- 다른점은, 하나의 JVM에서만 사용할 수 있는게 아니라,여러 JVM에서 사용할 수 있다는 것이다.

- AOT Compiler는 생성한 AOT code를 Shared Cache에 저장한다. 그러면 이 Shared cache를 사용하는 JVM은 기동 시 AOT Code를 바로 사용할 수 있게 되어 기동시간이 줄어드는 이점이 있다

Wikipedia

Ahead of time compilation (AOT)

AOT는 컴파일을 하는 작업의 하나의 종류로 고수준의 언어인 java와 .net 같은 것들의 중간코드 IR 들 즉, 머신에 독립적인 코드들을 native 코드로 변경 하는 작업을 말한다.

보통 중간코드들은 실행되는 순간에 머신 코드로 변경이되는 Just in time(JIT)방식을 취하게 된다. 하지만 이러한 방법들은 응용프로그램의 성능 저하에 원인이 될 수 있다.

AOT는 이러한 수행중 컴파일되어야하는 필요성 자체를 제거하는 기법으로, 실행전에 모든것을 컴파일 하는 방법이다. 하지만 이것은 제한적인 수행 범위를 같는 것이 일반적이다.

AOT 컴파일 방식이 효과적인 상황에 대해서 이야기 하겠다.

1) interpreter가 너무 느린 경우

2) JIT 가 너무 복잡한 경우

3) 지연이 너무 큰경우

AOT는 표준 네이티브 컴파일러와 같은 최적화된 머신 코드를 만들어 낸다. 

즉, compiler 기술이라고 볼 수 있다.

Just in time compilation (JIT) - compiler라는게 정설이다 -

JIT는 dynamic translation기술로 알려져 있으며, 실행중에 중간코드를 머신코드로 변경하는 작업을 한다.

JIT compliation은 2개의 전통적인 기술을 조합한 방법이다. 즉, AOT 기술과 interpretation 기술의 각각의 장점과 단점들을 융합한것이다. 

중간 언어까지는 AOT로 컴파일을 하니, 그 장점을 취함.

Interpretation에서 제공하는 타겟에 덜 의존성적이며 이로인해서 컴파일러 개발 보다는 덜 보작하다는 장점을 취함. 또한 따로 최적화를 하지 않기 때문에 실행에 지연을 발생 시키지 않는다. 

- Applications

현대의 대부분의 runtime 환경들은 JIT compilation 기술에 의존한다. 높은 실행 속도를 제공하기 위해서

bytecode로 AOT를 이용해서 모두 변경 한다음에,

이러한 bytecode를 runtime시점에 machine code로 변경하게된다. 똑같은 코드가 다시 실행된다면, 그것을 재활용 하게 된다.

이것은 결국 interpreter 기능을 향상 시킨 기법이다.

이 JIT Compilation의 궁극적인 목표는 bytecode interpretation의 장점을 유지한체로, static compilation의 성능을 뛰어 넘는 것이다.

기본적으로, JIT은 interpreter 보다는 빠르다. 하지만 당연히 profiling을 하닌까 손실은 발생 할 수 있다.

그리고 몇몇 케이스에 대해서 static compiler 보다도 빠를 수 있다. 왜냐하면, 많은 최적화 기술들은 run time에만 실현 가능한 기술들이 있기 때문이다.

1) 실행중에 타켓 CPU나 운영체제에 맞추어서 최적화를 시킬 수 있다. 

2) 특정 영역이 얼마나 빈번히 실행 되는지에대한 통계값을 이용해서 최적화를 시도할 수 있다.

3) Inlining을 통해서 global code optimization들을 수행 할 수 있다. 이게 static에서는 어려운 이유가 virtual call 때문이다. 다형성으로 인해서 override 된 함수는 실행 해봐야 뭐가 콜 될지를 알 수 있다.

4) GC를 최적의 조건에 맞춰서 부를수 있다. 스태틱하게도 되지만, 어렵다. 실행해봐야 최적의 GC 시점을 알 수 있다.

- Startup delay and optimizations

bytecode를 Load하고 Compile하는 시간 때문에, JIT는 실행의 처음 단계에서 약간의 지연을 발생 시킨다.

이것을 startup time delay 라고 종종 부른다. 

JIT compiler는 최적화가 잘된 Machine Code를 만들어 낼 수 있다. 하지만, 지연은 더더욱 증가하게 되는  trade-off 관계를 가진다.

JVM에서의 전략은 다음과 같다.

일단 bytecode는 interpretation 된다. 그다음 JVM은 bytecode의 실행 빈도를 모니터링 하게 된다. 이렇게해서 가끔 실행 되는 코드들은 최적화를 위한 컴파일 시간을 대폭 줄이게 된다. 하지만 자주 실행 되는 코드라면, 최적화 기능을 모두 적용해서 interpretation 하게 된다. 이렇게하면 초기 지연은 좀 발생하지만, 자주실행되는 bytecode 이기 때문에 다음번 부터는 최적화된 machine code로 실행 할 수 있게 된다. 

Interpreter (이것은 compiler와 대립되는 기술이다.)

컴퓨터 프로그램을 직접적으로 실행하는 방식을 말한다. 즉, 프로그래밍 언어나 스크립트로 짜여진 명령어들을 머신 코드로 실행전에 변경하지 않고 그것을 실행 하는 것을 말한다. 그때 그때 머신 코드로 변경해서 실행하는 것이다.

interpreter는 다음의 전략들중 하나를 프로그램 실행을 위해서 사용 한다.

1) 소스코드를 파스하고 그것을 실행한다.

Lisp programing language and Dartmouth BASIC

2) 소스코드를 중간 코드 몇몇으로 변경한다음 그것을 실행 한다.

Perl, Python, MATLAB, Ruby

3) 인터 프리터 시스템의 한부분인 컴파일러에 의해서 만들어진 precompiled code를 실행하게 된다. (중간코드를 사용)

UCSD Pascal

소스코드는 ahead of time에 컴파일 되어지며, 이것은 머신에 독립적인 코드로 저장되어져 있다.

그다음 이것은 런타임에 인터프리터나, JIT 컴파일러 같은것들에 의해서 runtime에 실행 되어 진다.

java 같은 시스템들은 위 기술들중 몇개를 혼용해서 사용 한다.

Interpreter, static (ahead-of-time) compilation, and Just-in-time (JIT) 3개 구분

전통적으로 컴퓨터 프로그램을 실행하는 방법은 3가지 방법이 존재한다.

1) 인터프리터는 고수준 언어를 저수준언어로 실행할때 번역하게 된다.

2) AOT는 실행 이전에 모두 저수준언어로 번역하여 실행 한다.

3) JIT는 사실 위 두 기술의 hybrid 형태이다. 실행할때 고수준언오를 저수준언어로 번역하게 되고, 이것은 캐쉬에 저장된다. 따라서 매번 번역 과정을 수행하지 않는다. 하지만 분명히 AOT에 비해서 실행중에 번역을 하므로 오버해드는 존재한다.

Use-Def Analysis and SSA (Static Single Assignment)

Use-Definition chains (ud chains)

Each use of a variable is linked to all assginments that reach it

Definition-Use chains (du chains)

Each assignment to a variable is linked to all uses of it

SSA (Static Single Assignment Form)

UD를 좀더 축약한 것이다.

VM tools 설치 방법

Ubuntu 12.04 LTS 배포판에서 Vmware Tools 설치하기

(Vmware Tools 설치 뿐만아니라 kernel 헤더버전이 안맞는다고 에러메시지가 나는 경우 도움이 됩니다.)

0. VMTools ISO Image 위치: C:\Program Files (x86)\VMware\VMware Workstation\linux.iso

1. 우선 Vmware Workstation 메뉴에서 VM > Install VMware Tools 를 선택합니다. 만일 Vmware Esxi 일 경우 vSphere 등으로 접속하여 해당머신 마우스 오른쪽 클릭 후 게스트 > Vmware Tools 설치/업그레이드 를 선택합니다. 

2. 우분투에서 CD-ROM을 마운트 합니다.

mkdir /mnt/cdrom (마운트할 디렉토리 생성)

mount /dev/cdrom /mnt/cdrom (특별히 타입을 지정할 필요는 없습니다.)

압축해제

다른 상세한 설명 블로그

설치했을때 얻는 이점

To enable advanced X features (e.g., guest resolution fit, drag and drop, and 

file and text copy/paste), you will need to do one (or more) of the following:

1) Manually start /usr/bin/vmware-user

2) Log out and log back into your desktop session; and,

3) Restart your X session.

troubleshooting

VMware tools installation fails when Easy install is in progress (1017687)

Click

VMware full screen 방법

1. Enable 3D acceleration in VMware.

2. Set the Display option to "AuTomatic"/"host screen"

3. Install VMware tools in Ubuntu to enable dynamic screen resizing.

4. Use Ctrl+Alt+Enter to enable/disable full-screen mode.

DataFlow Analysis

대표적인 알고리즘 3개를 설명한다.

Live Variables Analysis 

정의: 현재 변수 값이 다른곳에서 사용될 것인지를 알아보는 것

아래와 같은 데이터를 모아야 함.

USE: 변수가 외부에서 사용되는 것을 말한다, 하나의 베이직 블럭에서

DEF: 하나의 베이직 블럭에서 정의되는것을 말함.

IN: 시작 포인트에서의 변수들이 살아 있는지를 말한다.

OUT: 변수들이 살아 있는지를 말한다.

Reaching Definition Analysis 

정의: 어떤 변수의 정의가 특정 위치까지 도달 하는지를 분석함. 

이것의 개념은 최적화 뿐만아니라, 각종 분석에 많이 사용되는 개념임.

요약: 

Forward 방식

Inner Analysis

GEN - 해당 BB에서 생성되는 정의들의 집합

KILL - 모든 BB에서 해당 GEN에 의해서 사라지는 정의들의 집합

Outer Analysis

IN - 모든 이전의 OUT들을 더함

OUT - GEN + ( IN - KILL )

Available Expressions 

정의: 이미 계산된 expression을 재사용 하자.

E_GEN의 생성은 G + (E_GEN(X) - K) 이다.

명령어

두 명령어를 연결하기 위해서 아래의 파일을 편집

아래의 코드를 삽입

터미널 이름 변경 방법

변경할 파일

재부팅

다중 스크린 사이즈를 지원하는 방법

용어 정리

Screen size:  대각선 상의 실제 크기를 말한다.

안드로이드 시스템에선 간단히 4개의 그룹으로 표현 한다.

small

normal

large

extra-large

Screen density: 

Orientation: 

Resolution: 화소수, 항상 가로부터 표현.

Density-independent pixel (dp): 가장 중요한 정보이다. 인치당 점의 개수로, UI의 실제 길이가 결정 되는 부분이다.

aspect ratio: 종횡비로 가로와 세로의 비율을 나타냄. 

4:3, 16:9와 같은 것들이며, long, notlong과 같이 표현 하기도함.

안드로이드가 이와 같이 그룹을 이용하는 것은, 약간의 차이는 거의 무시해도 되기 때문이다. 따라서 일반화를 시켜서 계산하게 됨.

화소 vs 밀도 -> 비례

크기 vs 밀도 -> 반비례

---

해상도 제각각

밀도가 제각각

화면이 잘리거나, 검정색 여백을 드러내는 프로그램들이 실제로 존재함.

문제를 발생 시키는 몇가지 나쁜 습관들

1) 물리 단위를 쓰지 않고 논리 단위를 쓴다.

2) 이미지는 가급적 밀도별로 모두 제공함.

3) 레이아웃의 배치 기능을 십분 활용 한다.

논리 단위의 이용

물리 단위는 해당 장치에서만 정확하게 동작하므로, 빌트인 앱과 같은 특수한 경우를 제외 하고는 이용하지 않도록 해야함.

안드로이드에서 제공하는 노리적 단위는 다음과 같음.

px 물리적인 픽셀단위

in, mm, pt 인치, 밀미미터, 포인트

dpi (or dp), sip (or sp) 밀도에 독립적인 단위, 폰트에 가변 크기

dpi가 논리적인 단위 이므로 이것을 사용 해야한다.

160을 기준으고 1 픽셀

240 이면 240/160 = 1.5 배 커짐.

120 이면 120/160 = 0.75배 만큼 감소.

이미지 리소스의 경우

이미지의 경우 다소 특별한 관리 기법을 따름.

운영체제는 장비의 밀도와 폴더의 밀도를 비교하여 이미지를 스케일링함.

모든 폴더에서 이미지가 발견되지 않으면 컴파일 에러로 처리함.

각각에 맞게,

drawable-ldpi

drawable-mdpi

drawable-hdpi

3개의 디렉터리에 이미지를 넣어 두면 좋은 효과를 볼 수 있다.

레이아웃 활용

절대적인 배치 레이아웃으론 맞추기가 어렵다.

따라서 렐러티브 레이아웃,

리눅스 명령어

검색 명령어

특정 파일만 검색하기

SLOC 계산 명령어

페키지 삭제

파일리스트 생성

find . -type d -print0 | while read -d '' -r dir; do
    files=("$dir"/*)
    printf "%5d files in directory %s\n" "${#files[@]}" "$dir"
done

vi 명령어

문자열치환

옵션

g : global - 한 줄에 패턴이 여러 번 나오면 모두 바꾼다. 지정하지 않으면 첫번째 패턴만 치환

i : ignore case - 대소문자 구분을 하지 않는다.

c : confirm - 검색된 모든 문자열에 대해서 바꿀지 말지를 물어본다.

이미지 파일 열기

네트워크 트레픽 모니터링