【高端微盘源码】【jqueryfind源码实现】【cms漫画源码】oncreate源码分析

时间:2024-12-23 23:18:42 编辑:盗窃公司源码怎么处理 来源:ea源码破解源码流程

1.Jetpack学习之----ViewModel
2.Android N 四大组件的工作原理
3.Navigation源码解析及自定义FragmentNavigator详解
4.Android 调用父类
5.❤️ Android 源码解读-从setContentView深入了解 Window|Activity|View❤️

oncreate源码分析

Jetpack学习之----ViewModel

        官方学习文档

        ViewModel就是存储页面相关的数据,并将这些数据和Activity、Fragment等有生命周期相关的组件相关联,赋予数据生命周期。

        特点:

        ViewModel的生命周期

        在viewModel对象创建时开始,一直到他所关联的界面控制器销毁时才销毁,这就说明了即使发生了横竖屏切换,界面相关的数据也是一直存在并且不受横竖屏切换的影响。

        通常我们是在Actvity的onCreate()方法中来创建ViewModel对象,该ViewModel对象会一直在内存中,直到这个Activity销毁时才释放资源。

        从上面ViewModel的工作原理可以得知:

        1、ViewModel 一旦创建好了,就会一直保存到当前界面控制器(Activity 、Fragment等)销毁时才会释放资源;

        2、不同的界面控制器,ViewModel 的对象时存在不同的Hashmap中的,他们也是不同的对象;局部单例;

        3、要做到全局单例ViewModel对象,可以将ViewModel放到Application中去;

        接下来从源码角度来分析一下原理:

        在构建Activity的对象时,在其父类ComponentActivity.java中实现了接口ViewModelStoreOwner,在其实现方法中生成ViewModelStore对象

        在界面控制器的构造函数中,就添加了对生命周期的观察者,而当观察者收到当前的界面控制器的生命周期是Lifecycle.Event.ON_DESTROY时,就会将mViewModelStore对象map中所有保存的viewModel清理掉,这样来达到释放资源。

        这里只处理了ON_DESTROY的生命周期状态,那么也就说明了在ViewModel对象实例创建成功后,不管界面控制器(如Activity)的生命周期(除ON_DESTROY外)如何发生变化,ViewModel都不会被清理掉。

        从这里看出来ViewModel对应key的唯一性

        ViewModel工作原理的核心技术点:

        观察者模式、工程模式、反射、Hashmap数据结构

        ViewModel在MVVM架构模型中,与DataBinding结合使用,会让你有起飞的感觉。后续会进一步加深使用。本篇仅以学会使用、了解原理为重点。

Android N 四大组件的工作原理

       æœ¬æ–‡ä¾§é‡è®²è§£android N 系统中四大组件的工作原理,不同系统原理略有差别。通过分析四大组件的工作流程加深对Android Framework的理解,也为插件化开发打下基础。

        Activity

        展示一个界面并和用户交互,它扮演的是一个前台界面的角色。

        Service

        计算型组件,用于后台执行一系列计算任务,工作在主线程,耗时操作需要另起线程, 分为启动状态和绑定状态。

        BroadcastReceiver

        消息型组件,主要用于不同组件或者不同应用之间的消息传递,它工作在系统内部,不适合执行耗时操作,操作超过5s,会出现ANR。

        ContentProvider

        数据共享型组件,用于向其他组件或者应用共享数据,主要执行CURD操作。

        我们启动一个activity有两种方法,

        第一种(Activity直接启动方式):

        Intent intent = new Intent(this,源码 MainActivity.class);

        startActivity(intent);

        第二种(Context启动方式)

        Intent intent = new Intent(this, MainActivity.class);

        getApplicationContext().startActivity(intent);

        不同的启动方式Activity的工作流程有点差别。

        两种启动都会调用到Instrumentation类中的execStartActivity的方法,系统最终是通过ActivityThread中的performLaunchActivity完成Activity的创建和启动。

        performLaunchActivity方法主要完成以下工作:

        1、通过ActivityClientRecord对象获取启动activity的组件信息

        2、通过mInstrumentation对象的newActivity方法调用classloader完成activity的创建

        3、通过r.packageInfo(LoadedApk 对象)的makeApplication方法尝试创建Application对象

        4、创建ContextImpl对象并调用Activity的attach方法完成一些数据的初始化

        5、调用Activity的onCreate方法

        在Activity启动的过程中,App进程会频繁地与AMS进程进行通信:

        App进程会委托AMS进程完成Activity生命周期的管理以及任务栈的管理;这个通信过程AMS是Server端,App进程通过持有AMS的client代理IActivityManager完成通信过程;

        AMS进程完成生命周期管理以及任务栈管理后,会把控制权交给App进程,让App进程完成Activity类对象的创建,以及生命周期回调;这个通信过程也是通过Binder完成的,App所在server端的Binder对象存在于ActivityThread的内部类ApplicationThread;AMS所在client通过持有IApplicationThread的代理对象完成对于App进程的通信。

        Service有两种启动方式,startService()和bindService(),两种状态可以并存:

        startService流程

        bindService流程

        BroadcastReceiver的工作过程主要包括广播的注册、发送和接收:

        动态注册过程:

        发送过程

        静态注册是由PackageManagerService(PMS)在应用安装的时候完成整个注册过程的,除广播以外,其他三大组件也都是在应用安装时由PMS解析并注册的。

        每个进程的入口都是ActivityThead.main(),App的启动流程如下:

        从源码中可以看出:

        应用启动的入口为ActivityThread的main方法,main方法会创建ActivityThread实例并创建主线程消息队列。

        attach方法中远程调用AMS的attachApplication方法,并提供ApplicationThread用于和AMS的通信。

        attachApplication方法会通过bindApplication方法和H来调回ActivityThread的handleBindApplication,这个方法会先创建Application,再加载ContentProvider,然后才会回调Application的onCreate方法。

        由上图可以看出,在ContentProvider的启动过程中伴随着app进程的启动。

        ContentProvider的其他CURD操作如insert,delete,update跟query的流程类似。

Navigation源码解析及自定义FragmentNavigator详解

       谷歌推出的Navigation主要目标是统一应用内页面跳转行为。使用方法简单,分析新项目选择Bottom Navigation Activity,源码系统自动生成页面逻辑。分析

       Navigation源码设计简洁,源码包含多个关键类。分析高端微盘源码其中,源码NavHostFragment是分析直接在XML文件中定义的,其生命周期方法onCreate中直接创建了NavHostController,源码并通过findNavController暴露给外部调用者。分析NavHostController继承自NavController。源码在此过程中,分析通过navController获取NavigatorProvider并添加了两个Navigator:DialogFragmentNavigator和FragmentNavigator。源码NavController构造方法中还额外添加了两个Navigator,分析分别对应DialogFragment、源码jqueryfind源码实现Fragment和Activity的页面跳转。NavGraphNavigator用于在XML配置的navGraph与根节点文件中的startDestination之间实现跳转,功能单一。

       各个Navigator通过重写navigate方法实现各自的跳转逻辑。FragmentNavigator的关键实现在于注释1处,使用replace加载Fragment,这不符合实际开发需求。文章后续将解释如何自定义FragmentNavigator以避免Fragment在切换时执行生命周期。

       NavigatorProvider内部维护了一个HashMap存储相关Navigator信息,通过获取Navigator的注解Name作为键和getClass作为值进行存储。在onCreate方法中,mNavController调用了setGraph,解析XML配置的mobile_navigation节点信息文件,根据不同的cms漫画源码节点各自解析。通过获取NavInflater进行解析,返回NavGraph,NavGraph继承自NavDestination,保存了所有解析出的节点信息。

       总结,通过NavHostFragment获取到NavContorl并存储了相关Navigator信息。通过各自navigate方法进行页面跳转,通过setGraph解析配置的页面节点信息并封装为NavGraph对象。其中,通过SparseArray存储Destination信息。

       自定义Navigator实现思路主要在于继承现有FragmentNavigator并重写其navigate方法,将replace方法替换为show和hide方法,完成Fragment切换。通过@Navigator.Name(value)注解标记自定义类为Navigator,asp软件源码加入NavigatorProvider中即可识别。自定义Navigator核心代码实现后,需调整mobile_navigation节点中的fragment为fixFragment,并删除布局文件中NavHostFragment节点信息,手动关联FixFragmentNavigator与NavControl,完成Fragment切换时生命周期不会重新执行。

Android 调用父类

       å› ä¸ºæˆ‘们用的Activity都是继承自Activity的,而Activity的onCreate()方法中是有一些必要的逻辑要执行的.所以我们的Activity中的onCreate()不调用super.onCreate()的话,Activity的初始化就会有问题.

       æœ‰äº›Activity函数就不需要调用父类的同一个方法,因为父类的这些方法里留空了,就是为了让子类复写的.当然这类方法写个super.XXX()也是没错的.

       å¦‚果有兴趣,可以自己翻下源码,就明白了.

❤️ Android 源码解读-从setContentView深入了解 Window|Activity|View❤️

       Android系统中,Window、Activity、View之间的关系是紧密相连且相互作用的。了解这三者之间的关系,有助于深入理解Android应用的渲染和交互机制。

       在Android中,通常在创建Activity时会调用`setContentView()`方法,sip对讲源码以指定显示的布局资源。这个方法主要作用是将指定的布局添加到一个名为`DecorView`的容器中,并最终将其显示在屏幕上。这一过程涉及到多个组件的交互,下面分步骤解析。

       在`Activity`类中,`setContentView()`方法调用`getWindow()`方法获取`Window`对象,而`Window`对象在`Activity`的`attach()`方法中被初始化。`Window`对象是一个抽象类,其默认实现为`PhoneWindow`,这是Android特定的窗口实现。

       `PhoneWindow`在创建时会通过`setWindowManager()`方法与`WindowManager`进行关联。`WindowManager`是系统级组件,用于管理所有的窗口,包括窗口的创建、更新、删除等操作。`WindowManager`的管理最终由`WindowManagerService`(WMS)执行,这是一个运行在系统进程中的服务。

       在`PhoneWindow`中,`installDecor()`方法会初始化`DecorView`和`mContentParent`。`mContentParent`是一个`ViewGroup`,用于存放`setContentView()`传入的布局。通过`mLayoutInflater`的`inflate()`方法,将指定的布局资源添加到`mContentParent`中。

       `DecorView`是一个特殊的`FrameLayout`,包含了`mContentParent`。在完成布局的添加后,`DecorView`本身并没有直接与`Activity`建立联系,也没有被绘制到屏幕上显示。`DecorView`的绘制和显示发生在`Activity`的`onResume()`方法执行后,这时`Activity`中的内容才真正可见。

       当`Activity`执行到`onCreate()`阶段时,其内容实际上并没有显示在屏幕上,直到执行到`onResume()`阶段,`Activity`的内容才被真正显示。这一过程涉及到`ActivityThread`中的`handleResumeActivity()`方法,该方法会调用`WindowManager`的`addView()`方法,将`DecorView`添加到`WindowManagerService`中,完成`DecorView`的绘制和显示。

       `WindowManagerService`通过`addView()`方法将`DecorView`添加到显示队列中,并且在添加过程中,会创建关键的`ViewRootImpl`对象,进一步管理`DecorView`的布局、测量和绘制。`ViewRootImpl`会调用`mWindowSession`的`addToDisplay()`方法,将`DecorView`添加到真正的显示队列中。

       `mWindowSession`是`WindowManagerGlobal`中的单例对象,其内部实际上是一个`IWindowSession`类型,通过`AIDL`接口与系统进程中的`Session`对象进行通信,最终实现`DecorView`的添加和显示。

       通过`setView()`方法的实现,可以看到除了调用`IWindowSession`进行跨进程添加`View`之外,还会设置输入事件处理。当触屏事件发生时,这些事件首先通过驱动层的优化计算,通过`Socket`跨进程通知`Android Framework`层,最终触屏事件会通过输入管道传送到`DecorView`处理。

       在`DecorView`内部,触屏事件会通过`onProcess`方法传递给`mView`,即`PhoneWindow`中的`DecorView`。最终,事件传递到`PhoneWindow`中的`View.java`实现的`dispatchPointerEvent()`方法,并调用`Window.Callback`的`dispatchTouchEvent(ev)`方法。对于`Activity`来说,`dispatchTouchEvent()`方法最终还是会调用`PhoneWindow`的`superDispatchTouchEvent()`,然后传递给`DecorView`的`superDispatchTouchEvent()`方法,完成事件的分发和处理。

       综上所述,通过`setContentView()`的过程,我们可以清晰地看到`Activity`、`Window`、`View`之间的交互关系。整个过程主要由`PhoneWindow`组件主导,而`Activity`主要负责提供要显示的布局资源,其与屏幕的直接交互则通过`WindowManager`和`WindowManagerService`实现。