ope足彩_ope体育投注_ope体育在线投注
ope足彩

网络歌曲,Application和四大组件启动时的办法次序和相关注意事项,小鸡

admin admin ⋅ 2019-04-07 01:35:08

布景

在做一个项目时,咱们想在运用最早发动时,先做一些判别,然后依据判别的成果再决议要不要对其他运用供给效劳。

对其他运用供给效劳指的是,咱们的运用中有 C3岁女童ontentProvider,第三方运用经过 call 办法调用到咱们供给的 ContentProvider,ContentProvider 履行逻辑后并给调用的回来成果。当第三方运用调用咱们的运用时,咱们的运用存在发动和未发动的两种状况。

刚开始,咱们将判别逻辑写在了自定义儿子小说的 Application 的 onCreate 办法中,但比及测验时发现了许多意想不到的状况,比方:

逻辑判别之后的成果是不给第三方运用供给“效劳”,但有时分第三方运用能够运用效劳,而有时分第三方运用不能使等等的问题。

所以咱们盯梢代码,发现了 四大组件 以及 Application 的各个办法( attachBaseConte网络歌曲,Application和四大组件发动时的办法次第和相关留意事项,小鸡xt、onCreate、call 等)发动次第,跟咱们之前了解的稍稍不一样。

在弄清楚了 四大组件 和 Application 在运用冷发动时的履行次第后,咱们才把遇到的问题彻底解决。

验证实验

为了测验 四大网络歌曲,Application和四大组件发动时的办法次第和相关留意事项,小鸡组件 和 Application 的各种办法( attachBaseContext、onCreate、call 等)被体系调用的次第,咱们创立一个简略的运用,只包括这5个组件,不考虑一个运用多进程的状况,代码别离为:


Application和四大组件发动时的办法次第和相关留意事项


MainApplication.java

Application和四大组件发动时的办法次第和相关留意事项


MainActivity.java


MainService.java


MainRec杜有泽eiver.java


MainProvider.java


在以下几个场景测验时,均已冷发动的办法发动运用。

冷发动,指的是在体系没有创立apk这个进程时发动apk。

留意在测验的手机上,不要让测验的运用被制止相关发动或自发动:

场景一,点击桌面的图标发动运用,日志如下:



场景二,经过别的一个运用以发动Service的办法发动运用,其间发动 MainService 的代码如下:



日志如下:



场景三,运用经过承受开机播送发动的办法发动,日志如下:



场景四,其他运用调用 Con笑三笑是怎样得到龙龟tentProvider 的 call 办法发动,其间,调用 MainProvider 的 call 代码如下:



日志如下:



定论:

从上面四个场景能够看出:

1. Application 的 attachBaseContext 办法是优先履行的;

2. ContentProvider 的 onCreate 的办法比 Application 的 onCreate 的办法先履行;

3. Activity、Service的 onCreate 办法以及 BroadcastReceiver 的 onReceive 办法,是在 MainApplication 的 onCreate 办法之后履行的;

4. 调用流程为: Application 的 attachBaseContext ---> ContentProvider 的 onCreate ----> Application 的 onCreate ---> Activity、Service 等的 onCreate(Activity 和 Service 不分先后);

问题

问题一:ContentProvider 的 onCreate 一定是优先于 Application 的 onCreate 履行的吗?

为了验证这个问题,MainApplication 的代码不变,咱们将 MainProvider 的 onCreate 的代码改为:



咱们再在上面第四种场景上进行验证,日志如下:



问题一定论:

确实是在 ContentProvider 的 onCreate 履行完结之后,才会履行 Application 的 onCreate 的。

问题二:ContentProvider中 的 call办法 是在 Application 的 onCreate 履行完之后才履行的吗?

为了验证这个问题,咱们将 MainProvider 和 MainApplication 的代码改为:




咱们还在第四个场景下验证,日志如下:



从日志中能够发现,Application 奈瑟匹拉使命怎样做的 onCreate 履行时,ContentProvider 的 call办法 也在一起履行。

问题二定论:

Application 的 onCreat舔奶揉胸gif动态图e办法 和 Provider 的 call办法 不是次第履行,而是会一起履行

问题三:有比 Application 的 attachBaseContext办法 更早履行的办法吗?

有,比方:Application地点类的结构办法。为了验证这个问题,将代码改为:



程序发动后,日志为:



问题三定论:

Application 的结构办法早于 Application 的 attachBaseContext办法 调用。

那么有没有比 Application 的结构办法还早被调用的办法呢?有,自己能够再想想哦。

遇到的坑

好了,咱们知道 attachBaseContext 的办法在“一般状况下是最早履行的“,那么在项目中为了能”尽早“的提早初始化某些模块、功用或许参数,那么咱们会把代码从 Application 的onCreate办法 提早到 attachBaseContext办法 中。嗯,全部感觉起来那么夸姣,直到你运转程序溃散时...

好吧好吧,那些“坑”总算仍是来了。

“坑”一:在 Application 的 attachBaseContext办法 中,运用了 elixergetApplicationContext吴宗玲办法。

当我发现在 attachBaseContext办法 中运用 getApplicationContext办法 回来null时,心里是溃散。

所以,假如在 attachBaseContext办法 中要运用 context 的话,那么运用 this 吧,别再运用 getAppl静香毁幼年icationContext() 办法了。下文有剖析为什么。

“坑”纪家尉二:这个其实不算很坑,也不会引起溃散,但需求留意:

在 Application 的 attachBaseContext办法 中,去调用本身的 ContentProvider,那么这个 ContentProvider 会被初始化两次,也就是说这个 ContentProvider 会被两次调用到onCreate。假如你在 ContentProvider 的 onCreate 中有一些逻辑,那么一定要检查是否会有影响。

做一下验证,在 Application 中调用 Provider 的 call办法,并在 MainActivity 中汉中城固气候的 onCreate办法 中调用 Provider 的 call办法,Application 的代码,Provider 的代码,Activity 的代码别离如下:



发动运用后,日志如下:



能够看到,MainProvider 的 onCreate 的办法被调用了两次(由于 MainProvider 的两次 onCreate 打印出的本身目标不一样),而在 MainActivity 中调用到 call办法 履行的类,跟 MainApplication 在 attachBaseContext办法 履行的类是同一个。

源码剖析

好了,现象、问题和“坑”都阅历了一遍,那么 为什么 会是这样呢?

咱们经过看源码,来盯梢:

1. Application 的 attachBaseContext、ContentProvider 的 onCreate 以及 Application 的 onCreate 在源码中网络歌曲,Application和四大组件发动时的办法次第和相关留意事项,小鸡的调用次第。

2. 为什么在 Application 的 attachBaseContext 中尚洁怡调用 getApplicationContext 得到的网络歌曲,Application和四大组件发动时的办法次第和相关留意事项,小鸡是null

先看第一个问题,咱们知道Java进程的进口办法一般都是在main中,而Android为了让运用开发者不需求关怀运用的创立,现已帮咱们进行封装,其实运用 main办法 是在 ActivityThread.java 中的。

咱们检查 ActivityThread.java 的源码,本文以下的源码都以 6.0.1_r10 根底。

a.气候预报标志图片解说 ActivityThread.java 的 main办法:



b. ActivityThread.java 的 attach办法:



c. ActivityThread.java 的 handleBindApplication(AppBindData data)办法:



d. LoaderApk.java 的 makeApplication办法



e. Instr网络歌曲,Application和四大组件发动时的办法次第和相关留意事项,小鸡umentation.java的相关办法



f. Application.java 的 attach办法



g. ActivityThread.java 的 handleBindApplication办法:



h. 持续盯梢 installCont傅西来entProviders 这个办法,而这个办法是会调用到 installProvider办法 中的,仍是在 ActivityThread.java 中:



i. 看 ContentProvider.java 中的 attachInfo办法(frameworks/base/core/java/android/content/ContentProvider.java)



j. 关于 注释7 的 mInstrumentation.callApplicatio网络歌曲,Application和四大组件发动时的办法次第和相关留意事项,小鸡nOnCreate(app) 调用到的 Instrumentation.java 中的办法



看第二问题,为什么在咱们自定义汉汉 Application 中的 attachBaseContext办法 中,调用 getApplicationContext() 为 null 呢?

1. 盯梢 getApplicationConte网络歌曲,Application和四大组件发动时的办法次第和相关留意事项,小鸡xt() 发现是在 ContextWrapper.狡猾仙子闯古代java 中完成的:



2. 咱们看 ContextImpl 的 getApplicationContext办法:



3. mPackageInfo 是什么时分赋值的呢?咱们从 ContextImpl 实例化的当地下手,在注释 5.1 之前的一行代码看到了 ContextImpl 的唐山地震七大疑团实例化代码,跟进代码发现,果不其然,看到了 mPackageInfo 被赋值的当地:



4. 注释b.1地点的流程 早于 注释5.4 的(在注释5.4时才调用到了Application的attachBaseContext办法),在咱们自定义的Application中att施寂摩achBaseContext调用getApplicationContext办法时,就到了注释b,而此刻mPackageInfo是不为空的,所以会履行mPackageInfo.getApplication(),那么咱们再看一下LoadedApk.java中的getApplication办法(正如前面所说,mPackageInfo是LoadedApk的实例),




看到郑登高这儿找到原因地点了:

由于咱们在 Application 的 attachBaseContext办法 中调用 getApplicationContext() 时, mApplication 还没有被赋值,所以回来的是空,只要把 attachBaseContext办法 履行完结后,mApplication 才会被赋值。

附图一张:



参阅

http://androidxref.com

http://blog.csdn.net/u011228356/article/details/45102623

http://www.wtoutiao.com/p/1f8OfGz.html

相关新闻

admin

admin

TA太懒了...暂时没有任何简介

精彩新闻