كيف تحسّن أداء SwiftUI فيما يخص هوية العرض (view identity) والمقارنة (diffing)؟

Question

IT Interview Practice · Accepted Answer

تعيد SwiftUI تشغيل `body` كلما تغيّرت الحالة المراقَبة، ثم **تقارن (diffs)** شجرة العرض الجديدة بالقديمة وتحدّث ما اختلف فقط. تنشأ مشكلات الأداء من جعل تلك المقارنة تؤدي عملًا أكثر من اللازم: **هوية** غير مستقرة، و**مراقبة** واسعة أكثر مما ينبغي، وحسابات `body` باهظة. عالِج ذلك بالتحكم في الهوية، وتضييق نطاق الحالة، وإبقاء `body` رخيصًا.

## كيف تعمل المقارنة والهوية

تطابق SwiftUI العروض عبر عمليات العرض المتتالية بواسطة **الهوية**. وبالنسبة للقوائم يكون ذلك `id`؛ فإذا كان المعرّف غير مستقر، تتخلص SwiftUI من العرض وتعيد بناءه (فاقدةً الحالة والرسوم المتحركة) بدلًا من تحديثه.

```swift
// BAD: array index as id — reorders/inserts break identity, full rebuild
ForEach(items.indices, id: \.self) { i in Row(items[i]) }

// GOOD: stable identity tied to the data
ForEach(items) { item in Row(item) }      // items: Identifiable, stable id
```

## تضييق نطاق المراقبة

يعيد `ObservableObject` عرض **كل** عرض يراقبه كلما تغيّرت **أي** خاصية `@Published`. قسّم النماذج الكبيرة، أو انتقل إلى **إطار Observation** (`@Observable`، iOS 17 فما فوق)، الذي يتتبّع القراءات *لكل خاصية على حدة* بحيث لا يُعاد عرض العرض إلا عند تغيّر خاصية استخدمها فعلًا.

```swift
@Observable final class Feed {     // iOS 17: fine-grained dependency tracking
    var unreadCount = 0            // a view reading only .posts won't re-render on this
    var posts: [Post] = []
}
```

## إبقاء body رخيصًا

يعمل `body` كثيرًا، لذا لا تنفّذ عملًا ثقيلًا داخله مباشرة:

```swift
var body: some View {
    List(sortedItems) { ... }      // BAD if sortedItems sorts on every render
}
// GOOD: compute derived data in the model, not in body
```

- استخرج العروض الفرعية بحيث يعيد تغيّر الحالة عرض عرض **صغير**، لا الشاشة بأكملها.
- استخدم `LazyVStack`/`List` للمجموعات الكبيرة بحيث لا تُبنى الصفوف خارج الشاشة.
- أضف `.equatable()` أو `EquatableView` لقطع المقارنة على الأشجار الفرعية المستقرة.

## المزالق

- يمحو `AnyView` هوية النوع ويُبطل المقارنة البنيوية — تجنّبه في المسارات الساخنة.
- تمرير closure/مصفوفة حرفية جديدة عند كل عرض قد يُبطِل العروض الفرعية دون داعٍ.

## لماذا يهم

على شاشة ProMotion بتردد 120Hz لديك نحو 8ms لكل إطار؛ و`body` الذي يفرز مصفوفة كبيرة أو يعيد عرض قائمة بأكملها يُسقط إطارات ويُسبّب تلعثم التمرير. تسبر مقابلات المستوى الأعلى هوية العرض ونطاق المراقبة لأن هناك حيث تتباطأ تطبيقات SwiftUI الحقيقية — وحيث تعيد بضعة إصلاحات دقيقة السلاسة.

كيف تعمل المقارنة والهوية

تضييق نطاق المراقبة

إبقاء body رخيصًا

المزالق

لماذا يهم

أسئلة ذات صلة