الفرق بين المراجعتين ل"React/profiler"

من موسوعة حسوب
اذهب إلى التنقل اذهب إلى البحث
(مراجعة)
ط
 
(4 مراجعات متوسطة بواسطة مستخدمين اثنين آخرين غير معروضة)
سطر 1: سطر 1:
<noinclude>{{DISPLAYTITLE:المكون دليل استخدام منصة إلكترون (Electron) في React}}</noinclude>
+
<noinclude>{{DISPLAYTITLE:واجهة برمجة مراقب الأداء (Profiler API) في React}}</noinclude>
إلكترون (Electron) هو إطار عمل يستخدم تقنيات الويب (مثل HTML وCSS وJS) لبناء تطبيقات حاسوب عابرة للمنصات (أي تعمل على منصّات مختلفة).
+
يُحدد الفاحص <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).
__toc__
 
== متطلبات النظام لتشغيل إطار عمل إلكترون ==
 
  
=== نظام لينكس ===
+
'''ملاحظة''': تُضيف عملية فحص الأداء (Profiling) تكاليف حاسوبية إضافية (أي استهلاك زائد للمعالج والذاكرة) لذا فهي مُعطَّلة افتراضيًا في الإصدار النهائي للتطبيق، لكن إذا أردت تضمينها في النسخة النهائية لتطبيقك فإن [[React]] يُتيح إطلاق نُسخة نهائية من التطبيق تضم عملية التعريف. راجع [https://fb.me/react-profiling دليل عملية فحص الأداء في React] الأجنبي لمزيد من التفاصيل حول كيفية استخدام هذا الإصدار.
  
* الإصدار 2.7 أو أعلى من بايثون (Python). ويُنصح بتفقًّد إصدار بايثون الذي تستخدمه خاصةً أنّ بعض توزيعات لينكس (مثل الإصدار 6 من توزيعة CentOS) لا تزال تستخدم الإصدار 2.6 من بايثون  افتراضيًّا.
+
== كيفية الاستخدام ==
  
=== نظام ماك ===
+
يمكنك إضافة عملية فحص أداء (مكون <code>Profiler</code>) في أيّ مكان ضمن هيكل [[React]] الشجري (tree) لقياس تكلفة تصيير ذلك القسم من الهيكل. يتطلب ذلك استخدام خاصيتين: الأولى هي مُعرّف العملية <code>id</code> والثانية هي دالّة رد نداء (callback function) باسم <code>onRender</code> تُستدعَى تلقائيًا عندما يُجرِي أي مُكوِّن في ذلك الهيكل تحديثًا ما.
  
* الإصدار 2.7 أو أعلى من بايثون (Python) بالإضافة إلى دعم بروتوكول طبقة المنافذ الآمنة TLS 1.2.
+
على سبيل المثال هكذا سيبدو استعلام تعريف مُكوِّن التنقل <code>Navigation</code> وأجزائه الفرعية:
* الإصدار 8.2.1 أو أعلى من بيئة تطوير Xcode الخاصة بنظام ماك. تتضمن هذه الحزمة جميع الأدوات الضرورية لتوقيع وتفسير التعليمات البرمجية الخاصة بنظام ماك.
 
* دعم أدوات توزيعة RedHat التالية:
 
** Homebrew: وهو أحد مديري الحزم المتاحين لنظام ماك ويُستخدم لتثبيت الأدوات والمصادر الإضافية. ستحتاج إلى أداة Homebrew أيضًا لتثبيت متطلبات مدير حزم RPM. راجع [https://brew.sh/ دليل تثبيت Brew] لمزيد من الإرشادات حول هذه النقطة.
 
** مدير حزم RPM: يُعَدّ RPM مدير الحزم الافتراضي للعديد من توزيعات لينكس ويُستخدم أيضًا لإنشاء حزم RPM لنظام لينكس. ستحتاج إلى استخدام أمر Homebrew التالي لتثبيت هذه الأداة:
 
  
<syntaxhighlight class="" lang="bash">
+
<syntaxhighlight class="" lang="html">render(
brew install rpm
+
  <App>
</syntaxhighlight>
+
    <Profiler id="Navigation" onRender={callback}>
=== نظام تشغيل ويندوز ===
+
      <Navigation {...props} />
 +
    </Profiler>
 +
    <Main {...props} />
 +
  </App>
 +
);</syntaxhighlight>
 +
يمكنك أيضًا استخدام مُكوِّنات <code>Profiler</code> متعددة لقياس أداء أجزاء مختلفة من التطبيق كما في المثال التالي:
  
* الإصدار 2.7.10 أو أعلى من بايثون.
+
<syntaxhighlight class="" lang="html">render(
* واجهة سطر أوامر PowerShell. لكن إذا كنت تستخدم نظام تشغيل Windows 7، فستحتاج إلى الإصدار 3.0 على الأقل لتتمكن من توقيع التطبيقات.
+
  <App>
* [https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/ أدوات استكشاف وإصلاح المشاكل] لنظام ويندوز. وهي حزمة أدوات لتعزيز قدرات استكشاف الأخطاء ويُنصح بتثبيتها مع الإصدار 10.0.15063.468 من حزمة أدوات تطوير ويندوز (Windows SDK).
+
    <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="bash">npm i -g cordova
+
<syntaxhighlight class="" lang="javascript">function onRenderCallback(
cordova create sampleApp
+
  id, // نص يُمثل خاصية مُعرّف القسم من مراقب الأداء الذي أجرى التحديث
cd  sampleApp
 
cordova platform add electron</syntaxhighlight>
 
'''ملاحظة''': إذا كنت تستخدم واجهة سطر أوامر كوردوفا أقدم من الإصدار 9، فستحتاج إلى استخدام دالّة <code>cordova-electron</code> عوضًا عن دالّة <code>electron</code> لأيّ تعليمة تتطلّب ذكر اسم المنصّة. مثال على ذلك:
 
  
<syntaxhighlight class="" lang="bash">cordova platform add cordova-electron
+
  phase, // إما "mount" إذا كانت العملية نُفِّذت للمرة الأولى أو "update" إذا طرأ تحديث ما تسبب بإعادة التصيير
cordova run cordova-electron</syntaxhighlight>
 
=== استعراض مشروع كوردوفا ===
 
  
ليس من الضروري تجميع تطبيق إلكترون قيد الإنشاء بهدف استعراضه ومراجعته نسبةً لبطء عملية التجميع. لذلك يُنصح بإضافة راية <code>nobuild--</code> لتعطيل عملية التجميع أثناء استعراض سير العمل.
+
  actualDuration, // الوقت المُستغرق لتصيير التحديث الحالي
  
<syntaxhighlight class="" lang="bash">cordova run electron --nobuild</syntaxhighlight>
+
  baseDuration, // الوقت المُقدر لتصيير القسم الفرعي من الهيكل بدون استخدام تقنيات تسريع
=== بناء مشروع كوردوفا ===
 
  
'''الإصدار التجريبي'''
+
  startTime, // الوقت الذي بدأ فيه ريآكت بتصيير التحديث
  
<syntaxhighlight class="" lang="bash">cordova build electron
+
  commitTime, // الوقت الذي أنهى فيه ريآكت إرسال التحديث
cordova build electron --debug</syntaxhighlight>
 
'''الإصدار المستقر'''
 
  
<syntaxhighlight class="" lang="bash">cordova build electron --release</syntaxhighlight>
+
  interactions // مجموعة التفاعلات المتعلقة بالتحديث الحالي
== تخصيص خيارات نافذة التطبيق ==
+
) {
 
+
  // سِجل توقيت عمليات التصيير
يوفر إطار عمل إلكترون خيارات متعدِّدة للتحكم بنافذة المُستعرض وسيُغطي هذا القسم كيفية إعداد بعض الخيارات الأساسية. راجع قسم [https://electronjs.org/docs/api/browser-window#new-browserwindowoptions خيارات نافذة العرض] من توثيق إلكترون لرؤية كامل قائمة الخيارات.
 
 
 
يُنصح بإنشاء ملف خاص بإعدادات إلكترون في جذر مسار مشروع كوردوفا وإدراج المسار المتعلق به في خيار <code>ElectronSettingsFilePath</code> الموجود بملف <code>config.xml</code> كما في المثال التالي:
 
 
 
<syntaxhighlight class="" lang="xml"><platform name="electron">
 
    <preference name="ElectronSettingsFilePath" value="res/electron/settings.json" />
 
</platform></syntaxhighlight>
 
إذا أردت تغيير أيٍّ من خيارات نافذة المُستعرض (<code>BrowserWindow</code>) الافتراضية، فستحتاج إلى إضافة تلك الخيارات إلى مُكوِّن <code>browserWindow</code> الموجود في ملف <code>res/electron/settings.json</code> كما هو موضَّح أدناه:
 
 
 
<syntaxhighlight class="" lang="json">{
 
    "browserWindow": { ... }
 
}</syntaxhighlight>
 
=== كيفية تحديد حجم النافذة الافتراضي ===
 
 
 
أبعاد نافذة المُستعرض الافتراضية هي 800 للعرض و600 للطول، لكنها قابلة للتخصيص عبر تعديل خصائص العرض والطول كما في المثال التالي:
 
 
 
<syntaxhighlight class="" lang="json">{
 
    "browserWindow": {
 
        "width": 1024,
 
        "height": 768
 
    }
 
}</syntaxhighlight>
 
=== كيفية منع تغيير حجم نافذة المستعرض ===
 
 
 
يمكنك تعطيل إمكانية تغيير أبعاد نافذة المُستعرض من قبل المستخدم عبر استخدام خاصية <code>resizable</code> كما هو موضح أدناه:
 
 
 
<syntaxhighlight class="" lang="json">{
 
    "browserWindow": {
 
        "resizable": false
 
    }
 
}</syntaxhighlight>
 
=== كيفية استخدام العرض الكامل لنافذة المستعرض ===
 
 
 
يمكنك فرض عرض التطبيق بوضع الشاشة الكاملة عبر استخدام خاصية <code>fullscreen</code> كما في المثال التالي:
 
 
 
<syntaxhighlight class="" lang="json">{
 
    "browserWindow": {
 
        "fullscreen": true
 
    }
 
}</syntaxhighlight>
 
=== كيفية دعم نظام برامج Node.js وواجهة برمجة تطبيقات إلكترون (Electron APIs) ===
 
 
 
حدد قيمة خاصية <code>nodeIntegration</code> إلى <code>true</code> لدعم مكتبات [[Node.js]] واستخدام الرموز التي يتشاركها <code>Node.js</code> وإلكترون كما هو موضح في المثال التالي. افتراضيًّا تًعَدّ  قيمة هذه الخاصية هي <code>false</code> ويمكنك قراءة المزيد من التفاصيل حول [https://electronjs.org/docs/faq#i-can-not-use-jqueryrequirejsmeteorangularjs-in-electron دعم مكتبات  - RequireJS - Meteor - AngularJS] و [[jQuery]] في توثيق إلكترون.
 
 
 
<syntaxhighlight class="" lang="json">{
 
    "browserWindow": {
 
        "webPreferences": {
 
            "nodeIntegration": false
 
        }
 
    }
 
}</syntaxhighlight>
 
== تخصيص عملية إلكترون الرئيسية ==
 
 
 
إذا احتجت إلى تخصيص عملية إلكترون الرئيسية بما يتخطى ما تُتيحه إعدادات إطار العمل فيُمكنك تغيير تعليمات ملف <code>cdv-electron-main.js</code> الموجود في مسار <code>‎{PROJECT_ROOT_DIR}/platform/electron/platform_www/‎</code> والخاص بعملية التطبيق الرئيسية.
 
 
 
لكن يجدر بنا تحذيركم من تعديل هذا الملف فعملية تحديث إطار <code>cordova-electron</code> تتضمن حذف المنصّة القديمة قبل تثبيت الإصدار الجديد.
 
 
 
== أدوات المطورين (DevTools) ==
 
 
 
تتحكم رايتي <code>release--</code> و<code>debug--</code> بإمكانية عرض أدوات المطورين والتي تظهر افتراضيًّا في إصدارات الاختبار (Debug Builds). قد تتضمن تلك الإصدارات راية <code>debug--</code> أو قد لا تستخدم أيّ راية. لذا فإن أردت إخفاء أدوات المطورين في تلك الإصدارات، فعليك إضافة راية <code>release--</code> عند بناء أو تشغيل التطبيق.
 
 
 
'''ملاحظة''': يمكن فتح أو إغلاق أدوات المطورين يدويًا في إصدارات الاختبار.
 
 
 
== إعدادات الإصدار ==
 
 
 
=== إعدادات الإصدار الافتراضية ===
 
 
 
إذا لم تُدرج أي إعدادات إضافية، فسيُنشِئ إطار عمل إلكترون حزمةً تستهدف نظام تشغيل الجهاز المُضيف والذي اُستخدم لإدخال استعلام تجميع الحزمة. يحتوي الجدول التالي على قائمة بالحزم الافتراضية لكلّ نظام تشغيل:
 
 
 
'''لينكس'''
 
 
 
{| class="wikitable"
 
! '''الحزمة'''
 
! '''المعمارية'''
 
|-
 
| <code>tar.gz</code>
 
| x64
 
|}
 
 
 
'''ماك'''
 
 
 
{| class="wikitable"
 
! '''الحزمة'''
 
! '''المعمارية'''
 
|-
 
| <code>dmg</code>
 
| x64
 
|-
 
| <code>zip</code>
 
| x64
 
|}'''ويندوز'''
 
 
 
{| class="wikitable"
 
! '''الحزمة'''
 
! '''المعمارية'''
 
|-
 
| <code>nsis</code>
 
| x64
 
|}
 
 
 
=== تخصيص إعدادات الإصدار ===
 
 
 
إذا رغبت بتخصيص إعدادات الإصدار لأيّ سبب، فستحتاج إلى تضمينها في ملف <code>build.json</code> والموجود في جذر مسار المشروع (مثل <code>‎{PROJECT_ROOT_DIR}/build.json</code>). يحتوي هذا الملفّ على جميع إعدادات الإصدار لجميع المنصّات (مثل: أندرويد، وإلكترون، وiOS، وويندوز). ستبدو بنية إعدادات إلكترون كما في المثال التالي:
 
 
 
<syntaxhighlight class="" lang="json">{
 
    "electron": {}
 
}</syntaxhighlight>
 
بما أنّ إطار عمل إلكترون يُستخدم لإنشاء تطبيقات عابرة للمنصات (أي تعمل على أنظمة تشغيل مختلفة)، فستحتاج إلى تخصيص إعدادات منفصلة لكلّ منصّة على حدة. يتضمن مكوّن إلكترون الموجود في ملفّ <code>build.json</code> ثلاث خصائص تفصِل بين إعدادات الإصدار لكلّ نظام تشغيل كما هو موضّح في المثال التالي:
 
 
 
<syntaxhighlight class="" lang="json">{
 
    "electron": {
 
        "linux": {},
 
        "mac": {},
 
        "windows": {}
 
    }
 
}</syntaxhighlight>
 
يحتوي كلّ مكوِّن على الخصائص اللازمة لتحديد أيّ حزمة يجب توليدها وكيف تُوقّع.
 
 
 
'''خصائص أنظمة التشغيل'''
 
 
 
* '''الحزمة (<code>package</code>)''': وهي مصفوفة تضمّ ترميز الإصدارات التي ستوَلّد لاحقًا.
 
* '''المعمارية (<code>arch</code>)''': وهي مصفوفة من المعماريات التي تستهدفها كلّ حزمة منفصلة.
 
* '''التوقيع (<code>signing</code>)''': وهو مُكوِّن يحتوي معلومات التوقيع. راجع صفحة [https://cordova.apache.org/docs/en/latest/guide/platforms/electron/index.html#signing-configurations إعدادات التوقيع] لمزيد من المعلومات عن هذه النقطة.
 
 
 
سيستخدم إلكترون الإعدادات الافتراضية في حالة وجود أيّ خصائص غير محددة القيمة في ملف <code>build.json</code>.
 
 
 
=== إضافة حزمة ===
 
 
 
تتضمن خاصية الحزمة (<code>package</code>) مصفوفةً من ترميز الحزم التي ستُجمّع لاحقًا، فإذا حدّدت تلك الخصائص، فلن يستخدم إلكترون الحزم الافتراضية ما لم تُضفها بنفسك. كما لن يهمّ ترتيب عناصر الحزمة الذي أدخلتها.
 
 
 
على سبيل المثال ستُولّد الإعدادات التالية حزم <code>tar.gz</code> و<code>dmg</code> و<code>zip</code> لمنصة ماك:
 
 
 
<syntaxhighlight class="" lang="json">{
 
    "electron": {
 
        "mac": {
 
            "package": [
 
                "dmg",
 
                "tar.gz",
 
                "zip"
 
            ]
 
        }
 
    }
 
}</syntaxhighlight>
 
'''الحزم المتاحة لكل نظام تشغيل''':
 
 
 
{| class="wikitable"
 
! '''نوع الحزمة'''
 
! '''لينكس'''
 
! '''ماك'''
 
! '''ويندوز'''
 
|-
 
| <code>default</code>
 
| -
 
| <code>dmg - zip</code>
 
| -
 
|-
 
| <code>dmg</code>
 
| -
 
| ✅
 
| -
 
|-
 
| <code>mas</code>
 
| -
 
| ✅
 
| -
 
|-
 
| <code>mas-dev</code>
 
| ✅
 
| -
 
| -
 
|-
 
| <code>pkg</code>
 
| -
 
| ✅
 
| -
 
|-
 
| <code>7z</code>
 
| ✅
 
| ✅
 
| ✅
 
|-
 
| <code>zip</code>
 
| ✅
 
| ✅
 
| ✅
 
|-
 
| <code>tar.xz</code>
 
| ✅
 
| ✅
 
| ✅
 
|-
 
| <code>tar.lz</code>
 
| ✅
 
| ✅
 
| ✅
 
|-
 
| <code>tar.gz</code>
 
| ✅
 
| ✅
 
| ✅
 
|-
 
| <code>tar.bz2</code>
 
| ✅
 
| ✅
 
| ✅
 
|-
 
| <code>dir</code>
 
| ✅
 
| ✅
 
| ✅
 
|-
 
| <code>nsis</code>
 
| -
 
| -
 
| ✅
 
|-
 
| <code>nsis-web</code>
 
| -
 
| -
 
| ✅
 
|-
 
| <code>portable</code>
 
| -
 
| -
 
| ✅
 
|-
 
| <code>appx</code>
 
| -
 
| -
 
| ¹ ✅
 
|-
 
| <code>msi</code>
 
| -
 
| -
 
| ✅
 
|-
 
| <code>AppImage</code>
 
| ✅
 
| -
 
| -
 
|-
 
| <code>snap</code>
 
| ✅
 
| -
 
| -
 
|-
 
| <code>deb</code>
 
| ✅
 
| -
 
| -
 
|-
 
| <code>rpm</code>
 
| ✅
 
| -
 
| -
 
|-
 
| <code>freebsd</code>
 
| ✅
 
| -
 
| -
 
|-
 
| <code>pacman</code>
 
| ✅
 
| -
 
| -
 
|-
 
| <code>p5p</code>
 
| ✅
 
| -
 
| -
 
|-
 
| <code>apk</code>
 
| ✅
 
| -
 
| -
 
|}
 
* ¹ يجدر بنا التنويه إلى أنّ الإصدار 10 فقط من نظام تشغيل ويندوز يمكنه إنشاء حزمة <code>AppX</code>.
 
 
 
=== إعداد معمارية الحزمة ===
 
 
 
تضم خاصية المعمارية (<code>arch</code>) مصفوفة من المعماريات التي تستهدفها كل حزمة. إذا حدّدت قيمة هذه الخاصية فلن يستخدم إلكترون المعمارية الافتراضية عند تجميع تلك الحزمة.
 
 
 
'''ملاحظة''': الخيارات المتاحة لأيّ نظام تشغيل قد لا تتضمن جميع المعماريات. يمكنك مراجعة [https://github.com/electron/electron/releases/ صفحة إصدارات إلكترون] لمعرفة الخيارات المتاحة لنظام التشغيل الذي تستهدفه.  فنظام ماك (داروين) على سبيل المثال لا يدعم سوى معمارية <code>x64</code> فقط
 
 
 
'''المعماريات المتاحة''':
 
 
 
* <code>ia32</code>
 
* <code>x64</code>
 
* <code>armv7l</code>
 
* <code>arm64</code>
 
 
 
لتوضيح ذلك فإن الإعدادات التالية ستُولّد حزمة <code>dmg</code> لمعمارية <code>x64</code>:
 
 
 
<syntaxhighlight class="" lang="json">{
 
    "electron": {
 
        "mac": {
 
            "package": [ "dmg" ],
 
            "arch": [ "x64" ]
 
        }
 
    }
 
}</syntaxhighlight>
 
=== كيفية دعم إصدار متعدد المنصّات ===
 
 
 
'''ملاحظة''': لا تدعم جميع المنصّات هذه الميزة وقد يتضمن استخدامها قيودًا على منصات أخرى.
 
 
 
من الممكن إنشاء تطبيق يعمل على منصات متعددة باستخدام نظام تشغيل واحد لكن ذلك قد يتضمن قيودًا ما. لذلك يُنصح باستخدام نظام التشغيل المستهدف لإنشاء تطبيق يعمل على نفس النظام. يعرض الجدول التالي التطبيقات متعددة المنصّات التي يمكن لكلّ نظام تشغيل إنشاءها:
 
 
 
{| class="wikitable"
 
! '''الخادم ¹'''
 
! '''لينكس'''
 
! '''ماك'''
 
! '''ويندوز'''
 
|-
 
| لينكس
 
| ✅
 
| -
 
| ²❗
 
|-
 
| ماك ³
 
| ✅
 
| ✅
 
| ²❗
 
|-
 
| ويندوز
 
| -
 
| -
 
| ✅
 
|}'''القيود''':
 
 
 
* ¹ : إذا كان التطبيق يحتوي أيّ مكتبات تستخدم تعليمات لغة الآلة الأصلية لنظام التشغيل المُستهدف، فلن يمكن تفسير التعليمات البرمجية إلّا على نظام التشغيل المُستهدف.
 
* ² : لا يمكن لنظامي ماك ولينكس إنشاء حزم <code>Appx</code> التي تستهدف متجر تطبيقات ويندوز.
 
* ³ : ستُحمّل جميع متطلّبات النظام تلقائيًا عند الطلب ما عدا مدير حزم <code>RPM</code> والذي ستحتاج إلى تحميله باستخدام أداة <code>brew</code> (متاحة لإصدار ماك Sierra 10.12 أو أعلى).
 
 
 
سيُفعّل الضبط التالي ميزة إنشاء إصدار متعدِّد المنصّات لجميع أنظمة التشغيل المُدرَجة باستخدام الإعدادات الافتراضية:
 
 
 
<syntaxhighlight class="" lang="json">{
 
    "electron": {
 
        "linux": {},
 
        "mac": {},
 
        "windows": {}
 
    }
 
}</syntaxhighlight>
 
== إعدادات التوقيع ==
 
 
 
=== التوقيع لنظام ماك ===
 
 
 
هناك ثلاثة أنواع من أهداف التوقيع (signing) هي <code>debug</code> و<code>release</code> و<code>store</code>. يحتوي كلّ منها على الخصائص التالية:
 
 
 
{| class="wikitable"
 
! '''مفتاح الكائن'''
 
! '''الوصف'''
 
|-
 
| <code>entitlements</code>
 
| قيمة المسار إلى ملف الاستحقاقات (entitlements file)
 
|-
 
| <code>entitlementsInherit</code>
 
| قيمة المسار إلى ملف الاستحقاقات الذي يرث إعدادات الأمان
 
|-
 
| <code>identity</code>
 
| نص يحتوي على اسم الشهادة
 
|-
 
| <code>requirements</code>
 
| قيمة المسار إلى ملف المتطلبات -❗لاحظ أن هذا المفتاح غير متاح في إعدادات توقيع إصدار المتجر (mas)
 
|-
 
| <code>provisioningProfile</code>
 
| قيمة المسار إلى ملف التزويد (provisioning profile)
 
|}
 
 
 
مثال على ذلك:
 
 
 
<syntaxhighlight class="" lang="json">{
 
    "electron": {
 
        "mac": {
 
            "package": [
 
                "dmg",
 
                "mas",
 
                "mas-dev"
 
            ],
 
            "signing": {
 
                "release": {
 
                    "identity": "APACHE CORDOVA (TEAMID)",
 
                    "provisioningProfile": "release.mobileprovision"
 
                }
 
            }
 
        }
 
    }
 
}</syntaxhighlight>
 
هناك بعض الاستثناءات لكيفية استخدام توقيع المعلومات في نظام ماك. لكن تستخدم جميع إصدرات الحزم إعدادات توقيع <code>debug</code> و <code>release</code> افتراضيًّا،  ما عدا <code>mas</code> و<code>mas-dev</code>.
 
 
 
لنستخدم المثال سابق الذكر لمراجعة بعض الحالات لتعميق فهمنا لتلك الاستثناءات.
 
 
 
'''الحالة الأولى''':
 
 
 
<syntaxhighlight class="" lang="bash">cordova build electron --debug</syntaxhighlight>
 
يهدف الأمر أعلاه إلى:
 
 
 
* توليد إصداري <code>dmg</code> و<code>mas-dev</code> باستخدام إعدادات توقيع <code>debug</code>.
 
* تجاهل توليد حزمة <code>mas</code> التي تستهدف نظام تشغيل ماك.
 
 
 
'''الحالة الثانية''':
 
 
 
<syntaxhighlight class="" lang="bash">cordova build electron --release</syntaxhighlight>
 
ينتج عن الأمر السابق:
 
 
 
* توليد إصدار <code>dmg</code> باستخدام إعدادات <code>release</code>.
 
* توليد إصدار <code>mas</code> باستخدام إعدادات <code>store</code>.
 
* تجاهل توليد حزمة <code>mas-dev</code>.
 
 
 
=== التوقيع لنظام ويندوز ===
 
 
 
تتضمن معلومات التوقيع الخاصة بنظام ويندوز نوعين من الوسوم هما <code>debug</code> و<code>release</code>، ويحتوي كلّ قسم منهما على الخصائص التالية:
 
 
 
{| class="wikitable"
 
! '''مفتاح الكائن'''
 
! '''الوصف'''
 
|-
 
| <code>certificateFile</code>
 
| نص يُمثل قيمة المسار إلى ملف الشهادة
 
|-
 
| <code>certificatePassword</code>
 
| نص يُمثل قيمة كلمة المرور الخاصة بالشهادة. يمكن الاستعاضة عن هذا المفتاح عبر تحديد قيمة متغيّر <code>CSC_KEY_PASSWORD</code> في بيئة التطوير
 
|-
 
| <code>certificateSubjectName</code>
 
| نص يحتوي على موضوع شهادة التوقيع.❗يتطلب هذا المفتاح استخدام ترميز توقيع EV ونظام تشغيل ويندوز
 
|}
 
 
 
<code>|signingHashAlgorithms|</code>مجموعة الخوارزميات المستخدمة لتوقيع الحزمة (مثلًا sha1 وsha256)، لا تدعم إصدارات <code>AppX</code> سوى خوارزمية تشفير  <code>|sha256certificateSha1|</code>قيمة شفرة <code>SHA1</code> الخاصة بشهادة التوقيع.❗ يتطلب استخدام نظام تشغيل ويندوز| <code>|additionalCertificateFile|</code>قيمة المسار إلى ملفات الشهادة الإضافية|
 
 
 
مثال على توقيع حزمة لنظام تشغيل ويندوز:
 
 
 
<syntaxhighlight class="" lang="json">{
 
    "electron": {
 
        "windows": {
 
            "package": [ "nsis" ],
 
            "signing": {
 
                "release": {
 
                    "certificateFile": "path_to_files",
 
                    "certificatePassword": "password"
 
                }
 
            }
 
        }
 
    }
 
 
}</syntaxhighlight>
 
}</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 توثيق تتبع التفاعلات] لمزيد من المعلومات عن هذه النقطة.
  
يمكن استخدام جميع الإضافات التي تعمل على متصفّحات الإنترنت ضمن منصّة إلكترون. وإذا كانت الإضافة تدعم كلا منصتي إلكترون <code>electron</code> ومتصفح الإنترنت <code>browser</code> (أي تقدّم دعمًا مُدمجًا لإطار عمل إلكترون بالإضافة إلى متصفح الإنترنت)، فسيستخدم إلكترون القسم الذي يستهدفه عند تضمين تلك الإضافة؛ أمّا إذا لم تتضمّن الإضافة أيّ دعم لمنصة إلكترون <code>electron</code> لكنها تحتوي على التعليمات الخاصة بالمتصفح <code>browser</code>، فسيستخدم إلكترون تلك التعليمات لإنشاء التطبيق.
+
== المصادر ==
  
بتفصيل أكثر فإنّ منصّة إلكترون تعتمد على محرك كروميوم (المستخدم في متصفح كروم) لعرض صفحات الويب، وفي ظِل امتلاك بعض الإضافات تعليمات مخصصة لكل متصفح إنترنت، فقد يؤثِّر ذلك على طريقة عمل تلك الإضافات. يُعزى السبب في ذلك إلى دعم إطار عمل إلكترون لمزايا لا تدعمها المتصفِّحات مما قد يتطلب تحديثها لتتوافق بأكثر مع منصّة إلكترون.
+
* [https://reactjs.org/docs/profiler.html صفحة Profiler API من توثيق React الرسمي]
  
ترجمة -وبتصرف- للمقال [https://cordova.apache.org/docs/en/latest/guide/platforms/electron/index.html Electron Platform Guide]، من توثيق [https://cordova.apache.org/ Cordova]
+
[[تصنيف: 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) لتحديد سبب التحديث لكن يجدر بك معرفة أنّ واجهة التطوير الخاصة بها لا تزال تحت الاختبار. راجع توثيق تتبع التفاعلات لمزيد من المعلومات عن هذه النقطة.

المصادر