服务器程序源代码分析之二:php-fpm

服务器程序源代码分析之二:php-fpm,第1张

php作为排名top2 互联网开发工具,非常流行,可以参考:中国最大的25个网站采用技术选型方案

php这个名称实际上有两层含义

直接定义:

php-fpm从php5.3.3开始已经进入到php源代码包,之前是作为patch存在的

很少人会去读php本身源代码,我6年前解决php内存泄露问题的时候做了些研究,最近再查看了一番,发现php的开发者很有诚意,这是一款非常出色的服务器软件,支持如下

在linux服务器上,如果不设置 events.mechanism ,那么默认就是采用epoll,所以

php-fpm的IO模型&并发处理能力和nginx是完全一致

nginx以性能卓越闻名,大部分程序员都认为php效率低下,看了源代码,才知道这是传奇啊

在高性能部署的时候,大家往往会针对性的优化nginx 。我自己之前部署php程序也犯了错误,8G内存的server,php-fpm的max children都会设置128+,现在看来太多了,参考nginx的部署:

php-fpm配置为 3倍 cpu core number就可以了

php-fpm稳定性比nginx稍差 这是因为php-fpm内置了一个php解析器,php-fpm进程就和php程序捆绑了,如果php脚本写得不好,有死循环或者阻塞在某个远端资源上,会拖累加载它的php-fpm进程

而nginx和后端应用服务器之间通过网络连接,可以设置timeout,不容易堵死的

php-fpm的fastcgi是短连接 我原以为是长连接的,看了代码才知道也是短连接,处理一个request就关闭掉

php-fpm接口采用fastcgi 非常遗憾,php-fpm和fastcgi完全绑定了,无法独立使用 。只能部署在支持http-fcgi协议转换程序背后(nginx)。其实可以考虑在php-fpm代码包里面引入http协议支持,这样php-fpm可以独立运行,让nodejs无话可说

php-fpm等同于OpenResty OpenResty是一个国人开发的nginx模块,就是在nginx引入lua解释器. 实际上,它和php-fpm的唯一差别就是一个采用php语法,一个用lua,所以OpenResty要作为nginx增强包使用还可以,要选择它作为一个主要编程工具,没有任何必要

从架构上来说,php-fpm已经做到最好,超过大多数 python部署工具,我再也不黑它了

源程序:

运行结果:

父进程显示字符“father”,子进程分别显示字符“child1”和字符“child2“。

为了更好的分析源程序,我加入获得进程id的代码:

运行结果:

进程创建及分析:

/*执行while((p1=fork() )==-1)后,父进程创建了第一个子进程,子进程复制了父进程的资源,成为独立于父进程的一个进程,并且第一个子进程的fork()返回值为0,父进程的fork()返回值为刚创建的子进程号4。*/

/*执行while((p2=fork() )==-1)后,子进程再创建了第二个子进程,第二个子进程复制了第一个子进程的资源,成为独立的一个进程,并且第二个子进程的fork()返回值为0,第一个子进程的fork()返回值为刚创建的子进程号5。*/

三个进程的pid分别是:

父进程=3

第一个子进程=4

第二个子进程=5

您可能听说过View ,ViewManager,Window,PhoneWindow,WindowManager,WindowManagerService,可是你知道这几个类是什么关系,干嘛用的。概括的来说,View是放在Window中的,Window是一个抽象类,它的具体实现是PhoneWindow,PhoneWindow还有个内部类DecorView,WindowManager是一个interface,继承自ViewManager,它是外界访问Window的入口,,提供了add/remove/updata的方法 *** 作View,WindowManager与WindowManagerSerice是个跨进程的过程,WindowManagerService的职责是对系统中的所有窗口进行管理。如果您不太清楚,建议往下看,否则就不要看了。

Android系统的Window有很多种,大体上来说,Framework定义了三种窗口类型;

这就是Framework定义了三种窗口类型,这三种类型定义在WindowManager的内部类LayoutParams中,WindowManager讲这三种类型 进行了细化,把每一种类型都用一个int常量来表示,这些常量代表窗口所在的层,WindowManagerService在进行窗口叠加的时候,会按照常量的大小分配不同的层,常量值越大,代表位置越靠上面, 所以我们可以猜想一下,应用程序Window的层值常量要小于子Window的层值常量,子Window的层值常量要小于系统Window的层值常量。 Window的层级关系如下所示。

上面说了Window分为三种,用Window的type区分,在搞清楚Window的创建之前,我们需要知道怎么去描述一个Window,我们就把Window当做一个实体类,给我的感觉,它必须要下面几个字段。

实际上WindowManager.LayoutParams对Window有很详细的定义。

提取几个重要的参数

Window是一个是一个抽象的概念,千万不要认为我们所看到的就是Window,我们平时所看到的是视图,每一个Window都对应着一个View,View和Window通过ViewRootImpl来建立联系。有了View,Window的存在意义在哪里呢,因为View不能单独存在,它必须依附着Window,所以有视图的地方就有Window,比如Activity,一个Dialog,一个PopWindow,一个菜单,一个Toast等等。

通过上面我们知道视图和Window的关系,那么有一个问题,是先有视图,还是先有Window。这个答案只有在源码中找了。应用程序的入口类是ActivityThread,在ActivityThread中有performLaunchActivity来启动Activity,这个performLaunchActivity方法内部会创建一个Activity。

如果activity不为null,就会调用attach,在attach方法中通过PolicyManager创建了Window对象,并且给Window设置了回调接口。

PolicyManager的实现类是Policy

这样Window就创建出来了, 所以先有Window,后有视图,视图依赖Window存在 ,再说一说视图(Activity)为Window设置的回调接口。

Activity实现了这个回调接口,当Window的状态发生变化的时候,就会回调Activity中实现的这些接口,有些回调接口我们还是熟悉的,dispatchTouchEvent,onAttachedToWindow,onDetachedFromWindow等。

下面分析view是如何附属到window上的,通过上面可以看到,在attach之后就要执行callActivityOnCreate,在onCreate中我们会调用setContentView方法。

getWindow获取了Window对象,Window的具体实现类是PhoneWindow,所以要看PhoneWindow的setContentView方法。

这里涉及到一个mContentParent变量,他是一个DecorView的一部分,DecorView是PhoneWindow的一个内部类,我先介绍一下关于DecorView的知识。

DecorView是Activity的顶级VIew,DecorView继承自FrameLayout,在DecorView中有上下两个部分,上面是标题栏,下面是内容栏,我们通过PhoneWindow的setContentView所设置的布局文件是加到内容栏(mContentParent)里面的,View层的事件都是先经过DecorView在传递给我们的View的。

OK在回到setContentView的源码分析,我们可以得到Activity的Window创建需要三步。

- 1、 如果没有DecorView,在installDecor中创建DecorView。

- 2、将View添加到decorview中的mContentParent中。

- 3、回调Activity的onContentChanged接口。

先看看第一步,installDecor的源码

installDecor中调用了generateDecor,继续看

直接给new一个DecorView,有了DecorView之后,就可以加载具体的布局文件到DecorView中了,具体的布局文件和系统和主题有关系。

在看第二步,将View添加到decorview中的mContentParent中。

直接将Activity视图加到DecorView的mContentParent中,最后一步,回调Activity的onContentChanged接口。在Activity中寻找onContentChanged方法,它是个空实现,我们可以在子Activity中处理。

到此DecorView被创建完毕,我们一开始从Thread中的handleLaunchActivity方法开始分析,首先加载Activity的字节码文件,利用反射的方式创建一个Activity对象,调用Activity对象的attach方法,在attach方法中,创建系统需要的Window并为设置回调,这个回调定义在Window之中,由Activity实现,当Window的状态发生变化的时候,就会回调Activity实现的这些回调方法。调用attach方法之后,Window被创建完成,这时候需要关联我们的视图,在handleLaunchActivity中的attach执行之后就要执行handleLaunchActivity中的callActivityOnCreate,在onCreate中我们会调用setContentView方法。通过setContentView,创建了Activity的顶级View---DecorView,DecorView的内容栏(mContentParent)用来显示我们的布局。 这个是我们上面分析得到了一个大致流程,走到这里,这只是添加的过程,还要有一个显示的过程,显示的过程就要调用handleLaunchActivity中的handleResumeActivity方法了。最后会调用makeVisible方法。

这里面首先拿到WindowManager对象,用tWindowManager 的父接口ViewManager接收,ViewManager可以

最后调用 mDecor.setVisibility(View.VISIBLE)设置mDecor可见。到此,我们终于明白一个Activity是怎么显示在我们的面前了。

参考链接:

http://blog.csdn.net/feiduclear_up/article/details/49201357


欢迎分享,转载请注明来源:内存溢出

原文地址: https://outofmemory.cn/yw/11086811.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2023-05-13
下一篇 2023-05-13

发表评论

登录后才能评论

评论列表(0条)

保存