이전에 동아리에서 진행하던 프로젝트를 다시 리펙토링하는 시간을 갖기로 했다.

전에는 3주라는 짧은 시간동안 모두 구현을 해야 했기 때문에 코드가 탄탄하지 않았고, 뿐만 아니라 난생 처음 써보는 SwiftUi와 혼용해야 했기에 코드를 다시 뜯어볼 필요가 있었다.

SwiftUI를 사용해야 했던 이유는, screenTime API를 사용해야 했기 때문이다.

당시에는 Github에서 누군가 사용해둔 screenTime API를 참고해서 개발을 진행했었는데, 공부할 시간조차 없다고 느껴졌기에 제대로 이해하지 못한채 프로젝트에 반영해버렸다.

이번에는 다시 더 탄탄하게 만드는만큼, 제대로 공부하고, screenTime API 마스터가 돼야 겠다.

오늘은 screenTime API를 프로젝트에 반영하기에 앞서, 해당 API에는 무엇이 있는지, 어떤 기능이 있는지, 어떻게 사용하는지 등을 공부하고 정리하고자 한다.

https://developer.apple.com/videos/play/wwdc2021/10123/

위 공식문서를 참고하였다.

ScreenTime API란?

자꾸 공식문서에서 강조하는 부분이 있었다. 

바로 맞춤형 부모 통제 기능을 지원한다는 것이었는데, 해당 내용을 강조하고 있다.

이 API는 크게 3가지로 나뉜다.

1. DeviceActivity

2. FamilyControls

3. ManagedSettings

차근차근 하나씩 공부해보자 !

1. DeviceActivity란?

https://developer.apple.com/documentation/DeviceActivity

이 Framework는 말 그대로, 기기 활동을 모니터링하기 위함이다.

이 프레임워크는 다음과 같은 기능을 제공한다.

1. 사용자의 앱 및 웹사이트 활동을 모니터링할 수 있도록 하고,

2. 프라이버시를 보호하는 방법을 제공한다.

구체적인 상황을 예로 들어보면,

사용자가 잠자리에 들어야하는 시간 동안 기기 활동을 모니터링하도록 취침 시간을 설정할 수 있다.

즉, 더 확장해보면, 활동 일정이 시작되거나 끝나기 전에, 혹은 활동이 미리 정의된 한계에 도달할 때 경고 혹은 알림을 받을 수 있다.

이는 계속 사용 시간과 활동을 모니터링하여 사용자가 특정 한계에 도달했을 때를 인지할 수 있다는 것이다.

내가 구현해야 하는 기능 중 하나인, 특정 앱을 특정 시간 사용했을 때 사용자가 이를 인지하게 하는 기능을 구현하기 위해서는 해당 framework의 기능이 무조건적으로 필요하다 !

2. FamilyControls란?

이 framework는 말 그대로, 처음에 계속 강조했던 부모의 통제 권한을 위한 것이다.

이 부분은 내가 진행하는 프로젝트에서 사용하지 않을 것 같지만, 자꾸 강조하니 짧게나마 정리를 해봐야겠다.

근데 지난 개발에서는 이 framework도 사용했던 것 같은데, screenTime을 설정하려면 1차적으로 필요한 framework인지 잘 모르겠다.

추후 직접 구현하다보면 알게 되겠지?

Family Sharing group

이 framework는 부모가 자녀의 앱 사용을 통제하기 위함이 목적이다.

이를 위해서는, 부모의 통제 권한 할 수 있는 승인이 필요한데 이를 위해서는 자녀과 같은 가족 공유 그룹에 속해있어야 한다.

즉, 자녀와 부모가 같은 가족 공유 그룹(Family Sharing group)에 속해 있어야 부모가 자녀의 앱 사용을 통제할 수 있다는 것이다.

이러한 승인 과정은, 시스템에서 자녀의 기기에 인증 sheet를 표시하고, 부모나 보호자가 이에 대한 권한을 승인 또는 거부할 수 있다.

그리고 그 결과를 앱의 AuthorizationCenter로 전달한다.

AuthorizationCenter

이 framework에서 AuthorizationCenter는 꽤나 중요한 역할을 한다.

부모가 권한을 승인 또는 거부할 수 있고, 사용자(즉, 자녀)의 승인 또한 필요한데 이 권한 결과 또한 AuthorizationCenter로 전송한다.

즉, 정리하면 쉽게 사용자를 부모와 자녀로 나눠보자.

이 때, 같은 가족 공유 그룹에 속한 부모와 자녀는 각각 권한에 대한 승인이 필요하다.

부모과 자녀가 권한을 승인 또는 거부했는지에 대한 응답 결과가 AuthorizationCenter로 모두 전송되어 처리된다는 것이다.

주요 기능

이 framework의 주요 기능은 다음과 같다.

1. 부모나 보호자로부터 인증된 자녀(사용자)가 부모 통제 설정을 우회할 수 있는 행동을 하지 못하도록 방지한다.

2. 기기에 부모나 보호자가 인증한 통제 앱이 하나 이상 있을 경우, 사용자는 iCloud에서 로그아웃 할 수 없다.

즉, 자녀는 부모 통제 아래 있는 앱을 삭제할 수 없으며, 통제를 벗어날 수 없다는 것이다.

자녀들은 정말 싫어할만한 framework이지만, 부모님들은 상당히 좋아하실.. 그런 framework이다.

3. Manage Settings

Managed Settings는 사용자가 자신의 기기에서 특정 설정 및 기능에 대한 접근을 제한할 수 있는 프라이버시 보호 방식을 제공한다.

사용자의 허가를 받으면, 다음과 같은 것들을 할 수 있다.

1. 미디어 콘텐츠 표시 제한

2. 앱 구매 제한

3. 암호 설정을 잠그고, 다른 기기 동작을 구성할 수 있다.

처음 배포를 준비해보는 나는,,,

디버깅 모드와 릴리즈 모드가 따로 있다는 것을 몰랐다.

순탄하게 test flight까지 등록하고, 설레는 마음으로 앱을 설치해 실행해봤는데

웬걸,,,

가장 중요한 탭바가 화면에 보이지 않는다.

아ㅏ... 어쩌지..

배포 경험이 있는 친구에게 물어봤다.

🤯 : 테플에 등록했는데 개발할때랑 다르면 어떡해?

😏 : 뭘 어떡해 다시 수정해야지

🙁 : (아오) 어떻게 그걸 재현하는데,,

🤔 : release 모드로 빌드하는거 있을걸? flutter에서는 flutter run —release하면 되던데 너네도 있을걸?

이렇게 할게 된 release 모드 빌드..

어떻게 하냐면, xcode의 상단에 있는 Product 에서 Scheme > Edit Scheme을 하고, 

Build Configuration을 Debug -> Release로 바꿔주면 된다 !

내 경우, 이렇게 해도 여전히 탭바가 안보였지만,,

이건 무슨 문제인지 더 찾아봐야 할 듯 하다.

어쨌든 배포된 버전으로 빌드하고 싶다면, 이렇게 Build Configuration을 바꿔주면 된다 !

여러 개발자가 하나의 저장소에 작업 할 때, 보다 효과적으로 협업하기 위해 git branch 에 대한 규칙을 정하고 저장소를 잘 활용하기 위한 workflow 를 정의하는 것을 바로 git branch 전략이라고 한다.

개발을 할 때, 추가된 기능이나 수정사항이 서로 영향을 주지 않고, 독립적으로 동시에 진행할 수 있도록 한다. 또한, 각 브랜치가 특정 작업을 진행하고, 필요한 경우 해당 작업 단위의 Rollback이 가능하기에 프로젝트 관리의 유연성을 향상시킬 수 있다.

이러한 전략은 원하는 버전 단위로 관리할 수 있도록 하여 프로젝트의 관리와 배포의 안정성을 높여준다.
Branch 전략은 다음과 같은 3가지가 있다.
1️⃣ Git flow
2️⃣ Github Flow
3️⃣ Gitlab flow

1️⃣ Git flow

브랜치 종류

1. master: 제품 출시 버전을 관리하는 메인 브랜치
2. develop: 다음 출시 버전을 위해 개발하는 브랜치
3. feature: 새로운 기능을 개발하는 브랜치
4. release: 다음 출시 버전을 준비하는 브랜치
5. hotfix: 출시된 제품의 버그를 고치기 위한 브랜치

Git Flow를 활용한 개발 진행 흐름

1. 신규 기능 개발은 develop 브랜치를 기준으로 한 feature 브랜치를 따서 작업
2. 작업이 완료된 feature 브랜치는 develop 브랜치로 병합.
   • PR을 통해 리뷰 후 병합하는 방식
3. 배포를 위한 준비는 다음 출시 버전을 위해 개발중인 develop 브랜치에서 release 브랜치를 따서 한다.
   • 만약, 해당 과정에서 버그가 발견된다면, release 브랜치에서 바로 반영
4. 테스트 후, 일정 주기로 master 브랜치로 병합하여 제품 출시
5. 배포 이후, release 브랜치에서 발견되지 못한 새로운 버그는 main 브랜치에서 hotfix 브랜치를 판 후, hotfix 브랜치에서 바로 고친 후 main으로 병합
6. hotfix 브랜치에서 고치고, main 브랜치에 병합 되었다면, 이를 develop 브랜치에도 병합

특징

• release와 hotfix 브랜치를 통해 명확한 배포 절차를 갖추고 있다.
• 다양한 종류의 브랜치를 사용한다.
• 복잡한 프로젝트나 대규모 팀에서 사용하기 적합하다.
• 복잡성과 Control을 가지고 있어 특정 기능이나 수정을 빠르게 배포해야 할 경우 등에서 유연성이 떨어짐.

2️⃣ Github Flow

브랜치 종류

• master : base가 되는 브랜치
• feature : master에 기능을 추가하기 위한 새로운 브랜치

Github Flow를 활용한 개발 진행 흐름

1. master 브랜치는 배포를 위한 소스코드를 관리하는 브랜치.
2. 만약, 신규 기능 개발이 필요하다면, master 브랜치로부터 feature 브랜치로 새로 따서 작업을 진행한다.
3. Task가 완료되면, Pull Request를 생성하여 Review를 요청하고, PR은 feature → master 브랜치이다.
4. 리뷰 완료 후, 피드백이 모두 반영되었다면, 해당 feature 브랜치를 master 브랜치로 병합한다.

특징

• 단순하며 지속적인 배포를 강조하며, master 브랜치에서 배포를 수행한다.
• 단순하며 빠른 개발 및 배포를 위해 사용된다.
• 테스트와 검증 절차를 거치지 않고 바로 master 브랜치로 Merge 되므로 위험성이 있다.

3️⃣ Gitlab flow

복잡한 Git Flow와 너무 간단한 Github Flow의 절충안

브랜치 종류

• master : 안정적인 코드가 저장되는 브랜치로 base가 되는 브랜치.
  • 전체적인 테스트 진행이 완료되어 기능에 대한 보장이 있다면, production 브랜치로 머지.
  • 만약 staging 단계가 필요하다면, pre-production 브랜치로 머지.
• feature : 각 기능이 개발되는 브랜치.
  • master 브랜치에서 파생되고 PR을 통해 다시 병합된다.
• Production : 테스트가 끝난 기능의 배포를 위한 브랜치
• Pre-Production : 배포 전에 제품을 테스트 (QA, 품질검사) 하는 브랜치
  • 테스트가 정상적으로 완료되면, production 과 master 에 각각 PR(Pull Request)을 보낸다.

Gitlab Flow를 활용한 개발 진행 흐름

• 기능 개발이 필요한 경우, master 브랜치에서 feature 브랜치를 생성한다.
• feature 브랜치에서 기능 개발 완료 후, PR을 통해
  • 기능에 대한 검증 및 보장이 있다면 production 브랜치로 머지한다.
  • 기능에 대한 검증 및 보장이 필요하다면, pre-production 브랜치로 머지한다.
• pre-production 브랜치에서 테스트가 완료 되었다면, production과 master에 PR을 통해 병합한다.

특징

• 간단하고 직관적인 플로우를 제공하여 개발 프로세스를 이해하기 쉽게 만든다.
• GitLab은 내장된 CI/CD 파이프라인을 제공하므로 빌드, 테스트, 배포 등을 자동화할 수 있다.
  • 이를 통해 안정적인 배포와 빠른 피드백을 얻을 수 있습니다.
• 비교적 간단한 프로세스를 제공하기 때문에, 대규모 프로젝트에서는 협업과 관리가 어려울 수 있다.
• 특히 지속적인 배포가 강조되는 환경에서 효과적이다.

🖥️  CPU Scheduling

시스템의 CPU 사용 효율을 극대화하기 위해 다중 프로그래밍과 멀티태스킹 기술을 사용하는 것

Resources (CPU포함)는 process들 사이에서 공유된다.

🖥️ CPU-IO Burst Cycle

프로세스가 실행되는 동안 CPU 사용(bursts)과 입출력(I/O) 대기 시간 사이를 번갈아 가며 반복하는 현상

Types of processes

• I/O bound process
  • 입력(input)과 출력(output) 작업에 더 많은 시간을 소비하는 프로세스
• CPU-bound process
  • 계산이나 처리 과정에서 대부분의 시간을 소비하는 프로세스

🖥️ CPU Scheduler

CPU Scheduler는 ready queue에서 process를 선택하고, CPU core를 할당한다.

When Scheduling Occurs?

1. running에서 waiting state으로 switch 될 때 (Nonpreemtive)
2. running에서 ready state으로 switch 될 때 (Preemtive)
3. wating에서 ready로 switch 될 때 (Preemtive)
4. 종료될 때 (Nonpreemtive)

Non-preemptive vs Preemptive

- Non-preemptive scheduling

• 아무도 interrupt할 수 없다.
• running → waiting / terminate 될 때마다 발생한다.
• Running process는 interrupted 가 아니다.

- Preemptive scheduling

• 1,2,3,4에서 발생할 수 있다.
• processing이 실행 중일 때 scheduling이 발생한다.
  • interrupt, process with higher priority
• HW의 지원과 shared data handling이 필요하다.
• 선점형 스케줄링이 여러 프로세스 간에 데이터를 공유할 때 경쟁 상태(레이스 컨디션)를 발생시킬 수 있다.

🖥️ Dispatcher

CPU를 현재 실행 중인 프로세스에서 다음에 실행할 프로세스로 넘겨주는 운영 체제의 모듈이다.

• Switching Context
  • CPU가 현재 실행 중인 프로세스(P0)의 상태(예: 레지스터 값, 프로그램 카운터 등)를 저장하고, 다음 프로세스(P1)의 이전 상태를 복원합니다.
• 유저 모드로 전환(Switching to User Mode)
  • 프로세스가 사용자 모드에서 실행될 수 있도록 CPU의 모드를 변경합니다.
• 적절한 위치로 점프(Jumping to the Proper Location)
  • 프로그램이 중단된 부분부터 계속 실행될 수 있도록 프로그램 카운터를 해당 위치로 설정합니다.

Dispatch Latency (지연)

한 프로세스(P0)를 중단하고 다른 프로세스(P1)가 실행을 시작하는 데 걸리는 시간을 의미한다.

🖥️ Scheduling Criteria

• CPU Utilization(CPU 이용률) : CPU가 얼마나 부지런히 일하는가. / 높을수록 좋은거임 (단위 : %)
• Throughput(처리율) : 시간당 몇개의 작업을 처리하는가. / 높을수록 좋은거임 (단위 : job/sec)
• Turnaround time(반환시간) : 작업이 메인메모리로 끝내고 나올때까지 걸리는 시간. / 짧을수록 좋은거임 (단위 : sec)
• Waiting time(대기시간) : CPU에서 서비스를 받기 위해 ReadyQueue에서 기다리는 시간. / 짧을수록 좋지 (단위 : sec)
• Response time(응답시간) : 컴퓨터와 대화하는 시스템에서 중요함. (요새는 다 맞긴함) / 짧을수록 좋음 (단위 : sec)

이제 곧 파드의 3기 iOS파트가 시시시시작이다.

세미나를 위해 OT 자료를 다시 살펴보던 중, 문득 누군가 이런 질문을 하면 어쩌지 하는 생각이 들었다.

Main이랑 Lauch 중 어디에서 해야돼요?

둘의 차이는 뭐죠?

.

.

정확하게 알려줘야 하기에 찾아보았다.

멀티 스레드를 원활하게 지원하기 위해 LauchStoryboard는 Android의 splash화면 같은 화면이었다.

그러니까, LauchStoryboard에 스플래시 화면을 넣어주면 된다는 것 !

.

.

Launch storyboard

Main storyboard

이렇게 각각을 지정해주었다.

그리고 빌드를 하면, 아마 Launch storyboard만 보여질 것이다.

이건 AppDelegate에서 Launch storyboard가 보여질 시간을 지정해주면 된다.

func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?) -> Bool {
    // Override point for customization after application launch.
    sleep(1)
    return true
}

이런식으로 sleep(1)을 추가해주면, 1초 뒤 Main 화면이 보이는 것을 확인할 수 있다.

두 번째 파트장을 하다 보니, 눈에 보이지 않던 것들이 하나씩 보여지기 시작한다.

.

.

아직 부족함이 많은 내가 파트장이라니,,

더 열심히 할게요 여러분..

.

.

끝