微信号:baobaospace

介绍:本公众号覆盖Android、iOS、设计模式、敏捷流程等多个领域.本人技术博客:http://www.cnblogs.com/Jax/

写给Android App开发人员看的Android底层知识(2)

2017-05-21 10:25 包建强

大家对我的文章感兴趣,可以加我的微信16230091,或者关注我的公众号。

我们这个系列的宗旨是尽量不贴代码,多画图。上篇文章我们讲完了Binder和AIDL的原理,接下来看Binder在实际中的应用,也就是我们最看得见摸得着的Activity与AMS的通信。

 我们从App是怎么启动的讲起来,篇幅很长,今天这篇文章只讲一部分。


(五)AMS

如果站在四大组件的角度来看,AMS就是Binder中的Server

       AMS全称是ActivityManagerService,看字面意思是管理Activity的,但其实四大组件都归它管。估计是Android底层开发人员先写了ActivityManagerService用来管理Activity,后来写ServiceReceiverCP的时候发现代码都差不多,于是就全都用ActivityManagerService,但是却忘记改名字了——我也是猜的,纯属八卦。

 

       由此而说到了插件化,我记得16年和Lody、张勇、林光亮一起吃夜宵的时候,我当时问了困惑已久的两个问题:

       1App的安装过程,为什么不把apk解压缩到本地,这样读取图片就不用每次从apk包中读取了——这个问题,我们放到PMS那一节再详细说。

       2)为什么Hook永远是在BinderClient端,也就是四大组件这边,而不是在AMS那一侧进行Hook

 

       这里要说清楚第二个问题。就拿Android剪切板举例吧。前面说过,这也是个Binder服务。

       AMS要负责和所有App的四大组件进行通信,也真够他忙的。如果在一个App中,在AMS层面把剪切板功能给篡改了,那会导致Android系统所有的剪切板功能被篡改——这就是病毒了,如果是这样的话,Android系统早就死翘翘了。所以Android系统不允许我们这么做。

我们只能在AMS的另一侧,Client端,也就是四大组件这边做篡改,这样即使我们把剪切板功能篡改了,也只影响篡改代码所在的App,在别的App中,剪切板功能还是正常的。

 

       关于AMS我们就说这么多,下面介绍四大组件时,会反复提到四大组件和AMS的跨进程通信。

 

       (六)Activity 1

       对于做App的开发人员而言,Activity是四大组件中用的最多的,也是最复杂的,我这里只讲Activity的启动和通信原理。还有一些相关的概念,比如说ViewLooperIntentResource,我以后另起章节来介绍。

 

       注:我对四大组件的分析,都是基于罗升阳的那本分析Android底层的书,我把其中罗列的大部分代码都删掉了,只保留那些对App开发人员有用的一些代码片段和一些关键类名,并融入了我对四大组件的理解。

 

 

       1)首先要搞清,App是怎么启动的。

       在手机屏幕上点击某个AppIcon,假设就是斗鱼App吧,这个App的首页(或引导页)就出现在我们面前了。这个看似简单的操作,背后经历了ActivityAMS的反反复复的通信过程。

       首先要搞清楚,在手机屏幕上点击Appicon快捷图标,此时手机屏幕就是一个Activity,而这个Activity所在的App,业界称之为LauncherLauncher是手机系统厂商提供的,类似小米华为这样的手机,比拼的就是谁的Launcher绚丽和人性化。

       Launcher这个App,其实和我们做的各类应用类App没有什么不同,我们大家用过华为、小米之类的手机,预装App以及我们下载的各种App,都显示在Launcher上,每个App表现为一个IconIcon多了可以分页,可以分组,此外,Launcher也会发起网络请求,调用天气的数据,显示在屏幕上,所谓的人性化界面。

还记得我们在开发一款App时,在Manifest文件中是怎么定义默认启动Activity的么?如下所示:



Launcher中为每个Appicon提供了启动这个App所需要的Intent信息,如下所示(比如说斗鱼的包名是):

       actionandroid.intent.action.MAIN

       category:android.intent.category.LAUNCHER

       cmp:斗鱼的包名+ 首页Activity

 

       这些信息是App安装(或Android系统启动)的时候,PackageManagerService从斗鱼的apk包的manifest文件中读取到的。

 

       所以点击icon就启动了斗鱼App中的首页。

 

       2)启动App哪有那么简单

       前面介绍的只是App启动的一个最简单的概述。

仔细看,我们会发现,Launcher和斗鱼是两个不同的App,他们位于不同的进程中,它们之间的通信是通过Binder完成的——这时候AMS出场了。

 

       仍然以启动斗鱼App为例子,整体流程是:

  1. Launcher通知AMS,要启动斗鱼App,而且指定要启动斗鱼的哪个页面(也就是首页)。

  2. AMS通知Launcher,好了我知道了,没你什么事了,同时,把要启动的首页记下来。

  3. Launcher当前页面进入Paused状态,然后通知AMS,我睡了,你可以去找斗鱼App了。

  4. AMS检查斗鱼App是否已经启动了。是,则唤起斗鱼App即可。否,就要启动一个新的进程。AMS在新进程中创建一个ActivityThread对象,启动其中的main函数。

  5. 斗鱼App启动后,通知AMS,说我启动好了。

  6. AMS翻出之前在第二步存的值,告诉斗鱼App,启动哪个页面。

  7. 斗鱼App启动首页,创建Application,创建Context并与首页Activity关联。然后调用首页ActivityonCreate函数。

 

至此启动流程完成,分成两部分,1-3步,LauncherAMS相互通信,而后面几步,斗鱼AppAMS相互通信。

 

这会牵扯一堆类进来,列举如下,在接下来的分析中,我们都会遇到:

  • Instrumentation

  • ActivityThread

  • H

  • LoadedApk

  • AMS

  • ActivityManagerNativeActivityManagerProxy

  • ApplicationThreadApplicationThreadProxy

 

 

1阶段 Launcher通知AMS


这是我根据老罗那本书中对Activity的分析,自己手绘的UML图,一共七张,也就是Activity启动所经历的七个阶段。建议各位读者也亲自手绘一遍,从而就加深理解。

 

  • 1步、第2

从上图中我们看到,点击Launcher上的斗鱼Appicon快捷图标,这时会调用LauncherstartActivitySafely方法,其实还是会调用ActivitystartActivity方法,intent中带着要启动斗鱼App所需要的关键信息,如下所示:

       action= “android.intent.action.MAIN”

       category= “android.intent.category.LAUNCHER”

       cmp= “com.douyu.activity.MainActivity”

 

       3行代码是我猜的,就是斗鱼AppMainfest文件中指定为首页的那个Activity。这样,我们终于明白,为什么在Mainfest中,给首页指定actioncategory了。在app的安装过程中,会把这个信息“记录”在Launcher的斗鱼启动快捷图标中。关于App的安装过程,我会在后面的文章详细介绍。

 

       startActivity这个方法,如果我们看它的实现,会发现它调来调去,经过一系列startActivity的重载方法,最后会走到startActivityForResult方法。


我们知道startActivityForResult需要两个参数,一个是intent,另一个是code,这里code-1,表示Launcher才不关心斗鱼的App是否启动成功了呢。

      

 

       3步:startActivityForResult

       Activity内部会保持一个对Instrumentation的引用,但凡是做过App单元测试的同学,对这个类都很熟悉,称之为仪表盘。

       startActivityForResult方法的实现中,会调用InstrumentationexecStartActivity方法:



看到这里,我们发现有个mMainThread变量,这是一个ActivityThread类型的变量。

       这个家伙的来头可不小。

ActivityThread,就是主线程,也就是UI线程,它是在App启动时创建的,它代表了App应用程序。

啥?ActivityThread代表了App应用程序,那Application类岂不是被架空了?其实,Application对我们App开发人员来说也许很重要,但是在Android系统中还真的没那么重要,他就是个上下文。Activity不是有个Context上下文吗?Application就是整个ActivityThread的上下文。

ActivityThread则没有那么简单了。它里面有main函数。

 

我们知道大部分程序都有main函数,比如javaC#,远了不说,iPhoneApp用到的Objective-C,也有main函数,那么Androidmain函数藏在哪里?就在ActivityThread中,如下所示,代码太多,我只截取了一部分:



又有人会问?不是说谁写的程序,谁就要提供main函数,作为入口吗?但Android App却不是这样的。Android Appmain函数,在ActivityThread里面,而这个类是Android系统提供的底层类,不是我们提供的。

       所以这就是Andoid有趣的地方。AndroidApp的入口是Mainifest中定义默认启动Activity。这是由Android AMS与四大组件的通信机制决定的。

 

       最近在看吴越版的西游记,就发现这个西天取经为啥用了十几年啊?因为这师徒四个取经路上爱管闲事,所以耽搁了很久。我这篇文章也是如此,经常讲着讲着就跑题了,再这么写下去,不知道要写到啥时候,所以我们一路向西,径直往前走,再遇到奇怪的类,先不要理它。

 

       在回到代码来,这里要传递2个很重要的参数:

  • 通过ActivityThreadgetApplicationThread方法取到一个Binder对象,它的类型为ApplicationThread,它代表着Launcher所在的App进程。

  • mToken,这也是个Binder对象,它代表了Launcher这个Activity,这里也通过Instrumentation传给AMSAMS一查电话簿,就知道是谁向AMS发起请求了。

      

这两个参数是伏笔,传递给AMS,以后AMS想反过来通知Launcher,就能通过这两个参数,找到Launcher

 

 

 

       4步,InstrumentationexecStartActivity方法

       Instrumentation绝对是Adnroid测试团队的最爱,因为它可以帮我们启动Activity

 

       回到我们的App启动过程来,在InstrumentationexecStartActivity方法中:



我理解这就是一个透传,Activity把数据借助Instrumentation,传递给ActivityManagerNative,没太多有趣的内容,就不多讲了。

 

       5步:AMNgetDefault方法

       ActivityManagerNative,简称AMN。这个类后面会反复用到。

AMN通过getDefault方法,从ServiceManager中取得一个名为activity的对象,然后把它包装成一个ActivityManagerProxy对象(简称AMP),AMP就是AMS的代理对象。

备注1ServiceManager是一个容器类。

备注2:  AMNgetDefault方法返回类型为IActivityManager,而不是AMPIActivityManager是一个实现了IInterface的接口,里面定义了四大组件所有的生命周期。

AMNAMP都实现了IActivityManager接口,AMS继承自AMN(好乱),那么对照着前面AIDLUML,就不难理解了:




6步,AMPstartActivity方法

看到这里,你会发现AMPstartActivity方法,和AIDLProxy方法,是一模一样的,写入数据到另一个进程,也就是AMS,然后等待AMS返回结果。

 

至此,第一阶段的工作就做完了。

 

后续流程请参加下一篇文章。


 
包建强的无线技术空间 更多文章 写给Android App开发人员看的Android底层知识(6) 写给Android App开发人员看的Android底层知识(4) 写给Android App开发人员看的Android底层知识(3) 写给Android App开发人员看的Android底层知识(1) App设计模式纵横谈(2)
猜您喜欢 数学居然还可以开导人生? 在麒麟970发布之际,谈谈麒麟芯片的发展史 12星座前任:听说爱情回来过 时钟向量在一致性问题中的应用 Go vs Erlang