2016년 4월 12일 화요일

[Linux] 리눅스 커널 다운로드

리눅스 커널 다운로드
www.kernel.org

 https://www.kernel.org/pub/linux/kernel/v2.6/
작성자: 시간: 댓글 없음:
라벨: , ,

2016년 4월 11일 월요일

[인사이드 안드로이드] 1. 안드로이드 프레임워크 개요




안드로이드 구조 - 한글
android structure








  • 프레임 워크를 이해하면 좋은점 
    • 구조와 동작원리 파악 -> 안드로이드 프레임워크에 최적화된 S/W설계 가능


<안드로이드 주요 소스코드 구성>

  1. Kernel  
    • 안드로이드 리눅스 커널
  2. Bionic 
    • 인드로이드 표준 C 라이브러리
  3. Bootloader 
    • 참고용 안드로이드 부트로더
  4. Build 
    • 안드로이드 빌드 시스템
  5. Cts
    • 안드로이드 호환성 테스트 관련 소스
  6. Dalvik 
    • 달빅 가상머신
  7. External
    • 안드로이드에서 사용하는 오픈 소스
  8. Framework
    • 안드로이드 프레임워크
  9. Hardware
    • 안드로이드 HAL(Hardware Abstraction Layer) 소스
  10. Packages 
    • 안드로이드 기본 어플리케이션, 컨텐트 프로바이더 등..
  11. System 
    • 안드로이드 init 프로세스, 블루트스 도구 모음 등..


<안드로이드 부팅 과정>




Step으로 분류

Linux(embedded system) VS Android VS Linux comparing



  1. 리눅스 커널
    • 안드로이드 - 리눅스 기반 플랫폼
  2. init
    • init프로세스 - 각종디바이스 초기화, 안드로이드 프레임워크 동작에 필요한 각종 데몬, 컨텍스트 매니저, 미디어 서버, Zygote등을 실행하는 프로세스
  3. 컨텍스트 매니저
    • 프로세스, 시스템 서비스 관리(안드로이드의 시스템 서비스)
      • 모든 시스템 서비스는 부팅시 자신의 핸들정보를 컨텍스트 매니저에 등록해야 됨
    • 프로세스간 통신 - IPC(Inter-Process Communication) 바인더
  4. 미디어 서버
    • C/C++ 기반으로 작성돼 있는 네이티브 시스템 서비스를 실행하는 역할
      • ex) Audio Flinger(오디오 출력담당), Camera
  5. Zygote
    • 애플리케이션의 로딩시간을 단축시키기 위한 목적으로 사용됨
    • 자바기반 앱은 Zygote를 통해 fork된 프로세스 상에서 동작
  6. 시스템 서버
    • Zygote에서 최초로 fork된 애플리케이션 프로세스
    • 자바시스템 서비스를 실행하는 역할


리눅스 부팅과정
http://www.linuxlab.co.kr/docs/5-2.htm

http://else102.tistory.com/entry/%EB%A6%AC%EB%88%85%EC%8A%A4-%EC%8B%9C%EC%8A%A4%ED%85%9C-%EC%A0%84%EC%B2%B4-%EB%B6%80%ED%8C%85%EA%B3%BC%EC%A0%95%EC%9D%98-%EC%9D%B4%ED%95%B4


작성자: 시간: 댓글 없음:
라벨: , ,

[인사이드 안드로이드] 1. 목차


1. 목차
  1. 안드로이드 프레임워크 개요
  2. 안드로이드 개발환경 구축
  3. init 프로세스
  4. JNI와 NDK
  5. Zygote
  6. 안드로이드 서비스 개요
  7. 안드로이드 바인더 IPC
  8. 안드로이드 서비스 프레임워크
  9. 네이티브 시스템 서비스 분석
  10. 자바 서비스 프레임 워크
  11. 자바 시스템 서비스 동작 분석
  12. 부록 - AIDL 언어의 문법


작성자: 시간: 댓글 없음:
라벨: , ,

2016년 4월 10일 일요일

[프로그래밍] 프로그래밍의 미래에 대한 12가지 예언

http://www.itworld.co.kr/slideshow/89568?slide=1#stage_slide
작성자: 시간: 댓글 없음:
라벨:

2016년 4월 8일 금요일

[퍼스트클래스 승객은 펜을 빌리지 않는다]


작성자: 시간: 댓글 없음:
라벨: ,

2016년 1월 8일 금요일

[Java - Game] 슈팅게임 - 1.2 



import java.util.logging.Level;
import java.util.logging.Logger;

import org.newdawn.slick.AppGameContainer;
import org.newdawn.slick.BasicGame;
import org.newdawn.slick.GameContainer;
import org.newdawn.slick.Graphics;
import org.newdawn.slick.SlickException;

public class Test extends BasicGame {

 public Test(String title) {
  super(title);
  // TODO Auto-generated constructor stub
 }
 
 @Override
 public void render(GameContainer arg0, Graphics arg1) throws SlickException{
  //TODO Auto-generated method stud
 }

 @Override
 public void init(GameContainer arg0) throws SlickException {
  // TODO Auto-generated method stub
  
 }

 @Override
 public void update(GameContainer arg0, int arg1) throws SlickException {
  // TODO Auto-generated method stub
  
 }
 
 public static void main(String[] args){
  
  
  try {
   AppGameContainer appgc;
   appgc = new AppGameContainer(new Test("Hello World!"));
   appgc.setDisplayMode(640, 480, false);
   appgc.start();
   
  } catch (SlickException e) {
   // TODO Auto-generated catch block
   //e.printStackTrace();
   Logger.getLogger(Test.class.getName()).log(Level.SEVERE, null, e);
  }
  
 }

}

실행결과

실행시 팝업된 윈도우창


실행 후 이클립스 Console 창

작성자: 시간: 댓글 없음:
라벨: , , ,

[Java - Game] 슈팅게임 - 1.1

본 페이지는 해당 블로그의 강좌를 따라 공부하며 정리한 내용을 기록한 것 입니다. http://blog.naver.com/sksd321/220411030175
  • 슈팅게임 - 1
    1. 라이브러리 추가 - 이클립스
      1. LWTGL2
      2. Slick2D
      3. 추가 방법
    2. LWTGL2
      1. Introduction
        • The Lightweight Java Game Library (LWJGL) is a solution aimed directly at professional and amateur Java programmers alike to enable commercial quality games to be written in Java. LWJGL provides developers access to high performance crossplatform libraries such as OpenGL (Open Graphics Library), OpenCL (Open Computing Language) and OpenAL (Open Audio Library) allowing for state of the art 3D games and 3D sound. Additionally LWJGL provides access to controllers such as Gamepads, Steering wheel and Joysticks. All in a simple and straight forward API.
          • Lightweight Java Game Library은 프로와 아마추어 자바 프로그래머를 겨낭한 것으로 상용 품질의 게임을 자바로 작성 할 수 있습니다. LWJGL은 OpenGL과 같은 고성능 크로스 플랫폼 라이브러리로 개발자 액세스를 제공합니다. OpenCL과 OpenAL은 예술 3D 게임 및 3D 사운드의 상태를 허용합니다. 추가적으로 LWJGL는 게임패드, 스티어링 휠 및 조이스틱과 같은 제어장치에 대한 액세스을 제공합니다. 모든 것이 간단하고 복잡하지 않는 AP입니다..
        • LWJGL is not meant to make writing games particularly easy; it is primarily an enabling technology which allows developers to get at resources that are simply otherwise unavailable or poorly implemented on the existingJava platform. We anticipate that the LWJGL will, through evolution and extension, become the foundation for more complete game libraries and "game engines" as they have popularly become known, and hide some of the new evils we have had to expose in the APIs.
          • LWJGL은 게임 작성을 특별히 쉽게하는 것은 아닙니다; 그것은 주로 개발자가 단순히 그렇지 않으면 사용할 수 없거나 기존의 자바 플랫폼 상에서 잘못 구현되어 있는 자원에서 얻을 수 있게 한 기술입니다. 우리는 LWJGL이 진화와 확장을 통해 완벽한 게임 라이브러리와 그들이 널리 알려져 “게임 엔진”의 기초가 되고 우리는 API에서 공개해야만 새로운 악마의 일부를 숨길 수 있도록 기대합니다.
      2. About LWJGL
        • Speed 
          • The whole point of LWJGL was to bring the speed of Java rendering into the 21st century. This is why we have:
            1. Thrown out methods designed for efficient C programming that make no sense at all in java, such as glColor3fv.
            2. Made the library throw an exception when hardware acceleration is not available on Windows. No point in running at 5fps is there?
        • Ubiquity
          • Our library is designed to work on devices as small as phones right the way up to multiprocessor rendering servers. Just because there aren't any phones or consoles yet with fast enough JVMs and 3d acceleration is neither here nor there - there will be, one day. We're carefully tailoring the library so that when it happens we'll have OpenGL ES support in there just like that. This means that:
            1. We had to have a very small footprint or it'll never catch on in the J2ME space at all. That's why the binary distribution is under half a meg, and that takes care of 3d sound, graphics, and IO.
            2. Even under desktop environments having a 1-2mb download just to call a few 3D functions is daft.
            3. We've worked to a lowest common denominator principle rather than attempting to design for all possibilities, but we've made sure that 99% of required uses are covered. That's why we've only got one window, and why we don't guarantee that windowed mode is even supported (it's officially a debug mode and hence we don't even supply some very basic windowy abilities that you'd get in AWT) and why we don't allow multiple thread rendering contexts.
        • Simplicity
          • LWJGL needed to be simple for it to be used by a wide range of developers. We wanted relative newbies to be able to get on with it, and professionals to be able to use it professionally, maybe typically coming from a C++ background. We had to choose a paradigm that actually fits with OpenGL, and one that fits with our target platforms which ranges from PDA to desktop level. This is why:
            1. We aren't catering for single-buffered drawing
            2. We don't require that an instance of GL is passed around all over the place but we do not prevent this style of coding. See below for why.
            3. We removed a lot of stuff that 99% of games programmers need to know nothing about
            4. We have decided that consistency is better than complexity. Rather than allowing multiple ways to call the same methods and bloating the library we've just said, "Right, no arrays. They're slower anyway. Get used to buffers, as this is what buffers are meant to be used for."
        • Smallness
          • See ubiquity above. We had to be small.
            1. Small == simple. The fewer ways there are to do something, the easier it is to learn the only way that works or is allowed.
            2. Small == our code is less buggy. Wouldn't you rather be hunting for bugs in your own code, not ours?
            3. Small == downloadable. No version nightmares. LWJGL is small enough to download with every application that uses it.
            4. Small == J2ME.
        • Security
          • We realised a few months ago that no-one was going to take us seriously if we couldn't guarantee the security of the LWJGL native libraries. This is why we:
          1. No longer use pointers but exclusively use buffers instead
          2. Are gradually adding further checks to buffer positions and limits to ensure that the values are within allowed ranges to prevent buffer attacks
        • Robustness
          • Similarly to security we have now realised that a reliable system is far more useful than a fast system. When we actually had a proper application to benchmark finally we had some real data. Many of our original design decisions were based on microbenchmarks - well, you have to start somewhere! But with a real application to benchmark we now know we can throw out asserts and replace them with a proper if (...) check and a thrown exception. We know also that we can move all that GL error checking out of native code and into Java code and we will no longer need a separate DLL for debug mode.
          • As for runtime exceptions, they have their place. There's not a reasonably well defined argument as to when you should use a runtime exception and when you should use a checked exception. When I made OpenGLException a checked exception all it did was end up littering my code with try {} catch {} sections - except that if you've got an OpenGLException there is very little sensible you can do to rectify it because it should never have occurred in the first place. That's why it's a runtime exception. You should simply not write code than can throw it because it is generally not recoverable nicely. However for robustness (and security) we are required to throw an exception if something is amiss. It falls, I believe, into exactly the same category of trouble as NPEs, ArrayIndexOOBs and ClassCastExceptions: should never occur but needs to be trapped somewhere.
        • Minimalism
          • This is another critical factor in our design decisions. If it doesn't need to be in the library, it's not in the library. Our original aim was to produce a library that provided the bare minimum required to access the hardware that Java couldn't access, and by and large we're sticking to this mantra. The vector math code in the LWJGL is looking mighty scared at the moment because it's probably for the chop - well, at least, from the core library - as it's not an enabling technology at all, and there are numerous more fully featured alternatives. We chucked out GLU because it's mostly irrelevant to game developers except for a few functions that we really need to get redeveloped in pure Java - but basically, GLU is just a library of code built on top of the enablement layer.
      3. Slick2D
        1. Home
          1. Slick2D is an easy to use set of tools and utilites wrapped around LWJGL OpenGL bindings to make 2D Java game development easier.
        2. Javadoc
          1. http://slick.ninjacave.com/javadoc/
        3. Slick-Util
          • Slick-Util is a small library to enable you to load various image, sound and font formats for use with LWJGL.
          • Its basically a subset of the full Slick2D library which contains various useful classes that can be used by users working with LWJGL code directly.
        4. License
          • All rights reserved.
            Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:
            * Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
            * Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
            * Neither the name of the Slick2D nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.
            THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS “AS IS” AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
        5. Wiki
          1. 사이트
            1. http://slick.ninjacave.com/wiki/index.php?title=Main_Page
          2. Contents
            1. Getting Starting
              1. Setting up Slick2D with NetBeansIDE
              2. Setting up Slick2D with Eclipse
              3. Hello World
            2. Learning the basics
              1. Inputs
              2. Graphics
              3. Game States
              4. Custom Application Icon
            3. Graphics
              1. Clipping
              2. Game Containers
              3. Image Buffer
              4. Image
              5. Rendering to an Image
              6. Scalable Vector Graphics
            4. Advanced
              1. Loading libraries and natives from path
            5. More
              1. ...and more
            6. Links
              1. Website
              2. Forums
              3. Javadoc
              4. Source code repo
              5. Maven package
작성자: 시간: 댓글 없음:
라벨: , , ,
피드 구독하기: 글 (Atom)