‫Android vitals کے ساتھ اپنی ایپ کی تکنیکی کوالٹی کی نگرانی کریں

ایپ کی کوالٹی کے مسائل اور تجاویز سے متعلق نئی بصیرتیں

کوالٹی سے متعلق مسائل کی ترجیحات کو طے کرنے میں مدد حاصل کرنے کیلئے، آپ ستمبر 2024 سے Play کونسول میں Android vitals کا مجموعی جائزہ اور ناکامیاں اور ANRs صفحات پر نئی بصیرتیں اور تجاویز حاصل کر سکتے ہیں۔

ابھی کے لیے، ایپ کی موافقت سے متعلق مسائل، خراب طرز عمل اور کچھ UX تجاویز دکھائی گئی ہیں۔ آئندہ سال میں ہم کوالٹی کے مزید مسائل کا پتا لگانا اور انہیں سامنے لانا جاری رکھیں گے اور مزید تجاویز فراہم کریں گے۔

اپنی ایپ کے استحکام، کارکردگی اور بیٹری کے استعمال وغیرہ کو سمجھنے اور اسے بہتر بنانے میں مدد کیلئے Android vitals کا استعمال کریں۔

اپنی ایپ کے ڈیٹا تک رسائی حاصل کرنے کا طریقہ منتخب کریں

There are two ways for you to use Android vitals: through Play Console and Play Developer Reporting API.

‫API ان ڈویلپرز کے لیے Android vitals تک پروگرامیٹک رسائی فراہم کرتا ہے جو Android vitals ڈیٹا کو دوسرے ڈیٹا سیٹس کے ساتھ ضم کرنا چاہتے ہیں یا اسے اپنے ورک فلوز میں بنانا چاہتے ہیں۔ ‫Android vitals تک رسائی کے لیے API استعمال کرنے کے بارے میں مزید جاننے کے لیے،Google Play Developer Reporting API صفحہ پر جائیں۔

‫Play کونسول میں اپنی ایپ کے Android vitals ڈیٹا کو تلاش کرنے اور اس کا جائزہ لینے کے لیے:

1. ‫Play کونسول کھولیں اور Android vitals کے مجموعی جائزہ کے صفحہ (نگرانی کریں اور بہتر بنائیں > Android Vitals > مجموعی جائزہ) پر جائیں۔
2. ڈیٹا کی وہ رینج منتخب کریں جسے آپ اوپری بائيں جانب تاریخ کی حد کے منتخب کنندہ کا استعمال کرتے ہوئے دیکھنا چاہتے ہیں۔

اہم: اگر کوئی ڈیٹا دستیاب نہیں ہے تو آپ کی ایپ کے پاس مخصوص فلٹرز کے اندر کسی بھی مسئلے کی نشاندہی کرنے کے لیے کافی ڈیٹا پوائنٹس نہیں ہیں۔

اپنی ایپ کے کور وائٹلز کی نگرانی کریں

Android vitals کے مجموعی جائزہ کے صفحہ کے اوپری حصے میں، آپ اپنی ایپ کے کور وائٹلز پر ڈیٹا دیکھ سکتے ہیں۔ یہ سب سے اہم تکنیکی میٹرکس ہیں اور Google Play پر آپ کی ایپ کی قابل دریافتگی کو متاثر کرتے ہیں۔ بنیادی ضروریات میں شامل ہیں:

• صارف کی نوٹس کردہ ANR شرح
• صارف کو درپیش کریش کی شرح
• حد سے زیادہ بیٹری کا استعمال (واچ فیس)
• حد سے زیادہ جزوی بیداری کے قفل (بی ٹا)

‫Google Play ان میٹرکس سے متعلق خراب طرز عمل کی حد کی وضاحت کرتا ہے۔ اگر آپ کی ایپ ان حدوں سے تجاوز کر جاتی ہے، تو امکان ہے کہ یہ Google Play پر کم قابل دریافت ہو سکے۔ کچھ معاملات میں، صارف کی توقعات کو سیٹ کرنے کے لیے آپ کی ایپ کے اسٹور کے صفحے پر ایک انتباہ دکھایا جا سکتا ہے۔

آپ ان علاقوں کی تیزی سے نشاندہی کرنے کے لیے "اہم مسائل" سیکشن کا استعمال کر سکتے ہیں جہاں آپ کی ایپ بہتر ہو سکتی ہے۔ اہم مسائل کی دو قسمیں ہیں:

• خراب طرز عمل: میٹرکس جو خراب طرز عمل کی حد سے تجاوز کرتے ہیں
• خامیاں: ڈیٹا میں اہم تبدیلیاں (مثال کے طور پر، صارف کی نوٹس کردہ ANR شرح میں تیز اضافہ)

ای میل اطلاعات موصول کرنے کے لیے، visit سیٹ اپ > اطلاعات یا اطلاعات کا نظم کریں "کور وائٹلز" سیکشن کے کونے میں (نگرانی کریں اور بہتر بنائیں > Android vitals > مجموعی جائزہ) پر کلک کریں۔ نوٹ کریں کہ اطلاعات فی الحال صرف خامیوں کے لیے دستیاب ہیں۔

تمام وائٹلز کو براؤز کریں

Android vitals کے مجموعی جائزہ کے صفحہ کے وسط کے قریب، آپ کوالٹی کے پہلو سے تمام وائٹلز پر ڈیٹا دیکھ سکتے ہیں۔

ٹیبل میں، آپ موجودہ اور گزشتہ وقت کے لیے اپنے میٹرکس کا جائزہ لے سکتے ہیں۔ آپ یہ بھی دیکھ سکتے ہیں کہ آپ کی ایپ Google Play پر موجود دیگر ایپس کے مقابلے کیسی ہے۔

تفصیلی میٹرکس دیکھیں

میٹرک کے بارے میں اضافی تفصیلات کے لیے، اس کے آگے تفصیلات دیکھیں () کو منتخب کریں۔ اگلی اسکرین پر، آپ جائزہ لے سکتے ہیں:

• خراب طرز عمل کی حد
• زمرہ کے معیارات
• تفصیلی بینچ مارک کے موازنے
  • صفحہ کے اوپری حصے کے قریب، پیئر موازنہ کارڈ میں، ایک حسب ضرورت پیئر گروپ میں ترمیم کرنے کے لیے پیئر گروپ میں ترمیم کریں کو منتخب کریں۔ حسب ضرورت پیئر گروپ بنانے کے بعد، آپ دیکھ سکتے ہیں کہ آپ کی ایپ Google Play پر آپ کے منتخب کردہ دیگر ایپس کے ساتھ کس طرح موازنہ کرتی ہے۔
• وقت کے ساتھ میٹرک کا رجحان

ڈائمینشنز کے ساتھ ڈیٹا کا تجزیہ کریں

اپنے ڈیٹا کو منظم کرنے، تقسیم کرنے اور تجزیہ کرنے میں آپ کی مدد کرنے کے لیے، آپ کے میٹرکس کو متعدد مختلف ڈائمینشنز سے تقسیم کیا گیا ہے۔ تمام میٹرکس میں درج ذیل بریک ڈاؤنز ہوتے ہیں:

• آرٹیفیکٹ: آپ کی ایپ کا وہ ورژن جس پر مسئلہ پیش آیا
• ‫Android ورژن (SDK): صارف کے آلے کے ذریعے رپورٹ کردہ Android OS ورژن
• فارم فیکٹر: آلہ کی قسم جس پر ایپ چلائی گئی تھی (مثال کے طور پر، فون، ٹیبلیٹ، ٹی وی، ویئرایبل)
• آلے کا ماڈل: ڈیوائس کی ایک اعلیٰ سطح کی تفصیل، جس میں ایک منفرد برانڈ اور آلہ کا شناخت کار شامل ہوتا ہے، مثال کے طور پر، "Google oriole۔" ایک ہی آلے کے ماڈل میں مختلف Android ورژنز، RAM، اسٹوریج، یا چپ پر لگے سسٹم (SoC) کے ساتھ مختلف حالتیں ہو سکتی ہیں۔
• ملک/علاقہ: مسئلہ کے وقت صارف کے آلے کے ذریعے رپورٹ شدہ مقام

تجویز: آلے کے ہارڈویئر یا سافٹ ویئر کے مخصوص پہلوؤں (مثال کے طور پر، آلہ کا ماڈل یا Android ورژن) کے بریک ڈاؤنز کے لیے، آپ ٹیبل میں آئٹم کے آگے علامت () پر کلک کر سکتے ہیں۔

کچھ میٹرکس میں اضافی بریک ڈاؤنز ہوتے ہیں:

• بیداری کے قفل کا نام: ٹیگز جو آپ کی ایپ میں PowerManager API استعمال کرتے وقت پروگرام کے لحاظ سے سیٹ کیے گئے تھے
• بیداری کا نام: ٹیگز جو آپ کی ایپ میں AlarmManager API استعمال کرتے وقت پروگرام کے لحاظ سے سیٹ کیے گئے تھے
• ‫ANR سرگرمی کا نام: سرگرمی کی کلاس کا مکمل طور پر اہل نام جہاں ANR واقع ہو (اگر دستیاب ہو)
• ‫ANR کی قسم: جب ANR واقع ہو (مثال کے طور پر، سروس کو چلاتے ہوئے) (اگر دستیاب ہو)

آپ مزید تفصیلات دستیاب ہونے پر دیکھ سکتے ہیں (مثال کے طور پر اس بریک ڈاؤن سے وابستہ کریش یا ANR کلسٹرز) کو منتخب کرکے آئٹم کے آگے تفصیلات دیکھیں () کو منتخب کریں۔

تجویز: آپ اسکرین کے اوپری حصے میں ٹوگل کا استعمال کرتے ہوئے ایک زمرے میں میٹرکس کے درمیان سوئچ کر سکتے ہیں اور صفحے کو فلٹر کر سکتے ہیں۔

ڈیٹا کی اقسام اور میٹرکس

‫Android vitals ڈیٹا Play کونسول میں گزشتہ 90 دنوں کے لیے اور Play ڈویلپر Reporting API میں تین سال کے لیے دستیاب ہے۔

ڈیٹا ان صارفین سے اکٹھا کیا جاتا ہے جنہوں نے Android آلے اور OS ورژنز کے ذیلی سیٹ سے استعمال اور ڈائیاگناسٹکس ڈیٹا کو خود کار طور پر اشتراک کرنے کا انتخاب کیا ہے۔ اس بارے میں مزید معلومات کے لیے کہ Android صارفین اشتراک کردہ ڈیٹا کا انتخاب کیسے کرتے ہیں، اکاؤنٹس ہیلپ سینٹر پر جائیں۔

‫Android vitals روزانہ اپ ڈیٹ ہوتی ہے۔ بعض اوقات +Android 10 آلات کا ڈیٹا Android 10 سے کم آلات کے ڈیٹا سے پہلے پہنچ سکتا ہے۔ اگر ایسا ہوتا ہے، تو آپ دیکھیں گے کہ +Android 10 ڈیٹا ان دنوں کے لیے دستیاب ہے جہاں صرف یہ دستیاب ہے۔

نوٹ: Android vitals کے میٹرکس ان تکنیکی مسائل کو خارج کر دیتے ہیں جو غیر تصدیق شدہ آلے کے ماڈلز یا آپ کی ایپ کے ان ورژنز پر پیش آتے ہیں جو Google Play کے ذریعے انسٹال نہیں کیے گئے تھے۔

سبھی کو سکیڑیں سبھی کو پھیلائیں

استحکام

‫

ANR کی شرح کے میٹرکس

‫ANR کی شرح کے میٹرکس آپ کی ایپ کے معیار کا مجموعی جائزہ فراہم کرتے ہیں۔ ان میٹرکس کا حساب آپ کے پاس موجود ANRs والے صارفین کی تعداد کو لے کر اور آپ کے ایپ کے استعمال کی بنیاد پر انہیں معمول پر لا کر لگایا جاتا ہے۔ ان کی اطلاع یومیہ فعال صارفین کے فیصد کے طور پر دی جاتی ہے، جہاں یومیہ فعال صارف کی وضاحت ایک ہی آلہ پر ایک دن میں ایپ استعمال کرنے والے صارف کے طور پر کی جاتی ہے۔ اگر کوئی صارف آپ کی ایپ کو ایک دن میں ایک سے زیادہ آلے پر استعمال کرتا ہے، تو ہر آلہ اس دن کے فعال صارفین کی تعداد میں تعاون کرے گا۔ اگر ایک ہی دن میں متعدد صارفین ایک ہی آلے کا استعمال کرتے ہیں، تو اس کا شمار ایک فعال صارف کے طور پر کیا جاتا ہے۔

‫ANR کی شرح کے تین میٹرکس ہیں:

• صارف کی نوٹس کردہ ANR شرح: آپ کے یومیہ فعال صارفین کا فیصد جنہوں نے کم از کم ایک صارف کی نوٹس کردہ ANR کا تجربہ کیا ہو۔ صارف کی نوٹس کردہ ANR ایک ANR ہے جسے صارف نے نوٹس کیا ہوگا۔ فی الحال، صرف "ان پٹ ڈسپیچنگ ٹائم آؤٹ" کے ANRs شمار کیے جاتے ہیں۔ یہ میٹرک ہمیشہ آپ کی مجموعی ANR کی شرح سے کم رہے گا، کیونکہ یہ روزانہ کے استعمال کے لحاظ سے معمول پر ہوتا ہے، لیکن تمام ANRs کو شمار نہیں کرتا ہے۔
  صارف کی نوٹس کردہ ANR شرح ایک کور وائٹل ہے، یعنی یہ Google Play پر آپ کی ایپ کی دریافت کو متاثر کرتی ہے۔ یہ اہم ہے کیونکہ اس میں شمار ہونے والے ANRs ہمیشہ اس وقت ہوتے ہیں جب صارف ایپ کے ساتھ مشغول ہوتا ہے، جس سے سب سے زیادہ خلل پڑتا ہے۔
• ‫ANR کی شرح: آپ کے یومیہ صارفین کا فیصد جنہوں نے کم از کم ایک ANR کا تجربہ کیا۔ اس میٹرک میں ANRs شامل ہیں جن کی درجہ بندی صارف کے خیال میں نہیں کی گئی ہے، لیکن ہم اس بات کی ضمانت نہیں دے سکتے کہ یہ ANRs صارفین کو متاثر نہیں کر رہے ہیں۔
• ملٹی ANR کی شرح: آپ کے یومیہ صارفین کا فیصد جنہوں نے کم از کم دو ANRs کا تجربہ کیا۔ یہ میٹرک مسئلے کے لوپس کو نمایاں کرنے میں مدد کرتا ہے۔

مسئلہ حل کریں

‫ANRs جو آپ کے ANR کی شرح کے میٹرکس میں تعاون کرتے ہیں ان کی اطلاع کریشز اور ANRs صفحہ پر دی جاتی ہے۔ آپ اس صفحہ پر صارف کی نوٹس کردہ ANRs کے لیے فلٹر کر سکتے ہیں۔

‫Android ڈیولپرز سائٹ ANRs کی تشخیص اور اسے درست کرنے کے لیے رہنمائی فراہم کرتی ہے۔

کریش کی شرح کے میٹرکس

کریش کی شرح کے میٹرکس آپ کی ایپ کے معیار کا مجموعی جائزہ فراہم کرتے ہیں۔ ان میٹرکس کا حساب آپ کے کریشز والے صارفین کی تعداد لے کر اور آپ کے ایپ کے استعمال کی بنیاد پر ان کو معمول پر لا کر لگایا جاتا ہے۔ ان کی اطلاع یومیہ صارفین کے فیصد کے طور پر دی جاتی ہے، جہاں یومیہ صارف کی وضاحت ایک ہی آلہ پر ایک ہی دن میں ایپ استعمال کرنے والے صارف کے طور پر کی جاتی ہے۔ اگر کسی صارف کے پاس ایک سے زیادہ آلے ہیں، تو صارف کو ایک سے زیادہ مرتبہ شمار کیا جائے گا۔ مثال کے طور پر، اگر دو صارفین ہر ایک آلے پر دو دن تک ایپ استعمال کرتے ہیں، تو یہ یومیہ چار سیشنز پیدا کرے گا۔

کریش کی شرح کے تین میٹرکس ہیں:

• صارف کو درپیش کریش کی شرح: آپ کے یومیہ صارفین کا فیصد جنہوں نے کم از کم ایک صارف کے نوٹس کردہ کریش کا تجربہ کیا۔ صارف کا نوٹس کردہ کریش ایک ایسا کریش ہوتا ہے جسے صارف نے نوٹس کیا ہو۔ مثال کے طور پر، کریش جو اس وقت ہوتا ہے جب آپ کی ایپ کوئی سرگرمی ڈسپلے کر رہی ہو یا پیش منظر کی سروس کے طور پر چل رہی ہو۔ یہ میٹرک آپ کے کریش کی مجموعی شرح سے ہمیشہ کم رہے گا، کیونکہ یہ روزانہ کے استعمال کے لحاظ سے معمول پر ہوتا ہے، لیکن تمام کریشز کو شمار نہیں کرتا ہے۔
  صارف کو درپیش کریش کی شرح ایک کور وائٹل ہے، یعنی یہ Google Play پر آپ کی ایپ کی دریافت کو متاثر کرتا ہے۔ یہ اہم ہے کیونکہ اس میں شمار ہونے والے کریش ہمیشہ اس وقت ہوتے ہیں جب صارف ایپ کے ساتھ مصروف ہوتا ہے، جس سے سب سے زیادہ خلل پڑتا ہے۔ اس لیے آپ کو یہ یقینی بنانا چاہیے کہ آپ کی ایپ اس میٹرک کے لیے خراب طرز عمل کی حد سے تجاوز نہیں کرتی۔

• کریش کی شرح: آپ کے یومیہ صارفین کا فیصد جنہوں نے کم از کم ایک کریش کا تجربہ کیا۔ اس میٹرک میں ایسے کریشز شامل ہیں جن کی درجہ بندی صارف کے خیال میں نہیں کی گئی ہے، لیکن ہم اس بات کی ضمانت نہیں دے سکتے کہ یہ کریش صارفین کو متاثر نہیں کر رہے ہیں۔

• ملٹی کریش کی شرح: آپ کے یومیہ صارفین کا فیصد جنہوں نے کم از کم دو کریشز کا تجربہ کیا۔ یہ میٹرک مسئلے کے لوپس کو نمایاں کرنے میں مدد کرتا ہے۔

مسئلہ حل کریں

Android ڈیولپرز سائٹ کریشز کی تشخیص اور اسے ٹھیک کرنے کے لیے رہنمائی فراہم کرتی ہے۔

‫LMK کی شرح کے میٹرکس

‫LMK کی شرح ایک ایپ کوالٹی میٹرک ہے جو آپ کی ایپ کے صارف کے تجربے پر میموری کے دباؤ کا اثر دکھاتا ہے۔ ‫LMK ی شرح ان صارفین کی تعداد پر مبنی ہے جنہوں نے آپ کی ایپ کے استعمال کے میٹرکس کے مقابلے میں میموری کو کم کرنے کا تجربہ کیا ہے۔ ان کی اطلاع ان صارفین کے فیصد کے طور پر دی جاتی ہے جو ایک ہی آلہ پر ایک دن میں ایپ استعمال کرتے ہیں۔ اگر کسی صارف کے پاس ایک سے زیادہ آلات ہیں تو وہ ایک سے زیادہ مرتبہ شمار کیے جاتے ہیں۔ مثال کے طور پر، اگر دو صارفین ہر ایک آلے پر دو دن تک ایپ استعمال کرتے ہیں، تو یہ یومیہ چار سیشنز پیدا کرے گا۔

ایک LMK میٹرک ہے:

• صارف کی نوٹس کردہ LMK کی شرح:: آپ کے یومیہ فعال صارفین کا فیصد جنہوں نے کم از کم ایک صارف کی نوٹس کردہ کم میموری کل (LMK) کا تجربہ کیا ہو۔ صارف کی نوٹس کردہ LMK ایک LMK ہے جسے صارف نے نوٹس کیا ہو گا۔ مثال کے طور پر، LMKs جو اس وقت ہوتا ہے جب آپ کی ایپ کوئی سرگرمی دکھا رہی ہو، یا پیش منظر کی سروس کے طور پر چل رہی ہو۔

مسئلہ حل کریں

‫Android ڈیولپرز سائٹ LMKs کی تشخیص اور اسے درست کرنے کے لیے رہنمائی فراہم کرتی ہے۔

آغاز اور لوڈ ہونے کے اوقات

آغاز کا وقت (ابتدائی ڈسپلے کا وقت)

آغاز کے وقت صفحے پر، آپ اس بارے میں تفصیلات دیکھ سکتے ہیں کہ آپ کی ایپ سرد ،وارم، اور گرم سسٹم کے حالات سے کب آہستہ آہستہ شروع ہوتی ہے۔ آغاز کا وقت اس وقت کی پیمائش کرتا ہے جب صارف آپ کی ایپ لانچ کرتا ہے، اس وقت تک جب اسکرین پر پہلے فریم ظاہر ہوتے ہیں۔ اسے 'ابتدائی ڈسپلے کا وقت' بھی کہا جاتا ہے۔

ہوسکتا ہے کہ آپ کی ایپ اس وقت کے بعد صارف کے ساتھ تعامل شروع کرنے کے لیے تیار نہ ہو، مثال کے طور پر، اگر آپ کی ایپ میں اضافی لوڈ کی اسکرینز ہیں۔

ڈیٹا کی جمع آوری کی تفصیلات

• آغاز کے اوقات صرف اس وقت ریکارڈ کیے جاتے ہیں جب صارف کسی سرگرمی کو متحرک کرتا ہے۔
  • مثال: کی بورڈ ایپس کے لیے، آغاز کا وقت ساتھی ایپ کے آغاز کے وقت کے برابر ہے۔
• اگر ایک ایپ ایک ہی دن میں ایک ہی سسٹم کی حالت سے کئی بار شروع ہوتی ہے تو دن کا زیادہ سے زیادہ آغاز کا وقت ریکارڈ کیا جاتا ہے۔
• ایپ کا پہلا فریم مکمل طور پر لوڈ ہونے پر آغاز کا وقت ٹریک کیا جاتا ہے، چاہے یہ کوئی اسکرین نہ ہو جس کے ساتھ صارفین تعامل کرتے ہیں۔
  • مثال: اگر کوئی ایپ سپلیش اسکرین سے شروع ہوتی ہے، تو آغاز کا وقت سپلیش اسکرین کو ڈسپلے کرنے کے لیے درکار وقت کے برابر ہوتا ہے۔

اہم تفصیلات

• متاثرہ سیشنز: ان سیشنز کا فیصد جن کے دوران صارفین کو ہر متعلقہ سسٹم کی حالت کے لیے سست آغاز کے وقت کا تجربہ ہوا:
  • سست کولڈ اسٹارٹ: 5 سیکنڈ یا اس سے زیادہ
  • سست وارم اسٹارٹ: 2 سیکنڈ یا اس سے زیادہ
  • سست ہاٹ اسٹارٹ: 1 سیکنڈ یا اس سے زیادہ
• سیشنز کی تعداد: ریکارڈ شدہ سیشنز کی تخمینی تعداد۔
• ‫99واں/90واں پرسنٹائل: ‎10%/1% یومیہ سیشن جہاں صارفین کو آپ کی ایپ کے لیے ایپ کے سست وقت آغاز کا تجربہ ہوا۔

مسئلہ حل کریں

اگر آپ کی ایپ میں سست ایپ کے آغاز کے اوقات بہت زیادہ ہیں، تو تجویز کردہ حل کے لیے Android ڈیولپرز سائٹ پر جائیں۔

رینڈرنگ

تمام رینڈرنگ

سست سیشن کی شرح (‎30 FPS یا ‎20 FPS) [صرف گیمز]

یہ کیوں ضروری ہے

سست سیشنز کا استعمال کرتے ہوئے آپ اپنے گیم کی فریم ریٹ کی کارکردگی کو سمجھ سکتے ہیں، جو اس بات پر اثر انداز ہوتا ہے کہ آپ کا گیم صارفین کو کتنا ہموار اور سیال محسوس ہوتا ہے۔

اپنی ایپ کے ڈیٹا کو سمجھیں

سست سیشنز کے صفحہ پر، آپ کو یومیہ سیشن کے فیصد کے بارے میں تفصیلات نظر آئیں گی جہاں صارفین نے 25 فیصد سے زیادہ فریموں کو ‎30 FPS یا ‎20 FPS سے آہستہ چلانے کا تجربہ کیا ہے، اس بنیاد پر کہ آپ کس بینچ مارک کو منتخب کرتے ہیں۔ آپ اپنے گیم کے لیے فریم ریٹ کے لحاظ سے سیشنز کی تقسیم بھی دیکھ سکتے ہیں۔ (سیشن لیول فریم ریٹ 75 ویں صدویہ پر پیمائش کیا جاتا ہے، یعنی 75 فیصد فریم کم از کم اس فریم ریٹ کو حاصل کرتے ہیں۔)

‫Google Play پر زیادہ تر گیمز کا مقصد ‎30 FPS یا اس سے زیادہ ہونا چاہیے۔ یہ صارفین کے لیے ایک معقول تجربہ فراہم کرتا ہے، قطع نظر اس کے کہ وہ کس قسم کی گیم کھیل رہے ہیں (حالانکہ کچھ صارفین کم از کم ‎60 FPS کو ترجیح دیں گے، خاص طور پر اعلیٰ درجے کے آلات پر)۔ یہ یقینی بنانے کے لیے کہ آپ اس بار کو حاصل کر رہے ہیں، سست سیشن کی شرح (‎30 FPS) میٹرک کی نگرانی کریں۔ ذہن میں رکھیں کہ اس میٹرک میں صرف وہ سیشن شامل ہیں جہاں 25 فیصد سے زیادہ فریموں میں ‎30 FPS موجود نہیں ہیں لہذا اس میں فریم کی شرح کے تغیر کے لیے کچھ رواداری ہے۔

جبکہ ‎30 FPS ایک معقول تجربہ فراہم کرتا ہے، ایسے اوقات یا گیمز کی اقسام ہو سکتی ہیں جہاں فریم ریٹ کو اس سے نیچے گرانا سمجھ میں آتا ہے یا صارف آپ کا گیم ایسے فونز پر کھیلنا چاہتے ہیں جو ‎30 FPS کو سپورٹ نہیں کر سکتے۔ ان حالات میں، ایک سیشن میں کم از کم 75 فیصد فریمز کو اب بھی ‎20 FPS یا اس سے زیادہ حاصل کرنا چاہیے۔ سست سیشنز کی شرح (‎20 FPS) میٹرک کی نگرانی کریں تاکہ یہ یقینی بنایا جا سکے کہ آپ اس بار کو پورا کر رہے ہیں۔

‫Android vitals ہر آلے کے ساتھ ساتھ تمام آلے اور سیشنز کے لیے سست سیشنز (‎30 FPS) اور سست سیشنز (‎20 FPS) کی رپورٹ کرتے ہیں۔ اپنے صارف کے مجموعی تجربے کو سمجھنے کے لیے مجموعی میٹرک کا استعمال کریں، لیکن فی آلے کی کارکردگی پر بھی توجہ دیں۔ مناسب وقت میں، Play صارفین کو ان گیمز سے دور رکھنا شروع کر دے گا جو اپنے فون پر ‎20 FPS حاصل نہیں کر سکتے۔

وائٹلز صرف آپ کے گیم کے 1 منٹ تک چلنے کے بعد ہی فریم ریٹ کی نگرانی شروع کرتا ہے۔

ڈیٹا کی جمع آوری کی تفصیلات

سست سیشن میٹرک کا حساب SurfaceFlinger سے جمع کردہ ڈیٹا سے کیا جاتا ہے۔ مزید ٹھوس طور پر، ایک سیشن کے فریم ریٹ کا تخمینہ ایپ کی ملکیت والی سطحوں پر کھینچے گئے فریموں کے درمیان وقت کی بنیاد پر لگایا جاتا ہے، اور اس میں OpenGL، Vulkan کے ساتھ ساتھ Android UI ٹول کٹ کے ذریعے پیش کیے گئے فریم بھی شامل ہیں۔ یہ میٹرک فی الحال صرف گیمز کے لیے دستیاب ہے۔

سست سیشنز کے لیے فریم ریٹ کا ڈیٹا Android 9 اور اس کے بعد کے ورژن چلانے والے آلات کے لیے جمع کیا جاتا ہے۔

ڈیش بورڈ ڈسپلے

• نمائندہ فریم ریٹ: Android 9 یا اس کے بعد والے آلات پر آپ کے گیم کی فریم ریٹ کی کارکردگی، 75ویں صدویہ پر شمار کی جاتی ہے۔ اس کا مطلب ہے کہ 75 فیصد سیشنز کا یہ فریم ریٹ تھا یا اس سے 75 فیصد تیز تھا۔
• وقت کے ساتھ سست سیشنز کی شرح: ایک وقت کا سلسلہ جو سست سیشنز کے لیے متعین کردہ سیشنز کا فیصد دکھاتا ہے۔
• فریم ریٹ کی تقسیم: ہسٹوگرام تمام سیشنز میں 75ویں صدویہ کا فریم ریٹ دکھا رہا ہے۔ اس کا مطلب یہ ہے کہ ایک سیشن میں 75 فیصد فریم سیشن بالٹی میں استعمال کرنے والے فریم ریٹ سے زیادہ تیز تھے۔

مسئلہ حل کریں

اگر آپ کی ایپ میں بہت زیادہ تعداد میں سست سیشنز ہیں تو تجویز کردہ حل کے لیے Android ڈویلپرز کی سائٹ پر جائیں۔

‫Android UI ٹول کٹ رینڈرنگ

ضرورت سے زیادہ سست فریم [صرف ایپس]

اپنی ایپ کے ڈیٹا کو سمجھیں

ضرورت سے زیادہ سست فریم والے صفحہ پر، آپ کو یومیہ سیشن کے فیصد کے بارے میں تفصیلات نظر آئیں گی جہاں صارفین کو 50 فیصد سے زیادہ فریمز کا تجربہ ہوا جو آلے کی ڈرائنگ کی آخری تاریخ سے محروم ہے۔ آپ کی ایپ کے ساتھ صارف کے تعاملات 60 فریمز فی سیکنڈبغیر کسی کمی یا تاخیر کے فریمز کے ساتھ چلنا چاہیے۔

ڈیٹا کی جمع آوری کی تفصیلات

‫UI ٹول کٹ فریم ورک کا استعمال کرتے وقت Google آپ کی ایپ کے ذریعہ پیش کردہ ہر فریم کا رینڈر ٹائم جمع کرتا ہے۔ ‫OpenGL یا Vulkan کو براہ راست استعمال کرتے ہوئے پیش کیے گئے فریمز کو جمع نہیں کیا جاتا ہے۔

ڈیش بورڈ ڈسپلے

جب آپ ایک قطار کو منتخب کرتے ہیں، تو آپ دیکھیں گے کہ ڈیٹا پرسنٹائلز میں ٹوٹا ہوا ہے۔

• متاثرہ سیشنز: یومیہ سیشنز کا فیصد جہاں صارفین نے 16 ms سے زیادہ رینڈر ٹائم کے ساتھ ‎50% سے زیادہ فریمز کا تجربہ کیا۔ یومیہ سیشن سے مراد وہ دن ہے جس کے دوران آپ کی ایپ استعمال کی گئی تھی۔ مثال کے طور پر، اگر دو صارفین دو دن تک ایپ کا استعمال کرتے ہیں تو یہ یومیہ چار سیشنز پیدا کرے گا۔
• سیشنز کی تعداد: ریکارڈ شدہ سیشنز کی تخمینی تعداد۔
• ‫99واں/90واں پرسنٹائل: %99/%90 کل فریمز کا رینڈر ٹائم دکھائے گئے نمبر سے کم تھا۔ یہ اعداد تمام جمع کیے گیے فریمز پر مبنی ہیں۔

جب آپ ٹیبل میں کسی اندراج پر کلک کرتے ہیں، تو آپ کو 'UI رینڈر ٹائم کی تقسیم' کا چارٹ نظر آئے گا۔ چارٹ کا جائزہ لیتے وقت، آپ اس بات کو یقینی بنانا چاہیں گے کہ آپ کی ایپ کے زیادہ تر فریم 16 ms پر یا اس سے کم ہیں۔

چارٹ کے نیچے کا ڈیٹا ایپ کی رینڈرنگ کارکردگی کی ترسیل کرتا ہے اور رینڈر ٹائم کے ساتھ کسی بھی مسئلے کی بنیادی وجہ تلاش کرنے میں آپ کی مدد کر سکتا ہے۔ مثال کے طور پر اگر آپ کی 'اعلی ان پٹ میں تاخیر' کا فیصد زیادہ ہے تو آپ اپنی ایپ کے کوڈ کو دیکھنا چاہیں گے جو صارف کے ان پٹ کو ہینڈل کرتا ہے۔ ان میٹرکس کے بارے میں مزید معلومات کے لیے، UI کارکردگی کی جانچ پر جائیں۔

• چھوٹی ہوئی Vsyncs: تمام فریمز کے لیے جو ‎16 ms سے زیادہ میں پیش کیے گئے ہیں، Vsync کے چھوٹنے والے ایونٹس کی تعداد کو فریمز کی تعداد سے تقسیم کیا جاتا ہے۔
• اعلی ان پٹ میں تاخیر: ‎16 ms سے زیادہ میں پیش کیے گئے تمام فریمز کے لیے، ‎24 ms سے زیادہ لینے والے ان پٹ ایونٹس کی تعداد کو فریمز کی تعداد سے تقسیم کیا جاتا ہے۔
• سست UI سلسلہ: ‎16 ms سے زیادہ میں پیش کیے گئے تمام فریمز کے لیے، UI سلسلہ کو مکمل ہونے میں ‎8 ms سے زیادہ وقت لگے فریمز کی تعداد سے تقسیم کیا جاتا ہے۔
• سست ڈرا ہدایات: تمام فریمز کے لیے جو ‎16 ms سے زیادہ میں پیش کیے گئے ہیں، GPU کو ڈرا ہدایات بھیجنے میں ‎12 ms سے زیادہ بار فریمز کی تعداد سے تقسیم کیا جاتا ہے۔
• سست بٹ میپ اپ لوڈز: تمام فریمز کے لیے جو ‎16 ms سے زیادہ میں پیش کیے گئے ہیں، وہ تعداد جب بٹ میپ کو GPU پر اپ لوڈ کرنے میں ‎3.2 ms سے زیادہ وقت لگے فریمز کی تعداد سے تقسیم کیا جاتا ہے۔

مسئلہ حل کریں

اگر آپ کی ایپ میں 16 ms سے زیادہ رینڈر ٹائم کے ساتھ فریمز کی زیادہ تعداد ہے، تو تجویز کردہ حل کے لیے Android ڈویلپرز سائٹ پر جائیں۔

ضرورت سے زیادہ منجمد فریم [صرف ایپس]

ضرورت سے زیادہ منجمد فریمز کے صفحہ پر، آپ کو یومیہ سیشنز کے فیصد کے بارے میں تفصیلات نظر آئیں گی جہاں صارفین نے 700 ms سے زیادہ رینڈر ٹائم کے ساتھ 0.1 فیصد سے زیادہ فریمز کا تجربہ کیا۔ آپ کی ایپ کے ساتھ صارف کے تعاملات 60 فریمز فی سیکنڈ بغیر کسی کمی یا تاخیر کے فریمز کے ساتھ چلنا چاہیے۔

ڈیٹا کی جمع آوری کی تفصیلات

‫UI ٹول کٹ فریم ورک کا استعمال کرتے وقت Google آپ کی ایپ کے ذریعہ پیش کردہ ہر فریم کا رینڈر ٹائم جمع کرتا ہے۔ ‫OpenGL یا Vulkan کو براہ راست استعمال کرتے ہوئے پیش کیے گئے فریمز کو جمع نہیں کیا جاتا ہے۔

ڈیش بورڈ ڈسپلے

جب آپ ڈائمینشن کی قطار کو پھیلاتے ہیں تو آپ دیکھیں گے کہ ڈیٹا پرسنٹائلز میں ٹوٹا ہوا ہے۔

• متاثرہ سیشنز: یومیہ سیشنز کا فیصد جہاں صارفین نے 700 ms سے زیادہ رینڈر ٹائم کے ساتھ 0.1 فیصد سے زیادہ فریمز کا تجربہ کیا۔ یومیہ سیشن سے مراد وہ دن ہے جس کے دوران آپ کی ایپ استعمال کی گئی تھی۔ مثال کے طور پر، اگر دو صارفین دو دن تک ایپ کا استعمال کرتے ہیں تو یہ یومیہ چار سیشنز پیدا کرے گا۔
• سیشنز کی تعداد: ریکارڈ شدہ سیشنز کی تخمینی تعداد۔
• ‫99 ویں/90 ویں صدویہ: کل فریمز میں سے %99/%90 کا رینڈر ٹائم دکھائے گئے نمبر سے کم تھا۔ یہ اعداد تمام جمع کیے گیے فریمز پر مبنی ہیں۔

جب آپ ٹیبل میں کسی اندراج پر کلک کرتے ہیں تو آپ کو 'UI رینڈر ٹائم کی تقسیم' کا چارٹ نظر آئے گا۔ چارٹ کا جائزہ لیتے وقت، آپ اس بات کو یقینی بنانا چاہیں گے کہ آپ کی ایپ کے زیادہ تر فریم 700 ms سے کم ہیں۔

چارٹ کے نیچے کا ڈیٹا ایپ کی رینڈرنگ کارکردگی کی ترسیل کرتا ہے اور رینڈر ٹائم کے ساتھ کسی بھی مسئلے کی بنیادی وجہ تلاش کرنے میں آپ کی مدد کر سکتا ہے۔ مثال کے طور پر اگر آپ کی 'اعلی ان پٹ میں تاخیر' کا فیصد زیادہ ہے تو آپ اپنی ایپ کے کوڈ کو دیکھنا چاہیں گے جو صارف کے ان پٹ کو ہینڈل کرتا ہے۔ ان میٹرکس کے بارے میں مزید معلومات کے لیے، UI کارکردگی کی جانچ پر جائیں۔

• چھوٹی ہوئی Vsyncs: تمام فریمز کے لیے جو 16 ms سے زیادہ میں پیش کیے گئے ہیں، Vsync کے چھوٹنے والے ایونٹس کی تعداد کو فریمز کی تعداد سے تقسیم کیا جاتا ہے۔
• اعلی ان پٹ میں تاخیر: 16 ms سے زیادہ میں پیش کیے گئے تمام فریمز کے لیے، 24 ms سے زیادہ لینے والے ان پٹ ایونٹس کی تعداد کو فریمز کی تعداد سے تقسیم کیا جاتا ہے۔
• سست UI سلسلہ: 16 ms سے زیادہ میں پیش کیے گئے تمام فریمز کے لیے، UI سلسلہ کو مکمل ہونے میں 8 ms سے زیادہ وقت لگے فریمز کی تعداد سے تقسیم کیا جاتا ہے۔
• سست ڈرا ہدایات: تمام فریمز کے لیے جو 16 ms سے زیادہ میں پیش کیے گئے ہیں، GPU کو ڈرا ہدایات بھیجنے میں 12 ms سے زیادہ بار فریمز کی تعداد سے تقسیم کیا جاتا ہے۔
• سست بٹ میپ اپ لوڈز: تمام فریمز کے لیے جو 16 ms سے زیادہ میں پیش کیے گئے ہیں، وہ تعداد جب بٹ میپ کو GPU پر اپ لوڈ کرنے میں 3.2 ms سے زیادہ وقت لگے فریمز کی تعداد سے تقسیم کیا جاتا ہے۔

مسئلہ حل کریں

اگر آپ کی ایپ میں 700 ms سے زیادہ رینڈر ٹائم کے ساتھ فریمز کی زیادہ تعداد ہے، تو تجویز کردہ حل کے لیے Android ڈویلپرز سائٹ پر جائیں۔

بیٹری

اٹکا ہوا بیداری کا قفل اور اٹکا ہوا جزوی بیداری کا قفل (پس منظر)

اٹکا ہوا جزوی بیداری کا قفل اور اٹکا ہوا جزوی بیداری کا قفل (پس منظر) صفحات دکھاتے ہیں جزوی بیداری کا قفل PowerManager کلاس کے ذریعے آپ کی ایپ کے ذریعے حاصل کیے گئے ہیں۔ جزوی بیداری کا قفل اس بات کو یقینی بناتا ہے کہ CPU چل رہا ہے لیکن اسکرین اور کی بورڈ کی بیک لائٹ کو بند کرنے کی اجازت ہوگی۔

ڈیٹا کی جمع آوری کی تفصیلات

• رازداری کے مقاصد کے لیے، جزوی بیداری کا قفل شناختی ٹیگز گمنام کر دیا جاتا ہے۔
• جزوی بیداری کے قفل کے بارے میں ڈیٹا اس وقت جمع کیا جاتا ہے جب آلہ چارج نہیں ہو رہا ہوتا ہے اور اسکرین آف ہوتی ہے۔
• اٹکا ہوا جزوی بیداری کے قفل کے ڈیٹا (پس منظر) کو صرف اس وقت جمع کیا جاتا ہے جب ایپ پس منظر میں چل رہی ہو۔
• ‫Google فی بیٹری سیشن کے زیادہ سے زیادہ جزوی بیداری کے قفل کے دورانیہ کا حساب لگاتا ہے تاکہ یہ ظاہر کیا جا سکے کہ طویل بیداری کے قفل سے کتنے سیشنز متاثر ہوتے ہیں۔ مثال کے طور پر، اگر کوئی صارف دو گھنٹے کے بیداری کے قفل کو متحرک کرتا ہے، تو Google زیادہ سے زیادہ ایک گھنٹے کی بیداری کے قفل کی ویلیو استعمال کرے گا۔
• ان ایپس کے لیے جو مینی فیسٹ فائل میں SharedUserId سیٹ کرتی ہیں: آپ کو ڈیٹا صرف اسی صورت میں نظر آئے گا جب ایک ہی sharedUserId کے ساتھ زیادہ سے زیادہ ایک ایپ انسٹال ہو۔

اہم تفصیلات

• متاثرہ سیشنز: بیٹری سیشنز کا فیصد جہاں صارفین کو کم از کم ایک گھنٹے سے زیادہ بیداری کے قفل کا تجربہ ہوا۔
• سیشنز کی تعداد: ریکارڈ شدہ سیشنز کی تخمینی تعداد۔
• 99واں/90واں پرسنٹائل: ‎10%/1% یومیہ سیشنز جہاں صارفین کو دکھائے گئے نمبر سے زیادہ جزوی بیداری کے قفل کے دورانیے کا تجربہ ہوا۔
• خراب طرز عمل کی حد: اگر آپ کی ایپ موجودگی کی شرح دکھائی گئی حد کے برابر یا اس سے زیادہ کا مظاہرہ کرتی ہے تو یہ Google Play پر ٹاپ 1,000 ایپس میں سے نچلے ‎25% میں ہے (انسٹالز کی تعداد کے لحاظ سے)۔

مسئلہ حل کریں

اگر آپ کی ایپ میں زیادہ تعداد میں جزوی بیداری کے قفل اٹکے ہوئے ہیں، تو تجویز کردہ حل کے لیے Android ڈیولپرز سائٹ پر جائیں۔

ضرورت سے زیادہ ویک اپس

ضرورت سے زیادہ ویک اپس کا صفحہ الارم مینیجر ویک اپ کو آپ کی ایپ کے ذریعے متحرک کرتا ہے۔آپ کلاسز کے لیے ویک اپ کا ڈیٹا دیکھیں گے ELAPSED_REALTIME_WAKEUP یا RTC_WAKEUP۔

ڈیٹا کی جمع آوری کی تفصیلات

• رازداری کے مقاصد کے لیے، ویک اپس کے شناختی ٹیگز گمنام ہیں۔
• جب آلہ چارج نہیں ہوتا ہے تو ویک اپس جمع کیے جاتے ہیں۔
• نارملائز میٹرک فراہم کرنے کے لیے، ویک اپس کی تعداد کا موازنہ اس وقت سے کیا جاتا ہے جب آلہ بیٹری پر ہوتا ہے۔ ‫Google یہ بتانے کے لیے فی گھنٹہ فی صارف ویک اپ کی تعداد کا حساب لگاتا ہے کہ کتنے صارفین اعلی ویک اپ کی شرح سے متاثر ہوتے ہیں۔
• ان ایپس کے لیے جو مینی فیسٹ فائل میں SharedUserId سیٹ کرتی ہیں: آپ کو ڈیٹا صرف اسی صورت میں نظر آئے گا جب ایک ہی sharedUserId کے ساتھ زیادہ سے زیادہ ایک ایپ انسٹال ہو۔

اہم تفصیلات

• متاثرہ سیشنز: بیٹری سیشنز کا فیصد جہاں صارفین نے فی گھنٹہ 10 سے زیادہ ویک اپس کا تجربہ کیا۔ بیٹری سیشن دیے گئے 24 گھنٹے کی مدت میں موصول ہونے والی تمام بیٹری رپورٹس کا مجموعہ ہے۔ ‫Android 10 میں، بیٹری کی رپورٹ سے مراد دو بیٹری چارجز کے درمیان وقفہ ہے یا تو 20 فیصد سے نیچے سے 80 سے اوپر تک یا کسی بھی قدر سے 100 فیصد تک۔ ‫Android 11 اور اس سے اوپر کے ورژن میں، بیٹری کی رپورٹ سے مراد 24 گھنٹے کی ایک مقررہ مدت ہے۔ ‫Google ڈیٹا صرف اس وقت جمع کرتا ہے جب آلہ چارجر سے دور ہو۔
• سیشنز کی تعداد: ریکارڈ شدہ سیشنز کی تخمینی تعداد۔
• ‫90واں/99واں پرسنٹائل: ‎10%/1% یومیہ سیشنز جہاں صارفین کو دکھائی گئی قدر سے زیادہ فی گھنٹہ جاگنے کا تجربہ ہوا۔
• خراب طرز عمل کی حد: اگر آپ کی ایپ موجودگی کی شرح دکھائی گئی حد کے برابر یا اس سے زیادہ کا مظاہرہ کرتی ہے تو یہ Google Play پر ٹاپ 1,000 ایپس میں سے نچلے ‎25% میں ہے (انسٹالز کی تعداد کے لحاظ سے)۔

مسئلہ حل کریں

اگر آپ کی ایپ اکثر ویک اپ رہتی ہے تو تجویز کردہ حل کے لیے Android ڈیولپرز سائٹ پر جائیں۔

ضرورت سے زیادہ Wi‑Fi اسکینز (پس منظر)

ضرورت سے زیادہ Wi‑Fi اسکینز (پس منظر) صفحہ یہ ظاہر کرتا ہے کہ کب Wi-Fi اسکینز کے نتیجے میں بیٹری کا زیادہ استعمال ہوتا ہے۔

ڈیٹا کی جمع آوری کی تفصیلات

‫Wi-Fi سکیننگ کے بارے میں ڈیٹا اس وقت جمع کیا جاتا ہے جب آلہ چارج نہیں ہو رہا ہوتا ہے اور ایپ پس منظر میں ہوتی ہے۔

اہم تفصیلات

• متاثرہ سیشنز: بیٹری سیشنز کا فیصد جہاں صارفین نے فی گھنٹہ 4 سے زیادہ Wi-Fi اسکینز کا تجربہ کیا۔
• سیشنز کی تعداد: ریکارڈ شدہ سیشنز کی تخمینی تعداد۔
• ‫99واں/90واں پرسنٹائل: ‎10%/1% یومیہ سیشن جہاں صارفین کو دکھائے گئے نمبر کے مقابلے میں پس منظر میں زیادہ گھنٹہ وار Wi-Fi اسکینز کا تجربہ ہوا۔

مسئلہ حل کریں

اگر آپ کی ایپ میں پس منظر کے Wi-Fi اسکینز کی ایک بڑی تعداد ہے، تو تجویز کردہ حل کے لیے Android ڈیولپرز سائٹ پر جائیں۔

ضرورت سے زیادہ نیٹ ورک کا استعمال (پس منظر)

ضرورت سے زیادہ نیٹ ورک کا استعمال صفحہ ظاہر کرتا ہے جب نیٹ ورک ڈیٹا کی ایک بڑی مقدار پس منظر کی خدمت سے وابستہ ہوتی ہے۔ جب موبائل نیٹ ورک کا استعمال پس منظر میں ہوتا ہے، تو آپ کے صارفین کو ڈیٹا کی منتقلی کو روکنے کے لیے کنٹرولز تک آسان رسائی نہیں ہوتی ہے۔

ڈیٹا کی جمع آوری کی تفصیلات

موبائل نیٹ ورک کے استعمال کے بارے میں ڈیٹا اس وقت جمع کیا جاتا ہے جب آلہ چارج نہیں ہو رہا ہوتا ہے اور ایپ پس منظر میں ہوتی ہے۔

اہم تفصیلات

• متاثرہ سیشنز: بیٹری سیشنز کا فیصد جہاں صارفین نے پس منظر میں روزانہ ‎50 MB سے زیادہ نیٹ ورک کے استعمال کا تجربہ کیا۔
• سیشنز کی تعداد: ریکارڈ شدہ سیشنز کی تخمینی تعداد۔
• ‫99واں/90واں پرسنٹائل: ‎10%/1% یومیہ سیشنز جہاں صارفین کو دکھائے گئے نمبر سے زیادہ پس منظر میں روزانہ نیٹ ورک کے استعمال کا تجربہ ہوا۔

مسئلہ حل کریں

اگر آپ کی ایپ کے پس منظر نیٹ ورک کا زیادہ استعمال ہے تو تجویز کردہ حل کے لیے Android ڈیولپرز سائٹ پر جائیں۔

حد سے زیادہ بیٹری کا استعمال (واچ فیس) 

بیٹری کا حد سے زیادہ استعمال (واچ فیس) صفحہ اس وقت ظاہر ہوتا ہے جب واچ فیس ایپ زیادہ بیٹری کے استعمال سے وابستہ ہوتی ہے۔ جب واچ فیس حد سے زیادہ بیٹری کے استعمال کا سبب بنتا ہے تو گھڑی ایک ہی چارج پر پورا دن نہیں چل پائے گی۔

ڈیٹا کی جمع آوری کی تفصیلات

بیٹری کے استعمال کے بارے میں ڈیٹا اس وقت جمع کیا جاتا ہے جب آلات چارج نہ ہو رہیں ہوں اور کوئی ایپ استعمال میں نہ ہو۔

اہم تفصیلات

• متاثر سیشنز: ان واچ فیس سیشنز کا فیصد جہاں بیٹری کا استعمال 4.44 فیصد فی گھنٹہ سے زیادہ ہے۔
• سیشنز کی تعداد: ریکارڈ شدہ سیشنز کی تخمینی تعداد۔

مسئلہ حل کریں

اگر آپ کی واچ فیس میں بیٹری کا حد سے زیادہ استعمال ہے تو تجویز کردہ حل کے لیے Android ڈیولپرز سائٹ پر جائیں۔

حد سے زیادہ جزوی بیداری کے قفل (بی ٹا) 

حد سے زیادہ جزوی بیداری کے قفل ایک معیاری میٹرک ہے جو اس بات کی نشاندہی کرتا ہے کہ پس منظر میں چلنے والے آپ کی ایپ کے جزوی بیداری کے قفل کا دورانیہ بہت زیادہ تھا۔ جزوی بیداری کے قفل آلہ کی اسکرین اور کی بورڈ کی بیک لائٹ کو آف کرنے کی اجازت دیتے ہوئے CPU کو چلاتے رہتے ہیں۔

حد سے زیادہ جزوی بیداری کے قفل ایک کور وائٹلز میٹرک ہے۔ دیگر کور وائٹلز میٹرکس کے برعکس، حد سے زیادہ بیداری کے قفل بی ٹا میں ہیں، اور خراب طرز عمل کی حد سے تجاوز کرنا فی الحال آپ کی ایپ کو Google Play پر کم قابل دریافت نہیں بناتا ہے۔

ڈیٹا کی جمع آوری کی تفصیلات

• حد سے زیادہ جزوی بیداری کے قفل کے بارے میں ڈیٹا اس وقت جمع کیا جاتا ہے جب آلہ چارج نہیں ہو رہا ہوتا ہے اور اسکرین آف ہوتی ہے۔
• حد سے زیادہ جزوی بیدار کے قفل کا ڈیٹا فی الحال صرف اس وقت جمع کیا جاتا ہے جب ایپ پس منظر میں چل رہی ہو۔
• ان ایپس کے لیے جو اپنی مینی فیسٹ فائل میں sharedUserId سیٹ کرتی ہیں: آپ کو ڈیٹا صرف اس صورت میں نظر آئے گا جب ایک ہی sharedUserId والی زیادہ سے زیادہ ایک ایپ انسٹال ہو۔

اہم تفصیلات

• متاثر سیشن: بیٹری سیشنز کا فیصد جہاں صارفین نے 3 گھنٹے سے زیادہ کے ایک یا زیادہ جزوی بیداری کے قفل کا تجربہ کیا
• سیشنز کی تعداد: ریکارڈ شدہ سیشنز کی تخمینی تعداد۔
• ‫99ویں / 90ویں صدویہ: 1 فیصد / 10 فیصد یومیہ سیشن جہاں صارفین کو دکھائے گئے نمبر سے زیادہ جزوی بیداری کے قفل کے دورانیے کا تجربہ ہوا۔

مسئلہ حل کریں

اگر آپ کی ایپ میں زیادہ تعداد میں جزوی بیداری کے قفل ہیں تو تجویز کردہ حل کے لیے Android ڈیولپرز سائٹ پر جائیں۔

اجازتیں

اجازت سے انکار

اجازت سے انکار صفحہ پر، آپ یومیہ اجازت کے سیشنز کے فیصد کے بارے میں تفصیلات دیکھ سکتے ہیں جن کے دوران صارفین نے اجازتوں سے انکار کیا۔ یومیہ اجازت کا سیشن سے مراد وہ دن ہوتا ہے جس کے دوران آپ کی ایپ اپنے صارف سے کم از کم ایک اجازت کی درخواست کرتی ہے۔

ڈیٹا کی جمع آوری کی تفصیلات

اجازت سے انکار کے بارے میں ڈیٹا اس وقت جمع کیا جاتا ہے جب صارفین آپ کی ایپ میں اجازت کی درخواستوں کا جواب دیتے ہیں۔

اہم تفصیلات

• انکار: یومیہ اجازت کے سیشنز کا فیصد جس کے دوران صارفین نے اجازت سے انکار کیا۔
• دوبارہ کبھی نہ پوچھیں: یومیہ اجازت کے سیشنز کا فیصد جس کے دوران صارفین نے دوبارہ کبھی نہ پوچھیں کو منتخب کر کے اجازتوں سے انکار کیا۔
• کل سیشنز: ریکارڈ کیے گئے سیشنز کی تخمینی تعداد۔

مسئلہ حل کریں

اگر آپ کی ایپ میں اجازتوں سے انکار کی ایک بڑی تعداد ہے، تو تجویز کردہ حل کے لیے Android ڈیولپرز سائٹ پر جائیں۔

بنیادی فائدہ

DAU / MAU

‫Android vitals صفحہ پر، آپ اپنی ایپ کے بنیادی فائدے کے بارے میں تفصیلات دیکھ سکتے ہیں۔ ‫DAU / MAU ان میٹرکس میں سے ایک ہے جو صارفین کے لیے آپ کی ایپ کے بنیادی فائدے کا اندازہ لگانے کے لیے استعمال ہوتی ہے۔ یہ یومیہ فعال صارفین (DAU) کی شرح کی نمائندگی کرتا ہے، وہ لوگ جو دن میں کم از کم ایک بار آپ کی ایپ کھولتے ہیں سے لے کر ماہانہ فعال صارفین (MAU)، وہ لوگ جو 28 دن میں کم از کم ایک بار آپ کی ایپ کھولتے ہیں تک کا تناسب۔ جب آپ کی ایپ کا DAU / MAU بنیادی فائدے کے لیے 8 فیصد کی حد کو پورا نہیں کرتا ہے تو آپ کے اسٹور کی فہرست پر ایک وارننگ دکھائی جا سکتی ہے اور ہو سکتا ہے کہ آپ کی ایپ Google Play پر مخصوص سطحوں پر ظاہر ہونے کی اہل نہ ہو۔

صارف کے نقصان کی شرح

صارف کے نقصان کی شرح کا استعمال صارفین کے لیے آپ کی ایپ کے بنیادی فائدے کا جائزہ لینے کے لیے کیا جاتا ہے۔ صارف کے نقصان کی شرح ان صارفین کا تناسب ہے جنہوں نے اپنے تمام آلات سے آپ کی ایپ کو مکمل طور پر ان انسٹال کر دیا ہے، ان لوگوں کے مقابلے جنہوں نے کم از کم ایک فعال آلے پر ایپ انسٹال کی ہے۔ اگر کسی آلہ کو پچھلے 30 دن میں آن کیا گیا ہے تو اسے فعال سمجھا جاتا ہے۔ صارف کے نقصان کی اعلی شرح یہ تجویز کر سکتی ہے کہ صارفین کے لیے بنیادی قدر کم ہے۔ اگر آپ کے صارف کے نقصان کی شرح Play کی حد 5 فیصد سے زیادہ ہے تو آپ کے اسٹور کی فہرست پر ایک وارننگ دکھائی جا سکتی ہے اور ہو سکتا ہے کہ آپ کی ایپ Google Play پر مخصوص سطحوں پر ظاہر ہونے کی اہل نہ ہو۔

کور وائٹلز کے لیے خراب طرز عمل کی حد

‫Google Play نے آپ کی ایپ کے کور وائٹلز پر خراب طرز عمل کی حد کی وضاحت کی ہے۔

اگر آپ کی ایپ خراب طرز عمل کی حد سے تجاوز کر جاتی ہے، تو امکان ہے کہ یہ Google Play پر کم قابل دریافت ہو سکے۔ اگر آپ کی ایپ کا مخصوص آلے کے ماڈلز پر خراب طرز عمل ہے، تو Google Play ان آلات پر صارفین کو ان عنوانات سے دور رکھے گا اور ان کے لیے زیادہ موزوں دوسروں کی طرف لے جائے گا۔ کچھ معاملات میں، صارف کی توقعات کو سیٹ کرنے اور اعلی تکنیکی معیار کے ساتھ متبادل تلاش کرنے کا اختیار فراہم کرنے کے لیے آپ کی ایپ کے اسٹور کے صفحے پر ایک انتباہ ڈسپلے کیا جا سکتا ہے۔

‫Google Play عام طور پر آپ کی ایپ کے معیار کا جائزہ لیتے وقت آخری 28 دنوں کے ڈیٹا پر غور کرے گا لیکن اس میں اضافے کی صورت میں جلد کارروائی کر سکتا ہے۔

سبھی کو سکیڑیں سبھی کو پھیلائیں

استحکام

صارف کی نوٹس کردہ ANR شرح کی حد

‫Google Play نے صارف کی نوٹس کردہ ANR شرح پر خراب طرز عمل کی حدود کی وضاحت کی ہے:

• مجموعی طور پر خراب طرز عمل: یومیہ فعال صارفین میں سے کم از کم ‎0.47% تمام آلے کے ماڈلز میں صارف کی نوٹس کردہ ANR کا تجربہ کرتے ہیں۔

• فی آلے کا خراب طرز عمل: کم از کم ‎8% یومیہ فعال صارفین کو ایک آلے کے ماڈل کے لیے صارف کی نوٹس کردہ ANR کا تجربہ ہوتا ہے۔

اپنے ANR کی شرح کو بہتر بنانے کے لیے، ان بنیادی ANR کلسٹرز کو درست کریں جن کی اطلاع کریشز اور ANRs صفحہ پر دی گئی ہے۔ متاثرہ صارفین کی تعداد جتنی زیادہ ہوگی، وہ کلسٹر آپ کے ANR کی شرح میں اتنا ہی زیادہ تعاون کرے گا۔

اگر آلے کے ہارڈویئر یا سافٹ ویئر کے مخصوص پہلو آپ کے ANR کی شرح میں تعاون کر رہے ہیں تو Android vitals آپ کو مطلع کرے گی۔ آپ رسائی اور آلات کے مجموعی جائزے کے صفحے (نگرانی کریں اور بہتر بنائیں > رسائی اور آلات > مجموعی جائزہ) پر اپنے لئے ایسوسی ایشنز بھی دریافت کر سکتے ہیں۔

صارف کو درپیش کریش کی شرح کی حد

‫Google Play نے صارف کو درپیش کریش کی شرح پر خراب طرز عمل کی حد کی وضاحت کی ہے:

• مجموعی طور پر خراب طرز عمل: کم از کم ‎1.09% یومیہ صارفین تمام آلے کے ماڈلز میں صارف کے نوٹس کردہ کریش کا تجربہ کرتے ہیں۔

• فی آلہ خراب طرز عمل: کم از کم ‎8% یومیہ صارفین کسی ایک آلے کے ماڈل کے لیے صارف کے نوٹس کردہ کریش کا تجربہ کرتے ہیں۔

اپنے کریش کی شرح کو بہتر بنانے کیلئے، ان بنیادی کریش کلسٹرز کو ٹھیک کریں جن کی اطلاع کریشز اور ANRs صفحے پر دی گئی ہے۔ متاثرہ صارفین کی تعداد جتنی زیادہ ہوگی، وہ کلسٹر آپ کے کریش کی شرح میں اتنا ہی زیادہ حصہ ڈالے گا۔

اگر آلے کے ہارڈویئر یا سافٹ ویئر کے مخصوص پہلو آپ کے کریش کی شرح میں تعاون کر رہے ہیں تو Android vitals آپ کو مطلع کرے گی۔ آپ رسائی اور آلات کے مجموعی جائزے کے صفحے (نگرانی کریں اور بہتر بنائیں > رسائی اور آلات > مجموعی جائزہ) پر اپنے لئے ایسوسی ایشنز بھی دریافت کر سکتے ہیں۔

بیٹری

حد سے زیادہ بیٹری کا استعمال (واچ فیس) کی حدود

Google Play نے بیٹری کے حد سے زیادہ استعمال (واچ فیس) پر خراب طرز عمل کی حد کی وضاحت کی ہے:

• مجموعی طور پر خراب طرز عمل: 1 فیصد سے زیادہ واچ فیس سیشنز میں تمام آلے کے ماڈلز میں بیٹری کا حد سے زیادہ استعمال ہوتا ہے۔

• فی آلہ خراب طرز عمل: 1 فیصد سے زیادہ واچ فیس کے سیشنز میں ایک آلہ کے ماڈلز کے لیے بیٹری کا حد سے زیادہ استعمال ہوتا ہے۔

حد سے زیادہ جزوی بیداری کے قفل (بی ٹا) کی حدود

‫Google Play نے حد سے زیادہ جزوی بیداری کے قفل (بی ٹا) پر خراب طرز عمل کی حد کی وضاحت کی ہے۔ اگرچہ میٹرک بی ٹا میں ہے، یہ Google Play پر آپ کی ایپ کی دریافت کو متاثر نہیں کرے گا۔

• مجموعی طور پر خراب طرز عمل: 5 فیصد سے زیادہ بیٹری سیشنز میں 3 گھنٹے سے زیادہ کے ایک یا زیادہ جزوی بیداری کے قفل کا تجربہ ہوا ہے۔

اپنی بیٹری کے استعمال کو کم کرنے کے لیے تجویز کردہ حل کے لیے Android ڈیولپرز کی سائٹ پر جائیں۔

متعلقہ مواد

اپنی ایپ کی کارکردگی اور استحکام کو بہتر بنانے کے لیے Android vitals استعمال کرنے کے بہترین طریقے دریافت کریں۔