|
|
(5 مراجعات متوسطة بواسطة مستخدمين اثنين آخرين غير معروضة) |
سطر 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=""> | | <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="">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="">cordova platform add cordova-electron
| | phase, // إما "mount" إذا كانت العملية نُفِّذت للمرة الأولى أو "update" إذا طرأ تحديث ما تسبب بإعادة التصيير |
| cordova run cordova-electron</syntaxhighlight>
| |
| === استعراض مشروع كوردوفا ===
| |
|
| |
|
| ليس من الضروري تجميع تطبيق إلكترون قيد الإنشاء بهدف استعراضه ومراجعته نسبةً لبطء عملية التجميع. لذلك يُنصح بإضافة راية <code>nobuild--</code> لتعطيل عملية التجميع أثناء استعراض سير العمل.
| | actualDuration, // الوقت المُستغرق لتصيير التحديث الحالي |
|
| |
|
| <syntaxhighlight class="">cordova run electron --nobuild</syntaxhighlight>
| | baseDuration, // الوقت المُقدر لتصيير القسم الفرعي من الهيكل بدون استخدام تقنيات تسريع |
| === بناء مشروع كوردوفا ===
| |
|
| |
|
| '''الإصدار التجريبي'''
| | startTime, // الوقت الذي بدأ فيه ريآكت بتصيير التحديث |
|
| |
|
| <syntaxhighlight class="">cordova build electron
| | commitTime, // الوقت الذي أنهى فيه ريآكت إرسال التحديث |
| cordova build electron --debug</syntaxhighlight>
| |
| '''الإصدار المستقر'''
| |
|
| |
|
| <syntaxhighlight class="">cordova build electron --release</syntaxhighlight>
| | interactions // مجموعة التفاعلات المتعلقة بالتحديث الحالي |
| == تخصيص خيارات نافذة التطبيق ==
| | ) { |
| | | // سِجل توقيت عمليات التصيير |
| يوفر إطار عمل إلكترون خيارات متعددة للتحكم بنافذة المُستعرض وسيُغطي هذا القسم كيفية إعداد بعض الخيارات الأساسية. راجع قسم [https://electronjs.org/docs/api/browser-window#new-browserwindowoptions خيارات نافذة العرض] من توثيق إلكترون لرؤية كامل قائمة الخيارات.
| |
| | |
| يُنصح بإنشاء ملف خاص بإعدادات إلكترون في جذر مسار مشروع كوردوفا وإدراج المسار المتعلق به في خيار <code>ElectronSettingsFilePath</code> الموجود بملف <code>config.xml</code> كما في المثال التالي:
| |
| | |
| <syntaxhighlight class=""><platform name="electron">
| |
| <preference name="ElectronSettingsFilePath" value="res/electron/settings.json" />
| |
| </platform></syntaxhighlight>
| |
| إذا أردت تغيير أي من خيارات نافذة المُستعرض (BrowserWindow) الافتراضية فستحتاج إلى إضافة تلك الخيارات إلى مُكوِّن <code>browserWindow</code> الموجود في ملف <code>res/electron/settings.json</code> كما هو موضح أدناه:
| |
| | |
| <syntaxhighlight class="">{
| |
| "browserWindow": { ... }
| |
| }</syntaxhighlight>
| |
| === كيفية تحديد حجم النافذة الافتراضي ===
| |
| | |
| أبعاد نافذة المُستعرض الافتراضية هي 800 للعرض و 600 للطول. لكنها قابلة للتخصيص عبر تعديل خصائص العرض والطول كما في المثال التالي:
| |
| | |
| <syntaxhighlight class="">{
| |
| "browserWindow": {
| |
| "width": 1024,
| |
| "height": 768
| |
| }
| |
| }</syntaxhighlight>
| |
| === كيفية منع تغيير حجم نافذة المُستعرض ===
| |
| | |
| يمكنك تعطيل إمكانية تغيير أبعاد نافذة المُستعرض من قبل المستخدم عبر استخدام خاصية <code>resizable</code> كما هو موضح أدناه:
| |
| | |
| <syntaxhighlight class="">{
| |
| "browserWindow": {
| |
| "resizable": false
| |
| }
| |
| }</syntaxhighlight>
| |
| === كيفية استخدام العرض الكامل لنافذة المُستعرض ===
| |
| | |
| يمكنك فرض عرض التطبيق بوضع الشاشة الكاملة عبر استخدام خاصية <code>fullscreen</code> كما في المثال التالي:
| |
| | |
| <syntaxhighlight class="">{
| |
| "browserWindow": {
| |
| "fullscreen": true
| |
| }
| |
| }</syntaxhighlight>
| |
| === كيفية دعم نظام برامج Node.js وواجهة برمجة تطبيقات إلكترون (Electron APIs) ===
| |
| | |
| حدد قيمة خاصية <code>nodeIntegration</code> إلى <code>true</code> لدعم مكتبات Node.js واستخدام الرموز التي يتشاركها Node.js وإلكترون كما هو موضح في المثال التالي. بشكل افتراضي فإن قيمة هذه الخاصية هي <code>false</code> ويمكنك قراءة المزيد من التفاصيل حول [https://electronjs.org/docs/faq#i-can-not-use-jqueryrequirejsmeteorangularjs-in-electron دعم مكتبات jQuery - RequireJS - Meteor - AngularJS] في توثيق إلكترون.
| |
| | |
| <syntaxhighlight class="">{
| |
| "browserWindow": {
| |
| "webPreferences": {
| |
| "nodeIntegration": false
| |
| }
| |
| }
| |
| }</syntaxhighlight>
| |
| == تخصيص عملية إلكترون الرئيسية ==
| |
| | |
| إذا احتجت إلى تخصيص عملية إلكترون الرئيسية بشكل يتخطى ما تُتيحه إعدادات إطار العمل فيُمكنك تغيير تعليمات ملف <code>cdv-electron-main.js</code> الموجود في مسار <code>{PROJECT_ROOT_DIR}/platform/electron/platform_www/</code> والخاص بعملية التطبيق الرئيسية.
| |
| | |
| لكن يجدر بنا تحذيركم من تعديل هذا الملف إذ أن عملية تحديث إطار cordova-electron تتضمن حذف المنصّة القديمة قبل تثبيت الإصدار الجديد.
| |
| | |
| == أدوات المطورين (DevTools) ==
| |
| | |
| تتحكم رايتي <code>release--</code> و <code>debug--</code> بإمكانية عرض أدوات المطورين والتي تظهر بشكل افتراضي في إصدارات الاختبار (Debug Builds). قد تتضمن تلك الإصدارات راية <code>debug--</code> أو قد لا تستخدم أي راية لذا إن أردت إخفاء أدوات المطورين في تلك الإصدارات فعليك إضافة راية <code>release--</code> عند بناء أو تشغيل التطبيق.
| |
| | |
| '''ملاحظة''': يمكن فتح أو إغلاق أدوات المطورين يدويًا في إصدارات الاختبار.
| |
| | |
| == إعدادات الإصدار ==
| |
| | |
| === إعدادات الإصدار الافتراضية ===
| |
| | |
| إذا لم تُدرج أي إعدادات إضافية فإن إطار عمل إلكترون سيُنشئ حزمة تستهدف نظام تشغيل الجهاز المُضيف والذي اُستخدم لإدخال استعلام تجميع الحزمة. يحتوي الجدول التالي على قائمة بالحزم الافتراضية لكل نظام تشغيل:
| |
| | |
|
| |
| | |
| '''لينكس'''
| |
| | |
| {| class="wikitable"
| |
| ! '''الحزمة'''
| |
| ! '''المعمارية'''
| |
| |-
| |
| | tar.gz
| |
| | x64
| |
| |}
| |
| | |
|
| |
| | |
| '''ماك'''
| |
| | |
| {| class="wikitable"
| |
| ! '''الحزمة'''
| |
| ! '''المعمارية'''
| |
| |-
| |
| | dmg
| |
| | x64
| |
| |-
| |
| | zip
| |
| | x64
| |
| |}
| |
| | |
|
| |
| | |
| '''ويندوز'''
| |
| | |
| {| class="wikitable"
| |
| ! '''الحزمة'''
| |
| ! '''المعمارية'''
| |
| |-
| |
| | nsis
| |
| | x64
| |
| |}
| |
| | |
| === تخصيص إعدادات الإصدار ===
| |
| | |
| إذا رغبت بتخصيص إعدادات الإصدار لأي سبب ما فستحتاج إلى تضمينها في ملف <code>build.json</code> والموجود في جذر مسار المشروع (مثل <code>{PROJECT_ROOT_DIR}/build.json</code>). يحتوي هذا الملف على جميع إعدادات الإصدار لجميع المنصّات (مثل أندرويد وإلكترون و iOS وويندوز). ستبدو بنية إعدادات إلكترون كما في المثال التالي:
| |
| | |
| <syntaxhighlight class="">{
| |
| "electron": {}
| |
| }</syntaxhighlight>
| |
| بما أن إطار عمل إلكترون يُستخدم لإنشاء تطبيقات عابرة للمنصات (أي تعمل على أنظمة تشغيل مختلفة) فستحتاج إلى تخصيص إعدادات منفصلة لكل منصّة على حدة. يتضمن مكوّن إلكترون الموجود في ملف <code>build.json</code> ثلاث خصائص تفصل بين إعدادات الإصدار لكل نظام تشغيل كما هو موضح في المثال التالي:
| |
| | |
| <syntaxhighlight class="">{
| |
| "electron": {
| |
| "linux": {},
| |
| "mac": {},
| |
| "windows": {}
| |
| }
| |
| }</syntaxhighlight>
| |
| يحتوي كل مكوّن على الخصائص اللازمة لتحديد أي حزمة يجب توليدها وكيف تُوقّع.
| |
| | |
| '''خصائص أنظمة التشغيل'''
| |
| | |
| * '''الحزمة (package)''': وهي مصفوفة تضم ترميز الإصدارات التي ستوَلّد لاحقًا
| |
| * '''المعمارية (arch)''': وهي مصفوفة من المعماريات التي تستهدفها كل حزمة منفصلة.
| |
| * '''التوقيع (signing)''': وهو مُكوِّن يحتوي معلومات التوقيع. راجع صفحة [https://cordova.apache.org/docs/en/latest/guide/platforms/electron/index.html#signing-configurations إعدادات التوقيع] لمزيد من المعلومات عن هذه النقطة.
| |
| | |
| سيستخدم إلكترون الإعدادات الافتراضية في حالة وجود أي خصائص غير محددة القيمة في ملف <code>build.json</code>.
| |
| | |
| === إضافة حزمة ===
| |
| | |
| تتضمن خاصية الحزمة (package) مصفوفة من ترميز الحزم التي ستُجمّع لاحقًا. إذا حدّدت تلك الخصائص فلن يستخدم إلكترون الحزم الافتراضية ما لم تُضفها بنفسك كما لن يهم ترتيب عناصر الحزمة الذي أدخلتها.
| |
| | |
| على سبيل المثال ستُولّد الإعدادات التالية حزم tar.gz و dmg و zip لمنصة ماك:
| |
| | |
| <syntaxhighlight class="">{
| |
| "electron": {
| |
| "mac": {
| |
| "package": [
| |
| "dmg",
| |
| "tar.gz",
| |
| "zip"
| |
| ]
| |
| }
| |
| }
| |
| }</syntaxhighlight>
| |
| '''الحزم المتاحة لكل نظام تشغيل''':
| |
| | |
| {| class="wikitable"
| |
| ! '''نوع الحزمة'''
| |
| ! '''لينكس'''
| |
| ! '''ماك'''
| |
| ! '''ويندوز'''
| |
| |-
| |
| | default
| |
| | -
| |
| | dmg - zip
| |
| | -
| |
| |-
| |
| | dmg
| |
| | -
| |
| | ✅
| |
| | -
| |
| |-
| |
| | mas
| |
| | -
| |
| | ✅
| |
| | -
| |
| |-
| |
| | mas-dev
| |
| | ✅
| |
| | -
| |
| | -
| |
| |-
| |
| | pkg
| |
| | -
| |
| | ✅
| |
| | -
| |
| |-
| |
| | 7z
| |
| | ✅
| |
| | ✅
| |
| | ✅
| |
| |-
| |
| | zip
| |
| | ✅
| |
| | ✅
| |
| | ✅
| |
| |-
| |
| | tar.xz
| |
| | ✅
| |
| | ✅
| |
| | ✅
| |
| |-
| |
| | tar.lz
| |
| | ✅
| |
| | ✅
| |
| | ✅
| |
| |-
| |
| | tar.gz
| |
| | ✅
| |
| | ✅
| |
| | ✅
| |
| |-
| |
| | tar.bz2
| |
| | ✅
| |
| | ✅
| |
| | ✅
| |
| |-
| |
| | dir
| |
| | ✅
| |
| | ✅
| |
| | ✅
| |
| |-
| |
| | nsis
| |
| | -
| |
| | -
| |
| | ✅
| |
| |-
| |
| | nsis-web
| |
| | -
| |
| | -
| |
| | ✅
| |
| |-
| |
| | portable
| |
| | -
| |
| | -
| |
| | ✅
| |
| |-
| |
| | appx
| |
| | -
| |
| | -
| |
| | ¹ ✅
| |
| |-
| |
| | msi
| |
| | -
| |
| | -
| |
| | ✅
| |
| |-
| |
| | AppImage
| |
| | ✅
| |
| | -
| |
| | -
| |
| |-
| |
| | snap
| |
| | ✅
| |
| | -
| |
| | -
| |
| |-
| |
| | deb
| |
| | ✅
| |
| | -
| |
| | -
| |
| |-
| |
| | rpm
| |
| | ✅
| |
| | -
| |
| | -
| |
| |-
| |
| | freebsd
| |
| | ✅
| |
| | -
| |
| | -
| |
| |-
| |
| | pacman
| |
| | ✅
| |
| | -
| |
| | -
| |
| |-
| |
| | p5p
| |
| | ✅
| |
| | -
| |
| | -
| |
| |-
| |
| | apk
| |
| | ✅
| |
| | -
| |
| | -
| |
| |}
| |
| | |
|
| |
| | |
| * ¹ يجدر بنا التنويه إلى أن الإصدار 10 فقط من نظام تشغيل ويندوز يمكنه إنشاء حزمة AppX.
| |
| | |
| === إعداد معمارية الحزمة ===
| |
| | |
| تضم خاصية المعمارية (arch) مصفوفة من المعماريات التي تستهدفها كل حزمة. إذا حدّدت قيمة هذه الخاصية فلن يستخدم إلكترون المعمارية الافتراضية عند تجميع تلك الحزمة.
| |
| | |
| '''ملاحظة''': الخيارات المتاحة لأي نظام تشغيل قد لا تتضمن جميع المعماريات. يمكنك مراجعة [https://github.com/electron/electron/releases/ صفحة إصدارات إلكترون] لمعرفة الخيارات المتاحة لنظام التشغيل الذي تستهدفه. على سبيل المثال فإن نظام ماك (داروين) لا يدعم سوى معمارية x64 فقط.
| |
| | |
| '''المعماريات المتاحة''':
| |
| | |
| * ia32
| |
| * x64
| |
| * armv7l
| |
| * arm64
| |
| | |
| لتوضيح ذلك فإن الإعدادات التالية ستُولّد حزمة dmg لمعمارية x64:
| |
| | |
| <syntaxhighlight class="">{
| |
| "electron": {
| |
| "mac": {
| |
| "package": [ "dmg" ],
| |
| "arch": [ "x64" ]
| |
| }
| |
| }
| |
| }</syntaxhighlight>
| |
| === كيفية دعم إصدار متعدد المنصّات ===
| |
| | |
| '''ملاحظة''': لا تدعم جميع المنصّات هذه الميزة وقد يتضمن استخدامها قيودًا على منصات أخرى.
| |
| | |
| من الممكن إنشاء تطبيق يعمل على منصات متعددة باستخدام نظام تشغيل واحد لكن ذلك قد يتضمن قيودًا ما. لذلك يُنصح باستخدام نظام التشغيل المستهدف لإنشاء تطبيق يعمل على نفس النظام. يعرض الجدول التالي التطبيقات متعددة المنصّات التي يمكن لكل نظام تشغيل إنشاءها:
| |
| | |
| {| class="wikitable"
| |
| ! '''الخادم ¹'''
| |
| ! '''لينكس'''
| |
| ! '''ماك'''
| |
| ! '''ويندوز'''
| |
| |-
| |
| | لينكس
| |
| | ✅
| |
| | -
| |
| | ²❗
| |
| |-
| |
| | ماك ³
| |
| | ✅
| |
| | ✅
| |
| | ²❗
| |
| |-
| |
| | ويندوز
| |
| | -
| |
| | -
| |
| | ✅
| |
| |}
| |
| | |
|
| |
| | |
| '''القيود''':
| |
| | |
| * ¹ : إذا كان التطبيق يحتوي أي مكتبات تستخدم تعليمات لغة الآلة الأصلية لنظام التشغيل المُستهدف فلن يمكن تفسير التعليمات البرمجية إلا على نظام التشغيل المُستهدف.
| |
| * ² : لا يمكن لنظامي ماك ولينكس إنشاء حزم Appx التي تستهدف متجر تطبيقات ويندوز.
| |
| * ³ : ستُحمّل جميع متطلبات النظام تلقائيًا عند الطلب ما عدا مدير حزم RPM والذي ستحتاج إلى تحميله باستخدام أداة brew (متاحة لإصدار ماك Sierra 10.12 أو أعلى).
| |
| | |
| سيُفعّل الضبط التالي ميزة إنشاء إصدار متعدد المنصّات لجميع أنظمة التشغيل المُدرجة باستخدام الإعدادات الافتراضية:
| |
| | |
| <syntaxhighlight class="">{
| |
| "electron": {
| |
| "linux": {},
| |
| "mac": {},
| |
| "windows": {}
| |
| }
| |
| }</syntaxhighlight>
| |
| == إعدادات التوقيع ==
| |
| | |
| === التوقيع لنظام ماك ===
| |
| | |
| هناك ثلاثة أنواع من أهداف التوقيع (signing) هي <code>debug</code> و<code>release</code> و<code>store</code>. يحتوي كل منها على الخصائص التالية:
| |
| | |
| {| class="wikitable"
| |
| ! '''مفتاح الكائن'''
| |
| ! '''الوصف'''
| |
| |-
| |
| | entitlements
| |
| | قيمة المسار إلى ملف الاستحقاقات (entitlements file)
| |
| |-
| |
| | entitlementsInherit
| |
| | قيمة المسار إلى ملف الاستحقاقات الذي يرث إعدادات الأمان
| |
| |-
| |
| | identity
| |
| | نص يحتوي على اسم الشهادة
| |
| |-
| |
| | requirements
| |
| | قيمة المسار إلى ملف المتطلبات -❗لاحظ أن هذا المفتاح غير متاح في إعدادات توقيع إصدار المتجر (mas)
| |
| |-
| |
| | provisioningProfile
| |
| | قيمة المسار إلى ملف التزويد (provisioning profile)
| |
| |}
| |
| | |
| مثال على ذلك:
| |
| | |
| <syntaxhighlight class="">{
| |
| "electron": {
| |
| "mac": {
| |
| "package": [
| |
| "dmg",
| |
| "mas",
| |
| "mas-dev"
| |
| ],
| |
| "signing": {
| |
| "release": {
| |
| "identity": "APACHE CORDOVA (TEAMID)",
| |
| "provisioningProfile": "release.mobileprovision"
| |
| }
| |
| }
| |
| }
| |
| }
| |
| }</syntaxhighlight>
| |
| هناك بعض الاستثناءات لكيفية استخدام توقيع المعلومات في نظام ماك. لكن بشكل افتراضي فإن جميع إصدارات الحزم ما عدا <code>mas</code> و <code>mas-dev</code> تستخدم إعدادات توقيع <code>debug</code> و <code>release</code>.
| |
| | |
| لنستخدم المثال سابق الذكر لمراجعة بعض الحالات لتعميق فهمنا لتلك الاستثناءات.
| |
| | |
| '''الحالة الأولى''':
| |
| | |
| <syntaxhighlight class="">cordova build electron --debug</syntaxhighlight>
| |
| يهدف الأمر أعلاه إلى:
| |
| | |
| * توليد إصداري dmg و mas-dev باستخدام إعدادات توقيع debug.
| |
| * تجاهل توليد حزمة mas التي تستهدف نظام تشغيل ماك.
| |
| | |
| '''الحالة الثانية''':
| |
| | |
| <syntaxhighlight class="">cordova build electron --release</syntaxhighlight>
| |
| ينتج عن الأمر السابق:
| |
| | |
| * توليد إصدار <code>dmg</code> باستخدام إعدادات <code>release</code>.
| |
| * توليد إصدار <code>mas</code> باستخدام إعدادات <code>store</code>.
| |
| * تجاهل توليد حزمة <code>mas-dev</code>.
| |
| | |
| === التوقيع لنظام ويندوز ===
| |
| | |
| تتضمن معلومات التوقيع الخاصة بنظام ويندوز نوعين من الوسوم هما debug و release ويحتوي كل قسم منهما على الخصائص التالية:
| |
| | |
| {| class="wikitable"
| |
| ! '''مفتاح الكائن'''
| |
| ! '''الوصف'''
| |
| |-
| |
| | certificateFile
| |
| | نص يُمثل قيمة المسار إلى ملف الشهادة
| |
| |-
| |
| | certificatePassword
| |
| | نص يُمثل قيمة كلمة المرور الخاصة بالشهادة. يمكن الاستعاضة عن هذا المفتاح عبر تحديد قيمة متغيّر <code>CSC_KEY_PASSWORD</code> في بيئة التطوير
| |
| |-
| |
| | certificateSubjectName
| |
| | نص يحتوي على موضوع شهادة التوقيع.❗يتطلب هذا المفتاح استخدام ترميز توقيع EV ونظام تشغيل ويندوز
| |
| |}
| |
| | |
| |signingHashAlgorithms|مجموعة الخوارزميات المستخدمة لتوقيع الحزمة (مثلًا sha1 و sha256).❗لا تدعم إصدارات AppX سوى خوارزمية تشفير |sha256certificateSha1|قيمة شفرة SHA1 الخاصة بشهادة التوقيع.❗ يتطلب استخدام نظام تشغيل ويندوز| |additionalCertificateFile|قيمة المسار إلى ملفات الشهادة الإضافية|
| |
| | |
| | |
| | |
| مثال على توقيع حزمة لنظام تشغيل ويندوز:
| |
| | |
| <syntaxhighlight class="">{
| |
| "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]] |
| [[ReactNative:تصنيف]]
| |
يُحدد الفاحص 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) لتحديد سبب التحديث لكن يجدر بك معرفة أنّ واجهة التطوير الخاصة بها لا تزال تحت الاختبار. راجع توثيق تتبع التفاعلات لمزيد من المعلومات عن هذه النقطة.
المصادر