我的计划是使用单例而不是Parcelable在我的活动和后台服务之间共享数据.所以我的Activity1将通过调用MySingleton.getInstance()添加一些数据.addData(foo);然后我会发送一个意图通知我的服务,新的数据已被添加到单身人士.接下来,我的BackgroundService将处理intent并调用MySingleton.getInstance().getLatestData();然后它会处理数据(需要一些时间).接下来,通过使用单例并激发广播意图,该服务的结果将“后”回来,由Activity1处理(如果存活),并且Activity1将从单例中检索结果.
你们认为这是个坏主意吗？
编辑：
我想要实现的是一个软件的和平,从Web服务器下载数据解析它并返回结果.所以我的Activity将创建DownloadJob对象. DownloadJob-Object将被放入DownloadScheduler(Singleton),它将所有DownloadJobs排队和管理. DownloadScheduler允许同时运行5个DownloadJobs并使用队列来存储等待.有效的下载将由DownloadService(IntentService)完成,它通过Intent通知现在应该执行(下载)新的DownloadJob. DowanlodService将从DownloadSchedulers队列(PriorityBlockingQueue)中检索下一个作业,并通过设置DownloadJob.setResult(…)返回结果并触发广播意图,结果已准备就绪,这将由DownloadScheduler接收,从队列中取出作业并通知活动下载完成等.
因此,在我的场景中,我将使用单例从DownloadService访问DownloadJobs,而不是使用DownloadWob Parcelable并将其传递给Intent.所以我会避免这个问题,我在内存中有两个DownloadJobs(一个在“活动站点”,一个在“服务站点”).
任何建议如何更好地解决这个问题？
静态实例(例如DownloadScheduler(Singleton))是否会被低内存的android系统释放？那么将子类化应用程序并保持引用(非静态)避免此问题？
解决方法
如果单例中的数据不同步,则必须小心,因为您依赖于“协议”以确保在后台线程正在写入时没有人正在读取(这可能会导致错误).
另一方面,如果它是同步的,则您可能面临错误,因为可能会阻止读取数据的活动等待服务完成以在单例中写入数据.
正如另一个所说,你还必须记住,如果操作系统需要资源,你的单身可能会被释放,而你的数据可能不再存在了.
编辑：
使用单例作为后台(意图)服务的入口点是2010年Virgil Dobjanschi talk建议的关于为Android构建休息客户端应用程序的方法.
建议的方法是具有作为正在进行的请求的控制器的单一单元.请注意,对意图服务的请求已经由操作系统排队,因此您可以抛出几个意图服务将按顺序处理的意图.
前段时间我也尝试将其作为图书馆的起点,但仍未完成.你可以找到来源here
我当然不会做的是将数据存储在单例中.我更喜欢的方法是将数据存储在某些持久存储(例如sql / preferences / file / content provider)中,让客户端通过广播消息知道更改(或者,如果您使用的是内容提供商,则通过观察员).
