Android中集結了大量的系統管家Manager

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 SYSTEM_SERVICE_MAP =            new HashMap();

原來是一個HashMap, 並且是一個static的私人變數。這表明，SYSTEM_SERVICE_MAP儲存的是一個公用、共用的一定數量的ServiceFetcher。

SYSTEM_SERVICE_MAP儲存的這些ServiceFetcher值是什麼時候初始化的呢？我們後面再說。

（2）我們來看看ServiceFetcher到底是什嗎？

        /**         * Main entrypoint; only override if you don't need caching.         */        public Object getService(ContextImpl ctx) {            ArrayList 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
IME的管理服務程式，包括何時使能IME，切換IME等等。


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的方式放在案頭上，這就是這套管理和服務的介面