Dev.log

Block과 Non-Block

Block과 Non-Block은 함수 호출에 관해서 호출자가 취하는 태도의 차이이다.

Block 시에는 호출자가 함수를 호출하고, 해당 함수가 실행되고 결과값이 리턴될 때까지 기다린다.

Non-Block 시에는 호출자가 함수를 호출하고, 리턴 되기를 기다리지 않고 바로 다음 코드를 실행한다.

Sync와 Async

동기와 비동기는 추상적인 개념이다.

Task A와 Task B가 인과관계가 있을 때, 이 인과관계에 따라서 순차적으로 실행된다면 동기이다.

만약 인과관계가 있음에도 A와 B가 동시에 실행된다면 이는 비동기이다.

인과관계가 없다면 A와 B는 동기에 가깝다. (인과관계가 아예 없는 경우는 동기 비동기를 논하는 것이 큰 의미가 없는 듯 하다.)

한편으로는, 제어권의 반환과 결과값(리턴값)의 전달이라는 측면에서도 이를 설명할 수 있다.

제어권의 반환과 결과값의 전달이 동시에 일어난다면 동기, 제어권의 반환과 결과값의 전달이 동시에 일어나지 않는다면 비동기이다.

인텐트(intent)의 필요성

안드로이드 스튜디오에서 New Project - empty project를 생성하면 기본적으로 하나의 Main Activity가 존재한다.

가장 기본이다. 하지만 실제 어플리케이션 내에서는 화면 간 이동이 존재하고 그 속에서 데이터가 오고간다.

하나의 화면에 앱이 사용자에게 제공하고자 하는 모든 기능과 뷰를 담을 수는 없다.

그렇기 때문에 우리는 화면을 여러개로 나누어 전환하며 데이터를 주고 받으며 처리하여 사용자에게 원하는 서비스를 제공한다.

이 역할을 인텐트(intent)가 한다.

인텐트(intent)의 두 가지 역할

인텐트의 핵심 두 가지 역할은 화면 전환과 데이터 전달이다.

화면 전환

Activity 하나당 하나의 화면을 구성한다고 생각하면 되며, intent 를 이용해 이러한 화면을 전환할 수 있다.

데이터 전달

물론 화면을 이동할 때 전 화면에서 가지고 있던 데이터를 전달할 필요가 생긴다. 이러한 데이터 전달 또한 인텐트가 해낸다.

명시적 인텐트(Explicit Intent)와 묵시적 인텐트(Implicit Intent)

명시적 인텐트는 Intent 객체에 다음 화면으로 전환할 때 쓰일 컴포넌트를 직접 지정하며, 이러한 화면 전환은 주로 어플리케이션 내부에서 일어난다.

묵시적 인텐트는 Intent 객체에 다음에 수행할 액션(ex. uri 웹 검색, 전화 걸기, 지도 보기 등)을 지정한다. 동작 시 해당 액션을 수행할 관련 어플리케이션을 탐색하고 선택하여 인텐트 객체를 기반으로 실행한다.

Virtual Address와 Physical Address 사이의 Mapping

CPU가 가지고 있는 Virtual Address와 Main Memory의 실제 데이터를 가리키는 Physical Address가 있다.

운영체제(OS)는 이와 같은 메모리 가상화를 제공한다.

가상화를 통해서, 각각의 프로세스는 개별적으로 고유한 메모리를 할당받아 사용할 수 있으며, 이를 통해서 다수의 프로세스를 실행할 때 발생하는 잘못된 메모리 접근으로부터의 보안과 효율적인 메모리 관리가 가능해졌다.

Segment와 Page

Segment(세그먼트)는 메모리를 서로 크기가 다른 논리적 블록 단위이다.

이렇게 세그멘트를 나누어 메모리를 관리하는 기법을 세그멘테이션이라고 하며,

세그멘테이션과 가상 메모리를 고정된 크기의 블록으로 나누어 관리하는 것이 페이징 기법이다.

따라서 Page(페이지)는 메모리를 잘게 쪼갠 일정한 크기의 블록 단위이다.

Page Table

Page Table은 Virtual Address와 Physical Address 사이에서 Page 단위의 memory address를 Mapping하는 역할을 한다.

Main Memory에 상주하고 있으며 이로 인해 CPU는 불가피하게 Main Memory에 한 번 더 접근해야 한다.

1. Virtual Address에 해당하는 Physical Address를 Main Memory의 Page Table로부터 조회한다.

2. 조회한 Physical Address로부터 데이터를 가져온다. 이 때, 해당 데이터가 Cache에 있을 경우 Cache로부터, 없을 경우 Main Memory로부터 가져온다.

즉, 1번 단계에서 반드시 Main Memory에 접근해야 하므로 성능 측면에서 비효율적이다.

Translation Look-aside Buffer

데이터를 가져올 때, CPU와 Main Memory사이의 간극을 줄이기 위해 캐시 메모리를 도입한 것처럼 

데이터를 가져오기 위한 address를 조회할 때, CPU와 Main Memory사이의 간극울 줄이기 위해 도입한 것이 TLB(Translation Look-aside Buffer)이다. Page Table의 cache라고 볼 수 있다.

이를 통해서 가상 메모리 주소(virtual address)로부터 물리적 메모리 주소(physical address) 변환하는 속도를 높일 수 있다.

캐시 일관성

각각 CPU의 캐시 데이터와 메인 공유 메모리의 데이터가 모두 일치하도록 하는 것

캐시 일관성 문제

위의 캐시 일관성이 지켜지지 않는 상황이다. CPU 캐시 데이터와 메인 메모리의 데이터 사이의 괴리 또는 멀티 프로세서에서 각각 CPU 캐시 데이터 사이의 괴리 모두 이에 포함된다.

해결 방식

소프트웨어적 해결방식과 하드웨어적 해결방식으로 나뉜다.

소프트웨어적으로는 컴파일 시(Compile time) 문제를 검출하며

하드웨어적으로는 실행 시(Run time) 문제를 검출한다.

소프트웨어적 해결

운영체제(OS)와 컴파일러를 사용하여 해결하는 방식이다. 코드 분석을 통해 안전하게 공유 변수를 사용할 수 있도록 주기를 설정하거나, 아예 공유 데이터 변수를 캐시에 저장하지 않도록 설정하는 방법 등이 있다. Compile Time에 문제를 검출하므로, 캐시 이용률 측면에서 다소 비효율적이라는 단점이 있다.

하드웨어적 해결

1. 스누피 프로토콜(snoopy protocol)

각각 CPU의 캐시들은 공유되는 캐시 데이터를 파악하고 있으며, 공유되는 캐시 데이터가 갱신 되었을 경우 이를 기반으로 갱신되지 않은 나머지 데이터를 무효화한다. 공유되는 버스 구조가 Broadcasting 및 Snooping에 유리하므로 버스 기반 다중 프로세서 시스템에 적합한 방식이다.

2. 디렉토리 프로토콜(directory protocol)

주기억장치의 중앙 제어기가 캐시 일관성을 관리하는 형태이다. 주기억장치의 중앙 제어기는 각각 CPU의 캐시 데이터들을 가지고 있으며, 모든 지역 캐시 제어기의 동작을 제어하고 보고받으며 캐시 일관성을 관리한다.

이전에 Layout과 View의 차이에 대해서 알아보았다.

이번엔 XML과 View 사이에서 LayoutInflater가 하는 역할에 대해 알아본다.

View

View는 앱 사용자에게 실제로 보여지는 위젯이다.

Xml

XML은 View에 사용되는 Resource를 정의하여 저장해두는 문서이다.

이렇게 하면, Xml에 저장된 뷰를 재사용할 수 있어 용이하고, 로직과 뷰를 분리할 수 있어 가독성과 관리 측면에서 유리하다.

LayoutInflater

LayoutInflater는 xml에 정의된 뷰 리소스를 메모리에서 사용할 수 있는 View객체로 반환하는 역할을 한다.

따라서, 뷰 리소스가 정의되어 있는 Xml을  객체화(Objectify) 실제 앱에 사용하고 싶을 때 이 과정을 담당하는 것이 LayoutInflater이다.

안드로이드 앱 개발을 시작하면 View와 Layout이 등장한다.

둘의 차이점이 모호하게 느껴져 명확하게 하고 싶었다.

Layout, View

Layout은 View를 포함하는 보이지 않는 틀이다.

View는 실제로 사용자가 어플을 사용할 때 보이는 위젯이다.

그렇다면 Layout은 보이지 않는데 왜 필요할까?

View 위젯들을 배치하는 과정에서 Layout의 존재가 없다면 중구난방일 것이다. 앱을 개발하다보면 View는 각각 독립적으로 따로 노는 것이 아닌, 하나의 흐름을 갖기도 하고, 하나의 기능을 나타내기도 하며, 사용자에게 제공하고자 하는 작은 단위 서비스의 묶음이 되기도 한다. 그래서, View들을 그룹화해 정렬하거나 배치하고자 하는 필요가 생길 것이다.

Layout이 이를 담당한다.

Layout과 View의 포함관계

Layout이 View를 그룹화하는데 사용되지만, 이렇게 View를 그룹화한 Layout이 다시 상위 View로 나타내지기도 한다.

View안에 (ex. HorizontalScrollView) 여러 View들(ex. TextView)을 그룹화하여 나타내고 싶을 때, Layout(ex. LinearLayout)을 통해서 작은 여러 View들을 묶어 큰 View(ex. HorizontalScrollView)로 나타내줄 때도 있다는 것이다.

Entity

개체. 실생활에서 필요한 정보들을 데이터베이스화하는 과정에서 각각의 정보들은 각각은 Entity로 정의된다.

Relationship

관계. 정의한 Entity들 사이에서 관계를 맺는다.

Entity Relationship

개체간의 관계를 맺는 것

왜 개체간의 관계를 맺을까?

수강 신청 시스템을 생각해보자.

엔티티로 학생과 수업이 존재한다.

학생이 수강신청을 한다.

학생-수업간의 관계가 발생한다.

즉, 해당 학생(학생 엔티티의 인스턴스)과 해당 수업(수업 엔티티의 인스턴스) 사이에는 '모 학생이 신청한 모 수업'이라는 관계가 발생한다.

이제, 해당 학생을 조회하면 관계를 통해 신청한 수업 목록을 조회할 수 있다. 반대로 수업을 조회하면 해당 수업을 신청한 학생 목록을 조회할 수 있다.

우리는, 그리고 세상의 모든 것들은 저마다 고유한 관계를 맺고 있다.

개발자는 그 중에서, 개발하는 시스템의 requirements(요구 조건)에 부합하는 특정 정보들을 추출하여 데이터베이스화한다.

이러한 데이터베이스화 과정에서 엔티티간의 관계를 맺는 Entity Relationship 과정은 유의미하고 필수적이다. 

Mapping Constraints

Entity Relationship을 정의할 때 엔티티 간에 서로 관계를 맺을 수 있는 엔티티의 개수에 대해서 표현하는 조건이다.

- 1 :1   일대일 매핑

- 1 : n   일대다 매핑

- n : 1   다대일 매핑

- m : n   다대다 매핑

Participation Constraints

관련된 엔티티의 모든 인스턴스가 반드시 참여해야하는지, 꼭 그럴 필요는 없는지 표현하는 조건이다.

- Total (mandatory)

관련 엔티티의 모든 인스턴스는 반드시 관계를 맺어야한다.

- Partial (optional)

관련 엔티티의 모든 인스턴스가 관계에 참여할 필요는 없다.

(min, max) Constraints

엔티티간 맺을 관계의 개수를 범위로 제한한다.

(관련된 엔티티가 맺어야하는 최소 관계 수, 관련된 엔티티가 맺을 수 있는 최대 관계 수)

Recursive Relationship

Relationship with degree 1

하나의 엔티티에서, 해당 엔티티의 인스턴스간에 관계를 맺는 것이다.

Relationship에 참가하는 인스턴스간의 엔티티 타입이 같다.

예를 들어, 학생과 학생의 관계, 과목과 과목들간의 관계, 부품과 부품간의 관계가 이와 같다.

참여한 동일한 엔티티 타입의 인스턴스를 구분하기 위해서, 서로 맡은 다른 역할(Role)이 필요하다.