2015-09-29 17 views
15

Có ai khác có bất kỳ vấn đề nào với trải nghiệm phát triển rất chậm chạp trong các ứng dụng viết VS 2015 cho nền tảng Windows Universal 10 không? Biên dịch, gỡ lỗi, thậm chí chuyển đổi giữa các cửa sổ là rất chậm so với làm việc với một ứng dụng WPF cơ bản tương tự.Tại sao phát triển UWP 10 quá chậm?

Tôi chưa thể tìm thấy bất kỳ đề cập nào về trải nghiệm này trên Google, điều này khiến tôi tự hỏi liệu có điều gì đó trong thiết lập của tôi đang ném cờ lê khỉ vào UWP dev hay không.

Có ai đã trải nghiệm điều này hoặc biết cách nào để tăng tốc độ phát triển không?

Cập nhật

Bối cảnh của câu hỏi này được soạn thảo trong chế độ DEBUG, không tiết lộ chế độ (NET mẹ đẻ).

+0

Bạn có bất kỳ bổ trợ nào trong cài đặt VS của mình không? Bạn đã thử đặt lại cấu hình VS của mình chưa? Có bất kỳ quá trình chống vi-rút hoặc nền nặng nào khác đang chạy không? – Dai

+0

"Nền tảng Windows phổ biến" - Microsoft mất âm mưu ..... –

+0

Tôi đã phát hiện ra rằng nó mất mãi mãi để xây dựng trong bản phát hành ... –

Trả lời

2

Cập nhật Oct 2016

Câu trả lời này là không còn phù hợp, tính đến Visual Studio 2015 Update 3. Microsoft đã thực hiện một công việc tuyệt vời đưa môi trường phát triển trở lại trạng thái ổn định. Mặc dù hiện tại tôi có vấn đề với nhà thiết kế XAML, việc mã hóa tòa nhà & nhanh hơn và thú vị hơn nhiều. Tôi hy vọng hầu hết các vấn đề gây suy thoái được tìm thấy trong trình thiết kế XAML được giải quyết trong Visual Studio 15 tiếp theo.


Có ai có kinh nghiệm này

.

Mọi người trong nhóm của tôi đều mất tóc vì UWP. Tôi gần như bị thuyết phục rằng Microsoft muốn tôi ghét C# & XAML.

... hoặc biết cách nào để tăng tốc độ phát triển?

Tôi đang chuyển ứng dụng của mình sang UWP nhưng tôi không thể kết thúc hỗ trợ cho Win8. Vì vậy, tôi có cả hai dự án trong cùng một giải pháp. Đối với tôi, để tăng tốc mọi thứ, tôi đã sửa đổi các cấu hình xây dựng thành "Debug-UWP" và "Release-UWP" để loại trừ ứng dụng và dự án Win8 khi tôi đang làm việc với ứng dụng Windows 10. Đây chỉ là một cứu trợ nhỏ. Tòa nhà vẫn là một trải nghiệm đau đớn.

Cũng

Bạn có thể tắt NuGet từ khôi phục lại các gói trên mỗi xây dựng. Chuyển đến Tùy chọn>Trình quản lý gói NuGet và bỏ chọn "Tự động kiểm tra các gói bị thiếu trong khi xây dựng trong Visual Studio." Điều này cũng rất nhỏ, nhưng mỗi chút giúp.

+0

I LOVE WUP. Thật tuyệt vời khi tôi có thể xây dựng một ứng dụng cho máy tính và nó hoạt động trên điện thoại. –

+0

Mặc dù không có cách giải quyết nào được trình bày (tại thời điểm này, tôi cho rằng không có cách nào để làm mọi thứ nhanh hơn), cảm ơn ít nhất là cho tôi biết tôi không đơn độc trong bản UWP dev chậm chạp. – BCA

+0

@ARandomGuy, tôi cũng thích nó, tin tôi đi. Tôi có hy vọng cao cho nó. – Laith

4

Chỉ cần 2 xu của tôi, nhưng gần đây tôi đã phát hiện ra rằng có một vấn đề lớn khi làm việc trên dự án UWP.

Tôi đang làm việc trên dự án của mình với Xamarin để có ứng dụng tương thích trên Android/iOS/WP8 và UWP.

Nhưng làm việc trong Visual Studio 2015 Update 2 (Với W10) gần đây, tôi có màn trình diễn rất chậm, giao diện rất chậm, Xây dựng, Gỡ lỗi, XAML, mọi thứ đều rất chậm.

Sau đó, tôi chỉ phát hiện ra điều gì đó rất khủng khiếp: Nếu bạn thiết lập dự án UWP của bạn làm dự án khởi động của Solution, Visual Studio 2015 trở nên chậm như địa ngục! Tôi không phải là vấn đề thực sự nhưng đây là một vấn đề thực sự đối với tôi!

Tôi đặt dự án khởi động của mình trên một dự án khác trong giải pháp, ngoài UWP và WP8. Nếu tôi cần gỡ lỗi, tôi khởi chạy chúng bằng cách nhấp chuột phải vào trình thám hiểm giải pháp, sau đó gỡ lỗi.

Kể từ đó, VS2015 không có vấn đề về hiệu suất đối với tôi.

+0

Đây là giải pháp tốt nhất cho đến nay, điều này làm việc liên tục. Bây giờ chỉ khi Microsoft khắc phục được sự cố ... – silencedmessage

3

Hấp dẫn ... chỉ đơn giản là hấp dẫn.

Tắt "Biên dịch với .NET Chuỗi công cụ gốc" trên thuộc tính Xây dựng của ứng dụng UWP chính. Thư viện UWP không xuất hiện để cung cấp tùy chọn chuỗi công cụ gốc.

Tôi đã chống lại sự cố tại sao ứng dụng phân tích cú pháp tệp của tôi mất khoảng gấp đôi thời gian để thực thi (không xây dựng) dưới dạng bản phát hành hơn là bản dựng gỡ lỗi. Hoàn toàn ngược lại những gì đáng lẽ đã xảy ra. Tôi cũng đã xảy ra để lưu ý thời gian dài để hoàn thành việc xây dựng phát hành, nhưng nó là một vấn đề thứ cấp trong thời gian này.

Nếu bạn xem cửa sổ đầu ra trong khi xây dựng lại hoàn chỉnh, bạn sẽ lưu ý bất kỳ thư viện nào bạn có sẽ xây dựng nhanh như bạn thường làm. Sau đó, các ứng dụng chính sẽ là một trong những bogs xuống - một LOT.

Kiểm tra thuộc tính Xây dựng cho các dự án của bạn và chỉ lưu ý ứng dụng UWP chính có tùy chọn "Biên dịch với .NET Native tool". Các thư viện không có nó. Ngoài ra, theo mặc định, chỉ phiên bản phát hành mới được bật. Trình gỡ lỗi không. Chắc chắn, hãy tắt nó trên bản phát hành bản phát hành và bản phát hành bản phát hành bắt đầu hoàn thành nhanh như bản dựng gỡ lỗi.

Sau đó, sự kỳ lạ của sự kỳ lạ ... Phiên bản phát hành ứng dụng UWP của tôi hiện chạy nhanh hơn khoảng 10% so với phiên bản gỡ lỗi khi nó chạy gần gấp hai lần.

Đây là tất cả VERY phản trực giác. Bản dựng gốc nên chạy nhanh, nếu thậm chí không nhanh hơn một chút so với bản dựng không phải gốc. Trình biên dịch dưới Visual Studio chắc chắn có tùy chọn đưa công việc khó khăn hơn vào việc tối ưu hóa việc xây dựng cho bộ vi xử lý.

Tôi tự hỏi liệu có bất kỳ điều gì khác được xuất bản về các vấn đề với công cụ xây dựng gốc hay không và liệu có giải thích hay không. Thời gian xây dựng chậm tôi có thể hiểu hoàn toàn nếu các công cụ xây dựng đang munching đi rất nhiều khó khăn hơn cố gắng để tối ưu hóa cho các bộ xử lý bản địa cụ thể. Tuy nhiên thực tế, mã nguồn gốc chạy chậm hơn đáng kể so với mã không phải là mã nguồn gốc hoàn toàn ngược trực quan. Nó dường như không có ý nghĩa rằng MSFT sẽ phải lo lắng để phát hành các công cụ xây dựng bản địa trong hoàn cảnh như vậy, dẫn người ta tự hỏi nếu các công cụ đang được sử dụng không chính xác hoặc một số hiểu lầm khác là a'foot.

+0

Tôi cũng đã tìm thấy hành vi đầu trầy xước này với hiệu suất thời gian chạy giữa các bản dựng Debug và Release. Tôi có một trang GridView mất 3 giây để hiển thị với bản dựng Gỡ lỗi và 5 giây tẻ nhạt với bản dựng Bản phát hành. Tuy nhiên, tôi có thể sai nhưng tôi tin rằng nếu bạn đang đưa ứng dụng của mình vào Windows Store, nó sẽ được biên dịch bằng chuỗi công cụ .NET Native vào cuối – BCA

+0

Tôi dường như nhớ đọc ở đâu đó rằng nếu bạn đang dựa vào mã sử dụng các biểu thức (ví dụ như JSON.NET) sau đó mã phát hành của bạn có thể sẽ chậm hơn, lý do là chúng không thể được JITted như với bản dựng không phải bản địa, thay vào đó chúng phải được hiểu. –

Các vấn đề liên quan