Android 是否可以创建应用程序/活动对象的数组/列表，每个对象都有自己的上下文，每个对象都有自己的LocationManager？

请注意，我对Android非常陌生

我正试图通过限制位置感应等方法来研究节省电池寿命的方法。。。为此，我想“背负”多个基于位置的应用程序的位置感测。我想要实现的是模拟多个这样的应用程序，每个应用程序都有自己的LocationListener（来自应用程序上下文的LocationManager），我想尝试从单个活动中生成新的应用程序，就像实例化对象一样。 这里重要的一点是，我可以将大量不同的应用程序上下文存储在一个数组或列表中

因此，简言之，一种方法是：

Vector<Application> applications = new Vector<Application>();

applications.add( new Application() );
applications.add( new Application() );

// here new Application would only be an object which extends Application

如果这不是多余的，那么如何实现它呢？：）

再一次，谢谢

为此，我想“背负”多个基于位置的应用程序的位置感测

这将由硬件和操作系统自动完成，适用于任何传统的“背驮”定义

如果同时有100个应用程序要求安装GPS，那么硬件不会自动增加100个GPS收音机。有（最多）一个GPS无线电，消耗一个电量，向当前请求定位的应用程序发送定位信息

这里重要的一点是，我可以将大量不同的应用程序上下文存储在一个数组或列表中

---

这是不可能的。

您试图从本质上为自己的目的劫持应用程序生命周期。这不是它的工作原理-Android应用程序声明它们希望如何运行（主要在

AndroidManifest.xml

中），操作系统根据该规范进行操作

如果不修改操作系统，您的方法就无法实现。这是件好事

让我这样说吧——作为一名应用程序开发人员，您有可能实现您的解决方案，这有意义吗？也就是说，其他开发人员编写的应用程序会改变你的应用程序的工作方式，就像那样？您可能有loft目标（缩短电池寿命），其他开发人员可能不那么高尚

我建议您阅读全文（不仅仅是第一页），您将对Android的工作原理有一个基本的了解

---

文章链接提供后更新：不，我说的是您描述的方法不可能：）。本文的作者尝试了一种不同的方法——他们注册了一个新的

LocationProvider

他们到底是如何做到的还不清楚-这取决于他们对“SP连接到位置感应注册函数requestLocationUpdate（）中”这句话的意思。此外，他们在一款

G1

手机上完成了这项工作，这是最早的安卓消费设备之一。从实现细节来看，他们编写的内容现在可能已经过时。

您是否正在尝试动态启动新的应用程序实例，并向它们提供“缓存”的位置数据？我本质上想要的是从动态对象中实例化它们—一个包含位置感知功能的对象，然后将每个实例存储在一个可访问的列表中。哦，好吧，那么LocationManager实例是静态的，并且在android设备上运行的所有应用程序中共享？换句话说，在整个设备及其所有应用程序中都可以访问同一个设备，因此它们中的每一个都可以在没有额外电源的情况下获得相同的位置？我只是想在这种情况下理解这篇文章：-关于“背驮”的部分。。。如果它在整个设备上共享同一个LocationManager，那又有什么意义呢？“基于多个位置的应用程序”部分。@Piotr：“LocationManager实例是静态的，在android设备上运行的所有应用程序中共享？”——

LocationManager

是一个与核心操作系统进程对话的对象，而核心操作系统进程实际上决定了位置。“所以他们每个人都可以在没有额外电源的情况下获得相同的位置？”——同样，耗电量主要取决于GPS无线电是否通电，同时有几个应用程序并不会改变这一点。@Piotr:关于那篇文章，它是从2010年开始的，指的是2008年的老式设备。此外，建议的技术应该（现在大部分）在操作系统层实现。非常感谢您的回答！所以你的意思是，他们在论文中所写的内容——搭载——不修改操作系统是不可能实现的？

• {(Gps), Gps}: The prototype checks whether the (Gps, T1, D1)
state is valid. If so, then it compares (T1, D1) to (T0, D0). If
T1 < T0 and D1 < D0, then piggybacking is enabled, and the
piggybacking time is calculated.
• {(Gps), Net}: As Net typically has coarser location information
than Gps, the operations are similar to the ({Gps},Gps) scenario,
but the comparison is between (T2, D2) and (T0, D0).
• {(Net), Net}: Similar to {(Gps), Gps} case by replacing Gps
with Net.
• {(Net), Gps}: Since Gps is typically finer than Net, the request
cannot piggyback on existing Net registrations. The new registration is passed through                 immediately.
• {(Gps, Net), Gps}: Similar to {(Gps), Gps}.
• {(Gps,Net), Net}: The prototype firstly checks the Net state,
which is similar to that of {(Net), Net}. If not possible to piggyback, then it checks the     Gps     state, which is similar to {(Gps),
Net} scenario.

(c) Sensing Piggybacking (SP)
Variables
StateGps: Gps registration state
StateNet: Net registration state
time: Requested location sensing frequency
dist: Requested location sensing distance
1 Received requestLocationUpdate(provider, time, dist,...)
2 Store information about provider, time, distance
3 Check validity of StateGps and StateNet
4 If provider == Gps
5 Compare StateGps to time and dist
6 If StateGps allows piggybacking
7 Delays the registration to enable piggybacking
8 End
9 Else // provider == Net
10 Compare StateNet to time and dist
11 If StateNet allows piggybacking
12 Delays the registration to enable piggybacking
13 Else
14 Compare StateGps to time and dist
15 If StateGps allows piggybacking
16 Delays the registration to enable piggybacking
17 End
18 End
19 End