الخدمة المرجعية لتطبيقات الهاتف المتحرك

رسلان أروماتوف ، كبير المطورين ، ICD



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

خلفية


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

لكن هذا المخطط البسيط لا يعمل لسبب واحد بسيط - لا يتم تحديث جميع العملاء. وبحسب الإحصائيات ، هناك الكثير من هؤلاء العملاء.

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

"الابتدائية!" - قول انت. - "قم بتنزيل هذه البيانات من الخادم وستكون سعيدًا."

وستكون على حق. نفعل ذلك. هذا كل شيء ، نحن نختلف .

ومع ذلك ، ليست كلها بهذه البساطة. لدينا تطبيقات لكل من iOS و Android. تحتوي كل منصة على العديد من الإصدارات المختلفة التي لها وظائف مختلفة و api.
نتيجة لذلك ، قد يحدث أننا بحاجة إلى تحديث الملف لتطبيق Android مع إصدار واجهة برمجة تطبيقات أعلى من 27 ، ولكن لا نلمس iOS والإصدارات السابقة.

اتضح أنه أكثر إثارة للاهتمام عندما نحتاج ، على سبيل المثال ، إلى تحديث رموز مستلمي الدفع أو إضافة عناصر جديدة برموز جديدة. نرسم كل مثيل من الأيقونة بسبع درجات دقة مختلفة لكل نوع معين من الشاشات: لنظام Android لدينا 4 منها (hdpi و xhdpi و xxhdpi و xxxhdpi) و 3 لنظام التشغيل iOS (1x و 2 x و 3 x). أيهما يجب أن أرسل إلى تطبيق معين؟

"حسنًا ، قم بإرسال معلمات الملف التي يحتاجها تطبيق معين."

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

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

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

أيقونات التشغيل

"ثم قم بتنزيل مجموعة الرموز بالكامل في أرشيف واحد عند بدء تشغيل التطبيق."

تفكير جيد. لا حقا. ولكن هناك فارق بسيط.

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

ونحن لم نحسب بعد تكلفة هذا العمل على الخادم. لنفترض أن 10000 عميل في الساعة يأتون إلينا (هذه هي القيمة المتوسطة ، ويحدث ذلك أكثر). تحديث التطبيق بداية يبادر خلفية الدلائل(نعم ، أنت تعرف الآن ما نسميه). إذا احتاج عميل واحد إلى تحديث كيلوبايت واحد ، فبعد ساعة سيعطي الخادم أكثر من 10 ميغابايت. البنسات ، أليس كذلك؟ وإذا كانت مجموعة التحديثات تزن 1 ميغا بايت؟ في هذه الحالة ، يجب أن نعطي بالفعل 10 غيغابايت. في مرحلة ما ، نصل إلى استنتاج مفاده أنه ينبغي النظر في حركة المرور.

ثم تحتاج إلى معرفة كيفية فهم الملفات التي تم تغييرها وتغييرها ، وتنزيل الملفات الضرورية فقط.

حق. ولكن كيف نفهم الملفات التي تغيرت والتي لم تتغير؟ نعتبر تجزئة لهذا. وبالتالي ، تظهر ذاكرة تخزين مؤقت معينة للملف في التطبيق ، والتي تحتوي على مجموعة من الملفات المرجعية. يتم استخدام هذه الملفات كموارد حسب الحاجة. وعلى جانب الخادم ، ولدنا في النهاية ...

خدمة الدليل


بشكل عام ، هذه خدمة ويب عادية ترسل الملفات عبر http مع مراعاة جميع متطلبات التطبيق. يتكون من عدد من حاويات السفن ، حيث يعمل تطبيق java مع خادم الويب jetty على متن الطائرة. الواجهة الخلفية هي قاعدة بيانات Tarantool على محرك الفينيل (لم يكن هناك أي خيار مؤلم - كان لديها فقط الربط الكامل لقاعدة البيانات هذه ؛ يمكنك القراءة عنها في مقالتي السابقة خدمة التخزين المؤقت الذكي المستندة إلى ZeroMQ و Tarantool ) مع النسخ المتماثل الرئيسي. لإدارة الملفات ، توجد واجهة ويب للخدمة ، مكتوبة ذاتيًا تمامًا.



تفاصيل التنفيذ الفني في موضوع هذه المقالة ليست ذات أهمية خاصة. يمكن أن يكون php + apache + mysql أو C # + IIS + MSSQL أو أي حزمة أخرى ، بما في ذلك بدون قاعدة بيانات على الإطلاق.

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

مخطط العمل

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

الملفات الضرورية في التطبيقات ، نقسم إلى 3 أنواع مختلفة.

  1. الملفات التي يجب أن تكون دائمًا في التطبيق ، ومستقلة عن نوع نظام التشغيل. على سبيل المثال ، هذا ملف pdf مع اتفاقية خدمة مصرفية.
  2. -, , ( ) . , .
  3. , , . - , , . , .

إنضم لبرنامج

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

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

2. وفقًا للجدول الزمني (أو عن طريق الزر) ، تعمل الخدمة من خلال جميع ملفات جميع الأدلة ، وتشكل على أساسها مجموعة من ملفات الفهرس (داخل json) لكل من الملفات من النوع الأول (نسختان لنظامي iOS و android) ، وملفات الموارد من النوع الثاني اكتب (7 إصدارات لكل نوع من أنواع الشاشة).
يبدو شيء من هذا القبيل:

{
  "version": "43",
  "date": "04 Apr 2020 12:31:59",
  "os": "android",
  "screen": "any",
  "hashType": "md5",
  "ts": 1585992719,
  "files": [
    {
      "id": "WBRbDUlWhhhj",
      "name": "action-in-rhythm-of-life.json",
      "dir": "actions",
      "ts": 1544607853,
      "hash": "68c589c4fa8a44ded4d897c3d8b24e5c"
    },
    {
      "id": "o3K4mmPOOnxu",
      "name": "banks.json",
      "dir": "banks",
      "ts": 1583524710,
      "hash": "c136d7be420b31f65627f4200c646e0b"
    }
  ]
}

تحتوي الفهارس على معلومات حول جميع الملفات من نوع معين ، والتي يتم على أساسها بناء آلية تحديث الأدلة على التطبيقات.

3. التطبيقات عند بدء التشغيل ، أول شيء يتم تنزيله هو ملفات الفهرس في الدليل / الجديد داخل ذاكرة التخزين المؤقت للملفات. وفي الدليل / الحالي لديهم فهارس للمجموعة الحالية من الملفات مع الملفات نفسها.

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

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

6. بمجرد استلام مجموعة الملفات بالكامل في الدليل / الجديد ، يتم فحصها مقابل ملف الفهرس (في بعض الأحيان حدث عدم تحميل الملفات بالكامل).

7. في حالة نجاح الفحص ، يتم نقل شجرة الملفات بالكامل مع الاستبدال في الدليل الحالي . يصبح ملف الفهرس الحديث الحالي.

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

لكن لماذا هو صعب جدا؟

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

نقطة مهمة هي توفير حركة المرور. كانت هناك أوقات استخدمنا فيها تمامًا قناة 100 ميغابت بعد التحديثات الكثيفة. كان علي أن أتوسع إلى 300. حتى الآن ، يكفي. في المتوسط ​​، تظهر المقاييس أنه عادة ما يقوم العملاء بتنزيل من 25 إلى 50 جيجا بايت في الساعة خلال اليوم (هذا لأن لدينا ملفات كبيرة جدًا يتم تحديثها يوميًا). لا يزال هناك مجال لمزيد من التطوير من حيث الاقتصاد ، ولكن الأعمال في حالة تأهب أيضًا - طوال الوقت يضيفون مجموعة متنوعة من الجمال الجديد.

في الختام ، يمكنني أن أضيف أن الخوادم الأمامية نفسها تستخدم أيضًا الخدمة ، التي تقوم ، عند بدء التشغيل ، بتنزيل البيانات اللازمة لمعالجة طلبات العملاء.

وكيف تقدم تحديثات المحتوى للتطبيقات؟

All Articles