Android DDMS: دليل إلى Ultimate Android Console

التطوير عمل صعب. يستمر الهدف في التحرك ، وتظهر التقنيات والمجالات الجديدة بشكل دوري ، وتظهر أدوات جديدة بين الحين والآخر ، وتتغير اللغات فيما يبدو أنه خراب مُدار.

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

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

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

DDMS في Android: سلاحي المفضل للاستبطان

لحسن الحظ بالنسبة لنا ، تمكن مجتمع Android من تقديم العديد من أدوات الاستبطان من الدرجة الأولى. Stetho من Facebook هو من بين الأفضل ، AT & T's ARO ("مُحسِّن موارد التطبيق") هو أقدم نوعًا ما ولكنه لا يزال من الدرجة الأولى ، مع ربما أفضل وحدة تحكم لمراقبة الشبكة ، بينما LeakCanary يتخذ طريقة أكثر محدودية في التركيز (ويقوم بعمل رائع في it) في مكتبة كشف تسرب الذاكرة وقت التشغيل. باختصار ، لا يوجد نقص في أدوات تصحيح أخطاء Android المتوفرة.

ومع ذلك ، لا يزال الماس الموجود في التاج ، أداة الاستبطان التي يمكن الوثوق بها عند الحاجة إلى استخراج بيانات مهمة ودقيقة ومنسقة جيدًا فيما يتعلق بسلوك وقت تشغيل تطبيقك ، هو خادم Dalvik Debug Monitor القديم الجيد (DDMS) في Android Studio ، والذي كان معنا (للأسف لا يستخدمه الكثير من الفرق) منذ أيام البرنامج الإضافي Eclipse Android.

ما هي أهمية DDMS في تطوير Android؟ حسنًا ، إن معرفة ما أعرفه الآن عن DDMS ومراقبة تطبيقات الأجهزة المحمولة بشكل عام يقول منذ 5-6 سنوات ، بصفتي مطور Android أقل خبرة ، أنقذني الكثير من المتاعب وليالي تصحيح الأخطاء.

والشيء هو أن نظام DDMS بسيط للغاية لإتقانه!

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

غالبًا ما يُطرح سؤال بخصوص الفرق بين مطوري الأجهزة المحمولة المبتدئين والمتخصصين. يعد إتقان DDMS في Android - أو بشكل عام ، تحديد سمات التطبيق وإمكانيات الاستبطان - أحد هذه الاختلافات الرئيسية.

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

دليل سريع لنظام DDMS في Android Studio

والآن ، دون مزيد من اللغط ، دعونا الآن نتعمق في وصف DDMS ، إحدى أدوات مطوري Android المثالية.

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

لنبدأ بدورة مكثفة في DDMS:

يمكن الوصول إلى DDMS عبر Studio> Tools> Android> Android Device Monitor والنقر فوق زر DDMS في القائمة. يمكنك أيضًا وضعه كرمز اختصار (أفعل) في اللوحة العلوية.

بمجرد الفتح ، هذا ما ستراه:

تسمح اللوحة اليسرى بتحديد الجهاز / التطبيق وتوفر لك وحدة التحكم اليمنى عدة طرق عرض ، كل منها في علامة تبويبها الخاصة ، كل منها يعرض عرضًا محددًا لتطبيقك.

الخدمات الرئيسية التي يقدمها Dalvik Debug Monitor Server هي:

• إحصائيات استخدام ذاكرة التطبيق (إجمالي الكومة وإحصاءات تخصيص الكائن)
• إحصائيات سلسلة التطبيق
• التقاط شاشة الجهاز
• مستكشف ملفات الجهاز
• انتحال المكالمات والرسائل القصيرة الواردة
• انتحال بيانات الموقع
• لوجكات

للحصول على قيمة ذاكرة الكومة الحالية التي يستخدمها تطبيقك ، ما عليك سوى القيام بما يلي:

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

ربما يتطلب هذا السطر الأخير شرحًا إضافيًا. يعد استخدام الذاكرة أحد تلك القيم التحليلية حيث تكون ديناميكياتها أكثر أهمية من القيمة الأولية. بالنسبة لمعظم التطبيقات ، لن نهتم كثيرًا بقيمة استخدام الكومة الأولية. سنهتم كثيرًا بتقدم هذه القيمة ، حيث ستزودنا بمؤشر واضح عن أحد الكوابيس الحقيقية التي تنتظر مطوري الأجهزة المحمولة - تسرب ذاكرة Android:

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

إذا تم الكشف عن تسرب للذاكرة ، فإن الأداة التالية التي سأستخدمها هي متتبع تخصيص الكائنات. دعونا نرى ما يمكن أن يفعله لإدارة الذاكرة في Android.

كائن تخصيص المقتفي

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

لبدء التتبع ، قم بما يلي:

• حدد الجهاز / العملية ذات الصلة كما كان من قبل
• قم بالتبديل إلى علامة التبويب Allocation Tracker وانقر فوق Start Tracking (بدء التتبع) للبدء.
• من هنا فصاعدًا سيتم تعقب جميع المخصصات الجديدة
• انقر فوق "الحصول على التخصيصات" للحصول على عرض قائمة بجميع التخصيصات الأخيرة (الأحدث منذ "البدء" الأخيرة)
• لمعرفة من هي سلطة التخصيص ، انقر فوق سطر معين في القائمة

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

وحدة تحكم معلومات الخيط: أصبح استخدام وحدة المعالجة المركزية في Android أمرًا سهلاً

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

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

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

وحدة تحكم مؤشر ترابط Android DDMS للإنقاذ!

عندما تدخل عرض سلسلة الرسائل ، سترى قائمة مكونة من سجلات الموضوع ، كل منها يحتوي على اسم ومعرف الموضوع ، وعدادان إضافيان يسمى utime and stime. يقيس Utime إجمالي الوقت الذي يقضيه مؤشر الترابط في تنفيذ رمز المستخدم (فكر في وظائفك ومكتبات الطرف الثالث) ، بينما يقيس stime إجمالي الوقت الذي يقضيه في رمز النظام (السكون ، والمزامنة ، واستدعاءات النظام - الكثير). عادة ما يكون الجزء الأول - الوقت المناسب - أكثر إثارة للاهتمام بالنسبة لنا ، على الرغم من أنني أستطيع التفكير في المشكلات التي ستظهر في الغالب من خلال عداد الستيم.

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

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

نصيحة: لا تستخدم الاسم الافتراضي للخيط. هذا لا يعني شيئًا وستفشل عادةً في اكتشافه في عروض DDMS. بدلاً من ذلك ، عند إنشاء سلسلة رسائل أو جلبها من مجموعة مؤشرات ترابط ، ابدأ تفاعلك عن طريق تعيين اسم لا يحتاج إلى شرح. هذا سيجعل حياتك أسهل من تصحيح أخطاء النظام الخاص بك. عادةً ما أقوم بإدخال اسم التطبيق مسبقًا للتمييز بين سلسلة الرسائل التي تم إنشاؤها بواسطة Android وتلك الناتجة عن الكود الخاص بي ، على سبيل المثال: MyApp-server-connector ، MyApp-db-dynamic ، إلخ.

نصيحة: تشير أولوية سلسلة الرسائل (بشكل فضفاض) إلى مقدار وقت وحدة المعالجة المركزية الذي يمنحه المجدول. إن الأولوية المعينة لسلاسل محادثات العاملين لديك ذات أهمية حاسمة للأداء العام و "سلاسة" تطبيقك ، وفي كثير من الحالات يمكن أن تكون الفرق بين السلوك السريع البارع والسلوك البطيء الوعر. القاعدة هنا بسيطة: الأولوية الافتراضية التي يحددها Android ، وهي NORMAL = 5 ، لا تكون دائمًا هي الأولوية التي تريد استخدامها. بدلاً من ذلك ، بالنسبة لمعظم مؤشرات الترابط العاملة ، فأنت تريد تأثيرًا أقل على الاستخدام الكلي لوحدة المعالجة المركزية. للقيام بذلك ، عند بدء تشغيل سلسلة رسائل ، اضبط أولويتها على قيمة أقل ، وعادةً ما أختار الأولوية = 3.

وحدة تحكم إحصائيات الشبكة

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

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

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

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

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

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

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

على الرغم من أنك نادرًا ما تستخدم هذه المعلومات ، لاحظ أن DDMS يعتمد على مكدس Android Debug Bridge (ADB) لتمرير البيانات مرة أخرى / من الجهاز. إذا فشل DDMS في إظهار تطبيقك ، أو تجمد في منتصف جلسة DDMS ، فسيكون أفضل رهان لك هو فتح وحدة تحكم وكتابة:

 adb devices

للتأكد من إمكانية الوصول إلى جهازك وترخيصه من خلال ADB. إذا لم يكن الأمر كذلك ، في كثير من الحالات ، يجب أن تؤدي إعادة تشغيل خادم ADB المحلي إلى حل المشكلة:

 adb kill-server adb devices # restarts the adb server and displays all detected devices

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

مثال على استخدام DDMS الواقعي: توقف التطبيق (لا يتوقف عن التعطل ، فقط يتوقف). يندفع المستخدم فورًا إلى محطة العمل القريبة ، ويتصل بـ USB ، ويفتح DDMS في عرض الخيط لاكتشاف مكدس الخيط »تتبع الخيط الفاشل» تتبع المكدس - في حالتي ، بسبب الجمود المزمن الذي ، بمجرد اكتشافه ، تم حله بسهولة عن طريق التبديل.

نصيحة: إذا كانت ذاكرة الوصول العشوائي القياسية المخصصة لتطبيقك من Android غير كافية ، كما قد يحدث ، على سبيل المثال ، التطبيقات كثيفة الوسائط ، فلاحظ أنه يمكنك الحصول على حوالي 15-20٪ من الذاكرة الإضافية على معظم الأجهزة عن طريق رفع _ علامة البيانات الكبيرة : https://developer.android.com/guide/topics/manifest/application-element.html_

محاكاة حالة الجهاز في Android DDMS

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

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

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

لكن مع ذلك - كيف سنتعامل مع حالات المحاكي؟ كيف يمكننا اختبارها لهذه التغييرات؟

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

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

يعد تنشيط حالة وإجراءات الاتصال الهاتفي أمرًا بسيطًا إلى حد ما:

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

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

تصبح الأمور أكثر إثارة عندما يتعلق الأمر بالسخرية من موقع جديد.

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

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

لهذا ، سنستخدم تنسيقًا خاصًا يسمى KML ، والذي تم تطويره خصيصًا لاستخدامه مع Google Earth ، والذي يمثل المسارات ، أو المسارات ، كمجموعة من النقاط المتصلة في الفضاء ، والتي يمكن أن تكون بواسطة الأجهزة التي تدعم نظام تحديد المواقع العالمي (GPS).

GPX هو تنسيق مسار بديل يدعمه DDMS. لجميع الأغراض العملية ، يجب اعتبار هذين النوعين قابلين للتبديل عند استخدامهما لانتحال موقع الهاتف المحمول.

دعونا ننتقل الآن عبر مراحل تعيين مسار وهمي في المحاكي.

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

1. بمجرد عرض المسار على الخريطة ، انتقل إلى سطر العنوان وانسخ عنوان URL

2. باستخدام عنوان URL في الحافظة ، انتقل إلى GPS Visualizer ، والصقه في مربع النص "توفير عنوان URL" ، وانقر فوق الزر "تحويل":

وانقر لتنزيل ملف GPX الناتج (باسم فوضوي إلى حد ما ، على سبيل المثال ، 20170520030103-22192-data.gpx)

1. بالعودة إلى DDMS Location Control ، افتح علامة تبويب GPX ، وانقر فوق تحميل GPX وحدد الملف الذي تم تنزيله حديثًا

1. لقد انتهينا! يمكنك الآن التنقل بين مواقع المسار المختلفة عن طريق النقر فوق زري "للخلف" و "الأمام" ، أو عن طريق النقر فوق الزر "تشغيل" للتنقل تلقائيًا عبر المسار بسرعة محددة.

لا تحتاج إلى إنشاء مسارك الخاص. الكثير من المسارات للتنزيل من موقع مثل OpenStreetMap (راجع قسم "تتبع نظام تحديد المواقع العالمي").

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

على سبيل المثال ، يبدو أن GPX 1.1 فقط مدعوم بواسطة DDMS. قد تتطلب إصدارات GPX الجديدة بعض الضبط اليدوي.

بالإضافة إلى ذلك ، لم يعد تنسيق إحداثية GPX مدعومًا. بدلاً من ذلك ، استخدم تنسيق GPX Track:

 <trk> <name /> <cmt /> <trkseg> <trkpt lat="27.0512" lon="-80.4324"> <ele>0</ele> <time>2017-02-02T08:01:41Z</time> </trkpt> </trkseg> </trk>

تصحيح أخطاء Android: ساعة في الأسبوع تحدث فرقًا!

كفى نظرية! حان الوقت الآن لبعض التدريب. أقترح ، بافتراض أنك مطور Android ، أنه بدءًا من مشروعك التالي ، ستخصص ساعة واحدة فقط في الأسبوع لاكتساب التأمل في أداء تطبيقك عبر DDMS.

ستندهش من كمية معلومات الجودة (أي المعلومات التي يمكن استخدامها لتحسين حالة تطبيقك على الفور) وهذا سيوفر لك!

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

كن واحدا من الرجال الأذكياء. استخدمه.