绑定服务中的设计模式?

时间:2015-12-24 16:39:14

标签: android design-patterns service

我正在探索Android中的Bound服务。我在Android开发人员文档中遇到了关于Bound service

的下面一行
  

多个客户端可以立即连接到该服务。然而   系统调用您服务的onBind()方法来检索IBinder   只有当第一个客户绑定时。然后系统提供相同的功能   IBinder到绑定的任何其他客户端,而不调用onBind()   试。

如前所述,似乎Android系统正在使用已存在的IBinder来返回其他客户端。

这种实现是否基于Flyweight设计模式的概念?众所周知,Flyweight模式主要用于减少创建的对象数量,减少内存占用并提高性能。

更新

我检查了处理此代码的Android的源代码。 如下:

if (!data.rebind) {
                        IBinder binder = s.onBind(data.intent);
                        ActivityManagerNative.getDefault().publishService(
                                data.token, data.intent, binder);
                    } else {
                        s.onRebind(data.intent);
                        ActivityManagerNative.getDefault().serviceDoneExecuting(
                                data.token, SERVICE_DONE_EXECUTING_ANON, 0, 0);
                    }

data.rebind只是一个布尔值,在下面的静态类中声明,数据是这个BindServiceData类的对象。

static final class BindServiceData {
        IBinder token;
        Intent intent;
        boolean rebind;
        public String toString() {
            return "BindServiceData{token=" + token + " intent=" + intent + "}";
        }
    }

因此,也许它与Flyweight模式没有直接关系。

1 个答案:

答案 0 :(得分:1)

我不相信这在技术上是使用飞重模式。有一些相似之处,但两者之间存在一些细微差别。

来自WIKI page

  

flyweight是一个通过共享来最小化内存使用的对象   与其他类似对象尽可能的数据;这是一种使用方式   当一个简单的重复表示时,会有大量的对象   使用不可接受的内存量。

然后

  

flyweight模式的典型示例用法是数据结构   字处理器中字符的图形表示。对于文档中的每个字符,可能需要包含字体轮廓,字体度量和其他格式数据的字形对象,但是对于每个字符,这将达到数百或数千个字节。相反,对于每个字符,可能存在对文档中相同字符的每个实例共享的flyweight字形对象的引用;只需要在内部存储每个字符的位置(在文档和/或页面中)。

这描述了一个场景,其中有大量对象,如果每个对象在每个对象中存储“完整数据”,则需要大量内存。当大量对象(例如文本编辑器中的字符)通常具有相同的值集(例如字体大小,字体类型,颜色,背景颜色等)时,Flyweight模式用于减少内存使用量。他们只是共享一个“flyweight”对象,以存储这些数据。 (减少每个对象的多个变量对指针的内存影响)

Android绑定服务在服务启动时创建一个新的ibinder,如果它们“碰巧”在服务启动时绑定到服务,则将该ibinder实例返回给新客户端。但是,与flyweight模式不同,在Android中完成的原因是因为只有一个绑定服务的实例可以启动。所以没有理由退回新的ibinder。 Android服务没有内置任何并发安全性。因此,除非您从头开始设计服务以实现并发并处理多个客户端,否则它们需要以无状态方式进行设计。这就是他们如何通过将并发问题放在开发人员而不是平台上来创建绑定服务的单个实例。

只是将ibinder的单个实例发送给多个客户端并不会使这成为Flyweight模式。如果有什么我会想到它更接近Singleton模式。但这仍然是一个延伸,因为绑定服务的不同实例可能是不同的对象,违反了单例模式。