[향상]앱 데이터 캐싱

[QuaRang1225]

현재 앱 생명주기적으로 봤을 때 다음과 같은 로직이 사용됨

• 현재 아이메드 iOS앱은 새로운 화면 표시 시 그 화면에서 보여줄 데이터를 서버 API를 통해 요청하여 뷰에 표시함
• 하지만 화면 전환이 빈번한 앱 특성 상 많은 트래픽을 요구함
• 최대한 서버의 트래픽과 앱 내부의 네트워킹 요청을 줄이고자 캐싱기능을 추가할 예정

참고 https://www.youtube.com/watch?v=MQYb9S8QD4E

[QuaRang1225]

불필요한 네트워크 요청을 줄이기 위해 서버에서 받아온 response데이터를 캐싱하기로 함 여기서 두가지를 선택할 수 있음

NSCache

• 장점
  1. 시스템 메모리를 많이 사용하지 않게하고 다른곳에서 메모리를 사용할경우 캐시에서 아이템을 제거하여 관리해줌
  2. 쓰레드의 안전성
  3. NSMutableDictionary와 다르게 캐시의 키객체를 복사하지않아 메모리적으로 안전
• 단점
  1. 무조건 참조타입만 사용할 수 있다.(구조체의 경우 사용할 수 없음)

Dictionary

• 장점
  1. 값타입 데이터도 저장할 수 있다.
  2. 조금더 포괄적인 의미로 넓게 설계하여 사용할 수 있다.
• 단점
  1. 쓰레드의 불안전성
  2. 데이터 충돌을 방지하기 위한 코드 수 증가

위의 내용을 고려하여 현재 코드에서의 서버에서 받아온 데이터 타입은 모두 값타입(struct)이기 때문에 딕셔너리를 사용해서 데이터를 저장하는 방식을 채택하기로 결정

참고

https://kirkim.github.io/ios/2022/08/08/nscache.html

[QuaRang1225]

유저정보 앱 데이터 캐싱관련

• 앱에 로그인 혹은 토큰으로 인증을 진행할 경우 사용자 정보를 내부적으로 가지고 있음
• 기존엔 앱간에 서로 유저정보를 넘겨서 사용했음으로 매우 비효율적이며 뷰끼리의 의존성 문제가 존재했었음
• 처음에 인증정보를 받아온 뒤 싱글턴 인스턴에 저장을 해 필요한 뷰에서 해당 데이터를 사용할 수 있도록 수정
• 다만 주의할 점은 싱글턴 메서드 특성상 앱 생명주기에 따른 데이터 생성 및 확실하게 할 필요가 있음

[QuaRang1225]

다른 잇슈로 세분화하여 진행