2016년 8월 2일 화요일

[번역] Surround 360 is now open source

Surround 360 is now open source

*주의 이글은 허가 받지 않은 번역으로 잘 못된 번역이 포함 되어 있을 수 있습니다. 꼭 원문도 함께 보시기 바랍니다.
* 저작권의 문제가 발생할 시 삭제 하겠습니다.
오늘 우리는 고품질의 3D-360의 하드웨어,소프트웨어인 Surround 360 을 공식적으로 오픈소스로 공개 하였습니다. 오픈소스 프로젝트는 촬영부터 처리 까지 가능한 카메라의 하드웨어 디자인과 3D-360 video를 하나의 시스템에서 생성할 수 있는 스티칭 코드를 담고 있습니다.
우리는 GitHub 무료로 공개한 카메라 디자인과 스티칭 코드가 3D-360 생태계의 성장을 가속하리라고 믿습니다 - 개발자는 그 코드를 더 풍부 하게 할것 이고, 컨텐츠 생산자는 카메라를 그들의 컨텐츠에 사용할 것 입니다. 이번 스펙을 기준으로 모두는 계속하여 기여 하고 개선하며, 구축하고, 배포 할 것 입니다.  
하드웨어 디자인과 소프트웨어는 모두 고품질의 결과물을 생성하는 역할을 합니다.
우리는 먼저 카메라의 하드웨어 디자인(hardware design) 과 영상 처리 시간을 감축의 중요성에 대하여 이야기 하고자 합니다. 우리는 고품질의 광학기기(Optic)와 기계로 제작된 Rig를 이용하고 다양한 카메라렌즈를 사용하더라도 Stereo 결과물을 볼 수 없었다(3D 가 아닌 Double Vision은 가능). 우리의 Stitching 소프트웨어는 17개의 카메라로 촬영(Captured)된 Surround 360 이미지를 사용하여 VR을 위한 360 스테레오 스코픽 파노라마로 변형 합니다.이 소프트웨어는 최고의 VR 경험을 위하여 각 카메라당 8K로 담은 3D-360 처리시간을 꽤나 단축 시킵니다. 이 게시물은 이러한 문제를 해결하고, 설정한 목표를 달성하고 우리의 도전 위하여 결정하고 만든 렌더링 소프트웨어의 몇 가지 기술에 대하여 깊게 다루고자 합니다.

스테레오 360 video rendering 도전 (Challenges of rendering stereo 360 video)

스테레오 360  video 는 다양한 이유로 어려운 문제 입니다:
  • * 관련된 데이터가 매우 많습니다. 많은 카메라를 이용하여 압축되지 않은 최고 품잘의 원본 영상을 사용하기 때문입니다. 대략 1분당 120GB의 데이터(30 fps의 경우 60fps의 경우 두배).
  • * 적은 에러만 허용됩니다. 360 mono 컨텐츠를 위하여 약간의 에러가 허용됩니다. 그러나 스테레오는 완벽히 처리 되지 않을 경우 물리적인 불편함을 느끼게 됩니다.
  • * VR동영상을 실제적으로 생성하기 위하여 모든 데이터가 최대한 빠르게 처리 되며, 가급적 최고의 품질을 지향해야 합니다.
기존의 모노스티칭(mono stitching)프로그램으로는 문제를 해결할 수 없습니다. 그것은 소스이미지의 간단한 변형으로 처리된 후 경계선(edge)를 섞는 과정을 거치는 데 이것은 스테레오를 처리할 수 없습니다. 그런 처리는 스테레오 불일치를 생산하며 그것은 불편함의 인인 3D 지각 불일치입니다.

스테레오 파노라마 생성법 (Methods for constructing stereo panoramas)

우리는 3D-360 카메라 프로토타입을 위하여 많은 카메라와 소프트웨어 조합을 시도했습니다. 먼저 두 눈의 거리만큼 떨어진  4개의 카메라 구성으로 시도해 보았습니다. 그 다음 왼쪽 눈과 오른쪽 눈의 이미지를  알파블렌딩과 함께 심리스 파노라마를 이용하여 스티칭을 하였다. 이것은 이미지를 자연스럽게 섞기 위한 기본적인 기술이다. 카메라가 직선 방향으로 바라볼때는 좋았으나, 구석에 있는 경우는 스테레오가 되지 않았다. 이 방법의 또 다른 문제는 당신이 회전 할 때에 당신의 눈이 어떤 특정 거리의 물체에 대하여 서로 다른 방향으로 방향으로 보게되고 이것은 눈의 피로를 발생 시킨다.
기본 알파 블렌딩 스티치 보다 스테레오 파노라마를 구성하는 좀 더 정교한 방법이 있습니다. 고정된 축을 중심으로 회전하는 카메라로 촬영한 이미지의 조각을 사용하는 것입니다. 이것은 기본적인 스트치 보다 좀 더 향상된 이향운동(vergence) 에 대한 파노라마를 만듭니다. 그러나 이것은 어떤한 움직임이라도 있는 장면에 적용할 수 없습니다. 한발짝 더 나아가 우리는 회전하는 카메라를 시뮬레이션 하기 위하여 고리(Ring) 에 배치된 많은 작은 카메라의 “보기보간(View Interpolation)” 이라고 하는 광학흐름(Optical flow)를 사용합니다; 이는 움직임이 있는 장면을 촬영할 수 있습니다. 그러나 광학흐름(Optical flow)는 Computer Vision 연구의 어려운 도전 과제 입니다.

지오메트리를 사용하여 현실적인 결과물 만들기 (Using geometry to create realistic results)

Surround 360 렌더링 코드는 괜찮은 품질의 이미지를 유지하고, 깊이와 규모에 대한 정확한 인식, 편안한 스테레오 보기를 지원하며, 360x180를 이용한 몰입을 위한 상단과 하단에 조합처리(삼각대 보이지 않게 하기)를 빠르게 렌더링 할수 있도록 설계 되었습니다.
Equirectangular projections은 VR 비디오, 이미지 를 처리 하기 위한 보편 적인 처리 기술 입니다. Equirectangular projection은 세계지도 처럼 구면체의 표면을 평면으로 보여주기 위한 하나의 방법입니다. 각 equirect image 왼쪽, 오른쪽 픽셀의 열(Column)은 사용자의 특정 머리 방향에 대응하고, 머리 방향에 있는 좌,우 눈에 보여지게 됩니다.
그래서 우리의 목표는 좌우 눈을 위한 서로 다른 머리 방향에 대응하는 픽셀로 구성된 equirectangular 파노라마를 만드는 것입니다. 머리 방향을 구하기 위하여 2개의 가상 눈(eye)를 6.4cm 간격으로 배치 하였습니다, 이것은 머리 중심 축을 회전 합니다. 각 가상 눈(eye)은 코의 방향을 을 고려 합니다. 그리고 해당 방향에 따른 실 세계의 색상과 빛을 알고자 합니다. 그 색상은 equirectangular image에서 인지 하고자하는 각 픽셀의 색상이다.
이제 카메라(2D top down 관점) 안에서 벌어지는 모든일을 상상해보자. 머리의 중심이 카메라의 중심인 것이다. 선(The Ray)는  가상의 눈이 시작되는 Pixel 과 결국 카메라의 원형을 탈출 한 Pixel로 구성된다.(The ray we constructed through each pixel starts at a virtual eye and eventually exits the circle of cameras.) 만약 해당 선이 실제 카메라를 바로 통과 한다면, 우리는 카메라의 일부 이미지에서  어떤 색상인지 알게 됩니다. 그러나 대부분의 선(the ray)은 실제 카메라가 없는 원형(Circle)을 탈출 하게 됩니다. 이런 경우 우리는 가상 카메라와 실제 카메라 사이의 보간법(interpolation)을 사용하여 색상을 가져옵니다.
위의 설명은 실제의 세계의 광선(The ray)에 대응하여 스테레오 equirectangular 이미지 렌더링 하기 위한 방법이고 이것이 (약간은 거칠지만) 사실적인 느낌을 주는 이유를 설명 해줍니다.

렌더링 파이프라인 (Rendering pipeline)

실제로 우리는 이미지 프로세싱 단계의 파이프라인 모델을 통하여 위의 모델을 구현하였습니다. 파이프라인은 많은 단계(step)로 구성 되었으나 대부분은 자동이어서, 렌더링 시간은 수동 스티칭 보다 덜 걸립니다.
먼저 카메라는 RAW bayer pattern 이미지를 출력합니다. Surround 360 의 이미지 시그널 프로세서(The Image Signal Processor (ISP)) 코드는 RAW 센서 데이터를 감마 색상 보정을 적용하여 표준화된 RGB 포멧의 .png이미지로 변경합니다. 그 다음, 렌더링 시스템은 각 카메라 이미지와 equirectangular 사상(projection)을 읽어옵니다. equirectangular 사상(projection)은 사각형 텍스쳐의 전체면을 커버합니다. 각 카메라는 전체 구면체의 일부만 촬영하지만, 이것은 equirectangular 사상에 표시될 수 있습니다. 우리는 파이프라인의 후속 단계를 통과 함으로 사상(projection)을 좀 더 편하게 할수 있다.
원본이미지를 equirectangular로 사상하는 동안 렌즈 왜곡을 보정해야 합니다. 컴퓨터 비전에서 흔히 사용하는 체커보드를 많이 활영하는 방법으로 왜곡에 대한 측정을 하였습니다.
우리는 또한 수직시차(vertical prallex)가 원인이 되어 발생하는 카메라/렌즈/마운팅 시스템의 회전,  틀어짐 을 보정합니다. 우리는 모든 조청된 카메라로 부터 매칭 키포인트를 찾아내고 인접한 각 카메라의 정류(Rectifies)를 위한 시점 변화(perspective transform)을 최적화 함으로서 수직시차(오른쪽 눈과 왼쪽눈의 수직차이)를 최소화 합니다.
모든 카메라는 제로변위에 카메라를 두고 무한대의 거리에 물체를 둠으로 equirectangular에 투영합니다. 이것은 카메라 사이에 다른 거리에 물체가 존재 투영(Project) 하는 경우 시각차에 대응 하기 위함 입니다. 이것은 멀리있는 것은 0에서 부터 추측하기 때문에 광학 흐름(optical flow)에 도움이 됩니다.
가까이 있는 카메라의 이미지 중첩 영역을 발견하고 처리 합니다.
광학흐름은 시점을 보간(view interpolation)하는데 사용됩니다. 그래서 우리는 가상카메라에서 필요로하는 선(the ray)를 얻을 수 있습니다.
지금까지, 우리는 파노라마의 스테레오를 렌더링 하는 부분에 대하여 설명하였습니다. 우리는 상하단 카메라를  통합하여 360도x180도의 전체 범위에 대하여 더욱 몰입하게 만듭니다. 측면의 카메라들은 대략 90도의 수직 수평 FOV(베럴 디스토션 보정을 하면 77도 까지 좁혀짐) 를 가진 광각 카메라가 있습니다. 그래서 전체 180도 수직범위를 벗어나 수평 77도 스트립을 포함 합니다. 우리는 상하단에 단일 구멍을 채우는 180도 어안렌즈 카메라를 가집니다.  이것은 사실상 최상단과 촤하단의 mono를 가지게 됩니다. 왜냐하면 머리 방향에 대하여 좌우 equirectangular 이미지 쌍에 맞도록 구성할 수 없습니다. 그래서 지평선의 스테레오로부터 극점의 모노로 점진적(gradually)으로 구성합니다. 다른 렌즈를 통하여 스테레오 범위를 증가 시킬수 있지만, 해상도와 Pixel 밀도 간의 트레이드 오프가 있습니다.
편안한 스테레오를 위하여 상단 카메라와 사이드 카메라의 좌우 이미지간 자연스러운 스티치를 해야 합니다. 상단이미지와 파노라마를 매치시키위하여  광학흐름을 사용합니다. 그 다음 상단의 이미지는 흐름에 따라 이동(warping)하고 이미지를 구성하기 위하여 알파블랜딩(deghosting 포함) 됩니다.
하단에는 2개의 카메라가 있습니다. 그래서 우리는 삼각대의 막대를 자동으로 제거 할 수 있습니다. 기본 카메라는 상단 카메라와 대칭 되어 리그(rig)의 중심에 위치 합니다.  문제는 삼각대 봉에 의하여 생기는 이미지가 막힌 부분 입니다. 두 번째 카메라는 봉의 반대 편에 있습니다. 그래서 기본 카메라에서 봉(pole)때문에 막힌 부분을 볼 수 있습니다. 우리는 이미지를 조합 함으로서 기본 카메라에서 봉(pole)이 제거된 장면을 볼 수 있습니다. 이것은  두 개의 이미지에서 특정 봉(pole)부분을 가린 후 광학 흐름을 이용하여 두 번째 이미지에서 첫 번째 이미지로 옮기고, 섞습니다 이때 첫 번째 이미지의 봉의 마스크 부분에 두 번째  이미지의 픽셀을 사용합니다. 2개의 이미지를 사용하여 봉이 제거된 후 사이드의 좌우 파노라마 이미지에 상단 카메라와 동일한 방법으로 스티칭을 하게 됩니다.
이것은 다중 CPU의 장점을 사용한 멀티플쓰레드(multiple Thread)환경에서 일어납니다. 예를 들면, 광학 흐름은 모든 이미지 쌍을 동시에 계산합니다. 반면 파이프라인의 각 단계는 가능한 만큼 CPU의 복잡도를 위지 하기 위하여 단계 별 종속성을 가진다.

시작에 불과합니다. (Just the beginning)

이 렌더링 파이프라인은 높은 몰입 경험을 위하여 고해상도의 360 도 x 180도 의 구체로 이루어진  3D 360 파노라마를 생성합니다. 우리는 각 단계 별로 상당히 심혈을 기울였습니다. 이미지 품질을 유지 하기 위하여, 속도를 최적화 하기 위하여 그리고 현실에 가까운 실용적인 상용 하드웨어를 생산 할 수 있도록. 우리는 오픈소스로 하드웨어 설계 및 소프트웨어를 공개 하고 향후 모든 360 파이프라인을 계속적으로 기여할 수 있어서 매우 기쁩니다. 우리는 자기 자신의 360 리그 구축 하고 , 무엇보다도  진정한 몰입 경험을 획득 할 수 있기를 희망한다. 커뮤니티로 돌아와 당신의 생각을 알려주고 기여하기 바랍니다.

2015년 6월 9일 화요일

node.js + add-on c, c++

** node.js
- v8기반으로 동작하는 플랫폼.
- 자바스크립트 기반 언어
- 설치 (ubuntu 12.04기준)

 apt-get install nodejs
 apt-get install npm

** add-on
- c, c++ library(*.so파일들..)를 사용하기 위한 오브젝트
- node-gyp 설치 필요
- 설치 (ubuntu 12.04기준)

npm install -g mode-gyp
(python 2.7, make, c compiler like gcc설치 필요)


**add-on 예제

1. js file (test.js)
var binding = require('./build/Release/binding');
var timeVal = binding.time();
var loginVal = binding.login();

var http = require("http");
var server = http.createServer(function(request, response) {
  response.writeHead(200, {"Content-Type": "text/html"});
  response.write("<!DOCTYPE /html>");
  response.write("<html>");
  response.write("<head>");
  response.write("<title>Hello World Page</title>");
  response.write("</head>");
  response.write("<body>");
  response.write(timeVal);
  response.write(loginVal);
  response.write("</body>");
  response.write("</html>");
  response.end();
});
server.listen(8080, 'localhost');
console.log('binding.timeVal() =', timeVal);
console.log('binding.loginVal() =', loginVal);

2. binding.gyp - json타입이며, binding lib세팅, target_name이 library name
{
  "targets": [
    {
      "target_name": "binding",
      "sources": [ "binding.cpp" ]
    }
  ]
}

3. binding.cpp
#include <node.h>
#include <v8.h>


#include <time.h>
#include <stdio.h>

#include <unistd.h>
using namespace v8;

void getTime(const FunctionCallbackInfo<Value>& args) {
  Isolate* isolate = Isolate::GetCurrent();
  HandleScope scope(isolate);

  time_t   current_time;

  time( &current_time);
 
  args.GetReturnValue().Set(String::NewFromUtf8(isolate, ctime( &current_time)));
}

void getLogin(const FunctionCallbackInfo<Value>& args) {
  int i = 0;
  char cBuf[256];
 
   Isolate* isolate = Isolate::GetCurrent();
   HandleScope scope(isolate);
 
 
  int j = sprintf(cBuf, "%s", getlogin());

  args.GetReturnValue().Set(String::NewFromUtf8(isolate, cBuf));
}


void init(Handle<Object> target) {
  NODE_SET_METHOD(target, "time", getTime);
  NODE_SET_METHOD(target, "login", getLogin);
}

NODE_MODULE(binding, init);

**build
$node-gyp configure build

**execute
$node test.js

**결과 화면


**sample code svn rep.
https://121.134.202.97/svn/Dev3/SRC/trunk/nodejs_addontest


2015년 4월 21일 화요일

Gradle 고찰 - Part.1

1. 배경

어느 날인가, 갑자기 개발환경을 최신화 해야 겠다는 생각이 들어서, Android ADT를 기동하고 SDK을 업데이트 하였으나, 예상대로 매끄럽게 업데이트가 되지 않았다. 그래서 Android 개발자 페이지(https://developer.android.com/index.html)에 가서 ADT를 받으려고 하였으나... 어디에도 찾아 볼 수 없고, 그 자리에 정식 버전으로 릴리스된 Android Studio 가 차지하고 있었다. (헉!! 그래도 현재 Eclipse Plug-in을 통해서 동일한 방식으로 빌드는 할 수 있다.) 
새로운 환경으로 옮겨가기로 맘도 먹었으니 가벼운 마음으로 Android Studio를 설치 하고 기존으로 프로젝트를 임포트 하였으나...빌드가 되지 않는 것이다. 그때 부터 약 30분 간 구글링을 한 결과 빌드 방법이 바뀌었기 때문에 Converting을 해야 만 한다는 사실을 깨달았다. 
그 빌드 방법이 바로 "Gradle"(http://gradle.org)!!!! 이 녀석이 뭐길래 구글의 Android 빌드로 선택 되었나 궁금하여 이 녀석을 고찰 하기로 한다. 

2. Gradle 개요

OPEN SOURCE BUILD AUTOMATION
From command line to IDE to continuous integration, only one Enterprise build automation system to rule them all. Declare and execute all tasks necessary to compile, test, package and ship multi-language multi-platform multi-project and multi-channel software, SaaS and Mobile Apps.


홈페이지에 들어가면 위와 같은 문구를 가장 먼저 볼수 있다. 굳이 직역하자면 

오픈소스 빌드 자동화로서 CLI(Command Line Interface) 부터 IDE(e.g Eclipse, Intelli J....)까지 지원 하는 함. 컴파일, 테스트, 패키지,다양한 언어, 플랫폼, 프로젝트 그리고 SaaS, 모바일 App 등의 다양한 채널로 배포(Ship)을 정의 하고 실행 함. 
(다수의 오역이 있을 수도 있습니다. 지적해주세요)

위와 같다.

흠 그냥 느낌은 뭐 이런 아이들은 많잖아 기존 Ant(http://ant.apache.org)나 Maven(https://maven.apache.org)도 있는데 왜 Android Studio는 Gradle을 공식 빌드로 수용 하였을까? 라는 느낌이다.

https://gradle.org/why/polyglot-builds/#av_section_2 의 "Android's Build System" 부분을 참조하면 의존성 관리, 여러 프로젝트를 통합하여서 빌드해야 하는 경우에 대하여 손쉽게 구성할 수 있는 장점이 있다고 한다.
개인적으로 느낄때는, 기존에는 Ant를 사용하거나 혹은 그냥 Plug-in 에 내장되어 있는 Build를 사용하여도 크게 문제는 없었던 것 같은데 좀 더 명확하게 관리 할수 있게 된것이 장점으로 생각된다. 
오~! 그리고 Signing도 한큐에 어러가지로 할 수 있는 것 같다.(이 부분은 좀 좋은 것 같다~!)

* Gradle?!Groovy??

Gradle은 기본적으로 XML이 아닌 Groovy(http://www.groovy-lang.org) Syntax 로 기술한다.
XML 대비 장점은 다음의 글을 참조 하기 바란다. 

내가 생각하는 Maven의 가장 큰 문제점은 두가지이다.
  • 프로젝트 구성/빌드 툴로써 프로젝트 구성은 정적인 설정 정보이고 빌드는 동적인 행위이다. 그런데 이것을 정적인 데이터를 저장하는데 적합한 XML로 그 내용을 기술하게 함으로써 동적인 행위인 빌드에 크나큰 제약을 가한다. 게다가 XML은 너무 장황해서 실제 설정 내용보다 XML 뼈대가 더 많다.
  • 다른 하나는 Gradle을 사용하다 느낀 것인데, Maven은 설계상의 문제도 있다. 바로 멀티 프로젝트 구성을 상속 구조로 한 점이다. 그에 반해 Gradle은 구성 주입 방식(Configuration Injection, 설정 주입 방식이 더 나은 번역일까?)을 사용한다. 이는 빌드 구성 정보에서 매우 큰 차이를 만든다.
Gradle은 Groovy DSL로 작성하며, 설정 정보는 변수에 값을 넣는 형태로, 동적인 빌드는 Groovy 스크립트로 Gradle용 플러그인을 호출하거나 직접 코드를 짜면 된다.

요컨데 심플하고 환경에 따라 동적으로 빌드 할 수 있는 장점인것으로...

이상 Gradle이 어떤 것인가 대하여 대략 적으로 살펴보았다. 이후 Android의 빌드를 중심으로 Gradle 활용에 대하여 정리하고자 한다. 

to be Continued....

PS. 잘못된 내용이나 문제가 발생할 수 있는 내용은 지적 부탁드립니다.

2015년 4월 17일 금요일

다국어 리소스 파일 생성 툴

오늘 포스팅할 내용은 다국어 파일 생성기입니다.
안드로이드, iOS 두 OS에 대한 다국어 파일을 생성해주며 구글 스프레드시트를 이용하기 때문에 키, 스트링에 대한 관리면에서도 효율적으로 활용할 수 있는 툴입니다.



1. 스프레드시트 작성법
첫번째 열은 KEY와 언어 코드를 작성합니다. 언어 코드는 ISO 639-1에 정의된 값으로 작성합니다.
첫번째 행은 KEY값들을 나열하고 다른 행은 해당 언어의 값을 입력합니다.
** 구글 스프레드시트 팁!!
GOOGLETRANSLATE 함수를 사용하여 쉽게 번역할 수 있다.


2. 공유 설정
생성기를 사용하기 위해서는 공유 설정을 통해 접근 권한을 주어야합니다.
① 접근 공유 설정
- 우측 상단 공유 -> 고급 -> 변경 -> 링크가 있는 모든 사용자 선택

② 웹에 게시
- 파일 -> 웹에 게시 -> 게시 선택
- 게시 후 URL을 복사


3. 리소스 파일 생성
iOS / Android Language Files Maker 사이트 접속.
② URL 입력 및 Make Language Files 버튼 클릭.
- URL은 스프레드시트를 웹에 게시할 때 생성되는 URL을 입력

③ zip파일 다운로드



좀 더 자세한 사용 설명은 아래 동영상을 참고하시기 바랍니다.


2015년 4월 1일 수요일

[HTML5]canvas 데이터 처리


  • 개요
    • 본 문서는 HTML 태그 요소 중 하나인 <canvas>의 데이터 핸들링에 대한 간략한 소개 문서이다.
    • canvas에 그러진 이미지 정보의 추출과 추출된 데이터를 통해 다시 canvas 이미지로의 변환을 소개한다.
    • 추출/변환되는 데이터는 text기반의 타입이다.
  • 예제 소개(기존 단말 샘플 예제)
    1. 이전에 저장된 데이터가 존재하며, 그 데이터를 다시 로드하겠는지 여부 확인


    2. 저장된(단말의 Preference에 저장된) 데이터를 canvas에 로딩.


  • 소드 코드 소개
    1. canvas 이미지를 text기반의 데이터로 저장
      [html]
      <canvas id="canvasSignature" width="200px" height="100px" style="border:1px solid #000000; margin:5px"/>

      [js]
      var sigCanvas = document.getElementById("canvasSignature");
      sigCanvas.toDataURL();

      [sigCanvas.toDataURL(); 결과값]

    2. 저장된 text기반의 데이터를 canvas로 load
      Image 객체를 생성한 뒤, drawImage()

      var context = sigCanvas.getContext("2d");
      var image = new Image();
      image.src = eachdata.value;
      image.onload = function(){
      context.drawImage(image, 0, 0);
      }
  • 브라우저 테스트
    : 위 샘플코드를 일부 수정하여 캔버스 복사 기능을 pc브라우저에서 테스트 함.
    좌측의 기존 캔버스에 드로잉 입력 후, '회원가입'버튼을 클릭하면 오른쪽 캔버스에 동일한 이미지가 복사되도록 테스트
    • 동작 개념 : 좌측 캔버스 드로잉 -> '회원가입' 버튼 클릭 -> 좌측 캔버스에서 base64기반의 텍스트 데이터 추출 -> 오른쪽 캔버스에 해당 텍스트 데이터를 Image객체로 드로잉
    • 사파리 테스트 결과(버전 7.1.4(9537.85.13.7))
    • IE(11.0.17)

2015년 2월 17일 화요일

ACRA Essential

Crash Logger 관련 사용부분에 대하여 기존 정리된 문서가 있어서 공유합니다.

작성자: 전두일/서미정
  1. 개요



본 문서는 Android Application Crash Report Library ACRA(Application Crash Report for Android) 사용법에 대하여 설명하고자 작성한다.
[ ACRA Github에 설명이 잘 되어있어 실사용 관점에서 설명하고자한다. ]


  1. ACRA



ACRA 는 안드로이드 Application의 Crash 를 자동으로 보고해 주는 오픈소스 MIT  License의 라이브러리입니다.
(최초 Google Form 과 연동으로 작성되었으나 구글Docs 부하문제로 사용불가하게됨)



  1. ACRA 사용법 (Device)



    1. Android 설정방법



  1. 라이브러리 등록



  • Maven dependency
<dependency>
 <groupId>ch.acra</groupId>
 <artifactId>acra</artifactId>
 <version>4.5.0</version>
</dependency>


  • Gradle
dependencies {
   ...
   compile 'ch.acra:acra:4.5.0'
}


  • jar include
 Application Project add acra-4.5.0.jar


  1. Android Manifest.xml 수정

<manifest ...>
 <application ... android:name="MyApplication"> ⇐  3.Code 수정 에서 Override한 Application  
   ...
 </application>
 <uses-permission android:name="android.permission.INTERNET"> ⇐ Add Code  
 </uses-permission>
</manifest>


  1. Code 수정 : Application Override

import org.acra.*;
import org.acra.annotation.*;
@ReportsCrashes(
       formKey = "",
       formUri = "http://192.168.0.35:5984/crashlog",
       reportType = org.acra.sender.HttpSender.Type.JSON,
       httpMethod = org.acra.sender.HttpSender.Method.POST
       )                       ⇐ Add Code   3.2. ReportsCrash params  설명
public class MyApplication extends Application {
 @Override
 public void onCreate() {

   ACRA.init(this);  ⇐ Add Code
   super.onCreate();  
 }
}

    1. ReportCrash params

  • User interface

    • mode : 크래쉬발생시 UI
  • ReportingInteractionMode.SLENT
  • ReportingInteractionMode.NOTIFICATION
  • ReportingInteractionMode.TOAST
  • ReportingInteractionMode.DIALOG
*각 모드에 따라 추가되는  params  있음  ex( resDialogText/ resDialogIcon …)
[Toast/ Notification/ Dialog]


    • forceCloseDialogAfterToast : Crash Dialog 보여주기 여부
  • false
  • true : [Force Close] Dialog Show


  • Report Destination

    • formKey : 현재 사용하지는 않지만( GoogleDoc Form ID) 필수 입력항목 [“”]
    • mailTo : 크래쉬 내용이 Mail Intent로 실행됨
    • formUri : 크래쉬 데이터 전송할 Custom Server Uri
    • formUriBasicAuthLogin : 보낼 서버의 로그인 아이디
    • formUriBasicAuthPassword : 보낼 서버 로그인 패스워드
    • httpMethod : 데이터 전송 유형
  • org.acra.sender.HttpSender.Method.POST
  • org.acra.sender.HttpSender.Method.PUT
    • reportType : 데이터 전송 타입
  • org.acra.sender.HttpSender.Type.FORM
  • org.acra.sender.HttpSender.Type.JSON
* 그외  OwnSender 로 Interface를 만들어 사용하는 경우 도 있음
(3.3 OwnServer 에서 추가설명)


  • Report Contents

    • customReportContent : Report 항목을 설정 할 수 있음
5.1 ReportContent 참고
    • additionalSharedPreferences : SharedPreference정보 연동
    • sharedPreferencesName : Acra 설정값의 SharedPreferrnces의 Name 설정
  • arc.* 로 설정정보 get/set
acra.enable/ acra.disable : acra 사용여부
acra.syslog.enable : syslog 보내기여부
acra.deviceid.enable : deviceid 사용여부
acra.user.email : set send user email
acra.alwaysaccept : 보내기설정의 묻는창에서 항상  YES처리
… 소스코드 참고
    • includeDropBoxSystemTags : DropBoxManager 사용여부
  • false
  • true : 그외 참고
  • 설정

    • sharedPreferencesMode : Acra 설정값의 SharedPreferrnces의 Mode 설정
  • Context.MODE_PRIVATE
  • Context.MODE_WORLD_WRITEABLE
  • Context.MODE_WORLD_READABLE
    • sendReportsInDevMode: Signed application package 만 전송됨
  • true / false
    • deleteUnapprovedReportsOnApplicationStart
    • deleteOldUnsentReportsOnApplicationStart
    • connectionTimeout
    • socketTimeout
    • maxNumberOfRequestRetries
    • disableSSLCertValidation


  • Dynamic Configuration

: Configuration을 code 로수정가능 (v4.3)


import org.acra.ACRA;

...
ACRA.getConfig().setHttpMethod(org.acra.sender.HttpSender.Method.POST);
...


    1. Send exception

: catch 된 exception보내기


try {
serverPort = Integer.parseInt("a");
 }
catch (NumberFormatException e) {
ACRA.getErrorReporter().handleSilentException(e);
}
* handleException()  Toast/Dlg/Notification 있음


    1. OwnSender

: Sender를 생성하여 사용
public class OwnSender implements ReportSender {

public OwnSender()
{
}
@Override
public void send(CrashReportData arg0) throws ReportSenderException {
// TODO Auto-generated method stub
Log.d("OwnSender","STACK_TRACE:" + arg0.getProperty(ReportField.STACK_TRACE) );
}
}


    1. 추가 라이브러리

      1. ANR

: [ANR-WatchDog] 추가 라이브러리로 주기적 모니터링을 통해 ACRA 로 보고할수 있다


      1. Native Code error (JNI C/ C++)

:  [Native-Crash-Handler] 추가 라이브러리로 Native Code의 error를 ACRA 로 보고할수 있다.


  1. ACRA 사용법 (Server)

    1. CouchDB

ACRA연동 소개 페이지에서는 iriscouch.com의 ‘cloud couchDB’를 통한 연동을 소개한다.
 하지만 가격 정책이 있고 향후 확장성을 고려하여 이를 배제하고, 일반 couchDB에 구성을 하여 동일하게 동작하도록 구성한다.
      1. CouchDB 설치

      1. CouchDB 구성

  • DB 생성(ex. crashlog db 생성) : admin > ‘create Database’ 클릭
  • Restful API 배포
    couchDB는 Restful API를 기본 기능으로 제공한다.
    위 예제와 같이 crashlog로 DB를 구성한 경우 아래와 같이 클라이언트에 API를 배하면 된다.
    http://192.168.0.35:5984/crashlog
  • DB 내용 확인
    futon admin에서 ‘crashlog’ DB를 클릭하면, 클라이언트에서 전송된 crashlog를 확인 할수 있다.

<그림. DB에 저장된 데이터(2건)>
<그림. 데이터 상세 내역>
      1. 데이터 분석
        https://github.com/ACRA/acralyzer/wiki/manual-setup
        위 setup 가이드를 통해 4.3 viewer 구성 가능
        하지만 커스터마이징을 위해서 관련 라이브러리/소스 분석 작업이 필요하다.
        <그림. iriscouch 연동을 통한 분석 결과 화면>


acralyzer를 이용하지 않고 couchDB의 데이터를 직접 추출하여 화면을 구성하는 방법도 가능하다.
* 참고사항
acra lib에 의해 생성된 json-body에 포함된 crash발생 시각은 단말 기준 시간이다.
    1. R-DBMS

저장 DB(couchDB, R-DBMS)의 종류에 상관없이 연동 규격은 동일하게 구성할 것을 추천한다.
단말은 서버의 DB종류에 상관없이 crashlog수집 및 전송을 위해 acra lib을 사용한다.
서버는 동일한 연동 규격(4.1 couchDB에 소개된 restful API)을 제공한다.


단말로부터 전달받는 정보는 http post방식의 json data이므로
R-DBMS구성을 json data규격을 고려하여 구성할 것을 추천한다.
(acra lib에서 추출되는 json data를 모두 전송할 것인지는 논의 필요)


HTTP연동방식, DB구성, JSON 파싱 등에 제약사항은 없으며, 일반적인 웹 프로젝트 구성에 준해서 진행하도록 한다.


    1. Viewer



  1. 맺음

    1. Report Contents

: 내용이 방대하여 필요부분만 뽑아 전송
ANDROID_VERSION
APP_VERSION_CODE
APP_VERSION_NAME
APPLICATION_LOG
AVAILABLE_MEM_SIZE
BRAND
BUILD
CRASH_CONFIGURATION
CUSTOM_DATA ??
DEVICE_FEATURES
DEVICE_ID
DISPLAY
DROPBOX
DUMPSYS_MEMINFO
ENVIRONMENT
EVENTSLOG
FILE_PATH
INITIAL_CONFIGURATION
INSTALLATION_ID
IS_SILENT
LOGCAT
MEDIA_CODEC_LIST
PACKAGE_NAME
PHONE_MODEL
PRODUCT
RADIOLOG
REPORT_ID
SETTINGS_GLOBAL
SETTINGS_SECURE
SETTINGS_SYSTEM
SHARED_PREFERENCES
STACK_TRACE
THREAD_DETAILS
TOTAL_MEM_SIZE
USER_APP_START_DATE
USER_COMMENT
USER_CRASH_DATE
USER_EMAIL

    1. 분류기준

: 크래쉬 분석시 분류기준으로 잡아야할 사항에 대한 정의 필요
- AppVersion
- Crash Type
- Crash Address  : STACK_TRACE 로 잡으면 되나 내용이 방대함
- Device Type
- Android Version
- Catched Exception / uncatched Exception
-- End of Document--