تصميم واجهات برمجة التطبيقات (API) لعمر بطارية الهاتف المحمول: تقليل كثرة الطلبات

لماذا تستهلك واجهات برمجة التطبيقات الكثيرة البطارية على المحمول

واجهات برمجة تطبيقات "شاتية" تجعل التطبيق يرسل الكثير من الطلبات الصغيرة لبناء شاشة واحدة. كل طلب يبدو بسيطًا عند النظر إليه، لكن على الهاتف تتراكم التكلفة بسرعة.

أكبر تأثير على البطارية عادةً يأتي من راديو الشبكة. شرائح الخلوية وWi‑Fi تتحول إلى حالات طاقة عالية لإرسال واستقبال البيانات. عندما يطلق التطبيق العديد من الطلبات متقاربة، يبقى الراديو يستيقظ ويبقى نشطًا لفترة أطول. حتى لو كان كل رد صغيرًا، فإن الاستيقاظ المتكرر يكلف طاقة حقيقية.

هناك أيضًا عبء على المعالج. كل طلب يعني بناء رؤوس، إجراء عمل TLS، تحليل JSON، تحديث الكاش، وتشغيل كود التطبيق لدمج النتائج. إذا سقطت الاتصالات، يتكرر عمل الإعداد.

الطلبات الكثيرة تجعل واجهة المستخدم تبدو أبطأ أيضًا. بدلًا من تحميل واحد متوقع، تنتظر الشاشة سلسلة من المكالمات. تحصل على دوارات أطول، وعروض جزئية تتغير فجأة، وزمن انتهاء أقصر عندما تكون الشبكة ضعيفة. التحديث في الخلفية يتدهور بنفس الطريقة: المزيد من المحاولات، المزيد من الاستيقاظ، ومزيد من استنزاف البطارية.

طريقة عملية للتفكير في تصميم واجهات برمجة التطبيقات (API) لعمر بطارية الهاتف المحمول بسيطة: اعرض نفس واجهة المستخدم مع دورات أقل، بايتات أقل، وعمل خلفي أقل.

يمكنك تتبع النجاح ببعض التغييرات الملموسة:

• عدد أقل من طلبات API لكل تحميل شاشة
• عدد أقل من البايتات التي يتم تنزيلها لكل شاشة
• تحسّن المتوسط والأسوأ في زمن الوصول للتفاعل على الشبكة الخلوية
• عدد أقل من عمليات التحديث الخلفية والمحاولات للحصول على نفس النتيجة

عندما تتحسّن هذه المقاييس، عادةً ما تتحسّن الاستجابة وعمر البطارية معًا.

ماذا تقيس قبل أن تغيّر أي شيء

قبل التجميع أو تعديل التخزين المؤقت، احصل على صورة واضحة لما يفعله التطبيق اليوم. الانتصارات السريعة عادةً تأتي من إصلاح عدد قليل من المسببات المتكررة، لكنك ستجدها فقط إذا قمت بقياس الشاشات والتدفقات الحقيقية (وليس مجرد اختبار مسار واحد ناجح).

بالنسبة لعدد قليل من الشاشات عالية الحركة، سجّل الأساسيات: عدد الطلبات لكل تحميل، أي نقاط النهاية المستدعاة، البايتات المرسلة والمستقبلة (الرؤوس بالإضافة إلى الجسم)، معدلات المحاولة وانتهاء المهلة، وكم يستغرق حتى تشعر أن واجهة المستخدم قابلة للاستخدام. إن أمكن، فرق معدلات الأخطاء حسب نوع الشبكة (Wi‑Fi مقابل خلوي). تلك التقسيمات غالبًا تكشف مشاكل قد تغفل عنها على اتصال ثابت.

فصل حركة الواجهة الأمامية عن حركة الخلفية. قد تبدو الشاشة هادئة، لكن الهاتف قد يكون مشغولًا بتحديثات الخلفية، مزامنة بدافع الإشعارات، تحميل تحليلات، أو مكالمات جلب مسبق "للاحتياط". تتبع هذه بشكل منفصل حتى لا تُحسّن الشيء الخطأ.

النقاط الساخنة تميل إلى التجمع حول لحظات قليلة: تشغيل التطبيق، شاشة المنزل/التغذية، شاشات التفاصيل التي تتفرع إلى العديد من المكالمات، والسحب للتحديث. اختر واحدة من هذه وقِسها من البداية للنهاية.

حدد ميزانية أساسية حتى يتفق الفريق على ما يبدو "جيدًا". على سبيل المثال: "تحميل بارد لشاشة تتبع الطلب يجب ألا يتجاوز 6 طلبات وتنزيل لا يزيد عن 250 كيلوبايت قبل عرض الحالة."

إذا أردت زوج KPI بسيط للبدء استخدم (1) الطلبات لكل تحميل شاشة و(2) معدل المحاولات. تقليل المحاولات غالبًا يوفر بطارية أكثر مما تتوقع، لأن المحاولات المتكررة تبقي الراديو نشطًا لفترة أطول.

خطوة بخطوة: تقليل الطلبات عن طريق التجميع

من السهل إنشاء واجهات برمجة تطبيقات شاتية عن طريق الخطأ. كل ويدجت يحمل "بياناته"، وتؤدي شاشة واحدة إلى اثني عشر مكالمة صغيرة. الإصلاح عادةً ليس معقّدًا: حدّد ما يتم تحميله دائمًا معًا وأرجعه في عدد أقل من المكالمات.

ابدأ برسم خريطة لشاشة عالية الحركة واحدة (الصفحة الرئيسية، البريد الوارد، قائمة الطلبات). اكتب ما يظهر فوق الطي، ثم تتبع كل عنصر واجهة مستخدم إلى الطلب الذي يقدّمه. ستجد غالبًا تكرارات (نفس ملف التعريف للمستخدم يتم جلبه مرتين) ومكالمات تسير دائمًا معًا (الملف الشخصي بالإضافة إلى الأذونات وعدد الرسائل غير المقروءة).

بعد ذلك، جمّع المكالمات التي تحدث معًا باستمرار. لديك عمومًا خياران:

• أنشئ نقطة نهاية مخصصة للشاشة (غالبًا الأكثر استقرارًا)
• أضف نقطة نهاية تجميع تقبل قائمة صغيرة ومتوقعة من الموارد

حافظ على التجميعات موجهة للشاشة ومحدودة حتى يسهل تخزينها مؤقتًا ومراقبتها وتصحيحها.

قواعد قليلة تمنع التجميع من أن يصبح فوضى. أعد فقط ما تحتاجه الشاشة الآن، لا الكائنات الكاملة "تحسبًا". إذا كانت بعض الأجزاء اختيارية، فاجعل ذلك صريحًا حتى يتمكن الواجهة من عرض الأجزاء المهمة بسرعة. صمم الاستجابة بحيث لا تجبر الفشل الجزئي على إعادة المحاولة الكاملة. أرخص بكثير إعادة محاولة ما فشل فقط بدل إعادة إرسال الدُفعة بأكملها.

رؤوس التخزين المؤقت التي توفر البطارية (وليس فقط النطاق الترددي)

التخزين المؤقت هو ميزة للبطارية. كل طلب يوقظ الراديو، يبقي المعالج مشغولًا، ويشغّل تحليل وبرمجيات التطبيق. رؤوس التخزين المؤقت الجيدة تحول العديد من التحديثات إلى فحوصات خفيفة.

أكبر مكسب هو الطلبات الشرطية. بدل إعادة تنزيل نفس البيانات، يسأل العميل "هل تغيّر هذا؟" إذا لم يتغير، يرد الخادم بـ 304 Not Modified صغير.

استخدم ETag في الاستجابات التي تمثل نسخة من مورد، وليرسل العميل If-None-Match عند الجلب التالي. إذا كان توليد ETag صعبًا، فـ Last-Modified مع If-Modified-Since يعمل جيدًا للموارد البسيطة المبنية على "تم التحديث في".

لبيانات نادراً ما تتغير، اجعل قرار التخزين المؤقت صريحًا. يجب أن يتطابق Cache-Control مع الواقع. قد يكون max-age قصير لملفات تعريف المستخدمين مقبولًا، بينما إعدادات التطبيق، قوائم المرجع، وعلم الميزات يمكن أن تكون أطول.

على جانب التطبيق، اعتبر 304 كمسار سريع. لا تحلل JSON (فلا يوجد)، لا تعيد بناء النماذج، ولا تسبب وميضًا في الواجهة. احتفظ بما هو معروض بالفعل وقم بتحديث المؤشرات فقط.

مثال: شاشة تتبع الطلب تستطلع حالة الطلب كل 15 ثانية. إذا كانت الاستجابة تتضمن ETag، يمكن لمعظم الفحوص أن تُرجع 304. يحتفظ التطبيق بآخر حالة ولا يقوم بعمل حقيقي إلا عندما تتغير الحالة (مثلًا من "Packed" إلى "Shipped").

كن متعمدًا مع البيانات الحساسة. التخزين المؤقت ليس بالضرورة غير آمن، لكنه يحتاج قواعد واضحة. تجنّب تخزين الاستجابات التي تحتوي على تفاصيل شخصية أو رموز وصول ما لم تسمح المتطلبات بذلك. استخدم أوقات حياة قصيرة للبيانات الخاصة بالمستخدم، وامنَع التخزين المشترك للاستجابات الخاصة (Cache-Control: private) عند الحاجة.

حمولات أذكى: أرسل أقل، وافتح أقل

كل بايت إضافي يكلف أكثر من مجرد النطاق الترددي على المحمول. إنه يبقي الراديو مستيقظًا لفترة أطول ويجعل التطبيق يقضي وقتًا في فك ترميز JSON وتحديث النماذج. إذا كنت تحاول تقليل كثرة طلبات الـ API، فاقتطاع الحمولات غالبًا ما يكون أسرع مكسب.

ابدأ بتدقيق الحمولات لكل شاشة. اختر شاشة واحدة (مثل الخلاصة الرئيسية)، سجّل أحجام الاستجابات، وانظر حقلًا بحقل: هل يعرض العميل هذا الحقل، أم يستخدمه لقرار ما؟ إذا لا، احذفه من تلك النقطة النهائية.

بالنسبة للقوائم، شكل "ملخّص" صغير عادةً يكفي. صف القائمة غالبًا يحتاج id، عنوان، حالة، وطابع زمني. لا يحتاج أوصافًا كاملة، ملاحظات طويلة، أو كائنات متداخلة عميقة. احصل على التفاصيل فقط عندما يفتح المستخدم عنصرًا.

بعض التغييرات التي تقلل الحمولات بسرعة:

• فضّل الـ ids أو رموز enum قصيرة بدل السلاسل الطويلة المكررة
• لا تعيد إرسال القيم الافتراضية الواضحة التي يمكن للعميل افتراضها
• تجنّب تكرار نفس الكائن المتداخل في كل صف من القائمة
• حافظ على ثبات أسماء الحقول والأنواع حتى لا يضطر العميل للتفرّع وإعادة التحليل

الضغط يمكن أن يساعد، خاصة على الشبكات البطيئة، لكن اختبر مقايضة المعالج على الأجهزة الحقيقية. Gzip أو Brotli غالبًا تقلّلان حجم النقل كثيرًا، لكن الهواتف القديمة قد تقضي وقتًا ملموسًا في فك ضغط الاستجابات الكبيرة جدًا. المكسب الأفضل ما زال من إرسال بيانات أقل أصلاً.

عامل أشكال الاستجابة كعقد. عندما تبقى أسماء الحقول والأنواع متسقة، يحتاج التطبيق إلى عدد أقل من حالات الطوارئ وكود دفاعي أقل، مما يساعد على الحفاظ على سلاسة الواجهة وتقليل استهلاك البطارية.

صمم للشبكات الضعيفة ومحاولات أقل

التطبيق المحمول لا يحرق البطارية فقط عندما يرسل طلبات. إنه يحرق البطارية أيضًا عندما يفشل، يعيد المحاولة، يوقظ الراديو مرة أخرى، ويكرر العمل. إذا افترضت واجهة برمجة التطبيقات شبكة Wi‑Fi مثالية، سيدفع المستخدمون الحقيقيون على 4G المتقطعة الثمن.

سهّل طلب بيانات أقل. فضّل عوامل فلترة على الخادم وتقسيم الصفحات بدلًا من "تحميل كل شيء والتصفية على الهاتف." إذا كانت الشاشة تحتاج آخر 20 حدثًا لمستخدم واحد، ادعم هذا الاستعلام بالضبط حتى لا يجلب التطبيق مئات الصفوف ليُهدر معظمها.

ادعم المزامنة التفاضلية حتى يسأل العميل "ما الذي تغيّر منذ آخر فحص؟" يمكن أن يكون ذلك بسيطًا مثل إرجاع طابع زمني أو رقم إصدار متزايد، ثم يسمح للعميل بطلب التحديثات والحذوفات فقط منذ تلك النقطة.

المحاولات حتمية، لذا اجعل التحديثات idempotent. لا يجب أن تؤدي إعادة المحاولة إلى خصم مزدوج أو إرسال مكرر أو إنشاء سجلات مكررة. مفاتيح idempotency لعمليات الإنشاء وسلوكيات التحديث التي تضبط الحالة (بدلًا من "أضف واحدًا") تساعد كثيرًا.

عندما تحدث محاولات، تجنّب عواصف المحاولات. استخدم تراجعًا أُسّيًا مع تشتّت حتى لا تضرب آلاف الأجهزة خوادمك في نفس الوقت، وحتى لا يستيقظ الهاتف كل ثانية.

أعد رموز خطأ واضحة تساعد العميل على اتخاذ القرار. 401 يجب أن يؤدّي إلى إعادة المصادقة، 404 عادةً توقف إعادة المحاولة، 409 قد يتطلب تحديث الحالة، و429 أو 503 يجب أن يُشغّل التراجع.

سلوك العميل الذي يضاعف تكلفة الـ API

حتى مع API مصممة جيدًا، يمكن للعميل أن يضاعف العمل الشبكي بهدوء. على المحمول، تلك الاستيقاظات الإضافية ووقت تشغيل الراديو غالبًا ما تكلف البطارية أكثر من البايتات نفسها.

خزن على العميل البيانات التي نادرًا ما تتغير. صور الملفات الشخصية، أعلام الميزات، وبيانات المرجع (دول، حالات، فئات) لا يجب استدعاؤها عند كل زيارة شاشة. امنحها أوقات حياة معقولة، خزّنها على القرص، وجددها فقط عند الحاجة. إذا دعم الـ API التحقق (ETag أو Last-Modified)، ففحص سريع غالبًا أرخص من تنزيل كامل.

مشكلة شائعة أخرى هي الطلبات المكررة الجارية. جزءان من التطبيق يعيدان طلب نفس المورد في نفس الوقت (مثلًا، شريط العنوان وشاشة الإعدادات يطلبان الملف الشخصي). بدون تجميع، ترسل مكالمتين، تحلل ردين، وتحدث الحالة مرتين. عامل مكالمة الشبكة الواحدة كمصدر واحد للحقائق ودع المستهلكين المتعددين ينتظرون عليها.

التحديث في الخلفية يجب أن يكون مقصودًا. إذا لم يغير ما يراه المستخدم قريبًا، أو لن يشغل إشعارًا، فعادة يمكن تأجيله. تجنّب تشغيل منطق التحديث عند كل استئناف للتطبيق. أضف فترة تبريد قصيرة وتحقق من وقت آخر تحديث.

إذا بنيت الواجهات الخلفية بـ AppMaster، فسيكون من الأسهل دعم هذه السلوكيات العميلية عبر تشكيل نقاط النهاية حول الشاشات، الحفاظ على تناسق مخططات الاستجابة، وإضافة رؤوس التخزين المؤقت بشكل متحكم به حتى تبقى العملاء صامتين معظم الوقت.

أخطاء شائعة مع التجميع والتخزين المؤقت والحمولات

الهدف هو: استيقاظات راديو أقل، عمل معالج أقل، ومحاولات أقل. بعض الأنماط يمكن أن تلغي المدّخرات وتجعل الشاشات أبطأ.

متى يجعل التجميع الأمور أسوأ

يفيد التجميع حتى يتحول الطلب إلى "أعطني كل شيء". إذا اضطر الخادم لربط جداول كثيرة، تشغيل فحوص أذونات ثقيلة، وبناء استجابة ضخمة، فإن ذلك الطلب الواحد قد يأخذ وقتًا أطول من عدة طلبات أصغر. على المحمول، طلب واحد بطيء يبقي التطبيق ينتظر، يبقي الشبكة نشطة، ويزيد خطر انتهاء المهلة.

الدفعة الصحية مصممة على شكل الشاشة: فقط ما تحتاجه رؤية واحدة، مع حدود واضحة. إذا لم تستطع وصف الاستجابة في جملة واحدة، فالواجهة ربما واسعة جدًا.

التخزين المؤقت الذي يخلق شاشات قديمة

التخزين المؤقت بدون إبطال واضح يؤدي إلى حلقة سيئة: المستخدمون يرون بيانات قديمة، يسحبون للتحديث، ويجري التطبيق تحميلات كاملة إضافية. استخدم رؤوس التخزين المؤقت مع خطة لما يحدث عند تحديث البيانات (إجراءات إنشاء/تحديث، أحداث الخادم، أو نوافذ حداثة قصيرة) حتى يثق العميل في الاستجابات المخزنة مؤقتًا.

الاستطلاع المتكرر فخ بطارية آخر. مؤقت 5 ثواني ضيق يبقي الجهاز مشغولًا حتى عندما لا يتغير شيء. فضّل التحديثات المدفوعة بالخادم عندما أمكن، أو تراجع بقسوة (فترات أطول بعد استطلاعات فارغة، إيقاف في الخلفية).

الحمولات الضخمة تكلفة صامتة. إرجاع كائنات متداخلة كبيرة "للغرض" يعني المزيد من البايتات، المزيد من تحليل JSON، والمزيد من تشوّش الذاكرة. أرسل فقط ما تحتاجه الشاشة وجلب التفاصيل عند الطلب.

وأخيرًا، لا تتجاهل الفشل الجزئي في الدفعة. إذا فشل جزء واحد وأعدت محاولة الدفعة كاملة، فأنت تضاعف الترافيك. صمّم الاستجابات بحيث يمكن للعميل إعادة محاولة الأجزاء الفاشلة فقط.

قائمة تحقق ذهنية سريعة: احتفظ بالتجميعات محدودة، عرّف حداثة الكاش مسبقًا، تجنّب الاستطلاع الضيق، اقتطع الحمولات، وادعم النجاح الجزئي.

قائمة تحقق سريعة قبل الإصدار

قبل الشحن، قم بمرّة تفقد تركز فقط على سلوك الشبكة. معظم مكاسب البطارية تأتي من إزالة المفاجآت: استيقاظات أقل، تحليل أقل، ومحاولات أقل في الخلفية.

نفّذ هذا على أعلى ثلاث شاشات لديك:

• التحميلات الباردة تنتهي بعد عدد صغير ومحدد من الطلبات (راقب المكالمات الخفية التالية مثل استعلامات لكل عنصر).
• الاستجابات تتضمن قواعد تخزين مؤقت واضحة (ETag أو Last-Modified حيث يناسب) وترجع 304 Not Modified عندما لا يتغير شيء.
• نقاط نهاية القوائم محدودة: ترتيب ثابت، تقسيم صفحات، ولا حقول غير مستخدمة افتراضيًا.
• منطق المحاولة يتراجع مع تشتّت ويتوقف عند الأخطاء التي لن تُصلح ذاتيًا؛ وقت المحاولة الإجمالي محدود.
• التحديثات الخلفية مبررة؛ تجنب الاستطلاع المستمر ما لم يغير المحتوى ما يراه المستخدم.

اختبار واقعي بسيط: حمّل شاشة مرة، شغّل وضع الطائرة، ثم أعد فتحها. إذا ما زالت تُظهر شيئًا مفيدًا (محتوى مخزن مؤقتًا، الحالة الأخيرة المعروفة، نائبات ودّية)، فقد خفّضت الطلبات غير الضرورية وحسّنت السرعة المدركة أيضًا.

مثال: جعل شاشة تتبع الطلب أرخص في التحميل

يفتح عميل تطبيق تتبع طلب على بيانات الجوال والبطارية على 20%. يريد شيئًا واحدًا: "أين طردي الآن؟" الشاشة تبدو بسيطة، لكن الترافيك خلفها قد يكون مكلفًا بشكل مفاجئ.

قبل، التطبيق يحمّل الشاشة بتدفق من الطلبات. الواجهة تنتظر بينما يستيقظ الراديو مرارًا وتكرارًا، وبعض المكالمات تنتهي مهلة في اتصال ضعيف.

نمط "قبل" نموذجي يبدو كالتالي:

• GET /orders/{id} لمُلخّص الطلب
• GET /orders/{id}/items لبنود الطلب
• GET /orders/{id}/history لأحداث الحالة
• GET /me لملف المستخدم والتفضيلات
• GET /settings لقواعد العرض (العملة، تنسيق التاريخ)

اطبق الآن ثلاث تغييرات لا تغيّر الواجهة:

أولًا، أضف نقطة نهاية شاشة واحدة تُرجع فقط ما تحتاجه الواجهة في رحلة واحدة: ملخّص الطلب، أحدث حالة، تاريخ حديث، وعناوين البنود. ثانيًا، خزن الملف الشخصي في الكاش: GET /me يرجع ETag وCache-Control: private, max-age=86400، لذا تصبح معظم الفتحات سريعة 304 (أو لا تحتاج طلبًا إذا كانت النسخة المخزنة ما زالت طازجة). ثالثًا، قلّص الحمولة: قائمة البنود ترسل id, name, qty, وthumbnail_url فقط، لا أوصاف المنتج الكاملة أو بيانات تعريف غير مستخدمة.

النتيجة: طلبات أقل، بايتات أقل، ومحاولات أقل عندما تتلعثم الشبكة. يبقى راديو الهاتف في وضع السكون أكثر، وهو المكان الذي تأتي منه وفورات البطارية الحقيقية.

للمستخدم، لا يظهر شيء "جديد". الشاشة نفسها، لكنها تُحمّل أسرع، تبدو أكثر استجابة، وتستمر في العمل حتى عندما تكون الشبكة مهتزة.

الخطوات التالية: خطة نشر عملية (وأين يمكن أن يساعد AppMaster)

إذا أردت مكاسب سريعة، ابدأ صغيرًا وأثبت التأثير. وفورات البطارية عادةً تأتي من استيقاظات راديو أقل وعملية تحليل أقل، لا من إعادة كتابة ضخمة.

ثلاثة تغييرات آمنة، قابلة للقياس، وسهلة التراجع:

• قِس شاشة واحدة من البداية للنهاية (عدد الطلبات، إجمالي البايتات، وقت الوصول للتفاعل، معدلات الخطأ والمحاولة)
• جمّع طلبات تلك الشاشة في واحد أو اثنين من المكالمات (ابقِ النقاط النهائية القديمة للتوافق)
• أضف دعم ETag على نقاط GET الأعلى حركة حتى يستخدم العملاء If-None-Match ويتلقّون 304 Not Modified

اختر ميزة ذات استخدام ثابت، مثل قائمة الطلبات أو صندوق الوارد. انشر خلف علم على الخادم إذا أمكن، ثم قارِن مؤشرات الأداء للطريق القديم مقابل الجديد عبر بضعة أيام. ابحث عن انخفاض في الطلبات لكل جلسة، انخفاض في المحاولات، وقلة البايتات التي ينزلها المستخدم النشط.

نَسِّق إصدارات الـ API والتطبيق حتى لا تكسر العملاء القدامى. قاعدة عملية: أضف السلوك الجديد أولًا، حرّك العملاء ثانيًا، واحذف السلوك القديم أخيرًا. إذا غيرت سلوك التخزين المؤقت، كن حذرًا مع البيانات المخصصة وتأكد من أن الكاشات المشتركة لا تخلط بين المستخدمين.

إذا أردت نمذجة وشحن تغييرات الخادم بشكل أسرع، يمكن لـ AppMaster (appmaster.io) مساعدتك في نمذجة البيانات بصريًا، بناء منطق الأعمال بمحرّر سحب وإفلات، وإعادة توليد كود جاهز للإنتاج مع تغيّر المتطلبات.

جرّب نقطة نهاية مجمّعة واحدة بالإضافة إلى ETag على شاشة عالية الحركة أولًا. إذا تحسّنت الأرقام، ستعرف بالضبط أين تستثمر وقت الهندسة الإضافي.