《Android 源码设计模式解析与实战》——第2章,第2.7节Android源码中的单例模式

2.7 Android源码中的单例模式
在Android系统中,我们经常会通过Context获取系统级别的服务,如WindowsManagerService、ActivityManagerService等,更常用的是一个LayoutInflater的类,这些服务会在合适的时候以单例的形式注册在系统中,在我们需要的时候就通过Context的getSystemService(String name)获取。我们以LayoutInflater为例来说明,平时我们使用LayoutInflater较为常见的地方是在ListView的getView方法中:

@Override
public View getView(int position, View convertView, ViewGroup parent)
  View itemView = null;
  if (convertView == null) {
    itemView = LayoutInflater.from(mContext).inflate(mLayoutId, null);
    // 代码省略
  } else {
    // 代码省略
  }
  // 代码省略
  return itemView;
}
通常我们使用LayoutInflater.from(Context)来获取LayoutInflater服务,下面看看LayoutInflater.from (Context)的实现:

public static LayoutInflater from(Context context) {
  LayoutInflater LayoutInflater =(LayoutInflater) context.getSystemService(Context. LAYOUT_INFLATER_SERVICE);

  if (LayoutInflater == null) {
    throw new AssertionError("LayoutInflater not found.");
  }
  return LayoutInflater;
}
可以看到from(Context)函数内部调用的是Context类的getSystemService(String key)方法,我们跟踪到Context类看到,该类是抽象类:

public abstract class Context {
  // 省略
}

getView中使用的Context对象的具体实现类是什么呢?其实在Application、Activity、Service中都会存在一个Context对象,即Context的总个数为Activity个数 + Service个数 + 1。而ListView通常都是显示在Activity中,那么我们就以Activity中的Context来分析。

我们知道,一个Activity的入口是ActivityThread的main函数,在main函数中创建一个新的ActivityThread对象,并且启动消息循环(UI线程),创建新的Activity、新的Context对象,然后将该Context对象传递给Activity。下面看看ActivityThread源代码:

public static void main(String[] args) {
// 代码省略
    Process.setArgV0("<pre-initialized>");
    // 主线程消息循环
    Looper.prepareMainLooper();
    // 创建ActivityThread对象
    ActivityThread thread = new ActivityThread();
    thread.attach(false);

    if (sMainThreadHandler == null) {
      sMainThreadHandler = thread.getHandler();
    }

    AsyncTask.init();
    // 代码省略
    Looper.loop();
  }

  private void attach(boolean system) {
    sThreadLocal.set(this);
    mSystemThread = system;
    // 不是系统应用的情况
    if (!system) {
      ViewRootImpl.addFirstDrawHandler(new Runnable() {
        public void run() {
          ensureJitEnabled();
        }
      });

      android.ddm.DdmHandleAppName.setAppName("<pre-initialized>",UserHandle.myUserId());
      RuntimeInit.setApplicationObject(mAppThread.asBinder());
      IActivityManager mgr = ActivityManagerNative.getDefault();
      try {
        // 关联mAppThread
        mgr.attachApplication(mAppThread);
      } catch (RemoteException ex) {
        // 省略
      }
    } else {
        // 省略
    }
}  

在main方法中,我们创建一个ActivityThread对象后,调用了其attach函数,并且参数为false。在attach函数中,参数为false的情况下(即非系统应用),会通过Binder机制与ActivityManager Service通信,并且最终调用handleLaunchActivity函数,我们看看该函数的实现:

private void handleLaunchActivity(ActivityClientRecord r, Intent customIntent) {
    // 代码省略
    Activity a = performLaunchActivity(r, customIntent);
    // 代码省略
  }

   private Activity performLaunchActivity(ActivityClientRecord r, Intent customIntent) {
    // 代码省略
    Activity activity = null;
    try {
      java.lang.ClassLoader cl = r.packageInfo.getClassLoader();
      activity = mInstrumentation.newActivity(     // 1. 创建Activity
      cl, component.getClassName(), r.intent);
     // 代码省略
    } catch (Exception e) {
     // 省略
    }

    try {
    // 创建Application对象
      Application app = r.packageInfo.makeApplication(false, mInstrumentation);
      if (activity != null) {
        Context appContext = createBaseContextForActivity(r, activity);
        // 2. 获取Context对象
        CharSequence title = r.activityInfo.loadLabel(appContext.getPackageManager());
        Configuration config = new Configuration(mCompatConfiguration);
        // 3. 将appContext等对象attach到activity中
        activity.attach(appContext, this, getInstrumentation(), r.token,
        r.ident, app, r.intent, r.activityInfo, title, r.parent,
        r.embeddedID, r.lastNonConfigurationInstances, config);

        // 代码省略
        // 4. 调用Activity的onCreate方法
        mInstrumentation.callActivityOnCreate(activity, r.state);
        // 代码省略
    } catch (SuperNotCalledException e) {
      throw e;
    } catch (Exception e) {
      // 代码省略
    }

    return activity;
  }
  private Context createBaseContextForActivity(ActivityClientRecord r,
      final Activity activity) {
    // 5. 创建Context对象, 可以看到实现类是ContextImpl
 ContextImpl appContext = ContextImpl.createActivityContext(this, r.packageInfo, r.token);
    appContext.setOuterContext(activity);
    Context baseContext = appContext;
    // 代码省略
    return baseContext;
  }

通过上面1~5注释处的代码分析可以知道,Context的实现类为ComtextImpl。我们继续跟踪ContextImpl类:

class ContextImpl extends Context {

// 代码省略
// ServiceFetcher通过getService获取服务对象
   static class ServiceFetcher {
    int mContextCacheIndex = -1;

    // 获取系统服务
    public Object getService(ContextImpl ctx) {
      ArrayList<Object> cache = ctx.mServiceCache;
      Object service;
      synchronized (cache) {
        if (cache.size() == 0) {
          for (int i = 0; i < sNextPerContextServiceCacheIndex; i++) {
            cache.add(null);
          }
        } else {
          service = cache.get(mContextCacheIndex); // 从缓存中获取Service对象
          if (service != null) {
            return service;
          }
        }
        service = createService(ctx);
        cache.set(mContextCacheIndex, service);
        return service;
      }
    }

    /**
     * 子类覆写该方法用以创建服务对象
     */
    public Object createService(ContextImpl ctx) {
      throw new RuntimeException("Not implemented");
    }
  }

  // 1. Service容器
  private static final HashMap<String, ServiceFetcher> SYSTEM_SERVICE_MAP =
      new HashMap<String, ServiceFetcher>();

  private static int sNextPerContextServiceCacheIndex = 0;
  // 2. 注册服务器
  private static void registerService(String serviceName, ServiceFetcher fetcher) {
    if (!(fetcher instanceof StaticServiceFetcher)) {
      fetcher.mContextCacheIndex = sNextPerContextServiceCacheIndex++;
    }
    SYSTEM_SERVICE_MAP.put(serviceName, fetcher);
  }

  // 3. 静态语句块, 第一次加载该类时执行 ( 只执行一次, 保证实例的唯一性 )
  static {
    // 代码省略
    // 注册LayoutInflater service
    registerService(LAYOUT_INFLATER_SERVICE, new ServiceFetcher() {
        public Object createService(ContextImpl ctx) {
          return PolicyManager.makeNewLayoutInflater(ctx.getOuterContext());
        }});
    // 代码省略
  }

  // 4. 根据key获取对应的服务
  @Override
  public Object getSystemService(String name) {
    // 根据name来获取服务
    ServiceFetcher fetcher = SYSTEM_SERVICE_MAP.get(name);
    return fetcher == null ? null : fetcher.getService(this);
  }
  // 代码省略
}

从ContextImpl类的部分代码中可以看到,在虚拟机第一次加载该类时会注册各种ServiceFatcher,其中就包含了LayoutInflater Service。将这些服务以键值对的形式存储在一个HashMap中,用户使用时只需要根据key来获取到对应的ServiceFetcher,然后通过ServiceFetcher对象的getService函数来获取具体的服务对象。当第一次获取时,会调用ServiceFetcher的createService函数创建服务对象,然后将该对象缓存到一个列表中,下次再取时直接从缓存中获取,避免重复创建对象,从而达到单例的效果。这种模式就是小节中通过容器的单例模式实现方式,系统核心服务以单例形式存在,减少了资源消耗。

时间: 2025-01-21 19:08:21

《Android 源码设计模式解析与实战》——第2章,第2.7节Android源码中的单例模式的相关文章

《Android 源码设计模式解析与实战》——第1章,第1.1节优化代码的第一步——单一职责原则

第1章 走向灵活软件之路--面向对象的六大原则Android 源码设计模式解析与实战 1.1 优化代码的第一步--单一职责原则单一职责原则的英文名称是Single Responsibility Principle,缩写是SRP.SRP的定义是:就一个类而言,应该仅有一个引起它变化的原因.简单来说,一个类中应该是一组相关性很高的函数.数据的封装.就像老师在<设计模式之禅>中说的:"这是一个备受争议却又及其重要的原则.只要你想和别人争执.怄气或者是吵架,这个原则是屡试不爽的".

《Android 源码设计模式解析与实战》——第2章,第2.1节单例模式介绍

第2章 应用最广的模式--单例模式Android 源码设计模式解析与实战 2.1 单例模式介绍单例模式是应用最广的模式之一,也可能是很多初级工程师唯一会使用的设计模式.在应用这个模式时,单例对象的类必须保证只有一个实例存在.许多时候整个系统只需要拥有一个全局对象,这样有利于我们协调系统整体的行为.如在一个应用中,应该只有一个ImageLoader实例,这个ImageLoader中又含有线程池.缓存系统.网络请求等,很消耗资源,因此,没有理由让它构造多个实例.这种不能自由构造对象的情况,就是单例模

《Android 源码设计模式解析与实战》——导读

目 录 自序一 自序二 前言 致谢 第1章 走向灵活软件之路--面向对象的六大原则 1.1节优化代码的第一步--单一职责原则1.2节让程序更稳定.更灵活--开闭原则1.3节构建扩展性更好的系统--里氏替换原则1.4节让项目拥有变化的能力--依赖倒置原则1.5节系统有更高的灵活性--接口隔离原则1.6节更好的可扩展性--迪米特原则1.7节总结 第2章 应用最广的模式--单例模式 2.1节单例模式介绍2.2节单例模式的定义2.3节单例模式的使用场景2.4节单例模式UML类图2.5节单例模式的简单示例

《Android 源码设计模式解析与实战》——第2章,第2.8节无名英雄——深入理解LayoutInflater

2.8 无名英雄--深入理解LayoutInflater LayoutInflater在我们的开发中扮演着重要的角色,但很多时候我们都不知道它的重要性,因为它的重要性被隐藏在了Activity.Fragment等组件的光环之下. LayoutInflater是一个抽象类,具体代码如下: public abstract class LayoutInflater { // 代码省略 } 既然是抽象不是具体的,那我们必须把这个深藏功与名的"家伙"找出来!需要先从layoutInflater的

《Android 源码设计模式解析与实战》——第2章,第2.5节单例模式的简单示例

2.5 单例模式的简单示例单例模式是设计模式中比较简单的,只有一个单例类,没有其他的层次结构与抽象.该模式需要确保该类只能生成一个对象,通常是该类需要消耗较多的资源或者没有多个实例的情况.例如,一个公司只有一个CEO.一个应用只有一个Application对象等.下面以公司里的CEO为例来简单演示一下,一个公司可以有几个VP.无数个员工,但是CEO只有一个,请看下面示例. 示例实现代码 package com.dp.example.singleton; // 普通员工 public class

《Android 源码设计模式解析与实战》——第2章,第2.9节运用单例模式

2.9 运用单例模式 在Android应用开发过程中,ImageLoader是我们最为常用的开发工具库之一.Android中最著名的ImageLoader就是Universal-Image-Loader(https://github.com/nostra13/Android-Universal-Image- Loader),它的使用过程大概是这样的: public void initImageLoader(Context context) { // 1. 使用Builder构建ImageLoad

《Android 源码设计模式解析与实战》——第1章,第1.2节让程序更稳定、更灵活——开闭原则

1.2 让程序更稳定.更灵活--开闭原则 开闭原则的英文全称是Open Close Principle,缩写是OCP,它是Java世界里最基础的设计原则,它指导我们如何建立一个稳定的.灵活的系统.开闭原则的定义是:软件中的对象(类.模块.函数等)应该对于扩展是开放的,但是,对于修改是封闭的.在软件的生命周期内,因为变化.升级和维护等原因需要对软件原有代码进行修改时,可能会将错误引入原本已经经过测试的旧代码中,破坏原有系统.因此,当软件需要变化时,我们应该尽量通过扩展的方式来实现变化,而不是通过修

《Android 源码设计模式解析与实战》——第2章,第2.6节单例模式的其他实现方式

2.6 单例模式的其他实现方式 2.6.1 懒汉模式 懒汉模式是声明一个静态对象,并且在用户第一次调用getInstance时进行初始化,而上述的饿汉模式(CEO类)是在声明静态对象时就已经初始化.懒汉单例模式实现如下. public class Singleton { private static Singleton instance; private Singleton () {} public static synchronized Singleton getInstance() { if

《Android 源码设计模式解析与实战》——第1章,第1.5节系统有更高的灵活性——接口隔离原则

1.5 系统有更高的灵活性--接口隔离原则 接口隔离原则英文全称是InterfaceSegregation Principles,缩写是ISP.ISP的定义是:客户端不应该依赖它不需要的接口.另一种定义是:类间的依赖关系应该建立在最小的接口上.接口隔离原则将非常庞大.臃肿的接口拆分成更小的和更具体的接口,这样客户将会只需要知道他们感兴趣的方法.接口隔离原则的目的是系统解开耦合,从而容易重构.更改和重新部署. 接口隔离原则说白了就是,让客户端依赖的接口尽可能地小,这样说可能还是有点抽象,我们还是以