IOS에서의 싱글 톤 사용 및주의해야 할 점

Question

다음 클래스와 비슷한 firebase와 상호 작용하기 위해 싱글 톤을 아주 광범위하게 사용 해왔다. 싱글 톤을 매우 편리하게 사용할 수 있으므로 사용하기 전에 먼저 더 많은 통찰력을 얻고 싶다. 온라인 과정의 강사 중 한 명은 싱글 톤 사용에 대해 매우주의해야한다고 언급했지만 실제로 이유는 설명하지 않았습니다. 나는 그것을 올바르게 사용할 수있는 방법을 알고 싶습니다. 왜 그것을 사용하는데 매우주의해야합니까?

class DataService { 
static let dataService = DataService() 

private var _BASE_REF = Firebase(url: "\(BASE_URL)") 
private var _USER_REF = Firebase(url: "\(BASE_URL)/users") 
private var _JOKE_REF = Firebase(url: "\(BASE_URL)/jokes") 

var BASE_REF: Firebase { 
    return _BASE_REF 
} 

var USER_REF: Firebase { 
    return _USER_REF 
} 

var CURRENT_USER_REF: Firebase { 
    let userID = NSUserDefaults.standardUserDefaults().valueForKey("uid") as! String 

    let currentUser = Firebase(url: "\(BASE_REF)").childByAppendingPath("users").childByAppendingPath(userID) 

    return currentUser! 
} 

var JOKE_REF: Firebase { 
    return _JOKE_REF 
} 

또한, 나는 또한 아래 그림과 같이 또 다른 싱글을 (내가 조금 더 먼저 이해하는 것이 원하는대로 나는 아직 작성하지 않은)을 만들려고하고있다. 이러한 "게시물"은 여러 VC에서 액세스 할 수 있습니다. 그 이유는 모든 VC가 충돌을 일으키지 않고 필요한 배열에 액세스 할 수 있도록 싱글 톤을 사용하려고했기 때문입니다. 일반적으로, 이런 종류의 설치에주의해야 할 사항이 있습니까?

죄송합니다. 약간의 문제 일 수 있습니다. 그러나 아이디어는 내가 아는 한 (?? 메모리 할당, 타이밍)이 구체적인 예에서 싱글 톤을 사용하여

class PostService { 

static let ps = PostService() 

private var _myPosts = [Post]() 
private var _otherPeoplesPosts = [Post]() 
private var _followingPosts = [Post]() 

var myPosts: [Post] { 
    return _myPosts 

} 

var otherPeoplesPosts: [Post] { 
    return _otherPeoplesPosts 
} 

var followingPosts: [Post] { 
    return _followingPosts 
} 

Answer 1

을보고 무엇에 대한 개요를 얻을 수 있습니다, 싱글에 대한 유일한 주요 문제는이다 당신이 그것을 사용하든 사용하지 않든 그들이 기억에 남아 있다는 사실.

첫 싱글 톤은 정적 함수가있는 구조체로 쉽게 대체 될 수있는 것처럼 보입니다.

설명 중 하나에서 언급했듯이 개체가 힙에 없기 때문에 (일종의 CoreData가 아닌) 일종의 저장소 (즉 CoreData)를 사용하면 더 좋을 것입니다. 배열이 수십 개의 개체로 이루어져 있다면 문제가되지 않지만 모든 배열에 수백 개의 개체가 있다고 상상해보십시오. 물론 앱의 어느 곳에서나 액세스 할 수 있지만 단점은 메모리 사용량이 매우 높다는 것입니다.

CoreData를 사용하지 않고 프로젝트에 통합하는 것이 문제가 될 경우 문서 폴더에 데이터를 저장하고 메모리에있는 객체의 수를 제한하는 것이 좋습니다. 배열에없는 객체를 문서 폴더에서로드하고 마지막으로 사용한 객체를 바꿉니다 (CoreData와 비슷합니다). 이상적인 것이 아니고 강렬한 논리가 필요하지만 힙에 너무 많은 객체를 가지고 메모리 경고를 발생시키는 것보다 낫습니다.

결론은 데이터의 용도와 크기에 따라 다릅니다.

희망은 어떤면에서 도움이 될 것입니다.