WWDC 2018 ) What's New in Cocoa Touch

안녕하세요 :) Zedd입니다.

WWDC에는 너무 매력적인 주제들이 많고........정말 다 공부하고싶네요. XD

그리고 아 너무 복잡해서 엄청나게 요약할겁니다. 너무 완벽하게 막 글을 쓰려는 압박감이;;;;;; 그러다보니 글을 쓸 수가 없네요;;

What's New in Cocoa Touch 

---

이번 업데이트의 세가지의 메인 카테고리가 있습니다.

- Framework update : Performance, Security등

- API 강화 : notification과 message를 포함한 다양한 API

- Siri shortcuts

● Framework update : 성능

세가지 영역에 대한 성능이야기를 이야기해봅시다.

- Scrolling

- Memory

- Auto Layout(오..)

들어가기전에 스크롤에 관한 약간의 배경지식을 알아야하는데요,

iOS에서 "스크롤"하는 것은 대부분의 상황에서 꽤 일반적인 패턴을 따릅니다.

우리가 스크롤하는동안 새로운것을 로드 할 것이 없으면 프레임을 생성하기는 정말 쌉니다.(cheap)

하지만 어떤 새로운 프레임이로드 될 때, 이 프레임은 다른 프레임보다 약간 더 비쌉니다. (expensive)

하지만 이 비싼 프레임을 로드하고 나서는 CPU에서 수행하는 작업의 양은 다시 작아지죠 == 위에서 말한 cheap.

그럼 저 새로운 프레임, 비싼 프레임(expensive frame)을 만들 때 도대체 어떤일이 일어나고 있는걸까요?

예시는 UITableView로 들겠지만, UICollectionView, 어떠한 Custom View도 동일하게 작동할겁니다.

자, 저 비싼 프레임 작업은 아마도 TableView의 delegate메소드인 cell For Row At index Path에서 시작할텐데요,

우리가 여기서 하고싶은 일은 우리가 표시하고 싶은 cell을 얻는것이죠. 

재사용 큐에서 재사용할게 있으면 그걸 쓰고, 없으면 만들어야 하기 때문에 메모리 할당을 할 수도 있겠죠.

cell을 디큐하거나 메모리에 할당하면 이제 cell에 데이터를 채워야겠죠?

이 cell에 데이터를 채우는 것은 app에 따라 비용이 다르게 메겨집니다.

파일 io, DB에서 데이터로드 등 값비싼 작업을 할 수 있겠죠.

자, 여기까지가 값비싼 작업의 끝~~~~이라고 생각 할 수 있겠죠.

하지만 실제로 cell을 화면에 표시할 준비가 되려면 더 많은 작업이 필요하답니다.

1. cell의에 있는 모든 컨텐츠를 배치(position)해야합니다. 

=> 이는 실제로 Text를 측정하는 것과 같은 다른 비싼 작업을 포함할 수 있기 때문에 우리가 소비하는 총 시간 중 상당 부분이 될 수 있어요.

일단 모든것이 적절하게 크기도 조정되고 배치되고...끝나면!

2. 그려야할 컨텐츠를 생성하고 해당 cell내의 모든 하위 view에 대해 draw Rect메소드를 호출해야합니다.

=> 여기서도 Text를 그리는 것과 같은 일을 하기 때문에 시간이 많이 걸릴 수도 있어요.

자ㅏ!!!! 전반적으로 이 코드 전체에서 많은 작업을 하죠? 근데......내가 부드럽게 스크롤을 하는 것 처럼 느끼려면 이 모든 작업이 정말 짧은 시간안에 끝나야해요.

60헤르츠 디바이스의 경우 프레임 drop이 일어나지 않게 하려면 이 모든 작업을 16ms안에 해야하죠.

12헤르츠 아이패드의 경우 오직 8ms의 시간밖에 없습니다. (프레임 drop이 안일어나려면)

이말이 머겠음;;;;

가능한 빨리 위 작업들을 완료해야 된다는 말이겠죠?

자, 위와같은 상황을 한번 볼게요. 밝은 파란색과 어두운 파란색은 우리가 변경한 프레임을 나타냅니다.

하지만 저 중간에 밝은 파란색이 두번 나왔죠?

그 말은 스크롤을 하는데, 프레임이 변경이 안되고;; 동일한 프레임이 그려졌다는 것을 의미합니다.

프레임이 변경이 되어야 하는데 왜 변경이 안되고 동일한 프레임이 그려졌냐??

cell Load가 실제로 프레임을 그려야하는시간 (16ms)보다 오래걸렸기 때문입니다. 어디서요? 위에서말한 레이아웃, drawing과정에서 말이죠.(==cellForRowAt)

자..이걸 어떻게 해결 할 수 있을까요? iOS10에서 cell prefetching API가 소개됐었죠? 이걸 사용하면 되지 않을까요?

위 그림을 보시면, Prefetch가 cell을 로드하는 것과 "동시에" 실행이 된 것을 볼 수 있어요. 

우리가 미래의 cell에서 필요할지도 모르는 데이터를 호출했지만, 이것이 현재 cell load와 동시에(concurrently) 일어나고 있죠.

이렇게 되면 CPU가 엄청 할일이 더 많아지겠죠? 위와 같은 상황은 결국 "두가지 작업 모두" 조금씩 더 오래걸리게 되었어요.

위 그림을 보시면 cell Load와 Prefetch가 동시에 실행이 시작되죠??! 그래서 이런 상황때문에 두가지 작업 모두 느려지는 결과가 생길 수 있었어요.

(세션에서는 CPU contention이라고 말하고 있습니다. 직역하면 CPU경합, 논쟁...CPU 경합은 가상화 된 하드웨어 시스템의 개별 CPU 구성 요소 및 시스템이 처리시에 너무 오래 기다리는 이벤트입니다. )

하지만!!!!!!!!!!!!

iOS 12에서 이러한 백그라운드 prefetch작업 스케쥴링이 훨씬 더 지능적(intelligent)이어서, 동시발생과 CPU 경합을 일으키지 않고, serially하게 실행되므로 현재 cell을 로드하는데 걸리는 시간이 단축될 뿐더러 많은 경우에 프레임이 떨어지는 것을 방지했다고 합니다 XD!!

위 그림을 보시면 저기 위에 그림과는 다르게, cell Load가 먼저 일어나고, 그 "다음에" Prefetch가 일어나는 걸 볼 수 있죠? 그러니 CPU경합도 일으키지 않을거고, 훨씬 빨라지겠죠!!!

개발팀(?)은 또한 앱을 프로파일링 하는 도중 프레임이 드랍이 일어나는 또다른 사례를 발견했다고 해요.

background작업은 없고, 그냥 단순히 "스크롤"을 할 뿐인데 말이죠.

이건 정말 말도 안되지 않나요? 

저 빨간 언덕이 프레임 드랍을 일으키는 부분인데요, 이 언덕이 높아질 때는 이미 표시해야할 cell을 적재하기 위해 작업을 완료하기에는 이미 늦은 시간입니다. 그래서 프레임 드랍이 일어난거죠.

iOS 12에서는 스크롤이 발생하는 시점 및 critical section이 발생하고 있을 때, 그 정보를 저수준 CPU 성능 컨트롤러로 전달하여, 현재 일어나고 있는 작업에 대해 훨씬 더 지능적으로 추론 할 수 있도록 UIKit프레임워크에 있는 모든 정보를 가져왔어요. 이로인해 CPU는 훨씬 더 자주, 훨씬 더 빨리, cell을 디스플레이 하는데 늦지 않을려고 ( 프레임 드랍을 발생하지 않도록 하려고 ) CPU는 부하가 발생되게되었죠.

이 때문에 iOS에서 관련된 여러가지 다양한 스크롤 시나리오에서 큰 개선이 이루어졌다고 해요 :)

그래서 하고싶은 말은, tableView / CollectionView cell prefetching API를 아직 채택하지 않았다면, 꼭 한번 보는것을 추천한다.

하지만 물론, Cell Load가 하는 양을 가능한 한 많이 줄이는 것이 중요.

다음은 메모리₩~

여러분 다들 공감하시죠?

메모리는 성능이다!!!!!!!!!!!!!!!!!!!!!!!

앱이 사용할 메모리가 많을수록 앱 성능에 더 많은 영향을 미칩니다. 

iOS 12에서는 Automatic Backing Stores이라는 새로운 기술이 생겼는데요, 앱의 메모리 사용을 줄이는데 도움이 되는 기능이라고 해요.

한가지 예를 살펴보도록 합시다.

우리가 아이폰X에서 portrait 모드로 이 귀여운.............prairie dog를 그린다고 생각해봅시다. (제가 그리는건 아니고 시스템이 이 prairie dog를 그려서 표시하는데..라고 생각하시면 될듯)

가로세로 비율을 유지하려면, 가로 375pt, 세로 250pt가 필요하며 아이폰X은 3x를 쓰니 픽셀당 64비트를 씁니다. 즉, 이 prairie dog를 그리는데 2.2MB의 메모리가 필요합니다.

그렇다면 제가 이 prairie dog를 따라 그린다고 생각해볼게요.

진심 개대충 발로 그렸지만 왼쪽의 prairie dog와 정확히 같은 메모리를 사용합니다.

왼쪽은 색깔도 있고. 진짜 같고...그런데 오른쪽은 무슨 색깔도 없고 검정색이랑 회색만 써놓고 무슨 prairie dog같지도 않은데 말이죠...

암튼 이랬는데!!!

iOS12에서는 Automatic Backing Stores라는 기술을 도입하였습니다!!!

이제 drawRect로 구현한 모든 View에는 그려진 내용의 depth에 따라 정의된 backing stores를 가집니다. 

따라서 Core Graphics를 사용하여 grayscale content만 스케치 하는 경우( 위 그림에서 오른쪽과 같은 경우), 실제로 픽셀 당 64비트 대신!!! 대신!! 8비트 픽셀 backing store 가 자동으로 사용됩니다.

그러면~~~

275KB....대박적...이죠...

단위가 줄어든..!!

별거 아닌거 같아 보이지만...이것은 정말 큰 개선이라고 볼 수 있어요.

이 Automatic Backing Stores는 iOS12 SDK로 제작된 모든 앱에 사용되며, 

위와같은 애들은 이제 기본적으로 Automatic Backing Stores를 사용하게 됩니다.

그리고 AutoLayout!

오토레이아웃은 iOS10에서도 큰 개선이 있었는데요, iOS12에는 기본적으로 오토레이아웃이 더!! 빨라졌습니다.

superView안에 있는 view들이 서로 독립적일때. 

흠..밸루.. 

저 그래프의 Y축은 비용이라고 보시면 될 듯? X축은 view개수

이걸 뭐라 번역해야하지, sibling view들이 서로간에 제약이 있을 때!

오옹

iOS12가 좋아진게 아니라 iOS11이 너무 안좋았던거 아닐까요???애플>???

iOS11에서는 view가 많으면 많을수록 exponentially하게 비용ㅇ이...증가하는 것을 볼 수 있습니다. 

하지만 iOS12에서는 알고리즘을 수정해서 이제 linearly하게 비용이 증가됩니다.

view안에 view안에 view안에 view안에....

이러한 상황은 우리의 앱에서 꽤 흔한 상황이죠. ㅋ.ㅋ.ㅋ.ㅋ.ㅋ.ㅋ...

다시한번 말하지만 iOS11이 너무 안좋았던거 아닐까요>???? 애플?????

아무튼 이것도 선형으로 만듬ㅎㅎ

애플짱!!!!ㅎㅎㅎㅎㅎ

암튼 걍 봐도 오토레이아웃이 상당히 좋아진 것을 볼 수 있습니다. 

그리고 이제 프레임워크 업데이트 ㄱㄱ

iOS12에서, Swift 4.2를 소개합니다.

UIKit이 다른 Swift Standard Library와 함께 사용될 때 좋은 느낌(great feel)을 느끼게 해주고 싶었오!!!!

그래서 모든 UIKit을 감사(audited, 회계감사 할 때 그 감사임)했고, 모든것이 자연스럽게 맞는지 확인해씀

그리고 UIKit에 대한 모든 변경 내용이 자동으로 마이그레이션 되므로, 이러한 업데이트를 얻기위해서 추가작업이 필요없는 부분ㅇㅇ

일단 Nesting에 대해서 이야기 해봅시다.

Swift4에는 UI Application State와 같이 global name space에 있는 많은 타입이 있는데요.

이것을 관련 클래스의 하위 타입으로 이동했다고 해요.

자연스럽죠? 뭔느낌을 원한건지 알 것 같은..

둘 사이의 관계에 대해 훨씬 더 강력한 메세지를 보내고, 이해력도 높히고, 혼란도 없애는데 도움이 될거얌.

UIKit전체에 있는 모든 전역 상수를 적절한 위치에 중첩했다고 해요.

이런것도 바뀌었는데요, Swift4에서 뭔가 구구절절한 느낌이라면...

Swift4.2에서는 뭔가 딱!!! 딱!!! 뭔가 뭔가 자연스러운 느낌??? 뭔가 당연히 이래야 할 것 같은 느낌ㄴ/!?!? 

png데이터를 얻기위헤ㅐ서 UIImagePNGRepresentation파라미터에 우리의 이미지를 넣는다...는 것보다 이미지에서 png데이터를 주는 메소드를 호출하는게 더 뭔가 더 자연스럽잖아요!?!?!?!? 아무튼 ㅇㅣ런 느낌을 주기위해서 엄청나게 노력한 것 같음

애플짱!!!!

iOS12에서는 새로운 secure 인코딩 및 디코딩 API가 추가되었다고해요. 

이후에 뭐 알림이나 단축어 등 많이 이야기하는데 하다가 내가 왜 이걸 하고 있나 라는 생각이 들어 그만 씁니다.

이러한 종류(?)의 WWDC세션 공부는 정리하는게 의미가 없네여ㅛ 재미도 없음 ㅠ

Swift성능 이해하기 정도는 되어야............재밌음ㅎ

사실 이 글같은 경우에는, WWDC가 끝난 직후에 쓰기 시작했는데 너무 완벽하게?? 글을 쓰려다 보니 엄청 미뤄지고 시간도 없고..그래서 한번 엎고... 지금에서야 발행하네요.

그리고 여러분 제 글이 잘 읽히시나요? 

저는 정리를 하면서 공부를 하면 더 잘되고? 잘 기억하고?..잘 이해하고??..암튼 그래서 겸사겸사 블로그에 정리해서 올리는...데

항상 글을 쓰고 나서..이 글을 처음보는 사람의 입장으로 글을 한번 쫙 다 읽어보는데

Swift성능 이해하기 글이 잘 이해가 안갈수도 있겠다..싶더라구요

물론 볼 사람들은 보고 안볼 사람들은 안보겠으니 이런 걱정?은 의미가 없지만...

암튼 그런생각이 들어서...!!! 그냥 말해범

남은 연휴 잘 보내시고 행복한 하루 되세요.