كيف يتم تنفيذ كود C# (IL و JIT و AOT)؟

Question

Accepted Answer

لا يقوم C# بالترجمة المباشرة إلى كود الآلة. بدلاً من ذلك، يتم تجميعه إلى **IL** (لغة وسيطة) — وهي bytecode مستقلة عن المنصة — والتي يقوم **CLR** بتشغيلها، باستخدام **JIT** (ترجمة في الوقت المناسب) لترجمة IL إلى كود الآلة الأصلي في وقت التشغيل. **AOT** (الترجمة قبل التشغيل) هو بديل يقوم بترجمة الكود إلى code أصلي في وقت البناء.

## خط أنابيب التنفيذ

```text
C# source (.cs)
   │  C# compiler (roslyn)
   ▼
IL bytecode (in a .dll/.exe assembly)  ← platform-INDEPENDENT intermediate code
   │  CLR loads it; JIT compiles IL → native code AT RUNTIME (per method, as called)
   ▼
Native machine code → executes on the CPU
```

مجمع C# ينتج **IL** (bytecode مستقل عن المعالج)، معبأ في assembly. في وقت التشغيل، يستخدم **CLR** (Common Language Runtime) **مجمع JIT** لترجمة طرق IL إلى كود الآلة الأصلي عند استدعاؤها أولاً — وكود الآلة يتم تخزينه مؤقتاً للاستدعاءات اللاحقة.

## لماذا IL + JIT؟ الفوائد

```text
✓ Platform independence — the SAME IL runs on any platform with a CLR
✓ Runtime optimization — the JIT optimizes for the ACTUAL hardware it runs on
✓ Language interoperability — C#, F#, VB all compile to IL → can interoperate
✓ The CLR provides GC, type safety, security on top
```

IL + JIT يوفر استقلالية المنصة (assembly واحد، أي منصة بها runtime) ويسمح لـ JIT بالتحسين لأجهزة معينة. (هناك تكلفة بدء حيث يتم ترجمة الطرق بـ JIT عند الاستخدام الأول.)

## AOT — ترجمة قبل التشغيل

```text
Native AOT (modern .NET) → compiles directly to native machine code at BUILD time.
  ✓ FASTER startup (no JIT at runtime), smaller deployment, lower memory
  ✓ Good for: serverless, CLI tools, containers (where fast startup matters)
  ✗ Trade-offs: no runtime JIT optimization, some reflection/dynamic limitations
JIT (default) → flexible, runtime-optimized, but has startup/warm-up cost.
```

**AOT** تقوم بترجمة الكود إلى كود أصلي في وقت البناء — مما يلغي تكلفة بدء JIT (بدء أسرع، حجم أصغر، ذاكرة أقل)، وهو قيِّم للتطبيقات التي بدون خادم وواجهات سطر الأوامر، على حساب بعض المرونة.

## أهمية هذا

فهم كيفية تنفيذ كود C# — خط أنابيب **IL → JIT → native** — هو معرفة قيمة لفهم منصة .NET بعمق، وشرح إمكانياتها، واتخاذ قرارات مستنيرة حول النشر والأداء.

الرؤية الأساسية هي أن C# يتم تجميعه إلى **IL** (bytecode مستقل عن المنصة) بدلاً من الكود الأصلي، و**CLR** يستخدم **ترجمة JIT** لترجمته إلى كود آلي أصلي في وقت التشغيل — وهذا هو ما يمكّن استقلالية منصة .NET (نفس assembly المترجم يعمل في أي مكان به runtime)، تحسين وقت التشغيل (JIT يحسّن للأجهزة الفعلية)، والتوافقية بين اللغات (C# و F# و VB جميعها تتجمع إلى IL).

هذا يفسر السلوكيات مثل تكلفة بدء/إحماء JIT (ذات صلة عند قياس الأداء أو تحسين البدء).

فهم **AOT** (Native AOT، بديل حديث يقوم بترجمة الكود إلى كود أصلي في وقت البناء) أصبح مهماً بشكل متزايد للسيناريوهات المحددة: فهو يوفر **بدء أسرع وانتشار أصغر وذاكرة أقل** (قيِّم لدوال serverless وأدوات CLI والحاويات حيث يهم وقت البدء والحجم)، على حساب تحسين JIT في وقت التشغيل وبعض قيود reflection/dynamic — لذا فهم المقارنة بين JIT و AOT يساعدك على اختيار الطريقة الصحيحة لهدف النشر.

بينما هذا أكثر مفهومياً من معرفة الترميز اليومية، فهم نموذج التنفيذ (IL/JIT/AOT) قيِّم لشرح كيفية تحقيق .NET للاستقلالية عن المنصة والأداء، والاستدلال على أداء البدء، واتخاذ قرارات النشر (خاصة الصلة المتزايدة لـ AOT للسيناريوهات الأصلية للسحابة) — مما يجعله معرفة ذات صلة على مستوى كبير توضح فهماً عميقاً لمنصة .NET وهي موضوع ذا صلة للنقاشات التي تركز على الأداء والنشر.