'전체 글'에 해당되는 글 677건

  1. 2010.10.13 디아2 앵벌과 매찬
  2. 2010.10.13 백섭이란? 백섭에 대해서...
  3. 2010.10.05 Bootanimation.zip 파일 설명(영문) (1)
  4. 2010.10.05 Android Porting On Real Target/ko

퍼온 글입니다. 출처 트레디아 사게.

--------------------------------------------------------

 

이 글은 헬클랜 덴마님의 글을 토대로 요약한 것이며 1.10 패치 직후의 자료이므로 현재와는 다를 수도 있습니다.
대부분 알고 계시겠지만 모르는 분들을 위하여 정리해 보았습니다.

앵벌과 매찬에 대하여

몹을 잡았을때 아이템의 생성순서는 크게 3가지 스텝으로 나눌 수 있습니다.

① 아이템을 떨어뜨릴 것인가 / 떨어뜨리지 않을 것인가.
방의 인원수에 영향을 받습니다.

② 어떤 종류(type)의 아이템을 떨어뜨릴 것인가.
잡는 몹의 종류와 사냥 장소에 영향을 받습니다.

③ 어떤 품질(quality)의 아이템을 떨어뜨릴 것인가.
매찬의 영향을 받습니다.


위 세가지 변수를 주제로 한가지씩 살펴보겠습니다.

♣ 방의 인원수 ♣
방의 인원수에 따라 드롭되는 아이템의 숫자가 변하게 되는데 방의 인원이 많을수록 더 많은
아이템을 드롭하게 됩니다.

인원수        몹라이프     경험치+%       아이템 드롭율%  
    2              *2               +75%             37.5%
    3              *3              +150%            61.22%
    4              *4              +225%            61.22%
    5              *5              +275%            75.94%
    6              *6              +300%            75.94%
    7              *7              +325%            85.71%
    8              *8              +350%            85.71%

그러나 같은 수의 인원이라도 파티조건에 따라 차이가 있습니다.
① 파티원과 동일지역에서 앵벌할때
② 파티원과 다른 지역에서 앵벌할때
③ 비파티원과 같은 지역에서 앵벌할때
④ 비파티원과 다른 지역에서 앵벌할때

파티원과 동일지역에서 앵벌할때 최고의 드롭율을 가지게되며 ②③④ 는 같은 드롭율이 같지만
①에 비해 낮은 드롭율을 가지게 됩니다.
카우방에서 같은 풀방이라도 모두 파티하고 사냥할때는 드롭되는 아이템이 많지만
혼자 사냥하면 드롭되는 아이템이 상대적으로 적다는 것을 느끼셨을 것입니다.

방 인원수가 많을수록 드롭율이 높기는 하지만 인원이 많아질수록 증가폭은 줄어들어
큰 차이를 보이지 않으므로 3명이상인 방에서 파티후 같은 지역에서 앵벌한다면 충분한 조건을
갖춘셈
이 됩니다.


♣ 어느 장소에서 어떤 몹을 잡을 것인가 ♣
이것을 설명하려면 TC에 대한 개념이 있어야 할것 같습니다.
TC(Treasure Class)란 무엇일까요?
TC를 복잡하게 생각하실 필요는 없습니다.
그냥 단순하게 아이템 등급 정도로 생각하시면 무난합니다.

디아블로의 모든 아이템은 고유의 TC를 가지고 있으며 고급 아이템일수록 높은 TC를 가지게 됩니다.
몬스터는 레벨과 TC한계치를 가지고 있으며 레벨이 높을수록 고급 아이템을 드롭하게 됩니다.
예외는 있지만 몬스터의 레벨은 TC 한계치와 비례하기 때문에 레벨이 높은 몬스터를 사냥해야
고급 아이템을 얻을 수 있습니다.

여기서 말하는 고급아이템의 의미는 두가지입니다.
첫째, 노말/익셉셔널/엘리트 중 상위버젼을 말합니다.
샤코의 예를 든다면 노말버젼은 캡이고 익셉셔널 버젼은 워햇, 엘리트 버젼이 샤코지요.
둘째, TC가 높은 아이템을 말합니다.
하이드라보우를 예로 들어 보겠습니다.
하이드라보우의 TC는 87인데 메피스토의 TC한계는 78입니다.
메피스토의 TC가 78로 하이드라보우보다 낮기 때문에 메피스토는 하이드라보우를 드롭할 수 없고
따라서 메피스토에게서는 유닉윈포를 얻을 수 없습니다.

그런데 액트의 각 지역도 레벨이 있고 1.10 패치후에는 몬스터의 레벨이 지역 레벨에 따라 상향됩니다.

몬스터의 레벨은 몬스터 원래 레벨과 지역레벨 둘 중 높은 쪽의 레벨을 가지게 됩니다.
- 지역레벨 1인 곳에서 레벨 2의 일반 몬스터의 레벨은 2가 됩니다.
- 지역레벨 3인 곳에서 레벨 2의 일반 몬스터의 레벨은 3이 됩니다.
- 챔피언 몬스터는 지역레벨 +2의 레벨 보너스를 가집니다.
- 유닉 몬스터는 지역레벨 +3의 레벨 보너스를 가집니다.
- 각 액트 보스 및 일부 슈퍼유닉 몬스터는 지역레벨의 영향을 받지 않습니다.

헬에서는 대부분 지역레벨이 몬스터 레벨보다 높기 때문에 지역레벨이 높은 곳에서 사냥을 하는 것이
유리하고 헬의 지역레벨은 최하 67부터 최고 85까지입니다.
당연히 지역레벨 85인 곳에서 사냥을 하는 것이 가장 유리하겠지요.
지역레벨 85인 지역의 유닉몬스터는 +3의 보너스를 받아 레벨 88이되며 이 몬스터들은
모든 아이템을 다 떨굴 수 있는 TC를 가지게 됩니다.

통상 액트1에서부터 액트5까지 순차적으로 지역레벨이 상향되지만 예외적으로
지역레벨이 높은 곳이 많이 있습니다. 지역레벨 85인 장소를 모두 정리해 보았습니다.
참조 : 헬의 모든 지역레벨

[ 액트 1 ]
- 머셜리엄 (콜드플레인)
- 피트 (타모에 고지)

[ 액트 2 ]
- 마고트 동굴 3층 (파오아시스)
- 고대인 하수도(잊혀진 도시)

[ 액트 3 ]
- 하수도 2층 (쿠라스트)
- 잊혀진 사원 (북부쿠라스트)
- 버려진 유적 (쿠라스트 커즈웨이)
- 폐허의 신전 (쿠라스트 커즈웨이)

[ 액트 4 ]
- 불길의 강    
- 카오스 생츄어리

[ 액트 5 ]
- 월드스톤성채 1,2,3 층
- 쓰론 오브 디스트럭션
- 월드스톤 챔버

지역 레벨이 높다고해서 무조건 앵벌장소로 좋은 것은 아닙니다.
그 지역의 몹숫자, 난이도, 캐릭특성 등을 고려하여 효율적인 곳을 선택해야 하는데
가장 대표적인 곳이 피트입니다. 피트는 몹이 많고 비교적 약해서 앵벌장소로 사랑받고 있지요.
액트3의 85지역은 몹이 적어서 앵벌장소로 적당하지 않습니다.
액트4, 5의 85지역은 난이도가 높아서 햄딘, 무공체라소서등이 아니면 앵벌이 어려운 곳이지요.


♣ 매찬은 얼마가 적당할 것인가 ♣

매찬의 역할은 드롭되는 아이템의 품질(quality)을 결정하는 것입니다.

예를 들어 TC에 의해 콜로서스블레이드가 드롭되기로 결정 되었을때
그 콜로서스블레이드가 세트냐 레어냐 유닉이냐 등등 품질을 결정하는 것이 바로 매찬입니다.
매직,레어,유닉 구분이 없는 아이템(룬,키 등)은 매찬의 영향을 받지 않겠지요.

여기서 품질이란 노말 > 슈페리어 > 매직 > 레어 > 세트 > 유니크 를 말하며
후순위일수록 품질이 높다고 생각하시면 되겠습니다.
즉, 매찬이 높을수록 상위 품질로 나올 확률이 높아진다는 것입니다.

그럼 매찬이 100%면 몹 잡을때마다 100% 유닉이 드롭되어야 하는 것 아닌가?
물론 그렇게 계산되지 않습니다.
각 아이템에는 고유의 드롭율이 정해져 있습니다.
매찬 0%인 캐릭이 바알을 잡았을때 바알이 유닉 샤코를 떨어뜨릴 확률은 0.031165% 입니다.
매찬 300%인 캐릭이 바알을 잡으면 0.031165% 의 300%인 0.0933495%가 추가되어서
0.12466% 가 되는 것입니다.

그렇다면 매찬은 높을수록 좋은 것인가?
그렇다고 할 수 있습니다.

그러나 두가지 이유에 의해서 매찬이 높을수록 효율성은 떨어지게 됩니다.
첫째, 매찬이 높은만큼 캐릭이 약해지므로 그만큼 사냥속도가 떨어진다는 것입니다.
사냥속도가 떨어진다는 것은 드롭율을 낮추는 결과가 되므로 오히려 역효과가 있을 수 있습니다.

둘째, 아래 표에서 보시는바와 같이 매찬이 높아질수록 실제 적용되는 매찬수치가
상대적으로 줄어든다는 것입니다.

※ 매찬이 게임상에서 실제 적용되는 수치  
매찬          매직     레어    세트    유니크
   0%           0%     0%      0%      0%
  50%         50%    50%    50%     50%
100%       100%   100%   100%   100%
110%       110%   110%   110%   110%
120%       120%   119%   119%   118%
130%       130%   130%   128%   128%
140%       140%   138%   137%   135%
150%       150%   146%   145%   141%
200%       200%   185%   183%   171%
250%       250%   220%   215%   193%
300%       300%   250%   242%   211%
400%       400%   300%   287%   236%
500%       500%   340%   322%   253%
600%       600%   372%   350%   266%
800%       800%   423%   391%   284%
1000%    1000%   460%   421%   295%
1200%    1200%   494%   448%   305%
1500%    1500%   520%   468%   312%  

즉, 유닉의 경우 매찬 500% 맞춘 캐릭과 800% 맞춘 캐릭의 매찬차이는 300%지만 실제 적용매찬 차이는
1/10인 31%에 불과하다는 것입니다.
무리해서 매찬을 높이느니 300~500% 매찬만 맞추어 빠른 사냥을 하는 것이 더 효율적이라는
결론이지요.
또 매찬이 높으면 룬워드 재료의 획득에는 더 불리합니다.


※헬 각 액트 지역레벨

[ Act 1 - Rogue Encampment ]
카우레벨(Secret Cow Level) ------------------ 81
블러드무어(Blood Moor) --------------------- 67
덴오브이블(Den of Evil) --------------------- 79
콜드플레인(Cold Plains) --------------------- 68
동굴1층(Cave Level 1) ----------------------- 77
동굴2층(Cave Level 2) ----------------------- 77
베리얼그라운드(Burial Grounds) -------------- 80
크립트(Crypt) ------------------------------- 83
머셜리엄(Mausoleum ) ----------------------- 85
스토니필드(Stony Field) ---------------------- 68
트리스트럼(Tristram) ------------------------ 76
지하통로 1층(Underground Passage Level 1) --- 69
지하통로 2층(Underground Passage Level 2) --- 83
다크우드(Dark Wood) ------------------------ 68
블랙마쉬(Black Marsh) ----------------------- 69
홀1층(Hole Level 1) ------------------------- 80
홀2층(Hole Level 2) ------------------------- 81
포가튼타워 1층(Tower Cellar Level 1) ---------- 75
포가튼타워 2층(Tower Cellar Level 2) ---------- 76
포가튼타워 3층(Tower Cellar Level 3) ---------- 77
포가튼타워 4층(Tower Cellar Level 4) ---------- 78
포가튼타워 5층(Tower Cellar Level 5) ---------- 79
타모에고지(Tamoe Highland) ----------------- 69
피트 1층(Pit Level 1) ------------------------- 85
피트 2층(Pit Level 2) ------------------------- 85
수도원정문(Monastery Gate) ----------------- 70
수도원외곽(Outer Cloister) ------------------- 70
병영(Barracks) ---------------------------- 70
감옥 1층(Jail Level 1) ---------------------- 71
감옥 2층(Jail Level 2) ---------------------- 71
감옥 3층(Jail Level 3) ---------------------- 71
수도원안쪽(Inner Cloister ) ----------------- 72
대성당(Cathedral) --------------------------- 72
카타콤 1층(Catacombs Level 1) --------------- 72
카타콤 2층(Catacombs Level 2) --------------- 73
카타콤 3층(Catacombs Level 3) --------------- 73
카타콤 4층(Catacombs Level 4) --------------- 73

[ Act 2 - Lut Gholein ]
하수도 1층(Sewers Level 1) ------------------ 74
하수도 2층(Sewers Level 2) ------------------ 74
하수도 3층(Sewers Level 3) ------------------ 75
로키황무지(Rocky Waste) -------------------- 75
스토니툼 1층(Stony Tomb Level 1) ------------ 78
스토니툼 2층(Stony Tomb Level 2) ------------ 79
메마른언덕(Dry Hills) ----------------------- 76
죽음의홀 1층(Halls of the Dead Level 1) ----- 79
죽음의홀 2층(Halls of the Dead Level 2) ----- 79
죽음의홀 3층(Halls of the Dead Level 3) ----- 79
파오아시스(Far Oasis) --------------------- 76
마고트동굴 1층(Maggot Lair Level 1) --------- 84
마고트동굴 2층(Maggot Lair Level 2) --------- 84
마고트동굴 3층(Maggot Lair Level 3) --------- 85
잊혀진도시(Lost City) ----------------------- 76
고대하수도(Ancient Tunnels) ---------------- 85
스네이크벨리(Valley of Snakes) -------------- 77
클러바이퍼사원 1층(Claw Viper Temple 1) ----- 82
클러바이퍼사원 2층(Claw Viper Temple 2) ----- 83
하렘 2층(Harem Level 2 ) -------------------- 78
궁전지하 1층(Palace Cellar Level 1) --------- 78
궁전지하 2층(Palace Cellar Level 2) --------- 78
궁전지하 3층(Palace Cellar Level 3) --------- 78
아케인 생츄어리(Arcane Sanctuary) ----------- 79
마기의 캐넌(Canyon of the Magi) ------------- 79
탈라샤의 무덤(Tal Rasha's Tomb) ------------- 80
듀리엘 방(Duriel's Lair) -------------------- 80

[ Act 3 - Kurast Docktown ]
스파이더 정글(Spider Forest) ---------------- 79
어레크니드 동굴(Arachnid Lair) -------------- 79
스파이더 동굴(Spider Cavern) --------------- 79
그레이트 마쉬(Great Marsh) ----------------- 80
프레이어 정글(Flayer Jungle) ---------------- 80
스웜피 피트 1층(Swampy Pit Level 1) --------- 80
스웜피 피트 2층(Swampy Pit Level 2) --------- 81
스웜피 피트 3층(Swampy Pit Level 3) --------- 82
프레이어 던전 1층(Flayer Dungeon Level 1) --- 81
프레이어 던전 2층(Flayer Dungeon Level 2) --- 82
프레이어 던전 3층(Flayer Dungeon Level 3) --- 83
남부 쿠라스트(Lower Kurast) ----------------- 80
하수도 1층(Sewers Level 1) ------------------ 84
하수도 2층(Sewers Level 2) ------------------ 85
쿠라스트 바자(Kurast Bazaar) ---------------- 81
폐허의 사원(Ruined Temple) ----------------- 84
버려진 신전(Disused Fane) ------------------ 84
북부 쿠라스트(Upper Kurast) ----------------- 81
잊혀진 유적(Forgotten Reliquary) ------------- 84
잊혀진 사원(Forgotten Temple) --------------- 85
쿠라스트 커즈웨이(Kurast Causeway) --------- 81
버려진 유적(Disused Reliquary) -------------- 85
폐허의 신전(Ruined Fane) ------------------- 85
트라빈컬(Travincal) ------------------------ 82
증오의 사원 1층(Durance of Hate Level 1) ----- 83
증오의 사원 2층(Durance of Hate Level 2) ----- 83
증오의 사원 3층(Durance of Hate Level 3) ----- 83

[ Act 4 - The Pandemonium Fortress ]
지옥의 평원 외곽(Outer Steppes) ------------- 82
절망의 평원(Plains of Despair) --------------- 83
지옥 망령의 도시(City of the Damned) --------- 84
불길의 강(River of Flame) ------------------- 85
카오스 생츄어리(Chaos Sanctum) ------------ 85

[ Act 5 - Harrogath ]
블러디 풋힐(Bloody Foothills) --------------- 80
프리지드 하이랜드(Frigid Highlands) --------- 81
어배던(Abaddon) ------------------------- 81
아리앗 고원(Arreat Plateau) ----------------- 81
피트 오브 아케런(Pit of Acheron) ------------ 82
크리스탈 라인(Crystalline Passage) --------- 82
프로즌 리버(Frozen River) ------------------ 83
글레이셜 트레일(Glacial Trail) --------------- 83
드리프터 동굴(Drifter Cavern) --------------- 84
프로즌 툰드라(Frozen Tundra) -------------- 81
인퍼널 피트(Infernal Pit) -------------------- 83
고대인의 길(Ancient's Way) ----------------- 82
아시이 셀라(Icy Cellar) --------------------- 83
아리앗 정상(Arreat Summit) ----------------- 87
나라트하크 사원(Nihlathaks Temple) --------- 83
홀스 오브 앵귀쉬(Halls of Anguish) ---------- 83
홀스 오브 페인(Halls of Pain) --------------- 84
홀스 오브 보우트(Halls of Vaught) ----------- 84
월드스톤성채 1층(The Worldstone Keep 1) ----- 85
월드스톤성채 2층(The Worldstone Keep 2) ----- 85
월드스톤성채 3층(The Worldstone Keep 3) ----- 85
쓰론 오브 디스트럭션(Throne of Destruction) --- 85
월드스톤 챔버(The Worldstone Chamber) ------ 85


'ETC > 게임 이야기' 카테고리의 다른 글

FF3 LV 테이블 및 JOB 베이직 테이블  (0) 2010.10.13
FF3 난수 테이블  (0) 2010.10.13
FF3 기본 스텟 및 전투 시스템  (0) 2010.10.13
Final Fantasy 3 (FF3) 소개  (0) 2010.10.13
디아2 앵벌과 매찬  (0) 2010.10.13
백섭이란? 백섭에 대해서...  (0) 2010.10.13
안정적인 DNS서비스 DNSEver DNS server, DNS service
Posted by 키르히아이스

댓글을 달아 주세요


출처 Flash Game Revolution! | 갬메이커
원문 http://blog.naver.com/zencraft/150000928727
작성일 : 2004년 08월 20일
작성자 : 김호광 (testcode@korea.com)


백섭이 뭔가요?
방학이 된 우리 미란이는 늦은 아침 식사 후에 온라인 게임을 즐기고 있었다. 몇 시간 게임을 즐긴 끝에 그 게임에서 나오기 힘든 “와장창 무지 강한 검” 아이템을 얻게 되었다. 이 아이템은 현금 거래도 되고 매우 희귀했기 때문에 미란이는 너무나 기뻐했다. 하지만 잠시 후 갑자기 서버가 끊겼다는 메시지가 나면서 게임 접속이 안됐다. 몇 시간 후에 온라인 게임 서비스가 정상으로 돌아오자 미란이는 바로 게임에 접속해 게임을 플레이 했다. 그런데 자기가 획득한 “와장창 무지 강한 검”이 없는 것이 아닌가?

놀란 미란은 게임 웹 페이지로 접속하여 항의하려고 했다. 이미 게시판은 백섭이라며 폭동에 가까운 상태였다. 결국 아이템은 복구되지 않았고 미란은 백섭이 뭔지는 모르지만 무지 나쁜 기억을 가지게 되었다.

오픈 베타 온라인 게임이나 프리 온라인 게임을 즐기다 보면 갑자기 게임 서버가 다운되는 현상이 있다. 이 경우 유저들이 서버가 다시 오픈될 때까지 있다가 게임에 접속했을 때 자기 아이템이 없어졌거나 애써 레벨업 한 자기 캐릭터의 능력치가 몇 시간 혹은 하루나 이틀 전까지 되돌아간 경우 그 온라인 게임의 홈페이지는 아수라장이 된다. 개발사는 사과 공지와 선별적인 구제 혹은 침묵으로 일관하고 다시 이런 일은 뫼비우스의 고리처럼 재현된다.

왜? 백섭이라는 현상이 일어날까? 이에 대한 사항을 이야기해보도록 하자.

백섭이란 약자를 좋아하는 한국 게임 유저의 특성에 맞춘 약어이다. 정식 용어는 Back Service라는 말로 일정 서비스 시간 이전의 데이터로 되돌아갔다는 의미이다. 간단히 말하면 오늘 정보가 아니라 어제 정보나 한 달 전 유저 정보로 돌아간다는 것이다.

온라인 게임 유저들이 오픈 베타 게임을 즐길 때 빈번하게 나타나는 현상이 바로 백섭 (Back Service)이다 이런 현상이 왜 일어나는지에 대해서 알아보자.

MMORPG나 온라인 게임은 한 명이 즐기는 게임이 아니기 때문에 개인 정보를 서버 (Server)에 둔다.

서버란 영어 단어 그대로 서비스를 제공하는 주체이다. 서버는 유저의 정보를 저장하는 공간과 프로그램을 갖는데 이를 DB(Daatabase)라고 말한다.

온라인 게임은 인간이 만든 것이기 때문에 버그가 일어난다. 우리가 윈도우를 사용하다보면 인터넷 익스플로어의 다운 현상이나 프로그램의 다운 현상을 자주 살펴볼 수 있듯이 아무리 잘 만든 온라인 게임이라도 비정상적인 실행이나 운영체제(Windows, Linux 등)의 실행 버그, 해킹, 온라인 게임 서버 프로그램의 오류로 인해 온라인 게임 서비스가 중단되는 상황이 발생한다.

이 경우 게임 서버는 갑자기 다운되는 상황이기 때문에 게임 DB에 정상적인 유저 정보를 저장하지 못하고 다운된다. 이 때 짧게는 몇 초에서 길게는 하루 사이의 유저 정보가 비게 된다. 유저 정보의 백 서비스 현상이 몇 초의 정보에서 하루 이틀 사이의 정보가 되는 이유는 게임 서버가 유저 정보를 언제 저장하느냐에 따라 다르다.

1. 유저 정보가 변경될 때마다 DB에 저장한다. -> 짧은 시간의 백 서비스
2. 유저가 로그 오프하고 나갔을 때 DB에 저장한다. -> 긴 시간의 백 서비스
3. 일정 시간 DB에 저장한다. -> 시간에 따른 백 서비스

일반적으로 게임 서버가 안정하다는 가정에서는 유저가 로그 오프되었을 때 DB에 저장하는 것이 서버와 DB에 대한 효율이 좋다. 그러나 베타 상태의 온라인 게임에서 잦은 서비스 패치와 안정성 문제로 인해 실질적으로 이런 온라인 게임 서버 구조로 이행하기 힘들다.

따라서 유저 정보가 변경될 때마다 혹은 일정한 정보를 가졌을 때 저장하는 방식이나 일정 시간마다 저장하는 방식을 사용하는 경우가 많다. 많은 게임의 경우 위 3가지 방식을 섞어서 사용하는 경우가 많다.

 

백 서비스 문제에서 가장 유저들의 비난을 받는 부분이 획득한 아이템을 잃어버리는 사태이다. 많은 상용 온라인 게임의 경우 아이템 거래 정보나 아이템 획득 정보를 별도의 DB나 로그 파일 (일정 정보를 저장하는 파일)로 남겨서 아이템 사기나 백 서비스 문제가 일어났을 때 아이템을 되돌려 줄 수 있도록 하고 있다.

그렇다면 독자 여러분이 의문을 제기하는 사항이 있을 것이다!

“그럼 내가 즐기는 온라인 게임은 왜 백섭이 나타나서 아이템을 잃어 먹으면 꿀 먹은 벙어리인가?"

이유는 대략 3가지로 정리할 수 있다.

첫째, 로그 정보를 분석하고 처리하는데 너무 많은 인력이 들어 무시한다.
둘째. 게임 서버에서 별도 로그 정보를 안 남기고 있다.
셋째, 로그 정보가 완벽하지 않다.

로그 정보는 온라인 게임 서버가 실행될 때 유저 정보의 아이템 정보가 각종 디버그 정보(게임 버그를 잡기 위한 정보)를 담고 있기 때문에 파일 용량이 수 십 메가에서 수 백 메가의 용량을 자랑한다.

불행하게도 우리 개발자들이 주 5일 근무 시대에 주 7일 근무와 야근, 특근을 가리지 않고 개발하더라도 절대적인 개발 시간이 더 필요한 실정이다. 상용화 경험이 매우 풍부한 게임 개발사가 아니라면 대부분의 게임 개발사의 온라인 게임은 제대로 된 운영 툴이 없다. 데이터 백업 툴, 로그 분석 툴, 운영자 툴 등의 각종 툴을 개발할 새도 없이 오픈 베타로 내몰린 상태이다. (운영자는 그런 열악한 상태에서 게임 화면을 보면서 유저의 각종 불만을 몸으로 때우며 열정으로 운영의 원활함을 위해 노력하고 있을 것이다.) 따라서 로그 파일을 남겼더라도 로그를 분석할 툴이 열악하거나 없을 수도 있는 것이다.

이럴 경우 정책적으로 혹은 인력의 한계로 인해 잃어버린 아이템을 되돌려줄 생각을 못하는 것이다. 열성 유저의 경우 강력한 항의로 일부 선별 구제되는 경우가 있긴 하지만 현실적으로 수만 명에서 수 십만명의 유저 정보에서 최종 아이템 정보를 추출하여 유저 정보 DB에 되돌려주기는 정말로 끔찍한 작업에 속하기에 개발사 입장에서는 며칠 게시판과 전화, 메일로 욕을 먹더라도 침묵하게 되는 것이다.

로그 정보를 안 남기는 경우는 대부분 서비스 준비가 완벽하지 않은 상태에서 급하게 오픈 베타를 연 신생 게임 업체나 초보 개발자의 경우에 종종 발생하는 경우이다. 이 경우에는 어느 시점이 되면 개발자의 필요와 회사 내부, 운영자의 요청으로 인해 로그 파일과 로그 분석 툴 등이 만들어진다. 그 동안은 베타 유저들이 조마조마한 마루타가 된 기분으로 게임을 즐길 수밖에 없다.

마지막으로 로그 정보가 부정확할 경우는 로그를 남기는 기술적인 문제로 인한 것이다. 기술적 미비로 인해 온라인 서버 게임 프로그램이 다운될 때 파일이나 DB에 현재 메모리에 있는 유저 정보를 저장하지 못하고 다운되는 상황인 것이다.

온라인 게임 서버 프로그램이나 서버 OS가 다운되는 상황에서는 제아무리 로그를 남길려고 하더라도 제대로 로그를 남기기 힘든 것이 사실이다. 서버 개발자들 사이에는 불행한 1%라는 말로 잃어버리는 게임 아이템에 대한 이야기를 한다. 정말 개발자 입장에서는 어떻게 처리하기 난감한 상황이다.

최근 일부 온라인 게임에서는 이런 다운이 일어났을 때 유저가 가지고 있는 아이템에 대한 정보를 암호화된 파일로 남겨 놓아 백 서비스 문제에 대한 보완을 하려는 회사도 있다. 아무래도 현금 거래가 되는 아이템을 잃어버리는 상황은 메가톤급 폭발력이 있는 이슈이기 때문이다.

그런데 같은 온라인에서 서비스를 하는 은행, 증권사는 이런 문제가 신문 지상에 나오지 않는다. 이는 수십 년 된 노하우가 있기 때문이다. 금융권 서버 프로그래밍에서는 99.999% 가동률이라는 말을 사용한다. 1년 운영을 가정했을 때 시스템 장애로 서비스가 불가능한 시간을 0.001%로 낮춰야한다는 말로 시간으로 환산하면 1년에 5분의 장애 사항을 의미한다. (아무리 잘 된 온라인 게임 서버라도 한 달에 한번이나 분기에 한 두 번은 서비스 정검으로 리부팅을 해야 한다. 이는 나중에 칼럼으로 다룰 것이다.)

은행과 같은 금융 정보는 다운되어 고객 정보가 날아가면 돈이 날아가는 일이기 때문에 다운으로 인한 데이터 손실을 본질적으로 허용하지 않는다. 이런 금융권 서버의 기술 중 하나가 DB를 실시간으로 백업하는 기술 (미러링)과 로그를 실시간으로 백업하고 남기는 기술 등이 있다.

이런 기술은 엄청난 하드웨어 장비와 엄격한 프로그래밍이 요구되기 때문에 보통 게임 개발사에서는 시도조차 못하는 것이 일반적이었다. 대부분 유닉스나 IBM 메인 프레임 등에서 구현된 기술에서 구현되기에는 너무나 고사양 스팩이였던 것도 사실이다.

그러나 대중적인 서버를 모토로한 Windows NT와 Linux의 등장으로 기술의 장벽과 난이도는 낮아지기 시작했다. 즉, 고가의 유닉스 서버를 쓰지 않고, 고가의 유닉스 프로그램을 구매하지 않아도 되는 공짜 혹은 수백만원 때의 OS와 프로그램이 등장한 것이다. 덕분에 하이엔드 금융권 서버의 기술이 온라인 게임이나 저가형 웹 서버에도 도입될 수 있는 길이 열린 것이다. 그러나 이런 기술은 아직까지 기술적인 난이도나 많은 투자와 숙달이 필요하기 때문에 일부 고급 서버 프로그래머들과 엄청난 고스톱 머니와 포커 머니가 오고 가는 대형 포털에서 구현되고 있다

 

지금까지 백 서비스가 일어나는 상황에 대해서 이야기를 했다. 백 서비스가 일어나는 원인을 간단하게 정리해보자.

첫째, 온라인 게임 서버 프로그램의 불안정
둘째, OS의 불안정
셋째, 네트워크의 불안정
넷째, 서버 하드웨어의 불안정
다섯째, 해킹과 스피드 핵
여섯째, 이유를 알 수 없음

많은 경우가 바로 게임 서버 프로그램이 불안정하기 때문이다. 대단위 유저가 리얼 타임으로 접속하고 전투하고 퀘스트를 진행한다. 기획은 어찌나 더디고 미완성인지 새로운 기능은 거의 리얼 타임으로 업그레이드 된다. 웬만한 금융권 프로그래밍이나 기업 프로그래밍의 경우 완성 후 몇 달 동안 안정화 테스트를 거치고 사용자들이 서비스를 이용한다.

온라인 게임은 유저의 만족감과 완성도를 높이기 위해 수시로 패치가 진행되다 보니 버그나 잠재적인 버그가 속출하게 된다. 이런 버그 중 즉각 반응을 보이지 않고 있던 버그가 또 다른 버그와 만나면 상승 작용을 일으켜 다운되는 현상을 불러온다. 서버 프로그래머로써는 미치는 일인 것이다. 원래 정상적인 개발 플로우라면 Close Beta에서 내부자와 전문 디버깅 유저를 동원하여 대부분의 버그를 잡고 안정화를 해야 하는 것이 정상이다.

그러나 한국의 특수성으로 인해 오픈 베타라는 이름으로 고객을 상대로 버그가 잡힐 때까지 테스트를 하는 것이다. 고객이 게임을 무료로 즐기는 대가로 버그 발견을 유저의 손에 맡긴 것이다. 일부 개발사들은 테스트 서버를 두고 일정 시간 안정화가 확인된 후 패치를 올리는 식으로 안정화를 꾀하기도 하지만 많은 개발사는 베타 유저를 마루타로 삼고 있는 것이다.

OS의 불안정은 정말 끔찍한 상황이다. 운영체제의 버그로 온라인 게임이 죽는 경우를 몇 번 봤는데 이 경우는 개발자가 할 일이 거의 없다. 공개 운영체제인 Linux의 경우 커널 (운영체제의 핵심 구현부)를 볼 수 있다면 수정 가능하지만 윈도우나 상용 OS의 경우 버그 패치가 나올 때까지 땜빵 처방이나 운에 맡길 수밖에 없다. (프로그래머로서는 좌절감이 드는 순간이다.) 그러나 요즘 OS의 안전화로 이런 경우는 점점 더 줄어들고 있다.

네트워크 불안정의 대표적인 예는 모 IDC(온라인 게임 서버가 모여 있는 서비스 센터)의 정전 사태를 들 수 있다. 덕분에 모 IDC에 입주했던 온라인 게임은 돈으로도 환산할 수 없는 엄청난 피해를 입었다. IDC는 지진, 태풍, 정전에 대비하여 지어진 인터넷 서비스를 위한 건물이라 이런 사태를 피할 수 있어야 하지만 예외적인 상황으로 재앙에 가까운 사태도 맞을 수 있다. 이런 경우는 길을 가다가 벼락을 맞을 확률에 가깝긴 하지만 아예 없지는 않다.

IDC의 하드웨어 장비의 고장으로 서비스가 중지되거나 장비 셋팅의 실수로 네트워크가 느려지는 경우도 밖으로 알려지지 않지만 없지는 않은 백 서비스 원인 중 하나이다.

해킹과 스피드 핵은 정말로 개발자에게 생각조차 하기 싫은 상황 중 하나이다. 최근 자동화된 해킹 툴이 많이 나와서 전문적인 지식 없이 원 클릭만으로 게임 서버를 죽이거나 서비스에 지장을 줄 수 있게 되었다.

해킹 툴을 구하거나 해킹을 하는 방법에 대해서는 워낙 위험하기 때문에 정확하게 기술하지는 않지만 이는 매우 위험한 일이다.

경고한다!
첫째, 해킹 툴에는 트로이 목마처럼 수상한 기능이 숨어 있을 수 있다.
둘째, 바이러스에 오염되어 있을 수 있다.
셋째, 추적이 가능하다. 범죄자로 검거될 수 있다.

해킹 툴은 해커들이 만든 프로그램이다. 그런데 일부 불순한 해커들이 툴을 사용하는 순진한 초보 유저의 PC를 점거하거나 해킹의 중간 경유지로 사용하기 위해 악성 프로그램을 숨기는 경우가 있다.

이런 해킹 툴 속의 악성 코드는 전문가가 아니면 확인하기 힘들 뿐 아니라 순진한 ‘초보’ 해커에게 심각한 피해를 입힌다.

개발 중 너무 급하게 개발되어 에러 사항에 대한 예외 처리가 생략되어 있을 경우 과도한 스피드 핵에도 서버가 다운된다. 스피드 핵이란 사용자가 이동을 빠르게 하거나 공격을 빠르게 하기 위해 편법으로 사용하는 프로그램을 지칭한다. 서버가 초당 100번의 걷기 명령을 처리를 한다고 가정했을 때 10배로 빨리 걷게 만들려고 한다면 초당 일천 번의 걷기 명령 처리가 가능하다. 서버에서 이런 예외 처리 프로그래밍이 약하거나 네트워크 대역폭을 넘어 설 경우 서버는 다운된다.

이럴 경우 개발자와 개발사는 스피드 핵을 막기 위한 프로그램을 구매하거나 로직을 구현하는 방법으로 문제를 해결한다. 스피드 핵은 게임 서버 전체의 서버 성능을 떨어트리는 일이기 때문에 다른 유저를 배려한다면 하지 말아야 할 행동 중 하나이다. 위에서 이야기했듯이 이런 해킹, 스피드 핵 프로그램에는 트로이 목마형 해킹 프로그램이 숨겨져 있을 가능성도 많기 때문에 사용에 따른 손실은 유저 스스로가 책임져야 할 것이다.

마치는 말
백 서비스는 온라인 게임이 상용화되기 위한 진통이라고 볼 수 있다. 그러나 충분한 개발을 보장한다면 막을 수 있는 백 서비스가 많은 것도 현실이다. 오픈 베타 유저들도 언젠가는 돈을 내고 게임을 즐길 잠재적인 고객이다.

개발사들은 백 서비스에 대한 온라인 게임의 안정적인 처리가 오픈 베타 유저들을 위한 배려일 뿐 아니라 빠른 시간 내에 상용화로 가는 지름길이라는 것을 잊지 말아야 할 것이다.

'ETC > 게임 이야기' 카테고리의 다른 글

FF3 LV 테이블 및 JOB 베이직 테이블  (0) 2010.10.13
FF3 난수 테이블  (0) 2010.10.13
FF3 기본 스텟 및 전투 시스템  (0) 2010.10.13
Final Fantasy 3 (FF3) 소개  (0) 2010.10.13
디아2 앵벌과 매찬  (0) 2010.10.13
백섭이란? 백섭에 대해서...  (0) 2010.10.13
안정적인 DNS서비스 DNSEver DNS server, DNS service
Posted by 키르히아이스

댓글을 달아 주세요


출처 : http://cafe.naver.com/htc/75746

Bootanimation.zip File Explained

Back when I had some interest in doing a custom boot animation, I read different posts about what the contents of the bootanimation.zip file meant. I came across some info that explains it pretty well.


In 2.0, the android boot animation has been changed to enable easy replacement or customization.

There is a file called bootanimation.zip stored in /system/media/ in the root file system (or /data/local). This file contains two things:

1) A description file (desc.txt) that outlines how the animation progresses, what images to use, image size etc.
2) Folder(s) that contain the images for the animation.

The basic structure of the bootanimation.zip file is as follows:

bootanimation.zip
|-- desc.txt
|-- part0
`-- part1


part0 and part1 are directories that contain a series of images for example, in part 0 there is:

part0
|-- boot_00001.png
|-- boot_00002.png
|-- boot_00003.png
|-- boot_00004.png
|-- boot_00005.png
|-- boot_00006.png
|-- boot_00007.png
|-- boot_00008.png
|-- boot_00009.png
`-- boot_00010.png

And in part 1 there are:

part1
|-- boot_00011.png
|-- boot_00012.png
|-- boot_00013.png
|-- boot_00014.png
|-- boot_00015.png
|-- boot_00016.png
|-- boot_00017.png
|-- boot_00018.png
|-- boot_00019.png
`-- boot_00020.png

These images form the 'part0' and 'part1' animations that are combined as outlined in the 'desc.txt' file to form the overall startup animation. The images are ordered by number and run in sequence.
The 'desc.txt' file outlines how the animation progresses and a sample is as follows:

512 256 30
p 1 0 part0
p 0 0 part1

'523' is the width of the animation
'256' is the height of the animation
'30' is the desired fps of the animation
'p' defines a animation part
'1' how many times this animation part loops
'0' defines a pause (max 10)
'part0' is the folder name where the animation images are
'p' defines another animation part
'0' defines that it loops forever (until android starts)
'0' defines a pause
'part1' is the folder for the second animation part.

Hope this helps those looking to create their own boot animations.
 
안정적인 DNS서비스 DNSEver DNS server, DNS service
Posted by 키르히아이스

댓글을 달아 주세요

  1. 브주듀 2011.04.10 11:14 신고  댓글주소  수정/삭제  댓글쓰기

    설명대로 해봤는데 문제가 있더라고요.. (원본링크 참조)
    해결 어떻게 하면 될까요.?


    아.. 권한주고 "무압축"으로 하니 되는군요.


출처 : http://wiki.kldp.org/wiki.php/AndroidPortingOnRealTarget/ko


1 Introduction


구글은 안드로이드가 운영체제, 미들웨어 그리고 중요 프로그램을 포함하는 임베디드 디바이스를 위한 소프트웨어 스택이라고 설명합니다. 이 문서는 구글 안드로이드 아키텍처에 대해 설명하고 실제 하드웨어에 포팅하는 절차를 설명합니다. 설명은 안드로이드 에뮬레이터의 m3 SDK 버전에 기초해서 설명합니다.

여러분이 커널 패치, 패치의 거부 해결, 램디스크 이미지 만들기, 리눅스 커널 자체에 대한 충분한 지식을 가지고 있다면 이 아티클은 쉬울 것입니다.

2 Copyright and Acknowledgements


이 문서의 소유권은 Kwangwoo Lee <Kwangwoo.lee@gmailREMOVETHIS.com> 에게 있습니다. 이 문서에 대한 복사, 배포, 수정에 대한 권리는 GNU Free Documentation License 를 따릅니다.

번역은 양정석(dasomoli@gmailREMOVETHIS.com) 이 하였습니다만, 이상한 곳이 있다면 가차없이 수정해 주세요. :) 원문 : http://wiki.kldp.org/wiki.php/AndroidPortingOnRealTarget

3 안드로이드 아키텍처의 요약 분석


3.1 안드로이드 커널


안드로이드 커널의 가장 큰 차이점은 ARM EABI(Embedded Application Binary Interface)와 OpenBinder IPC(Inter Process Communication)를 사용한다는 것입니다. 여러분이 ARM EABI를 지원하는 커널을 컴파일하려면, ARM EABI를 지원하기 위한 툴체인(toolchains)을 새로 빌드하여야 합니다.

안드로이드 SDK는 Qemu를 사용하여 goldfish 아키텍처를 에뮬레이션합니다. alsa는 안드로이드의 오디오를 위해서 사용됩니다. goldfish 아키텍처 디렉토리의 audio.c 파일을 보고, 드라이버는 안드로이드 시스템 상의 오디오를 위한 /dev/eac를 사용합니다. 또한 RTC(Real Time Clock) 장치는 /dev/rtc0를 통해 사용됩니다.

다음 파트들은 주된 차이점을 설명합니다:

3.1.1 ARM EABI


EABI는 ARM사(ARM Ltd.)에 의한 새로운 "임베디드" ABI입니다. 그 차이는 데비안 위키에 정리되어 있습니다.

  • FPU를 쓰거나 쓰지 않는, 빠른 실수 연산(floating point) 성능
  • soft 와 hardfloat 코드의 혼용 가능
  • 이전에 사용되어지던 것과 같이 구조체 팩킹(packing)이 고통스럽지 않습니다.
  • 다른 툴들과의 더 나은 호환성(compatibility)
  • 더 효율적인 syscall 관례(convention). (http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=3105/4)

long ftruncate64(unsigned int fd, loff_t length); 의 예:

기존 ABI:
- put fd into r0 (fd를 r0로 넣음)
- put length into r1-r2 (길이를 r1-r2로 넣음)
- 커널 호출을 위해서 "swi #(0x900000 + 194)" 사용.

새로운 ARM EABI:
- put fd into r0 (fd를 r0로 넣음)
- put length into r2-r3 (skipping over r1) (길이를 r2-r3로 넣음. r1은 무시)
- put 194 into r7 (194를 r7로 넣음)
- use "swi 0" to call the kernel (커널을 호출하기 위해서 "swi 0" 사용)

안드로이드는 EABI 커널 기능을 사용합니다. CONFIG_AEABI 와 CONFIG_OABI_COMPAT의 커널 옵션을 활성화 하세요. 여러분은 다음과 같은 실행 바이너리의 차이를 볼 수 있습니다:

  • 기존 ABI
$ arm-softfloat-linux-gnu-objdump -x t7-demo | grep private
private flags = 202: [APCS-32] [FPA float format] [software FP] [has entry point]

$ file t7-demo
t7-demo: ELF 32-bit LSB executable, ARM, version 1 (ARM), 
for GNU/Linux 2.4.3, dynamically linked (uses shared libs), 
for GNU/Linux 2.4.3, stripped

  • ARM EABI
$ arm-softfloat-linux-gnueabi-objdump -x t7-demo  | grep private
private flags = 4000002: [Version4 EABI] [has entry point]

$ file t7-demo
t7-demo: ELF 32-bit LSB executable, ARM, version 1 (SYSV), 
for GNU/Linux 2.6.14, dynamically linked (uses shared libs), 
for GNU/Linux 2.6.14, stripped


ARM 아키텍처를 위한 ABI가 무엇인가요? ARM EABI와 같은 건가요?

ARM 아키텍처의 ABI는 ARM와 (CodeSourcery를 포함하는) 그 파트너들에 의해 개발된 어떻게 컴파일러와 어셈블러와 링커와 다른 비슷한 툴들이 Object 파일과 실행 파일을 생성해야만 하는지를 설명하는 표준입니다. ARM 아키텍처의 ABI를 정확히 구현한 툴들은 상호 운용(interoperate)될 수 있습니다:예를 들면, 다른 툴체인에서 빌드된 Object 파일과 또 다른 툴체인에서 빌드된 Object파일이 양 쪽의 컴파일러가 ARM 아키텍처의 ABI를 사용한다면 함께 합쳐질 수 있습니다. "ARM EABI"는 ARM 아키텍처 ABI의 또다른 이름입니다.

3.1.2 OpenBinder


OpenBinder는 객체지향(object-oriented) 운영체제 환경을 제공합니다. 전통적인 커널에 호스팅(to be hosted)되어지도록 설계되었습니다. 이 프로젝트는 BeOS 다음번 생성의 일부로 Be. Inc에서 시작되었고, Cobalt 시스템의 코어 부분으로 PalmSource에 구현이 완료되었습니다. 그 것은 시스템이 Application에 지향보다는 컴포넌트 아키텍처에 지향적이고, 프로세스 간의 IPC, 스레드풀, 메모리 관리와 클린 업(clean up) 기능을 바인더 Obejct의 참조의 끝에서 제공합니다. 바닐라(vanilla) 커널은 OpenBinder IPC 메카니즘을 가지고 있지 않으므로, 여러분은 커널에 패치하여야 합니다. OpenBinder는 시스템의 스레드 관리를 /dev/binder를 통해서 제공합니다. 그 것이 안드로이드가 스레드 라이브러리를 제공하지 않는 이유입니다.

커널 패치 후에, 여러분은 /drivers/binder/에서 바인더를 위한 파일을 볼 수 있을 것입니다.

3.1.3 프레임 버퍼


기본적인 프레임 버퍼 드라이버는 이미 구현되어져 있어야만 합니다. 그 후에 여러분은 여러분의 아키텍처 드라이버와 goldfish 드라이버 간의 차이를 구현해야 할 것입니다.

goldfish 아키텍처의 프레임 버퍼 드라이버는 struct fp_ops의 fb_pan_display 함수를 지원합니다. 그 것은 실제 프레임 크기보다 두 배의 메모리가 할당되어야 함을 의미합니다.

  • 프레임 버퍼 정보 초기화
struct fb_info *fbinfo;
...
fbinfo->fix.ypanstep	= 1;
fbinfo->var.yres_virtual    = gm->lcd.yres * 2;
fbinfo->fix.smem_len        =	(gm->lcd.xres *
                                gm->lcd.yres *
                                gm->lcd.bpp / 8) * 2;

  • 프레임 버퍼 메모리 할당
struct mvfb_info *fbi;
...
fbi->map_size = PAGE_ALIGN(fbi->fb->fix.smem_len + PAGE_SIZE);
fbi->map_cpu  = dma_alloc_writecombine(fbi->dev, fbi->map_size,
                                       &fbi->map_dma, GFP_KERNEL);

  • fb_pan_display 함수 후킹 구현
static int mvfb_pan_display(struct fb_var_screeninfo *var, struct fb_info *fb)
{
...
}

static struct fb_ops mvfb_ops = {
        .owner		= THIS_MODULE,

        .fb_check_var	= mvfb_check_var,
        .fb_set_par	= mvfb_set_par,	
        .fb_setcolreg	= mvfb_setcolreg,
        .fb_blank	= mvfb_blank,
        .fb_pan_display = mvfb_pan_display,

        .fb_fillrect	= cfb_fillrect,
        .fb_copyarea	= cfb_copyarea,
        .fb_imageblit	= cfb_imageblit,

        .fb_mmap	= mvfb_mmap,	
};

그 디바이스 파일은 /dev/graphics/fb0에 위치해 있습니다.

3.1.4 입력 장치


안드로이드는 사용자 입력을 위한 이벤트 디바이스를 사용합니다. 거기에는 키패드와 쿼티2(qwerty2) 키보드와 마우스와 같은 세가지 디바이스가 있습니다. 쿼티2(qwerty2) 키보드와 마우스는 보통 디바이스입니다. 그래서 마우스 디바이스를 대체하는 키패드와 터치스크린을 설명하겠습니다.

안드로이드 쉘에서 /proc/bus/input/{devices,handlers}를 cat 하면, 안드로이드에서 사용되는 디바이스들을 볼 수 있습니다.
$ adb shell

# cat /proc/bus/input/devices
I: Bus=0000 Vendor=0000 Product=0000 Version=0000
N: Name="goldfish-events-keyboard"
P: Phys=
S: Sysfs=/class/inut/input0
U: Uniq=
H: Handlers=kbd mouse0 event0
...
#
# cat /proc/bus/input/handlers
N: Number=0 Name=kbd
N: Number=1 Name=mousedev Minor=32
N: Number=2 Name=evdev Minor=64
#

  • 키패드
Qemu는 goldfish-events-keyboard를 에뮬레이트합니다. 그 것은 이벤트 디바이스(/dev/input/event0)를 사용하는 키패드입니다. 그래서 여러분은 이벤트 디바이스로부터 실제 활성화된 안드로이드 프로그램으로 전달되어지는 키 이벤트의 종류와 값을 알 수 있습니다. 그렇게 하기 위해서 event0 디바이스를 cat으로 읽고 파일로 그 출력을 재지정(redirect)합니다. 만약 에뮬레이터 상의 키 버튼이 눌리고 떼어지면 그 출력 값이 저장될 것입니다.

그 출력 형식은 input_event 구조체 입니다. 그래서 각 event의 출력은 시간을 위한 8 바이트, 타입을 위한 2 바이트, 코드를 위한 2 바이트, 값을 위한 4바이트로 총 16 바이트입니다. 리눅스 커널 소스 코드의 Documentation/input 디렉토리의 입력 이벤트 디바이스(input event device)에 관한 input.txt를 읽고, input-programming.txt를 읽으세요.
struct input_event {
        struct timeval time;
        unsigned short type;
        unsigned short code;
        unsigned int value;
};

Tiger7 개발 보드는 그 고유의 scancode 테이블을 가집니다. 다음은 개발보드의 키 레이아웃과 scancode 테이블과 안드로이드 키 코드를 보입니다:
/*
 *  Key Layout       Scancode Table
 *
 *   1  2  3        0x1  0x10  0x100
 *   4  5  6        0x2  0x20  0x200
 *   7  8  9        0x4  0x40  0x400
 *   *  0  #        0x8  0x80  0x800
 */

static unsigned short android_keycode[] = {
        /*
         *  0x66 0x67 0x9e	Home  Up   Back
         *  0x69 0xe8 0x6a	Left  Ok   Right
         *  0xe7 0x6c 0x6b	Send  Down Hangup
         *  0xe5		Menu       just_distinction_for_private
         */
        KEY_HOME,         KEY_UP,       KEY_BACK,
        KEY_LEFT,         KEY_REPLY,    KEY_RIGHT,
        KEY_SEND,         KEY_DOWN,     KEY_END,
        KEY_KBDILLUMDOWN, KEY_RESERVED, KEY_PLAY
};

에뮬레이터에는 전원(power) 버튼이 있습니다. 그러나 출력 값을 얻기 위해서 무시했습니다.

키패드의 인터럽트가 감지(caught)되면 위 테이블의 안드로이드의 키 코드로 scancode를 변환하고 사용자 공간(user space) 프로그램으로 이벤트를 보냅니다.
...
keycode = translate_keycode(scancode);
...
input_event(keydev->input, EV_KEY, keycode, KEY_PRESSED);
or
input_event(keydev->input, EV_KEY, keycode, KEY_RELEASED);
...

고정밀도 타이머 - hrtimer는 키패드 debounce를 줄이기 위해서 사용되었습니다.

  • 터치 스크린

포인팅 디바이스를 위한 이벤트 인터페이스를 지원하는 터치스크린 드라이버를 갖고 있다면, 잘 동작할 것입니다. 그렇지 않다면, 다른 포인팅 디바이스를 사용하거나 구현해야 합니다. 다행스럽게도 개발보드는 이미 안드로이드 포팅을 시작하기 전에 만들어진 터치스크린 드라이버 - drivers/input/touchscreen/tsc2007.c -가 구현되어 있었습니다. 여러분 고유의 드라이버를 구현하기 위해서는 drivers/input/touchscreen/ 의 드라이버와 Documentation/input/의 텍스트 파일을 참고하세요.
여기 개발 보드 상의 /proc/bus/input/{devices,handlers}의 출력이 있습니다.
# cat /proc/bus/input/devices
I: Bus=0000 Vendor=0000 Product=0000 Version=0000
N: Name="MVT7 KEYPAD"
P: Phys=
S: Sysfs=/class/input/input0
U: Uniq=
H: Handlers=kbd event0 evbug
B: EV=f
...

I: Bus=0000 Vendor=0000 Product=0000 Version=0000
N: Name="TSC2007 Touchscreen"
P: Phys=0-0090/input0
S: Sysfs=/class/input/input1
U: Uniq=
H: Handlers=event1 evbug
B: EV=b
B: KEY=400 0 0 0 0 0 0 0 0 0 0
B: ABS=1000003

# cat /proc/bus/input/handlers
N: Number=0 Name=kbd
N: Number=1 Name=evdev Minor=64
N: Number=2 Name=evbug

결과에서 보는 것과 같이, 프로그램 계층(application layer)에서 키패드는 /dev/input/event0를 사용하고, 터치스크린 인터페이스는 /dev/input/event1를 사용합니다.

3.1.5 Low Memory Killer


리눅스 커널은 프로세스의 요청을 위한 할당을 위해서 남은 메모리가 없는 상황을 위한 OOM(Out of Memory) 킬러를 가지고 있습니다. 그 것은 모든 프로세스를 시험하고 어떤 제약으로 점수를 매깁니다. 최고 점수의 init을 제외한 프로세스는 죽여집니다.

안드로이드의 Low Memory Killer는 OOM 킬러와 약간 다릅니다. 그 것은 그룹의 중요성에 따라 프로세스를 분류하고 가장 낮은 그룹의 프로세스를 죽입니다. 그 것은 시스템을 최종 사용자(end user) 관점에서 안정적이게 만듭니다. 예를 들면, UI 프로세스 - foreground process -는 최종 사용자에게 가장 중요한 프로세스입니다. 그래서 프로세스를 지키는 것은 다른 background 프로세스의 삶을 지키는 것보다 더 안정적으로 보이는 것을 살립니다.

커널 패치 후에 CONFIG_LOW_MEMORY_KILLER 를 활성화하세요.

3.1.6 안드로이드 로거(Android Logger)


여러분이 이 기능을 활성화하면 /dev/log/main를 통해 안드로이드에 관한 유용한 정보를 볼 수 있습니다. main, events, radio 같은 /dev/log 상의 세가지 디바이스 파일이 있습니다. /dev/log/radio 파일은 안드로이드 시스템 상의 모뎀과 ril 데몬 - rild - 에 관련된 것을 보여줍니다.

이 로거를 활성화할때, 시스템 성능은 시스템 상에서 약간 느려집니다. 이 기능을 사용하기 위해서 CONFIG_ANDROID_LOGGER를 활성화하세요.

3.1.7 안드로이드 파워(Android power)


안드로이드 파워는 디바이스 상의 배터리 관리과 전원 관리에 관련된 파일 시스템 상의 inotify 기능과 같은 서브시스템을 위한 것입니다. 그 것은 안드로이드 시스템의 init 바이너리를 통해 안드로이드를 시작하기 위해서 필요합니다. 그러나 runtime 바이너리는 안드로이드의 수동 시작 상에서 안드로이드 파워에 따르는 어떤 파일 - /sys/android_power/acruire_partial_wake_lock - 을 찾고 시작에 실패합니다. 사용하기 위해서는 CONFIG_ANDROID_POWER 옵션을 활성화시키세요.

3.1.8 Panic Timeout


개발 보드 상의 안드로이드 시작을 위해서 필요없습니다. CONFIG_PANIC_TIMEOUT 를 원하는 값으로 설정하세요.

3.2 안드로이드 루트 파일 시스템


안드로이드 에뮬레이터는 tools/lib/images디렉토리 상에 3개의 기본 이미지를 가집니다.

  • ramdisk.img
  • system.img
  • userdata.img

ramdisk.img 은 gzip으로 압축된 cpio 파일입니다. 램디스크 이미지는 매우 작고, 설정 파일과 init과 recovery 같은 실행파일을 포함합니다. init 파일은 정식 System V init은 아닙니다. 그 것은 안드로이드를 위해 만들어졌고, 안드로이드 시스템을 시작하기 위한 특별한 것을 수행합니다.

system.img 와 userdata.img 는 VMS Alpha 실행파일입니다. system.img와 userdata.img 는 루트 파일 시스템 상의 /system 과 /data 디렉토리의 내용을 가집니다. 그들은 NAND 디바이스 상에 yaffs2 파일 시스템으로 맵핑되어 있습니다. /dev/block/mtdblock0 는 /system 이고, /dev/block/mtdblock1 은 /data 입니다.

/system 디렉토리는 라이브러리와 기본 시스템 패키지(*.apk)를 가지고 있습니다. /data 디렉토리는 타임존, 캐쉬, ApiDemos.apk 패키지를 가지고 있습니다.

주 서비스는 zygote(/system/bin/app_process), runtime(/system/bin/runtime), 그리고 dbus(/system/bin/dbus-daemon) 입니다. 여러분은 안드로이드 램디스크 상의 /etc/init.rc 파일을 볼 수 있습니다.

...
zygote {
    exec /system/bin/app_process
    args {
        0 -Xzygote
        1 /system/bin
        2 --zygote
    }
    autostart 1
}
runtime {
    exec /system/bin/runtime
    autostart 1
}
...
dbus {
    exec /system/bin/dbus-daemon
    args.0 --system
    args.1 --nofork
    autostart 1
}
...

3.3 안드로이드 패키지의 라이센스


tools/lib/images/NOTICE 는 패키지 리스트와 각 라이브러리의 라이센스를 포함하고 있습니다. 라이센스 표는 2008 Korea Android Summit에서 임근식 씨의 발표로부터 게시되었습니다.

Open Source License
Linux Kernel GPL
NetBSD C Library BSD
DBUS GPL2
OpenBinder (core) GPL2
YAFFS2 GPL
SQLite GPL2
Webkit BSD (including LGPL)
WebCore LGPL
SDL LGPL
SGL Google(Skia)
OpenGL SGI OpenGL (BSD/MPL)


4 ARM EABI를 지원하는 툴체인


툴체인은 시스템 개발에 사용되어지는 툴들을 말합니다. C/C++ 컴파일러, 링커, 라이브러리, binutils와 기타 다른 것들을 포함합니다. 안드로이드 커널과 시스템은 EABI 지원을 필요로 합니다. 그래서 기존 툴체인은 안드로이드 시스템을 만드는데 호환되지 않습니다.

4.1 툴체인 빌드하기


더 쉽게 삶을 살기 위해서, Dan Kegel에 의한 crosstool-0.43 스크립트(http://www.kegel.com/crosstool/ )를 사용했습니다. 불행히도 그 것은 eabi 툴체인을 빌드하기 위한 지원을 하지 않습니다. 그래서 Khem Raj의 a glibc 2.5+ nptl build for arm softfloat eabi patch (http://sources.redhat.com/ml/crossgcc/2006-12/msg00076.html )를 적용했습니다.
$./arm-softfloat-eabi.sh

네트워크가 연결되어 있다면, 스크립트가 gcc 4.1.1 과 glibc 2.5을 사용해서 툴체인을 다운로드하고 빌드해 줄 겁니다.

4.2 다른 툴체인


Codesourcery 툴체인을 사용하지 않았습니다만, 그들은 그 것이 안드로이드 시스템 빌드를 위해서 잘 동작할 것이라고 말하고 있습니다.


5 커널


실제 하드웨어 상에 안드로이드를 포팅하는 것은 Benno (http://benno.id.au )에 의해서 시작되었습니다. 여러분은 그의 블로그에서 유용한 정보를 볼 수 있습니다. 그의 블로그는 pre-compiled static binaries를 링크합니다. 그것은 안드로이드 시스템 디버깅에 매우 유용합니다. 여러분 역시, static build busybox와 strace 바이너리를 빌드할 수 있지만, 갖다 쓰는 게 더 좋을 겁니다.

여러분은 안드로이드 커널과 바닐라 커널 2.6.23 버전 사이의 차이를 포함한 패치 파일을 얻을 수 있습니다. 그 것은 그것들 사이의 모든 차이를 가집니다. 그래서 여러분은 그것들의 일부를 추출할 필요가 있고, 여러분의 시스템 아키텍처를 위한 여러분 고유의 패치를 만들 수 있습니다.

예를 들면, 안드로이드 커널은 그 고유의 yaffs 파일 시스템 패치를 가집니다. 여러분의 아키텍처상에서 여러분 고유의 yaffs 나 jffs2 같은 어떤 다른 파일 시스템을 가진다면, yaffs 패치의 일부를 제거해야 합니다. 안드로이드 커널이 에뮬레이트하는 qemu 상의 ARM 아키텍처의 goldfish 아키텍처는 여러분의 아키텍처의 일부가 될 필요가 없습니다. 제거 될 수 있습니다.

안드로이드 커널은 ARMv5 명령을 에뮬레이트합니다. 그래서 ARM926EJ-S (ARMv5TEJ)는 작업하기 매우 좋을 겁니다.

5.1 커널 패치


Benno 는 openmoko의 NEO1973 디바이스로 작업했습니다. 그래서 그는 그 것을 위한 패치 파일을 만들었습니다. http://benno.id.au/blog/2007/11/21/android-neo1973 에서 원본 패치 파일을 얻고, android.diff를 사용했습니다. 그 것은 goldfish, qemu, yaffs 그리고 안드로이드에 특정적인 부분에 관한 전부를 가지고 있습니다.

여러분은 직접 패치 파일을 편집하고 제거할 수 있습니다. goldfish와 qemu에 특정적인 부분을 제외한 binder, 안드로이드 파워, 안드로이드 로거, low memory 킬러를 포함하는 패치를 만든 후에 바닐라 리눅스 커널 2.6.23을 얻고, 그 걸로 패치하세요.

여러분이 2.6.24.1 버전 리눅스 커널을 사용한다면 안드로이드 파워에 관련된 부분이 동작을 위해서 비활성화 되거나 적절히 고쳐져야 합니다.

5.2 .config


  • 필수적인 부분
...
CONFIG_PANIC_TIMEOUT=0
CONFIG_AEABI=y
CONFIG_OABI_COMPAT=y
CONFIG_BINDER=y
CONFIG_LOW_MEMORY_KILLER=y
...

  • 필요에 따른 부분
...
# CONFIG_ANDROID_GADGET is not set
# CONFIG_ANDROID_RAM_CONSOLE is not set
# CONFIG_ANDROID_POWER is not set
# CONFIG_ANDROID_LOGGER is not set
...

6 루트 파일 시스템


루트 파일 시스템은 램 상의 기본 램디스크 이미지, NAND dev0 (/dev/block/mtdblock0) 그리고, NAND dev1 (/dev/block/mtdblock1)의 자료 이미지, 세가지 부분으로 제작되어 있습니다. MTD 디바이스는 yaffs2 파일 시스템을 가지고 각각은 안드로이드 에뮬레이터 상에서 64MiB 용량을 가집니다.

추출된 system 과 data 디렉토리는 실제 존재하는 NAND 디바이스 상에 복사되었고, 그들은 실제 하드웨어에서 동작시키기 위해서 --bind 옵션으로 마운트되어졌습니다.

6.1 에뮬레이터에서 램디스크 이미지 얻기


1. tools/lib/images/ramdisk.img에서 ramdisk 이미지를 unpack
$ gzip -cd ramdisk.img > ramdisk
$ cpio -iv -F ramdisk

cpio 는 현재 작업중인 디렉토리상에 파일과 디렉토리를 푼다.

2. 램디스크의 내용 목록

data
dev
etc
etc/default.prop
etc/firmware
etc/firmware/brf6150.bin
etc/firmware/brf6300.bin
etc/hcid.conf
etc/hosts
etc/init.gprs-pppd
etc/init.rc
etc/init.ril
etc/init.testmenu
etc/ppp
etc/ppp/chap-secrets
etc/ppp/ip-down
etc/ppp/ip-up
etc/qemu-init.sh
etc/system.conf
etc/system.d
etc/system.d/bluez-hcid.conf
etc/usbd.conf
init
proc
sbin
sbin/recovery
sys
system
tmp
var
var/run

6.2 에뮬레이터에서 data와 system 디렉토리 얻기



data와 system 디렉토리를 얻기 위해서 여러분은 busybox 바이너리를 static 컴파일하여야 합니다. 컴파일된 바이너리는 http://benno.id.au/blog/2007/11/14/android-busybox 에서 얻거나, 여러분 고유의 바이너리를 만들 수 있습니다.

1. 안드로이드 에뮬레이터를 실행시키세요.

2. 에뮬레이터 안에 static 컴파일된 busybox를 넣으세요.
# adb push busybox .

3. 안드로이드 쉘을 실행시키세요.
# adb shell

4. busybox로 tarball을 만드세요.
# chmod +x /busybox
# busybox tar -c /data.tar /data
# busybox tar -c /system.tar /system
# exit

5. 에뮬레이터에서 tarball을 추출하세요.
# adb pull /data.tar .
# adb pull /system.tar .

추출 명령은 종종 실패합니다. 성공적으로 될 때까지 계속 실행하세요.

6.3 존재하는 램디스크 이미지로 안드로이드 시스템을 통합하기


여러분의 아키텍처의 램디스크는 여러분의 작업을 조금 더 쉽게 만듭니다. system과 data 디렉토리를 제외한 안드로이드 램디스크의 내용을 여러분 고유의 램디스크로 복사하세요. 그리고 그냥 system과 data 디렉토리의 마운트 지점을 만드세요. 마운트 지점은 나중에 bind 옵션으로 사용될 수 있습니다. 안드로이드 램디스크 이미지의 init 바이너리는 시스템을 시작하기 위한 중요 바이너리이고, 그것은 /etc/init.rc 파일 상에서 설정 파일을 읽습니다.

/etc/init.rc를 편집하고 qemu 부분을 주석으로 만드세요.
...
startup {
        ...
#       qemu-init {
#           exec /etc/qemu-init.sh
#       }
}
...

run.sh 스크립트를 만드세요. /dev/block/mtdblock5는 실제 NAND 디바이스의 mtd 파티션이고, 그 것은 /mnt 상에 마운트되어 집니다. data와 system 디렉토리는 이미 mtdblock5 상에 복사되어져 있습니다. 그래서 그 스크립트는 아래와 같이 / 상의 각 디렉토리의 바인드 마운팅(bind mounting)을 보입니다. 여러분의 보드 설정에 따라 스크립트를 고치세요.
#!/bin/sh
mount -t yaffs /dev/block/mtdblock5 /mnt
mount --bind /mnt/data   /data
mount --bind /mnt/system /system

# data folder is owned by system user on emulator. Fix 777 to other.
chmod 777 /data
#chmod 777 /system

export PATH=/system/sbin:/system/bin:/sbin/usr/local/bin
export LD_LIBRARY_PATH=/system/lib

export ANDROID_BOOTLOGO=1
export ANDROID_ROOT=/system
export ANDROID_ASSETS=/system/app
export EXTERNAL_STORAGE=/sdcard
export ANDROID_DATA=/data
export DRM_CONTENT=/data/drm/content

/init &

터치스크린을 위한 필요에 따른 설정 - TSLib.
...
export TSLIB_CONSOLEDEVICE=none
export TSLIB_FBDEVICE=/dev/fb0
export TSLIB_TSDEVICE=/dev/input/event1
export TSLIB_CALIBFILE=/etc/pointercal
export TSLIB_CONFFILE=/etc/ts.conf
export TSLIB_PLUGINDIR=/lib/ts

export LD_PRELOAD=/lib/libts.so:/lib/ts/pthres.so
...

6.4 System 과 data 디렉토리


system 과 data 디렉토리의 내용은 이미 mtdblock5에 이미 복사되어져 있습니다. 여러분은 여러분 고유의 방법으로 복사하셔야 합니다. 그것을 사용하기 위해서 저는 루트 디렉토리상에 바인드 마운팅(bind mounting)을 선택했습니다. 바인드 마운팅은 이미 존재하는 디렉토리를 새로운 마운트 포인트로 마운트하는 기술입니다.

6.5 실행과 디버그


이제 커널과 램디스크와 자료 디렉토리 - data와 system -이 준비되었습니다. 빨간 사일런 눈을 볼 시간입니다. 여러분의 통합된 시스템을 부팅하고 나서 run.sh를 루트 디렉토리에서 실행하세요.
# cd /
# . /android/run.sh
yaffs: dev is 32505861 name is "mtdblock5"
yaffs: passed flags ""
yaffs: Attempting MTD mount on 31.5, "mtdblock5"
yaffs: auto selecting yaffs2
# init: HOW ARE YOU GENTLEMEN
init: reading config file
init: device init
init: mtd partition -1,
init: mtd partition 0, "l1boot"
init: mtd partition 1, "u-boot"
init: mtd partition 2, "params"
init: mtd partition 3, "kernel"
init: mtd partition 4, "ramdisk"
init: mtd partition 5, "rootfs"
sh: can't access tty; job control turned off
# binder_open(c394bcc8 c3c731a0) (pid 1577) got c3e48000
binder_open(c394bcc8 c3cd8dc0) (pid 1616) got c319f000
binder_open(c394bcc8 c3cd8ac0) (pid 1673) got c3d10000
binder_open(c394bcc8 c3cd8940) (pid 1680) got c0e19000
binder_open(c394bcc8 c3cd88c0) (pid 1691) got c2fa0000
binder_open(c394bcc8 c3d174a0) (pid 1592) got c25b8000
binder_release(c394bcc8 c3cd88c0) (pid 1691) pd c2fa0000
#

  • /dev 상에 eac 디바이스 파일을 만들지 마세요. 그 것은 qemu상의 오디오를 위한 것입니다. 만약 있다면 시작 절차(start up sequence)는 사운드 디바이스에 어떤 데이터를 쓰는 것을 끝마치기 위해서 영원히 기다릴 것입니다.
  • 수동 시작(manual startup) 대신에 안드로이드 init 바이너리를 사용하세요. 수동 시작은 안드로이드 패치가 필요합니다. 그 경우 시작 절차는 /sys/android_power/acquire_partial_wake_lock에 접근하고 기다릴 것입니다.

안드로이드 시스템을 디버깅하기 위해서 http://benno.id.au/blog/2007/11/18/android-runtime-strace 의 static 컴파일된 strace 바이너리를 사용하고, 안드로이드를 수동으로 실행하세요.

#!/bin/sh
# set environment variables above example
...
/system/bin/app_process -Xzygote /system/bin --zygote &
/system/bin/dbus-daemon --system &
/system/bin/runtime

다음 예제는 수동 시작 절차를 보여줍니다. /system/bin/runtime 바이너리 상에서 strace를 사용하세요.

./strace -ff -F -tt -s 200 -o /tmp/strace runtime

6.6 스크린샷


recvfrom(4, "add@/devices/virtual/misc/networ"..., 1024, 0, NULL, NULL) = 144
mknod("/dev/network_latency", S_IFCHR|0600, makedev(10, 58)) = 0
chown32("/dev/network_latency", 0, 0)   = 0
recvfrom(4, 0xbee2b72a, 1024, 0, 0, 0)  = -1 EAGAIN (invain)
getdents64(8, /* 5 entries */, 4200)    = 136
getdents64(8, /* 0 entries */, 4200)    = 0
close(8)                                = 0
SYS_305(0x7, 0x27f3b, 0x24000, 0, 0x28e98) = 8
SYS_305(0x8, 0x1b6ec, 0x20001, 0, 0x28e98) = 9
write(9, "add\n", 4)                    = 4
close(9)                                = 0
recvfrom(4, "add@/devices/virtual/misc/networ"..., 1024, 0, NULL, NULL) = 150
mknod("/dev/network_throughput", S_IFCHR|0600, makedev(10, 57)) = 0
chown32("/dev/network_throughput", 0, 0) = 0
recvfrom(4, 0xbee2b72a, 1024, 0, 0, 0)  = -1 EAGAIN (Resource temporarily unavailable)
getdents64(8, /* 5 entries */, 4200)    = 136
getdents64(8, /* 0 entries */, 4200)    = 0
close(8)                                = 0
getdents64(7, /* 0 entries */, 4200)    = 0
close(7)                                = 0
SYS_305(0x6, 0x26f13, 0x24000, 0, 0x27e18) = 7
SYS_305(0x7, 0x1b6ec, 0x20001, 0, 0x27e18) = -1 ENOENT (No such file or directory)
getdents64(7, /* 3 entries */, 4200)    = 80
SYS_305(0x7, 0x27e6b, 0x24000, 0, 0xffffffff) = 8
SYS_305(0x8, 0x1b6ec, 0x20001, 0, 0x28e98) = 9
write(9, "add\n", 4)                    = 4
close(9)                                = 0
recvfrom(4, "add@/devices/virtual/sound/timer"..., 1024, 0, NULL, NULL) = 128
mknod("/dev/timer", S_IFCHR|0600, makedev(116, 33)) = 0
chown32("/dev/timer", 0, 0)             = 0
recvfrom(4, 0xbee2b72a, 1024, 0, 0, 0)  = -1 EAGAIN (Resource temporarily unavailable)
getdents64(8, /* 5 entries */, 4200)    = 136
getdents64(8, /* 0 entries */, 4200)    = 0
close(8)                                = 0
getdents64(7, /* 0 entries */, 4200)    = 0
close(7)                                = 0
getdents64(6, /* 0 entries */, 4200)    = 0
close(6)                                = 0
getdents64(5, /* 0 entries */, 4200)    = 0
close(5)                                = 0

7 애플리케이션 개발


안드로이드 애플리케이션은 XML 레이아웃과 자바 문법을 사용합니다만, 자바는 아닙니다. 왜냐하면 그들은 그들 고유의 가상 머신 - dalvik - 과 dex 파일 형식을 위한 컴파일러를 사용하기 때문입니다. 그리고 Home.apk, Phone.apk, ApiDemos.apk 등 과 같이 apk로 이름붙여진 패키지를 사용합니다.

apk 파일은 ZIP 압축파일이고 네 가지 부분을 가집니다.

  • AndroidManifest.xml
  • classes.dex
  • resources.arsc
  • res 디렉토리

Dex 파일 형식은 http://www.retrodev.com/android/dexformat.html 에 설명되어져 있습니다. 그리고 그 파일들의 내용과 디렉토리는 언젠가 구글이 설명할 겁니다. 현재는 설명되지 않았습니다. 우리는 단지 그렇게 추측할 뿐입니다.

안드로이드 SDK는 *.apk 파일을 생성할 것입니다.

7.1 이클립스(Eclipse) 통합개발환경(IDE) 설치하기


http://code.google.com/android/intro/installing.html 의 설치 절차를 따르세요.

1. http://www.eclipse.org/downloads/ 의 (JDT와 WST 플러그인이 포함된)Eclipse IDE for Java developer


3. Apache Ant를 포함하는 eclipse plugin인 ADT (Android Development Tools)

7.2 샘플 애플리케이션을 빌드하고 실행하기


1. 샘플 프로젝트를 열고 빌드

2. 에뮬레이터 상에서 샘플 애플리케이션 실행

7.3 스크린샷


8 에필로그


안드로이드 시스템은 데비안, 레드햇, 수세나 기타 등과 같은 모바일 환경을 위한 새로운 종류의 리눅스 기반의 배포판이 될 것으로 보입니다. 그들은 오픈소스 세상의 리눅스 커널과 많은 다른 라이브러리를 사용할 뿐입니다. 그들은 현재 3D 가속화를 OpenGL-ES 라이브러리에 기반한 소프트웨어를 제공합니다. 그러나 그들은 그를 위한 하드웨어 가속의 기본 프로세서 상에서 개발하고 있습니다. 그 하드웨어 가속은 추후의 빠른 UI 렌더링 효과를 위해 필수적입니다.

SDK 상의 안드로이드 시스템은 실제 하드웨어 상에 포팅하는 것은 완벽하지 않습니다. 왜냐하면, 라이브러리와 클래스에 관련된 어떤 디바이스 - 예를 들면, 카메라 -는 아직 구현되지 않았고, 사용자에게 공개되지 않았습니다. 그 것은 아직 개발 단계에 있는 것으로 보입니다. 그래서 구글의 전체 포팅 킷을 기다리는 것이 더 나을 것 같습니다.

그 전에, 우리는 안드로이드 시스템의 사업 모델을 살펴봐야만 합니다. 그 것은 약간 빠른 CPU 성능을 필요로 하기 때문에 운송 판매사는 싼 기본 프로세서(RF 부분)와 멀티미디어 코프로세서(co-processor)가 필요할 겁니다. 멀티미디어 기능을 포함하는 기본 프로세서는 매우 비싸기 때문입니다.

9 링크와 참조

안정적인 DNS서비스 DNSEver DNS server, DNS service
Posted by 키르히아이스

댓글을 달아 주세요