الفرق بين المراجعتين لصفحة: «React/profiler»
رقية-بورية (نقاش | مساهمات) إفراغ الصفحة وسمان: إفراغ المحرر المرئي: تبديل |
جميل-بيلوني (نقاش | مساهمات) طلا ملخص تعديل |
||
(3 مراجعات متوسطة بواسطة مستخدمين اثنين آخرين غير معروضة) | |||
سطر 1: | سطر 1: | ||
<noinclude>{{DISPLAYTITLE:واجهة برمجة مراقب الأداء (Profiler API) في React}}</noinclude> | |||
يُحدد الفاحص <code>Profiler</code> عدد المرات التي يُصيَّر فيها تطبيق React وما عبء تلك العملية على أداء التطبيق، إذ يهدف ذلك إلى تحديد أجزاء التطبيق الأبطأ والتي قد تحتاج إلى استخدام تقنيات مخصصة لتحسين أدائها مثل [[React/hooks faq#.D9.83.D9.8A.D9.81 .D9.8A.D9.85.D9.83.D9.86 .D8.A7.D8.B3.D8.AA.D8.B8.D9.87.D8.A7.D8.B1 .28memoize.29 .D8.A7.D9.84.D8.B9.D9.85.D9.84.D9.8A.D8.A7.D8.AA .D8.A7.D9.84.D8.AD.D8.B3.D8.A7.D8.A8.D9.8A.D8.A9.D8.9F|تقنية الاستظهار]] (memoization). | |||
'''ملاحظة''': تُضيف عملية فحص الأداء (Profiling) تكاليف حاسوبية إضافية (أي استهلاك زائد للمعالج والذاكرة) لذا فهي مُعطَّلة افتراضيًا في الإصدار النهائي للتطبيق، لكن إذا أردت تضمينها في النسخة النهائية لتطبيقك فإن [[React]] يُتيح إطلاق نُسخة نهائية من التطبيق تضم عملية التعريف. راجع [https://fb.me/react-profiling دليل عملية فحص الأداء في React] الأجنبي لمزيد من التفاصيل حول كيفية استخدام هذا الإصدار. | |||
== كيفية الاستخدام == | |||
يمكنك إضافة عملية فحص أداء (مكون <code>Profiler</code>) في أيّ مكان ضمن هيكل [[React]] الشجري (tree) لقياس تكلفة تصيير ذلك القسم من الهيكل. يتطلب ذلك استخدام خاصيتين: الأولى هي مُعرّف العملية <code>id</code> والثانية هي دالّة رد نداء (callback function) باسم <code>onRender</code> تُستدعَى تلقائيًا عندما يُجرِي أي مُكوِّن في ذلك الهيكل تحديثًا ما. | |||
على سبيل المثال هكذا سيبدو استعلام تعريف مُكوِّن التنقل <code>Navigation</code> وأجزائه الفرعية: | |||
<syntaxhighlight class="" lang="html">render( | |||
<App> | |||
<Profiler id="Navigation" onRender={callback}> | |||
<Navigation {...props} /> | |||
</Profiler> | |||
<Main {...props} /> | |||
</App> | |||
);</syntaxhighlight> | |||
يمكنك أيضًا استخدام مُكوِّنات <code>Profiler</code> متعددة لقياس أداء أجزاء مختلفة من التطبيق كما في المثال التالي: | |||
<syntaxhighlight class="" lang="html">render( | |||
<App> | |||
<Profiler id="Navigation" onRender={callback}> | |||
<Navigation {...props} /> | |||
</Profiler> | |||
<Profiler id="Main" onRender={callback}> | |||
<Main {...props} /> | |||
</Profiler> | |||
</App> | |||
);</syntaxhighlight> | |||
يمكنك أيضًا إنشاء مُكوِّنات <code>Profiler</code> مُتداخلة لقياس مُكوِّنات مختلفة ضمن نفس القسم من الهيكل الشجري كما هو موضح أدناه: | |||
<syntaxhighlight class="" lang="html">render( | |||
<App> | |||
<Profiler id="Panel" onRender={callback}> | |||
<Panel {...props}> | |||
<Profiler id="Content" onRender={callback}> | |||
<Content {...props} /> | |||
</Profiler> | |||
<Profiler id="PreviewPane" onRender={callback}> | |||
<PreviewPane {...props} /> | |||
</Profiler> | |||
</Panel> | |||
</Profiler> | |||
</App> | |||
);</syntaxhighlight> | |||
'''ملاحظة''': مع أنّ المكون <code>Profiler</code> يُعَدّ مكوِّنًا خفيفًا على وحدة المعالجة إلا أنه يُنصح باستخدامه عند الضرورة فقط، إذ يضيف كل استخدام بعض العبء على المُعالج والذاكرة مما قد يؤثِّر على أداء التطبيق ككُل. | |||
== دالة المعالجة اللاحقة (onRender Callback) == | |||
يتطلب مُراقب الأداء <code>Profiler</code> تحديد دالّة رد نداء (Callback) تُفعّل عند بدء التصيير أو المُعالجة (<code>onRender</code>) كإحدى الخاصيات الممرة إليه. ستستدعي React هذه الدالة في كل مرة يُحدَّث فيها أحد المُكوِّنات المذكورة ضمن المكوِّن <code>Profiler</code>. عندها ستستقبل تلك الدالّة مُعامِلات تصِف ما تم مُعالجته وما الوقت الذي استغرقه ذلك. | |||
<syntaxhighlight class="" lang="javascript">function onRenderCallback( | |||
id, // نص يُمثل خاصية مُعرّف القسم من مراقب الأداء الذي أجرى التحديث | |||
phase, // إما "mount" إذا كانت العملية نُفِّذت للمرة الأولى أو "update" إذا طرأ تحديث ما تسبب بإعادة التصيير | |||
actualDuration, // الوقت المُستغرق لتصيير التحديث الحالي | |||
baseDuration, // الوقت المُقدر لتصيير القسم الفرعي من الهيكل بدون استخدام تقنيات تسريع | |||
startTime, // الوقت الذي بدأ فيه ريآكت بتصيير التحديث | |||
commitTime, // الوقت الذي أنهى فيه ريآكت إرسال التحديث | |||
interactions // مجموعة التفاعلات المتعلقة بالتحديث الحالي | |||
) { | |||
// سِجل توقيت عمليات التصيير | |||
}</syntaxhighlight> | |||
لنُلقِ نظرةً عن تلك الخصائص سابقة الذكر: | |||
* '''<code>id</code> (المُعرِّف)''': هو نص يُمثل خاصية <code>id</code> للقسم المُعين من شجرة <code>Profiler</code> الذي أجرى التحديث. يمكن استخدام هذا المعرف لتحديد أيّ جزء من الهيكل قد حُدّث في حال كنت تستخدم مُعرِّفات متعددة. | |||
* '''<code>phase</code> (طُور العملية)''': تُمثّل هذه الخاصية بإحدى قيمتين (update أو mount) واللذان يُحددان إذا ما كانت العملية التي أُجريت على القسم المُحدد من الهيكل قد نُفِّذت للمرة الأولى أو أُعيد تصييرها نتيجة تحديث أحد الخصائص أو حالة المُكوِّنات أو الأحداث المُرتبطة بها. | |||
* '''<code>actualDuration</code> (مُدَّة التنفيذ الفعلية)''': تُمثّل هذه الخاصية برقم يُعبر عن الوقت المُستغرق لتصيير عملية <code>Profiler</code> ومُكوناتها الداخلية للتحديث الحالي. يُشير هذا الرقم إلى مدى فعالية تقنيات التسريع (مثل [[React/react api#React.memo|React.memo]] أو [[React/hooks reference#useMemo|useMemo]] أو [https://wiki.hsoub.com/React/hooks_faq#.D9.83.D9.8A.D9.81_.D9.8A.D9.85.D9.83.D9.86.D9.86.D9.8A_.D8.AA.D9.86.D9.81.D9.8A.D8.B0_shouldComponentUpdate.D8.9F shouldComponentUpdate]) المستخدَمة في هذا القسم من الهيكل الشجري. في العادة يُفترضانخفاض قيمة هذه الخاصية كثيرًا موازنةً بالقيمة الأولية، لأنّ العديد من المُكوِّنات الداخلية لا تحتاج إلى إعادة التصيير ما لم يطرأ أيّ تغيير على خصائصها. | |||
* '''<code>baseDuration</code> (مُدَّة التنفيذ الأساسية)''': تُمثّل هذه الخاصية أيضًا برقم يُعبر عن الوقت الذي استغرقته آخر عمليات التصيير لكلّ مُكوِّن ضمن الهيكل الشجري. تُستخدم هذه القيمة لتقدير تكلفة التصيير في أسوأ الحالات (مثلًا عند التصيير للمرة الأولى أو في حالة عدم استخدام أيّ تقنيات تسريع). | |||
* <code>'''startTime'''</code> '''(وقت البدء)''': وهو رقم يُمثل الطابع الزمني للحظة بدء React بتصيير التحديث الحالي لإحدى المُكوِّنات. | |||
* '''<code>commitTime</code> (وقت التنفيذ)''': وهو رقم يُمثل الطابع الزمني للحظة تنفيذ React للتحديث الحالي على أحد المُكوِّنات. تتشارك جميع عمليات التعريف هذه القيمة عند تنفيذ التحديث مما يُتيح تجميعها معًا إذا رغب المُطوِّر في ذلك. | |||
* '''<code>interactions</code> (التفاعلات)''': وهي مجموعة التفاعلات التي يجري تتبُّعها عند جدولة التحديث (مثلًا عند التصيير أو عند تفعيل دالّة <code>setState</code>). | |||
'''ملاحظة''': يمكن استخدام التفاعلات (Interactions) لتحديد سبب التحديث لكن يجدر بك معرفة أنّ واجهة التطوير الخاصة بها لا تزال تحت الاختبار. راجع [https://fb.me/react-interaction-tracing توثيق تتبع التفاعلات] لمزيد من المعلومات عن هذه النقطة. | |||
== المصادر == | |||
* [https://reactjs.org/docs/profiler.html صفحة Profiler API من توثيق React الرسمي] | |||
[[تصنيف: React]] |
المراجعة الحالية بتاريخ 16:11، 11 أبريل 2021
يُحدد الفاحص Profiler
عدد المرات التي يُصيَّر فيها تطبيق React وما عبء تلك العملية على أداء التطبيق، إذ يهدف ذلك إلى تحديد أجزاء التطبيق الأبطأ والتي قد تحتاج إلى استخدام تقنيات مخصصة لتحسين أدائها مثل تقنية الاستظهار (memoization).
ملاحظة: تُضيف عملية فحص الأداء (Profiling) تكاليف حاسوبية إضافية (أي استهلاك زائد للمعالج والذاكرة) لذا فهي مُعطَّلة افتراضيًا في الإصدار النهائي للتطبيق، لكن إذا أردت تضمينها في النسخة النهائية لتطبيقك فإن React يُتيح إطلاق نُسخة نهائية من التطبيق تضم عملية التعريف. راجع دليل عملية فحص الأداء في React الأجنبي لمزيد من التفاصيل حول كيفية استخدام هذا الإصدار.
كيفية الاستخدام
يمكنك إضافة عملية فحص أداء (مكون Profiler
) في أيّ مكان ضمن هيكل React الشجري (tree) لقياس تكلفة تصيير ذلك القسم من الهيكل. يتطلب ذلك استخدام خاصيتين: الأولى هي مُعرّف العملية id
والثانية هي دالّة رد نداء (callback function) باسم onRender
تُستدعَى تلقائيًا عندما يُجرِي أي مُكوِّن في ذلك الهيكل تحديثًا ما.
على سبيل المثال هكذا سيبدو استعلام تعريف مُكوِّن التنقل Navigation
وأجزائه الفرعية:
render(
<App>
<Profiler id="Navigation" onRender={callback}>
<Navigation {...props} />
</Profiler>
<Main {...props} />
</App>
);
يمكنك أيضًا استخدام مُكوِّنات Profiler
متعددة لقياس أداء أجزاء مختلفة من التطبيق كما في المثال التالي:
render(
<App>
<Profiler id="Navigation" onRender={callback}>
<Navigation {...props} />
</Profiler>
<Profiler id="Main" onRender={callback}>
<Main {...props} />
</Profiler>
</App>
);
يمكنك أيضًا إنشاء مُكوِّنات Profiler
مُتداخلة لقياس مُكوِّنات مختلفة ضمن نفس القسم من الهيكل الشجري كما هو موضح أدناه:
render(
<App>
<Profiler id="Panel" onRender={callback}>
<Panel {...props}>
<Profiler id="Content" onRender={callback}>
<Content {...props} />
</Profiler>
<Profiler id="PreviewPane" onRender={callback}>
<PreviewPane {...props} />
</Profiler>
</Panel>
</Profiler>
</App>
);
ملاحظة: مع أنّ المكون Profiler
يُعَدّ مكوِّنًا خفيفًا على وحدة المعالجة إلا أنه يُنصح باستخدامه عند الضرورة فقط، إذ يضيف كل استخدام بعض العبء على المُعالج والذاكرة مما قد يؤثِّر على أداء التطبيق ككُل.
دالة المعالجة اللاحقة (onRender Callback)
يتطلب مُراقب الأداء Profiler
تحديد دالّة رد نداء (Callback) تُفعّل عند بدء التصيير أو المُعالجة (onRender
) كإحدى الخاصيات الممرة إليه. ستستدعي React هذه الدالة في كل مرة يُحدَّث فيها أحد المُكوِّنات المذكورة ضمن المكوِّن Profiler
. عندها ستستقبل تلك الدالّة مُعامِلات تصِف ما تم مُعالجته وما الوقت الذي استغرقه ذلك.
function onRenderCallback(
id, // نص يُمثل خاصية مُعرّف القسم من مراقب الأداء الذي أجرى التحديث
phase, // إما "mount" إذا كانت العملية نُفِّذت للمرة الأولى أو "update" إذا طرأ تحديث ما تسبب بإعادة التصيير
actualDuration, // الوقت المُستغرق لتصيير التحديث الحالي
baseDuration, // الوقت المُقدر لتصيير القسم الفرعي من الهيكل بدون استخدام تقنيات تسريع
startTime, // الوقت الذي بدأ فيه ريآكت بتصيير التحديث
commitTime, // الوقت الذي أنهى فيه ريآكت إرسال التحديث
interactions // مجموعة التفاعلات المتعلقة بالتحديث الحالي
) {
// سِجل توقيت عمليات التصيير
}
لنُلقِ نظرةً عن تلك الخصائص سابقة الذكر:
id
(المُعرِّف): هو نص يُمثل خاصيةid
للقسم المُعين من شجرةProfiler
الذي أجرى التحديث. يمكن استخدام هذا المعرف لتحديد أيّ جزء من الهيكل قد حُدّث في حال كنت تستخدم مُعرِّفات متعددة.phase
(طُور العملية): تُمثّل هذه الخاصية بإحدى قيمتين (update أو mount) واللذان يُحددان إذا ما كانت العملية التي أُجريت على القسم المُحدد من الهيكل قد نُفِّذت للمرة الأولى أو أُعيد تصييرها نتيجة تحديث أحد الخصائص أو حالة المُكوِّنات أو الأحداث المُرتبطة بها.actualDuration
(مُدَّة التنفيذ الفعلية): تُمثّل هذه الخاصية برقم يُعبر عن الوقت المُستغرق لتصيير عمليةProfiler
ومُكوناتها الداخلية للتحديث الحالي. يُشير هذا الرقم إلى مدى فعالية تقنيات التسريع (مثل React.memo أو useMemo أو shouldComponentUpdate) المستخدَمة في هذا القسم من الهيكل الشجري. في العادة يُفترضانخفاض قيمة هذه الخاصية كثيرًا موازنةً بالقيمة الأولية، لأنّ العديد من المُكوِّنات الداخلية لا تحتاج إلى إعادة التصيير ما لم يطرأ أيّ تغيير على خصائصها.baseDuration
(مُدَّة التنفيذ الأساسية): تُمثّل هذه الخاصية أيضًا برقم يُعبر عن الوقت الذي استغرقته آخر عمليات التصيير لكلّ مُكوِّن ضمن الهيكل الشجري. تُستخدم هذه القيمة لتقدير تكلفة التصيير في أسوأ الحالات (مثلًا عند التصيير للمرة الأولى أو في حالة عدم استخدام أيّ تقنيات تسريع).startTime
(وقت البدء): وهو رقم يُمثل الطابع الزمني للحظة بدء React بتصيير التحديث الحالي لإحدى المُكوِّنات.commitTime
(وقت التنفيذ): وهو رقم يُمثل الطابع الزمني للحظة تنفيذ React للتحديث الحالي على أحد المُكوِّنات. تتشارك جميع عمليات التعريف هذه القيمة عند تنفيذ التحديث مما يُتيح تجميعها معًا إذا رغب المُطوِّر في ذلك.interactions
(التفاعلات): وهي مجموعة التفاعلات التي يجري تتبُّعها عند جدولة التحديث (مثلًا عند التصيير أو عند تفعيل دالّةsetState
).
ملاحظة: يمكن استخدام التفاعلات (Interactions) لتحديد سبب التحديث لكن يجدر بك معرفة أنّ واجهة التطوير الخاصة بها لا تزال تحت الاختبار. راجع توثيق تتبع التفاعلات لمزيد من المعلومات عن هذه النقطة.