Gambaran Keseluruhan .NET di Unity

Unity menggunakan open-source. Platform NET untuk memastikan bahwa aplikasi yang Anda buat dengan Unity dapat berjalan pada berbagai konfigurasi perangkat keras yang berbeda. Platform .NET mendukung berbagai bahasa dan perpustakaan API.

Scripting backends

Unity memiliki dua backend scripting; Mono, dan IL2CPPBack-end scripting bersatu yang dapat Anda gunakan sebagai alternatif untuk Mono ketika proyek bangunan untuk beberapa platform. More info
Lihat di Glossary (Interte Language To C++), masing-masing yang menggunakan teknik kompilasi yang berbeda:

• Mono menggunakan hanya-in-time (JIT) kompilasi dan menyusun kode pada permintaan pada runtime.
• IL2CPP menggunakan kompilasi maju-of-time (AOT) dan menyusun seluruh aplikasi Anda sebelum berjalan.

Manfaat menggunakan backend scripting berbasis JIT adalah waktu kompilasi biasanya jauh lebih cepat daripada AOT.

Secara default, Unity menggunakan backend Mono pada platform yang mendukung Mono. Ketika Anda membangun pemain untuk aplikasi Anda, Anda dapat memilih yang scripting backend untuk digunakan. Untuk melakukan ini melalui Editor, pergi ke Edit > Project Settings > Player, buka panel Other Settings, kemudian klik pada dropdown Scripting Backend dan pilih yang backend yang Anda inginkan. Untuk informasi lebih lanjut, lihat Scripting backendsKerangka kerja yang skrip di Unity. Unity mendukung tiga backend scripting yang berbeda tergantung pada platform target: Mono, .NET dan IL2CPP. Platform Windows Universal, namun hanya mendukung dua: .NET dan IL2CPP. More info
Lihat di Glossary.

Dikelola kode pengupasan

Ketika Anda membangun aplikasi, kompilator Unity dan kemudian mencari rakitan (.DLLs) dalam proyek Anda untuk mendeteksi dan menghapus kode yang tidak digunakan. Proses pengupasan kode ini mengurangi ukuran biner akhir dari build Anda, tetapi meningkatkan waktu build.

Pengupasan kode dinonaktifkan secara default ketika Anda menggunakan mono tetapi pengupasan kode tidak dapat dinonaktifkan untuk IL2CPP. Anda dapat mengontrol berapa banyak strip Unity kode dengan properti Managed Stripping Level.

Untuk mengubah properti ini, pergi ke Edit > Project Settings > Player, buka panel Other Settings, kemudian klik pada dropdown Managed Stripping Level dan pilih tingkat pengupasan.

Ketika Anda meningkatkan Managed Stripping Level, Unity menghapus lebih banyak kode. Ini meningkatkan risiko bahwa Unity mungkin menghapus kode yang aplikasi Anda bergantung pada, terutama jika Anda menggunakan refleksi atau menghasilkan kode pada runtime.

Anda dapat menggunakan anotasi pada elemen tertentu dari kode Anda untuk mencegah Unity dari pengupasan itu. Untuk informasi lebih lanjut, lihat Dikelola Kode Stripping.

Photogallery

Unity menggunakan Pengumpul sampah Boehm untuk backend Mono dan IL2CPP. Unity menggunakan mode Incremental secara default. Anda dapat menonaktifkan mode Incremental untuk menggunakan koleksi garbage stop-the-world, meskipun Unity merekomendasikan mode Incremental.

Untuk beralih antara mode Incremental dan stop-the-world, pergi ke Edit > Project Settings > Player, buka panel Other Settings dan klik pada kotak centang Use incremental GC. Dalam mode Incremental, kolektor sampah Unity hanya berjalan untuk jangka waktu terbatas dan tidak selalu mengumpulkan semua objek dalam satu umpan. Ini menyebar waktu yang dibutuhkan untuk mengumpulkan benda di beberapa bingkai dan mengurangi lonjakan dan lonjakan CPU. Untuk informasi lebih lanjut, lihat Memori terkelola.

Untuk memeriksa jumlah alokasi dan kemungkinan lonjakan CPU dalam aplikasi Anda, gunakan Profiler Unity. Anda juga dapat menggunakan API GarbageCollector untuk koleksi garbage yang dapat dinonaktifkan di Pemain. Ketika kolektor dinonaktifkan, berhati-hati untuk menghindari mengalokasikan memori berlebih.

Sitemap Sistem NET

Unity mendukung banyak platform dan mungkin menggunakan backend scripting yang berbeda tergantung pada platform. Perpustakaan sistem NET memerlukan implementasi spesifik platform untuk bekerja dengan benar dalam beberapa kasus. Sementara Unity mencoba yang terbaik untuk mendukung sebanyak . ekosistem NET mungkin, ada beberapa pengecualian untuk bagian dari . NET sistem perpustakaan yang Unity eksplisit tidak mendukung.

Unity tidak membuat jaminan kinerja atau alokasi untuk . Perpustakaan sistem NET di versi Unity. Umumnya, Unity tidak memperbaiki regresi kinerja di . Perpustakaan sistem NET.

Unity tidak mendukung sistem. Menggambar perpustakaan dan tidak dijamin untuk bekerja di semua platform.

kompilasi JIT bahwa backend mono skrip memungkinkan Anda untuk memancarkan C # / dinamis. NET Intermediate Language (IL) generasi kode selama runtime aplikasi Anda. AOT compilationAhead of Time (AOT) kompilasi adalah metode optimasi yang digunakan oleh semua platform kecuali iOS untuk mengoptimalkan ukuran pemain yang dibangun. . More info
Lihat di Glossary yang digunakan backend IL2CPP tidak mendukung generasi kode dinamis.

Hal ini penting untuk dipertimbangkan ketika Anda menggunakan perpustakaan pihak ketiga, karena mereka mungkin memiliki jalur kode yang berbeda untuk JIT dan AOT, atau mereka mungkin menggunakan jalur kode yang bergantung pada kode yang dihasilkan secara dinamis. Untuk informasi lebih lanjut tentang cara menghasilkan kode pada runtime, lihat dokumentasi ModuleBuilder Microsoft.

Meskipun Unity mendukung beberapa. Profil API NET, Anda harus menggunakan . NET Standard Tingkat Kompatibilitas API untuk semua proyek baru untuk alasan berikut:

• Login Standar adalah permukaan API yang lebih kecil dan memiliki implementasi yang lebih kecil. Ini mengurangi ukuran file executable akhir Anda.
• Sitemap Login Standar memiliki dukungan lintas platform yang lebih baik, sehingga kode Anda lebih cenderung bekerja di semua platform.
• Sitemap Dukungan runtimes NET Standar, sehingga kode Anda bekerja di lingkungan VM / runtime lebih (misalnya, .NET Framework. .NET Core, Xamarin, Unity) ketika Anda menggunakan . Standar NET.
• Sitemap Login Standar memindahkan lebih banyak kesalahan untuk menyusun waktu. Sejumlah API dalam .NET Framework tersedia pada waktu kompilasi, tetapi memiliki implementasi pada beberapa platform yang melempar pengecualian pada runtime.

Profil lain dapat berguna jika, misalnya, Anda perlu memberikan dukungan untuk aplikasi yang lebih lama. Untuk mengubah pengaturan Api Compatibility Level, pergi ke Edit > Project Settings > Player. Di bawah judul Other Settings, set Api Compatibility Level ke pengaturan yang diinginkan.

Untuk informasi lebih lanjut, lihat Sitemap NET Profil.

Menggunakan pihak ketiga. Login

Anda hanya boleh menggunakan pihak ketiga. NET perpustakaan yang telah diuji secara luas pada berbagai konfigurasi Unity dan platform.

Karakteristik kinerja jalur kode JIT dan AOT di perpustakaan pihak ketiga mungkin berbeda secara signifikan. AOT umumnya mengurangi waktu startup dan cocok untuk aplikasi yang lebih besar untuk alasan ini tetapi meningkatkan ukuran file biner untuk mengakomodasi kode yang disusun. AOT juga memakan waktu lebih lama untuk membangun selama pembangunan.

JIT menyesuaikan pada runtime berdasarkan platform yang berjalan, yang dapat meningkatkan kinerja berjalan dengan biaya waktu startup aplikasi yang lebih lama. Seperti itu, Anda harus menprofilkan aplikasi Anda di kedua Editor, dan di platform target Anda. Untuk informasi lebih lanjut, lihat Profiler.

Anda harus profil penggunaan Anda. Perpustakaan sistem NET pada semua platform target karena karakteristik kinerja mereka mungkin bervariasi tergantung pada backend scripting, versi .NET, dan profil yang Anda gunakan.

Ketika Anda meninjau perpustakaan pihak ketiga, pertimbangkan daerah berikut:

• Kompatibilitas: Perpustakaan pihak ketiga mungkin tidak kompatibel dengan beberapa platform Unity dan backend scripting.
• Kinerja: Perpustakaan pihak ketiga mungkin memiliki karakteristik kinerja yang sangat berbeda dalam Unity dibandingkan dengan . NET runtimes.
• Ukuran biner AOT: Perpustakaan pihak ketiga dapat meningkatkan ukuran biner AOT secara signifikan karena jumlah ketergantungan penggunaan perpustakaan.

C# reflektor

Mono dan IL2CPP cache internal semua objek C # refleksi (Sistem.Reflection) dan dengan desain, Unity tidak mengumpulkannya. Hasil perilaku ini adalah bahwa kolektor sampah terus memindai objek refleksi C# yang tersimpan selama masa pakai aplikasi Anda, yang menyebabkan pengumpul sampah yang tidak perlu dan berpotensi signifikan.

Untuk meminimalkan overhead pengumpul sampah, hindari metode seperti Login Login dan Type.GetMethods() dalam aplikasi Anda, yang menciptakan banyak benda refleksi C# pada saat runtime. Sebagai gantinya, Anda harus memindai perakitan di Editor untuk data yang diperlukan dan serialisasi dan/atau codegen untuk digunakan pada runtime.

Login Objek perilaku khusus

Login Sitemap adalah tipe khusus dari objek C# dalam Unity, karena itu terkait dengan objek rekan C++ asli. Misalnya, ketika Anda menggunakan komponen KameraKomponen yang menciptakan gambar sudut pandang tertentu di tempat kejadian Anda. Output ditarik ke layar atau ditangkap sebagai tekstur. More info
Lihat di Glossary, Unity menyimpan keadaan objek pada rekan C++ asli objek, bukan pada objek C# itu sendiri.

Unity tidak saat ini mendukung penggunaan kelas C# WeakReference dengan instance UnityEngine. Sitemap Untuk alasan ini, Anda tidak boleh menggunakan WeakReference untuk merujuk aset yang dimuat. Lihat Dokumentasi WeakReference Microsoft untuk informasi lebih lanjut tentang kelas WeakReference.

Unity C# dan Unity C++ berbagi Objek UnityEngine

Ketika Anda menggunakan metode seperti Sitemap Login atau Object.DestroyImmediate untuk menghancurkan UnityEngine. Objek yang berasal, Unity menghancurkan (tidak beban) objek counter asli. Anda tidak dapat menghancurkan objek C# dengan panggilan eksplisit, karena kolektor sampah mengelola memori. Setelah tidak lagi referensi ke objek yang dikelola, pengumpul sampah mengumpulkan dan menghancurkannya.

Jika aplikasi Anda mencoba mengakses UnityEngine yang hancur. Sitemap Unity menciptakan kembali objek rekan asli untuk sebagian besar jenis. Dua pengecualian perilaku rekreasi ini adalah MonoBehaviour dan Login Sitemap: Unity tidak pernah mengisi ulang mereka setelah mereka telah hancur.

MonoBehaviour dan Scriptable Objek menimpa equality (==) dan inequality (!=) operator. Jika Anda membandingkan MonoBehaviour atau ScriptableObject terhadap null, operator kembali benar ketika objek yang berhasil masih ada dan belum mengumpulkan sampah.

Karena Anda tidak dapat membebani dan ?. operator, mereka tidak kompatibel dengan objek yang berasal dari UnityEngine. Sitemap Operator tidak mengembalikan hasil yang sama dengan operator yang berkualitas dan berkualitas ketika Anda menggunakannya pada MonoBehaviour atau ScriptableObject sementara objek yang berhasil masih ada.

Batasan tugas async dan menunggu

The Unity API bukan benang yang aman dan oleh karena itu, Anda hanya boleh menggunakan async dan menanti tugas dari dalam UnitySynchronizationContext. Async tugas sering mengalokasikan objek ketika divoked, yang mungkin menyebabkan masalah kinerja jika Anda terlalu menggunakannya.

Unity menimpa default SinkronisasiContext dengan UnitySynchronizationContext kustom dan menjalankan semua tugas pada benang utama dalam mode Edit dan Play secara default. Untuk menggunakan tugas sinkronisasi, Anda harus secara manual membuat dan menangani benang Anda sendiri dengan API Login Login, dan gunakan Sinkronisasi defaultContext bukan versi Unity.

Unity tidak secara otomatis menghentikan tugas sinkronisasi yang berjalan pada benang yang dikelola ketika Anda keluar Mode Play. Untuk mendengarkan masuk dan keluar Mainkan peristiwa mode untuk menghentikan tugas secara manual, gunakan WordPress.org. Jika Anda mengambil pendekatan ini, sebagian besar API skrip Unity tidak tersedia untuk digunakan kecuali Anda meniru konteks kembali ke UnitySynchronizationContext.

Pada development buildsMembangun pengembangan termasuk simbol debug dan memungkinkan Profiler. More info
Lihat di Glossary, Unity menampilkan pesan kesalahan berikut jika Anda mencoba menggunakan API Unity dalam kode multithreaded:

UnityException: Internal_CreateGameObject can only be called from the main thread. \

Constructors and field initializers will be executed from the loading thread when loading a scene. \

Don't use this function in the constructor or field initializers, instead move initialization code to the Awake or Start function.

Untuk alasan kinerja, Unity tidak melakukan pemeriksaan untuk perilaku multithreaded dalam build non-development dan tidak menampilkan kesalahan ini dalam membangun hidup. Ini berarti bahwa sementara Unity tidak mencegah pelaksanaan multithreaded kode pada membangun langsung, kecelakaan acak dan kesalahan yang tidak dapat diprediksi lainnya kemungkinan jika Anda menggunakan beberapa benang. Untuk alasan ini, Unity menyarankan Anda tidak menggunakan multithreading.

Untuk mengambil keuntungan dari manfaat multithreading dengan aman, gunakan Sistem Pekerjaan C#. Sistem Kerja menggunakan beberapa benang dengan aman untuk mengeksekusi pekerjaan secara paralel dan mencapai manfaat kinerja multithreading. Untuk informasi lebih lanjut, lihat [Apa yang dimaksud?.