• View 위젯들을 그룹화하여 배치하기 위한 용도로 사용되는 ViewGroup

ViewGroup

• 다른 View를 포함할 수 있는 View
• 컨테이너 역할을 수행

LinearLayout & RelativeLayout & FrameLayout

LinearLayout

• 여러 View 위젯들을 가로/세로 방향으로 나열할 때 사용하는 Layout
• orientation 속성을 가지고 있어 가로(Horizontal), 세로(Vertical)을 설정할 수 있다.
• 자식들은 중첩되지 않고 지정한 방향으로 쌓이는 형태로 표시된다.
• weight 속성으로 가중치를 설정할 수 있다. 비율로 나타낼 수 있다. 다양한 디바이스 화면에 dp가 아니라 비율에 따른 대응으론 좋다. (그러나 onLayout()를 자주 호출하여 상관관계를 파악하기에 성능상 좋진 않다)

RelativeLayout

• 자식 View 위젯들이 서로 간의 상대적 배치 관계에 따라 화면에 표시될 위치가 결정되도록 만들어주는 Layout 클래스
• 상대적인 배치 기준을 정하지 않는다면, 내부에서 중첩되어 표시된다.
• 특정 위젯을 기준으로 배치하게 된다.
• 아무런 조작을 하지 않았을 때는 왼쪽 상단부터 위젯이 쌓이게 된다.

FrameLayout

• 주로 하나의 자식 View위젯만 표시할 때 사용하는 layout 클래스.
• 추가된 순서대로 쌓이게 되기에 마지막에 추가된 뷰가 가장 위에 올라오게 된다.
• 여러 Fragment를 동일한 위치 내에서 교체하여 표시하고자 할 때, Fragment의 컨테이너 역할로써 FrameLayout을 주로 사용한다.
• 보통 로딩중 Progress를 보여줄 때

ConstraintLayout

레이아웃에 배치되는 뷰들에 여러 제약을 적용하여 각 뷰의 위치와 크기를 결정하는 레이아웃

• RelativeLayout의 상대적 위치 관계에 따른 배치 + LinearLayout의 가중치가 가진 장점 + chain 사용을 다른 레이아웃 없이 요소들을 그룹화

• ConstraintLayout는 성능향상을 얻을 수 있다. (수평적인 구조로 인해)

• ConstraintLayout은 레이아웃에 배치되는 뷰들에 여러 제약을 적용하여 각 뷰의 위치와 크기를 결정한다.

RelativeLayout

레이아웃 내의 자식 뷰 위젯들이 서로 간의 상대적 위치 관계에 따라 최종적으로 표시될 영역을 결정하도록 만드는 레이아웃

왜 ConstraintLayout을 써야할까?

LinearLayout, RelativeLayout, ConstraintLayout의 효율을 비교한 포스팅이 있어서 가져왔다.

이 글에서는 ConstraintLayout을 LinearLayout, RelativeLayout 대비해서 설명하고 있다.

해당 글에선 onMeasure() 호출 개수를 가지고서 레이아웃 성능 비교를 하고 있다.

이렇게 3가지의 비교만 보더라도 ConstraintLayout의 호출횟수가 적은 것을 볼수 있다. onMeasure() 메서드는 뷰의 크기를 구하는 역할을 하게 되는데 이 과정을 LinearLayout은 10번 RelativeLayout은 14번 ConstraintLayout은 8번을 수행한다.

특히, RelativeLayout의 경우, 특정 뷰를 기준으로 상대적인 위치를 나타내기에 특정 뷰 위치를 구하는 것을 반복하게 된다.

relative layout에서 4 depth이상 들어가야하는 것도 ConstraintLayout에선 1 depth로 가능!!!

위 글의 대부분의 내용은 안드로이드 View가 렌더링 되는 과정 해당 글을 참고하여 적었습니다.

Intro

안드로이드의 화면은 아래와 같은 단위로 구성된다. 화면을 구성하는 최소단위는 View이며 최대 단위는 Window이다.

Window > Surface > Canvas > View

Window

• 화면 구성의 가장 상위 요소로 무언가를 그릴 수 있는 화면 상 사각 영역이다.
• 어플리케이션에서는 각각의 Window에 Surface를 만들어 어플리케이션에 전달하고, 어플리케이션은 이를 통해 화면을 렌더링한다.
• 터치 이벤트, 키 이벤트 등 사용자 이벤트를 받아 처리할 수 있다.
• statusBar
• SoftKey

Surface

• Surface는 화면에 합성되는 픽셀을 보유한 객체
• 화면에 표시되는 모든 Window(StatusBar, Dialog, Activity etc)는 자신만의 Surface를 가지고 있으며
• Surface Flinger가 여러 소스로부터 그래픽 데이터 버퍼를 받고, 그것들을 합성하여 display로 보낸다.

Canvas

• 모든 드로인 메서드를 포함하고 있는 클래스
• 각종 도형, 선 등을 그리기 위한 모든 로직이 Canvas에 포함되어 있다.
• Bitmap 또는 OpenGL 컨테이너 위에 그려진다.

View 렌더링 과정

XML로 작성한 View가 어떻게 최종적으로 화면에 렌더링 되는 지 ?

Android에서는 Activity가 Focus를 얻게 되면 자신의 Layout을 그린다.

이때 그리고자 하는 Layout의 Root Node를 요청하게 되는데, 우리가 setContentView()를 호출할 때 Root Node가 정해진다.

Root Node가 결정되면 Root Node를 따라 Child Node를 따라가면서 차례대로 View를 그리게 된다.

그리는 순서

Layout을 그리는 건 측정과 순서란 과정을 따른다.

measure() > onMeasure() > layout() > onLayout()

• measure(widthMeasureSpec :Int, heightMeasureSpec:Int)

  • 뷰의 크기를 알아내기 위해 호출되며, 실제 크기 측정을 위해 onMeausre()를 호출한다.
  • widthMeasureSpec : Parent가 뷰여한 필요한 가로 공간
  • heightMeasureSpec : Parent가 부여한 필요한 세로 공간

• onMeasure(widthMeasureSpec :Int, heightMeasureSpec:Int)

  • 실제 뷰의 크기를 측정한다.
  • widthMeasureSpec : Parent가 뷰여한 필요한 가로 공간
  • heightMeasureSpec : Parent가 부여한 필요한 세로 공간

• layout(left:Int, top:Int, right:Int, bottom:Int)

  • 뷰의 위치를 할당하기 위해 호출되며, 실제 할당을 위해 onLayout()을 호출한다.
  • left : Parent에 대한 왼쪽 포지션
  • top : Parent에 대한 위쪽 포지션
  • right : Parent에 대한 오른쪽 포지션
  • bottom : Parent에 대한 하단 포지션

• *onLayout(changed:Boolean, left:Int, top:Int, right:Int, bottom:Int) *

  • 실제 뷰의 크기 및 위치를 할당한다.
  • changed : 새로운 사이즈나 위치인지 맞으면 True/False
  • left : Parent에 대한 왼쪽 포지션
  • top : Parent에 대한 위쪽 포지션
  • right : Parent에 대한 오른쪽 포지션
  • bottom : Parent에 대한 하단 포지션

View의 생명주기

measure() > layout() > draw()

onAttachToWindow()

• 뷰가 윈도우에 붙었을때 호출
• Parent View가 addView(view:View)를 호출하면 해당 View가 window에 연결된다. 이 단계부터 id를 통해 접근 가능하다.

measure()

• 🌟뷰들의 사이즈를 측정(결정)

onMeasure()

• View의 사이즈를 측정
• 요구된 View와 Child View의 사이즈가 결정되면 호출된다.

layout()

onLayout()

• Child 뷰의 사이즈 및 위치 할당
• View와 ChildView의 사이즈와 포지션을 적용할 때 호출
• 🌟뷰를 측정하여 화면에 배치한 후 호출된다.

dispatchToDraw()

onDraw()

• Canvas와 Paint를 사용해서 뷰를 그리기 시작
• 뷰가 화면에 컨텐츠(텍스트,이미지 등)을 그릴 준비가 되었을 때 호출
• Canvas 객체를 생성하고 뷰를 그린다.

View Update

• 특정 속성이 변경되었을 때 호출되는 메서드

invalidate()

• 변경사항을 보여주고자 하는 특정 뷰에 대해 강제로 다시 그리기를 요구하는 메소드.
• 뷰 모양이 변경되면 invalidate()를 호출해야 한다.

requestLayout()

• 어떤 시점에서 뷰의 경계가 변경되었다면, View를 다시 측정하기 위해 requestLayout()을 호출하여 Measure 및 Layout 단계를 다시 거칠 수 있다.

Rasterization (래스터화)

문자열, 버튼 또는 도형과 같은 객체들을 픽셀로 변환시키고 스크린 상의 텍스처로 나타내는 과정을 말한다.

• 레스터화는 비용이 큰 작업에 속한다.
• 그러므로 GPU가 래스터화 가속을 위해 사용된다.
• CPU는 polygon, texture 등을 계산하고 처리하는 데 특화되어 설계되었다.(병렬 처리)

CPU는 화면에 무언가 그리기 위해 GPU에게 폴리곤이나 텍스쳐의 래스터화를 위임하고 GPU의 최종적인 처리 결과가 화면에 나타난다.

이러한 CPU와 GPU의 데이터 전송 처리는 일반적으로 OpenGL ES API의 호출에 의해 일어난다. 안드로이드에서 점,선,면을 포함한 버튼, 이미지 등의 UI 객체가 화면에 나타나기 위해서는 항상 OpenGL ES를 거치게 된다. OpenGL은 3개의 정점을 이어 하나의 삼격형을 이루고 이를 PolyGon이라고 한다. Polygon이 모여 메쉬를 이룬다. 예를 들어, 아주 간단한 UI 버튼을 화면에 렌더링 하는 과정을 생각해보자. 우선, 버튼이 있어야 하고, 이를 CPU에 의해 폴리곤과 텍스처로 변환 시킨 뒤 GPU에게 넘겨지게 된다.

UI객체를 메쉬로 변환하는 과정은 비용이 큰 작업이다. 모든 변환 과정이 끝난 뒤 변환된 데이터가 OpenGL ES API에 의해 CPU에서 GPU로 전달되게 된다.

결국 렌더링 퍼포먼스를 최적화한다는 의미는 _GPU메모리에 데이터를 얼마나 많이 적재하고 제거하며 이를 얼마나 잘 참조하냐_이다.

UI 퍼포먼스

OverDraw > UI 퍼포먼스를 저하

오버드로우는 시스템이 단일 렌더링 프레임에서 같은 픽셀을 여러번 덧 그리는 것이다. 이러한 GPU의 리소스 낭비로 인해 퍼포먼스가 떨어지고, 사용자에게 나쁜경험을 제공할 수 있다.

오버드로잉을 줄이기 위한 몇가지 방법

• 레이아웃에서 불필요한 배경 제거
• 뷰 계층을 평탄화 하기
  • 이때 ConstraintLayout의 큰 효과를 볼 수 있다.
  • ConstraintLayout은 레이아웃 내에 또 다른 레이아웃을 포함시킬 필요 없이 간단한 제약조건으로 평탄한 계층 구조를 만든다.
  • 평탄한 뷰 계층을 구성하여 퍼포먼스를 향상하자.
• 투명도 줄이기

Ref

• https://www.charlezz.com/?p=34935
• https://developer.android.com/topic/performance/rendering?hl=ko

우선 두 용어는 모두 SW 프로그램 개발의 서로 다른 두 계층의 차이를 설명하기 위한 용어이다.

Compiletime 컴파일 타임

프로그램을 생성하기 위해 개발자는 첫째로 소스코드를 작성하고 컴파일이라는 과정을 통해 기계어 코드로 변환되어 실행 가능한 프로그램이 된다.

Runtime 런타임

컴파일 과정을 마친 프로그램은 사용자에 의해 실행되며 이러한 응용프로그램이 동작되어지는 때를 런타임이라고 한다.

종종 2가지 타입의 에러를 나타내기 위해 사용되어지곤 한다.

오류의 유형 차이

• 컴파일 타임 오류 유형

  • Syntax 오류
  • Type check 오류

• 런타임 오류의 유형

  • 0 나누기 오류
  • Null 참조 오류
  • 메모리 부족 오류

MultiDex?

ART 위에서 동작하기 위해 안드로이드 코드는 dex 파일로 컴파일 된다. 이때, 메서드 수가 64k(65535)개를 초과할 수 없어서 나오게 된 개념이 Multidex이다.

Multidex는 메서드가 64k(65536)개를 초과하지 않도록 dex파일을 여러개로 쪼개주고 쪼개진 dex를 읽을 수 있게 해준다.

어떻게?

minSdkVersion이 21 이상인 경우, multidex는 기본 사용 설정이 된다.

20이하의 경우엔 명시적으로 선언을 해줘야한다.

  // build.gradle

  android{
    complieSdkVersion 28
    defaultConfig{
      ...

      // 멀티덱스 기능 true
      multiDexEnabled true
    }
    ...
  }

  dependencies{
    // 의존성 추가
    implementation 'com.android.support:multidex:1.0.3'
  }
  import android.support.multidex.MultiDexApplication;

  public class App extends MultiDexApplication{ // 매니페스트의 앱 이름과 같은 클래스가 상속받아야한다.
    @Override
    public void onCreate(){
      super.onCreate();
    }
  }

Ref

• https://colinch4.github.io/2020-11-25/Multidex/

코드를 난독화 및 최적화 시켜주는 오픈 소스 툴

• 무료 자바 클래스 파일 축소기, 최적화기, 난독화기, 프리버레이터.
• 사용되지 않는 클래스, 필드, 방법, 속성을 검출해 제거한다.
• bytecode를 최적화하고 사용하지 않는 지시사항을 제거한다.
• 짧은 의미 없는 이름을 사용하여 나머지 클래스, 필드, 방법의 이름을 바꾼다.

필요 이유

자바는 JVM위에서 바이트 코드 형태로 컴파일 된다. 이때, 컴파일 된 코드에서 자바 소스코드 정보가 그대로 포함되어 있기에 디컴파일을 하면 쉽게 코드를 얻을 수 있다. 그렇기에 디컴파일 시에 알아볼 수 없도록.

• 코드 난독화로 인해 디컴파일 시 본인 코드 노출을 방지할 수 있다.
• 불필요한 메서드를 제거하여 멀티덱스를 피할 수 있다.

멀티덱스(Multidex)..?

• 안드로이드 앱을 구성하는 코드는 컴파일 되어 덱스(dex)파일로 만들어진다.
• 하나의 덱스파일에는 최대 65536개의 메서드만 참조할 수 있다.
• 만약 프로젝트의 코드가 65536개의 메소드를 초과하게 될 경우 덱스파일이 여러개 생성된다.
• 그러면 멀티덱스를 사용하여 컴파일 할 수 있지만, 빌드 과정에서 앱 내의 파일을 여러 개의 덱스파일로 나눠야 하므로 빌드 속도가 느려지고 apk용량이 커진다.

Proguard를 사용하지 않았을 시 문제점

• 프로젝트 코드가 난독화가 되지 않아 디버그 시에 코드 노출이 우려된다.
• 불필요 코드가 앱 컴파일 시 포함되어 불필요하게 앱의 용량이 증가한다.
• 불필요 코드가 컴파일에 포함되기에 개발시 메서드 65536개 초과로 멀티덱스 사용을 피할 수 없다.

장점

• 프로젝트 코드 난독화
• 프로젝트에서 사용하지 않는 메서드 제거
• 불필요한 메서드 제거로 인해 멀티덱스 사용하지 않을 수 있음

APK 빌드 과정

앱 관련(R.java, 소스코드, 자바 인터페이스) 코드들은 컴파일을 거쳐

1. 바이트 코드로 전환되고
2. 인증을 포함한 패키징 과정을 통해 생성된다.

1️⃣ Android Manifest, xml 등 모든 리소스 파일들이 컴파일되어 R.java 파일을 생성하여 AAPT 파일을 생성하고 특정 resourceid로 매핑시킨다.

2️⃣ .aidl interface를 자바 인터페이스로 만들어준다.

3️⃣ javac는 앱 관련 코드(R.java 파일, 소스코드, 자바 인터페이스)를 컴파일 하여 바이트코드(.class파일)로 변환되며 이때 프로가드 과정이 일어난다. (dex파일 생성)

4️⃣ dex + 3rd party library 클래스 파일 -> .dex file

5️⃣ AAPT + .dex file -> apk로 패키징 -> .apk 생성

6️⃣ debug 또는 release 용 keystore로 인증 진행 -> 인증된 .apk 생성

6️⃣-1️⃣ release 모드로 인증 시 zipalign tool을 이용하여 align 시켜줌(align시 메모리 효율성을 높여줌)

Ref

• https://iw90.tistory.com/298
• https://dwenn.tistory.com/95

WebRTC ?

• Web Real-Time Communication
• 웹 어플리케이션 및 사이트들이 별도의 소프트웨어 없이 음성, 영상 미디어 혹은 텍스트, 파일 같은 데이터를 브라우저끼리 주고 받을 수 있게 만든 기술.
• WebRTC로 구성된 프로그램들은 별도의 플러그인이나 소프트웨어 없이 P2P 화상회의 및 데이터 공유를 한다.

웹 브라우저 상에서 어떠한 플러그인도 필요없이 음성 채팅과 화상 채팅, 데이터 교환까지 가능한 기술

같이 알아야 할 용어 개념

• data stream, STUN/TURN servers, signaling, JSEP, ICE, SIP, SDP, NAT, UPD/TCP, network socket 등

통신 원리

WebRTC 기술은 P2P 통신에 최적화되어 있다. WebRTC에 사용되는 기술은 여러 가지가 있지만 크게 3가지의 클래스에 의해 실시간 데이터 교환이 일어난다.

• MediaStream : 카메라와 마이크 등의 데이터 스트림 접근
• RTCPeerConnection : 암호화 및 대역폭 관리 및 오디오, 비디오 연결
• RTCDataChannel : 일반적인 데이터의 P2P 통신

이 3가지의 객체를 통해 데이터 교환이 이뤄지며 RTCPeerConnection들이 적절하게 데이터를 교환할 수 있게 처리해주는 과정을 시그널링(Signaling)이라고 한다.

위 그림은 시그널링을 하는 과정이며 PeerConnection은 2 명의 유저가 스트림을 주고 받는 것이므로 연결을 요청하는 콜러(Caller)와 연결을 받는 콜리(Callee)가 존재한다.

콜러와 콜리가 통신을 하기 위해서는 중간 역할을 해주는 서버가 필요하고 서버를 통해 SessionDescription을 서로 주고 받아야한다.

장점

Latency가 짧다.

흔히 우리가 아는 인스타라이브, 유튜브라이브, 트위치 등은 RTMP를 사용하여 실시간 스트리밍을 한다. RTMP보다 WebRTC는 낮은 Latency를 가지고 있고 거의 지연 시간 없는 REAL-TIME 성향을 갖고 있따.

별 다른 소프트웨어 없이 실시간 커뮤니케이션이 가능하다.

웹/앱으로 방송을 키고 싶을 때, 별도의 플러그인이나 미디어 송출 관련 소프트웨어 설치가 필요없다.

개발 시 진입 장벽이 낮다.

단점

크로스 브라우징 문제

WebRTC는 현재 크롬,오페라,파이어폭스 뿐아니라 안드로이드, IOS 등 브라우저, 앱에서 활용가능하다. 그러나 최신 버전을 사용하지 않는 사용자는 사용이 불가능하다는 단점이 있다. (IE 지원은 안한다고 한다)

STUN/TURN 서버 필요

P2P 통신을 위해서는 사용자의 IP 주소를 알아야한다. 하지만, 대부분의 사용자는 방화벽 등을 사용하고 다른 네트워크 상에서 연결이 이뤄지기 위해서는 STUN/TURN서버가 꼭 필요하다.

관련 개념을 정리해두신 블로그

추가 설치를 덕지덕지해야하는 activex, flash를 지워버리고 당당하게 스트리밍 기술로 상용화된 WebRTC에 대해서 실제로 작업을 해보면서 더 익혀봐야 할것 같다.

그리고 충분한 네트워크 공부가 바탕이 되어야 깊은 이해가 될 수 있을 것 같다.

🆒

해당 글은 A Garbage Collection Story를 번역한 글이며 아주 조금의 첨언이 되어있는 글입니다.

출처는 ProAndroidDev

몇몇 안드로이드 관련 아티클을 찾아보는 곳 중 공식 미디엄 말곤 proandroiddev를 많이 보게 된다. 생각해보지 못한 부분에 대한 글 혹은 이것도 공부하면 좋겠다 싶은 글이 많다.

🆗 아무튼 오늘 번역할 이야기는 안드로이드 GC 이야기다.

JVM의 GC는 공부하였지만 Android에서 GC는 다른 이야기일 것이다. 왜? Android는 JVM이 아닌 DVM(Dalvik Virtual Machine)에서 동작한다. DalVik부터 ART까지 GC의 발전 역사를 알아보자.

Introduction

여러 차들이 주차되어 있는 주차장을 떠올려보자.

차들이 들어오고 나가며 한 대당 하나의 자리를 차지하게 된다. 물론 승용차가 아닌 대형 트럭이라면 여러 자리를 차지할 수도 있다. 사람들은 아마 이 부분에서 화를 낼 수 있다.

이게 바로 메모리다.

Garbage Collector라고 부르는 Recycler Bill이 있다. 일생 단 하나의 목적은 주차장의 쓰레기를 모으는 것이다.

차들이 주차장을 떠날 때 그들은 Bill이 쓰레기를 처리할 수 있도록 잘 모아둔다. 뭐 모든 사람이 잘 모아두진 않는다. 누군가는 쓰레기를 모아서 가방에 넣어두지 않고 간다. 대신, 그들은 쓰레기 더미를 잘 모아두고 떠난다.

불행하게도, Bill은 이 일에 대한 충분한 급여를 받지는 못해서 쓰레기 더미 조차 치울 수는 없습니다. 쓰레기는 이때 애매하게 주차장의 일부를 차지하게 됩니다.

이게 바로 메모리 누수이다.

새로운 차들이 와서 주차하려 할 때, 공간이 충분하지 않을 수 있게 된다.. 주차 공간은 터지게 되고 Bill 역시 머리가 터지겠지? 🤯

이게 바로 OutOfMemoryException이다.

Bill은 단순 Garbage Collector 그 이상이다. 그의 손에는 주차장의 운명이 달릴 정도다..🆒

우리가 할 일이 이제 뭘까? 재활용하는 Bill의 일상을 따라서 그가 주차장을 잘 관리하는 best garbage collector가 되도록.... 한 번 알아보자

(대충 여기까지가 GC의 이유와 목적을 주차장에 비유해서 표현한 부분이다.)

Dalvik Bill (up until Android 4.4)

주차장의 상황이 좋지 않다는 것 정도는 우리 안다.

정~말 필요한 차들만 주차를 해야 한다.

더욱이, Bill은 쓰레기 수거를 위해 청소가 끝날 떄 까지 어떠한 차도 들어오고 나갈 수 없도록 하기에 이 부분은 다소 사람들을 짜증나게 할 수 있다.

Bill은 이러한 고충을 어떻게 해결할까?

여기서 그의 특별한 기술인 Mark and Sweep가 나타난다.

우선, Bill은 자주 쓰레기를 수거하는 것이 좋지 않다는 것을 알아내었다. 대신, 그는 주차장이 꽉 찰 때까지 기다린다. 그리고 꽉차면 그는 쓰레기 수집을 한다.

두 가지 단계로 쓰레기를 수집하는데, 1️⃣ 그는 주차장을 돌아다니면서 차들이 있는 곳을 marking한다. 이 과정에서 주차장 내부의 움직인은 잠시 멈춤을 한다.

2️⃣ 어떠한 위치에 차들이 있는지 알았따면, 그는 마킹되지 않는 주차 공간의 쓰레기들을 sweep하게 된다. 그는 여전히 동일 급여를 받기에 packing되지 않는 쓰레기는 수거하지 않는다.😂

많이 나아졌음에도 bill은 여전히 문제를 갖고 있다.

그가 쓰레기 수집을 한 이 후에, 주차장에 많은 틈이 남아 있다. 군대가 와서 여러 탱크가 주차 공간을 요구한다면?? 👀

이 문제는 Heap Fragmentation 이다.

시간이 지난 후 bill은 해결책을 가져온다.

밤에, 주차장에 유동 트래픽이 많지 않는 때에, 그의 미친 힘으로 차들을 재정렬하고 그럼으로 인해 연속적인 주차 공간을 만들어 낸다.😬

이것이 애플리케이션의 백그라운드에서 발생하고 있는 heap compaction(힙 압축)이다.

realign을 하고 나면 이런식의 주차 공간이 생길 것이다. (100%는 아니지만)

그러나 여전히 문제는 있다. 군대가 낮 시간에 오면?? 주차 공간은 아마.. 폭발할것이다🤮

ART Bill

몇년 동안, Bill 그의 기술을 연마했다.

이제, Bill은 승진을 해서 *낮 시간 동안에도 주차 공간을 realign할 수 있게 *되었다. (승진하면 힘이 더 쎄지는 군) 군대가 탱크를 끌고 오더라도 bill은 수용이 가능해졌다.

이것이 애플리케이션이 포그라운드에 있더라도 발생하는 힙 압축이다.

주차 공간은 더 발전하였고 가격은 내려갔으며 사람들은 이제 이곳에 주차하는 것을 망설이지 않는다.

주차 공간은 더 이상 pause 상태를 갖지 않고 bill은 주차 공간을 marking할 수 있다. 전체 garbage collection 과정은 3배나 빨라졌다.👍

게다가, 주차 공간의 디지털화로 인해 bill은 더욱 쉽게 주차 공간에서 얼마나 차들이 머물고 간지 싑게 추적할 수 있게되었다. 이러한 지식들로, bill은 차들을 그룹화 시킬 수 있게 되었다.

여기엔 3가지의 heap generation가 있다.

• Young Generation (Eden, S0, S1)
• Old Generation
• Permanent Generation

자동차들이 오랜 시간동안 주차를 한다면 bill은 차들을 old generation으로 옮긴다.

각 generation은 주차 된 차량이 차지 할 수 있는 공간에 대한 자체 상한선이 있다. 만약 generation에서 한계에 도달한다면, bill은 해당 generation을 위한 garbage collection을 하게 된다.

여기까지 이야기의 전부이다.

우리가 흔히 JVM을 공부할 때, GC를 공부하게 되고 Young Generation(Eden, S0, S1), Old Generation, Permanet Generation를 공부하고 minor gc, major gc를 공부한다.

해당 글은 주차장과 주차장을 관리하는 bill을 갖고서 gc를 설명하였고 Dalvik에서의 GC와 ART에서의 GC의 차이도 살펴보았다.

잠시 정리해보자.

Dalvik

• Mark & Sweep과정을 통해 쓰레기를 수집하자.
• Heap Fragmentation이 발생한다. 이는 Heap Compaction으로 해결가능한데 백그라운드에서 가능하다.
• 결국 백그라운드가 아니라면 불가능하다는 문제를 마주한다.

ART

• (발전) Heap Compaction을 낮에도 할 수 있다. 포그라운드에서도 할 수 있다는 것이다.
• (발전) 더 이상 pause 상태로 주차장을 멈추고 mark&sweep을 하지 않아도 된다. 3배나 빨라졌다.
• (새로운) 주차 공간을 추적하여 오래 머문 차, 이제 막 들어온 차 이렇게 분류도 할 수 있어서 그룹화 할 수 있게 된다. Generalization

Dalvik에서 ART로 넘어가면서 발전 된 것들과 새롭게 얻게 된 기술, 능력들이 있다. 이를 통해 우린 Android에서 GC가 어떤 발전을 이루었는지 어떤 기능을 갖추었는지 알 수 있다.

deep dive를 하고 싶다면, 아래 영상을 참고하자.👊 Trash Talk: The Evolution of Android Garbage Collection

Ref

• A Garbage Collection Story

곧 Android 12가 출시 되겠지만 그래도...

여러 프로젝트를 해보면서 지도에서 사용자 위치 접근에 대한 퍼미션을 많이 다뤘었다. 근데 정작 허용 여부를 물어보고 허용/비허용에 따른 동작만 다루었을 뿐, 허용에 대한 상세적인 이야기를 다뤄본 적이 없다.

그래서 Android에서의 위치 권한을 이번 글에서 다루고자 한다.

안드로이드 6,10,11 위치 권한 변경 위 글에서 충분히 자세히 설명을 해주시고 있고 난 여기에 덧붙여 설명하려 한다.

우선 위치 권한 퍼미션의 역사를 살펴보면 크게 Android 6.0 이전과 이후로 나눠진다.

Before Android 6.0 (1~22)

Android 6.0 이전에는 앱에서 필요한 권한을 사용자로부터 요구할 때 어플을 설치할 때 요구하였다.

After Android 6.0 (23-마시멜로)

Android 6.0 부터는 앱에서 필요한 권한이 있을 때 사용자로부터 권한을 그때 받게 되었다.

즉, 위치 권한이 필요한 시점에 사용자에게 요청할 수 있었다.

manifest

<uses-permission android:name="android.permission.ACCESS_COARSE_LOCATION" />
<uses-permission android:name="android.permission.ACCESS_FINE_LOCATION" />

ACCESS_COARSE_LOCATION : 네트워크를 이용하여 단말기 위치 식별 ACCESS_FINE_LOCATION : GPS와 네트워크를 이용하여 단말기 위치 식별 (더 정확한 위치는 ACCESS_FINE_LOCATION이라고 한다.)

위치 권한 요청 코드

int permissionCheck = ContextCompat.checkSelfPermission(this, Manifest.permission.ACCESS_FINE_LOCATION);

if(permissionCheck == PackageManager.PERMISSION_DENIED){ //위치 권한 확인

    //위치 권한 요청
    ActivityCompat.requestPermissions(this, new String[]{Manifest.permission.ACCESS_FINE_LOCATION}, 0);
}

이러한 이미지를 통해 허용과 비허용을 체크할 수 있다. 그리고 그 상태에 따라 개발자는 분기처리를 하게 된다.

Android 8 (26)

Android 26에서는 위치 권한 변경 사항이라기보단 백그라운드 위치 제한을 두게 된다!

공식문서 say 기기 성능 개선을 위해 포그라운드 실행 중이지 않은 앱의 특정 동작을 제한한다.

Android 백그라운드 위치 제한

• startService()를 사용하여 백그라운드 서비스 생성이 허용되지 않은 시점에 접근하려 할 경우 illegalStateException을 발생시킨다고 한다.
• 배터리, 사용자 환경 및 시스템 상태를 유지하기 위해 Android 8.0를 실행하는 기기에서 백그라운드 앱 사용 시 위치 업데이트를 받는 빈도가 줄어듭니다. 라고 하면서 제한을 시키기 시작한다...

위치 권한 설정 여부와 관계없지만 Android 8에서 나타난 백그라운드 접근 제한을 시작으로 10부터는 백그라운드 위치 접근을 아예 분리시켜 놓게 된다! 이야기의 흐름 맥락 상 알고있으면 좋을 내용이다.

Android 10 (29)

Android 10에서는 백그라운드 위치 권한과 포그라운드 위치 권한으로 나뉘었다.

백그라운 위치 권한 - 화면이 보이지 않지만 위치는 체크 하고 있는 포그라운 위치 권한 - 앱의 화면이 보이는 상태에서 위치를 체크하게 되는

그래서 백그라운드 위치 권한 요청을 하려면 Manifest에 한 가지 더 추가해줘야 한다.

<uses-permission android:name="android.permission.ACCESS_BACKGROUND_LOCATION" />

이렇게 지정해두게 된다면 권한 허용 여부를 물어보는 과정에서 Android 6과는 다르게 나타난다.

위의 사진에서 볼 수 있듯 3가지의 경우로 분기 처리가 된다.

• *항상 허용 (Allow all the time) *
  • 백그라운드, 포그라운드 모두 허용
• 앱 사용 중에만 허용 (Allow only while using the app)
  • 포그라운드만 부분 허용
• 거부 (deny)
  • 모두 거부

그렇다면 기존에 Android 6 이후에 Background 위치 권한 요청을 하지 않는다면 무슨 일이 일어날까?

여러 영향을 생각해봐야 OS 버전 업데이트를 하더라도 어플 문제가 없지 않을까?

역시나 정리를 해주신 분들이 있다 Android Q 새로운 위치 접근 위 글이 원문이다.

개발자 입장에서의 대응이 궁금해서 가져와봤다.

1️⃣ 사용자가 앱을 사용하는 동안에만 위치 정보를 확인하는 경우

• 사용자 근처에서 특정 장소를 찾는 경우 (해당 앱이 사용자 포커스를 갖고 있는 경우) 기기 위치 정보를 필요로 할 수 있다.
• Target SDK가 Q(10) 미만이라면, 시스템에서 ACCESS_BACKGROUND_LOCATION 권한을 자동으로 추가하게 되고 결국 불필요한 '항상 허용' 옵션이 표시된다.
• Target SDK를 Q(10)으로 올리게 될 경우, ACCESS_BACKGROUND_LOCATION 권한을 완전히 제외할 수 있다.

2️⃣ 앱이 포그라운드 서비스를 통해 빈번하게 사용자 위치 정보를 확인하는 경우

• 네비게이션 서비스가 대표적이다. (앱이 포커스를 갖고 있지 않더라도 지속적으로 위치를 확인해야 하는 경우)
• 이런 경우엔 포그라운드 서비스를 이용하여 백그라운드 실행 및 위치 제한을 피할 수 있다. 근데 이런 경우도 이런저런 이유로 포그라운드 서비스 남용을 막기 위해 'location'이 포함된 경우 포그라운드 서비스를 통해 기기 위치 정보를 확인할 수 있다.
• ACCESS_BACKGROUND_LOCATION 권한을 요청할 필요가 없고, 사용자가 '앱 사용 중에만 허용' 옵션을 선택한 경우에도 앱이 정상적으로 동작한다.

3️⃣ 앱이 백그라운드에서 위치 정보를 확인하는 경우

• 위치 기반으로 사용자 위치를 알아내서 광고를 하는 경우!
• 사용자가 '앱 사용중에만 허용' 옵션을 선택한 경우, 사용자가 앱을 끈 경우 위치 정보를 확인할 수 없다.... 이런 경우 ACCESS_BACKGROUND_LOCATION 권한을 요청해야 한다. 기기 위치 권한은 있지만 백그라운드 위치 권한이 없는 경우를 처리하는 별도 로직을 구현하고 권한이 필요한 이유를 잘 설명하는 UX가 필요하다!

정리

• 내가 만든 어플의 타겟이 Android 10 (API 29) 이상을 타겟한다. 근데 백그라운드 위치 정보 엑세스는 필요하지 않다?

  • ACCESS_BACKGROUND_LOCATION 권한을 MANIFEST에서 삭제!

• 내가 만든 어플의 타겟이 Android 10 (API 29) 이상을 타겟한다. 그리고 백그라운드 위치 정보를 필요로 한다!

  • 사용자에게 왜 필요한지를 알려주고 별도 로직을 구현하여 요청해야 한다.

백그라운드 정책 관련하여 더 궁금하다면 공식 문서를 살펴보자. (개인적으로는 백그라운드 위치 접근에 대해 아주 많이 제한,제약을 두려고 하는 것 같다)~~

위치 권한 여부 코드

int permissionCheck = ContextCompat.checkSelfPermission(this, Manifest.permission.ACCESS_FINE_LOCATION);

if(permissionCheck == PackageManager.PERMISSION_DENIED){ //포그라운드 위치 권한 확인

    //위치 권한 요청
    ActivityCompat.requestPermissions(this, new String[]{Manifest.permission.ACCESS_FINE_LOCATION}, 0);
}


int permissionCheck2 = ContextCompat.checkSelfPermission(this, Manifest.permission.ACCESS_BACKGROUND_LOCATION);

if(permissionCheck == PackageManager.PERMISSION_DENIED){ //백그라운드 위치 권한 확인    
    //위치 권한 요청
    ActivityCompat.requestPermissions(this, new String[]{Manifest.permission.ACCESS_BACKGROUND_LOCATION}, 0);
}

Android 11 (30)

Android11에서는 사용자가 선택할 수 있는 위치 권한 옵션이 더 세분화 되었다. 😂

앞서 살펴보았듯 Android 10에서는 [항상 허용, 앱 사용중만 허용, 거부] 이렇게 3가지가 있었다. Android 11에서는 [항상 허용, 앱 사용중만 허용, 이번만 허용, 거부] 이렇게 4가지로 나누어지게 되었다.

이번만 허용???

• 말 그대로 일회성 권한이다.
• 오랜 시간 사용 안한 앱은 권한이 자동 재설정된다. 권한을 필요로 하는 백그라운드에서 주로 돌아가는 앱은 자동 재설정 되는 것을 막게 사용자에게 요청 필요.
• 사용자 개인 정보 보호 강화를 위해 추가된 방식!
• 사용자가 일회성 위치 엑세스 권한을 추가하고 사용자가 백그라운드 위치 엑세스 권한을 부여하는 방식.

Android 11에서의 위치 권한 요청 화면이다.

항상 허용은 어디 갔나요?

• Android 11에서는 즉시 '항상 허용' 옵션은 사용할 수 없다.
• 대신 위에서 볼 수 있듯, 설정에서 액세스를 허용하세요.를 눌러서 설정 창에 가서 직접 허용 해야 '항상 허용'이 가능하다!
• 이것 역시 사용자에게 더 많은 선택 권한을 준 것으로 볼 수 있다.

면접을 떠나서 안드로이드 개발자는 안드로이드 어플 개발을 하면서 RecyclerView를 정말 많이 만들어보고 다양한 adpater를 사용해본다.

수 많은 리스트의 데이터의 내용 중 변화가 생기게 된다면 우린 notifyDataChanged()를 통해 변화를 알려주게 된다. 그러나 notifyDataChanged()를 사용하면 새로운 item 인스턴스를 생성하기위해 비용이 많이 든다.

'RecyclerView 성능 개선' 이라고 검색만 해도 수많은 블로그 글들에서 notifyDataChaged()를 사용하지 말고 변경되는 특정 데이터에만 변경을 알려주자! 라고 한다.

*🖐 그럼 변경이 단 한개가 아니고 100만개의 리스트 데이터중 7만개가 변경되었고 위치는 그때 그때 다르다고 하자. *

우리가 7만개를 다 계산해서 notifyItemChanged()를 날려줄까? 여러 개니까 notifyItemRangeChanged(positionStart, itemCount)를 날려줘? 위치는 다 다른데?

저러한 연산들이 무조건 비효율적이란게 아니다! 상황에 따라 더 나을 수도 있지만 주로 DiffUtil의 성능이 좋다. (그 이유는 앞으로 설명하겠지만)

그럼 알아보자.

DiffUtil

두 목록의 차이를 계산하고 old item에서 new item으로 목록이 변환 할 때 업데이트 되는 작업 목록을 출력하는 유틸리티 클래스

• RecycerView에 새로운 리스트가 들어올 경우, 해당 리스트를 탐지하고 자동으로 변경해주는 역할을한다.
• Eugene W.Myers의 difference 알고리즘을 사용한다.
• 목록 변환을 위한 최소의 업데이트 수를 계산.
• O(N + D^2)의 시간 복잡도를 갖는다. N:추가/제거 된 항목 수, D : 스크립트 길이

그래서 이점은?

• 변한 아이템을 탐지하고, 내부적으로 알아서 notify해주기에 아이템 변경에 대해 고려를 덜 할 수 있다.

더 나아가서 표현하자면

💡 DiffUtil을 사용하여 데이터 갱신을 위임하자.

Let's use it.

class SubjectDiffUtilCallback(
    private val oldTiles: List<Subject>,
    private val newTiles: List<Subject>
) : DiffUtil.Callback() {

    override fun areItemsTheSame(oldItemPosition: Int, newItemPosition: Int): Boolean {
        return oldSubjects[oldItemPosition] == newSubjects[newItemPosition]
    }

    override fun getOldListSize(): Int {
        return oldSubjects.size
    }

    override fun getNewListSize(): Int {
        return newSubjects.size
    }

    override fun areContentsTheSame(oldItemPosition: Int, newItemPosition: Int): Boolean {
        return oldSubjects[oldItemPosition].number == newSubjects[newItemPosition].number
    }
}

예제는 DiffUtil.Callback에서 주로 쓰이는 4개의 메서드를 구현해놓았습니다.

DiffUtil 클래스 사용을 위해서 바뀌기 전 리스트와 바뀐 후 리스트 2가지를 모두 알고 있어야 한다.

원래 DiffUtil.Callback은 4개의 추상 메서드와 1개의 비추상 메서드로 구성되어있다.

4가지 추상 메서드

• areItemsTheSame(oldPosition:Int, newPosition:Int) : 두 객체가 동일한 항목을 나타내는지 확인
• getOldListSize() : 바뀌기 전 리스트의 크기를 리턴한다.
• getNewListSize() : 바뀐 후 리스트의 크기를 리턴한다.
• areContentsTheSame(oldPosition:Int, newPosition:Int) : 두 항목의 데이터가 같은지 확인한다. 해당 메서드는 areItemsTheSame()에서 true 판별이 난 항목에 대해서만 검사를 수행한다.

1가지 비 추상 메서드

• getChangePayload(oldPosition:Int, newPosition:Int) : areItemsTheSame == true && areContentsTheSame==false일 경우에 호출된다.

🔌 동작방식을 생각해보자.

1. 우리가 DiffUtil.Callback()을 반환하는 커스텀 클래스를 생성해줘야한다. 위의 예시에서 SubjectDiffUtilCallback처럼!! 그리고 반드시 areItemsTheSame()과 areContentsTheSame()를 포함한 4가지 추상메서드를 구현을 해줘야한다. 그래야 비교가 가능하다.

2. 해당 부분을 adapter내에서 데이터를 setting하는 부분에 넣어준다.

   private fun calDiff(newTiles: MutableList<Tile>) {
        val subjectDiffUtilCallback = SubjectDiffUtilCallback(dataSet, newTiles)
        val diffResult: DiffUtil.DiffResult = DiffUtil.calculateDiff(tileDiffUtilCallback)
        diffResult.dispatchUpdatesTo(this)
    }

   이런식이라고 생각해보자. subjectDiffUtilCallback으로 콜백 결과를 받고 이를 DiffUtil.calculateDiff로 넣어서 다시 결과를 받고 이를 업데이트 요청하게 된다. 이는 adapter내에 정의된 메서드이며 adapter에게 변경을 알린다.

💢 조심할 점

• 목록이 많으면 작업이 상당히 오래 걸릴 수 있기에 백그라운드 스레드에서 실행을 설정하고 DiffUtil.DiffResult를 가져와서 메인스레드에서 RecyclerView에 적용하는게 좋다.
• 구현 제약으로 목록의 최대 크기는 2²⁶개로 제한 되어 있다고 한다.

Ref

• https://onemask514.tistory.com/48
• https://gamjatwigim.tistory.com/120#recentComments
• https://sohee1702.tistory.com/409

왜 알아야 해?

디자이너와 협업을 해야하니까. 여러 화면에 대응해야 하니까

🧐 다양한 디바이스 크기에 대응? 그게 뭔데?

dp는 픽셀 독립 단위이다. (Device Independent Pixel)이라고도 하는데 말 그대로 _픽셀에 독립된 디바이스 라는 말로 다양한 안드로이드폰의 해상도를 지원하기 위해 나온 단위이다. 귀여운 안드로이드를 기준으로 설명을 해보겠다. 화면이 작은 단말기도 존재하지만 큰 단말기도 너무 많다. 워낙 파편화가 심하다 보니 다양한 크기에 대응을 해야하고 그 기준도 어느정도 나눠져있다. 위의 그림에서 보듯이 작은 화면과 큰 화면 모두에서 동일하게 안드로이드 아이콘을 볼 수 있게 만들 수 있다.

아래의 두 그림을 보면 왜 사용해야 하는지 명확히 이해 될 것이다.

Low, Medium, High-Density 화면에 픽셀 단위로 크기를 지정한 경우

Low, Medium, High-Density 화면에 DP 단위로 크기를 지정한 경우

긴 말 필요없이 dp는 화면 별 대응이 가능하다. 더 자세하게 다양한 치수들을 알아보자.

dpi (Dots Per Inch)

1인치 당 픽셀 수. 물리적인 단위인 1 inch(2.54cm)에 몇 픽셀이 들어가는가에 대한 단위

Low density (120dpi) : ldpi Medium density (160dpi) : mdpi (기본) High density (240dpi) : hdpi Extra High density (320dpi) : xdpi xxhdpi : 480dpi xxxhdpi : 640dpi

디자이너와 협업을 하다보면 디자이너가 휴대폰을 mdpi에 맞춰 작업한다고 하신다. 😅 아 그럼 160dpi 라고 알아들어야겠지?

px (pixel)

스크린의 실제 픽셀 단위, 실제 크기나 밀도와 관련없다. 절대적 표시 단위이다.

mdpi(기본값) = 160dpi이다. 여기서 공식을 하나 알고 가면 좋다.

개발을 하다보면 dp를 px로 혹은 px을 dp로 바꾸는 경우가 있다.

공식을 알고있다면 매우 편하다. dp = px * 단말 dpi / 기본 160 px = dp * 기본 160 / 단말 dpi 이다.

이게 뭔소리냐고?

mdpi가 기본 값이라고 dpi 설명에서 보았다. (mdpi=160dpi) 즉, 기본값을 기본값으로 나누면 1dp = 1px인 것이다.

그럼 hdpi인 경우엔? hdpi는 240dpi였고 공식에 대입을 해보자. px = dp * 160/240으로 나온다. px = dp * 2/3 👉 1dp = 1.5px 즉, hdpi를 1dp로 볼 때 1.5px이 된다.

이런 식으로 화면의 밀도에 따라 정해진 px값을 요리조리 바꿔가며 사용자에게 보여주게 된다.

ldpi : 1dp = 0.75px mdpi : 1dp = 1px hdpi : 1dp = 1.5px xdpi : 1dp = 2px

이렇게 정리할 수 있다.

dp (dip : Density Independent Pixel)

픽셀에 독립적인 단위로 안드로이드의 다양한 해상도를 지원하기 위해 만든 다위이다.

• dip와 비슷해 보이지만 전혀 다른 아이다.

sp

• sp와 비슷해보이지만 사용자가 선택한 글꼴 크기에 의해 크기가 조절된다.

Layout 등 UI적인 요소는 dp단위를 사용하는 것이 좋고 글자 크기에는 sp를 사용하는 것이 좋다.

해상도별 레이아웃 대응 고찰 위 글을 참고하여 해상도별 레이아웃에 대한 정리를 해보고자 한다. 각자의 방법이 있겠지만 위 글의 방법이 좋다고 나는 생각한다.

🖐 레이아웃 세분화

• 각 기기에 대한 레이아웃 파일을 세분화하여 관리하는 방법

물론 정말 기기마다 레이아웃을 만들어야 한다면 이만큼 비효율적일 수도... 사이즈도 엄청 커지고 관리도 힘들것이다. 그래서 안드로이드에서 크기, 해상도, 방향 등으로 일반화하여 대응이 가능하도록 지원하고 있다.

위에서 살펴본 DPI를 떠올려보자.

Dots Per Inch = 1인치 당 들어가있는 픽셀의 개수 기억나는가?

기기의 dpi가 기준 되는 dpi와 정확하게 맞아야 하는건 아니다. 기기의 dpi와 가장 비슷한 레이아웃으로 자동으로 찾아간다. 이때 고밀도에서 저밀도 순으로 우선순위가 정해진다.

레이아웃 세분화의 장단점

장점

• 여러 기기 대응이 가능하다.
• 여러 기기에서 같은 비율의 이미지들과 글자를 사용하여 같은 화면처럼 표시가 가능하다.

단점

• 관리가 힘들다.. 유지보수/추가로 인해 레이아웃이 바뀐다면? 🤮

🧐 그럼 결국 어떻게 해상도별 레이아웃 대응을 할까?

dimens.xml을 이용하는 방법 레이아웃은 하나로 통일시키고 dimes.xml을 세분화하여 사용하는 방법

 <ImageView

        android:layout_width="@dimen/imageWidth"

        android:layout_height="@dimen/imageHeight"

        android:background="@color/colorAccent" />

dimens.xml (mdpi)

    <?xml version="1.0" encoding="utf-8"?>

    <resources>

        <dimen name="imageWidth">40dp</dimen>
        <dimen name="imageHeight">20dp</dimen>
        <dimen name="textSize">12dp</dimen>
        <dimen name="topMargin">5dp</dimen>

   </resources>

dimens를 mdpi, hdpi, xhdpi, xxhdpi 별로 나눠두면 된다.

세그멘테이션

• 프로세스를 논리적 내용일 기반으로 나눠 메모리에 배치하는 것을 말한다.
• 세그먼트의 집합으로, 각 세그먼트의 크기는 일반적으로 같지 않다.
• 프로세스를 code, data, stack으로 나누는 것 역시 세그멘테이션의 모습이다. 물론 code, data, stack 각각 내부에서 더 작은 세그먼트로 나눌 수도 있다.

세그먼트를 메모리에 할당할 때는 페이지를 할당하는 것과 동일하다.

하지만 테이블은 조금 다른데, 세그멘테이션을 위한 테이블은 세그먼트 테이블이라고 한다. 그리고 세그먼트 테이블은 세그먼트 번호와 시작 주소, 세그먼트 크기를 엔트리로 갖는다.

세그먼트에서 주소 변환 역시, 페이징과 유사하다. ✋ 한 가지 주의점은, 세그먼트의 크기는 일정하지 않기에 테이블에 limit정보가 주어진다. CPU에서 해당 세그먼트의 크기를 넘어서는 주소가 들어오면 인터럽트가 발생해서 해당 프로세스를 강제 종료시킨다.

위 그림은 세그먼트 테이블과 프로세스가 할당된 메모리의 모습이다. 페이징 주소변환과 동일하게 d는 논리주소와 물리주소가 동일하다. 물리주소 a는 base[s] + d로 계산된다.

• 논리주소 (2,100) -> 물리주소 4400번지 (4300+100)
• 논리주소 (1,500) -> 인터럽트로 인해 프로세스 강제 종료(범위 벗어남)

세그멘테이션에서의 보호/공유

페이징보다 세그멘테이션에서의 보호와 공유는 더 효율적이다. 보호에서는 세그멘테이션 역시 r,w,x 비트를 테이블에 추가하여, 세그멘테이션은 논리적으로 나누기에 해당 비트를 설정하기 매우 간단하고 안전하다.

페이징은 code+data,stack 영역이 있을 때 이를 일정한 크기로 나누므로 2가지 영역이 섞일 수가 있다. 그러면 비트 설정이 매우 까다로워진다.

공유에서도 마찬가지다. 페이징에서는 code 영역을 나눈다해도 다른 영역이 포함될 확률이 매우 높다. 하지만, 세그멘테이션은 정확히 code 영역만 나누기에 더 효율적으로 공유를 수행할 수 있다.

세그멘테이션 & 페이징

세그멘테이션은 페이징과 유사하고 보호와 공유에서는 더 나은 성능을 보여주지만, 현재 대부분은 페이징 기법을 사용한다.

그 이유는 세그멘테이션의 치명적 단점에 있다.

메모리 할당을 처음 시작할 때 다중 프로그래밍에서의 문제는 크기가 서로 다른 프로세스로 인해 여러 크기의 hole이 발생한다. 이로 인해, 어느 hole에 프로세스를 할당하는 것에 대한 최적화 알고리즘이 존재하지 않고, 외부 단편화로 인해 메모리 낭비가 크다고 했었다.

세그멘테이션도 동일한 문제점이 발생한다. 왜냐? 세그멘테이션은 논리적인 단위로 나누기에 세그먼트의 크기가 다양하다. 이로 인해 다양한 크기의 hole이 발생하므로 같은 문제가 발생한다.

결론적으로 세그멘테이션은 보호/공유에서 효율적이고, 페이징은 외부 단편화 문제를 해결 할 수 있다. 그래서 2가지를 같이 사용하는 방법이 나왔고 두 장점을 합치기 위해 세그먼트를 페이징 기법으로 나누는 것이다. (Paged Segmentation)

이 역시 단점은 있다. 세그먼트와 페이지가 동시에 존재할 수 있기에 주소 변환도 2번 해야 한다. 즉, CPU에서 세그먼트 테이블에서 주소 변환을 하고, 그 다음 페이지 테이블에서 또 주소 변환을 해야 한다..

외부 단편화로 인한 메모리 낭비가 심하다. Compaction을 사용하면 외부 단편화를 해결 할 수 있지만 오히려 이로인해 발생하는 오버헤드, 비효율적인 성능으로 사용하기 어렵다. 그래서 나온게 페이징이다. hole을 가지고 해결하려 하지 않고 프로세스를 작은 단위로 나눠서 외부 단편화를 해결하려 한다.

페이징

• 프로세스를 일정한 작은 크기로 나누고, hole 역시 같은 크기로 나눈다.
• 이러한 작은 조각들의 크기에 맞춰 메모리에 할당한다.

🧐 하지만, 하나의 프로세스는 연속적인 동작을 수행하는데 이를 작은 여러 조각으로 나누면 프로세스가 정상적으로 동작할까?

다중 프로그래밍에서 살펴봤던 개념처럼 MMU를 통해 논리 주소와 물리주소를 나눠 사용하고 이를 MMU가 재배치 해주는 작업을 해준다고 하였다. 이 역시 CPU를 속이는 행동이다. 실제로 메모리는 전혀 연속적이지 않은데, CPU는 연속적으로 사용하고 있다는 것을 보장받으며 수행한다.

50byte크기의 프로세스가 있다고 하자. 페이징의 크기는 각 10byte로 나눈다.

위 그림과 같이 P1은 5개의 페이지로 나눌 수 있다. 이를 메인 메모리 5곳에 나눠 할당한다. CPU는 논리 주소로 프로그램이 설정한대로 연속적인 주소값으로 명령을 내리고 이는 메모리로 가기전에 각 페이지의 실제 메모리 주소가 저장되어 있는 테이블에서 물리주소로 변경되어야 한다.

프로세스를 나눈 조각을 page라고 하고, 메모리를 나눈 조각을 frame이라고 한다. 프로세스는 페이지의 집합이고, 메모리는 프레임의 집합이다.

프로세스를 정상적으로 사용하기 위해 MMU의 재배치 레지스터를 여러 개 사용하여 위의 그림처럼 각 페이지의 실제 주소로 변경해준다.

이러한 여러 개의 재배치 레지스터를 페이지 테이블이라 한다.

주소 변환

• 페이징 기법을 사용하기 위해 여러 개로 흩어진 페이지에 CPU가 접근하기 위해서 페이지 테이블을 통해 주소를 변환해야 한다.

논리 주소

CPU가 내는 주소는 2진수로 표현되고 이를 m비트가 있다고 가정하자. 여기서 하위 n비트는 오프셋 또는 변위라고 한다. 그리고 상위 m-n 비트는 페이지의 번호에 해당한다. (n = d, m-n = p) 이렇게만 보면 이해가 안되니 예제로 보자.

페이지 번호(p)는 페이지 테이블의 인덱스 값. p에 해당하는 테이블 내용은 메모리의 프레임 번호!

• Page Size = 16bytes
• Page Table : 5, 3, 2, 8 , 1, 4
• 논리 주소 50번지는 물리 주소 몇 번지 인가?

위 그림은 프로세스 P가 메모리에 할당된 모습이다. CPU가 50번지에 접근하려 한다. 그러면 페이지 테이블의 정보를 읽어오기 위해 논리주소를 p,d로 나눠야 한다.

d는 페이지 크기에 따라 달라지는 데, Page Size가 16byte이니까 2^4이다. 그래서 d = 4가 되므로 이진수의 뒤에서 4칸이 d이다.

50 = 110010
p = 11
d = 0010

P는 이진수로 11이고 십진수로 3이다. 즉, 페이지 테이블의 페이지 번호 3을 가리킨다. 페이지 3번에 해당하는 프레임번호는 8이므로 물리주소를 구성하는 f값은 8이 된다.

f = 1000
d = 0010
물리주소 = 10000010

최종적으로 물리주소는 f,d로 구성되어 있으므로 물리주소는 이진수로 10000010이 되고, 십진수로는 130번지가 된다. 즉, 변위는 2이므로 8번재 프레임의 시작주소는 128번지가 된다.

연속 메모리 할당을 하면서 외부 단편화가 발생하여 이를 해결하기 위해 페이징이 나왔다. 하지만 페이징은 외부 단편화가 아닌 내부 단편화가 발생한다.

내부단편화

• 프로세스 크기가 페이지 크기의 배수가 아닐 경우, 마지막 페이지는 한 프레임을 다 채울 수 없다.
• 이로 인한 공간 발생은 메모리 낭비로 이어진다.

예를 들어, 15byte 크기의 프로세스 P가 있다. 페이지 크기(프레임 크기)는 4byte로 P를 페이지로 나누면 4,4,4,3의 크기로 총 4개의 페이지가 만들어진다. 여기서 마지막 3byte 페이지는 프레임 크기보다 1byte 작으므로, 이 만큼 메모리 공간이 비게 된다. 이렇게 비어진 공간은 프로세스 P에서도 쓰지 않고, 다른 프로세스에서도 쓰지 못하는 낭비되는 공간이 된다.

내부단편화는 해결 방법이 없다. 😹 하지만 내부단편화는 외부단편화에 비해 낭비되는 메모리 공간은 매우 적다. 내부 단편화의 최대 낭비되는 크기는 page size - 1이 된다. (외부 단편화는 최대 전체 메모리의 1/3이 낭비된다고 이전에 살펴봤다) 이는 무시할 정도로 작은 크기다.

페이지 테이블 만들기

• CPU 내부에 페이지 테이블을 만들 수 있다. CPU 내부의 기억장치는 레지스터로 여러개의 레지스터로 페이지 테이블을 만드는 것. CPU 내부에 페이지 테이블을 만들면, 장점은 주소 변환 속도가 빠르다. 하지만 단점은 CPU 내부에 사용할 수 있는 레지스터는 한정되어 있어 페이지 테이블의 크기가 매우 제한된다.

• 페이지 테이블을 메모리 내부에 만들 수도 있다. 메모리 내부에 만드는 것의 장단점은 CPU와 정반대이다. 즉, 장점은 페이지 테이블의 크기 제한이 없는 것이고 단점은 주소 변환 속도가 느리다는 것이다. CPU는 프로세스의 주소에 접근하기 위해 메모리에 위치한 페이지 테이블에 한 번, 실제 주소로 접근하는데 한 번해서 메모리에 총 2번 접근해야 하므로 속도가 2배 느려진다.

이 모든 것을 해결하기 위해 페이지 테이블도 캐시로 만들어 해결한다. 페이지 테이블을 별도의 칩(SRAM)으로 만들어서 CPU와 메모리 사이에 위치시킨다. 이러한 테이블을 TLB(Translation Lock-aside Buffer) 라고 부른다.

👍 CPU보다 변환 속도가 느리고 메모리보다 테이블 크기는 작지만, CPU보다 테이블 크기가 크고 메모리 보다 변환 속도가 빠르다.

TLB는 캐시와 역할이 동일하므로, 실제 전체 페이지 테이블은 메모리에 위치해 있고 테이블의 일부를 TLB에 가져와서 사용한다. TLB에 유효한 페이지가 있을 때와 없을 때의 속도차이가 발생한다.

TLB 효율을 알아보기 위해 Effective Memory Access Time을 계산해보자.

• 메모리를 읽는 시간(Tm) = 100ns
• TLB를 읽는 시간(Tb) = 20ns
• TLB에 유효한 페이지 엔트리가 있을 확률(hit ratio) = 80%

먼저, EMAT의 정형화된 식을 보자.

EMAT = h(Tb + Tm) + (1-h)(Tb + Tm + Tm), h는 hit ratio

예제를 계산해보면 140ns가 나온다. hit ratio는 실제로 평균 95%이상이므로 충분히 효율적으로 동작한다고 볼 수 있다.

실제 유효한 메모리에 접근하는 시간은 위와 같다. TLB에 유효한 페이지가 있다면 TLB를 읽는 시간과 실제 메모리를 읽는 시간만 있으면 된다. 하지만, TLB에 유효한 페이지가 없다면 이를 다시 메모리에서 가져와야 하므로 메모리를 총 2번 읽어야 한다.

Ref

• KOCW 운영체제 강의

가장 단순하게는 2중 반복문을 돌리는 것이다.

public class Main{
    public static void main(String[] args){
        int[] arr = {1,2,3,4,2,5,2,3,1,1,2};
        int m = 5;

        for(int i=0; i<arr.length; i++){
            int sum = arr[i];

            for(int j=i+1; j<10; j++){
                if(sum==m){
                    count++;
                }else if(sum>m){
                    break;
                }else{
                    sum+=arr[j];
                }
            }
        }
    }
}

아주 쉽게 볼수 있는 형태이다. 근데 이렇게 하면 시간복잡도가 O(N^2)이 나온다. (2중 반복문이니까) 배열의 크기가 커질 수록 느려지게 된다.

결국, 1차원 배열의 연속된 구간에 대해 2중 반복문을 개선하기 위해 나온 것이 투 포인터 알고리즘이다.

투 포인터 알고리즘

위와 같은 그림이 있다.

위의 1차원 배열에서 연속된 구간의 합이 5인 것의 경우의 수를 구해보자.

위의 2중 반복문과 큰 차이는 없지만, Right를 우측으로 하나씩 옮겨가면서 arr[left] + ... + arr[right]의 값이 5보다 크다면 더 이상 right를 옮기는 것은 무의미하다. right를 우측으로 옮겨봤자 마찬가지로 5보다 크기에. 그래서 이런 경우 left를 우측으로 옮긴다.

let's code it.

public class Main{
    public static void main(String[] args){
        int[] arr = {1, 2, 3, 4, 2, 5, 3, 1, 1, 2};
        int m = 5;

        int count = twoPointer(arr, m);
    }

    public static int twoPointer(int[] arr, int m){
        int sum =0, count =0;
        int left=0, right=0;

        while(true){
            if(sum>m){
                sum -= arr[left++]; //left를 우측으로 옮기는 경우, left를 움직이면서 이전 위치에 있던 값을 합에서 빼줌.
            }else if(right==arr.length-1){
                break;
            }else{
                sum += arr[right++]; //right를 우측으로 옮기는 경우
            }

            if(sum == m) count++;
        }

        return count;
    }
}

let's solve it.

완전 간단한 예제 문제를 풀어보자.

• https://www.acmicpc.net/problem/2018

package twoPointer;

import java.util.*;
public class boj_2018 {

    public static void main(String[] args){
        Scanner sc = new Scanner(System.in);
        int n = sc.nextInt();
        int[] arr = new int[n];
        for(int i=1; i<=n; i++) arr[i-1] = i;

        System.out.println(twoPointers(arr, n));
    }

    public static int twoPointers(int[] arr, int n){
        int sum=0, count=1;
        int left=0, right=0;

        while(true){
            if(sum>n){
                sum -= arr[left++];
            }else if(right == arr.length-1){
                break;
            }else{
                sum += arr[right++];
            }

            if(sum==n) count++;
        }

        return count;
    }

}

Stack 2개를 이용한 문제 풀이! (데이터 타입을 잘 보자..)

문제 설명

IT 벤처 회사를 운영하고 있는 라이언은 매년 사내 해커톤 대회를 개최하여 우승자에게 상금을 지급하고 있습니다. 이번 대회에서는 우승자에게 지급되는 상금을 이전 대회와는 다르게 다음과 같은 방식으로 결정하려고 합니다. 해커톤 대회에 참가하는 모든 참가자들에게는 숫자들과 3가지의 연산문자(+, -, ) 만으로 이루어진 연산 수식이 전달되며, 참가자의 미션은 전달받은 수식에 포함된 연산자의 우선순위를 자유롭게 재정의하여 만들 수 있는 가장 큰 숫자를 제출하는 것입니다. 단, 연산자의 우선순위를 새로 정의할 때, 같은 순위의 연산자는 없어야 합니다. 즉, + > - > * 또는 - > * > + 등과 같이 연산자 우선순위를 정의할 수 있으나 +, > - 또는 * > +,-처럼 2개 이상의 연산자가 동일한 순위를 가지도록 연산자 우선순위를 정의할 수는 없습니다. 수식에 포함된 연산자가 2개라면 정의할 수 있는 연산자 우선순위 조합은 2! = 2가지이며, 연산자가 3개라면 3! = 6가지 조합이 가능합니다. 만약 계산된 결과가 음수라면 해당 숫자의 절댓값으로 변환하여 제출하며 제출한 숫자가 가장 큰 참가자를 우승자로 선정하며, 우승자가 제출한 숫자를 우승상금으로 지급하게 됩니다.

예를 들어, 참가자 중 네오가 아래와 같은 수식을 전달받았다고 가정합니다.

"100-200*300-500+20"

일반적으로 수학 및 전산학에서 약속된 연산자 우선순위에 따르면 더하기와 빼기는 서로 동등하며 곱하기는 더하기, 빼기에 비해 우선순위가 높아 * > +,- 로 우선순위가 정의되어 있습니다. 대회 규칙에 따라 + > - > * 또는 - > * > + 등과 같이 연산자 우선순위를 정의할 수 있으나 +,* > - 또는 * > +,- 처럼 2개 이상의 연산자가 동일한 순위를 가지도록 연산자 우선순위를 정의할 수는 없습니다. 수식에 연산자가 3개 주어졌으므로 가능한 연산자 우선순위 조합은 3! = 6가지이며, 그 중 + > - > * 로 연산자 우선순위를 정한다면 결괏값은 22,000원이 됩니다. 반면에 * > + > - 로 연산자 우선순위를 정한다면 수식의 결괏값은 -60,420 이지만, 규칙에 따라 우승 시 상금은 절댓값인 60,420원이 됩니다.

참가자에게 주어진 연산 수식이 담긴 문자열 expression이 매개변수로 주어질 때, 우승 시 받을 수 있는 가장 큰 상금 금액을 return 하도록 solution 함수를 완성해주세요.

[제한사항]

expression은 길이가 3 이상 100 이하인 문자열입니다. expression은 공백문자, 괄호문자 없이 오로지 숫자와 3가지의 연산자(+, -, ) 만으로 이루어진 올바른 중위표기법(연산의 두 대상 사이에 연산기호를 사용하는 방식)으로 표현된 연산식입니다. 잘못된 연산식은 입력으로 주어지지 않습니다. 즉, "402+-561"처럼 잘못된 수식은 올바른 중위표기법이 아니므로 주어지지 않습니다. expression의 피연산자(operand)는 0 이상 999 이하의 숫자입니다. 즉, "100-2145*458+12"처럼 999를 초과하는 피연산자가 포함된 수식은 입력으로 주어지지 않습니다. "-56+100"처럼 피연산자가 음수인 수식도 입력으로 주어지지 않습니다. expression은 적어도 1개 이상의 연산자를 포함하고 있습니다. 연산자 우선순위를 어떻게 적용하더라도, expression의 중간 계산값과 최종 결괏값은 절댓값이 263 - 1 이하가 되도록 입력이 주어집니다. 같은 연산자끼리는 앞에 있는 것의 우선순위가 더 높습니다.

입출력 예

expression "100-200*300-500+20"
result 60420

expression "506-32"
result 300

입출력 예에 대한 설명

입출력 예 #1

* > + > -로 연산자 우선순위를 정했을 때, 가장 큰 절댓값을 얻을 수 있습니다. 연산 순서는 아래와 같습니다. 100-200300-500+20 = 100-(200300)-500+20 = 100-60000-(500+20) = (100-60000)-520 = (-59900-520) = -60420 따라서, 우승 시 받을 수 있는 상금은 |-60420| = 60420 입니다.

입출력 예 #2

- > *로 연산자 우선순위를 정했을 때, 가장 큰 절댓값을 얻을 수 있습니다. 연산 순서는 아래와 같습니다.(expression에서 + 연산자는 나타나지 않았으므로, 고려할 필요가 없습니다.) 506-3*2 = 50(6-3)2 = (503)2 = 1502 = 300 따라서, 우승 시 받을 수 있는 상금은 300 입니다.

접근 방식

순차적으로 접근했다.

1. 연산자들의 순열을 구해야 한다.
2. 구한 순열에 따라 연산자 우선순위를 적용하여 답을 구해야한다. 처음에는 ArrayList로 하려고 했는데 값을 넣고 삭제하고 리스트 길이 고려하는 게 복잡하다는 걸 알아서 캐시 형태로 스택을 만들어서 구현하자! 했다.

정리해보면, ✅ 숫자와 문자를 나눠 배열에 저장. ✅ 거꾸로 cacheStack에 삽입! ✅ cacheStack에서 하나씩 pop()하면서 연산자 우선순위에 따라 연산자를 판별하고 맞다면 resultStack에 넣은 숫자를 pop()해서 cacheStack에서 연산자 다음의 숫자를 또 pop()해서 둘을 연산하고 resultStack()으로 보낸다! ✅ 위 과정을 하고나서 다시 다른 연산자를 계산해야 하기에 resultStack을 pop()해서 cacheStack()에 다시 넣어준다! ✅ 이 과정을 연산자 우선순위에 따라 쭉~ 하면 마지막에 cacheStack에만 값이 하나 남는다. ✅ 하나 남는 값을 여러 값들과 Math.max로 비교하여 정답을 반환한다.

핵심은 스택 2개를 왔다갔다 하면서 연산자가 있으면 pop()을 통해 값을 계산하고 넣고 빼고 하는 방식이다!

주의할 점!

나는 처음에 구현하고 채점하니까 70.0/100.0이 나왔다... 뭐지? 싶어서 한~~참 고민해보니까

연산자 우선순위를 어떻게 적용하더라도, expression의 중간 계산값과 최종 결괏값은 절댓값이 2^63 - 1 이하가 되도록 입력이 주어집니다.

위와 같은 제한 사항이 있었다. 그래 나의 계산 과정은 모두 int였고 결과만 long으로 반환하려는 놀부심보였다... 코드 내 계산 과정에 있는 int를 모두 long으로 교체 한 후, 통과할 수 있었다.

코드

import java.util.*;
class Solution {
    static String[] num, cal;
    static Stack<String> cacheStack = new Stack<>(); //계산 이전 값들 넣어둘 곳
    static Stack<String> resultStack = new Stack<>();//계산 이후 값들 넣어둘 곳
    static long answer = 0;

    public long solution(String expression) {        
        Set<String> set = new HashSet<>();

        num = expression.replaceAll("[^0-9]"," ").split(" ");
        cal = expression.replaceAll("[0-9]","").split("");        
        for(String c : cal) set.add(c);

        String[] calList = new String[set.size()]; //계산 조합을 위해 필요        
        Iterator it = set.iterator();
        int a=0;
        while(it.hasNext()) calList[a++] = (String)it.next();        

        perm(calList, calList.length, 0);        

        return answer;
    }

    public static void getMoney(String[] calList){
        //초기 설정
        for(int i=cal.length-1; i>=0; i--){
            if(i==cal.length-1) cacheStack.push(num[i+1]);
            cacheStack.push(cal[i]);
            cacheStack.push(num[i]);
        }

        for(int i=0; i<calList.length; i++){
            String cc = calList[i]; 

            while(!cacheStack.isEmpty()){
                String p = cacheStack.pop();

                if(p.equals(cc)){
                    long n1 = Long.parseLong(resultStack.pop());                    
                    long n2 = Long.parseLong(cacheStack.pop());
                    resultStack.push(getCalculate(p, n1, n2));
                }else{
                    resultStack.push(p);
                }

            }            

            while(!resultStack.isEmpty()){
                cacheStack.push(resultStack.pop());
            }            
        }

        while(!cacheStack.isEmpty()){                        
            answer = Math.max(answer, Math.abs(Long.parseLong(cacheStack.pop())));           
        }
    }

    public static void perm(String[] calList, int p, int r){
        if(p==r){
            getMoney(calList);
        }else{
            for(int i=0; i<calList.length; i++){
                swap(calList, i, r);
                perm(calList, p, r+1);
                swap(calList, i, r);
            }
        }
    }

    public static void swap(String[] list, int i, int r){
        String tmp = list[i];
        list[i] = list[r];
        list[r] = tmp;
    }

    public static String getCalculate(String p, long n1, long n2){
        long result = 0;
        if(p.equals("+")){
            result = n1+n2;
        }else if(p.equals("-")){
            result = n1-n2;
        }else{
            result = n1*n2;
        }
        return String.valueOf(result);
    }
}

현재에도 여전히 메모리를 최대한 효율적으로 사용하기 위한 여러 방법들이 연구되고 OS 기능에서 매우 중요한 부분을 차지 한다.

이 글은 KOCW 운영체제 강의를 토대로 작성되는 내용입니다.

1. 메모리에 프로그램 할당하기

메모리는 기본적으로 주소(Address), 데이터(Data)로 구성되어있다.

CPU와 메모리는 양방향으로 위 그림처럼 정보를 주고 받게 된다. CPU는 주소를 가지고 메인 메모리에 요청을 하거나 해당 주소에 계산 결과를 저장하고, 메모리는 요구하는 주소에 저장되어 있는 데이터를 CPU에게 전달한다.

프로그램의 빌드 과정은 소스파일 ➡️ 목적 파일 ➡️ 실행 파일 순이다.

• 소스 파일 : 고수준언어 또는 어셈블리어
• 목적 파일 : 컴파일 또는 어셈블 결과
• 실행 파일 : 링크 결과

위 그림은 프로그램이 만들어지는 과정을 표현한 그림이다.

1. 소스파일은 컴파일러에 의해 컴파일 수행 결과로 목적 파일을 생성한다. 프로그래밍을 하면 외부 라이브러리를 사용하는 경우가 빈번한데, 컴파일 타임에 이를 추가하지 않기에 목적 파일에는 이에 대한 정보는 없다. 2. 링크 단계에서 하드디스크에서 프로그래머가 추가한 라이브러리를 찾아 정보를 추가하여, 실행 파일을 만든다. 이 프로개름을 실행하면 로더(loader)에 의해 메인 메로리에 할당 된다.

그리고 생성된 프로그램은 Code, Data, Stack 영역으로 나뉜다. 단순 생성된 프로그램은 Code, Data 영역만 존재하며, 메모리에 적재되었을 때는 실제로 실행해야 하기에 stack영역이 추가된다.

실제로 프로그램을 메모리에 올리려면 이 프로그램을 메모리의 몇 번지에 할당할까?

만약 OS가 없다면 프로그래머가 이를 직접 해줘야 한다.(고수준언어에서는 직접 주소를 다루지 않는 경우가 많다)

다중 프로그래밍 환경에서는 여러 프로그래밍이 메모리에 적재되고 교체 되는 과정이 있기에 한 프로그램은 고정적인 공간을 차지 할 수 없다. 위의 문제를 해결해주는 것이 바로 MMU이다. MMU에는 프로그램이 메모리에 할당될 때마다 다른 주소 공간을 사용하기에 재배치 레지스터가 별도로 존재한다.

MMU의 존재

위의 그림처럼 MMU가 존재함으로 인해서 프로그램은 메인 메모리에 해당 주소를 사용할 수 있는지 여부를 생각하지 않고 주소를 사용한다.

🙌 해당 프로그램이 사용하는 시작 주소가 0번지라고 할 때, 실제 메인 메모리에서는 할당되는 주소가 유동적이기에 0번지라는 주소를 실제 할당된 주소로 변경해줘야 한다.

이게 재배치 레지스터의 역할이다. 마치 필터링을 해주듯이 맵핑을 해주게 된다.

MMU의 기능에서 보면, 이전에 메모리 보호를 위해 base, limit레지스터가 있었다. CPU에서 주소를 사용하는데 이 주소가 해당 프로그램의 base~limit범위를 벗어나면 인터럽트를 발생시켜 프로그램을 강제 종료 시킨다.

base/limit 기능 이외에도 위에서 말한 reallocation 기능을 통해 프로그램이 어느 주소를 사용하더라도 실제 메인 메모리에서 할당된 주소를 찾아갈 수 있도록 address traslation 동작을 수행한다.

⭐️ 즉, CPU는 프로그램에 설정된 주소를 계속 사용하고 메모리에 명령을 보내지만, MMU에 의해 실제로 프로그램이 할당된 메모리 주소로 변환해서 사용할 수 있는 것이다.

MMU에 의해 위 그림과 같이 주소는 2가지로 구분된다. CPU에서 사용하는 주소는 논리 주소라고 하고 메모리가 사용하는 주소는 물리 주소라고 한다.

2. 메모리 낭비 방지

OS에서 메모리 효율은 매우 중요한 부분이다.

동적 적재(Dynamic Loading)

• 프로그램이 실행하는 데 필요한 루틴/ 데이터만 적재하는 것.

오류처리 구문은 if문과 같이 오류가 발생한 순간에만 실행하면 되기에 미리 메모리에 올려두지 않고 오류가 발생한 순간 내부 코드를 실행시키면 된다.

데이터 역시 모든 데이터가 필요하지 않다. 배열과 클래스의 경우 필요한 부분만 메모리에 적재하고 실행 도중 필요해지면 그때 찾아서 추가적으로 메모리에 적재한다.

그럼 당연히 반대로 모든 루틴과 데이터를 적재하고 실행하는 것을 정적 적재(static loading)이라고 한다.

동적 연결(Dynamic Linking)

동적 연결은 여러 프로그램에 공통으로 사용되는 라이브러리를 중복으로 메모리에 올리지 않고 하나만 올리도록 하는 것이다.

// P1
int a = 1;
int b = 2;
printf("%d\n", a + b);

// P2
int a = 1;
int b = 2;
printf("%d\n", a * b);

위의 코드처럼 p1, p2 프로세스가 있지만 둘을 실행시키면 둘은 모두 printf()를 사용하는 라이브러리를 메모리에 적재하게 된다. 이는 중복 적재이다.

같은 라이브러리를 메모리에 중복으로 적재하면 메모리 낭비가 발생한다.

그렇기에 프로그램이 메모리에 적대된 후에 링크(link)작업을 수행한다. 기존에는 실행 파일이 만들어지기 전에 링크 과정을 수행하였는데, 이를 정적 연결이라고 한다.

공통 라이브러리(printf())를 연결한 모습이다. 리눅스에서는 이러한 라이브러리를 공유 라이브러리 윈도우에서는 동적 연결 라이브러리 라고 한다.

Swapping

• 메모리에 적재되어 있는 프로세스 중 오랫동안 사용하지 않은 프로세스를 프로세스 이미지 형태로 만든 후 하드디스크에 내려보낸다. 메모리에서 Backing Store로 가는 것을 swap-out, 다시 Backing Store에서 메모리로 가는 것을 swap-in이라고 한다.

프로세스 이미지는 해당 프로그램이 메모리에 적재된 후 실행되면서 데이터를 추가하거나 변경하는 등의 과정을 거치는데, 현재 데이터의 상태를 프로세스 이미지라고 부른다.

swapping 과정으로 인한 프로세스 이미지를 저장하기 위해 하드 디스크 일부분을 분리하여 사용하는데 이를 backing store 혹은 swap device라고 부른다.

Backing Store의 크기는 대략 메인 메모리 크기 정도로 예상할 수 있다. 메모리의 모든 프로세스가 쫓겨난다고 해도 메인 메모리 크기를 넘지 않기 때문이다. 메인 메모리 크기가 크지 않는 PC나 스마트폰은 하드디스크의 일부를 backing store로 사용하지만 메모리 크기가 크다면 따로 하드디스크 자체를 backing store로 사용하는 경우도 있다.

Swap-out된 프로세스가 다시 swap-in될때 이전의 메모리 주소가 아닌 새로운 주소로 갈 수 있다. 이는 해당 프로세스가 backing store에 있는 동안 다른 프로세스가 해당 주소공간을 사용할 수 있기 때문이다. 하지만 이는 MMU의 재배치 레지스터로 인해 어디에 적재되어도 상관없이 정상동작이 가능하다.

프로세스의 크기가 커지고, 하드디스크는 메인 메모리보다 속도면에서 매우 느리고 swapping 동작의 오버헤드가 매우크다. 하지만 이로 인해 얻는 이득이 더 많으므로 대부분의 운영체제는 이를 사용하고 있고, 속도가 중요한 서버 컴퓨터나 슈퍼 컴퓨터는 backing store를 하드 디스크가 아닌 좀 더 빠른 저장 자칠르 사용하기도 한다.

연속 메모리 할당

현재는 메모리에 여러 프로세스가 할당되는 다중 프로그래밍 환경이다.

부팅 직후 메모리 상태를 보면, OS만 할당되어 있고 비어 있다. 이러한 비어있는 공간을 hole이라고 부른다.

즉, 부팅 직후 운영체제와 big single hole이 존재한다.

시간이 지나면서 프로세스가 생성되고 종료하고를 반복하면, 여러 곳에 서로 다른 크기의 홀이 존재한다. 이러한 상태를 scattered holes라고 한다.

부팅 직후 여러 프로세스들이 생성, 종료를 반복한 후의 상태이다. 이와 같이 hole들이 불연속하게 흩어진 상태를 메모리 단편화라고 한다.

메모리 단편화로 인해 여러 곳에 Hole이 흩어진 상태에서 하나의 프로세스가 메모리에 할당되려면 문제가 발생할 수 있다.

hole이 3개가 있고 각 크기는 50byte, 50byte, 80byte이다. 근데 할당하려는 프로세스 크기가 150byte이다. 각 홀들을 하나로 합치면 230byte로 이 프로세스를 할당할 수 있지만 실제로는 나뉘어져 있기에 할당되지 못한다.

이러한 현상을 외부 단편화라고 한다.

연속 메모리 할당 방식

외부 단편화의 해결 방법을 살펴보기 전 연속 메모리 할당 방식을 먼저 보자. 연속 메모리 할당 바식에는 3가지가 있다. First-fit, Best-fit, Worst-fit

• First-fit(최초 적합) : 최초 적합은 할당할 프로세스 크기보다 크거나 같은 hole을 탐색하는 순서 중에서 가장 먼저 찾은 hole에 프로세스를 할당하는 것.

• Best-fit(최적 적합) : 최적 적합은 할당할 프로세스 크기와 hole 크기의 차이가 가장 작은 hole에 프로세스를 할당하는 것. (hole크기는 프로세스 크기보다 반드시 커야한다)

• Worst-fit(최악 적합) : 최적 적합과 반대로 할당할 프로세스 크기와 hole크기 차이가 가장 큰 hole에 프로세스를 할당하는 것.

Hole은 100kb, 500kb, 600kb, 300kb, 200kb 총 5개가 있고 프로세스는 P1, P2, P3, P4 총 4개가 있다. 프로세스의 각 크기는 212kb, 417kb, 112kb, 426kb이다.

• First-fit

• Best-fit

• Worst-fit

각 3가지 방식대로 프로세스를 할당하였다.

결과를 보면 best-fit은 4개의 프로세스를 모두 할당할 수 있고 나머지 전략은 마지막 프로세스를 할당하지 못한다. 모든 hole을 합치면 p4를 할당할 수 있지만 hole들은 나눠져 있기에 할당할 수 없다 = 외부 단편화.

각 할당 방식의 일반적인 성능 비교를 보면, 속도면에서는 first-fit이 가장 빠르다. 메모리 이용률면에서는 first-fit, best-fit이 비슷하다.

하지만 여러 실험을 통해 best-fit을 사용하더라도 외부 단편화로 인해 전체 메모리의 1/3정도를 낭비한다고 한다. 거의 사용불가 수준.

Compaction

이를 해결하는 방법 중 하나는 Compaction이다. 여러 곳에 흩어진 hole들을 강제로 하나로 합치는 것이다. 하지만 hole을 옮기는 오버헤드가 너무 크고, 어느 hole을 옮겨야 빠르게 합칠 수 있는지에 대한 최적 알고리즘이 존재하지 않는 큰 단점이 있다.

Ref

• KOCW 운영체제 양희재 교수님 강의

• HW 자원을 각 사용자 어플리케이션에 적절히 분배해주는 것.
• HW 자원은 CPU, Main Memory, 하드디스크, 키보드, 마우스, 프린터 등이 존재한다.
• 이러한 하드웨어 자원을 사용자 어플리케이션이 요구하거나 OS내의 규칙에 의해 적절히 분배하여 컴퓨터의 성능을 최대한 효율적으로 사용해야 한다.

1.프로세스 관리

• 운영체제 기능 중 가장 중요한 기능
• 프로세스와 프로그램은 기본적으로 구분된다.

프로세스는 실제 메인 메모리에서 실행 중인 프로그램. 프로그램은 하드 디스크와 같은 보조 기억장치에서 아무런 동작을 하지 않는 상태. 어떠한 요청에 의해 메인 메모리에 할당하여 CPU를 사용하면서 실행하게 되는데 이를 프로세스라고 부른다.

프로세스 관리의 주요 기능

• 프로세스의 생성 과 소멸
• 프로세스 활동 일시 중지, 활동 재개
• 프로세스 간 통신(IPC)
• 프로세스 간 동기화
• 교착상태 관리

2. 주기억장치 관리

• 주기억장치 즉, 메인 메모리는 프로그램이 실행되기 위한 공간.

CPU는 오직 메인 메모리에 있는 프로그램(프로세스)하고만 통신이 가능하다. 주기억장치 관리에서는 메인 메모리를 효율적으로 사용하도록 관리한다.

• 프로세스에게 메모리 공간 할당
• 메모리의 어느 부분이 어느 프로세스에게 할당되었는지 추적 및 감시
• 프로세스 종료 시 메모리 회수
• 메모리의 효과적 사용
• 가상 메모리 : 물리적 실제 메모리보다 큰 용량을 사용할 수 있다.

3. 파일 관리

디스크는 물리적으로 Track과 Sector로 구성되어 있으며, 여기서 파일이라는 논리적 관점으로 데이터를 바라보고 관리하는 것이다.

파일은 OS가 실행되는 컴퓨터에서 자주 볼 수 있는데, 이는 복잡한 과정으로 하드 디스크에 저장되어 있는 것을 사용자가 편리하게 사용할 수 있게 파일이라는 논리적인 형태로 OS에서 관리하여 보여준다.

• 파일 생성과 삭제
• 디렉토리의 생성과 삭제
• 기본 동작 지원 : open, close, read, write, create, delete
• Track/Sector : file간 매핑
• 백업

4. 보조기억장치 관리

하드디스크, 플래시 메모리가 있다. 하드디스크에서 아무 것도 저장되어 있지 않는 공간을 block이라 하는데, 보조기억장치 관리는 이를 관리하는 것.

• 빈 공간 관리
• 저장공간 할당
• 디스크 스케줄링

5. 입출력 장치 관리

키보드, 마우스, 프린터, 스피커 등

• 장치 드라이브
• 입추력 장치 성능 향상 : buffering, caching, spooling

6. 시스템 콜

유저 프로세스에서 운영체제 서비스를 필요로 할 때 이를 받기 위해 사용하는 호출. Process1에서 프로세스 관리에 의해 System Call을 요청한 상태. 프로세스가 실행하는 중간에 운영체제 서비스가 필요하면 시스템 콜을 통해 운영체제 안의 해당 코드로 점프할 수 있다.

주요 시스템 콜

• Process: end, abort, load, execute, create, terminate, get/set, attributes, wait event, signal event
• Memory : allocate, free
• File : create, delete, open, close, read, write, get/set attributes
• Device : request, release, read, write, get/set attributes, attach/detach devices
• information : get/set time, get/set system data
• Communication : socket, send, receive

Reference

• 운영체제-OS-운영체제 서비스

• OS의 커널이 제공하는 서비스에 대해, 응용 프로그램의 요청에 따라 커널에 접근하기 위한 인터페이스
• 보통 C,C++과 같은 고급 언어로 작성된 프로그램들은 직접 시스템 호출을 사용할 수 없기에 고급 API를 통해 시스템 호출에 접근하게 하는 방법

연관지어 나오는 내용 Q. 함수 호출과 시스템 호출은 뭐가 달라요? -> 함수 호출은 사용자가 작성한 함수 및 라이브러리의 메서드 등을 호출하는 것. 시스템 호출은 OS내에 미리 정의되어 있는 함수를 호출하는 것.

시스템 콜의 필요 이유

• 우리가 일반적으로 사용하는 프로그램은 '응용 프로그램'이다.
• 유저레벨의 프로그램은 유저레벨의 함수들 만으로 많은 기능을 구현하기 힘들기에 커널의 도움을 받아야 한다.
• 이러한 작업은 응용 프로그램으로 대표되는 유저 프로세스에서 유저모드에서는 수행할 수 없다.
• 반드시 커널에 관련된 것은 커널 모드로 전환한 후에야, 해당 작업을 수행할 권한이 생긴다.
• 커널 모드를 통한 이러한 작업은 반드시 시스템 콜을 통해 수행하도록 설계되어 있다.

Q. 권한이 왜 필요할까?

• 해커가 악의적으로 시스템 콜을 사용하는 경우, 초보가 의도치 않게 아무 함수를 호출해서 시스템이 망가진 경우를 막기 위해!!
• 그래서 유저 모드에서 시스템 콜을 호출할 경우 OS에서 불법적인 접근으로 인지하고 trap을 발생시킨다..

시스템 호출의 유형

1. 프로세서 제어
2. 파일 조작
3. 장치 관리
4. 정보 유지
5. 통신

시스템 호출 종류

• 프로세스와 관련된 시스템 호출

  • 프로세스 제어용

    • exec : 자신을 수행 가능한 다른 프로세스로 대치 수행
      • fork : 현재의 프로세스 이미지를 복사하고 child 프로세스를 만듬
    • wait

  • pipe: 파이프

  • signal : SW 인터럽트 또는 시그널

  • exit : 프로세스 종료

  • getuid, setuid : 사용자 및 그룹 id 접근

• 표준 파일에 대한 입출력 시스템 호출

  • open(), create(), close(), read(), write(), lseek()..

• 소켓 기반 입출력 시스템 호출

  • socket(), bind(), listen(), accept(), connect()

프로그램을 실행하는 도중, 예기치 않은 상황이 발생할 경우 현재 실행중인 작업을 즉시 중단하고, 발생된 상황을 우선 처리한 후 실행 중이던 작업으로 복귀하여 계속 처리하는 것.

인터럽트 당한 시점의 레지스터와 PC(Program Counter : 다음 번에 실행할 명령어 주소)를 PCB에 저장해두고 CPU의 제어를 인터럽트 서비스 루틴에 넘긴다.

지금 수행 중인 일보다 더 중요한 일(ex. 입출력, 우선 순위 연산 등)이 발생하면 그 일을 먼저 처리하고 나서 하던 일을 계속해야 한다.

외부/내부 인터럽트는 CPU의 하드웨어 신호에 의해 발생 소프트웨어 인터럽트는 명령어의 수행에 의해 발생

외부 인터럽트

• 입출력 장치, 타이밍 장치, 전원 등 외부적인 요인으로 발생 전원 이상, 기계 착오, 외부 신호, 입출력

내부 인터럽트

• Trap이라고 부르며, 잘못된 명령이나 데이터를 사용할 때 발생 0으로 나누기가 발생, 오버플로우, 명령어를 잘못 사용한 경우(Exception), 디버깅시 break point

소프트웨어 인터럽트

• 프로그램 처리 중 명령의 요청에 의해 발생한 것 (SVC 인터럽트) 사용자가 프로그램을 실행시킬 때 발생, 소프트웨어 이용 중에 다른 프로세스를 실행 시키면 시분할 처리를 위해 자원 할당 동작이 수행된다.

인터럽트 발생 처리 과정

사진 출처 : https://mindstation.tistory.com/164

1. 인터럽트 요청 발생
2. 프로그램 수행 중단
   • 현재 수행중인 명령의 수행이 완료된 시점에서 중단
   • 현재의 주기억 장치 사이클이 끝나는 시점이 아님
3. PC에 기억되어 있는 주소를 안전한 곳에 기억시켜서 보존
   • 상태 레지스터와 PC 등을 스택에 잠시 저장한다.
4. 인터럽트 전처리 실행
   • 원인 파악
   • 처리 루틴을 호출
5. 인터럽트 처리 루틴 수행
   • 프로그램의 상태를 안전한 곳에 기억시켜 보존
   • 해결
6. 보존 시킨 PC의 값을 PC에, 그리고 보존시킨 프로그램의 상태를 환원시킨 프로그램의 수행을 중단되었던 곳에서부터 계속하여 수행.

전반적으로 PC의 값을 안전한 곳에 기억시켜 보존하고, 원인 판단, 인터럽트 처리루틴의 수행을 개시시키는 순서로 이뤄진다.

근데 위 처럼 인터럽트 기능이 없다면, 컨트롤러가 특정한 일을 할 시기를 알기 위해 지속적으로 체크를 해야 한다 이는 폴링이다.

즉, 컨트롤러가 입력을 받아들이는 방법(우선순위 판별방법)에는 2가지가 있다.

• 폴링 방식

  • 사용자가 명령어를 사용해 입력 핀의 값을 계속 읽어 변화를 알아내는 방식
  • 인터럽트 요청 플래그를 차례로 비교하여 우선순위가 가장 높은 인터럽트 자원을 찾아 이에 맞는 인터럽트 서비스 루틴을 수행. (하드웨어에 비해 속도가 느리다)

• 인터럽트 방식

  • MCU 자체가 하드웨적으로 변화를 체크하여 변화 시에만 일정한 동작을 하는 방식
    • daisy chain
      • 병렬 우선순위 부여

인터럽트 방식은 HW로 지원 받아야 하는 제약이 있지만, 폴링에 비해 신속 대응이 가능하다. 그래서 실시간 대응의 경우 = 인터럽트 방식이 필수적이다.

면접 질문

Q. 한컴오피스 '한글'을 클릭 후 빈 화면어 커서가 깜빡이고 있다. 이때 hello world를 작성하면 컴퓨터 내부에서 어떤일이 발생하는가?

• 키보드에서 사용자 입력이 들어오면 키보드 컨트롤러가 인터럽트를 발생시켜서 CPU에게 키가 입력 되었다는 사실을 알려준다.
• CPU는 현재 수행중이던 작업의 상태를 저장하고 인터럽트 요청 처리를 위해 OS내에 정의된 키보드 인터럽트 처리 루틴을 찾아간다.
• 키보드 인터럽트 처리 루틴은 키보드로부터 입력받은 내용을 메모리의 특정 부분에 저장해서 해당 프로그램에게 키보드 입력이 들어왔음을 알리며 인터럽트 처리를 완료한다.
• 인터럽트 처리가 끝나면 인터럽트 발생 직전 상태를 복구시켜 중단된 작업을 재개한다.

Reference

• brave-tech-interview
• Interrupt

✋ 속도가 빠른 장치와 느린 장치에서 속도 차이에 따른 병목 현상을 줄이기 위한 메모리를 말한다.

ex1) CPU 코어와 메모리 사이의 병목 현상 완화 ex2) 웹 브라우저 캐시 파일은, 하드디스크와 웹페이지 사이의 병목 현상 완화

CPU가 주기억장치에서 데이터를 읽어올 때, 자주 사용하는 데이터를 캐시 메모리에 저장한 뒤, 다음에 이용할 때 주기억장치가 아닌 캐시 메모리에서 먼저 가져오면서 속도를 향상시킨다.

속도라는 장점이 있지만, 용량이 적기도 하고 비용이 비싼 점이 있다.

CPU에는 이러한 캐시 메모리가 2~3개 정도 사용된다. (L1, L2, L3 cache memory라고 부른다)

속도와 크기에 따라 분류한 것으로, 일반적으로 L1 캐시부터 먼저 사용된다. (CPU에서 가장 빠르게 접근하고 여기서 데이터를 찾지 못하면 L2로 간다.)

듀얼 코어 프로세서의 캐시 메모리

: 각 코어마다 독립된 L1 캐시 메모리를 가지고, 두 코어가 공유하는 L2 캐시 메모리가 내장되어 있다.

만약 L1 캐시가 128kb면, 64/64로 나눠 64kb에 명령어를 처리하기 직전의 명령어를 임시 저장하고, 나머지 64kb에는 실행 후 명령어를 임시 저장한다.

• L1 : CPU 내부에 존재 (I-Cache(Instruction Cache) + D-Cache(Data Cache)
• L2 : CPU와 RAM 사이에 존재
• L3 : 보통 메인 보드에 존재

디스크 캐시 : 주기억장치(RAM)와 보조기억장치(하드디스크) 사이에 존재하는 캐시

CPU는 데이터를 가져오기 위해 캐시메모리 -> 메모리(RAM) -> 보조기억장치(HDD) 순으로 접근한다.

• Cache hit ✅ : 캐시 메모리의 데이터를 CPU 레지스터에 복사한다.
• Cache Miss ❎, Memory hit ✅ : 메모리에서 데이터를 캐시 메모리에 복사하고 캐시 메모리의 복제된 내용을 CPU 레지스터에 복사한다.
• Cache Miss ❎, Memory Miss ❎, HDD hit ✅ : 보조 기억장치에서 필요한 데이터를 메모리에 복사한다. 메모리에 복제된 내용을 캐시 메모리에 복제한다. 캐시 메모리의 복제된 데이터를 CPU 레지스터에 복제한다.

캐시 메모리 작동원리

• 시간 지역성
  • for, while 같은 반복문에 사용하는 조건 변수처럼 한 번 참조된 데이터는 잠시 후 또 참조될 가능성이 높음
• 공간지역성
  • A[0], A[1]과 같은 연속 접근 시, 참조된 데이터 근처에 있는 데이터가 잠시 후 또 사용될 가능성이 높음.
• 순차지역성
  • 분기가 발생하지 않는 한 명령어는 메모리에 저장된 순서대로 인출/실행된다.

캐시에 데이터를 저장할 때는 이러한 참조 지역성(공간)을 최대한 활용하기 위해 해당 데이터 뿐 아니라, 옆 주소의 데이터도 같이 가져와 미래에 쓰일 것을 대비한다.

보통 명령어(Instruction)은 공간 지역성이 높고 데이터는 시간 지역성이 높다.

CPU가 요청한 데이터가 캐시에 있으면 'Cache hit' 없으면 DRAM에서 가져오면 'Cache Miss'.

Cache Miss의 3가지 경우

1. Cold miss (Compulsory miss)

• 해당 메모리 주소를 처음 불러서 나는 미스

2. Conflict miss

• 캐시 메모리에 A,B데이터를 저장해야 하는데, A,B가 같은 캐시 메모리 주소에 할당되어 있어서 나는 미스.
• 아주 좋은 예시 (항상 핸드폰과 열쇠를 오른쪽 주머니에 넣고 다니는데, 잠깐 친구가 준 물건을 받느라 손에 들고 있던 핸드폰을 가방에 넣었음. 그 이후 핸드폰을 찾으려 오른쪽 주머니에서 찾는데 없는 상황)

3. Capacity miss

• 캐시 메모리의 공간이 부족해서 나는 미스 (Conflict는 주소 할당의 문제, Capacity는 공간의 문제)

캐시 크기를 키워서 문제를 해결하려하면, 캐시 접근 속도가 느려지고 파워를 많이 먹는 단점..

구조 및 작동 방식

• Direct Mapped Cache
  • 가장 기본적인 구조.
  • DRAM의 여러 주소가 캐시 메모리의 한 주소에 대응되는 다대일 방식. 위의 그림에서 메모리 공간이 32개이고 캐시 메모리 공간은 8개인 상황. ex) 00000,01000,10000,11000인 메모리 주소는 000 캐시 메모리 주소에 맵핑
  • 이때 000이 '인덱스 필드', 인덱스 제외한 앞의 나머지 00,01,10,11를 태그 필드라고한다.
  • 이처럼 캐시메모리는 인덱스 필드 + 태그 필드 + 데이터 필드로 구성된다.
  • 간단하고 빠른 장점이 있지만, Conflict Miss가 발생하는 것이 단점이다. 위 사진처럼 같은 색깔의 데이터를 동시에 사용할 때 발생한다.

• Fully Associative Cache

  • 비어있는 캐시 메모리가 있으면, 마음대로 주소를 저장하는 방식 저장할 때는 매우 간단하지만, 찾을 때가 문제이다.
  • 조건이나 규칙이 없어서 특정 캐시 Set안에 있는 모든 블럭을 한번에 찾아 원하는 데이터가 있는지 검색해야 한다.
  • CAM이라는 특수한 메모리 구조를 사용해야 하지만 매우 비싸다..

• Set Associative Cahce

  • Direct + Fully 방식.
  • 특정 행을 지정하고 그 행 안의 어떤 열이든 비어있을 때 저장하는 방식.
  • Direct에 비해 검색 소도는 느리지만 저장이 빠르고 Fully에 비해 느린 대신 검색이 빠른 중간형이다.

Reference

• 캐시 메모리

• Process는 독립적
• 그렇기에 다른 프로세스에게 영향을 받지도 않는다. (스레드는 프로세스 안에서 자원을 공유하기에 영향을 받는다.)

이런 독립적 구조를 가진 프로세스 간 통신 상황에서 가능하도록 해주는 게 IPC이다.

프로세스는 커널이 제공하는 IPC 설비를 이용하여 프로세스 간 통신을 할 수 있다.

커널이란?

운영체제의 핵심적인 부분으로, 다른 모든 부분에 여러 기본적인 서비스를 제공해준다. IPC 설비 종류도 여러가지가 있다. 필요에 따라 IPC 설비를 선택해서 사용해야 한다.

IPC 종류

1. 익명 PIPE

• 파이프는 두 개의 프로세스를 연결하는데 하나의 프로세스는 데이터를 쓰기만 하고, 다른 하나는 데이터를 읽기만 할 수 있다.
• 한 쪽 방향으로만 통신이 가능한 반이중 통신이라고도 부른다. 따라서 양쪽으로 모두 송/수신을 하고 싶다면 2개의 파이프를 만들어야 한다.
• 매우 간단하게 사용 할 수 있는 장점이 있고, 단순한 데이터 흐름을 가질 땐 파이프를 사용하는 것이 효율적이다.
• 단점으로는 전이중 통신을 위해 2개를 만들어야 할 때는 구현이 복잡해지게 된다.

2. Named PIPE(FIFO)

• 익명 파이프로 통신할 프로세스를 명확히 알 수 없는 경우에 사용(부모-자식 프로세스 간 통신처럼)
• Named 파이프는 전혀 모르는 상태의 프로세스 들 사이 통신에 사용된다.
• 익명 파이프의 확장된 상태로 부모 프로세스와 무관한 다른 프로세스도 통신이 가능한 것 (통신을 위해 이름 있는 파일을 사용한다.)
• 하지만, Named 파이프 역시 읽기/쓰기 동시에 불가하다. 따라서 전이중 통신을 위해서는 익명 파이프처럼 2개를 만들어야 가능하다.

3. Message Queue

• 입출력 방식은 Named 파이프와 동일
• 다른 점은 메시지 큐는 파이프처럼 데이터의 흐름이 아니라 메모리 공간이다.
• 사용할 데이터에 번호를 붙이면서 여러 프로세스가 동시에 데이터를 다룰 수 있다.

4. 공유 메모리

• 파이프, 메시지 큐가 통신을 이용한 설비라면, 공유 메모리는 데이터 자체를 공유하도록 지원하는 설비
• 프로세스의 메모리 영역은 독립적으로 가지며 다른 프로세스가 접근하지 못하도록 반드시 보호되어야 한다. 하지만 다른 프로세스가 데이터를 사용하도록 해야하는 상황도 필요할 것이다. 파이프를 이용해 통신을 통해 데이터 전달도 가능. 하지만, 스레드 처럼 메모리를 공유하도록 해준다면 훨씬 편할 것이다.
• 공유 메모리는 프로세스 간 메모리 영역을 공유해서 사용할 수 있도록 허용해준다.
• 프로세스가 공유 메모리 할당을 커널에 요청하면, 커널은 해당 프로세스에 메모리 공간을 할당해주고 이후 모든 프로세스는 해당 메모리 영역에 접근할 수 있게된다.
• 중개자 없이 곧바로 메모리에 접근할 수 있어서 IPC중 가장 빠르게 동작한다.

5. 메모리 맵

• 공유 메모리처럼 메모리를 공유해준다.
• 메모리 맵은 열린 파일을 메모리에 맵핑시켜서 공유하는 방식이다. (즉, 공유 매개체가 파일+메모리)
• 주로 파일로 대용량 데이터를 공유해야 할 때 사용한다.

6. 소켓

• 네트워크 소켓 통신을 통해 데이터를 공유한다.
• 클라이언트와 서버가 소켓을 통해 통신하는 구조로, 원격에서 프로세스 간 데이터를 공유할 때 사용한다. 서버 (bind, listen, accept) 클라이언트(connect)

이러한 IPC 통신에서 프로세스 간 데이터를 동기화하고 보호하기위해 세마포어와 뮤텍스를 사용한다. (공유된 자언에 한번에 하나의 프로세스만 접근 시킬때)

Reference

• 위 글의 원본은 여기에 있습니다.