2013-07-15 17 views
8

Tôi đã lên kế hoạch xây dựng một khung ứng dụng kinh doanh WPF MVVM và tôi đã xem xét nhiều bài báo khi thực hiện nghiên cứu nói về rò rỉ bộ nhớ trong nền tảng WPF.Rò rỉ bộ nhớ nào vẫn còn hiện diện trong WPF 4

A memory leak may occur when you use data binding in Windows Presentation Foundation
Avoiding a WPF memory leak with DataBinding (Black Magic)
Serious Memory Leaks Plague WPF
Top 5 Memory leaks in WPF and Silverlight
WPF Binding Bug leads to possible Memory Issues

Nhưng hầu hết trong số họ ngày trở lại năm 2007 và 2008 vì vậy tôi đã tự hỏi đó trong số họ đã được giải quyết và đó không.

Nói cách khác, các nguồn rò rỉ bộ nhớ có thể có (có thể xảy ra) là gì khi tính đến khi xây dựng khung của tôi hoặc để xem tổng quát (WPF 4.0, .NET 4.0)?

Chỉnh sửa: Tôi sẽ cố gắng cụ thể hơn. Tôi có thể tận dụng lợi thế của WeakEventManager và các lớp con của nó để nghe các sự kiện mà không cần phải phát triển giải pháp của riêng tôi không?

Chỉnh sửa 2: Thậm chí cụ thể hơn. Tôi có thể sử dụng các WeakEventManager để giải quyết vấn đề rò rỉ bộ nhớ gây ra bởi các sự kiện trong NET nói chung và không chỉ WPF ?. Nếu vậy tại sao nó là một phần của một không gian tên WPF và không phải là một không gian tên .NET chung?

+4

Bạn có thể thêm một số liên kết cụ thể không? Sự hiểu lầm về các tham chiếu sự kiện là một nguồn phổ biến của các báo cáo 'rò rỉ bộ nhớ' sai lầm - hãy tìm WeakEvent như là một sự khởi đầu. – Govert

+0

@Govert tôi đã thêm một số liên kết. –

+0

Tôi chỉ tự hỏi tại sao ai đó có thể bỏ phiếu để đóng câu hỏi này, điều kiện nào là vi phạm hoặc có gì sai với nó nói chung? !! –

Trả lời

8

đầu tiên mà nói đến cái tâm của tôi:

  • System.Windows.Interactivity.Behavior từ System.Windows.Interactivity.dll: một hành vi có thể không tách khi bạn mong đợi nó đến và ngược lại, để lại sự kiện bổ sung xử lý trên điều khiển để tồn tại gc
  • Chỉ cần bằng cách mô tả của bạn Tôi đang khá chắc chắn vì bạn sẽ được sử dụng của bên thứ ba thành phần trong tương lai, chúng tôi thấy đây là một ứng cử viên hạng nhất cho rò rỉ

Thực tế là bạn đang xem xét điều này trước khi bắt đầu là ap lus, đầu tư vào một MemoryProfiler tốt và hồ sơ ứng dụng của bạn ngay từ đầu một cách thường xuyên và bạn sẽ được tốt.

Edit: Để bình luận về sửa đổi của bạn: Kiểm tra qua các liên kết của bạn tôi nghĩ bạn có thể Tách ba chủ đề chính:

  • thực hiện INotifyPropertyChanged là điều bắt buộc. Nhà phát triển đầu tiên của bạn nói với bạn "ist chỉ một chế độ xem tĩnh, dữ liệu sẽ không thay đổi trên mô hình của tôi, tôi chỉ bỏ qua INPC" phải được vẽ và đặt ở nơi công cộng. Thậm chí tốt hơn, khung công tác của bạn nên thực thi triển khai giao diện này, hoặc ít nhất cũng giúp các nhà phát triển sử dụng nó dễ dàng nhất có thể.
  • Không liên kết với PropertyDescriptors, có thể không rõ ràng ở nơi đầu tiên nhưng một lần nữa Framework của bạn có thể thiết lập đường dẫn cho các nhà phát triển chỉ sử dụng nó để liên kết với các thuộc tính viewmodel tùy chỉnh.
  • Luôn unregister eventhandler của bạn, mà theo ý kiến ​​của tôi là hơn một câu hỏi về vệ sinh đang

Như để chỉnh sửa của bạn liên quan đến các sự kiện yếu, vâng điều này có thể làm việc. Cá nhân tôi sẽ không xem xét thực hành tốt này vì nó có thể dẫn đến tình huống mà mô hình của bạn phơi bày các sự kiện bạn đang đăng ký được làm sạch sớm hơn bạn mong đợi nó. Tôi đề nghị để đi bộ thêm dặm và ý thức unregister xử lý của bạn.

+0

+1 cho thông tin chi tiết của bên thứ ba. Nếu bạn có thời gian, tôi sẽ biết ơn nếu bạn đưa ra câu trả lời của bạn với CÁCH bạn bị cô lập và phát hiện ml trong các thành phần này. Tôi đoán đó là một vấn đề được chia sẻ bởi rất nhiều người –

+0

+1 cho rò rỉ hành vi * (thêm một rò rỉ mà tôi không biết) *. Tôi sẽ xem xét các đề xuất của bạn, nhưng bạn có thể xem xét lại câu trả lời của mình vì tôi đã thực hiện một vài chỉnh sửa đối với câu hỏi ban đầu của tôi không? Cảm ơn bạn. –

+0

Re: Hành vi ... Tôi đã làm theo [hướng dẫn này] (http://dotnetbyexample.blogspot.com/2011/04/safe-event-detachment-pattern-for.html) để tách an toàn khỏi AssociatedObject – Thelonias