【Android GUI】FramebufferNativeWindow与Surface FramebufferNativeWindow是为surfaceflinger服务的,由Gralloc提供。surface虽然为应用程序服务的,但是本质上还是由surface flinger服务统一管理的。
【Android GUI】从总体上了解Android的GUI体系 Android的HAL层提供了Gralloc,包括fb和gralloc两个设备。VSync是“Project Butter”加入的同步机制,可以通过硬件产生,也可以通过软件,即VSyncThread模拟。Framebuffer是内核系统提供的图形硬件的抽象描述,它占用了系统存储空间的一部分,是一块包含屏幕显示信息的缓冲区。Gralloc对应的模块是由FramebufferNativeWindow在构造函数中加载的。Android中,Framebuffer提供的设备文件节点是。
【Android】Activity task和Instrumentation杂谈 Android不仅可以装载众多的系统组件,还可以将它们跨进程组成ActivityTask,这个特性使得每个应用都不是孤立的。
【Android surface 】二:源码分析App的surface创建过程 我们来回顾和总结一路过来的分析,为后续破解surfaceflinger做准备。创建了一个SurfaeComposerClient,调用它的createSurface,拿到一个SurfaceControl对象。调用SurfaceControl的writeToParcel把信息写道parcel中。根据parcel的信息构造一个surface对象,并保存到java层的mSurface对象中。这样viewroot得到了一个native的surface对象。
【Android Surface】从Activity的创建到Surface的创建,源码分析1 我们知道Android绘制图形依靠的是surface和surface flinger,但是当我说起这句话的时候,你脑海里面能复现出一幅图画,里面展示了Android绘制图像,然后渲染到屏幕这整个执行流程吗?如果没有,一起来研究研究Android的这个机制。我想,理清楚之后,作为Android开发的我们,必定获益良多。先看看surface系统的的整体关系:不论是使用Skia绘制二维图像,还是使用OpenGL绘制三维图像,APP都会Surface进行交互。
【Android ServiceManager】从源码入手,剖析ServiceManager是如何处理客户端的请求的? 代码分析到这里,我们总结下,前面代码中ServicManager打开了binder设备,让自己成为manager,接着进入循环并通过ioctl与binder设备进行交互,用于来处理客户端发过来的消息。我们不禁去思考ServiceManager存在的价值是什么。ServiceManager可以通过字符串查找对应的Service,这个与DNS很类似。并且ServiceManager对服务进行了权限控制,使得并非所有服务都能进行注册,这无疑提高了Android的安全性和各种服务的条理性。
【Android Binder】从源码出发,剖析Binder机制的实现流程 在这里我们可以做一个总结:这行代码中创建了BpBinder对象,然后把BpBinder对象作为参数新建了了一个BpServiceManager对象。sm就是这个BpServiceManager对象。一个是BpBinder对象,它的handle值为0,。一个BpServiceManager对象,它的mRemote值为BpBinder对象。而且BpServiceManager实现IServiceManager接口,又有了BpBinder作为通信代表。到这里进行通信的准备做的差不多了。但是还差些什么。
【Android Handler】从源码出发,一步步窥探Handler在Java层的数据结构关系和执行原理 Handler作为消息机制在整个Android系统里面起到了无可替代的作用,我们今天来探讨下这个无比重要的机制的实现细节。
【Java 多线程】从源码出发,剖析Threadlocal的数据结构 ThreadLocal是个很重要的多线程类,里面数据结构的设计很有意思,很巧妙。但是我们平时使用它的时候常常容易对它的使用感到迷惑,因为它跟其它的API很不一样,使用很不一样,设计也很不一样。但是不用担心,这篇文章将从源码出发,一步步深入剖析ThreadLocal内部构造,理清楚它的来龙去脉。
【Android 内存优化】KOOM线程泄漏监控的实现源码分析 前面我们通过研究KOOM的开源代码,研究了关于Java层和native层内存泄漏监控的实现原理。还剩下线程泄漏这部分没有进行分析,今天来补全它。整体下来,相信我们对于内存监控在代码上的实现上会有一个较为体系化的了解。
【CMake】Android native模块a调用native模块b,如何配置cmake? Android项目中如何配置cmake,让module a的native代码调用module b的native代码?首先可以看看CMAKE_SOURCE_DIR的具体路径:定义子目录的路径把子模块的cmakelists添加关联接着根据自己项目的具体位置,找到实际上module a的代码路径。接着调用add_subdirectory,添加到对应的路径中。add_subdirectory的主要作用是添加另外一个cmakelist到当前的cmakelisk的搜索目录中。这里需要注意的是,这种情境下使用
【C/C++ API】C++内存分配和释放函数分析 是一个 C 语言函数,用于分配一块内存,并保证返回的指针地址满足特定的对齐要求。指向的内存块,并使该内存块可用于后续的内存分配。字节,并返回一个指向重新分配后的内存块的指针。之后,我们检查是否分配成功,然后使用该内存,最后在不再需要时释放该内存。是 C 标准库中的一个函数,用于分配一块内存,并保证返回的指针地址满足特定的对齐要求。是 C 标准库中的一个函数,用于重新分配先前分配的内存块的大小。,即要释放的内存块的指针。是 C 标准库中的一个函数,用于动态分配内存,并将分配的内存空间初始化为零。
【Android 内存优化】快手框架KOOM是怎么实现native层内存泄漏监控的? 我们可以大体总结一下KOOM监控native泄漏的大致原理:主要是通过加载需要监听的so,然后通过开源框架XHook来hook内存分配相关的调用函数,把hook获取到的信息回调给Java应用层,从而达到监控native内存的目的。
【Android 内存优化】KOOM 快手开源框架线上内存监控方案-源码剖析 这篇文章主要剖析KOOM的Java层源码设计逻辑。【Android KOOM】KOOM java leak使用全解析/**/很简单的两行代码,里面包含了如此之多的业务逻辑和精彩的设计。很多时候,我们使用越是简单的开源框架,越是能证明作者的厉害之处。他们把繁杂的逻辑内聚到了框架里面,让使用者能用简单一两行代码实现复杂的逻辑业务。KOOM作为一个线上内存监控框架,有很多优秀的设计。这篇文章也只是在外层分析了一些表面的技术逻辑,至于更深入的内容,后续会继续更新。