由AMS和activityThread的交互理解binder(java层)

在ActivityThread中发现了一个ApplicationThread对象,这个对象是AMS回调app进程的binder服务端;在android的源码中IApplicationThread.aidl是一个aidl接口,android O源码编译,在out/target/common/obj/JAVA_LIBRARIES/framework_intermediates/core/java/android/app/目前下面找到了IApplicationThread.java和IActivityManager.java文件,
IApplicationThread.aidl文件会生成一个IApplicationThread.java文件,实际上在这个文件中主要是
public interface IApplicationThread extends android.os.IInterface {
    aidl的函数声明列表
    public static abstract class Stub extends android.os.Binder implements *.IApplicationThread {
        asInterface静态函数,返回proxy实例对象
        asBinder public函数,返回当前stub
        onTransact public函数,接收数据,调用stub的子类实现的aidl的函数
        private static class Proxy implements *.IApplicationThread {
            asBinder public函数,返回Ibinder实例
            aidl的函数实现,在这些函数里面使用ibinder对象transact发送数据给servie端
        }
    }

我靠是一个interface,并不是class;而且interface2个内部类,stub和proxy,stub是服务端的工作部分,proxy是client使用的代理。
由IActivityManager.attachApplication(mAppThread);说起,
1.IActivityManager是ams的client,在调用attachApplication方法时,会将传入的参数IApplicationThread类型,使用asBinder函数将IApplicationThread转换为stub的接口类型Ibinder,使用binder发送到AMS端,在AMS收到Ibinder对象后,使用asInterface静态函数获取IApplicationThread的client代理对象,那么AMS就获取了ApplicationThread的client端对象,使用这个对象回调到ApplicationThread进程,

实现跨进程通信。这里可以理解为在ApplicationThread端拿到AMS的client代理访问AMS,AMS拿到ApplicationThread的clinet代理访问ApplicationThread。

因此要在app层使用binder通讯,考虑activity和service binder流程注意事项:

1. 毫无疑问需要test.aidl文件

2. 为了实际意义上的跨进程通讯,需要给service指定process属性,确保service和activity不再一个进程

3.在service端,需要将service和aidl文件关联起来,为了使得二者取得联系需要继承abstract test.stub 类,并创建一个实例,在onBiner方法中返回这个实例

4.在client端,使用bindservice启动servie,在callback里面使用返回的IBinder对象作为参数,调用stub的静态方法asInterface,获取服务端在client的代理,使用这个代理直接调用aidl的方法,就可以实现跨进程调用。



基于http://blog.youkuaiyun.com/jelly_fang/article/details/50488915这个blog看了下细节

研究下bindservice究竟在做什么?
bindservice的过程分析(多进程模型下):
1.bindservice在启动进程中创建一个IServiceConnection(作为ams回调的service端)
2.binder通信将IServiceConnection发送到ams bindservice,
3.ams socket通信,Zygote启动art虚拟机进程
4.art进程binder 到ams启动app层对应的service代码(这里art进程和ams进程来回binder交互)
5.在art进程调用service的onbind方法,获取serviec 代码中实现的IBinder对象,通过binder发送给AMS
6.AMS找到IServiceConnection对象,binder到初始的启动进程中,一路回调到onServiceConnected方法,
7.启动进程的通过onServiceConnected获取到IBinder对象,使用service对应的Stub.asInterface(binder)方法获取service的proxy对象,使用proxy对象实现了跨进程通信为什么拿着IBinder不可以直接调用service的函数(需要解读binder模块的数据发送实现,才可以具体解释):
不过根据虚拟机内存区域的构成可以分析:因为类对象的方法一般保存在方法区,类对象中保存的一般都只是方法对应的地址,方法调用就是直接跳转到对应方法的地址执行;而经过binder通许后,进程切换了,继续使用前一个进程的地址来执行方法必然是非法的,因为不同进程是运行在不同的地址空间中的。保存的数据信息是可以拷贝,正常读取,但是如果是一些地址信息跨进程拷贝了实际上也是没有意义的。
client:_data.writeStrongBinder((((caller!=null))?(caller.asBinder()):(null)));
service:_arg0 = android.app.IApplicationThread.Stub.asInterface(data.readStrongBinder());

client端的数据经过binder发送后,发送对象是IBinder使用的writeStrongBinder方法,发送过去的东西到了service端即使依然是一个Ibinder对象,但是代表的含义应该有了改变,并不是原来的对象,使用这个对象去访问service的方法,必然是非法的。。


PS:发现一个可以跨进程发送消息的类Messenger 
https://www.cnblogs.com/lzjsky/p/4938256.html这个链接包含例子。


<think>我们正在讨论Android系统中的两个核心概念:ActivityRecordActivityThread。根据提供的引用内容相关知识,我将详细解释它们的区别各自的作用。首先,从引用[3]中我们知道,ActivityRecord是ATMS(ActivityTaskManagerService)用来记录每个Activity的信息的数据结构。它包含Activity的状态、所属进程等详细信息。而ActivityThread(引用[4])是应用程序的主线程,负责管理应用程序组件的生命周期消息循环。###ActivityRecord-**定义**:ActivityRecord是系统服务端(ATMS)中代表一个Activity实例的数据结构。每个启动的Activity都会对应一个ActivityRecord对象。-**作用**:-记录Activity的详细信息,如包名、类名、启动模式、任务栈(Task)信息等。-管理Activity的生命周期状态(如created,started,resumed等)。-维护Activity在任务栈(Task)中的位置(引用[1][3]提到,ActivityRecord被组织在Task中,Task具有栈的特性)。-**存在位置**:ActivityRecord存在于系统服务端(system_server进程)中,由ATMS管理。###ActivityThread-**定义**:ActivityThread是应用程序进程的主线程,也是应用程序的入口点。它负责执行应用程序代码,并管理应用程序组件的生命周期。-**作用**:-**管理应用程序组件的生命周期**(引用[4]):通过内部类ApplicationThread(继承自IApplicationThread.Stub,是一个Binder对象)与AMS(或ATMS)通信,接收系统服务发来的生命周期回调指令,然后执行相应的生命周期方法(如Activity的onCreate、onStart等)。-**维护消息循环**(引用[4]):包含一个Looper,处理主线程的消息队列,用于分发事件(如用户输入事件、生命周期回调等)。-**处理系统回调**(引用[4]):通过ApplicationThread接收系统服务发来的回调,然后转发给主线程处理。-**存在位置**:ActivityThread运行在应用程序进程中。###两者区别1.**所在进程不同**:-ActivityRecord位于系统服务进程(system_server)。-ActivityThread位于应用程序进程。2.**职责不同**:-ActivityRecord是服务端对Activity的抽象,用于记录Activity的状态任务栈信息,以便系统服务进行管理(如任务栈管理、生命周期调度)。-ActivityThread是应用程序进程的主线程,负责执行Activity的生命周期方法其他应用代码。3.**交互方式**:-当需要启动一个Activity时,ATMS(服务端)会创建或复用ActivityRecord,然后通过Binder调用应用程序进程的ApplicationThread(ActivityThread的内部类)来通知客户端执行相应的生命周期方法。-例如,当ATMS决定启动一个Activity时,它会通过IApplicationThread.scheduleLaunchActivity()方法通知应用程序进程。然后ActivityThread会调用handleLaunchActivity()方法,最终执行Activity的onCreate()、onStart()等方法(引用[2]展示了handleResumeActivityperformRestartActivity的调用流程)。###交互流程示例(启动Activity)1.**服务端(ATMS)**:-创建ActivityRecord,并确定其任务栈(Task)。-通过IApplicationThread接口(即ApplicationThread的Binder代理)向客户端发送消息(如scheduleLaunchActivity)。2.**客户端(应用程序进程)**:-ApplicationThread收到scheduleLaunchActivity调用,通过Handler将消息发送到主线程(ActivityThread)。-ActivityThread在handleLaunchActivity()方法中:-创建Activity实例(通过反射)。-调用Activity的onCreate()、onStart()等方法。-最后在handleResumeActivity()中调用onResume()(引用[2])。###总结|**特性**|**ActivityRecord**|**ActivityThread**||------------------|----------------------------------------------------|----------------------------------------------------||所在进程|系统服务进程(system_server)|应用程序进程||主要职责|记录Activity状态,管理任务栈位置|执行应用代码,管理组件生命周期,处理主线程消息循环||生命周期管理角色|服务端调度|客户端执行||数据结构/类|数据结构(服务端)|类(应用程序主线程)||交互方式|通过BinderIApplicationThread)通知ActivityThread|通过Handler处理来自ApplicationThread的消息|>**关键点**:ActivityRecord是服务端对Activity的表示,而ActivityThread是客户端执行实际代码的线程。两者通过Binder机制(ApplicationThread)协同完成Activity的生命周期管理[^1][^3][^4]。---§§相关问题§§1.ActivityRecord与ActivityClientRecord有何关联?2.ApplicationThread如何将系统服务端的调用转发给ActivityThread?3.ATMS如何通过ActivityRecord管理Activity的生命周期状态?4.在应用程序进程销毁重建时,ActivityThread如何恢复ActivityRecord信息?</think>### Android ActivityRecord 与 ActivityThread 的区别及各自作用 #### **1. ActivityRecord(系统服务端组件)** **定位**:系统服务端(ATMS)管理 Activity 的核心数据结构,存在于 `system_server` 进程。 **核心作用**: - **记录 Activity 元数据** 存储 Activity 的包名、类名、启动模式(如 `singleTask`)、任务栈(Task)归属等信息[^1][^3]。 - **管理任务栈关系** 通过 `Task` 容器组织多个 ActivityRecord,实现栈式管理(先进后出)[^3]: ```java // 伪代码:Task 中的 ActivityRecord 链表 class Task { List<ActivityRecord> mActivities; // 按启动顺序存储 void addActivity(ActivityRecord r) { mActivities.add(r); } } ``` - **维护生命周期状态** 跟踪 Activity 的状态机(如 `RESUMED`/`PAUSED`),供 ATMS 决策栈操作[^1][^3]。 - **跨进程通信中介** 作为 Binder 通信的标识,ATMS 通过 ActivityRecord 定位目标 Activity[^3]。 > **本质**:系统服务端对 Activity 的**抽象描述**,不包含业务逻辑。 --- #### **2. ActivityThread(应用进程主线程)** **定位**:应用程序的主线程入口,存在于**每个应用进程**。 **核心作用**: - **执行组件生命周期** 直接调用 Activity 的生命周期方法[^2][^4]: ```java // Android 14 源码示例 public void handleResumeActivity(...) { performRestartActivity(r); // → r.activity.performStart() r.activity.performResume(); // 执行 onResume() } ``` - **维护消息循环** 通过 `Looper` 处理事件(如点击事件、生命周期回调)[^4]: ```mermaid graph LR A[系统回调] --> B(ApplicationThread) B --> C[Handler] C --> D[ActivityThread主线程] D --> E[执行生命周期方法] ``` - **桥接系统服务** 通过内部类 `ApplicationThread`(继承 `IApplicationThread.Stub`)接收 ATMS 指令[^4][^5]: ```java // Binder 通信接口 class ApplicationThread extends IApplicationThread.Stub { void scheduleLaunchActivity(...) { /* 转发启动指令 */ } void scheduleResumeActivity(...) { /* 转发恢复指令 */ } } ``` > **本质**:应用进程的**执行引擎**,负责运行实际业务代码。 --- ### 关键区别总结 | **维度** | **ActivityRecord** | **ActivityThread** | |------------------|---------------------------------------------|-----------------------------------------| | **所在进程** | 系统服务进程 (`system_server`) | 应用进程 (每个应用独立) | | **职责** | 记录元数据、管理任务栈关系 | 执行生命周期方法、处理应用逻辑 | | **数据/行为** | 数据结构(无代码逻辑) | 线程(包含消息循环代码执行能力) | | **生命周期角色** | 状态记录者 | 状态执行者 | | **交互方式** | 通过 Binder 标识 Activity | 通过 Binder 接收系统指令 | > **协同流程示例**: > 当 ATMS 决定启动 Activity 时: > 1. 创建 `ActivityRecord` 并关联 Task > 2. 通过 `ApplicationThread` 通知目标应用的 `ActivityThread` > 3. `ActivityThread` 执行 `onCreate()` → `onStart()` → `onResume()`[^2][^4] ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值