-
Notifications
You must be signed in to change notification settings - Fork 1
Description
WWDC18 영상.
어떻게 하면 iOS 앱을 좀 더 멋지게 만들 수 있을까에 대한 키노트로, 다음 6가지 주제로 진행됐다.
- External Display Support
- Layout-Driven UI
- Laser-Fast Launches
- Smooth Scrolling
- Continuing with Continuity
- Debugging Like a Pro
External Display Support
아이폰을 외부 모니터와 연결했을 때, 아무 설정이 안 된 앱은 다음과 같이 단순히 아이폰 화면 그대로를 미러링합니다.
이는 외부 모니터의 광활한 크기를 낭비하는 것입니다.
이런 식으로 외부 모니터를 낭비하지 않고 잘 활용할 수 있습니다.
외부 모니터를 잘 활용하는 좋은 예시중 하나로는 키노트 앱이 있습니다.
외부 모니터와 연결된 아이폰에서 키노트 앱을 키면 외부 모니터에는 키노트 발표자료가 나오고, 아이폰 화면에는 발표 자료의 순서와 발표 메모가 나타나게 됩니다.
또는, 위와 같이 게임에서 사용할 경우 외부 모니터에는 게임 화면을, 아이폰이나 아이패드에는 조작 버튼만 보여줄 수 있겠죠.
UIScreen은 기기를 포함한 모든 연결된 디스플레이의 리스트를 포함하는 screens라는 변수가 있어서, 위와 같이 screens의 count가 1을 초과하는지를 판별하면 외부 디스플레이 연결 여부를 알 수 있습니다.
UIKit은 외부 디스플레이와 관련하여 위와 같은 notification을 제공합니다.
이를 통해 우리는 외부 디스플레이가 연결됐을 때, 그리고 해제됐을 때를 알 수 있습니다.
이 notification을 이용하면 적절한 타이밍에 외부 디스플레이가 연결됐을때의 UI로 변경하거나 원래 UI로 되돌릴 수 있겠죠.
외부 디스플레이는 UIScreen.screens의 마지막 요소로 추가되게 됩니다. 해당 요소를 담는 로컬 변수를 만듭니다.
외부 디스플레이가 미러링하지 않고 새로운 뷰를 표시하도록 하기 위해 외부 디스플레이에 보여질 새로운 UIWindow를 만듭니다.
그리고 새로운 UIWindow를 표시할 screen으로 외부 모니터의 screen인 externalScreen을 대입합니다.
그리고 외부 디스플레이에 표시할 뷰컨트롤러를 만들어서 externalWindow와 연결합니다.
여기서는 추상화가 되어 있지만 대충 뷰컨트롤러의 Window로 externalWindow를 선택하게 만든 코드라고 보시면 됩니다.
마지막으로, 외부 모니터에 화면이 보여야 하니까 isHidden을 false로 해줍니다.
만약 외부 모니터 연결을 해제하게 되면 정말 간단하게 externalWindow를 숨기고, 리소스를 없애기 위해 externalWindow에 nil을 대입해주면 됩니다.
그럼 외부 모니터 연결시 기기 화면 코드는 어떻게 될까요?
아이폰에서는 사진을 선택하는 CollectionView가, 외부 모니터에는 선택된 사진을 보여주는 예시를 한 번 살펴봅시다.
먼저 외부 모니터가 없을 때에는 사진을 선택하면 내비게이션 push로 선택된 사진 화면으로 이동합니다.
그런데 외부 모니터가 연결되면 아이폰에서는 단지 사진 선택만 이루어지므로 내비게이션 push 코드가 사라집니다.
Laser-Fast Launches
레이쟈만큼-빠른-실행
사용자가 앱 아이콘을 누르고 앱을 즐기기 전까지 거쳐야 하는 단계가 있습니다. 무엇일까요?
바로 앱 실행입니다.
앱 실행이 끝나고나서야 사용자는 비로소 앱을 즐길 수 있게 됩니다.
앱 실행은 위와 같은 5가지의 단계로 이루어집니다.
각 단계가 무엇이고, 빠른 앱 실행을 위해 어떤 최적화를 해야 하는지 알아보겠습니다.
Process Forking
Peter, what can we do in this phase of the launch? Well, for process forking, it's really complicated. You're going to want to read the Man pages for fork and exec, and familiarize yourself with POSIX fundamentals. No, no, I'm just kidding. iOS will take care of process forking for you.
이 단계는 iOS가 알아서 해주니까 무시해도 됩니다.
Dynamic Linking
- 실행에 필요한 메모리 할당
- 라이브러리와 프레임워크 연결
- swift등등 초기화
- static object 초기화
→ 일반적인 앱의 실행 시간의 40~50%를 차지합니다! 따라서 여기서 최대한 최적화를 합시다.
그런데 이 단계에서는 어떠한 코드도 실행되지 않습니다. 그러면 이 단계를 어떻게 최적화 해야 할까요?
-
avoid code duplication wherever possible.
쓸모없는 함수, 객체, 구조체가 있다면 제거하세요.
-
써드파티 라이브러리 수를 최대한 줄이기
iOS 퍼스트파티 라이브러리는 캐시 처리되어 있어서 만약 다른 앱에서 해당 퍼스트파티를 쓰고 있다면, 메모리 안에 존재합니다.
반면에 써드파티 라이브러리는 캐시되지 않기 때문에 다른 앱에서 동일한 라이브러리를 사용하고 있더라도 프레임워크에 넣어야 합니다. 따라서 써드파티 라이브러리 사용은 최소한으로 하세요.
-
static initializer 피하기.
static initializer는 앱에서 실제로 쓰이기 이전에 실행되어야 하기 때문에 꼭 필요하지 않다면 피하세요.
UI Construction
-
뷰컨트롤러 빌드처럼 UI를 준비하는 단계
-
상태 복구가 일어남.
앱이 마지막으로 종료된 화면(상태)를 복구하는 기능.
모든 앱에서 일어나는게 아니라, app state restoration을 설정한 앱에서만 일어남.
-
설정 로딩
-
앱이 실행되는데 필요한 모델 데이터 로딩
→ 이 단계를 최적화하려면?
-
appDelegate의 세 메서드의 return을 최대한 빨리 일어나게 하세요.
이 세 메서드가 반환되어야 UIKit이 비로소 앱을 active 상태로 두기 때문입니다.
-
앱이 실행되는 동안 파일 쓰기가 일어나지 않도록 해야 합니다.
-
당연한 얘기지만, 로딩하는 데이터셋 크기도 적당하게 유지해야 합니다.
- 앱 실행 당시에 꼭 필요한 데이터만 로딩하는 것을 추천!
-
DB hygiene 체크 → good idea to stay clean
- CoreData같은 라이브러리를 사용한다면, schema를 최적화하자.
- SQLite같은 own solution을 사용한다면, 앱 업데이트때마다와 같이 주기적으로 데이터베이스를 비워주는 것을 추천합니다.
First Frame
- 첫 프레임을 만드는 단계.
- Core Animation이 첫 프레임을 만들기 위해 필요한 모든 렌더링을 합니다.
- 텍스트를 그리고,
- 이미지를 로딩하고 압축해제합니다.
- 첫 화면에서는 정말 필요한 UI만 넣으세요.
- 예를 들면 내비게이션 이동이나 스크롤로 나타날 다음 화면은 로딩되지 않게, 나중에 lazily하게 로딩되도록 하세요.
- 뷰나 레이어가 숨겨져 있어도 코스트가 들기 때문에 숨겨놓는것도 피하세요.
Extended Launch Actions
앱의 실행을 빠르게 하기 위해 실행 단계에서 연기된 태스크가 이루어지는 단계입니다.
따라서 이 단계에서는 앱이 실행되기는 했지만, 아직 사용할 수 있는 상태는 아닙니다.
- 실행될때 보여져야할 콘텐츠에 우선순위를 설정하세요.
- 원격 서버에서 데이터를 가져와서 표시해야되는 경우, 인터넷이 느릴 경우를 대비하세요. 스켈레톤뷰 같은 플레이스홀더 UI를 두는것을 추천합니다.
ABM(Always Be Measuring)
Xcode의 Product > Profile을 누르거나 단축키 cmd+i를 누르면 나오는 창.
여기 있는 도구로 많은 것을 측정할 수 있는데, 특히 앱 실행 시간을 측정할 수 있습니다.
따라서 반복 측정을 통해 앱 실행 시간을 줄여나갑시다.


























