【Android笔记】 Framework

最新推荐文章于 2024-07-25 23:12:21 发布

2401_85667460

最新推荐文章于 2024-07-25 23:12:21 发布

阅读量417

点赞数 24

文章标签： android 笔记 python

本文链接：https://blog.csdn.net/2401_85667460/article/details/139962755

版权

| 具体类型 | 系统服务 | bind服务 |

| — | — | — |

| 启动方式 | 在ststemService进程的startBootStrapService();startCoreService();startOtherService();中启动 | startService(Intent intent) ,classLoader加载类，然后创建context |

| 注册方式 | public static void addService(String name,IBInder service){getServiceManager().addService(name,service,false)}(夸进程通信) | binder service到AMS |

| 注册位置 | 注册到serviceManager | 注册到AMS |

| 注册时机 | （1）systemService中启动各种服务时候（java方式）（2）surfaceflinger这种独立进程，通过jni添加 | 手动注册 |

| 使用方式 | context.getSystemService(Context.POWER_SERVICE) | binderService(serviceIntent,ServiceConnection) |

4. 进程 & binder启动

在启动进程过程中，binder通信是绕不开的一个点。应用在启动完毕通知AMS时候是通过binder通信进行通知。而binder的启动时在zygote启动启动进程的时候。zygote在收到AMS的启动请求的时候，会调用runOnce函数

boolean runOnce(){

String args=readArgumentList();

int pid=Zygote.forkAndSpecialize(…);

if(pid==0){

handleChildProc();

return true;

}else {

// deal parentProc

}

复制代码

在handleChildProc()中的nativeZygoteInit()中会启动binder。binder启动主要分为四个步骤

打开binder驱动
映射内存，分配缓冲区
注册binder线程
进入binder loop

5.Application

一般用来：

保存全局的应用变量
初始化操作
提供上下文

初始化：从main函数跟进

public static void main(String[] args){

Looper.prepareMainLooper();

ActivityThread thread=new ActivityThread();//只是一个普通java类，不是thread

thread.attach(false);

Looper.loop();

}

复制代码

在attach函数当中调用

private void attach(){

final IActivityManager mgr=ActivityManagerNative.getDefault();//AMS在应用进程的binder代理对象

mgr.attachApplication(mAppthread);//mAppthread是应用进程的binder对象，传入AMS中

}

复制代码

然后在ASM中调用函数

boolean attachApplicationLocked(IApplicationThread thread){

thread.bindApplication();//IPC通信到应用进程中

}

复制代码

应用进程的bindApplication函数为

public final void bindApplication（）{

AppBindData data=new AppBindData();

sendMessage(H.BIND_APPLICATION,data);//抛到应用主线程去处理

}

复制代码

在主线程创建Application对象并调用mInstrumentatio.callApplicationOnCreate(app); 所以Application的总体的执行顺序为

new Application() -> Application.attachBaseContext() -> Application.onCreate

复制代码

不能在Application的构造函数中调用上下文

因为这个时候上下文还没有被初始化。

不要在Application的生命周期中执行耗时参数。

不同于AMS的ONEWAY（发起调用马上返回）的调用方式，Application执行耗时函数会阻塞UI线程。阻碍Application自身后续组件的初始化。

Application中使用静态变量的坑。

在Application中声明一个static Strting name;在A activity中赋值，在B activity中使用。假如此时长时间压后台，然后重新切回来的时候，Application和B activity会重新创建，但是这个时候拿到的静态变量name不会被A activity赋值，从而引发异常。为解决这个问题，建议B activity接收name参数是用getIntent()的方式从A activity接收参数。同时在onSaveInstanceState中保存这个值。在恢复重建的时候从onCreate(Bundle savedState) 的savedState里读取

6.Context

应用中context的数量=activity数量+service数量+application数量方便访问系统资源，调用系统服务。

application context

application继承自ContextWrapper.

public class ContextWrapper extends Context{

Context mBase;//在activity中getBaseContext时候返回。所以是context中还包含了一个context。

protected void attachBaseContext(Context base){

mBase=base;

}

public Resources getResources(){

return mBase.getResources();//静态代理。context的所有调用

//都委托给了mBase

}

复制代码

getApplication和getApplicationContext都是返回Application全局对象。 getApplicationContext是属于Context的抽象函数。 getApplication是activity和service中特有的函数。

activity context

整体跟application的创建比较类似。但是activity是继承自ContextThemeWrapper. 代码执行也是先执行attachBaseContext，再执行onCreate; 具体创建包括

private Activity perfirmLaunchActivity(){

Activity activity=null;

activity=mInstrumenttation.newActivity();//内部通过classloader加载类

Application app=r.packageInfo.makeApplication();//获取Application对象

Context appContext =createBaseContextForActivity(r,activity);

activity.attach(appContext,app,…);//会调用attachBaseContext(context)

activity.onCreate();

return activity;

}

复制代码

servixe context

继承自ContextWrapper。创建流程和perfirmLaunchActivity差不多。

BroadcaseReceiver和Context Provider的上下文由外边传入。但是Context Provider的onCreate调用是在application的onCreate之前调用，但是在application的attachBaseContext之后。

7.Activity 启动流程 & 显示原理 & UI线程

冷启动流程大致如图：

[图片上传失败…(image-92a9c-1638946169885)]

而普通的应用启动流程如下：

发送startActivity请求到AMS，AMS通过socket发送消息到zygote，zygote发送socket消息到应用进程。后边的流程如上图对应的位置

UI线程

UI线程：UI刷新所在的线程，且UI是单线程刷新的对activity来说，UI线程就是主线程。runOnUiThread(); 对View来说，UI线程是ViewRootImpl创建所在的线程.View.post(only the origin thread that created a view hoerarchy can touch int view) 随之而来的另外一个问题就是：子线程刷新UI？参考主线程创建：

final void handleResumeActivity(IBinder token,…){

final Activity a=r.activity:

ViewManager wm =a.getWindowManager();

wm.addView(decor,l);//该方法中会创建ViewRootImpl

}

root=new ViewRootImpl()

root.setView(view,wparams,panelParentView)

复制代码

所以类似的我们也可以在子线程中刷新view

new Thread(){

public void run(){

Looper.prepare();

getWindowManager().addView(view,parmas);//可以正常显示和操作UI

Looper.loop();

}

}.start();

复制代码

8.屏幕刷新

带着问题去思考

丢帧一般是什么原因引起的？
Android 刷新频率是60帧/秒，每隔16ms调onDraw绘制一次？
onDraw完之后屏幕会马上刷新吗？
如果界面没有重绘，还会每隔16ms刷新屏幕吗?
如果在屏幕快要刷新的时候才去onDraw绘制会丢帧吗？

Choreographer：编舞者（通过threadLoacl创建）

public static Choregrapher getInstance(){

return sThreadInstance.get();//不同的线程调用getInstance返回的是不同的Choreographer对象

}

复制代码

requestLayout(){//在一个vsync周期内，只会执行一次刷新

scheduleTraversals();//插入同步屏障

}

复制代码

绘制的时候如果跳帧严重，源码会打印出日志提示，SKIPPED_FRAME_WARNING_LIMIT默认是30

void doFram(long framTimenanos,int frame){

if (skippedFrames >= SKIPPED_FRAME_WARNING_LIMIT) {

Log.i(TAG, "Skipped " + skippedFrames + " frames! "

“The application may be doing too much work on its main thread.”);

}

复制代码

当view调用requestLayout()时候，将一个callBack传到Choreographer中，Choreographer没有直接处理callBack，而是先向SurfaceFlinger发送requestNextVsync请求下一个vsync信号，SurfaceFlinger在下一个vsync信号来的时候通过postSynEvent通知给Choreographer，Choreographer收到通知后执行真正的绘制performTraversal()方法。

Choreographer作为编舞者，主要是起协调作用。将代码绘制控制到和vsync协调到一个节奏，避免在一个vsync信号的中间位置开始绘制，而是将真正绘制代码的起点和收到vsync信号的起点保持一致。从而减少卡顿。

1. 丢帧一般是什么原因引起的？

主线程耗时操作

2. Android 刷新频率是60帧/秒，每隔16ms调onDraw绘制一次？

刷新频率指得是vsync信号发生的频率，不一定每次vsync信号都去绘制，需要应用端主动发起重绘,然后才会向SurfaceFlinger请求接受vsync信号，然后再下次vsync信号来的时候才会去真正绘制

3. onDra完之后屏幕会马上刷新吗？

不会。要等到下次vsync信号来的时候才刷新

4. 如果界面没有重绘，还会每隔16ms刷新屏幕吗?

不发生重绘，就不会接受vsync信号,但是屏幕还是会每隔16m刷新屏幕，只不过刷新是旧的数据

5. 如果在屏幕快要刷新的时候才去onDraw绘制会丢帧吗？

不一定。我们代码中发起的绘制是要等到下次vsync信号来的时候才会执行，跟发起绘制操作的时机没有太大联系

9.surface

surface夸进程传递

怎么理解surface，它是一块buffer吗？
如果是，surface跨进程传递怎么带上这个buffer？
如果不是，那surface和buffer是什么关系？
surface是怎么进行夸进程传递回应用的？

private void performTraversals(){

if(mFirst){

relayoutResult=relayoutWindow(params,…);

}

int relayoutWindow(WindowManager.LayoutParams params,…){

//mWindowSession是一个binder对象，像wms申请surface，所以view的绘制也涉及跨进程通信

return mWindowSession.relayout(mWindow,…mSurface);

}

复制代码

WMS端创建了一个native的surface对象，并跟java层的surface对象绑定在一起。（将native层surface对象的指针保存在java层的surface对象中）。WMS端native service的核心是GraphicBufferProducer这个binder对象（简称GBP）。所以 surface的本质是GraphicBufferProducer，而不是buffer surface夸进程传递，本质是GraphicBufferProducer这个binder对象的传递。

1. 怎么理解surface，它是一块buffer吗？

不是，它只是一个壳子，里面包含了能生产buffer对象的GraphicBufferProducer这个binder对象

复制代码

2. 如果是，surface跨进程传递怎么带上这个buffer？

3. 如果不是，那surface和buffer是什么关系？

通过GraphicBufferProducer（GBP）这个binder对象来传递

复制代码

最后

小编这些年深知大多数初中级Android工程师，想要提升自己，往往是自己摸索成长，自己不成体系的自学效果低效漫长且无助。

因此我收集整理了一份《2024年Android移动开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友。

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、电子书籍、讲解视频，并且后续会持续更新

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人

都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

如果你需要这些资料， ⬅ 专栏获取
带上这个buffer？

3. 如果不是，那surface和buffer是什么关系？

通过GraphicBufferProducer（GBP）这个binder对象来传递

复制代码

最后

小编这些年深知大多数初中级Android工程师，想要提升自己，往往是自己摸索成长，自己不成体系的自学效果低效漫长且无助。

因此我收集整理了一份《2024年Android移动开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友。

[外链图片转存中…(img-vpwI65Fi-1719304305742)]

[外链图片转存中…(img-21bQuZdK-1719304305742)]

[外链图片转存中…(img-QrTfX1JW-1719304305743)]

[外链图片转存中…(img-8RKktxW5-1719304305743)]

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人

都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

如果你需要这些资料， ⬅ 专栏获取

2401_85667460

关注

24
点赞
踩
17

收藏

觉得还不错? 一键收藏
0
评论
【Android笔记】 Framework

小编这些年深知大多数初中级Android工程师，想要提升自己，往往是自己摸索成长，自己不成体系的自学效果低效漫长且无助。因此我收集整理了一份《2024年Android移动开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友。由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、电子书籍、讲解视频，并且后续会持续更新一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人。
复制链接

扫一扫