Windows Çalışma Zamanı Bileşenleri ve birlikte çalışmayı optimize etme

Birlikte çalışma performansı sorunlarını önlerken, Windows Çalışma Zamanı Bileşenlerini kullanan ve yerel ve yönetilen türler arasında birlikte çalışma sağlayan Windows uygulamaları oluşturun.

Windows Çalışma Zamanı Bileşenleriyle birlikte çalışabilirlik için en iyi yöntemler

Dikkatli değilseniz, Windows Çalışma Zamanı Bileşenlerinin kullanılması uygulama performansınızı büyük ölçüde etkileyebilir. Bu bölümde, uygulamanız Windows Çalışma Zamanı Bileşenleri'ni kullandığında iyi performans elde etme işlemleri açıklanmaktadır.

Giriş

Birlikte çalışabilirlik, performans üzerinde büyük bir etkiye sahip olabilir ve bunu farkında bile olmadan kullanıyor olabilirsiniz. Windows Çalışma Zamanı, daha üretken olabilmeniz ve diğer dillerde yazılmış kodu yeniden kullanabilmeniz için birlikte çalışabilirliğin çoğunu sizin için işler. Windows Çalışma Zamanı'nın sizin için yaptıklarından yararlanmanızı öneririz, ancak bunun performansı etkileyeebileceğini unutmayın. Bu bölümde, birlikte çalışabilirliğin uygulamanızın performansı üzerindeki etkisini azaltacak yapabilecekleriniz açıklanmıştır.

Windows Çalışma Zamanı,Evrensel Windows Platformu uygulaması yazabilen herhangi bir dilden erişilebilen bir tür kitaplığına sahiptir. Windows Çalışma Zamanı türlerini C# veya Microsoft Visual Basic'te .NET nesnelerini kullandığınız gibi kullanırsınız. Windows Çalışma Zamanı bileşenlerine erişmek için platform çağırma yöntemi çağrıları yapmanız gerekmez. Bu, uygulamalarınızı yazmayı çok daha az karmaşık hale getirir, ancak beklediğinizden daha fazla birlikte çalışabilirlik olabileceğini fark etmek önemlidir. Windows Çalışma Zamanı bileşeni C# veya Visual Basic dışında bir dilde yazılmışsa, bu bileşeni kullandığınızda birlikte çalışabilirlik sınırlarını aşmış olursunuz. Birlikte çalışabilirlik sınırlarını aşmak bir uygulamanın performansını etkileyebilir.

C# veya Visual Basic'te Evrensel Windows Platformu uygulaması geliştirirken, kullandığınız en yaygın iki API, Windows Çalışma Zamanı API'leri ve UWP uygulamaları için .NET API'leridir. Genel olarak, Windows Çalışma Zamanı üzerinde oluşturulan ve "Windows." ile başlayan ad alanlarına sahip türler ile .NET türleri, "System." ile başlayan ad alanlarındadır. Ancak bazı istisnalar vardır. UWP uygulamaları için .NET'teki türler kullanıldığında birlikte çalışabilirlik gerektirmez. Daha sonra Windows Çalışma Zamanı kullanan bir alanda kötü performansa sahip olduğunuzu fark ederseniz, daha iyi performans elde etmek için UWP uygulamaları için .NET kullanabilirsiniz.

Not Windows 10 ile birlikte gelen Windows Çalışma Zamanı bileşenlerinin çoğu C++ dilinde uygulanır, bu nedenle C# veya Visual Basic'ten kullanırken birlikte çalışabilirlik sınırlarını geçersiniz. Her zaman olduğu gibi, kodunuzda değişiklik yapmaya yatırım yapmadan önce Windows Çalışma Zamanı bileşenlerini kullanmanın uygulamanızın performansını etkileyip etkilemediğini görmek için uygulamanızı ölçtünüzden emin olun.

Bu konu başlığında "Windows Çalışma Zamanı bileşenleri" dendiğinde, C# veya Visual Basic dışında bir dilde yazılmış Windows Çalışma Zamanı Bileşenleri anlamına gelir.

 

Windows Çalışma Zamanı bileşeninde bir özelliğe her eriştiğinizde veya bir yöntem çağırdığınızda birlikte çalışabilirlik maliyeti tahakkuk eder. Aslında, Bir Windows Çalışma Zamanı bileşeni oluşturmak bir .NET nesnesi oluşturmaktan daha maliyetlidir. Bunun nedenleri, Windows Çalışma Zamanı'nın uygulamanızın dilinden bileşenin diline geçiş kodu yürütmesi gerekir. Ayrıca, verileri bileşene geçirirseniz, verilerin yönetilen ve yönetilmeyen türler arasında dönüştürülmesi gerekir.

Windows Çalışma Zamanı Bileşenlerini verimli bir şekilde kullanma

Daha iyi performans elde etmeniz gerektiğini fark ederseniz, kodunuzun Windows Çalışma Zamanı bileşenlerini mümkün olduğunca verimli bir şekilde kullandığına emin olabilirsiniz. Bu bölümde, Windows Çalışma Zamanı bileşenlerini kullanırken performansı geliştirmeye yönelik bazı ipuçları açıklanmaktadır.

Performansın etkisinin fark edilebilir olması için kısa bir süre içinde önemli sayıda çağrı gerekir. İş mantığından ve diğer yönetilen kodlardan Windows Çalışma Zamanı bileşenlerine yapılan çağrıları kapsülleyen iyi tasarlanmış bir uygulama, çok büyük birlikte çalışabilirlik maliyetleri doğurmamalıdır. Ancak testleriniz Windows Çalışma Zamanı bileşenlerini kullanmanın uygulamanızın performansını etkilediğini gösteriyorsa, bu bölümde açıklanan ipuçları performansı geliştirmenize yardımcı olur.

UWP uygulamaları için .NET tarafından sağlanan türleri kullanmayı göz önünde bulundurun

Bir görevi Windows Çalışma Zamanı türünü veya UWP uygulamaları için .NET tarafından sağlanan bir türü kullanarak gerçekleştirebileceğiniz bazı durumlar vardır. .NET türleriyle Windows Çalışma Zamanı türlerini karıştırmamaya çalışmak iyi bir fikirdir. Bir veya diğerinde kalmaya çalışın. Örneğin, Windows.Data.Xml.Dom.XmlDocument türünü (Windows Çalışma Zamanı türü) veya System.Xml.XmlReader türünü (.NET türü) kullanarak xml akışını ayrıştırabilirsiniz. Akışla aynı teknolojiye sahip API'yi kullanın. Örneğin, bir MemoryStream'den xml okursanız, her iki tür de .NET türü olduğundan System.Xml.XmlReader türünü kullanın. Bir dosyadan okuma yapıyorsanız, dosya API'leri ve XmlDocument, yerel Windows Çalışma Zamanı bileşenlerinde uygulandıkları için Windows.Data.Xml.Dom.XmlDocument türünü kullanın.

Pencere Çalışma Zamanı nesnelerini .NET türlerine kopyalama

Bir Windows Çalışma Zamanı bileşeni bir Windows Çalışma Zamanı nesnesi döndürdüğünde, döndürülen nesneyi bir .NET nesnesine kopyalamak yararlı olabilir. Bunun özellikle önemli olduğu iki yer, koleksiyonlar ve akışlarla çalıştığınız durumlardır.

Bir koleksiyon döndüren bir Windows Çalışma Zamanı API'sini çağırır ve sonra bu koleksiyonu birçok kez kaydedip erişirseniz, koleksiyonu bir .NET koleksiyonuna kopyalamak ve o tarihten sonra .NET sürümünü kullanmak yararlı olabilir.

Daha sonra kullanmak üzere Windows Çalışma Zamanı bileşenlerine yapılan çağrıların sonuçlarını önbelleğe alma

Bir Windows Çalışma Zamanı türüne birden çok kez erişmek yerine değerleri yerel değişkenlere kaydederek daha iyi performans elde edebilirsiniz. Bir döngünün içinde bir değer kullanıyorsanız bu özellikle yararlı olabilir. Yerel değişkenleri kullanmanın uygulamanızın performansını geliştirip geliştirmediğini görmek için uygulamanızı ölçün. Önbelleğe alınmış değerlerin kullanılması, birlikte çalışabilirlik için daha az zaman harcayacağından uygulamanızın hızını artırabilir.

Windows Çalışma Zamanı bileşenlerine yapılan çağrıları birleştirme

UWP nesnelerine mümkün olan en az sayıda çağrıyla görevleri tamamlamaya çalışın. Örneğin, bir akıştan büyük miktarda veri okumak, bir kerede küçük miktarlarda okumaktan daha iyidir.

Daha az iş yapıp daha fazla çağrı gerektiren API'ler yerine mümkün olduğunca az sayıda çağrıda çalışmayı paketleyen API'leri kullanın. Örneğin, varsayılan oluşturucuyu çağırmak ve özellikleri birer birer atamak yerine birden çok özelliği başlatan oluşturucuları çağırarak bir nesne oluşturmayı tercih edin.

Windows Çalışma Zamanı bileşenleri oluşturmak

C++ veya JavaScript ile yazılmış uygulamalar tarafından kullanılabilecek bir Windows Çalışma Zamanı Bileşeni yazarsanız, bileşeninizin iyi performans için tasarlandığından emin olun. Uygulamalarda iyi performans elde etmeye yönelik tüm öneriler, bileşenlerde iyi performans elde etmek için geçerlidir. Yüksek trafik desenlerine sahip API'leri bulmak için bileşeninizi ölçün ve bu alanlar için kullanıcılarınızın birkaç çağrıyla çalışmasını sağlayan API'ler sağlamayı göz önünde bulundurun.

Yönetilen kodda interop kullanırken uygulamanızın hızlı kalmasını koruyun

Windows Çalışma Zamanı, yerel ve yönetilen kod arasında birlikte çalışmanızı kolaylaştırır, ancak dikkatli olmazsanız performans maliyetlerine neden olabilir. Burada, yönetilen UWP uygulamalarınızda birlikte çalışma özelliğini kullanırken nasıl iyi performans elde edebilirsiniz?

Widows Runtime, her dilde kullanılabilen Windows Çalışma Zamanı API'lerinin projeksiyonları sayesinde geliştiricilerin XAML kullanarak tercih ettikleri dille uygulama yazmasına olanak tanır. C# veya Visual Basic'te uygulama yazarken bu kolaylık birlikte çalışma maliyetine neden olur çünkü Windows Çalışma Zamanı API'leri genellikle yerel kodda uygulanır ve C# veya Visual Basic'ten yapılan tüm Windows Çalışma Zamanı çağrıları CLR'nin yönetilen bir yığın çerçevesinden yerel yığın çerçevesine geçişini ve işlev parametrelerini yerel kod tarafından erişilebilen gösterimlere hazırlamasını gerektirir. Bu ek yük çoğu uygulama için göz ardı edilebilir. Ancak bir uygulamanın kritik yolunda Windows Çalışma Zamanı API'lerine çok sayıda çağrı yaptığınızda (yüz binlerce, milyonlarca) bu maliyet fark edilebilir hale gelebilir. Genel olarak, diller arasındaki geçişte harcanan sürenin kodunuzun geri kalanının yürütülmesine göre küçük olduğundan emin olmak istersiniz. Bu, aşağıdaki diyagramda gösterilmiştir.

Windows uygulamaları için .NET'te listelenen türler, C# veya Visual Basic'ten kullanıldığında bu birlikte çalışma maliyetine neden olmaz. Bir kural olarak, "Windows" ile başlayan ad alanları içindeki türlerin olduğunu varsayabilirsiniz. Windows tarafından sağlanan Windows Çalışma Zamanı API kümesinin bir parçası olan türler ve "System." ile başlayan ad alanlarındaki türlerdir. .NET türleridir. Windows Runtime türlerinin basit kullanımının bile, ayırma veya özellik erişimi için bir birlikte çalışma maliyeti getirdiğini unutmayın.

Birlikte çalışma maliyetlerinizi iyileştirmeden önce uygulamanızı ölçmeniz ve birlikte çalışma işleminin uygulama yürütme sürenizin büyük bir bölümünü kaplayıp kaplamadığını belirlemeniz gerekir. Visual Studio ile uygulamanızın performansını analiz ederken, İşlevler görünümünü kullanarak ve Windows Çalışma Zamanı'nı çağıran yöntemlerde harcanan kapsayıcı zamana bakarak birlikte çalışma maliyetlerinizde kolayca üst sınır elde edebilirsiniz.

Birlikte çalışma yükü nedeniyle uygulamanız yavaşsa, sık erişimli kod yollarında Windows Çalışma Zamanı API'lerine yönelik çağrıları azaltarak performansını geliştirebilirsiniz. Örneğin, UIElement'lerin konumunu ve boyutlarını sürekli sorgulayarak tonlarca fizik hesaplaması yapan bir oyun altyapısı, UIElements'ten yerel değişkenlere gerekli bilgileri depolayarak, önbelleğe alınan bu değerler üzerinde hesaplamalar yaparak ve hesaplamalar yapıldıktan sonra sonucu UIElement'lere geri atayarak çok zaman kazandırabilir. Başka bir örnek: Bir koleksiyona C# veya Visual Basic kodu tarafından yoğun bir şekilde erişiliyorsa, Windows.Foundation.Collections ad alanındaki bir koleksiyon yerine System.Collections ad alanından bir koleksiyon kullanmak daha verimlidir. Windows Çalışma Zamanı bileşenlerine yönelik çağrıları birleştirmeyi de düşünebilirsiniz; Bunun mümkün olduğu bir örnek, Windows.Storage.BulkAccess API'lerini kullanmaktır.

UWP bileşeni oluşturma

C++ veya JavaScript ile yazılmış uygulamalarda kullanmak üzere bir Windows Çalışma Zamanı bileşeni yazarsanız, bileşeninizin iyi performans için tasarlandığından emin olun. API yüzeyiniz birlikte çalışma sınırınızı tanımlar ve kullanıcılarınızın bu konudaki yönergeleri ne derece düşünmesi gerekeceğini tanımlar. Bileşenlerinizi diğer taraflara dağıtıyorsanız, bu özellikle önemli hale gelir.

Uygulamalarda iyi performans elde etmeye yönelik tüm öneriler, bileşenlerde iyi performans elde etmek için geçerlidir. Yüksek trafik desenlerine sahip API'leri bulmak için bileşeninizi ölçün ve bu alanlar için kullanıcılarınızın birkaç çağrıyla çalışmasını sağlayan API'ler sağlamayı göz önünde bulundurun. Uygulamaların birlikte çalışma sınırının sık sık geçişini gerektirmeden kullanabilmesi için Windows Çalışma Zamanı'nı tasarlamaya büyük çaba gösterildi.