컬렉션을 사용해 정리하기
내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요.
Google Play 게임즈 C++ SDK
요약
조직
Play 게임즈 서비스 기능의 기본 진입점은 GameServices 클래스입니다. GameServices 인스턴스는 GameServices::Builder로 생성됩니다. GameServices를 참고하세요.
전체 GameServices 세션의 상태에 액세스하거나 이를 변경하는 메서드는 GameServices 클래스 자체에 있습니다.
다른 기능은 기능별 관리자 집합을 통해 간접적으로 제공됩니다. 이러한 관리자는 관련 기능을 그룹화합니다. 여기에는 사용자가 볼 수 있는 상태가 없습니다. Manager는 참조로 반환되며 포함된 GameServices 인스턴스에 의해 수명이 제어됩니다. 따라서 클라이언트 코드는 관리자 참조를 보유해서는 안 되며 대신 GameServices 인스턴스를 보유해야 합니다. 관리자를 참고하세요.
데이터는 변경할 수 없는 값 유형 객체를 통해 반환됩니다. 이러한 값은 쿼리가 실행된 시점에서 기본 데이터의 일관된 뷰를 반영합니다. 값 유형을 참고하세요.
스레딩 모델
달리 명시되지 않는 한 모든 GameServices 메서드와 Manager 메서드는 스레드로부터 안전하고 비동기식입니다. 외부 잠금 없이 모든 스레드에서 호출될 수 있으며 호출 순서와 일치하는 순서대로 실행됩니다. 일반적으로 뮤테이터 메서드 (상태를 변경하는 메서드)는 파이어 앤 포겟 모델을 사용합니다. Accessor 메서드(상태를 읽는 메서드)에는 두 개의 주요 변형이 있습니다. 첫 번째 변형 (GetProperty와 같은 이름)은 제공된 콜백에 비동기적으로 결과를 제공합니다. 두 번째 변형 (GetPropertyBlocking과 같은 이름)은 호출 스레드에 동기적으로 결과를 반환합니다. 접근자는 이전에 호출된 모든 변형자의 결과를 확인할 수 있지만, 변형자가 특정 시점에 원격 게임 서비스 상태를 수정했을 수도 있고 수정하지 않았을 수도 있습니다.
모든 사용자 콜백 (액세스 메서드의 인수로 제공되는 일회성 콜백이든 GameServices 빌드 시간에 구성된 다중 사용 콜백이든)은 전용 콜백 스레드에서 호출됩니다. 이 스레드는 '기본 스레드' 또는 'UI 스레드'의 플랫폼 개념과 다를 수 있습니다. 콜백 스레드가 중단되면 로그아웃 요청 완료 지연과 같이 사용자에게 보이는 문제가 발생할 수 있으므로 사용자 콜백은 빠르게 실행되어야 합니다.
변경 불가능한 값 유형의 속성은 차단 없이 동기식으로 사용할 수 있습니다.
이 페이지에 나와 있는 콘텐츠와 코드 샘플에는 콘텐츠 라이선스에서 설명하는 라이선스가 적용됩니다. 자바 및 OpenJDK는 Oracle 및 Oracle 계열사의 상표 또는 등록 상표입니다.
최종 업데이트: 2025-07-27(UTC)
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["필요한 정보가 없음","missingTheInformationINeed","thumb-down"],["너무 복잡함/단계 수가 너무 많음","tooComplicatedTooManySteps","thumb-down"],["오래됨","outOfDate","thumb-down"],["번역 문제","translationIssue","thumb-down"],["샘플/코드 문제","samplesCodeIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-07-27(UTC)"],[],[],null,["# Google Play Games C++ SDK\n=========================\n\nSummary\n-------\n\nOrganization\n\nThe main entry point for Play Game Services functionality is the GameServices class. GameServices instances are created with GameServices::Builder. See [GameServices](/games/services/cpp/api/other/classgpg_1_1GameServices)\n\nMethods that access or mutate the state of the entire GameServices session live in the GameServices class itself.\n\nOther functionality is indirected through a set of per-feature managers. These managers group related functionality together; they contain no user-visible state themselves. Managers are returned by reference, and have lifetime controlled by the containing GameServices instance. As such, client code should never hold onto a manager reference, but instead hold on to the GameServices instance. See [Managers](/games/services/cpp/api/other/group__Managers).\n\nData is returned via immutable value type objects. These values reflect a consistent view of the underlying data at the point in time the query was made. See [Value Types](/games/services/cpp/api/other/group__ValueType).\n\nThreading Model\n\nUnless otherwise noted, all GameServices methods and Manager methods are threadsafe and asynchronous. They can be called on any thread without external locking, and will execute in an order consistent with their invocation order. In general, mutator methods (those that change state) use a fire-and-forget model. Accessor methods (those that read state) come in two major variants. The first variant (with names like GetProperty) asynchronously supply their results to a provided callback; the second variant (with names like GetPropertyBlocking) synchronously return their results to the calling thread. Accessors see the results of all mutators that have been called prior; however, the mutator may or may not have modified the remote Game Services state at any given time.\n\nAll user callbacks (whether one-shot callbacks supplied as arguments to accessor methods, or multi-use callbacks configured at GameServices build time) are invoked on a dedicated callback thread. This thread is potentially distinct from any platform concept of a \"main thread\" or \"UI thread\". User callbacks should execute quickly, as a stalled callback thread can cause user-visible issues (for example, delayed completion of a sign-out request).\n\nProperties on immutable value types are available synchronously and without blocking."]]