تطبيق واجهة المستخدم الرسومية (GUI) المهم للأداء (Windows، Linux)

Question

لقد تم تكليفي بتحديث سلسلة من التطبيقات التي تعتبر تطبيقات VB.NET ذات أهمية كبيرة للأداء والتي تقوم فقط بمراقبة إحصائيات الشبكة وإرجاعها.لدي ثلاثة متطلبات فقط: قم بتحويله إلى C#، وجعله سريعًا، واجعله مستقرًا

تحذير واحد هو أننا "يمكن" الترحيل من منصة .NET إلى Linux "قريباً"

سأكون مسؤولاً عن صيانة هذه التطبيقات في المستقبل، لذا أود القيام بذلك بشكل صحيح.لقد قررت إعادة تصميم هذه التطبيقات وفقًا لنمط MVP حتى أتمكن من اختبار الوحدة بشكل صحيح لهذا الولد الشرير.لكنني كنت أفكر أيضًا منذ أن كنت أستخدم MVP أنه يمكنني أيضًا القيام بالأشياء باهظة الثمن حسابيًا في كود C/C++ الأصلي بينما سيتم تنفيذ واجهة المستخدم الرسومية باستخدام نماذج .NET أو Qt أو أي شيء آخر.

أسئلة:

1. هل من المنطقي إنشاء واجهة المستخدم الرسومية في winforms ولكن الأشياء باهظة الثمن في لغة C/C++ الأصلية وغير المُدارة؟

2. هل هناك أي توصيات لمجموعة أدوات نوافذ جيدة عبر الأنظمة الأساسية تناسب السيناريو الموضح أعلاه؟

Answer 1

أولاً، أود أن أخصص بعض الوقت لتجربة عدد قليل منها محولات VB.NET إلى C#.أنت تقوم بشكل أساسي بنقل بناء الجملة، وليس هناك سبب للقيام بذلك يدويًا إذا لم تكن مضطرًا إلى ذلك.بالتأكيد، قد يتعين عليك تنظيف ما يخرج من المحول، ولكن هذا أفضل بكثير من التحويل اليدوي.

والآن بالنسبة لأسئلتك:

1) هل من المنطقي إنشاء واجهة مستخدم رسومية في winforms ولكن الأشياء باهظة الثمن في لغة C/C++ الأصلية وغير المُدارة؟

ليس بعد.انتظر حتى تنتهي من التحويل، ثم اكتشف أين تقضي وقتك فعليًا.لا يوجد سبب للانتقال إلى خلط C/C++ مع C# حتى تكتشف أن ذلك ضروري.قد تجد أن الانتقال إلى لغة C# غير الآمنة يعد أمرًا كافيًا.وحتى هذا قد يكون غير ضروري.قد تحتاج فقط إلى تحسين الخوارزميات.اكتشف ما هي الاختناقات لديك و ثم تقرر كيفية اصلاحها.

2) هل هناك أي توصيات لمجموعة أدوات نوافذ جيدة عبر الأنظمة الأساسية تناسب السيناريو الموضح أعلاه؟

سأكون أبحث في كثرة الوحيدات بالتأكيد.هذا حقًا أفضل ما يمكنك فعله إذا كنت تستخدم لغة C#.إنها إما أحادية أو إعادة كتابة أخرى بلغة أخرى عندما/إذا انتقلت إلى Linux.

Answer 2

1) التحسين المبكر شر.قم بتنفيذ "الأشياء باهظة الثمن" في C# ومعرفة ما إذا كنت بحاجة إلى إعادة هيكلتها.أو على الأقل قم بإعداد اختبار يسمح لك بتحديد ذلك.

2) يوتش.واجهة مستخدم عبر النظام الأساسي.لن أتحمل أشياء "ربما".ثبت ابن عرس؛كيف يمكنك اتخاذ قرارات التصميم دون معرفة ما تصممه؟إذا اخترت تطبيق .NET خالصًا، فهل سيشتكون إذا كان عليك (على الأقل) إعادة هيكلته للعمل في Mono؟إذا قمت بإنشائه في Java، فهل سينزعجون لأنه يبدو قبيحًا للغاية ويشكو المستخدمون من عدم تمكنهم من العثور على ملف .exe الخاص بهم بين كل تلك الجرار؟

Answer 3

1) ليس بالضرورة.أعتقد أنه سيكون من الأصح القول أنه ربما يكون من المفيد كتابة كود الواجهة الخلفية الخاص بك بلغة C++، بغض النظر عن الآثار المترتبة على الأداء.على الرغم من أنك لا تستطيع ربط كبار المسؤولين لديك بمفتاح النظام الأساسي، سيكون من الحكمة منك اتخاذ الاستعدادات لهذا الاحتمال، نظرًا لأن أنواع الإدارة تميل إلى تغيير رأيها كثيرًا دون سبب وجيه (أو تحذير)؛حتى لو قرروا عدم التبديل الآن، فهذا لا يعني أنهم لن يقرروا التبديل بعد ستة أشهر من الآن.كتابة المنطق الخاص بك في C++ الآن، مع العلم أنه احتمال، على الرغم من أنه أكثر صعوبة، قد يجعل حياتك أسهل بكثير في وقت لاحق.

2) ليس حقا.توجد "حلول" مثل wxWindows وGTK#، ولكنها غالبًا ما تكون بها عربات التي تجرها الدواب، أو يصعب تشغيلها بشكل صحيح، أو تفتقر إلى شيء مهم على نظام أساسي أو آخر.كما أنها عادةً ما تقيدك في واجهة مستخدم ذات قاسم مشترك أدنى (على سبيل المثال، تعمل عناصر التحكم العامة بشكل جيد ولكن يمكنك أن تنسى القيام بشيء مثير للاهتمام - WPF، على سبيل المثال - معها).من السهل كتابة واجهات المستخدم، لذلك أعتقد أنه إذا كتبت المنطق الخاص بك في شيء محمول، فيجب أن يكون أمرًا تافهًا تجميع العديد من واجهات المستخدم الخاصة بالنظام الأساسي.

Answer 4

بالنسبة للسؤال الأول، من الصعب حقًا تحديد ما إذا كان الأمر منطقيًا لأنه من المحتمل أن يعتمد على نوع الأداء الذي تحتاج إلى الحصول عليه.أنا شخصياً لم أشاهد أي بطء على مستوى النظام بسبب واجهة المستخدم الرسومية في واجهات المستخدم الرسومية المصممة بشكل صحيح باستخدام WinForms، لذلك لا أرى سببًا وراء تسبب ذلك في أي مشكلات، وعلى الأرجح سيجعل حياتك أسهل فيما يتعلق بواجهة المستخدم الرسومية .

أما بالنسبة لسؤالك الثاني، إذا كنت ستنتقل إلى منصة أخرى في وقت ما - فأنت تريد إلقاء نظرة على المكتبات التي تم تنفيذها بواسطة Mono (http://www.mono-project.com/Main_Page)، يجب أن يغطي هذا أيضًا معظم احتياجاتك فيما يتعلق بالنوافذ عبر الأنظمة الأساسية لأنه يدعم WinForms وGTK#.

Answer 5

لا، ليس من المنطقي القيام "بالأشياء باهظة الثمن" في C/C++.إن تحسينات الأداء المحتملة (وعلى الأرجح الطفيفة) لا تفوق أبدًا إنتاجيتك كونها مزحة سيئة ومرضية بالمقارنة مع C#.حقًا.انها ليست قريبة حتى.

اقرأ هذا (وجميع المشاركات المشار إليها داخل):http://blogs.msdn.com/ricom/archive/2005/05/10/416151.aspx

Answer 6

قد ترغب في النظر في استخدام كثرة الوحيدات.هذا إصدار مفتوح المصدر من .NET يعمل على العديد من الأنظمة الأساسية... Linux، وMac، وSolaris، وWindows، وما إلى ذلك.

الآن حول ترميز الأشياء باهظة الثمن في C/C++.إليك مقال يقوم بعمل جيد للغاية يشرح الاختلافات بين أداء C/C++ وC#.

Answer 7

ومرة أخرى، اسمحوا لي أن أؤكد أن عناصر C++ باهظة الثمن للغاية.فهل يعقل أن أفعل ما ذكرته أعلاه؟(نماذج .NET تخفي رفع الأحمال الثقيلة C++)

كما ذكرنا سابقًا، أنا شخصيًا لم ألاحظ أي بطء على مستوى النظام بسبب WinForms في التطبيقات المكتوبة باللغتين VB.NET وC#.ومع ذلك، إذا كان التطبيق كثيف الأداء حقًا، فقد تلاحظ بطءًا طفيفًا إذا كتبت كل شيء في C# نظرًا لامتثاله لـ CIL (http://www.cl.cam.ac.uk/research/srg/han/hprls/orangepath/timestable-demo/).على هذا النحو، فإن كتابة واجهة المستخدم الرسومية بلغة مثل C# من المحتمل أن تجعل هذا الجزء من التطوير أسهل قليلاً مما يمنحك المزيد من الوقت للعمل على الأجزاء المهمة من التعليمات البرمجية.المشكلة الوحيدة هنا هي ملاحظة بعض التباطؤ بسبب استدعاء كود C/C++ من كود C#؛ومع ذلك، فمن المرجح أن هذا غير مرجح للغاية.

Answer 8

1) هل من المنطقي إنشاء واجهة مستخدم رسومية في winforms ولكن الأشياء باهظة الثمن في لغة C/C++ الأصلية وغير المُدارة؟

على الأرجح لا.ما لم تكن تتواصل مع الكثير من ملفات C dll الأصلية الأخرى أو ما إلى ذلك، فمن المرجح أن تكون لغة C# أبطأ بنسبة تتراوح بين 5% إلى 5%. أسرع من C++ (std::string يقتلك حقًا إذا كنت تستخدمه)

2) هل هناك أي توصيات لمجموعة أدوات نوافذ جيدة عبر الأنظمة الأساسية تناسب السيناريو الموضح أعلاه؟

إذا كان الأمر يتعلق فقط ببعض النماذج البسيطة التي تحتوي على أزرار، فمن المحتمل أن يتمكن mono من تشغيلها بدون تعديل.يعد دعم .NET WinForms جيدًا جدًا هذه الأيام.ومع ذلك فهو قبيح :-)

Answer 9

ربما أسيء فهم الموضوع, ، ولكن إذا كان نظامًا لمراقبة الشبكة، فلماذا لا يتم كتابته كخدمة Windows "مخصصة"؟

لا ينبغي أن يكون VB.NET أبطأ بكثير من C#.لست متأكدًا بنسبة 100% مما إذا كان هناك أي اختلافات كبيرة في كود IL الذي تم إنشاؤه، ولكن الميزة الوحيدة (والسبب المبرر لإعادة كتابته في C#) التي يمكنني التفكير فيها (باستثناء أن C# لديها بناء جملة أجمل وبعض الأشياء الجيدة الأخرى) ) هو استخدام كتلة تعليمات برمجية غير آمنة قد تؤدي إلى تسريع الأمور قليلاً.

Answer 10

قد تكون عناصر c/c++ في نهاية المطاف فكرة جيدة، ولكن الآن YAGNI.نفس الشيء مع أشياء Linux.تجاهله، لن تحتاج إليها حتى تحتاج إليها.إحتفظ به بسيط.وحدة اختبار الجحيم للخروج منه، كما تقول.احصل على الكود يعمل و تطوير التصميم من هناك.

Answer 11

لقد واجهت معضلة مماثلة في وقت ما، أثناء محاولتي اكتشاف أفضل طريقة لتطوير أداة اختبار H/W المستندة إلى الكمبيوتر الشخصي (والتي تعني بوضوح "مع خيارات واجهة المستخدم") التي تتفاعل مع الأجهزة المضمنة (عبر واجهة PCMCIA).

كان عنق الزجاجة هو أن الاختبار يجب أن يتم بأقصى انحراف قدره 10 مللي ثانية عن الوقت المقصود الذي حدده المختبر.

على سبيل المثال:إذا قام المختبر بإنشاء تسلسل الاختبار التالي:

1.تفعيل H/W عن بعد
2.انتظر تأخير 50 ​​مللي ثانية.
3.قراءة معلومات H/W.

يجب ألا يكون التأخير المذكور في الخطوة 2 > 60 مللي ثانية.

لقد اخترت تطبيق C++ WIN32 كواجهة خلفية وVC++ 2005 Winform (منصة .NET) لتطوير واجهة المستخدم.تتوفر معلومات تفصيلية حول كيفية التعامل مع هذين الاثنين في msdn
لقد قمت بفصل النظام مثل هذا:
في VC++.NET:

1.واجهة المستخدم للحصول على معلومات كاملة حول H/W (القراءة عبر التطبيق الخلفي) والتحكم في H/W عند الطلب.(الأزرار ومربع التحرير والسرد وما إلى ذلك.إلخ..)
2.واجهة المستخدم لتشغيل تسلسلات الاختبار الحرجة للوقت (كما هو مذكور في المثال أعلاه).
3.جمع هذه المعلومات وإنشاء دفق (دفق ملف) بتنسيق خطي زمني (أي بالترتيب الدقيق للخطوات التي يجب تنفيذها).
4.آلية التشغيل والاهتزاز (عن طريق إعادة توجيه الإدخال القياسي والإخراج القياسي) مع تطبيق WIN32 الخلفي.الموارد المشتركة ستكون تدفقات الملفات.

في C++ WIN32:

1.تفسير دفق ملف الإدخال.
2.التفاعل مع H/W.
3.جمع المعلومات من H/W ووضعها في تدفق ملفات الإخراج الخاص بها.
4.إشارة إلى اكتمال الاختبار لواجهة المستخدم (عبر الإخراج القياسي المعاد توجيهه).

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

Answer 12

gtk-شارب هي مجموعة أدوات لطيفة جدًا عبر الأنظمة الأساسية.

Gtk# عبارة عن مجموعة أدوات لواجهة المستخدم الرسومية لـ mono و.Net.يربط المشروع مجموعة أدوات gtk+ ومكتبات جنوم المتنوعة، مما يتيح تطوير تطبيقات جنوم الرسومية الأصلية بالكامل باستخدام أطر التطوير Mono و.Net.