1.如何理解python@contextmanager装饰器源码?源码
2.consulmanager部署和使用
3.UE4 计时器管理 FTimerManager源码剖析
4.Framework层的Binder（源码分析篇）
5.一文总结Android系统服务大管家-ServiceManager
6.Android源码阅读分析：ActivityManagerService分析（一）——启动流程

如何理解python@contextmanager装饰器源码?

       理解@contextmanager装饰器的关键在于其如何简化上下文管理器的实现。通过将其包装在生成器函数中，推荐我们能使用with语句轻松执行前置和后置操作，源码而无需复杂的推荐try/finally语句。

       @contextmanager的源码实现依赖生成器和yield语句。当创建一个使用@contextmanager装饰器的推荐qwidget源码详解上下文管理器时，Python解释器会首先调用生成器函数的源码__enter__方法，返回生成器对象。推荐接着，源码解释器调用生成器对象的推荐__next__方法，执行yield语句前的源码代码。这允许我们在yield前执行前置操作，推荐并在yield后执行后置操作。源码当离开with语句时，推荐解释器会调用生成器的源码__exit__方法，执行清理操作。

       在使用with语句时，我们期望所有异常能够被处理，而不是向上抛出。在@contextmanager生成的上下文管理器中，通过try/except语句捕获所有异常，并将它们传递给yield语句。生成器函数决定是否处理这些异常，否则，异常将被重新抛出。

       总之，@contextmanager装饰器通过在生成器函数中实现上下文管理器，elementui的源码使得我们能够轻松使用with语句执行前置和后置操作。异常处理则通过try/except与yield语句结合，确保所有异常都能被妥善处理，同时保持代码简洁。

       下面是一个使用@contextmanager装饰器的示例：

       定义一个生成器函数my_context()，使用@contextmanager装饰器转换为上下文管理器。在with语句块开始时，打印一条消息。yield语句将控制权传递给with块内的代码，将返回值赋给message。with块结束后，打印一条离开上下文的消息。

       输出结果将显示进入和离开上下文的提示信息。如果在with块内部出现异常，finally语句块将确保上下文正确清理，即使异常发生。

consulmanager部署和使用

       书接上回 渐行渐远：prometheus的安装以及监控指标的配置

       这次主要介绍如何使用consulmanager 去监控各个监控项

       一 consulmanager安装

       github.com/starsliao/Te... #consulmanager项目地址

       consulmanager 是一个开源的项目，现在已经更名为tensuns，有兴趣的可以自行研究

       要想安装consulmanager，必须先安装下面三个 docker ，docker-compase， consul

       1.1 安装consul

       1.1.1 安装consul-基于centos7

       1.1.2 生成uuid

       1.1.3 配置文件设置

       1.1.4 启动consul

       访问方式 ip:

       1.2 安装docker和docker-compase

       1.2.1 安装docker

       1.2.2 安装docker-compase

       二 安装 ConsulManager

       2.1 下载源码

       下载地址 github.com/starsliao/Co...

       目录结构如下：

       2.2 docker-compose.yml 内容

       2.3 启动并访问

       三 配置consulmanager

       3.1 云主机管理

       3.1.1 同步云主机

       云主机管理就是可以自动同步云服务器到consulmanager这个上面

       前提是需要你在云账号里面创建access key 和secret key,这个账号还需要有访问主机的权限

       新增云资源

       创建完成之后，你可以手动同步，也可以自动同步，然后去云主机列表查看，是iapp 源码后缀否同步过来了

       3.1.2 批量云主机监控

       前提是每天主机需要安装好node-exporter

       选定好指定的组，选择好系统，点击生成配置，然后把这个配置，粘贴到prometheus的配置文件中

       进行重启prometheus

       然后进去到prometheus-target里进行查看

       当然如果你的node-exporter的端口不是,怎么办，打开cousul的web页面，可以自定义设置

       3.1.3 导入对应的模版

       导入ID：

       详细URL： grafana.com/grafana/das...

       3.1.4 设置告警规则

       3.2 blackbox站点监控设置

       3.2.1. 配置Blackbox_Exporter

       在Web页面点击

       Blackbox 站点监控/Blackbox 配置，点击

       复制配置，如下所示：

       复制配置到 blackbox.yml，清空已有的配置，把复制的内容粘贴进去，重启blackbox_exporter

       3.2.2 配置Prometheus

       在Web页面点击 Blackbox 站点监控/Prometheus 配置，点击复制配置。编辑Prometheus的

       prometheus.yml，把复制的内容追加到最后，reload或重启Prometheus

       3.2.3. 配置Prometheus告警规则

       在Web页面点击

       Blackbox 站点监控/告警规则，点击复制配置。

       编辑Prometheus的配置文件，添加 rules.yml，然后把复制的内容粘贴到rules.yml里面，reload或重启Prometheus。

       然后去prometheus查看告警规则是否生成

       3.2.4. 查看Prometheus

       在Prometheus的Web页面中，点击Status-Targets，能看到新增的Job即表示数据同步到Prometheus。

       3.2.5 新增tcp或者/grafana/das...

       最终在grafana访问的效果如下：

       四 总结

       到这里基本的监控项和报警规则都已经设定好了，接下来会介绍告警的方式和具体实现

UE4 计时器管理 FTimerManager源码剖析

       深入剖析UE4中的计时器管理系统FTimerManager，揭示其核心实现与优化细节。treesetremove方法源码在游戏开发中，精准的计时管理对实现流畅的物理交互和高效的性能优化至关重要。UE4提供了丰富的计时器功能，FTimerManager作为其核心组件，为开发者提供了一套灵活、高效的计时解决方案。

       FTimerManager通过FTimerUnifiedDelegate机制，允许开发者在任意时间点绑定逻辑到计时器上。这一设计使得计时逻辑的实现更加灵活，能够根据不同需求选择合适的执行时机。同时，FTimerManager支持计时器的暂停、重启和清除操作，为动态调整计时逻辑提供了便利。

       在实现细节上，FTimerManager通过稀疏数组TSparseArray来高效管理计时器列表，避免了传统数组的冗余内存使用，提升了内存管理和性能效率。这种数据结构在插入新计时器时，优先填补空洞，确保了空间使用的优化。

       当提及计时器的更新逻辑，FTimerManager在Tick函数中进行轮询处理。这一过程中，FTimerManager不仅维护了活跃计时器的状态，还负责在合适的rmi源码jdk时间点触发计时逻辑，确保逻辑的执行准确无误。此外，ETimerStatus数据类型用于记录每个计时器的生命周期状态，便于后续操作和状态管理。

       总结而言，FTimerManager在UE4中扮演着关键角色，不仅提供了高效、灵活的计时管理功能，还通过优化的数据结构和高效的时间管理机制，显著提升了游戏性能和开发效率。深入研究其源码，不仅能够对UE4的底层逻辑有更深刻的理解，还能启发开发者在自己的项目中进行创新和优化。

Framework层的Binder（源码分析篇）

       本文以android-.0.0_r的AOSP分支为基础，解析framework层的Binder工作原理。

       从ServiceManager的getService方法入手，其核心代码是通过getIServiceManager().getService(name)获取服务。首先，ServiceManager的实现与进程中的ProcessState密切相关，ProcessState是单例，负责打开和映射Binder驱动。构造函数中，它会初始化驱动、验证版本并设置线程数，接着进行binder映射。

       在ProcessState的getContextObject方法中，调用native函数android_util_Binder.cpp中的getContextObject()。这个函数通过handle 0（ServiceManager的handle）获取BpBinder对象，然后通过javaObjectForIBinder函数将其转换为Java中的类型。

       进一步分析，BpBinder与java层的Binder之间存在对应关系，通过BinderProxy NativeData创建单例的BinderProxy。然后，每个服务的BinderProxy实例化和计数处理都在这个过程中完成。ServiceManagerNative.asInterface方法简化了getIServiceManager的调用，通过调用asInterface实例化ServiceManagerProxy。

       IServiceManager接口通过AIDL生成，其代理类ServiceManagerProxy实际上是不必要的。aidl文件在编译时生成对应java代码，用于binder通信。通过aidl文件，我们可以看到如queryLocalInterface等方法的实现细节。

       在Parcel的协助下，客户端与服务端进行数据传递，通过序列化和反序列化进行交互。在transact函数中，对Parcel大小进行检查，避免数据传输过大导致的问题。最后，客户端与binder驱动的通信过程涉及了Transaction数据的写入、等待响应、数据处理和内存回收等步骤。

       总的来说，framework层的Binder工作涉及服务管理、数据转换、通信协议和内存管理等环节，理解这些有助于深入掌握Binder的工作机制。

一文总结Android系统服务大管家-ServiceManager

       本文以源码文件为切入点，旨在解析Android系统服务大管家 - ServiceManager的具体运作。首先介绍ServiceManager简介，定义了其为C/C++编写的系统服务，并说明其源码位于/framework/native/cmds/servicemanager，通过Android.bp文件明确，该服务以程序方式构建，启动入口位于main.cpp的main()函数。运行期间，ServiceManager将不断执行looper->pollAll(-1)操作，并默认依托于设备节点/dev/binder，同时也允许通过参数设置自定义节点。ServiceManager作为binder机制的核心组件，负责实现进程间通信。

       文章接下来指出在Android.bp文件中，ServiceManager对应程序名为servicemanager，同样存在vndservicemanager程序。两者的源码一致，主要差异在于rc文件，vndservicemanager通过/dev/vndbinder作为binder驱动。在Android启动时，vndservicemanager和servicemanager都被init拉起，它们的功能区别体现在如何指定binder驱动路径。

       文章深入探讨ServiceManager的启动过程。首先介绍init进程由内核管理，该进程在启动时，依据init.rc文件拉起关键服务进程，其中包括ServiceManager。在特定目录下（/framework/native/cmds/servicemanager/），存在servicemanager.rc文件，这是servicemanager初始化的配置文件。

       进入ServiceManager详细剖析阶段。主要步骤包括获取驱动名称、初始化进程状态、创建ServiceManager实例、设置上下文对象、创建并启动looper，并执行pollAll操作。其中获取驱动名称步骤依据命令行参数或默认采用/dev/binder。初始化进程状态涉及调用initWithDriver()设置libbinder支持特定驱动，同时为进程配置参数。创建ServiceManager实例并作为上下文对象，随后创建并启动looper，执行pollAll(-1)完成核心服务功能实现。

       文章最后指出ServiceManager的唤醒时机，通常发生在系统启动、服务注册、通信调用等场景。在Android系统中，ServiceManager的作用主要为实现应用程序与系统组件之间通过Binder机制的跨进程通信，访问和管理系统级服务，从而提供丰富的功能扩展性和灵活性。

Android源码阅读分析：ActivityManagerService分析（一）——启动流程

       本文深入解析了Android源码中的ActivityManagerService，即AMS的核心功能与启动流程。AMS作为管理Android四大组件的关键组件，其重要性不言而喻。本篇将从AMS的创建与启动逻辑开始分析，为理解其内部机制打下基础。

       AMS的创建始于SystemServer的startBootstrapServices方法。此方法通过SystemServiceManager的startService方法启动Lifecycle类实例，从而创建AMS对象。Lifecycle作为适配器，连接了AMS与SystemService之间的交互。再通过Lifecycle的构造器，创建出AMS实例。

       创建过程中，AMS线程、UI线程、CpuTracker线程和系统目录被初始化，同时StackSupervisor与ActivityStarter也得以创建，完成AMS对象的创建。

       随后，ActivityManagerService的startService(SystemService)方法执行，完成服务的注册与启动。Lifecycle的onStart方法调用ActivityManagerService的start方法，启动关键操作。

       在SystemServer的startBootstrapServices方法中，创建完AMS后，执行其setSystemProcess方法，为系统进程启动Application实例与服务注册。然后，SystemServer继续调用startBootstrapServices、startCoreServices与startOtherServices方法，启动更多系统服务与持久化进程，完成桌面Activity的启动与广播发布。

       文中总结了AMS创建与启动的关键步骤，并预告后续文章将深入探讨AMS的具体使用、对四大组件的管理以及内存管理等内容。通过本篇解析，读者能更直观地理解Android系统中AMS的核心功能与作用。

AndroidFramework 之启动 ServiceManager

        本文源码基于 Android ，涉及相关源码如下。

        ServiceManagaer 是 Binder 的守护进程，在 Binder 机制中起着重要的作用。本文将从源码的角度对其进行分析，整体流程如下：

        时序图如下。

        先来看看 ServiceManager 是如何启动的：

        在 Zygote 一文中说过， init 进程启动的第二阶段会解析 init.rc 文件。

        在这之后会触发 trigger init 。

        结合 init.rc 看看 action init 做了什么。

        当触发 trigger init 后，会启动 servicemanager 服务，其声明如下。

        对应的执行文件为 /system/bin/servicemanager ，在编译前位于 frameworks/native/cmds/servicemanager 下，来看看 Android.bp 。

        其对应的源码为 service_manager.c 和 binder.c ，入口函数 main() 位于 servicemanager.c 。

        启动完 ServiceManager 后会打开 Binder 驱动。

        在 main() 中首先调用 binder_open() 。

        binder_open() 主要做了如下事情：

        给结构体 binder_state 分配内存。

        系统调用 open() 打开 /dev/binder ，如果打开驱动失败，则执行 fail_open 释放内存。

        简单的解释一下什么是系统调用？

        由于需要限制不同的程序之间的访问能力，防止程序获取别的程序的内存数据， CPU 划分出两个权限等级，用户态和 内核态。

        所有的用户程序都是运行在用户态，但有时需要做一些内核态的事情，而唯一可以做这些事情的就是操作系统，所以程序需要向操作系统发起请求，以程序的名字来执行这些操作。这时就需要一个从用户态切换到内核态但不能控制内核态中执行的机制，这种机制就是 系统调用。

        系统调用 ioctl() 传入 BINDER_VERSION 命令获取 Binder 驱动版本，对比版本是否一致，不一致则执行 fail_open 释放内存。

        系统调用 mmap() 映射 kb 的内存空间，即把 Binder 驱动文件的 kb 映射到内存空间供 ServiceManager 使用，内存映射失败则执行 fail_map ，关闭 fd 并释放内存。

        ServiceManager 进程 mmap 的内存大小可以通过 adb shell 命令查看。

        可以看到内存映射地址为 0xff ~ 0xf ，差为 0x 即十进制的 kb 。

        打开 Binder 驱动后会将 ServiceManager 设置为上下文管理者。

        调用 binder_become_context_manager() 。

        android 新增 BINDER_SET_CONTEXT_MGR_EXT 命令来设置安全的上下文管理者，如果设置失败，则使用原有的 BINDER_SET_CONTEXT_MGR 命令来设置上下文管理者，两者区别在于是否携带参数。

        最后会进入循环，从 Binder 驱动读取和解析数据。

        调用 binder_loop() 进入循环，不断地通过系统调用 ioctl() 从 Binder 驱动读取数据，并通过 binder_parse() 进行数据解析。

        注意这里调用 binder_loop() 传入的 svcmgr_handler() ，后面会使用到。

        binder_write() 会封装 struct binder_write_read ，并通过系统调用 ioctl() 将对应的命令传递给 Binder 驱动。

        binder_parse() 用来解析从 Binder 驱动读取到的数据，然后根据不同的命令执行对应的操作。

        因为 cmd 命令可能有多个，所以通过 while 循环每次处理一个 cmd 命令，多 cmd 的结构大致如下图所示。

        这里重点看下 BR_TRANSACTION 命令。

        BR_TRANSACTION 是 Binder 驱动向 Server 端发送请求数据。

        binder_transaction_data 的结构如下，其表明了 transcation 传输的具体语义，语义码记录在 code 中，不同语义码携带的数据是不同的，这些数据由 data 指定。

        在解析完 binder_transaction_data 的具体语义后，会调用前面传给 binder_loop() 的 svcmgr_handler() ，其实就是 switch case 语义码做不同的事情。

        ServiceManager 的功能其实很简单：

        至此 ServiceManager 就分析完了。