我正在撰寫一個資源更有限的鍵盤擴展。我正在嘗試選擇代碼結構并需要一些幫助。該專案將有多個類或結構來封裝大量資料，并具有操作它們的函式。每個類中都會有一個或兩個變數來定義需要相應更新 UI 的狀態。
兩種設計選擇
將每個類設為 EnvironmentObject 并發布 UI 需要觀察的變數。這意味著我需要將 ~10 個類設定為 EnvironmentObject。
將狀態變數合并到一個設定為 EnvironmentObject 的類。它不太干凈，但我只需要將 1 個類設定為 EnvironmentObject。
我的問題是：選擇 1 是否有任何處罰？
uj5u.com熱心網友回復：
每個人的應用程式在設定方面都會略有不同。
然而，該ObservableObject協議意味著每個物件——無論是宣告為環境物件還是狀態物件——都有一個objectWillChange()方法，只要任何可觀察的屬性發生變化，就會觸發該方法。屬性包裝器@Published會自動為我們處理。
但該訊息僅告訴 SwiftUI 渲染系統物件中的某些內容發生了變化；然后，渲染系統必須確定是否有任何已更改物件的新屬性需要重新繪制 UI。
如果您有一個包含大量已發布屬性的環境物件，則可能會導致性能下降。如果您將單個物件拆分為多個環境物件，并且每個視圖只選擇進入它需要觀察的環境物件以重繪自身，您可能會看到一些性能改進，因為某些視圖的依賴關系不會改變，因此 SwiftUI 會本質上，能夠跳過它們。
但是擁有多個物件可能有缺點。作為開發人員，它可能更難維護。您還需要確保每個環境物件真正獨立于所有其他物件（否則您將獲得級聯更新，這將否定任何性能改進，并可能使事情變得更糟）。作為開發人員，有時它也會更容易——如果你正確地分離了功能，它可以幫助你保持代碼的組織性和可維護性。不過，獲得那個最佳位置可能真的很棘手。
所以要達到一個平衡點。如果性能成為一個問題，Instruments 應該能夠幫助確定您的個人痛點在哪里以及如何開始解決它們。
但一般來說，我會從更容易為您撰寫和除錯的代碼結構開始。優化結構良好的代碼比維護高度優化但難以閱讀的代碼更容易！
（免責宣告：我不是 SwiftUI 和 Combine 內部的資深專家——以上是從我的實際應用經驗中獲得的，以及在 JavaScript 世界中面臨的 ReactJS 和 Redux 世界中的類似問題，其中單個大型狀態物件面臨類似的規模問題）
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/497661.html
上一篇：向下轉型泛型類