אופטימיזציית ביצועים ב-.NET MAUI 10: זמן הפעלה, CollectionView וניהול זיכרון

ביצועים. זה מה שמבדיל בסופו של דבר בין אפליקציה שמורידים פעם אחת ושוכחים, לבין אפליקציה שהמשתמשים חוזרים אליה שוב ושוב. וב-.NET MAUI 10 המצב ממש השתפר — Hot Reload מהיר יותר, קומפילציית AOT שעובדת סוף סוף טוב, ו-Handlers שעברו דיאטה רצינית. אבל בואו נהיה כנים: עדיין יש הרבה אפליקציות בחוץ שסובלות מזמני הפעלה איטיים, גלילה מקוטעת ב-CollectionView ודליפות זיכרון שגורמות להאטה מצטברת (הכאב הזה מוכר לכל מי שפיתח אפליקציה ציבורית).

במדריך הזה אעבור איתכם על הטכניקות שעבדו לי הכי טוב בפועל בשנה האחרונה: מקיצור זמן ההפעלה הקר, דרך אופטימיזציה של רשימות ארוכות, ועד לניהול זיכרון חכם עם WeakReferenceMessenger. כל המלצה שתראו כאן מגובה במדידות אמיתיות, לא בתיאוריה מהבלוגים של מיקרוסופט.

אז למה הביצועים חשובים דווקא ב-.NET MAUI 10?

לפי מחקרי משתמשים של Google ו-Apple, 53% מהמשתמשים נוטשים אפליקציה שלוקח לה יותר משלוש שניות להיטען. שלוש שניות. זה כלום. ובאנדרויד המצב אפילו קשוח יותר — מערכת ההפעלה מציגה מסך ANR (Application Not Responding) לאחר חמש שניות של חוסר תגובה, ו-Google Play פשוט דוחה אפליקציות עם אחוזי קריסה מעל 1.09%.

כמה דברים חשובים ש-.NET MAUI 10 שינה מבחינת ביצועים:

• Native AOT לאנדרויד — צמצום גודל ה-APK בכ-35% וזמן הפעלה מהיר יותר בכ-40%. זה לא טוויק קטן, זה שיפור מטורף.
• Handlers מיועלים — זמן יצירת רכיבי UI הצטמצם משמעותית בהשוואה ל-MAUI 8.
• CollectionView משופר — גלילה חלקה יותר עם תמיכה טובה ב-IncrementalItemsSource.
• שיפורי GC — שיטות חדשות לניהול זיכרון שמיועדות ספציפית לפלטפורמות מובייל.

חלק 1: קיצור זמן ההפעלה של האפליקציה

זמן הפעלה קר (Cold Start) הוא הזמן שעובר מרגע הלחיצה על האייקון ועד שהאפליקציה מוכנה לאינטראקציה. לפי מיקרוסופט, היעד הוא מתחת ל-2 שניות במכשירים ברמת ביניים. בפועל? תמיד צריך לכוון ליותר, כי בכל זאת — המשתמש לא מסתכל על תיעוד Microsoft כשהוא ממתין.

1.1 הפעלת Native AOT Compilation

אחד מהשיפורים הבולטים בגרסה 10 הוא תמיכה מלאה ב-Native AOT גם ב-Android וגם ב-iOS. פתחו את קובץ ה-.csproj והוסיפו את זה:

<PropertyGroup Condition="'$(Configuration)' == 'Release'">
    <PublishAot>true</PublishAot>
    <RunAOTCompilation>true</RunAOTCompilation>
    <OptimizationPreference>Speed</OptimizationPreference>
    <TrimMode>full</TrimMode>
    <EnableTrimAnalyzer>true</EnableTrimAnalyzer>
</PropertyGroup>

אזהרה מניסיון אישי: אחרי שמפעילים את זה, חובה לוודא שה-Dependencies שלכם תואמים ל-Trimming. ספריות שמשתמשות ב-Reflection כבד (תכירו — גרסאות ישנות של Newtonsoft.Json) ישברו לכם את האפליקציה. איבדתי ערב שלם על זה פעם אחת. מומלץ לעבור ל-System.Text.Json עם Source Generators:

[JsonSerializable(typeof(Product))]
[JsonSerializable(typeof(List<Product>))]
public partial class AppJsonContext : JsonSerializerContext { }

// בשימוש:
var products = JsonSerializer.Deserialize(json, AppJsonContext.Default.ListProduct);

1.2 דחייה של אתחול שירותים

טעות ממש נפוצה: לאתחל את כל השירותים ב-MauiProgram.cs בצורה סינכרונית. זה פשוט רע לזמן הפעלה. השתמשו ב-Lazy<T> כדי לדחות אתחול של שירותים כבדים עד לשימוש הראשון:

public static MauiApp CreateMauiApp()
{
    var builder = MauiApp.CreateBuilder();
    builder
        .UseMauiApp<App>()
        .ConfigureFonts(fonts =>
        {
            fonts.AddFont("OpenSans-Regular.ttf", "OpenSansRegular");
        });

    // אתחול מיידי - שירותים קריטיים בלבד
    builder.Services.AddSingleton<IAuthService, AuthService>();

    // אתחול עצל - שירותים כבדים
    builder.Services.AddSingleton<Lazy<IAnalyticsService>>(sp =>
        new Lazy<IAnalyticsService>(() => new AnalyticsService()));

    builder.Services.AddTransient<MainPage>();
    builder.Services.AddTransient<MainViewModel>();

    return builder.Build();
}

1.3 אופטימיזציה של Splash Screen

עוד משהו קטן אבל משמעותי: השתמשו ב-Splash Screen מובנה של הפלטפורמה, לא ב-Splash Screen מבוסס XAML. ההגדרה פשוטה:

<ItemGroup>
    <MauiSplashScreen Include="Resources\Splash\splash.svg"
                      Color="#512BD4"
                      BaseSize="128,128" />
</ItemGroup>

המערכת תיצור Splash Screen נייטיבי שמוצג מיידית, עוד לפני שמנוע ה-.NET בכלל נטען. זה הבדל ויזואלי ענק שגורם לאפליקציה להרגיש הרבה יותר מהירה, גם אם בפועל זמן ה-Startup לא השתנה דרמטית.

1.4 מדידת זמן הפעלה בפועל

אל תנחשו — מדדו. ב-Android, הנה הפקודה שאני מריץ כמעט בכל פרויקט:

adb shell am start -W -n com.yourcompany.yourapp/crc64xxxxxx.MainActivity

הפקודה מחזירה שלושה ערכים חשובים: ThisTime, TotalTime ו-WaitTime. היעד שלי אישית: TotalTime מתחת ל-1500ms במכשיר Pixel 6a או שווה ערך. אם אתם מעל 2000ms, יש פה משהו לתקן.

חלק 2: אופטימיזציה של CollectionView

אוקיי, מגיעים לחלק הכי כואב. CollectionView הוא אחד הרכיבים הפופולריים והבעייתיים ביותר מבחינת ביצועים. גלילה מקוטעת ברשימות ארוכות היא התלונה מספר אחת שאני שומע מצוותים שעוברים ל-MAUI. החדשות הטובות? ב-99% מהמקרים ניתן לפתור אותה. החדשות הפחות טובות? זה דורש עבודה.

2.1 שימוש נכון ב-ItemsUpdatingScrollMode

כשמוסיפים פריטים חדשים לרשימה, ברירת המחדל היא לשמור על מיקום הגלילה הנוכחי. זה לא תמיד מה שתרצו — לרשימות אינסופיות (Feed, Chat וכו') עדיף להגדיר:

<CollectionView ItemsSource="{Binding Items}"
                ItemsUpdatingScrollMode="KeepItemsInView"
                RemainingItemsThreshold="5"
                RemainingItemsThresholdReached="OnLoadMore">
    <CollectionView.ItemTemplate>
        <DataTemplate x:DataType="models:Product">
            <Grid Padding="10">
                <Label Text="{Binding Name}" />
            </Grid>
        </DataTemplate>
    </CollectionView.ItemTemplate>
</CollectionView>

שימו לב ל-x:DataType — זה מה שמפעיל Compiled Bindings, שהן פי 8 עד 20 מהירות יותר מ-Bindings רגילים. אם אתם לא משתמשים בזה, אתם פשוט משאירים ביצועים על הרצפה.

2.2 Virtualization נכון

CollectionView אמנם משתמש ב-Virtualization כברירת מחדל, אבל זה עוזר רק אם ה-ItemTemplate שלכם פשוט. הימנעו מ:

• Nested Layouts מיותרים — במקום StackLayout בתוך Grid, השתמשו רק ב-Grid אחד. באמת.
• Converters כבדים — אם יש לכם Converter שרץ על כל פריט, העבירו את הלוגיקה ל-ViewModel. זה שיעור שלמדתי בדרך הקשה.
• Images ללא קאש — השתמשו ב-CachingEnabled ו-CacheValidity. תמיד.

דוגמה ל-ItemTemplate שעובד טוב אצלי:

<DataTemplate x:DataType="models:Product">
    <Grid ColumnDefinitions="60, *, Auto"
          Padding="12"
          RowSpacing="0">
        <Image Grid.Column="0"
               Source="{Binding ImageUrl}"
               Aspect="AspectFill"
               HeightRequest="60"
               WidthRequest="60">
            <Image.Behaviors>
                <mct:UriImageSourceBehavior
                    CacheValidity="7.0:0:0:0" />
            </Image.Behaviors>
        </Image>
        <Label Grid.Column="1"
               Text="{Binding Name}"
               VerticalOptions="Center" />
        <Label Grid.Column="2"
               Text="{Binding Price, StringFormat='₪{0:F2}'}"
               VerticalOptions="Center" />
    </Grid>
</DataTemplate>

2.3 Incremental Loading לרשימות גדולות

טעינת 10,000 פריטים בבת אחת היא פשוט לא אופציה (ואם אתם עושים את זה, הלקוחות שלכם לא יודו לכם). השתמשו ב-IncrementalItemsSource או ב-ObservableRangeCollection מ-CommunityToolkit.Mvvm:

public partial class ProductsViewModel : ObservableObject
{
    [ObservableProperty]
    private ObservableRangeCollection<Product> items = new();

    private int _currentPage = 0;
    private const int PageSize = 20;
    private bool _isLoading;

    [RelayCommand]
    private async Task LoadMoreAsync()
    {
        if (_isLoading) return;
        _isLoading = true;

        try
        {
            var newItems = await _productService
                .GetProductsAsync(_currentPage, PageSize);

            if (newItems.Count > 0)
            {
                Items.AddRange(newItems);
                _currentPage++;
            }
        }
        finally
        {
            _isLoading = false;
        }
    }
}

הנקודה החשובה פה: AddRange במקום Add בלולאה. זה חוסך פעולות ריענון UI מרובות ומשפר משמעותית את הביצועים בעת טעינת כמויות גדולות של נתונים. הבדל של פי 5 ביישום אמיתי אצלי.

חלק 3: ניהול זיכרון ומניעת דליפות

דליפות זיכרון הן הבעיה הערמומית ביותר בפיתוח מובייל. הן לא גורמות לקריסה מיידית — הן רק גורמות לאפליקציה להאט עם הזמן ובסוף להיסגר בשקט על ידי מערכת ההפעלה. ואז המשתמש מאשים אתכם.

3.1 שחרור מנויי Events

זה הגורם מספר אחת לדליפות ב-.NET MAUI: מנויים ל-events שלא משתחררים. כש-View נסגר, ה-ViewModel שלו עלול להישאר בזיכרון אם יש לו אירועים מחוברים. התבנית הבטוחה:

public partial class ProductsPage : ContentPage
{
    public ProductsPage(ProductsViewModel vm)
    {
        InitializeComponent();
        BindingContext = vm;
    }

    protected override void OnAppearing()
    {
        base.OnAppearing();
        if (BindingContext is ProductsViewModel vm)
        {
            vm.ProductAdded += OnProductAdded;
        }
    }

    protected override void OnDisappearing()
    {
        base.OnDisappearing();
        if (BindingContext is ProductsViewModel vm)
        {
            // קריטי: ניתוק האירוע
            vm.ProductAdded -= OnProductAdded;
        }
    }

    private void OnProductAdded(object sender, Product e)
    {
        // טיפול באירוע
    }
}

3.2 שימוש ב-WeakReferenceMessenger

אם אתם משתמשים ב-CommunityToolkit.Mvvm (ואתם צריכים), WeakReferenceMessenger הוא החבר הכי טוב שלכם. הוא מאפשר תקשורת בין ViewModels בלי ליצור הפניות חזקות שמונעות Garbage Collection:

// שליחת הודעה
WeakReferenceMessenger.Default.Send(new ProductAddedMessage(product));

// רישום (אוטומטי ישוחרר עם ה-GC)
public partial class CartViewModel : ObservableObject,
    IRecipient<ProductAddedMessage>
{
    public CartViewModel()
    {
        WeakReferenceMessenger.Default.Register(this);
    }

    public void Receive(ProductAddedMessage message)
    {
        // טיפול בהודעה
    }
}

3.3 זיהוי דליפות עם dotnet-gcdump

הכלי dotnet-gcdump מאפשר לצלם מצב של ה-heap בזמן ריצה ולזהות דליפות. התקנה והרצה:

dotnet tool install -g dotnet-gcdump
dotnet-gcdump collect -p <process_id>

פתחו את הקובץ שנוצר ב-Visual Studio או ב-PerfView, וחפשו אובייקטים מסוג ContentPage או ViewModel שלא אמורים עדיין להיות בזיכרון. אם יש יותר מ-instance אחד של הדף הפעיל — ברוכים הבאים למועדון דולפי הזיכרון.

3.4 Bitmap Caching חכם

תמונות הן הגורם המרכזי לצריכת זיכרון ברוב האפליקציות. וודאו שאתם טוענים רק את הרזולוציה שאתם באמת מציגים:

<Image Source="{Binding ThumbnailUrl}"
       HeightRequest="80"
       WidthRequest="80"
       Aspect="AspectFill" />

אם ה-URL מחזיר תמונה ב-2048x2048 פיקסלים אבל אתם מציגים 80x80 — האפליקציה עדיין תטען את כל הסכום הזה לזיכרון. השתמשו ב-CDN שתומך ב-resizing דינמי (Cloudinary, ImageKit, או Bunny CDN) והעבירו פרמטרים של גודל ב-URL. הבדל ענק, אני מבטיח.

חלק 4: טכניקות מתקדמות ל-2026

4.1 Compiled Bindings בכל מקום

הוסיפו ל-.csproj את ההגדרה הבאה שתאכוף Compiled Bindings בכל המקומות:

<PropertyGroup>
    <MauiEnableXamlCBindingWithSourceCompilation>true</MauiEnableXamlCBindingWithSourceCompilation>
</PropertyGroup>

זה יגרום לקומפיילר להזהיר בכל מקום שבו x:DataType חסר. כן, תראו המון אזהרות בהתחלה — אבל זה שווה את זה. בסוף כל ה-Bindings יהיו מקומפלים ומהירים.

4.2 Handler Pooling

תוספת מהגרסה החדשה: Handler Pooling. בקיצור, במקום ליצור Native Views מחדש בכל פעם, אפשר לעשות שימוש חוזר בהם. זה משפר ביצועים משמעותית ברשימות עם פריטים מורכבים. זה מורגש במיוחד בגלילה ארוכה.

4.3 SkiaSharp עבור UI מורכב

אם אתם צריכים לרנדר אלפי אלמנטים (גרפים מורכבים, אפליקציית ציור, ויז'ואליזציות), תשכחו מ-Shapes של MAUI. השתמשו ב-SKCanvasView מ-SkiaSharp. ההבדל בביצועים יכול להגיע לפי 50 ברנדור כבד. זה לא הגזמה.

שאלות נפוצות

כמה זמן הפעלה סביר באפליקציית .NET MAUI?

היעד המומלץ הוא פחות מ-2 שניות בהפעלה קרה במכשיר ברמת ביניים (כמו Pixel 6a או iPhone 12). עם AOT Compilation מופעל ואופטימיזציות נכונות, ניתן להגיע אפילו ל-1.2 שניות. מעל 3 שניות? זה נחשב בעייתי ומצריך אופטימיזציה דחופה.

האם Native AOT יציב בפרודקשן ב-.NET MAUI 10?

כן. בגרסה 10 התמיכה ב-Native AOT הגיעה לרמת GA (Generally Available) עבור Android ו-iOS. עם זאת, חשוב לבדוק שכל הספריות שלכם תומכות ב-Trimming. הנפוצות (CommunityToolkit.Mvvm, EF Core, SQLite-net) תומכות במלואן. ספריות ישנות שמבוססות על Reflection עלולות לדרוש עדכון — או החלפה מוחלטת.

מה ההבדל בין CollectionView ל-CarouselView מבחינת ביצועים?

שניהם משתמשים ב-Virtualization, אבל CarouselView טוען כברירת מחדל 3 פריטים (הנוכחי ושני הסמוכים), בעוד CollectionView טוען רק מה שנראה על המסך. אז עבור רשימות ארוכות — CollectionView תמיד עדיף. השתמשו ב-CarouselView רק כשבאמת נדרש swipe בין פריטים מלאי-מסך.

איך מזהים דליפת זיכרון באפליקציית MAUI?

הבדיקה שאני עושה: נווטו לדף, צאו ממנו, חיזרו אליו — ושוב, עשר פעמים. אם צריכת הזיכרון רק עולה ולא חוזרת לערך ההתחלתי אחרי GC, יש לכם דליפה. אחרי זה השתמשו ב-dotnet-gcdump או ב-Visual Studio Memory Profiler כדי לזהות אילו אובייקטים תקועים בזיכרון.

האם כדאי להעביר את האפליקציה מ-Xamarin.Forms ל-.NET MAUI 10 בגלל ביצועים?

בקיצור: בהחלט כן. Xamarin.Forms הגיע לסוף חייו במאי 2024, ו-.NET MAUI 10 מציע ביצועים טובים משמעותית — זמן הפעלה קצר ב-40%, צריכת זיכרון נמוכה ב-25% ותמיכה ב-AOT. וחוץ מזה, רק .NET MAUI מקבל עדכוני אבטחה ותכונות חדשות. אם האפליקציה שלכם עדיין ב-Xamarin — אל תדחו את המעבר יותר.

סיכום

אופטימיזציית ביצועים ב-.NET MAUI 10 היא לא פעולה חד-פעמית. זה תהליך מתמשך שדורש מדידה, זיהוי צווארי בקבוק ושיפור הדרגתי. המלצה שלי: התחילו מהפעלת AOT Compilation, עברו ל-Compiled Bindings בכל ה-XAML, אופטימזו את ה-CollectionView עם templates פשוטים ככל האפשר, ואמצו את WeakReferenceMessenger למניעת דליפות.

דבר אחרון — אפליקציה מהירה היא לא פריבילגיה. היא פשוט דרישה בסיסית לשרידות בחנויות האפליקציות של 2026. השקיעו את הזמן באופטימיזציה עכשיו, והמשתמשים יתגמלו אתכם בדירוגים טובים יותר ושימוש ממושך יותר. זה באמת משתלם.