DispatchQueue.main.async의 사용 위치와 방식에 따른 차이

DispatchQueue.main.async의 사용 위치와 방식이 다르며, 효율성 및 관리 측면에서의 차이점도 발생합니다.

첫 번째 함수에서는  DispathQueue.main.async 내에 UIView 변경을 담당하는 함수 configureData를 불러오고

두 번째 함수는 configureData 메서드에서 DispatchQueue.main.async 내에 UIImage 변경하는 요소를 넣었습니다. 

 

1. 첫 번째 함수에서의 DispatchQueue.main.async

private func getCommonData(contentId: String) {
    NetworkManager.shared.getCommonData(contentId: contentId) { [weak self] results in
        switch results {
        case .success(let items):
            if let randomElement = items.first(where: { $0.firstimage != nil }) {
                DispatchQueue.main.async {
                    self?.titleImageView.configureData(with: randomElement)
                }
            } else {
                print("No element with a non-nil firstimage found.")
            }
        case .failure(let error):
            print(error.localizedDescription)
        }
    }
}

 

특징 및 장점:

• UI 업데이트와 네트워크 결과 처리의 명확한 분리: 네트워크 호출 후 데이터를 처리하고, UI 업데이트가 필요할 때만 DispatchQueue.main.async에서 UI 작업을 처리합니다.
• UI 관련 코드를 최소화: UI 업데이트 코드가 비동기 작업 블록 안에서만 이루어지기 때문에, 네트워크 작업이 성공적으로 완료된 후에만 UI를 변경합니다. UI 작업의 범위가 작아집니다.

단점:

• 복잡한 UI 업데이트 로직이 필요한 경우: UI 업데이트가 여러 단계로 이루어지거나, 여러 곳에서 UI를 업데이트할 필요가 있을 때, 코드가 복잡해질 수 있습니다.
• UI 로직이 데이터 로딩 로직에 종속: UI 업데이트가 네트워크 로직에 묶여 있어, 두 로직이 분리되지 않고 관리 측면에서 유연성이 떨어질 수 있습니다.

 

 

2. 두 번째 함수에서의 DispatchQueue.main.async

func updateUI(with item: Item) {
    titleLabel.text = item.title
    if let imageUrl = item.firstimage, let url = URL(string: imageUrl) {
        DispatchQueue.global().async {
            if let data = try? Data(contentsOf: url) {
                DispatchQueue.main.async {
                    self.imageView.image = UIImage(data: data)
                }
            }
        }
    } else {
        imageView.image = nil
    }
}

 

특징 및 장점:

• UI 로직의 명확한 분리: UI 업데이트 로직이 별도의 함수에 캡슐화되어, 네트워크 결과를 단순히 받아서 이 함수를 호출하는 방식입니다. 이는 코드를 더 모듈화하고, 재사용성을 높입니다.
• 유연한 관리 가능: 여러 곳에서 동일한 UI 업데이트를 사용할 수 있고, 네트워크와 UI 로직이 서로 독립적이어서 코드의 유지보수가 용이합니다.

단점:

• 추가적인 비동기 처리: UI 업데이트를 위해 또 다른 비동기 블록을 실행해야 하므로, 상황에 따라 복잡성이 증가할 수 있습니다.
• 데이터와 UI 동기화의 잠재적 문제: UI가 네트워크 데이터와 동기화되지 않거나, 예상하지 못한 시점에 업데이트될 가능성이 생길 수 있습니다.

비교 및 권장 사항

• 효율성 측면: 첫 번째 방식에서는 UI 업데이트가 네트워크 결과와 직접 연결되어 있어 불필요한 비동기 작업을 줄일 수 있습니다. 이는 네트워크 작업이 성공적으로 완료된 후에만 UI를 변경해야 하는 경우에 효율적입니다.
• 관리 측면: 두 번째 방식은 UI 로직을 재사용 가능하고 명확하게 유지할 수 있는 장점이 있습니다. 네트워크와 UI 로직을 독립적으로 관리할 수 있어 코드의 유지보수와 확장이 용이합니다.

결론

• 간단한 UI 업데이트 및 네트워크 호출이 명확히 분리된 상황: 첫 번째 방식을 사용하는 것이 더 효율적일 수 있습니다. 네트워크 호출과 UI 업데이트가 명확하게 하나의 흐름에서 처리될 때 좋습니다.
• 복잡한 UI 업데이트, 재사용 가능한 UI 로직: 두 번째 방식을 사용하는 것이 더 유리합니다. 이 방식은 UI 로직을 독립적으로 관리할 수 있어, 여러 곳에서 동일한 UI 업데이트가 필요하거나 UI 로직을 여러 부분에서 재사용해야 할 때 효율적입니다.

프로젝트의 요구사항에 따라 적절한 방식을 선택하는 것이 중요합니다. UI 업데이트가 간단하거나 특정 상황에서만 발생하는 경우 첫 번째 방식을, 보다 유연하고 모듈화된 코드 구조가 필요한 경우 두 번째 방식을 선택하는 것이 좋습니다.