在应用程序中存储小部件是否会导致性能损失（或内存泄漏）？
我有一个在我的所有活动中引用的 SlidingDrawer。抽屉非常详细，并且具有很深的视图层次结构。目前，我的所有活动都在创建时调用应用程序上下文以接收抽屉的单例副本。当调用 Activity onPause 时，它会从其顶级 ViewGroup 中删除抽屉。这可行，但我不知道这是否是最好的方法。
我遇到的另一个问题是上下文使用。 SlidingDrawer 有一些按钮可以触发一些对话框。知道我无法传递应用程序上下文，我刚刚创建了一个 OnActivityChangeBroadcaster 和 Listener 来更改抽屉的引用上下文。但即使如此，该对话框始终出现在启动器活动中。
有人对此事有任何想法或智慧吗？
I have a SlidingDrawer that is referenced in all of my activities. The drawer is quite detailed and has a deep hierarchy of views. Currently I have all of my activities calling the application context upon creation to receive the singleton copy of the drawer. When an activities onPause is called, it removes the drawer from its top level ViewGroup. This works, but I don't know if it is the best way of doing it.
Also an issue I'm having is context usage. The SlidingDrawer has some buttons that fire off some dialogs. Knowing that I can't pass the application context, I just created a OnActivityChangeBroadcaster and Listener which changed the references context for the drawer. But even with this the dialog always appears in the launcher activity.
Does anyone have any thoughts or wisdom on the matter?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
你正在泄漏内存。切勿在 Activity 之间传递小部件。切勿将小部件或任何其他引用活动的东西放入
Application对象或静态数据成员中，除非您要在活动时null删除该引用。被毁了。请在每项活动中重新创建你的抽屉。
You are leaking memory. Never pass widgets between activities. Never put widgets, or anything else with a reference to an activity, in an
Applicationobject or static data member, unless you are going tonullout that reference when the activity is destroyed.Recreate your drawer in each activity, please.
我的方法是将用户界面与数据分离。如果您的许多 Activity 使用相同的 SlidingDrawer，我会将 SlidingDrawer 显示的数据分离到其自己的 [非 UI] 类中，以便它仅存在于一个位置，并让每个 SlidingDrawer 实例从该数据填充自身。您可以在 XML 中定义一次 SlidingDrawer，然后在您需要的所有布局中
然后，我将有一个函数，用来自单独类的数据填充 SlidingDrawer（可通过单例对象或通过将数据设为静态来访问）。为了实现这一点，您可以创建一个静态方法，将 SlidingDrawer 作为参数进行填充 (
public static void loadSlidingDrawer(SlidingDrawer destinationView) {...})，或者您可以扩展 SlidingDrawer 并使每个实例都可以访问该类方法。CommonsWare 是正确的，按照当前的策略，您将到处泄漏内存。 UI 元素需要具有不断销毁和重新创建的灵活性，因此将所有数据分离到 UI 简单访问并显示的非 UI 类中是一个非常好的习惯。这很好地解耦了一切，并使框架能够高效运行。
My approach would be to decouple the UI from the data. If many of your Activities use the same SlidingDrawer, I would separate the data that the SlidingDrawer is displaying into its own [non-UI] class so that it exists in only one place, and have each SlidingDrawer instance populate itself from that data. You can define your SlidingDrawer in XML once and
<include>it in the all the layouts you need.Then I would have one function that populated the SlidingDrawer with the data from your separate class (accessible via a singleton object or by making the data
static). To achieve that you can either make astaticmethod that takes the SlidingDrawer to populate as a parameter (public static void loadSlidingDrawer(SlidingDrawer destinationView) {...}), or you can extend SlidingDrawer and make that a class method accessible by each instance.CommonsWare is correct, you'll be leaking memory all over the place with your current strategy. UI elements need to have the flexibility to be destroyed and recreated constantly, so it's a really good habit to get into to separate all your data into non-UI classes that you UI simply accesses to display. This decouples everything nicely and allows the framework to function efficiently.