Capgo에서는 3가지 값이 중요하게 계산되고 이해되어야 합니다
- 사용자
- 스토리지
- 대역폭
각각은 약간 다른 방식으로 계산됩니다
사용자
사용자가 Capacitor JS 앱을 다운로드하고 열 때마다 업데이트가 가능한지 확인하기 위해 Capgo 백엔드로 요청을 보냅니다.
앱이 이를 수행할 때, 가장 중요한 정보인 DeviceID를 포함한 작은 정보를 전송합니다.
DeviceID: 기기에서 생성된 고유 ID(UUID)입니다. 플러그인 버전 v6.25.0 및 v7.25.0부터, 이 ID는 이제 앱 재설치 후에도 유지됩니다(기기 저장소에 안전하게 저장됨). 이전 버전에서는 앱을 설치할 때마다 ID가 재설정되었습니다.
계정이 새로운 Device ID를 받을 때마다 데이터베이스에 저장됩니다.
이전 DeviceID가 업데이트를 요청할 때마다(앱 열기), 해당 기록이 업데이트됩니다(데이터베이스의 updated_at).
이 데이터는 2곳에 저장됩니다:
update_at값이 있는 device 테이블- 오늘 활성화되고 이번 달에 활성화되지 않은 기기 수를 나타내는 일일 카운터가 있는 app_stats
플랜 제한에는 100% 신뢰할 수 있는 첫 번째 방법이 사용되고, 차트 표시에는 두 번째 방법이 사용됩니다. 홈 페이지의 계정에서 둘 다 확인할 수 있습니다:
- 차트에는 두 번째 방법
- 앱 테이블에는 첫 번째 방법
Capgo는 에뮬레이터와 개발 빌드를 사용량에 포함하지 않습니다. 시험 기간 이후에는 3% 이상을 초과할 수 없으며, 초과 시 수정할 때까지 계정이 잠깁니다.
Capgo는 또한 필터링을 수행합니다. Google PLAY에 버전을 보내도록 CI/CD가 구성된 경우, Google은 매번 20개 이상의 실제 기기에서 Capacitor 앱을 실행합니다. 새 번들의 처음 4시간 동안 Google 데이터 센터 IP가 카운트되지 않도록 차단합니다.
매월 이 데이터는 0에서 시작됩니다.
- 각 기기 요청마다 데이터베이스에서 기기를 생성하거나 업데이트
- 이번 달에 활성화되지 않은 활성 기기 수를 일일 카운터에 추가
첫 번째 방법은 900+ 사용자를 반환하고 두 번째 방법은 계정에서 200+ 사용자를 보여줍니다 플랜 제한에는 100% 신뢰할 수 있는 첫 번째 방법을 사용하고, 차트 표시에는 두 번째 방법을 사용합니다. 계정 홈 페이지에서 둘 다 확인할 수 있습니다.
스토리지
번들을 업로드할 때마다 업로드 크기만큼 이 숫자가 증가합니다.
이 데이터는 업로드 크기에만 관련되어 있으며, 앱 크기가 작을수록 플랜 내에서 더 잘 유지됩니다.
제한에 도달하거나 근접하면 CLI로 번들을 나열할 수 있습니다:
npx @capgo/cli@latest bundle list
정리할 수 있는 항목을 확인하고, 번들을 제거하면 스토리지가 확보되지만 통계는 삭제되지 않습니다.
정리할 준비가 되면 이 명령어를 사용하여 여러 번들을 제거하세요:
npx @capgo/cli@latest bundle cleanup
PS: 이는 지구를 위해서도, 여러분의 지갑을 위해서도 좋습니다 💪.
업로드의
--external을 사용하여 자체 스토리지를 사용하고 플랜에 포함시키지 않을 수 있습니다.
대역폭
이 값의 계산은 약간 더 복잡하지만, 기본 개념은 스토리지와 동일합니다.
사용자가 번들을 다운로드할 때마다 다운로드 크기만큼 이 숫자가 증가합니다.
이 데이터는 다운로드 크기에만 관련되어 있으며, Capacitor JS 앱 크기가 작을수록 플랜 내에서 더 잘 유지됩니다.
한 가지 중요한 점은 Capgo가 실제 다운로드된 크기를 볼 수 없고 번들의 크기만 볼 수 있다는 것입니다. 따라서 큰 번들이 있고 많은 사용자가 다운로드에 실패하면 빠르게 제한에 도달할 수 있습니다.
플랜 내에서 유지하는 가장 좋은 방법은 작은 번들을 사용하는 것이며, 불가능한 경우 사용자에게 다운로드 바를 표시하고 남은 다운로드 양을 알려주는 것입니다.
향후 Capgo는 한 번에 번들을 다운로드할 수 있는 기회를 더 많이 제공하도록 다운로드 시스템을 개선할 예정입니다.
