当前位置: 代码迷 >> Android >> Android的各个管家:ActivityManager仍是AudioManager还是
  详细解决方案

Android的各个管家:ActivityManager仍是AudioManager还是

热度:105   发布时间:2016-04-28 06:21:50.0
Android的各个管家:ActivityManager还是AudioManager还是?

Android中集结了大量的系统管家Manager:比如当你要kill一个后台Processes时候,你会用到ActivityManager;再比如你需要用到系统的声音相关的你需要AudioManager等等。而且获取这些管家对你来说很简单,比如获取一个ActivityManager,你只需要调用当前context的方法getSystemService就可以了:

        final ActivityManager am = (ActivityManager) context                .getSystemService(Context.ACTIVITY_SERVICE);

大家经常用context的方法getSystemService来获取你想要的Manager,你知道为什么任意context实例都能获取Manager吗? 今天又时间,就看看其秘密。

首先,我们知道Context是一个描述一个application的全局的资源和信息的。而Context其实是一个abstract的类,所以是不能直接用的,他的实现类其实是ContextImpl,看看androidd对ContextImpl一段原文介绍:

/** * Common implementation of Context API, which provides the base * context object for Activity and other application components. */
     从上面的意思我们可以知道:ContextImpl其实就是context的实现,application的组件其实继承于他的!所以要研究context,就是要研究ContextImpl。说道这里好像有点跑题了,嘿嘿,下面继续。

    刚才说了,context的方法getSystemService可以获取android系统当前使用的各个Manager,那我们来ContextImpl看看getSystemService在做什么。

    @Override    public Object getSystemService(String name) {        ServiceFetcher fetcher = SYSTEM_SERVICE_MAP.get(name);        return fetcher == null ? null : fetcher.getService(this);    }

这里我们分两点来看:

(1)首先来看看SYSTEM_SERVICE_MAP是什么?

    private static final HashMap<String, ServiceFetcher> SYSTEM_SERVICE_MAP =            new HashMap<String, ServiceFetcher>();
原来是一个HashMap, 并且是一个static的私有变量。这表明,SYSTEM_SERVICE_MAP存储的是一个公共、共用的一定数量的ServiceFetcher。  

SYSTEM_SERVICE_MAP存储的这些ServiceFetcher值是什么时候初始化的呢?我们后面再说。

(2)我们来看看ServiceFetcher到底是什么?

    /**     * Override this class when the system service constructor needs a     * ContextImpl.  Else, use StaticServiceFetcher below.     */    /*package*/ static class ServiceFetcher {        int mContextCacheIndex = -1;        /**         * Main entrypoint; only override if you don't need caching.         */        public Object getService(ContextImpl ctx) {            ArrayList<Object> cache = ctx.mServiceCache;            Object service;
            synchronized (cache) {                if (cache.size() == 0) {                    // Initialize the cache vector on first access.                    // At this point sNextPerContextServiceCacheIndex                    // is the number of potential services that are                    // cached per-Context.                    for (int i = 0; i < sNextPerContextServiceCacheIndex; i++) {                        cache.add(null);                    }                } else {                    service = cache.get(mContextCacheIndex);                    if (service != null) {                        return service;                    }                }                service = createService(ctx);                cache.set(mContextCacheIndex, service);                return service;            }        }
        /**         * Override this to create a new per-Context instance of the         * service.  getService() will handle locking and caching.         */        public Object createService(ContextImpl ctx) {            throw new RuntimeException("Not implemented");        }    }
很简单的一个static class,其中只有两个方法getService和createService:

先来看看createService这个方法:改方法里面没有什么实质的东西,重点我们看看这个方法上面的原文说明:说的很清楚这个方法其实是用来Override的,其目的就是创建一个服务Service.

再来看看getService,从这个方法可以知道:首先是看看ctx.mServiceCache里面是否已经有了这个我们需要的服务Service,如果还没有就调用createService来创建一个。

所以,ServiceFetcher很简单,其实就是对服务Service为方便使用而对其的创建、取用的一个封装类。

所以重点,我们还来到了是如何创建一个服务Service的。

很快,你就会发现在ContextImpl里面有一段static代码,其注册了所有的服务Service:

    static {        registerService(ACCESSIBILITY_SERVICE, new ServiceFetcher() {                public Object getService(ContextImpl ctx) {                    return AccessibilityManager.getInstance(ctx);                }});        registerService(ACCOUNT_SERVICE, new ServiceFetcher() {                public Object createService(ContextImpl ctx) {                    IBinder b = ServiceManager.getService(ACCOUNT_SERVICE);                    IAccountManager service = IAccountManager.Stub.asInterface(b);                    return new AccountManager(ctx, service);                }});        registerService(ACTIVITY_SERVICE, new ServiceFetcher() {                public Object createService(ContextImpl ctx) {                    return new ActivityManager(ctx.getOuterContext(), ctx.mMainThread.getHandler());                }});		...		}
里面都从新了方法createService来创建新的服务对象。

我们最后看看registerService这个方法做了些什么?

    private static void registerService(String serviceName, ServiceFetcher fetcher) {        if (!(fetcher instanceof StaticServiceFetcher)) {            fetcher.mContextCacheIndex = sNextPerContextServiceCacheIndex++;        }        SYSTEM_SERVICE_MAP.put(serviceName, fetcher);    }
SYSTEM_SERVICE_MAP.put(serviceName, fetcher);看到了吗!其实就是讲创建好的 ServiceFetcher 存储在SYSTEM_SERVICE_MAP这个HashMap里面了。
最后,我们来看都有那些Manager服务:
1. EntropyService
熵服务,周期性的加载和保存随机信息。主要是linux开机后,/dev/random的状态可能是可预知的,这样一些需要随机信息的应用程序就可能会有问题。这个无需提供应用程序接口。

2. PowerManagerService –> PowerManager
Android 的电源管理也是很重要的一部分。比如在待机的时候关掉不用的设备,待机时屏幕和键盘背光的关闭,用户操作的时候该打开多少设备等等。

3. ActivityManagerService->ActivityManager
这个是整个Android framework框架中最为核心的一个服务,管理整个框架中任务、进程管理, Intent解析等的核心实现。虽然名为Activity的Manager Service,但它管辖的范围,不只是Activity,还有其他三大组件,和它们所在的进程。也就是说用户应用程序的生命管理,都是由他负责的。

4. TelephonyRegistry->TelephonyManager
电话注册、管理服务模块,可以获取电话的链接状态、信号强度等等。<可以删掉,但要看的大概明白>

5. PackageManagerService -> PackageManager
包括对软件包的解包,验证,安装以及升级等等,对于我们现在不能安装.so文件的问题,应该先从这块着手分析原因。

6. AccountManagerService -> AccountManager
A system service that provides  account, password, and authtoken management for all
accounts on the device。

7. ContentService -> ContentResolver
内容服务,主要是数据库等提供解决方法的服务。

8. BatteryService
监控电池充电及状态的服务,当状态改变时,会广播Intent

9. HardwareService
一般是ring和vibrate的服务程序

10. SensorService -> SensorManager
管理Sensor设备的服务,负责注册client设备及当client需要使用sensor时激活Sensor

11. WindowManagerService -> WindowManager -> PhoneWindowManager
和ActivityManagerService高度粘合
窗口管理,这里最核心的就是输入事件的分发和管理。

12. AlarmManagerService -> AlarmManager
闹钟服务程序

13. BluetoothService -> BluetoothDevice
蓝牙的后台管理和服务程序

14. StatusBarService -> StatusBarManager
负责statusBar上图标的更新、动画等等的服务,服务不大。

15. ClipboardService -> ClipboardManager
和其他系统的clipBoard服务类似,提供复制黏贴功过。

16. InputMethodManagerService -> InputMethodManager
输入法的管理服务程序,包括何时使能输入法,切换输入法等等。

17. NetStatService
手机网络服务

18. ConnectivityService -> ConnectivityManager
网络连接状态服务,可供其他应用查询,当网络状态变化时,也可广播改变。

19. AccessibilityManagerService-> AccessibilityManager
这块可能要仔细看一下,主要是一些View获得点击、焦点、文字改变等事件的分发管理,对整个系统的调试、问题定位等,也需要最这个服务仔细过目一下。

20. NotificationManagerService -> NotificationManager
负责管理和通知后台事件的发生等,这个和statusbar胶黏在一起,一般会在statusbar上添加响应图标。用户可以通过这知道系统后台发生了什么事情。

21. MountService
磁盘加载服务程序,一般要和一个linux daemon程序如vold/mountd等合作起作用,主要负责监听并广播device的mount/unmount/bad removal等等事件。

22. DeviceStorageMonitorService
       监控磁盘空间的服务,当磁盘空间不足10%的时候会给用户警告

23. LocationManagerService -> LocationManager
       要加入GPS服务等,这部分要细看,现在应用中的navigation没响应,可以从此处着手看一下

24. SearchManagerService -> SearchManager
The search manager service handles the search UI, and maintains a registry of searchable activities.

25. Checkin Service(FallbackCheckinService)
貌似checkin service是google提供的包,没有源代码,源码只有fallbackCheckinService

26. WallpaperManagerService -> WallpaperManager
管理桌面背景的服务,深度定制化桌面系统,需要看懂并扩展<同时要兼容>这部分

27. AudioService -> AudioManager
AudioFlinger的上层管理封装,主要是音量、音效、声道及铃声等的管理

28. HeadsetObserver
耳机插拔事件的监控小循环

29. DockObserver
如果系统有个座子,当手机装上或拔出这个座子的话,就得靠他来管理了

30. BackupManagerService -> BackupManager
备份服务

31. AppWidgetService -> AppWidgetManager
Android可以让用户写的程序以widget的方式放在桌面上,这就是这套管理和服务的接口

32. StatusBarPolicy
管理哪个图标该在status bar上显示的策略。


mediaServer服务进程

MediaServer服务基本上都是native的services,mediaServer进程也是在init.rc中启动的,它不是一个daemon进程,这点容易搞混。他也是和systemserver进程类似的系统服务进程,提供应用进程的RPC调用的真正服务代码所运行的位置。其服务都是和媒体录播放有关,主要有三个服务:

AudioFlinger
声音的录播放服务,包括混音等

MediaPlayerService
提供媒体播放服务,opencore是这块的核心模块,对java端的接口在mediaplayer.java

CameraService
提供camera的录制、preview等功能的服务

AudioPolicyService
主要功能有检查输入输出设备的连接状态及系统的音频策略的切换等。

  相关解决方案