In Capgo 에서 3 가지 값이 계산되고 이해하는 것이 중요합니다.
- 사용자
- 저장소
- 대역폭
각각은 계산 방식이 약간 다릅니다.
사용자
사용자가 Capacitor JS 앱을 다운로드하고 열 때, Capgo 백엔드에 업데이트가 필요한지 확인하는 요청을 보냅니다.
앱이 그렇게 할 때, 작은 정보를 포함하여 가장 중요한 정보를 보냅니다. DeviceID
DeviceID: 사용자 기기에서 생성된 고유 ID (UUID)입니다. 버전 v5.10.0, v6.25.0 및 v7.25.0부터 시작하여, 이 ID는 앱 재설치 시 지속됩니다 (기기 저장소에서 안전하게 저장됩니다). 이전 버전까지는 앱 설치 시 ID가 초기화되었습니다.각각의 사용자 계정에서 새로운 기기 ID가 저장됩니다.
기존 기기 ID가 있는 사용자가 앱을 열 때, 기존 기록이 업데이트됩니다 (업데이트 시간이 데이터베이스에 저장됩니다).
버전 v5.10.0, v6.25.0 및 v7.25.0부터 시작하여, 이 ID는 앱 재설치 시 지속됩니다 (기기 저장소에서 안전하게 저장됩니다). 이전 버전까지는 앱 설치 시 ID가 초기화되었습니다. DeviceID 각각의 사용자 계정에서 새로운 기기 ID가 저장됩니다.
기존 기기 ID가 있는 사용자가 앱을 열 때, 기존 기록이 업데이트됩니다 (업데이트 시간이 데이터베이스에 저장됩니다).
이 데이터는 2 곳에 저장됩니다:
- 기기 표에
update_at값 - app_stats에 일일 카운터가 포함되어 있으며, 오늘 활성화된 기기 수와 이 달에 활성화되지 않은 기기 수를 나타냅니다.
계획 제한을 위해 첫 번째 방법이 사용됩니다. 차트를 표시하기 위해 두 번째 방법이 사용됩니다. 계정의 홈 페이지에서 두 개를 모두 확인할 수 있습니다:
- 차트에서 사용하는 것은 두 번째 방법
- 앱의 표에서 사용하는 것은 첫 번째 방법
Capgo don’t count emulator and dev build in your usage. Keep in mind after the trial you can’t have more than 3% of them, or that will lock your account, until you fix it.
Capgo is also doing some filtering for you. If you have CI/CD configured to send your version to Google PLAY, Google is running your Capacitor app each time to 20+ real device. During the 4 first hours of a new bundle, we block Google data center IP to prevent them to being counted.
매월, 이 데이터는 0으로 시작됩니다.
- 기기 요청마다 내 데이터베이스에 기기를 생성하거나 업데이트합니다.
- 이 달에 활성화되지 않은 기기 수를 포함한 일일 카운터에 활성화된 기기 수를 추가합니다.
첫 번째 방법은 다음과 같은 값을 반환합니다: 900명 이상의 사용자 두 번째 방법은 계정에 200명 이상의 사용자가 있습니다 계획 제한을 위해 첫 번째 방법을 사용하고, 차트를 표시하기 위해 두 번째 방법을 사용합니다. 계정 홈 페이지에서 둘 다 볼 수 있습니다.
저장소
bundle을 업로드할 때마다 이 숫자는 업로드 크기에 따라 증가합니다.
업로드 크기에만 관련된 데이터입니다. 앱 크기가 좋을수록 계획에 더 잘 맞습니다.
계획 제한에 도달하거나 근처에 도달하면 CLI에 있는 bundle 목록을 확인할 수 있습니다:
npx @capgo/cli@latest bundle list
bundle을 삭제하면 저장소가 해제되지만 stat은 삭제되지 않습니다.
bundle을 삭제할 준비가 되면 여러 bundle을 삭제하는 명령어를 사용하세요:
npx @capgo/cli@latest bundle cleanup
PS: 이건 지구를 위한 것이지만 당신의 지갑에도 좋습니다.
업로드 크기를 사용하여 저장소를 사용하고 계획에 포함되지 않도록 할 수 있습니다.
--external대역폭
이 값의 계산은 저장소와 조금 더 복잡하지만 아이디어는 같습니다.
대역폭
사용자가 각 번들을 다운로드할 때마다 이 숫자는 다운로드 크기에 증가합니다.
다운로드 크기와 관련된 데이터만이 제공되며, Capacitor JS 앱 크기가 좋을수록, 계획에 남아있는 기간이 길어집니다.
Capgo는 다운로드한 크기를 알 수 없으며, 번들의 크기만을 볼 수 있습니다. 따라서 큰 번들을 다운로드하는 사용자가 많다면, 제한을 빨리 초과할 수 있습니다.
계획에 남아있는 기간을 길게 유지하려면, 번들이 작아야 합니다. 만약 그렇지 않다면, 사용자에게 다운로드 중인 크기를 알려주고, 다운로드할 수 있는 크기를 알려주어야 합니다.
Capgo는 향후 다운로드 시스템을 개선하여 한 번에 다운로드할 수 있는 기회를 더 많이 제공할 것입니다.
Capgo에서 사용하는 다운로드 방법에 대한 설명을 계속 읽으세요.
__CAPGO_KEEP_0__를 사용하여 Capgo __CAPGO_KEEP_0__를 사용하여 Capgo Live Updates Capgo Live Updates 번들이 작고 __CAPGO_KEEP_0__ Live Updates를 사용하여 제품 워크플로우를 연결하세요. 구현 세부 정보에 대한 Overview에서 기능 기능에 대한 구현 세부 정보에 대해 업데이트 동작 구현 세부 정보에 대한 업데이트 동작 및 업데이트 유형 기사 기여
