1.Yii2源码分析——应用是码分如何启动及其生命周期
2.Spring Boot源码解析（四）ApplicationContext准备阶段
3.application在哪个包
4.巨硬Application Inspector初体验On Mac
5.SpringBoot源码学习——SpringBoot自动装配源码解析+Spring如何处理配置类的
6.SpringBoot 一SpringApplication启动类的Args详解

Yii2源码分析——应用是如何启动及其生命周期

       Yii2是一个广泛使用的Web编程框架，旨在构建各种基于PHP的码分Web应用。通常，码分Web应用通过入口文件启动，码分无论是码分Web应用入口还是命令行入口，核心都是码分源码变成软件先初始化应用类，最终由run方法启动整个Yii2应用流程。码分

       运行方法清晰地展示了整个Web应用框架的码分生命周期。应用状态标志用于在执行对应状态时触发处理函数，码分直至响应完成，码分结束整个应用流程。码分其中，码分trigger方法体现了框架中的码分事件概念，而getRequest方法体现了组件概念，码分这一概念对控制反转这一思路的码分实现尤为关键，后续会深入探讨。

       在运行方法的代码中，可以看到Yii2关键核心概念的良好体现。通过返回应用主体的继承关系，我们了解到了基类的作用。例如，Configurable类定义为接口，Yii2在实例化对象时不使用new关键字，而是依赖注入容器(DI Container)获取对象。Configurable接口表示实现它的类必须遵循一定的约定，可以通过配置数组实例化和初始化对象。配置格式类似自定义组件配置方式。实现这种配置方式的关键在于BaseObject类，它是Yii2对象的基础类，提供了属性支持。

       成员变量与属性的goidea源码扫描区别与联系在于：成员变量反映类的结构构成，属性反映类的逻辑意义；成员变量无读写权限控制，属性可设置为只读或只写；成员变量不进行读取后处理，属性则可以。更多关于成员变量和属性的探讨，有兴趣的读者可以继续研究。

       组件（Component）与基类BaseObject最大的区别在于支持行为，行为允许在不改变类继承关系的情况下增强组件功能。行为通过组件响应事件，自定义或调整组件正常执行的代码。通过对比BaseObject和Component的魔术方法实现，可以了解行为的核心。

       服务定位器（ServiceLocator）是用于快速查找并定位服务的容器，位于vendor/yiisoft/yii2/di文件夹下。通过注册服务并访问服务实例，可以实现对服务的管理。ServiceLocator有两个属性：_components和_definitions，分别用于存储服务实例和服务定义。

       Module类位于base目录下，是基础类之一。可以将Module理解为一个子应用程序，如debug、gii等独立模块。模块由模型、视图、控制器和其他支持组件组成，终端用户可以访问已安装在主应用中的模块控制器。

       在Module类中，runAction方法非常重要，实现了根据路由访问调用相应控制器类，从而处理和响应请求。殡葬公墓源码最后，我们看到yii\web\Application类继承自yii\base\Application抽象类，而yii\base\Application继承自Module类。yii\web\Application的主要功能是定义核心组件加载位置和实现handleRequest方法，这一方法在启动应用流程中起关键作用。通过分析handleRequest，可以发现响应请求的核心在于调用Module类中的runAction方法。

       至此，我们对Yii2框架的生命周期和关键概念有了基本的讲解与分析。接下来的文章将深入探讨Yii2的基本概念的核心实现以及设计原则和设计思想的应用。

Spring Boot源码解析（四）ApplicationContext准备阶段

       深入解析Spring Boot中ApplicationContext的准备阶段，本文将带你从环境设置、后处理到初始化器的执行，直至广播事件和注册应用参数等关键步骤的全面解读。

       环境的设置是准备阶段的起点，主要涉及三个步骤。首先，通过AnnotatedBeanDefinitionReader和ClassPathBeanDefinitionScanner，将包含实际参数的Environment重新配置到这些实例中，以确保ApplicationContext能够准确理解和处理后续的配置信息。

       紧接着，对ApplicationContext进行后处理。这包括注册beanNameGenerator、设置resourceLoader和conversionService。对于一般配置的Spring Boot应用，这些部分往往为空，因此主要执行的是设置conversionService，确保数据转换的顺利进行。

       处理Initializer阶段，Spring Boot通过遍历META-INF/spring.factories中的猛虎掘金源码initializer加载配置，执行8个预设的Initializer方法，它们负责执行特定的功能，例如增强或定制ApplicationContext行为，尽管具体实现细节未详细展开。

       广播ApplicationContextInitialized和BootstrapContextClosed事件，以及注册applicationArguments和printedBanner，是准备阶段的后续操作，确保ApplicationContext能够接收外部参数并展示启动信息，同时为ApplicationContext的后续操作做准备。

       在设置不支持循环引用和覆盖后，调整lazy initialization为默认不允许。Spring Boot通过配置确保依赖注入过程的高效性和稳定性，同时提供了开启懒加载的选项，允许在实际使用时加载bean，提高应用启动性能。

       最后，处理重排属性的post processor，确保ConfigurationClassPostProcessor加载的property在正确的位置被处理，维护配置加载的逻辑顺序和依赖关系。

       资源的加载是准备阶段的最后一步，将PrimarySource与所有其他源整合到allSources中，并返回一个不可修改的集合。这个过程确保了资源的高效访问和管理，为ApplicationContext的后续操作提供基础。

       在完成启动类的加载后，Spring Boot通过构建BeanDefinitionLoader并配置相应的组件，将主类Application加载到Context中。这一过程是动态且高效的，确保了应用的快速启动和资源的有效管理。

       至此，题库源码aspSpring Boot中ApplicationContext的准备阶段全面解析完成，从环境设置到启动类加载，每一个步骤都为ApplicationContext的高效运行打下了坚实的基础。接下来，我们将探讨ApplicationContext的刷新过程，敬请关注。

application在哪个包

       application包的位置取决于编程语言和开发框架。

       在软件开发中，"application"一词常用于描述应用程序，而具体的包位置取决于你使用的是哪种编程语言或开发框架。例如，在Java开发中，一个名为“application”的类可能位于一个名为“com.example”的包下。而在其他语言如Python中，可能没有明确的包概念，因为Python倾向于使用模块和文件结构来组织代码。因此，要确定application在哪个包，需要考虑以下几个因素：

       1. 编程语言：不同的编程语言有其特定的组织和存储代码的方式。例如，Java使用包来组织类，而Python则更倾向于使用模块和目录结构。

       2. 开发框架：在特定的开发框架中，例如Java的Spring框架或Python的Django框架，通常有自己的代码组织方式。这些框架可能有特定的目录结构或命名约定。

       3. 项目结构：即使在相同的编程语言或框架内，不同的项目也可能有不同的代码组织方式。开发者可以根据自己的需求创建包和目录结构。

       因此，要确定application在哪个包，需要具体查看所使用的编程语言和开发框架的文档，或者查看项目的源代码结构。无法给出一个通用的答案，因为位置会因项目而异。如果需要关于特定编程语言或框架的详细信息，请提供更多上下文信息以便给出更准确的答案。

巨硬Application Inspector初体验On Mac

       Application Inspector 是微软开源的软件特征源码分析工具，主要功能在于源码分析与检查。用户需首先配置好 dotnet 环境，通过巨硬提供的安装包完成安装。接着，将/usr/local/lib加入profile并source使其生效，运行dotnet --version验证安装成功。

       随后，用户需将代码编译至目标平台，如osx-x，编译后，将运行成功提示信息反馈给用户。体验过程中，用户在命令行输入命令，进入编译后的目录，尝试运行Application Inspector。

       测试运行后，可以看到其支持的命令和功能，如analyze命令，用户可输入参数进行源码分析。对于本地源码，使用analyze命令，结果默认以html格式展示，检测速度快，完成后自动打开报告页面。

       报告页面设计美观，用户反馈体验时指出，安装与使用较为方便，输出结果美观。然而，对于特定语言如java源码，工具支持度一般，输出内容主要涉及js和html，作为代码审计工具，功能有限，可能与默认规则有关。用户建议，期待工具持续发展，增强功能，以提高其在代码审计领域的应用价值。

SpringBoot源码学习——SpringBoot自动装配源码解析+Spring如何处理配置类的

       SpringBoot通过SPI机制，借助外部引用jar包中的META-INF/spring.factories文件，实现引入starter即可激活功能，简化手动配置bean，实现即开即用。

       启动SpringBoot服务，通常使用Main方法启动，其中@SpringBootApplication注解包含@SpringBootConfiguration、@EnableAutoConfiguration、@ComponentScan，自动装配的核心。

       深入分析@SpringBootApplication，其实质是执行了@SpringBootConfiguration、@EnableAutoConfiguration、@ComponentScan三个注解的功能，简化了配置过程，强调了约定大于配置的思想。

       SpringBoot的自动装配原理着重于研究如何初始化ApplicationContext，Spring依赖于ApplicationContext实现其功能，SpringApplication#run方法为初始化ApplicationContext的入口。

       分析SpringApplication构造方法，SpringApplication.run(启动类.class, args) 实际调用的是该方法，其关键在于根据项目类型反射生成合适的ApplicationContext。

       选择AnnotationConfigServletWebServerApplicationContext，此上下文具备启动Servlet服务器和注册Servlet或过滤器类型bean的能力。

       准备刷新ApplicationContext，SpringBoot将主类注册到Spring容器中，以便@ConfigurationClassPostProcessor解析主类注解，发挥@Import、@ComponentScan的作用。

       刷新ApplicationContext过程包括一系列前置准备，如将主类信息封装成AnnotatedGenericBeanDefinition，解析注解并调用BeanDefinitionCustomizer自定义处理。

       解析配置类中的注解，通过BeanDefinitionRegistryPostProcessor和ConfigurationClassParser实现，筛选、排序候选者，并解析@Import注解实现自动装配。

       增强配置类，ConfigurationClassPostProcessor对full模式的配置进行增强，确保@Import正确处理，CGLIB用于增强原配置类，确保生命周期完整，避免真正执行@Bean方法逻辑。

       深入解析AutoConfigurationImportSelector实现自动装配，通过spring.boot.enableautoconfiguration设置开启状态，读取spring-autoconfigure-metadata.properties和META-INF/spring.factories文件，筛选并加载自动配置类。

SpringBoot 一SpringApplication启动类的Args详解

       传递参数的一种方式，如在启动时使用java -jar --spring.profiles.active=prod或更改自定义配置信息。使用方式是--key=value，其配置优先于项目内部的配置。

       在大部分使用SpringBoot进行开发的项目中，启动类的格式通常是SpringApplication.run(SpringBootDemoPropertiesApplication.class, args);然而，在日常使用中，我们似乎很少使用args参数。那么，args参数究竟有什么作用呢？让我们通过源码来一探究竟。

       启动一个带有web项目的示例，并在application.yml配置文件中定义一个自定义属性developer.name=test。以下是启动类，其中设置了args参数。

       1. Args使用场景一：在run方法中，args第一次出现在SpringApplication类中。getSpringFactoriesInstances(SpringApplicationRunListener.class, types, this, args)方法用于实例化SpringApplicationRunListener的实现类（配置在spring.factories中的实现类）。关于spring.factories的用法，可以参考SpringBoot 二spring.factories加载时机分析。此项目中只在spring.factories中找到了一个实现类org.springframework.boot.context.event.EventPublishingRunListener。在实例化的过程中，将两个参数{ SpringApplication和String[] args}传递过去。对应到的构造函数如下，并且在EventPublishingRunListener的方法中都有把Args传递下去。

       2. Args使用场景二：上述SpringApplicationRunListeners完成后，接下来就到了SimpleCommandLinePropertySource。主要看上面的new Source(args)方法。SimpleCommandLinePropertySource也是一个数据源PropertySource，但它主要是存放命令行属性，例如启动参数Args中的属性就会保存在这个对象中。并且SimpleCommandLinePropertySource会被放入到Environment中，所以也可以通过@link Environment.getProperty(String)来获取命令行的值。看构造函数，可以知道实例化之后的SimpleCommandLinePropertySource是name为commandLineArgs的数据源。属性值的解析规则如下。往下走到了，这个方法的作用就是把我们的Args放到到Spring的environment中；sources.addFirst(new SimpleCommandLinePropertySource(args))。看到方法是addFirst()，这说明什么？说明命令行的数据源被放到了最前面；那么命令行数据源的属性就会被最优先采用。那么我们就可以通过Environment.getProperty(String)获取args中的值了。那么我们可以利用这个args做什么用呢？可以用它来写入配置，并且是覆盖项目中的配置（因为它的优先级更高）；例如java -jar --spring.profiles.active=dev。这里就算yml配置的是prod，最终使用的是dev。

Application中的 Context 和 Activity 中的Context区别

        Context在我们开发中经常用到，不管是Framework提供给我们的四大组件，还是应用级别的Application，还是负责表现层的View相关类，甚至连我们很多时候创建的实体类都会需要持有一个Context的引用。那么Context到底是什么呢？

        建议看这个： /p/bde4cb

        Context英文释义是当前上下文，或者当前场景上，

        官方文档：Context

        public abstractclass Context extends Object

        Interface to globalinformation about an application environment. This is an abstract class whoseimplementation is provided by the Android system. It allows access toapplication-specific resources and classes, as well as up-calls forapplication-level operations such as launching activities, broadcasting andreceiving intents, etc.

        由官方文档，我们可以知道：

        1.该类是一个抽象（abstract class）类；

        2.它描述的是一个应用程序环境的信息，即上下文；

        3.通过它（Context）我们可以获取应用程序的资源和类，也包括一些应用级别的操作（例如，启动 Activity,广播和服务等）;

        前面我们讲过 Context 是一个抽象类，通过 Context我们可以获取应用程序的资源和类，调用它们的方法，那么具体定义的方法有哪些呢？我们来看一下 Context 的源码：

        源码里的方法太多了，总共 行。我们从以上部分源码看到了熟悉的对象---Application、Activity、Service、Broadcast、这些对象和 Context 的关系到底是什么呢？我们看一下官方文档可知：

        1.Acitiivity 继承自ContextThemeWrapper--->再继承ContextWrapper--->Context。

        2.Appliction 、Service继承自ContextWrapper--->再继承Context。

        3.Application、Service 和 Activity 最终都是继承自Context，所以它们是同一个上下文。

        通过以上的继承关系，我们就可以知道，Context的具体作用会包括：

        - 启动一个新的Activity

        - 启动和停止Service

        - 发送广播消息(Intent)

        - 注册广播消息(Intent)接收者

        - 可以访问APK中各种资源，如Resources和AssetManager

        - 创建View

        - 访问Package的相关信息

        - APK的各种权限管理

        由上面分析的继承关系，我们可以知道，Context创建的时机有三个：

        ①创建Application 对象时， 而且整个App共一个Application对象；

        ②创建Service对象时；

        ③创建Activity对象时；

        所以应用程序App共有的Context数目公式为：

        Service个数 + Activity个数 + 1（Application对应的Context实例）

        如上，Android中context可以作很多操作，但是最主要的功能是加载和访问资源。在android中常用的context有两种，一种是application context，一种是activity context，通常我们在各种类和方法间传递的是activity context。

        两者的区别：

        this是Activity 的实例，扩展了Context，其生命周期是Activity 创建到销毁。getApplicationContext()返回应用的上下文，生命周期是整个应用，应用摧毁它才被摧毁。Activity.this的context 返回当前activity的上下文，属于activity ，activity摧毁时被摧毁。

        使用Context时最需要注意的一个点就是，使用了不正确的context，比如有一个全局的数据操作类用到了context，这个时候就要getApplicationContext 而不是用ACtivity，如果在这个全局操作中引用的是Activity的context，那么就会一直引用Activity的资源，导致GC无法回收这部分内存，从而最终导致了内存泄漏。

        内存泄漏是开发中常见的错误之一，能不能发现取决于开发者的经验，当然了我们也会依赖现有的内存泄漏库，但是如果我们在开发的源头减少内存泄漏的概率，那么后期的工作会少很多。

        以下是避免context相关的内存泄露，给出的几点建议：

        以下的表列举的是三种Context对象的对应使用场景：

        从表中可以看到，和UI相关的都使用Activity的Context对象。

        小结：如上分析，Context在对应开发里的来源就是三个——Activity、Service和Appliaction，那么我们该如何选择使用哪一个Context对象呢？一个比较简单的方法是，当你无法确定使用某个Context对象是否会造成长引用导致内存泄漏时，那么就使用Appliaction的Context对象，因为Appliaction存在于整个应用的生命周期内。

        在实际开发中，我们往往会为项目定义一个Applictaion，然后在AndroidMainfest.xml文件中进行注册，

        而且在自定义Application往往会定义好一个静态方法，用以全局获取application实例：

        Activity和Application都是Context的子类，但是他们维护的生命周期不一样。前者维护一个Acitivity的生命周期，所以其对应的Context也只能访问该activity内的各种资源。后者则是维护一个Application的生命周期。

        1.如何判断context是属于哪个activity？

        2.全局不同如何获取对应的context？

        静态加载一个Fragment，在onCreateView()方法中通过getActivity获取上下文实例：

        3.四大组件可以像普通Java类一样，采用new的方式实例化吗？

        Android程序不像Java程序一样，随便创建一个类，写个main()方法就能运行，Android应用模型是基于组件的应用设计模式，组件的运行要有一个完整的Android工程环境，在这个环境下，Activity、Service等系统组件才能够正常工作，而这些组件并不能采用普通的Java对象创建方式，new一下就能创建实例了，而是要有它们各自的上下文环境，也就是我们这里讨论的Context。可以这样讲，Context是维持Android程序中各组件能够正常工作的一个核心功能类。