2. 程式人生 > >Android 外掛化原理解析——Service的外掛化

Android 外掛化原理解析——Service的外掛化

阿新 • • 發佈：2019-01-18

在 Activity生命週期管理 以及 廣播的管理 中我們詳細探討了Android系統中的Activity、BroadcastReceiver元件的工作原理以及它們的外掛化方案，相信讀者已經對Android Framework和外掛化技術有了一定的瞭解；本文將探討Android四大元件之一——Service元件的外掛化方式。

與Activity, BroadcastReceiver相比，Service元件的不同點在哪裡呢？我們能否用與之相同的方式實現Service的外掛化？如果不行，它們的差別在哪裡，應該如何實現Service的外掛化？

我們接下來將圍繞這幾個問題展開，最終給出Service元件的外掛化方式；閱讀本文之前，可以先clone一份 

understand-plugin-framework，參考此專案的 service-management 模組。另外，外掛框架原理解析系列文章見索引。

Service工作原理

連Service的工作原理都不瞭解，談何外掛化？知己知彼。

Service分為兩種形式：以startService啟動的服務和用bindService繫結的服務；由於這兩個過程大體相似，這裡以稍複雜的bindService為例分析Service元件的工作原理。

繫結Service的過程是通過Context類的bindService完成的，這個方法需要三個引數：第一個引數代表想要繫結的Service的Intent，第二個引數是一個ServiceConnetion，我們可以通過這個物件接收到Service繫結成功或者失敗的回撥；第三個引數則是繫結時候的一些FLAG；關於服務的基本概念，可以參閱 

官方文件。（現在漢化了哦，E文不好童鞋的福音）

Context的具體實現在ContextImpl類，ContextImpl中的bindService方法直接呼叫了bindServiceCommon方法，此方法原始碼如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

private boolean bindServiceCommon(Intent service, ServiceConnection conn, int flags,
 

        UserHandle user) {
    IServiceConnection sd;
    if (conn == null) {
        throw new IllegalArgumentException("connection is null");
    }
    if (mPackageInfo != null) {
        // important
        sd = mPackageInfo.getServiceDispatcher(conn, getOuterContext(),
                mMainThread.getHandler(), flags);
    } else {
        throw new RuntimeException("Not supported in system context");
    }
    validateServiceIntent(service);
    try {
        IBinder token = getActivityToken();
        if (token == null && (flags&BIND_AUTO_CREATE) == 0 && mPackageInfo != null
                && mPackageInfo.getApplicationInfo().targetSdkVersion
                < android.os.Build.VERSION_CODES.ICE_CREAM_SANDWICH) {
            flags |= BIND_WAIVE_PRIORITY;
        }
        service.prepareToLeaveProcess();
        int res = ActivityManagerNative.getDefault().bindService(
            mMainThread.getApplicationThread(), getActivityToken(), service,
            service.resolveTypeIfNeeded(getContentResolver()),
            sd, flags, getOpPackageName(), user.getIdentifier());
        if (res < 0) {
            throw new SecurityException(
                    "Not allowed to bind to service " + service);
        }
        return res != 0;
    } catch (RemoteException e) {
        throw new RuntimeException("Failure from system", e);
    }
}

大致觀察就能發現這個方法最終通過ActivityManagerNative藉助AMS進而完成Service的繫結過程，在跟蹤AMS的bindService原始碼之前，我們關注一下這個方法開始處建立的sd變數。這個變數的型別是IServiceConnection，如果讀者還有印象，我們在 廣播的管理 一文中也遇到過類似的處理方式——IIntentReceiver；所以，這個IServiceConnection與IApplicationThread以及IIntentReceiver相同，都是ActivityThread給AMS提供的用來與之進行通訊的Binder物件；這個介面的實現類為LoadedApk.ServiceDispatcher。

這個方法最終呼叫了ActivityManagerNative的bindService，而這個方法的真正實現在AMS裡面，原始碼如下：

1
2
3
4
5
6
7
8
9
10

public int bindService(IApplicationThread caller, IBinder token, Intent service,
        String resolvedType, IServiceConnection connection, int flags, String callingPackage,
        int userId) throws TransactionTooLargeException {
    enforceNotIsolatedCaller("bindService");
    // 略去引數校檢
    synchronized(this) {
        return mServices.bindServiceLocked(caller, token, service,
                resolvedType, connection, flags, callingPackage, userId);
    }
}

bindService這個方法相當簡單，只是做了一些引數校檢之後直接呼叫了ActivityServices類的bindServiceLocked方法：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44

int bindServiceLocked(IApplicationThread caller, IBinder token, Intent service,
        String resolvedType, IServiceConnection connection, int flags,
        String callingPackage, int userId) throws TransactionTooLargeException {
    final ProcessRecord callerApp = mAm.getRecordForAppLocked(caller);
    // 引數校檢，略

    ServiceLookupResult res =
        retrieveServiceLocked(service, resolvedType, callingPackage,
                Binder.getCallingPid(), Binder.getCallingUid(), userId, true, callerFg);
    // 結果校檢， 略
    ServiceRecord s = res.record;

    final long origId = Binder.clearCallingIdentity();

    try {
        // ... 不關心， 略

        mAm.startAssociationLocked(callerApp.uid, callerApp.processName,
                s.appInfo.uid, s.name, s.processName);

        AppBindRecord b = s.retrieveAppBindingLocked(service, callerApp);
        ConnectionRecord c = new ConnectionRecord(b, activity,
                connection, flags, clientLabel, clientIntent);
        IBinder binder = connection.asBinder();
        ArrayList<ConnectionRecord> clist = s.connections.get(binder);

        // 對connection進行處理， 方便存取，略
        clist.add(c);

        if ((flags&Context.BIND_AUTO_CREATE) != 0) {
            s.lastActivity = SystemClock.uptimeMillis();
            if (bringUpServiceLocked(s, service.getFlags(), callerFg, false) != null) {
                return 0;
            }
        }

        // 與BIND_AUTO_CREATE不同的啟動FLAG，原理與後續相同，略

    } finally {
        Binder.restoreCallingIdentity(origId);
    }

    return 1;
}

這個方法比較長，我這裡省去了很多無關程式碼，只列出關鍵邏輯；首先它通過retrieveServiceLocked方法獲取到了intent匹配到的需要bind到的Service元件res；然後把ActivityThread傳遞過來的IServiceConnection使用ConnectionRecord進行了包裝，方便接下來使用；最後如果啟動的FLAG為BIND_AUTO_CREATE，那麼呼叫bringUpServiceLocked開始建立Service，我們跟蹤這個方法：（非這種FLAG的程式碼已經省略，可以自行跟蹤）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44

private final String bringUpServiceLocked(ServiceRecord r, int intentFlags, boolean execInFg,
        boolean whileRestarting) throws TransactionTooLargeException {

    // 略。。

    final boolean isolated = (r.serviceInfo.flags&ServiceInfo.FLAG_ISOLATED_PROCESS) != 0;
    final String procName = r.processName;
    ProcessRecord app;

    if (!isolated) {
        app = mAm.getProcessRecordLocked(procName, r.appInfo.uid, false);
        if (app != null && app.thread != null) {
            try {
                app.addPackage(r.appInfo.packageName, r.appInfo.versionCode, mAm.mProcessStats);
                // 1. important !!!
                realStartServiceLocked(r, app, execInFg);
                return null;
            } catch (TransactionTooLargeException e) {
                throw e;
            } catch (RemoteException e) {
                Slog.w(TAG, "Exception when starting service " + r.shortName, e);
            }

        }
    } else {
        app = r.isolatedProc;
    }

    // Not running -- get it started, and enqueue this service record
    // to be executed when the app comes up.
    if (app == null) {
        // 2. important !!!
        if ((app=mAm.startProcessLocked(procName, r.appInfo, true, intentFlags,
                "service", r.name, false, isolated, false)) == null) {
            bringDownServiceLocked(r);
            return msg;
        }
        if (isolated) {
            r.isolatedProc = app;
        }
    }
    // 略。。
    return null;
}

這個方案同樣也很長，但是實際上非常簡單：注意我註釋的兩個important的地方，如果Service所在的程序已經啟動，那麼直接呼叫realStartServiceLocked方法來真正啟動Service元件；如果Service所在的程序還沒有啟動，那麼先在AMS中記下這個要啟動的Service元件，然後通過startProcessLocked啟動新的程序。

我們先看Service程序已經啟動的情況，也即realStartServiceLocked分支：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

private final void realStartServiceLocked(ServiceRecord r,
        ProcessRecord app, boolean execInFg) throws RemoteException {

    // 略。。

    boolean created = false;
    try {
        synchronized (r.stats.getBatteryStats()) {
            r.stats.startLaunchedLocked();
        }
        mAm.ensurePackageDexOpt(r.serviceInfo.packageName);
        app.forceProcessStateUpTo(ActivityManager.PROCESS_STATE_SERVICE);
        app.thread.scheduleCreateService(r, r.serviceInfo,
                mAm.compatibilityInfoForPackageLocked(r.serviceInfo.applicationInfo),
                app.repProcState);
        r.postNotification();
        created = true;
    } catch (DeadObjectException e) {
        mAm.appDiedLocked(app);
        throw e;
    } finally {
        // 略。。
    }

    requestServiceBindingsLocked(r, execInFg);

    // 不關心，略。。
}

這個方法首先呼叫了app.thread的scheduleCreateService方法，我們知道，這是一個IApplicationThread物件，它是App所在程序提供給AMS的用來與App程序進行通訊的Binder物件，這個Binder的Server端在ActivityThread的ApplicationThread類，因此，我們跟蹤ActivityThread類，這個方法的實現如下：

1
2
3
4
5
6
7
8
9
10

public final void scheduleCreateService(IBinder token,
        ServiceInfo info, CompatibilityInfo compatInfo, int processState) {
    updateProcessState(processState, false);
    CreateServiceData s = new CreateServiceData();
    s.token = token;
    s.info = info;
    s.compatInfo = compatInfo;

    sendMessage(H.CREATE_SERVICE, s);
}

它不過是轉發了一個訊息給ActivityThread的H這個Handler，H類收到這個訊息之後，直接呼叫了ActivityThread類的handleCreateService方法，如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

private void handleCreateService(CreateServiceData data) {
    unscheduleGcIdler();

    LoadedApk packageInfo = getPackageInfoNoCheck(
            data.info.applicationInfo, data.compatInfo);
    Service service = null;
    try {
        java.lang.ClassLoader cl = packageInfo.getClassLoader();
        service = (Service) cl.loadClass(data.info.name).newInstance();
    } catch (Exception e) {
    }

    try {
        ContextImpl context = ContextImpl.createAppContext(this, packageInfo);
        context.setOuterContext(service);

        Application app = packageInfo.makeApplication(false, mInstrumentation);
        service.attach(context, this, data.info.name, data.token, app,
                ActivityManagerNative.getDefault());
        service.onCreate();
        mServices.put(data.token, service);
        try {
            ActivityManagerNative.getDefault().serviceDoneExecuting(
                    data.token, SERVICE_DONE_EXECUTING_ANON, 0, 0);
        } catch (RemoteException e) {
            // nothing to do.
        }
    } catch (Exception e) {
    }
}

看到這段程式碼，是不是似曾相識？！沒錯，這裡與Activity元件的建立過程如出一轍！所以這裡就不贅述了，可以參閱 Activity生命週期管理。

需要注意的是，這裡Service類的建立過程與Activity是略微有點不同的，雖然都是通過ClassLoader通過反射建立，但是Activity卻把建立過程委託給了Instrumentation類，而Service則是直接進行。

OK，現在ActivityThread裡面的handleCreateService方法成功創建出了Service物件，並且呼叫了它的onCreate方法；到這裡我們的Service已經啟動成功。scheduleCreateService這個Binder呼叫過程結束，程式碼又回到了AMS程序的realStartServiceLocked方法。這裡我們不得不感嘆Binder機制的精妙，如此簡潔方便高效的跨程序呼叫，在程序之間來回穿梭，遊刃有餘。

realStartServiceLocked方法的程式碼如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

private final void realStartServiceLocked(ServiceRecord r,
        ProcessRecord app, boolean execInFg) throws RemoteException {

    // 略。。

    boolean created = false;
    try {
        synchronized (r.stats.getBatteryStats()) {
            r.stats.startLaunchedLocked();
        }
        mAm.ensurePackageDexOpt(r.serviceInfo.packageName);
        app.forceProcessStateUpTo(ActivityManager.PROCESS_STATE_SERVICE);
        app.thread.scheduleCreateService(r, r.serviceInfo,
                mAm.compatibilityInfoForPackageLocked(r.serviceInfo.applicationInfo),
                app.repProcState);
        r.postNotification();
        created = true;
    } catch (DeadObjectException e) {
        mAm.appDiedLocked(app);
        throw e;
    } finally {
        // 略。。
    }

    requestServiceBindingsLocked(r, execInFg);

    // 不關心，略。。
}

這個方法在完成scheduleCreateService這個binder呼叫之後，執行了一個requestServiceBindingsLocked方法；看方法名好像於「繫結服務」有關，它簡單地執行了一個遍歷然後呼叫了另外一個方法：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

private final boolean requestServiceBindingLocked(ServiceRecord r, IntentBindRecord i,
        boolean execInFg, boolean rebind) throws TransactionTooLargeException {
    if (r.app == null || r.app.thread == null) {
        return false;
    }
    if ((!i.requested || rebind) && i.apps.size() > 0) {
         
 

            
  

           

              
              

            

            
相關推薦

			   
            
            
            
 

    


    
    
Android 外掛化原理解析——Service的外掛化

     
 
                

在 Activity生命週期管理 以及 廣播的管理 中我們詳細探討了Android系統中的Activity、BroadcastReceiver元件的工作原理以及它們的外掛化方案，相信讀者已經對Android
 Framework和外掛化技術有了一定的瞭解；本文將探討 



  
 

    


    
    
Android外掛化原理解析——ContentProvider的外掛化

     
 
目前為止我們已經完成了Android四大元件中Activity，Service以及BroadcastReceiver的外掛化，這幾個元件各不相同，我們根據它們的特點定製了不同的外掛化方案；那麼對於ContentProvider，它又有什麼特點？應該如何實現它的外掛化？
與Activity，Broadcast 



  
 

    


    
    
Android外掛化原理解析——Hook機制之Binder Hook

     
 
                

Android系統通過Binder機制給應用程式提供了一系列的系統服務，諸如ActivityManagerService，ClipboardManager， AudioManager等；這些廣泛存在系統服務給應用程式提供了諸如任務管理，音訊，視訊等異常強大的功能。

外掛 



  
 

    


    
    
Android外掛化原理解析--外掛化載入機制

     
 
                上文 Activity生命週期管理 中我們地完成了『啟動沒有在AndroidManifest.xml中顯式宣告的Activity』的任務；通過Hook AMS和攔截ActivityThread中H類對於元件排程我們成功地繞過了AndroidMAnifest.xml的限制。但是 



  
 

    


    
    
Android 外掛化原理解析——外掛載入機制

     
 
                

上文 Activity生命週期管理 中我們地完成了『啟動沒有在AndroidManifest.xml中顯式宣告的Activity』的任務；通過Hook AMS和攔截ActivityThread中H類對於元件排程我們成功地繞過了AndroidMAnifest.xml的限 



  
 

    


    
    
Android外掛化原理解析——Hook機制之動態代理

     
 


使用代理機制進行API Hook進而達到方法增強是框架的常用手段，比如J2EE框架Spring通過動態代理優雅地實現了AOP程式設計，極大地提升了Web開發效率；同樣，外掛框架也廣泛使用了代理機制來增強系統API從而達到外掛化的目的。本文將帶你瞭解基於動態代理的Hook機制。
閱讀本文之前，可以先clo 



  
 

    


    
    
Android 掛逼 修煉之行---支付寶螞蟻森林能量自動收取外掛開發原理解析

     
  
  
  
 分享一下我老師大神的人工智慧教程！零基礎，通俗易懂！http://blog.csdn.net/jiangjunshow
 
 也歡迎大家轉載本篇文章。分享知識，造福人民，實現我們中華民族偉大復興！
 
 
          



  
 

    


    
    
Android支付寶螞蟻森林能量自動收取外掛開發原理解析

     
  
 
 轉發一篇高技術含量的文章，原文網址為：https://www.52pojie.cn/thread-794312-1-1.html 
   
 一、前言關於支付寶的螞蟻森林能量收取這個非常有重大意義的東西，本人表示非常認同，這個網上也是一直有人覺得馬雲是一個非常有遠見的男人，的確雖然很多人覺 



  
 

    


    
    
gRPC快速入門（二）——Protobuf序列化原理解析

     
 gRPC快速入門（二）——Protobuf序列化原理解析 
一、Protobuf序列化原理簡介 
1、序列化 
序列化是將資料結構或物件轉換成二進位制位元組流的過程。Protobuf對於不同的欄位型別採用不同的編碼方式和資料儲存方式對訊息欄位進行序列化，以確保得到高效緊湊的資料壓縮。Protobuf序列化過程 



  
 

    


    
    
hessian原理解析三(序列化協議)

     
 
                
1、序列化
　　序列化：將資料結構或物件轉換成二進位制串的過程
　　反序列化：將在序列化過程中所生成的二進位制串轉換成資料結構或者物件的過程
      目的：儲存物件狀態或用於網路傳輸
2、hessian 序列化協議 1.0 參考官方文件：http://hessian.c 



  
 

    


    
    
Android懸浮窗原理解析(Window)[源碼]

     
 tco   inflate   情況   tint   input   tdi   scree   list   接收   懸浮窗，在大多數應用中還是很少見的，目前我們接觸到的懸浮窗，差不多都是一些系統級的應用軟件，例如：360安全衛士，騰訊手機管家等；在某些服務行業如金融，餐飲等，也會在應用中添加懸浮窗，例 



  
 

    


    
    
Android View繪製原理解析

     
 
							
							
							概述
本篇文章主要講述View是如何在Android原始碼中產生的，以便於我們能夠更好的去自定義一些控制元件，大體上是按照View繪製的流程來走步驟，在追蹤原始碼之前我們先了解幾個基礎知識。來看下面的這張圖：

一張典型的系統View分解圖，一個Activity 



  
 

    


    
    
【android】RxJava1原理解析

     
 
							
							
							


寫在前面

讀了大神的部落格，為了學習，跪著看完再整理了出來，以便加深印象。

RxJava 是什麼，能解決什麼問題


github 官方介紹



  RxJava is a Java VM implementation of Reactive Ext 



  
 

    


    
    
原理解析Service Mesh與ESB、API管理與訊息代理的關係

     
 
							
							
							轉載自公眾號 EAWorld。

作者：Christian Posta  
譯者：海松  
原題：Application Network Functions With ESBs, API Management, and Now.. Service Mesh?

 



  
 

    


    
    
Android訊息機制原理解析

     
 
							
							
							Android訊息機制:主要指Handler的執行機制以及Handler所附帶的MessageQueue和Looper的工作過程。

Handler：主要作用是將一個任務切換到指定的執行緒中去執行。Android中UI控制元件不是執行緒安全的，所以在Androi 



  
 

    


    
    
[轉]遊戲外掛基本原理，遊戲外掛編寫的技術

     
 
                關注公眾號:C++開發前沿,傳送:初級外掛,獲取鬱金香初級外掛視訊教程











遊戲外掛已經深深地影響著眾多網路遊戲玩家,今天在網上看到了一些關於遊戲外掛編寫的技術,於是轉載上供大家參考
　　1、遊戲外掛的原理
　　外掛現在分為好多種，比如模擬鍵盤的，滑鼠的，修 



  
 

    


    
    
Android外掛化原理和實踐 (四) 之 合併外掛中的資源

     
  
 
 
 我們繼續來學習Android外掛化相關知識，還是要圍繞著三個根本問題來展開。在前面兩章中已經講解過第一個根本問題：在宿主中如何去載入外掛以及呼叫外掛中類和元件程式碼。Demo中使用了Service來演示，因為還沒有解決載入外掛中資源的問題，用Activity不好展示。所以本文將要從資源的載入機制 



  
 

    


    
    
Android外掛化原理和實踐 (七) 之 專案實踐

     
  
 
 
 我們在前面一系列文章中已經介紹完了外掛化原理以及三個根本問題的解決方案，本文主要就是作為前面幾篇文章的一個總結，通過專案實踐將前面的知識點串起來使完成一個入門級簡單的外掛化工程以及在實際外掛化開發中遇到的一些總結。 
 實踐 
 我們先通過Android Studio建立一個工程，工程中包括了兩 



  
 

    


    
    
android外掛化原理

     
 
                最近幾年移動開發業界興起了「 外掛化技術 」的旋風，各個大廠都推出了自己的外掛化框架，各種開源框架都評價自身功能優越性，令人目不暇接。隨著公司業務快速發展，專案增多，開發資源卻有限，如何能在有限資源內滿足需求和專案的增長，同時又能快速響應問題和迭代新需求，這就是一個矛盾點。此 



  
 

    


    
    
Android外掛化原理和實踐 (八) 之 注意事項

     
  
 
 
 注意事項 
 關於外掛化的三個根本問題和解決方案就已經全部介紹完畢了，前一篇文章也通過一個入門級的工程來完整地演示了。但是其實目前熱門的外掛化框架也遠不止這些內容，我們在實際開發中也遠不止這麼簡單。前面介紹的所有知識點只是一個入門而已，外掛化雖然帶來了很多便利，但是在開發過程中也增添了不少麻煩和