【问题标题】:Change activity variables from another activity/Service从另一个活动/服务更改活动变量
【发布时间】:2016-01-07 12:28:55
【问题描述】:

通常建议使用以下解决方案:

  • 使用像here这样的Intent
  • 使用像here这样的处理程序
  • 使用SharedPreferences 喜欢here

问题

定义一个公共方法来设置变量有什么问题:

public class Activity1 {
   private int var1;
   public void setVar1(int val){
           var1=val;
   }
}

在 Activity2 中:

public class Activity2 {
    Activity1.setVar1(4);
}

好像对静态和非静态变量都适用

EDIT1:

这是我当前项目的一个简单案例。在原始情况下,Activity2 连接到蓝牙 Hub 并接收多个传感器的数据。如果值发生更改,它应该将更改后的值(以及传感器 ID)传递给负责更新 UI 的Activity1。传感器的数量可以超过 100 个,更新周期在 100 毫秒的范围内,这意味着可运行对象每 100 毫秒读取传入的 BT 消息并检查更改。

EDIT2:

BroadcastReceiver 也是解决方案。但问题是:定义一个 set 方法来更改/更新变量有什么问题。这种方法在内存方面效率低下吗?它会使应用程序变慢吗?是不是代码不合适?

我只是想知道如果我定义 set 方法来更改活动变量,我会面临什么样的问题/效率低下。

【问题讨论】:

  • 可能有类似的问题,但我还不满意。
  • 为什么你需要改变这个值?尝试使用广播接收器。
  • @Sumant:请看Edit1
  • 正如@Sumant 所说,您可以使用广播接收器(BroadcastReceiver、LocalBroadcastManager 类)
  • @ondermerol:绝对正确,BroadcastReceiver 是一个解决方案。但问题是:定义一个 set 方法来更改/更新变量有什么问题,这种方法在内存方面效率低吗?慢吗?是不合适的代码吗?我只是想知道如果我定义设置方法来更改活动变量会遇到什么样的问题/效率低下

标签: android parameter-passing


【解决方案1】:

请记住,Activity 实例本身就是Context,并且这些实例占用的内存量可能非常大,因为它们保留了对 Activity 的视图层次结构及其所有相关资源的引用.保留对 Activity 实例的长期引用是内存泄漏的常见来源。

记住这一点,在这个特定的设置中:

public class Activity1 {
   private int var1;
   public void setVar1(int val){
           var1=val;
   }
}

...调用activity1.setVar1(...) 意味着Activity2 的运行实例引用了Activity1 的实例,这意味着不允许系统对其进行垃圾收集。这种模式最终可能导致应用程序耗尽其堆并崩溃。

您还询问了将这些方法公开为静态方法的可能性。虽然您可以避免上述问题,但这里的一个潜在陷阱是,如果用户切换到另一个应用程序,并且系统内存不足,您的应用程序进程可能会被系统杀死。由于静态变量与正在运行的流程实例相关联,因此当用户返回您的应用程序并且系统恢复其状态时,var1 将被重置为其默认值(零)。 (您可以通过挂钩生命周期方法将值保存到 Bundle 实例等来缓解这种情况)。

这些是我能想到的避免将 getter/setter 写入 Activity 界面的一些原因。

【讨论】:

    【解决方案2】:

    引用另一个活动并不是一个好方法,因为每个活动都有自己的生命周期。您引用的活动可能会被销毁,或者系统可能已经启动了该活动的新实例,而您仍然引用旧实例。

    或者,您可以使用事件总线(例如 Otto)将对象/事件发布到另一个活动。

    【讨论】:

      猜你喜欢
      • 2015-02-16
      • 1970-01-01
      • 2012-04-15
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2011-09-30
      • 1970-01-01
      • 2016-06-07
      相关资源
      最近更新 更多