{"id":"l-rn-5-1","courseId":"react-native-apps","lang":"ar","kind":"lesson","summary":"اعثر على أخطاء Trailhead وشاشاته البطيئة وأصلحها باستخدام LogBox وReact Native DevTools وPerformance Monitor والـ Profiler، مع القياس في وضع الإنتاج قبل تغيير الكود.","html":"

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

\n

الأدوات التي لديك

\n

LogBox هي الطبقة الظاهرة داخل التطبيق. الخطأ الأحمر بملء الشاشة استثناء JavaScript لم يُلتقط، مع stack trace يشير إلى مصدر الكود. والتحذيرات تظهر شريطًا صغيرًا في الأسفل. أصلح التحذيرات فور ظهورها؛ ومن العادات الجيدة في الفرق أن يُعامَل أي تحذير جديد كأنه اختبار فاشل، لأن التحذيرات التي تتجاهلها هي نفسها التي تتحوّل إلى انهيارات.

\n

مخرجات console.log تظهر في الطرفية التي تشغّل Metro وفي console الـ DevTools. جيدة للفحوص السريعة؛ لكن أزلها من المسارات الساخنة مثل renderItem، حيث يبطئ تسجيل كل صفّ القائمةَ نفسها.

\n

React Native DevTools هو أداة التصحيح المدمجة، مبني على Chrome DevTools. اضغط j في طرفية Metro، أو اختر Open DevTools من قائمة التطوير (m في الطرفية، أو هزّ الجهاز). وفيه:

\n\n

نقطة توقّف واحدة أفضل من عشرة استدعاءات console.log حين لا تعرف أين الخطأ. ضع واحدة في معالج الزر الذي «أحيانًا لا يفعل شيئًا»، وانقر عليه، وافحص الـ state التي لديك فعلًا.

\n

الانهيارات الأصلية (native crashes)، حين يُغلَق التطبيق دون شاشة حمراء، تأتي من الكود الأصلي (مكتبة، أو إذن مضبوط بشكل خاطئ، أو نفاد الذاكرة). أدوات JavaScript لا تراها. اقرأ سجلّات الجهاز: console في Xcode لـ iOS، وLogcat في Android Studio، أو مخرجات الطرفية من npx expo run:android. وفي بيئة الإنتاج، تجمع خدمة تقارير أخطاء مثل Sentry انهيارات JavaScript والانهيارات الأصلية معًا من المستخدمين الحقيقيين، مع stack traces.

\n

قِس في وضع الإنتاج

\n

يشغّل وضع التطوير فحوصًا إضافية: التحقّق من الـ props، والتحذيرات، وقائمة التطوير، وFast Refresh. ويمكن أن يجعل JavaScript أبطأ بعدّة أضعاف. الحكم على الأداء هناك يشبه توقيت عدّاء يحمل حقيبة ظهر. قبل أن تغيّر أي كود من أجل السرعة، شغّل التطبيق دون وضع التطوير:

\n
Terminal
npx expo start --no-dev --minify
\n

أو ثبّت build إصدار (ستصنع واحدًا باستخدام EAS لاحقًا في هذا القسم). اختبر على هاتف Android متوسط الفئة؛ فإن كان سلسًا هناك، فهو سلس في معظم الأماكن.

\n

الـ JS thread أم الـ UI thread؟

\n

افتح قائمة التطوير وفعّل Performance Monitor. يعرض معدّلَي إطارات، ويقابلان الـ threads الاثنين من الدرس الأول تمامًا:

\n
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
العَرَضالسبب المرجّحأين تبحث
ينخفض JS FPS ويبقى UI FPS جيدًاJavaScript أكثر من اللازم: عمليات re-render، وعمل ثقيل في الـ render، وتحليل JSON كبيرالـ Profiler والـ components
ينخفض UI FPSعمل أصلي أكثر من اللازم: أشجار views عميقة، وصور ضخمة، وظلال كثيرةتسلسل الـ views وأحجام الصور
النقرات تبدو متأخّرةالـ JS thread مشغول حين تصل اللمسةالـ Profiler أثناء التفاعل

معظم المشكلات في تطبيقات React Native على جانب JavaScript، ومعظم هذه سببها إعادة الـ render أكثر من اللازم. سجّل جلسة Profiler بينما تعيد إنتاج البطء، ثم ابحث عن components تُرسم أكثر بكثير مما ينبغي. ويستطيع الـ Profiler تسجيل سبب رسم كل component (props تغيّرت، أو state، أو context، أو الأب)، وهذا يحوّل التخمين إلى إصلاح.

\n

الإصلاحات، بترتيب العائد

\n

راجع أولًا قائمة التحقّق من درس القوائم: صفوف مغلّفة بـ memo، وprops ثابتة، وkeyExtractor، وصور بالحجم المناسب. وأبعد من القوائم:

\n\n\n

روتين لتصحيح الأخطاء يعمل

\n

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

\n","toc":[{"id":"sec-1","text":"الأدوات التي لديك","level":2},{"id":"sec-2","text":"قِس في وضع الإنتاج","level":2},{"id":"sec-3","text":"الـ JS thread أم الـ UI thread؟","level":2},{"id":"sec-4","text":"الإصلاحات، بترتيب العائد","level":2},{"id":"sec-5","text":"روتين لتصحيح الأخطاء يعمل","level":2}],"takeaways":["اضغط j في طرفية Metro (أو استخدم قائمة التطوير) لفتح React Native DevTools، وفيها console ونقاط توقّف (breakpoints) ومستكشف Components وProfiler.","وضع التطوير أبطأ بكثير من build الإصدار، فاحكم على الأداء باستخدام npx expo start --no-dev --minify أو build حقيقي.","يعرض Performance Monitor معدّلَي الإطارات لـ JS وUI منفصلين؛ وأيهما ينخفض يخبرك أين المشكلة.","معظم البطء في JavaScript داخل React Native سببه عمليات re-render أكثر من اللازم وبتكرار أكثر من اللازم؛ ويُظهر الـ Profiler أي components ولماذا.","شغّل الحركات على الـ UI thread (عبر Reanimated، أو Animated مع الـ native driver) حتى لا يستطيع JS thread مشغول أن يجعلها تتقطّع."],"further":[{"title":"React Native DevTools","url":"https://reactnative.dev/docs/react-native-devtools"},{"title":"Debugging Basics","url":"https://reactnative.dev/docs/debugging"},{"title":"Performance Overview","url":"https://reactnative.dev/docs/performance"}],"quiz":[{"q":"

تتمرّر قائمة الرحلات في Trailhead بشكل سيئ في وضع التطوير على هاتفك. ماذا يجب أن تفعل قبل تحسين أي شيء؟

","options":[{"text":"غلّف كل component بـ memo.","why":"الـ memoization العشوائي يضيف تعقيدًا وقد لا يمسّ المشكلة الحقيقية. قِس أولًا."},{"text":"حوّل القائمة من FlatList إلى ScrollView.","why":"هذا يرسم كل صف مقدّمًا، فيجعل القوائم الطويلة أبطأ لا أسرع."},{"text":"اشترِ أحدث هاتف متاح واختبر عليه.","why":"مستخدموك لا يملكون أحدث هاتف. اختبر على جهاز متوسط الفئة، وفي وضع الإنتاج."},{"text":"شغّل JavaScript في وضع الإنتاج (npx expo start --no-dev --minify أو build إصدار) وتحقّق هل ما زال بطيئًا.","why":"صحيح. يضيف وضع التطوير فحوصًا وتحذيرات تبطئ كل شيء؛ وكثير من «أخطاء الأداء» تختفي في وضع الإنتاج."}],"answer":3},{"q":"

يُظهر Performance Monitor الـ UI thread عند 60 FPS والـ JS thread ينخفض إلى 15 FPS أثناء التمرير. أين المشكلة؟

","options":[{"text":"في JavaScript، كأن تُعاد عمليات render للـ components مع كل حدث تمرير، أو أن يكون هناك عمل ثقيل داخل الـ render.","why":"صحيح. الجانب الأصلي يواكب؛ أما JavaScript لديك فلا. وسيُظهر الـ Profiler أي components مشغولة."},{"text":"في الـ native views، كأن تكون هناك Views متداخلة كثيرة جدًا أو صور كبيرة جدًا.","why":"كان ذلك سيظهر انخفاضًا في الـ UI thread. وهنا الـ UI thread بخير."},{"text":"في الشبكة، لأن الطلبات تحجب الـ JS thread.","why":"طلبات الشبكة غير متزامنة؛ وانتظارها لا يستهلك إطارات الـ JS thread."}],"answer":0},{"q":"

حركة ظهور تدريجي في شاشة تفاصيل الرحلة تتقطّع بينما تحمّل الشاشة بياناتها. ما الإصلاح الأمتن؟

","options":[{"text":"أخّر تحميل البيانات حتى تنتهي الحركة.","why":"هذا يبطئ الشاشة لإخفاء التقطّع، وأي عمل آخر في JavaScript قد يسبّبه مع ذلك."},{"text":"شغّل الحركة على الـ UI thread، باستخدام Reanimated أو Animated مع useNativeDriver: true.","why":"صحيح. الحركات التي تُقاد على الـ UI thread لا تعتمد على الـ JS thread المشغول، فتبقى سلسة."},{"text":"قلّل مدّة الحركة ليصبح التقطّع أقصر.","why":"التقطّع الأقصر يبقى تقطّعًا؛ والسبب أن الـ JS thread مشغول."}],"answer":1}],"exercise":{"kind":"spot-bug","language":"jsx","code":"import { memo, useEffect, useState } from 'react';\nimport { FlatList, Text, View } from 'react-native';\nimport { useHikes } from '../state/hikes';\n\nconst HikeRow = memo(function HikeRow({ hike }) {\n return (\n \n {hike.name}\n {hike.distanceKm} km\n \n );\n});\n\nexport default function HikeLog() {\n const hikes = useHikes();\n const [now, setNow] = useState(Date.now());\n\n useEffect(() => {\n const id = setInterval(() => setNow(Date.now()), 16);\n return () => clearInterval(id);\n }, []);\n\n return (\n \n Updated {new Date(now).toLocaleTimeString()}\n String(index)}\n renderItem={({ item }) => }\n />\n \n );\n}","bugLines":[19,28,29],"title":"لماذا يتقطّع سجلّ الرحلات؟","prompt":"

يتقطّع سجلّ Trailhead على هاتف Android متوسط الفئة، حتى في وضع الإنتاج. يُظهر Performance Monitor أن الـ JS thread يُسقط إطارات بينما الـ UI thread بخير، ويُظهر الـ Profiler أن كل HikeRow يُعاد رسمه باستمرار. اختر الأسطر الثلاثة المسؤولة.

\n","hints":["شيء ما يجعل الشاشة كلها يُعاد رسمها مرات كثيرة في الثانية. كم مرة يُطلَق مؤقّت بفاصل 16 ms؟","لا يتخطّى memo إعادة الـ render إلا حين يكون كل prop هو الكائن نفسه الذي كان في المرة السابقة.","انظر أيضًا إلى طريقة تعريف الصفوف: ماذا يحدث للمفاتيح حين تُدرج رحلة في الأعلى؟"],"explanation":"

السطر 19 يحدّث الـ state كل 16 ms، فيعيد رسم الشاشة كلها نحو 60 مرة في الثانية فقط لعرض ساعة بدقّة ثانية واحدة؛ استخدم فاصلًا أطول بكثير، وانقل الساعة إلى component صغير خاص بها حتى لا يُعاد رسم غيرها. والسطر 29 يمرّر { ...item }، وهو كائن جديد تمامًا في كل render، فلا يتمكّن memo(HikeRow) أبدًا من تخطّي صفّ؛ مرّر hike={item}. والسطر 28 يجعل مفتاح الصفوف هو الفهرس، فإدراج رحلة في الأعلى يُزيح كل المفاتيح، ويُعاد تركيب كل صف؛ استخدم keyExtractor={(hike) => hike.id}. أما كائنات style المباشرة داخل HikeRow فليست المشكلة: فهي لا تُنشأ إلا حين يُرسم الصف فعلًا.

\n","checkLabels":{}},"words":782,"readMinutes":5}