Android部分技术点目录(3)

目录

Android插件化原理
oom_adj的具体计算方法
ActivityStack/ActivityRecord/TaskRecord关系
Binder深入
把XML文件inflate到界面上的全过程
try catch finally的几个坑
关于Thread
Android中有哪些解析xml的类
SIM卡的EF文件是什么?有何作用
段式和页式存储的区别
P、V原语
Android虚拟机、apk、aapt、dex、odex、deodex、smali
JVM、Dalvik和ART的区别
JVM基于栈,Dalvik基于寄存器
ART的GC优化

Android插件化原理

插件化就是动态加载apk,两个核心问题是加载代码和加载资源,但真正棘手的问题在于组件的生命周期和资源id冲突。

1.加载代码

需要一个ClassLoader来加载类。
1.1 ClassLoader
DexClassLoader和双亲委派。
利用当前的ClassLoader,新建DexClassLoader:

    ClassLoader localClassLoader = ClassLoader.getSystemClassLoader();
    DexClassLoader dexClassLoader = new DexClassLoader(dexPath,
        dexOutputPath, null, localClassLoader);

新的DexClassLoader以现有的ClassLoader为双亲,根据双亲委派机制,两个apk的代码就都能访问了。

2.加载资源

需要通过ContextImpl来获取资源,具体是通过getAssets和getResources来获取资源的。
2.1 AssetManager
Asset需要add新apk的AssetPath:

Method addAssetPathMethod = AssetManager.class.getDeclaredMethod("addAssetPath", String.class);
addAssetPathMethod.invoke(instance, dexPath);

2.2Resources
Resource需要使用增加过的Asset:

private Resources getResources(Context ctx, AssetManager selfAsset) {
                DisplayMetrics metrics = ctx.getResources().getDisplayMetrics();
                Configuration con = ctx.getResources().getConfiguration();
                return new Resources(selfAsset, metrics, con);
}

3.生命周期管理

通过DexClassLoader通过反射创建出来的Activity是一个普通的java对象,并没有生命周期,这个问题有多个解决思路:
3.1 代理
在主应用的manifest中注册一个代理activity,并将proxy的生命周期,触摸按键回调等与插件Activity同步,实现插件Activity的生命周期管理。
3.2 替换ClassLoader
App的ClassLoader可以这样找到:ActivityThread-->LoadedApk-->mClassLoader。
然后,用反射,setFiledObject替换android.app.LoadedApk中的mClassLoader实例,这个实例需要mPackages,mPackages又需要currentActivityThread:

        Object currentActivityThread = RefInvoke.invokeStaticMethod(  
                "android.app.ActivityThread", "currentActivityThread",  
                new Class[] {}, new Object[] {});//获取主线程对象  
        String packageName = this.getPackageName();//当前apk的包名  
        ArrayMap mPackages = (ArrayMap) RefInvoke.getFieldOjbect(  
                "android.app.ActivityThread", currentActivityThread,  
                "mPackages");  
        WeakReference wr = (WeakReference) mPackages.get(packageName);  
        RefInvoke.setFieldOjbect("android.app.LoadedApk", "mClassLoader",  
                wr.get(), dLoader);  

这种方法下,声明组件,还是要在宿主App中声明。
而且,没有apk的资源包,不能再用setContentView,要额外做一个设置视图的功能。
3.3 插入dex
DexClassLoader和PathClassLoader(只能加载已安装的app)的父类BaseDexClassLoader,有一个Element[] dexElements。
将新的DexClassLoader中的Elements合并到PathClassLoader的数组中,也可以实现。

4.资源冲突

在apk编译过程中,资源文件会由aapt工具生成对应的ID,并在打包的时候组织成resources.arsc文件,resources.arsc文件是用来描述资源ID和资源位置配置信息,从18个维度描述了一个资源ID的配置信息(语言、分辨率等),就是资源ID和资源的索引表。资源的ID生成是有规则的,规则:0xPPTTNNNN,由8位16进制组成,其中:
PP段:表示资源的包空间:0x01表示系统资源空间,0x7f表示应用资源空间。
TT段:表示资源类型。
NNNN段:4个16进制表示资源id,一个apk中同一类型资源从0000开始递增。

因为宿主apk和插件apk是独立编译出来的两个独立的apk,那么其中就有资源ID相同的情况出现,从而产生资源ID冲突。Sophix的解决方法是把补丁中的resource用0x66替换0x7f。

Android中插件开发篇之----动态加载Activity(免安装运行程序)
Android动态加载技术三个关键问题详解
Android插件化系列第(二)篇---动态加载技术之apk换肤

oom_adj的具体计算方法

Linux有个OOM Killer,会监控那些占用内存过大,而且会瞬时消耗大量内存的进程,为防止内存耗尽,会强制杀死进程。
Linux内核会通过特定的算式计算每个进程的oom_score的值,oom_score为2的n次方,n为oom_adj的值,范围是-16~15,-17表示禁用OOM。

ActivityStack/ActivityRecord/TaskRecord关系

图片来自从源码角度看Activity launchMode与Stack/Task

从源码角度看Activity launchMode与Stack/Task

Binder深入

在App端,Binder操作时通过Activity-->ContextImpl-->LoadedApk$ServiceDispatcher来操作的,最终操作者是最后面这个LoadedApk的子类ServiceDispacher,最关键的代码为:

public void doConnected(ComponentName name, IBinder service, boolean dead) {
            ...
            // If there was an old service, it is now disconnected.
            if (old != null) {
                mConnection.onServiceDisconnected(name);//断开连接
            }
            if (dead) {
                mConnection.onBindingDied(name);//死亡通知(binder服务意外死亡)
            }
            // If there is a new service, it is now connected.
            if (service != null) {
                mConnection.onServiceConnected(name, service);//连接
            }
}

连接/连接断开通知
对于Binder来说,Binder的Service是一个存在于某个进程里的对象,系统用红黑树管理这些对象的引用,并提供给client。所以,如果进程尚未启动,没有注册这个Binder服务,系统就找不到该服务,无法提供给client。
因为建立服务的时长是不确定,所以需要在ServiceConnection中用回调来处理连接结果:

        ServiceConnection connection=new ServiceConnection() {
            @Override
            public void onServiceConnected(ComponentName name, IBinder service) {
            }

            @Override
            public void onServiceDisconnected(ComponentName name) {

            }
        };

死亡通知
服务进程关闭时,会释放进程资源,关闭文件等,此时调用Binder驱动的binder_release-->binder_Died,如果AIDL客户端注册过DeathRecipient接口,调用linkToDeath方法,就能收到死亡通知:

public class XX implements Binder.DeathReceipient{//注册接口

  observer.asBinder.linkToDeath();//调用方法

  @Override
  public void binderDied(){}//收到回调
}

如果是BindService的用法,可以直接在ServiceConnection中,用IBinder去注册死亡通知:

        ServiceConnection connection=new ServiceConnection() {
            @Override
            public void onServiceConnected(ComponentName name, IBinder service) {
                //注册死亡通知
                try {
                    service.linkToDeath(new IBinder.DeathRecipient() {
                        @Override
                        public void binderDied() {
    
                        }
                    }, IBinder.FLAG_ONEWAY);
                } catch (RemoteException e) {
                    e.printStackTrace();
                }
            }

            @Override
            public void onServiceDisconnected(ComponentName name) {

            }
        };

异常通知
DeadObjectException和RemoteException。
服务端进程死亡或缓冲内存区满,都会报DeadObjectException。
writeStrongBinder/readStrongBinder
为了实现双工通信,用来传送Binder对象的,例如startActivity时,会向AMS发送ApplicationThread Proxy对象:

data.writeStrongBinder();//data是Parcel对象

writeStrongBinder是调用native实现的
线程池
每个进程的binder线程池上限为15个,外加一个主binder线程。
如果线程都满,会在todo队列中阻塞等待
缓冲内存区
linux层对mmap的上限为4M,Binder申请的mmap更低,同步空间为1016K,异步空间为508K(一半)。
如果缓冲内存区满,会抛DeadObjectException。
传递Bitmap
如果通过广播传递Bitmap,是受1016K限制的,实际中,Bundler超过800K就会报TransactionTooLargeException。
但是如果通过AIDL传递Bitmap,只要超过128K,就会使用ashmem来传图片,mmap只传递ashmem的fd。

把XML文件inflate到界面上的全过程

整个过程分三部分:
1.连接系统服务,利用WMS获取Window的位置、层级、生命周期等;利用SurfaceFlinger获取Surface以便绘制界面;界面内容的定义是在Activity中实现的;
2.创建Activity界面,在attach时创建PhoneWindow,在setContent时创建DecorView,调用动画、生成状态栏、活动栏、以及内容控件mContentParent。(所以,动画、状态栏等属性,需要在setContent前设置);
3.填充DecorView,主要是把XML的layout文件,inflate到mContentParent中,把xml装进一个XmlResourceParser对象中,然后while解析xml结构,找到根节点(所以layout只能有一个最外层控件),用createViewFromTag创建根节点,用rInflateChildren遍历剩余的xml,最终生成xml对应的ViewTree,填充到DecorView的R.id.content里面。

try catch finally的几个坑

try catch finally中,四种情况:
1.try里system.exit时不走finally
2.在前面return或throw时,会先走finally,
3.但是finally不能改return的值,因为return的机制是个传值,把变量值赋给不知名变量,finally不会改变这个不知名变量
4.在finally里不能return,会导致数据不一致,会导致catch里throw不被执行

关于Thread

ActivityThread作为主线程,启动时最大的不同就是prepare(false),这个false表示线程不可以取消:

   //ActivityThread源码
    public static void prepareMainLooper() {
        prepare(false);//quitAllowed参数为false,不允许主线程退出

Thread是线程类,并不是线程,线程需要交给虚拟机去调用本地方法(VMThread.create),从CPU上切割线程资源。

Thread既继承了Runnable,又可以构造传参Runnable,所以它最终都是启动一个线程,去运行用户指定的Runnable,所以Thread相当于一个中介。

线程的wait、sleep、join和interrupt
wait不是java.lang.Thread的方法,是java.lang.Object的,wait会释放对象锁。
sleep是抱着对象等时间(CPU不释放)
join是插入到当前线程,让自己先执行
yield是自己先暂停一下,看看是否有其他优先级更高的线程需要执行,此时锁和CPU都没有释放,如果直接回来,不用切换上下文
interrupt是中断前面的执行过程,比如被block在wait,sleep或join上时,interrupt可以立即唤醒并抛出InterruptedException

Thread.interrupt:中断
Thread.interrupted:返回是否中断,并清除中断状态
Thread.isInsterrupted:返回是否中断,不清除中断状态

Android中有哪些解析xml的类

SAX,流式处理,事件驱动,解析时为每种xml调用处理函数。
PULL,Android系统内置,也是流式处理,但解析返回的是数字,根据数字自己写解析方式,可以自己控制解析到哪里。
DOM,树状结构解析,可以直接访问文件的各个部分

SIM卡的EF文件是什么?有何作用

sim卡里有MF、DF、EF三种文件,前两种用于检索,只有EF可以存放数据。
MF,主文件Master File,只有文件头,sim卡唯一,存放sim卡的控制信息和管理信息。
DF,专用文件Dedicated File,只有文件头,相当于目录的根,存放整个目录的控制信息和管理信息。
EF,基本文件Elementary File,既有文件头,又有文件体,文件头存放文件位置和控制信息,文件体存放数据

段式和页式存储的区别

基础:
页和块,逻辑地址是连续的页,页对应在物理地址上是大小一致(4K)位置分散的块,用页表存放对应的页号和块号即可。
段和基址,每个段对应一个连续的物理内存,段的大小不固定,通过段号和段表,找到物理基址。
页式是一维的,块号是地址高位,块号&偏移量,即可拼出完整的物理地址。
段式是二维的,根据段号找到基址(一个维度),加偏移量(另一个维度)即可找到对应的物理地址。
段页式:先按逻辑分段,每个段内部又分页,地址结构是:段号+段内页号+页内地址
段式/页式需访问两次内存,段页式需访问三次内存。

P、V原语

P、V原语解决资源争用的问题,主要依靠S信号量,S代表可用的资源数,P代表取用资源,V代表返还资源

P原语时,S=S-1,表示准备取走一份资源,此时如果S>=0,代表不会取成负的,那么就可以正常取,如果S<0,就意味着没有资源了,那么就需要等待资源释放

V原语时,S=S+1,表示准备还回一份资源,此时如果S>0,代表还之前不是负的,那么没有别人在等;如果S<=0,代表之前是负的,有别人在等资源,那么就需要通知一个等待资源的人。

Android虚拟机、apk、aapt、dex、odex、deodex、smali

虚拟机,Android的虚拟机先有Dalvik,后有Art,这两者都为移动平台做了特殊优化
apk,apk其实是个rar,里面有这样几个主要对象:
1.META-INF:文件夹,应用签名
2.res:文件夹,资源文件
3.classes.dex:执行程序
4.resources.arsc:二进制资源文件
aapt,Android的apk安装包是由aapt(Android Asset Packaging Tool)打包的
dex,Dalvik VM Executors,其中最大的改变就是dex文件取代了jar文件,安卓系统第一次执行dex时,会用dexopt工具做优化,使更适合在当前设备上运行。
odex,Optimized Dalvik VM Executors,优化的dex文件,这是安卓系统做的,把dex优化为odex,并删除旧的dex,优化的odex在data/dalvik-cache目录下。
odex的优点:
1.避免第一次启动时加载速度慢(已经优化过)
2.减少RAM占用(不需要保存优化前的dex)
3.防反编译(系统里只有本地优化过的odex)
odex的缺点:
1.升级时容易失败导致强制关闭
2.占rom
3.rom不方便修改
deodex,第三方rom里基本都是deodex,apk里直接是dex,启动时从apk里读dex,并优化为odex
deodex的优点:
1.减少rom体积(不需要在data/dalvik-cache里寸odex)
2.方便rom的定制和移植
3.方便apk反编译和修改
缺点:
1.启动耗时,每次启动需要读出dex,优化为odex
smali,odex需要用baksmali转换为dex,再把dex转换成jar包,直接从odex转jar包的话,大部分会有编译错误,只能简单的阅读分析。

JVM、Dalvik和ART的区别

Dalvik和ART并不是Java虚拟机,因为他们并没有完全遵循Java虚拟机规范。
JVM运行class字节码文件,Dalvik运行dex文件(JIT模式),ART在安装时转换为oat机器码。
最主要的差别是,JVM是基于栈,而Dalvik是基于寄存器,指令集不同。
odex和oat都是保存在data/dalvik-cache目录下,不过还都是同名文件(dex后缀名)。
odex是dey字节码,oat是机器码。

JVM基于栈,Dalvik基于寄存器

首先,无论哪种虚拟机,都需要以下功能:
取指令
译码
执行
存结果

JVM是基于栈的,使用指令来载入和执行栈上的操作,需要大量的指令。
基于栈的时候,真正的运算都在操作数栈上运行,不在非栈的内存中执行,这样虚拟机可以无视物理结构,但是处理速度慢。

Dalvik改为基于寄存器,使用空间小。
基于寄存器时,没有操作数栈的概念,而是有很多虚拟寄存器,执行引擎从寄存器中找到操作数,取出操作数,进行运算(直接传入CPU运算,不需要先进操作数栈)。
基于寄存器与基于栈的虚拟机

ART的GC优化

Dalvik:Dalvik虚拟机的内存管理并不好,有三大问题:
1.GC时挂起所有进程,查找活动对象时,会挂起所有的线程,stop the world,引起中断和阻塞
2.内存碎片化严重(标记清除)
3.缺少大块的连续空间

ART:
1.划分了四个堆空间(参考G1分堆垃圾回收器),各自的回收策略不同:
永不回收:ImageSpace
Sticky Mark Sweep:AllocationSpace
Partial Mark Sweep:AllocationSpace、Large Object Space
(力度最大)Mark Sweep:AllocationSpace、Large Object Space、ZygoteSpace
其中,Large Object Space是不连续的空间。
2.可以并行处理GC(过程参考CMS并发标记扫描垃圾回收器):
GC过程分成多个子任务,交给线程池处理,只在标记脏数据时stop the world。
并行GC基本过程:
--获取堆锁
--并行标记
--释放堆锁
--挂起ART,标记脏数据(并行标记期间被修改的)
--恢复ART
--获取堆锁
--回收内存
--释放堆锁

ART不一定会并行GC,如果是分配内存时发现内存不足,执行GC_FOR_ALLOC,不能并行,最耗时;如果分配堆后,剩余空间低于阈值,并行GC。
3.定期压缩活动对象,避免内存碎片化(标记整理)

ART运行时垃圾收集(GC)过程分析
【原创】【Android】揭秘 ART 细节 ---- Garbage collection

推荐阅读更多精彩内容