[SeSAC] August 15, 2023

✔︎ 오늘의 정리

• tableViewController에 만들어도 외부 xib 파일을 cell로 쓴다면 nib 연결은 해야 한다
• 뷰는 뷰, 데이터는 데이터, 각자 자신의 기능만!!!
• 직렬과 병렬, 동기와 비동기
• 왜 UI를 mainThread에서 update해야 할까?

 

 

---

tableViewController에 만들어도 외부 xib 파일을 cell로 쓴다면 nib 연결을 해야 한다

말그대로이다. 어제 밤이랑 오늘 헤맸던 게 ... 너무 허망해서 두 번 적었다.

원래 tableViewController에 만들면 nib 연결을 안 해줘도 ㄱㅊ지 않나? 했는데 그건!!!! tableViewController 내부의 cell 안에 기본 셀을 만들어 줬을 때 이야기이다.

외부 xib 파일로 셀을 만들게 된다면 꼭!!!! nib 연결을 해 주어야 제대로 동작한다.

사실 당연하다. 쩨기랄 그치만~~

 

 

그럼 tableViewController에 만든 거랑 viewController 위에 tableViewController를 올린 거랑은 무슨 차이일까?

UI적으로나 설계할 때나 특정 컨트롤러를 이용하여 만든 이유가 있겠지만, 아무튼 설계상에서 내가 기초적으로 무엇을 구현해 주어야 하느냐를 따졌을 때  tableView에 delegate와 dataSource 해 주어야 하냐 아니냐의 차이로 볼 수 있다. 

나는 여기에 nib까지 더해서인 줄 알았는데 완존 착각이었다.

nib은 외부 xib를 사용하게 되면 해당 tableView에 cell을 연결해 주는 과정이라 그랫는갑다...

 

기억하자. cellForRowAt에서 연결해 주는 것은 해당 cell과의 연결고리를 특정해 주고 내용을 넣어주는 것이고

viewDidLoad에서 nib을 register 해 주는 건 말 그대로 해당 셀을 tableView에서 사용하겠다고 등록해 주는 것이다.

 

일케 정리하니 지금껏 나는 왜 cell을 호출할 떄 nil이 나오지?!?! 했는데 사실 당연했다는 걸 깨닫는다...

 

당연함... 해당 셀을 사용하겠다고 등록을 안 했으니 어떤 셀을 부르는디? 하고 그냥 튕긴 것이었다.

 

머 이번에 헤맸으니 담부터 안 그러겠지

 

 

 

 

 

 

 

 

 

 

 

 

뷰는 뷰, 데이터는 데이터, 각자 자신의 기능만!!!

어제 에러를 해결하긴 했는데, 뷰에서 너무 많은 데이터를 해결한 거 같어서 ㅋㅋ 이넘을 어떻게 나누지?!?!?! 에 대한 고민이 많았다.

로엔에게 정말 많은 조언을 들었다.... ^_^ b

정말 멋진 분야.

 

뭔가 꾸준히 생각했던 거지만? 내 문제는 특정한 곳에서 너무 많은 일을 한다는 것이었다.

예를 들면, 데이터 구조체 안에 이미지 URL을 넣는다든가? 하는 것 같은 거 말이다. 

구조화를 하려고 나눴는데, 하다 보면 약간 주객이 전도되어 이 친구가 너무 많은 일을 하고 있는데?! 싶을 때가 있었다.

 

그런 나를 위한 해결책: 짤 때 이 친구가 어떤 일을 할지 정해둔 것을 주석으로 작성 후 그 친구는 그 일만 하게 하기.

 

자꾸 너무 많은 일들을 한 친구가 하고 있으니 과하게 복잡해 보이고 문제가 됐던 것 같다.

 

앞으로 조금 더 잘 나눠봐야겠음 ㄱ-

 

일단 코드를 와다닥 짜보고 구조화나 코드에 대한 지식이 더 필요하다! 싶으면 책을 읽어봐야겟당.

 

 

 

 

 

 

 

Serial과 Concurrent, Sync와 Async

Serial과  Concurrent는 하나의 Thread를 사용할지, 여러 Thread를 사용할지에 따라 나뉘어지며, Sync와 Async는 작업을 보내고 기다릴지 말지에 따라서 나뉘어진다.

 

Serial(직렬)의 경우에는 하나의 thread를 이용하여 순서대로 처리하는 것을 말하고,

Concurrent(병렬)의 경우에는 위 그림과 같이 여러 thread에서 동시에 task를 수행하는 것을 말한다.

 

 

 

 

 

 

 

Sync(동기)는 task를 main Thread에서 다른 Thread로 넘겼을 때, 그 일의 결과를 기다린 뒤 그 이후에 다음 일들을 처리하고,

Async(비동기)는 task를 main Thread에서 다른 Thread로 넘길 때, 그 일의 결과를 기다리지 않고 곧바로 다음 일을 처리한다.

 

동기의 경우에는 그 이후의 일이 task1의 결과물이 필요할 경우에 동기로 쓰이고,

비동기의 경우에는 서로가 서로에게 연관이 없을 때 주로 쓰는 것 같다.

 

 

 

정리하면 이렇다~!

 

 

SerialQueue.sync

메인 스레드의 작업 흐름이 queue에 넘긴 task가 끝날 때까지 기다리고 있음(sync)

넘겨진 task는 queue의 먼저 담겨 있던 작업들과 같은 스레드에 보내지기 때문에 해당 작업들이 모두 끝나야 실행(SerialQueue)

 

ConcurrentQueue.sync

메인 스레드의 작업 흐름이 queue에 넘긴 task가 끝날 때까지 기다리고 있음(sync)

넘겨진 task는 먼저 담겨 있던 작업들과 다른 스레드에 보내질 수 있기 때문에 해당 작업들이 모두 끝나지 않아도 실행(Concurrent Queue)

 

SerialQueue.async

메인 스레드의 작업 흐름이 queue에 넘긴 task가 끝나든 말든 일단 보내고 자기 일을 실행(async)

넘겨진 task는 queue에서 먼저 담겨 있던 작업들과 같은 thread에 보내지기 때문에 해당 작업들이 모두 끝나야 실행(SerialQueue)

 

ConcurrentQueue.async :

메인 스레드의 작업 흐름이 queue에 넘긴 task가 끝나든 말든 일단 보내고 자기 일을 실행(async)

넘겨진 task는 먼저 담겨 있던 작업들과 다른 스레드에 보내질 수 있기 때문에 해당 작업들이 모두 끝나지 않아도 실행(Concurrent Queue)

 

 

 

 

https://sujinnaljin.medium.com/ios-%EC%B0%A8%EA%B7%BC%EC%B0%A8%EA%B7%BC-%EC%8B%9C%EC%9E%91%ED%95%98%EB%8A%94-gcd-4-a621eca0a1d2

[iOS] 차근차근 시작하는 GCD — 4

https://jeong9216.tistory.com/514

[Swift] GCD(Grand Central Dispatch) - 1

https://www.zehye.kr/ios/2021/08/19/iOS_dispatch_group/

iOS Dispatch Group 사용해보기 · 지혜의 개발공부로그

 

 

 

 

 

 

 

 

왜 UI를 mainThread에서 update해야 할까?

사실 main에서 UI를 업데이트한다는 걸 듣고 글쿤. 하고 넘겼는데 문득 이런 글을 보게 돼서 헐... 왜 그렇지? 하고 홀린듯이 들어가게 되었다. 

해당 글은 요기 https://medium.com/@duwei199714/ios-why-the-ui-need-to-be-updated-on-main-thread-fd0fef070e7f

해석 자료는 요기 https://www.inflearn.com/news/40327

 

그러니까, 요약해 보자면

 

UIKit의 모든 속성은 Thread-safe하게 설계되어 있지 않다. 애초에, UIKit처럼 거대한 프레임워크를 Thread-safe하게 설계하는 건 비현실적이다. 만약 UIKit의 모든 속성을 Thread-safe하게 설계했다고 해도 동기적으로 여러 Thread에서 UI를 업데이트하게 된다면, 어느 곳에서는 셀이 만들어지지도 않았는데 해당 테이블뷰를 로드하려고 할 수도 있을 것이다. 이는 main에서 Serial(직렬)로 UI를 처리하는 것보다 훨씬 비효율적이며 위험하다.

 

main Runloop가 뷰의 업데이트를 관리하는 View Drawing Cycle을 통해 뷰를 동시에 업데이트 하는 설계를 통해 동작하고 있다. 하지만, 메인이 아닌 thread가 각자의 runloop로 뷰를 동시에 업데이트하는 설계를 하게 되면, 뷰가 원하는대로 동작하지 않을 수 있다.

-> 이 부분은 잘 모르겠다 ... ^_^

 

위와 같이 UIKit 아래에 UI를 그리는 렌더링 프로세스가 있다. 기존에는 위와 같은 animation 작업을 main에서 모두 수행한 이후에 GPU에 보내어 동작을 수행하는데, 만약 각각의 동작을 다른 thread에서 실행하게 된다면 GPU에 원래처럼 하나의 요청만 가는 게 아니라, 실행하는 작업만큼의 요청이 갈 것이다.

GPU는 각각의 정보를 모두 해석해야 하니 본래보다 느려지고, 비효율적이 될 수 있다.

 

 

 

 

 

 

 

 

 

 

 

14일 TIL을 좀 정리해 두고 올리지는 않았길래 내용을 더 보충해서 15일 TIL로 합쳐서 올린다.

생각해 보면 오늘 올리는 건 TIL이 아니라 YTIL 아냐?

어제 오늘 제가 공부한 거예요 .. ..

 

오늘 dispatch group도 정리하고 싶엇는데 정신 차려 보니까 지금 시간이라 택도 없을 거 같다

나는 지금껏 그냥 큐들이 어케 .. 끝나는 거 알려줄 수 없나?? 햇는데 그걸 해주는 친구가 dispatch group이엇을줄이야

엊그제의 충격이가시질않는다...

 

하 얼렁 자야댐 낼 절대 오프라인~~!!!!!

 

 

일단 생각했던대로 코드 수정하고...

제대로 나오면 DetailView까지 수정하고 싶엇는데

아니 디테일뷰수정안했네

미쳣나????

그냥 디테일뷰 누르면 쥐 사진이나 보여주면서 안녕하세요? 하게댐

 

안녕하세요?

 

 

 

하 .. ㅋㅋ 개념 정리하고 디테일뷰 수정해야지~~ ㅋㅋ 하고 미뤘다가

걍 디테일뷰 안한사람됏다

근데귀엽긴해서짱난다 . .

우리집쥐는왜케귀여운걸까

아무튼

내일 아침에 일직 가서 해야지... ^_^

 

 

내일 할 일

• 절 ㄷㅐ 오프라인 출석
• 메인뷰에서 데이터 받아온 거 반영
• 캐스팅 API codable로 구현해보기
  • 안되면 걍 alamofire로 하고 리팩 도전~~!