تسهّل أُطر عمل الويب، مثل Angular وReact وVue وSvelte، كتابة تطبيقات الويب المعقّدة وصيانتها على نطاق واسع.
ومع ذلك، تقدّم هذه الأُطر طبقة تجريد فوق نموذج تطبيق المتصفّح. في الواقع، ينتهي الأمر بالرمز الذي يكتبه المطوّرون باستخدام هذه التجريدات إلى أن يتم تحويله إلى رمز غير قابل للقراءة ومصغّر ومجمّع. نتيجةً لذلك، قد يواجه المطوّرون صعوبة في الاستفادة الكاملة من إمكانات "أدوات المطوّرين" لتصحيح أخطاء هذه التطبيقات وتحديد خصائصها.
على سبيل المثال، عند إنشاء ملف تعريف لتطبيق Angular باستخدام لوحة الأداء في "أدوات مطوّري البرامج"، سيظهر لك ما يلي:
وباستخدام المعلومات المعروضة بهذه الطريقة، قد يكون من الصعب تحديد المشاكل التي تؤدي إلى بطء الأداء في قاعدة الرموز البرمجية. ففي النهاية، لا يتضمّن هذا الملف سياق بنى إطار العمل، كما أنّ جزءًا كبيرًا من المعلومات المعروضة يكون على شكل رمز مصغّر. من الصعب أيضًا التمييز بين النشاط المرتبط مباشرةً بالرمز الذي كتبته، والعمليات الداخلية للإطار، والرموز الأخرى التابعة لجهات خارجية والتي قد يتم تشغيلها على الصفحة نفسها.
من الأسباب الشائعة التي تدفع مؤلفي الأُطر والتجريد إلى تنفيذ إضافات DevTools الخاصة بهم، عرض بيانات تحديد المشاكل من حيث مفاهيم الأُطر. تكون هذه الأدوات مفيدة جدًا عند تصحيح الأخطاء وتحديد المشاكل في التطبيقات التي تم إنشاؤها باستخدام إطار عمل معيّن. ومع ذلك، ستجد نفسك في أغلب الأحيان بحاجة إلى ربط بيانات إطار العمل في أداة تحليل الأداء الخاصة بإطار العمل بمعلومات وقت التشغيل في المتصفّح في لوحة الأداء ضمن "أدوات مطوّري البرامج". يصعّب عرض هذين المصدرَين للبيانات بشكل منفصل في أدوات مستقلة رصد المشاكل وحلّها، خاصةً عندما يصبح التطبيق أكثر تعقيدًا. في ما يلي مثال على تصور الملف الشخصي في أداة Profiler في Angular DevTools:
في الحالة المثالية، سيتمكّن المطوّرون من عرض مصدرَي البيانات معًا في السياق نفسه على المخطط الزمني نفسه.
لهذا السبب، تعاونّا مع فريق Angular لدمج بيانات وقت تشغيل Angular مباشرةً في لوحة الأداء باستخدام واجهة برمجة التطبيقات الخاصة بإمكانية توسيع لوحة "الأداء". في هذه المشاركة، سنتعرّف على إمكانات واجهة برمجة التطبيقات وكيفية استخدامها في إطار عمل Angular لتحقيق ذلك. يمكن أن يكون التنفيذ مثالاً على الأُطر والملخّصات الأخرى التي تسعى إلى تحسين تجربة المطوّرين من خلال تزويد أدواتها الخاصة بالمقاييس ومساعدة المطوّرين في استخدام "أدوات مطوّري البرامج في Chrome".
ما هي واجهة برمجة التطبيقات الخاصة بإمكانية توسيع لوحة "الأداء"؟
تتيح لك واجهة برمجة التطبيقات إضافة إدخالات التوقيت الخاصة بك إلى تتبُّع لوحة الأداء، وذلك ضمن المخطط الزمني نفسه الذي تتضمّنه بقية بيانات المتصفّح. هناك آليتان تتيحان لك إجراء ذلك:
- واجهة برمجة تطبيقات User Timing
- واجهة برمجة التطبيقات
console.timeStamp
واجهة برمجة تطبيقات User Timing
يمكنك استخدام performance.mark وperformance.measure لإضافة الإدخالات على النحو التالي:
// Mark used to represent the start of some activity you want to measure.
// In this case, the rendering of a component.
const renderStart = performance.now();
// ... later in your code
performance.measure("Component rendering", {
start: renderStart,
detail: {
devtools: {
dataType: "track-entry",
track: "Components",
color: "secondary",
properties: [
["Render reason", "Props changed"],
["Priority", "low"]
],
}
}
});
سيؤدي ذلك إلى إضافة مسار المكوّنات إلى المخطط الزمني مع القياس:
تتيح لك واجهة برمجة التطبيقات هذه إضافة الإدخالات إلى المخزن المؤقت لمخطط الأداء الزمني، مع عرضها أيضًا في واجهة مستخدم لوحة الأداء في "أدوات مطوّري البرامج".
يمكنك الاطّلاع على مزيد من المعلومات حول واجهة برمجة التطبيقات هذه وعن العنصر devtools في المستندات.
واجهة برمجة التطبيقات console.timeStamp
تُعدّ واجهة برمجة التطبيقات هذه بديلاً بسيطًا لواجهة برمجة التطبيقات User Timing API. باستخدام المثال نفسه كما في السابق، يمكنك الحصول على ما يلي:
// Mark used to represent the start of some activity you want to measure.
// In this case, the rendering of a component.
const renderStart = performance.now();
// ... later in your code
console.timeStamp(
"Component rendering",
/* start time */ renderStart,
/* end time (current time) */ undefined,
/* track name */ "Components",
/* track group name */ undefined,
/* color */ "secondary"
);
توفّر واجهة برمجة التطبيقات هذه طريقة عالية الأداء لتسجيل التطبيقات: على عكس بديل User Timing API، لا تنشئ بيانات مخزّنة مؤقتًا. تضيف واجهة برمجة التطبيقات هذه البيانات حصريًا إلى لوحة **الأداء** في "أدوات مطوّري البرامج"، ما يعني أنّه عندما لا تسجّل "أدوات مطوّري البرامج" عملية تتبُّع، لا تنفّذ طلبات البيانات من واجهة برمجة التطبيقات أي عمليات (أي أنّها لا تفعل أي شيء)، ما يجعلها أسرع بكثير ومناسبة للمسارات السريعة التي تتطلّب أداءً عاليًا. إنّ اختيار استخدام وسيطات موضعية بدلاً من عنصر يحتوي على جميع مَعلمات التخصيص يخدم أيضًا الغرض من إبقاء واجهة برمجة التطبيقات بسيطة قدر الإمكان.
يمكنك الاطّلاع على مزيد من المعلومات حول استخدام console.timeStamp لتوسيع "لوحة الأداء" والمَعلمات التي يمكنك إدخالها في المستندات.
طريقة دمج Angular لواجهة برمجة التطبيقات القابلة للتوسيع في "أدوات مطوّري البرامج"
سنتعرّف على كيفية استخدام فريق Angular لواجهة برمجة التطبيقات الخاصة بإمكانية التوسيع من أجل الدمج مع "أدوات مطوّري البرامج في Chrome".
تجنُّب الحمل الزائد باستخدام console.timestamp
تتوفّر أداة Angular مع واجهة برمجة التطبيقات القابلة للتوسيع في لوحة الأداء اعتبارًا من الإصدار 20. يتطلّب مستوى التفصيل المطلوب لبيانات الأداء في "أدوات مطوّري البرامج" واجهة برمجة تطبيقات سريعة، لذا اختار طلب السحب (60217) الذي أضاف أداة القياس استخدام واجهة برمجة التطبيقات console.timeStamp. ويمنع ذلك تأثُّر أداء وقت تشغيل التطبيق بالعبء المحتمل لواجهة برمجة التطبيقات الخاصة بإنشاء الملفات الشخصية.
البيانات التي تم قياسها
لتقديم صورة جيدة عن التعليمات البرمجية التي يتم تنفيذها في Angular وسبب تنفيذها في المقام الأول، يتم تزويد أجزاء متعددة من مسارات بدء التشغيل والعرض بأدوات، بما في ذلك:
- بدء تشغيل التطبيق والمكوّنات
- إنشاء المكوّنات وتعديلها
- تنفيذ أدوات معالجة الأحداث وخطوات دورة الحياة
- العديد من الميزات الأخرى (مثل إنشاء المكوّنات الديناميكية وعرض الحظر المؤجّل).
الترميز بالألوان
يتم استخدام الترميز اللوني لإعلام المطوّر بالفئة التي يندرج فيها إدخال قياس معيّن. على سبيل المثال، تختلف الألوان المستخدَمة في الإدخالات التي تشير إلى تنفيذ رمز TypeScript الذي أنشأه المطوّر عن الألوان المستخدَمة في الرمز الذي أنشأه برنامج التجميع Angular.
في لقطة الشاشة التالية، يمكنك الاطّلاع على كيفية ظهور نقاط الدخول (مثل رصد التغيير ومعالجة المكوّنات) باللون الأزرق، والرمز البرمجي الذي تم إنشاؤه باللون الأرجواني، ورمز TypeScript (مثل أدوات معالجة الأحداث وخطافات) باللون الأخضر.
يُرجى العِلم أنّ وسيطة اللون التي يتم تمريرها إلى واجهة برمجة التطبيقات ليست قيمة لون CSS، بل هي رمز دلالي يتم ربطه بلون يتطابق مع واجهة مستخدم "أدوات مطوّلي البرامج". القيم المحتمَلة هي primary وsecondary وtertiary, مع الخيارات -dark و-light الخاصة بها بالإضافة إلى اللون error.
المقاطع الصوتية
في وقت كتابة هذا المقال، تتم إضافة جميع بيانات وقت التشغيل في Angular إلى المسار نفسه (المصنّف "🅰️ Angular"). ومع ذلك، من الممكن إضافة مقاطع متعددة إلى التتبُّع وحتى تجميع المقاطع. على سبيل المثال، في حال إجراء الطلبات التالية إلى واجهة برمجة التطبيقات console.timeStamp:
console.timeStamp("Component 1", componentStart1, componentEnd1, "Components", "Client", "primary");
console.timeStamp("Component 2", componentStart2, componentEnd2, "Components", "Client", "primary");
console.timeStamp("Hook 1", hookStart, hookEnd, "Hooks", "Client", "primary");
console.timeStamp("Fetch data base", fetchStart, fetchEnd, "Server", "primary");
ستظهر لك البيانات منظَّمة في مسارات بالطريقة التالية:
يمكن أن يكون استخدام مسارات منفصلة مفيدًا، على سبيل المثال، عندما يكون لديك نشاط غير متزامن أو مهام متعددة تعمل بالتوازي أو مجموعات أنشطة مميزة بما يكفي لتبرير فصلها في مناطق مختلفة من واجهة المستخدم.
أهمية ذلك لمطوّري Angular
والهدف من هذا الدمج المباشر هو تقديم تجربة أكثر بساطة وشمولاً لتحليل الأداء. من خلال عرض بيانات الأداء الداخلية في Angular مباشرةً ضمن لوحة **الأداء**، سيحصل المطوّرون على ما يلي:
- تحسين مستوى الظهور: إتاحة إمكانية الاطّلاع على أحداث الأداء الخاصة بـ Angular، مثل عرض المكوّنات ودورات رصد التغييرات وغير ذلك، ضمن المخطط الزمني الأوسع للمتصفّح
- فهم محسّن: من خلال معلومات غنية بالسياق حول العمليات الداخلية في Angular، ما يساعدك على تحديد المشاكل التي تؤدي إلى بطء الأداء بفعالية أكبر.
تفعيل عملية الدمج
تتوفّر واجهة برمجة التطبيقات القابلة للتوسيع رسميًا في إصدارات التطوير اعتبارًا من الإصدار 20 من Angular. لتفعيلها، عليك تشغيل الأداة المساعدة العامة `ng.enableProfiling()` في تطبيقك أو في وحدة تحكّم "أدوات مطوّري البرامج". يمكنك الاطّلاع على مزيد من المعلومات حول عملية الدمج في [مستندات Angular](https://angular.dev/best-practices/profiling-with-chrome-devtools).
اعتبارات أخرى
بعض الاعتبارات المهمة التي يجب أخذها في الاعتبار
خرائط المصدر والرمز المصغَّر:
خرائط المصدر هي أداة مستخدَمة على نطاق واسع تهدف إلى سد الفجوة بين الرمز المجمَّع أو المصغَّر والرمز الأصلي، لذا...
أليس من المفترض أن تحلّ خرائط المصدر مشكلة الرمز المصغَّر في التطبيقات المجمّعة؟
على الرغم من أنّ خرائط المصدر مفيدة بالفعل، إلا أنّها لا تزيل التحديات تمامًا عند إنشاء ملفات تعريف لتطبيقات الويب المعقّدة المصغّرة. تسمح خرائط المصدر لـ "أدوات مطوّري البرامج" بربط الرمز المصغَّر برمز المصدر الأصلي، ما يسهّل عملية تصحيح الأخطاء. ومع ذلك، قد يظلّ الاعتماد على خرائط المصدر فقط في تحليل الأداء يفرض بعض القيود. على سبيل المثال، يكون اختيار طريقة الفصل المرئي بين الأجزاء الداخلية للإطار والرمز البرمجي الذي تم إنشاؤه أمرًا معقّدًا باستخدام خرائط المصدر وحدها. من ناحية أخرى، توفّر واجهة برمجة التطبيقات القابلة للتوسيع المرونة اللازمة لتحقيق هذا التمييز وعرضه بالطريقة التي يراها المطوّر الأنسب.
إضافات "أدوات مطوّري البرامج في Chrome":
تُعدّ إضافات Chrome التي تستخدم DevTools API أداة مستخدَمة على نطاق واسع لتوسيع أدوات المطوّرين.
هل أصبحت أدوات تحليل الأداء المخصّصة (مثل إضافات "أدوات مطوّري البرامج في Chrome") غير ضرورية أو يُنصح بعدم استخدامها الآن بعد توفّر واجهة برمجة التطبيقات هذه؟
لا، ليس الهدف من هذه الواجهة استبدال أدوات تحليل الأداء المخصّصة أو تثبيط تطويرها، مثل إضافات "أدوات مطوّري البرامج في Chrome". ويمكن أن تقدّم هذه الأدوات ميزات وعروضًا مرئية ومسارات عمل متخصصة مصمَّمة لتلبية احتياجات معيّنة. تهدف واجهة برمجة التطبيقات القابلة للتوسيع في لوحة الأداء إلى إنشاء تكامل سلس للبيانات المخصّصة مع الرسومات المرئية في المتصفّح ضمن لوحة الأداء.
المسار المستقبلي
آفاق واجهة برمجة التطبيقات القابلة للتوسيع
العمل مع المزيد من الأُطر والتجريدات
نحن متحمّسون لأنّ الأُطر والملخّصات الأخرى ستعتمد واجهة برمجة التطبيقات هذه لتحسين تجربة مطوّريها في إنشاء الملفات الشخصية. على سبيل المثال، نفّذت React تجربة لاعتماد واجهة برمجة التطبيقات في إطار عملها. تُظهر هذه الأداة عملية عرض مكوّنات العميل والخادم، بالإضافة إلى بيانات واجهات برمجة التطبيقات الخاصة بجدولة React. يمكنك الاطّلاع على مزيد من المعلومات عن هذه الميزة وكيفية تفعيلها على صفحة React.
الإصدارات العلنية
أحد أهداف واجهة برمجة التطبيقات هذه هو العمل مع الأُطر وموفّري التجريد بشكل عام من أجل اعتماد إمكانية القياس وتفعيلها في الإصدارات المتاحة للجميع. قد يكون لذلك تأثير كبير في أداء التطبيقات التي تم تطويرها باستخدام هذه التجريدات، إذ سيتمكّن المطوّرون من تحديد خصائص التطبيق كما يختبرها المستخدمون. نعتقد أنّ واجهة برمجة التطبيقات console.timeStamp تتيح تحقيق ذلك، نظرًا إلى سرعتها وانخفاض تكاليفها. ومع ذلك، لا تزال الأُطر في مرحلة تجريب واجهة برمجة التطبيقات واستكشاف أنواع الأدوات التي يمكن للمطوّرين استخدامها على نطاق أوسع والاستفادة منها بشكل أكبر.