قليلا عن Neutralino.js

ما هو المحايدة.


هذه التكنولوجيا هي تناظرية مثيرة للاهتمام إلى حد ما من Electron و NodeWebkit القائمة حاليًا . كيف تختلف عن الحلول التكنولوجية المذكورة أعلاه؟ إذا كنت تعتقد أن البيانات المقدمة في الوثائق الرسمية ، فإن بنية بناء التطبيق نفسه ممتازة ، مما يسمح لك بإنشاء تطبيقات عبر الأنظمة الأساسية على تقنيات الويب بحجم صغير بما فيه الكفاية من البناء النهائي.

صورة

كيف تسير عملية التثبيت؟


استنادًا إلى الوثائق الرسمية ، يمكننا التمييز بين خيارين لتثبيت واستخدام التكنولوجيا الموضحة في تطوير تطبيقاتنا عبر الأنظمة الأساسية الخاصة بنا على تقنيات الويب.

  1. قم بتنزيل حزمة SDK المحمولة النهائية .
  2. استخدام واجهة CLI خاصة تحت اسم neu-cli.

في هذه المقالة سننظر في خيار التثبيت الثاني بالضبط ، لأنه في رأيي الشخصي ، فإن الحل المحدد هو الأكثر شمولية من الناحية المعمارية والعملية.

#  npm
$ ~ npm install -g @neutralinojs/neu

#  yarn
$ ~ yarn global add @neutralinojs/neu

ملاحظة لمستخدمي أنظمة * nix
, webkit2gtk. Neutralino.js.

#  Linux Arch   
$ ~ sudo pacman -S webkit2gtk

#  Debian   
$ ~ sudo apt-get install libwebkit2gtk


السمات المعمارية الرئيسية


يتم تنفيذ هذه التقنية على أساس بنية خادم العميل ، وتتميز أيضًا باستخدام نظام بناء غير تافه إلى حد ما ، والذي يعتمد على الملفات الثنائية المعدة مسبقًا لكل نظام تشغيل.
ربما أيضًا ، تجدر الإشارة إلى أن هناك العديد من الاختلافات في برامج بدء التشغيل وتصحيحها ، وهي:

  1. السحابة - تتميز بالقدرة على توصيل أي منتج برمجي ، مع مراعاة شعبية المنفذ المستخدم فيه.
  2. المتصفح - يتميز بالفتح التلقائي للمتصفح الرئيسي على كمبيوتر المستخدم. يتم استخدام نظام الرمز المميز.
  3. Window هي الطريقة الرئيسية المستخدمة لتوزيع برامجك. كما في الإصدار السابق ، يتم استخدام نظام الرمز المميز ، والذي يتم تضمينه في مستند html الخاص بك.

المجلد ونظام الملفات


├── app
| ├── assets
| | ├── app.css
| | ├── app.js
| | └── neutralino.js
| ├── index.html
| └── settings.json
└── neutralino-win.exe
└── neutralino-linux
└── neutralino-mac
└── storage

  1. app/assets — , Neutralino.js , . , app.css app.js.
  2. index.html — .
  3. settings.json — , .
  4. appname-linux — Linux.
  5. appname-win.exe — Windows.
  6. appname-mac — macOS.
  7. storage — JSON , .

. API-


  1. Settings — , «settings.json».
  2. File System — . , , .
  3. OS — . ,
  4. Computer — . .
  5. Storage — JSON- «storage».
  6. Debug — . .
  7. App — . exit.


يحاول مطورو هذه التقنية الالتزام ببيئة أضيق الحدود لتطبيقك النهائي ، ومن هذا يتبعها بعض الأخطاء والمشكلات المثيرة للاهتمام.

أولاً ، هناك وظيفة محدودة للغاية. ماذا سيحدث إذا كانت ناقصة؟ بالضبط. سيكون عليك استخدام حل تكنولوجي مختلف تمامًا.
ثانيًا ، لا يوجد تفاعل بين عملية التقديم وعملية الخادم في الوثائق الرسمية. في هذه الحالة ، لديك خيار واحد فقط لحل مشكلتك - عرض رموز المصدر من المطورين.

ثالثًا ، لا يتوافق نظام التجميع المستخدم مع مجموعة بيانات أضيق الحدود ، لأن توزيع البرامج تحتاج إلى توزيع كلا الملفين في نفس الوقت لنظام * nix و Windows.

رابعاً ، ينتهي الحد الأدنى المعلن للبناء النهائي بتجميع تطبيق رد فعل اختباري. البناء النهائي يذهب حوالي 180-190 MiB.

استنتاج


تعتبر التكنولوجيا الموضحة في هذه المقالة حلاً هندسيًا مثيرًا للاهتمام لكتابة تطبيقات سطح المكتب استنادًا إلى تقنيات الويب ، ولكن في الوقت نفسه منتج خام للغاية ، والذي في هذه المرحلة ليس قادرًا على إعطاء منافسة جيدة ليس فقط للإلكترون ، ولكن أيضًا لـ NodeWebkit .

في رأيي الخاص ، تكمن هذه المشكلة على وجه التحديد في الحلول المعمارية المستخدمة والتوثيق غير الكافي للتكنولوجيا نفسها. ربما يجب عليك توسيع وظائف التطبيق النهائي؟ وهل هذا الحد الأدنى مطلوب في وقت معين؟ بعد كل شيء ، فإن مكاسب 20-30 MiB لذاكرة الوصول العشوائي صغيرة جدًا وفقًا لمعايير الأجهزة اليوم.

All Articles