CoreFoundation CFRuntimeBase下的_cfinfo[4]存储信息探究

最新推荐文章于 2022-03-23 10:33:23 发布
最新推荐文章于 2022-03-23 10:33:23 发布
阅读量397 收藏
点赞数
文章标签： 移动开发 嵌入式
原文链接：https://juejin.im/post/5ad9b8256fb9a07aa92548e3
版权

前言

纯属探究，不对的地方请指出

为什么要探究这个，在学习runloop的过程中发现了一些，很难看的东西，在cf下可以看到充斥着各种各样的类似的函数


/* Bit 3 in the base reserved bits is used for invalid state in run loop objects */
CF_INLINE void __CFSetValid(void *cf) {
    __CFBitfieldSetValue(((CFRuntimeBase *)cf)->_cfinfo[CF_INFO_BITS], 3, 3, 1);
}

CF_INLINE void __CFUnsetValid(void *cf) {
    __CFBitfieldSetValue(((CFRuntimeBase *)cf)->_cfinfo[CF_INFO_BITS], 3, 3, 0);
}

复制代码

注释上已经很明确了，这个位代表着什么状态，于是乎我就猜想，是不是这个_cfinfo下面都有着通用的位来表示状态，就因此查看代码有了如下的结论。（咱们就不卖关子了啊，直接把结论写上，之后再说怎么看的）

_cfinfo[4]存储了什么信息

typedef struct __CFRuntimeBase {
    uintptr_t _cfisa;
    uint8_t _cfinfo[4];
#if __LP64__
    uint32_t _rc;
#endif
} CFRuntimeBase;
复制代码

isa指针不用多说，是个iOS开发都知道。

cfinfo[4]是个数组（这不TM废话么），类型是uint8_t，一个字节，跟char是一个样子的，能存储8位信息；4*8也就可以存储32位信息。

下面是结论：（不对请指出，但是不要喷啊，小编头一次发帖）

1-8位：

第8位：是否是系统默认分配的空间。kCFAllocatorSystemDefault

1~7位存储的信息都是不同的，看每个cf对象下的类型。

eg:（CFRunloopObserver，第一位firing，第二位repeats）

/* Bit 0 of the base reserved bits is used for firing state */
/* Bit 1 of the base reserved bits is used for repeats state */

CF_INLINE Boolean __CFRunLoopObserverIsFiring(CFRunLoopObserverRef rlo) {
    return (Boolean)__CFBitfieldGetValue(((const CFRuntimeBase *)rlo)->_cfinfo[CF_INFO_BITS], 0, 0);
}

CF_INLINE void __CFRunLoopObserverSetFiring(CFRunLoopObserverRef rlo) {
    __CFBitfieldSetValue(((CFRuntimeBase *)rlo)->_cfinfo[CF_INFO_BITS], 0, 0, 1);
}

CF_INLINE void __CFRunLoopObserverUnsetFiring(CFRunLoopObserverRef rlo) {
    __CFBitfieldSetValue(((CFRuntimeBase *)rlo)->_cfinfo[CF_INFO_BITS], 0, 0, 0);
}

CF_INLINE Boolean __CFRunLoopObserverRepeats(CFRunLoopObserverRef rlo) {
    return (Boolean)__CFBitfieldGetValue(((const CFRuntimeBase *)rlo)->_cfinfo[CF_INFO_BITS], 1, 1);
}

CF_INLINE void __CFRunLoopObserverSetRepeats(CFRunLoopObserverRef rlo) {
    __CFBitfieldSetValue(((CFRuntimeBase *)rlo)->_cfinfo[CF_INFO_BITS], 1, 1, 1);
}

CF_INLINE void __CFRunLoopObserverUnsetRepeats(CFRunLoopObserverRef rlo) {
    __CFBitfieldSetValue(((CFRuntimeBase *)rlo)->_cfinfo[CF_INFO_BITS], 1, 1, 0);
}
复制代码

还有其中array是否是mutiable的在第七位表示，在__CFArrayInit可以看到，不过得自己计算，就不贴代码了。可以推想一下dict或者其他的collect的mutiable是否在第七位存储。

9-18位：CFTypeID

19-21位不详，快找瞎了ಥ_ಥ，求哪位大神看到可以补充一下

22位：deallocing

23位：dealloced

24位：是否是自定义引用计数的对象

25-32：引用计数

还可以看到在64位下，用_rc代表着引用计数，至于上面25-32位在64位用来干啥，暂时没看到，希望大神指出。

#if __LP64__
    uint32_t _rc;
#endif
复制代码

关键宏以及一些注意点

CFRuntime.h

#if __BIG_ENDIAN__
#define INIT_CFRUNTIME_BASE(...) {0, {0, 0, 0, 0x80}}
#else
#define INIT_CFRUNTIME_BASE(...) {0, {0x80, 0, 0, 0}}
#endif
复制代码

CFInternal.h

#if defined(__BIG_ENDIAN__)
#define __CF_BIG_ENDIAN__ 1
#define __CF_LITTLE_ENDIAN__ 0
#endif

#if defined(__LITTLE_ENDIAN__)
#define __CF_LITTLE_ENDIAN__ 1
#define __CF_BIG_ENDIAN__ 0
#endif
复制代码
#define CF_INFO_BITS (!!(__CF_BIG_ENDIAN__) * 3)
#define CF_RC_BITS (!!(__CF_LITTLE_ENDIAN__) * 3)
复制代码
#define __CFBitfieldMask(N1, N2)	((((UInt32)~0UL) << (31UL - (N1) + (N2))) >> (31UL - N1))
#define __CFBitfieldGetValue(V, N1, N2)	(((V) & __CFBitfieldMask(N1, N2)) >> (N2))
#define __CFBitfieldSetValue(V, N1, N2, X)	((V) = ((V) & ~__CFBitfieldMask(N1, N2)) | (((X) << (N2)) & __CFBitfieldMask(N1, N2)))
#define __CFBitfieldMaxValue(N1, N2)	__CFBitfieldGetValue(0xFFFFFFFFUL, (N1), (N2))
复制代码

BIG_ENDIAN 大端模式 高字节的存储在内存的低低地址

LITTLE_ENDIAN 小端模式 反之

具体的什么自行百度，直接举个例子 0x01 23 45 67

大端 67 45 23 01

小端 01 23 45 67

这个跟cpu有关，我们常用的X86结构是小端模式，而KEIL C51则为大端模式。很多的ARM，DSP都为小端模式。有些ARM处理器还可以由硬件来选择是大端模式还是小端模式。

所以CF_INFO_BITS在小端代表的就是0

 __CFBitfieldSetValue(((CFRuntimeBase *)rlo)->_cfinfo[CF_INFO_BITS], 0, 0, 0)
 等价于
  __CFBitfieldSetValue(((CFRuntimeBase *)rlo)->_cfinfo[0], 0, 0, 0)
复制代码

__CFBitfieldSetValue(V, N1, N2, X)是个啥玩意？

我们存储的是位信息，你也可以用10进制来对cfinfo直接存储，但是不是太烧脑。所以通过移位来表示找到我们想要标记的位。

x来表示是不是对这个位置标记是1还是0，通过左移N2位之后同或之后的位为0。

至于N1可以先不用管它。N2就是表示你要标记为1的位。

说了这么多，还是自己推算一下才可以理解这个是怎么用的。

在哪里看到的

前面我bb了这么半天，你在哪看到的，你是不是在那忽悠我呢？

CFRuntime.c -> _CFRetain 函数这里基本上涵盖了全部，具体看注释部分

static CFTypeRef _CFRetain(CFTypeRef cf, Boolean tryR) {
    uint32_t cfinfo = *(uint32_t *)&(((CFRuntimeBase *)cf)->_cfinfo);
    if (cfinfo & 0x800000) { // '自定义引用计数'
        if (tryR) return NULL;
        CFTypeID typeID = (cfinfo >> 8) & 0x03FF; // mask up to 0x0FFF
        CFRuntimeClass *cfClass = __CFRuntimeClassTable[typeID];
        uint32_t (*refcount)(intptr_t, CFTypeRef) = cfClass->refcount;
        if (!refcount || !(cfClass->version & _kCFRuntimeCustomRefCount) || (((CFRuntimeBase *)cf)->_cfinfo[CF_RC_BITS] != 0xFF)) {
            HALT; // bogus object
        }
#if __LP64__
        if (((CFRuntimeBase *)cf)->_rc != 0xFFFFFFFFU) {
            HALT; // bogus object
        }
#endif
        refcount(+1, cf);
        return cf;
    }

    Boolean didAuto = false;
    if (tryR && (cfinfo & (0x400000 | 0x200000))) return NULL; //' deallocating or deallocated'
#if __LP64__
    if (0 == ((CFRuntimeBase *)cf)->_rc && !CF_IS_COLLECTABLE(cf)) return cf;	// Constant CFTypeRef
    uint32_t lowBits;
    do {
	lowBits = ((CFRuntimeBase *)cf)->_rc;
    } while (!CAS32(lowBits, lowBits + 1, (int32_t *)&((CFRuntimeBase *)cf)->_rc));
    // GC:  0 --> 1 transition? then add a GC retain count, to root the object. well remove it on the 1 --> 0 transition.
    if (lowBits == 0 && CF_IS_COLLECTABLE(cf)) {
	auto_zone_retain(objc_collectableZone(), (void*)cf);
	didAuto = true;
    }
#else
#define RC_START 24
#define RC_END 31
    CFIndex rcLowBits = __CFBitfieldGetValue(cfinfo, RC_END, RC_START);
    if (__builtin_expect(0 == rcLowBits, 0) && !CF_IS_COLLECTABLE(cf)) return cf;	// Constant CFTypeRef
    volatile uint32_t *infoLocation = (uint32_t *)&(((CFRuntimeBase *)cf)->_cfinfo);
    bool success = 0;
    do {
        cfinfo = *infoLocation;
        uint32_t prospectiveNewInfo = cfinfo; // dont want compiler to generate prospectiveNewInfo = *infoLocation.  This is why infoLocation is declared as a pointer to volatile memory.
        prospectiveNewInfo += (1 << RC_START);
        rcLowBits = __CFBitfieldGetValue(prospectiveNewInfo, RC_END, RC_START);
        if (__builtin_expect((rcLowBits & 0x7f) == 0, 0)) {
            /* '
             将另一位滚动到外部引用计数
             实际参考计数=低7位信息[CF_RC_BITS] +外部参考计数<< 6
             低位的第8位表示外部引用计数正在使用中。
             外部参考计数移位6而不是7，这样我们可以将低位设置为1100 0000而不是1000 0000。
             这样可以防止当复合保留计数恰好在1 << 7的倍数附近时，需要访问连续保留和释放的外部引用计数.'
             */
            prospectiveNewInfo = cfinfo;
            __CFBitfieldSetValue(prospectiveNewInfo, RC_END, RC_START, ((1 << 7) | (1 << 6)));
            __CFLock(&__CFRuntimeExternRefCountTableLock);
            success = CAS32(*(int32_t *)& cfinfo, *(int32_t *)&prospectiveNewInfo, (int32_t *)infoLocation);
            if (__builtin_expect(success, 1)) {
                __CFDoExternRefOperation(350, (id)cf);
            }
            __CFUnlock(&__CFRuntimeExternRefCountTableLock);
        } else {
            success = CAS32(*(int32_t *)& cfinfo, *(int32_t *)&prospectiveNewInfo, (int32_t *)infoLocation);
            // XXX_PCB:  0 --> 1 transition? then add a GC retain count, to root the object. we ll remove it on the 1 --> 0 transition.
            if (success && __CFBitfieldGetValue(cfinfo, RC_END, RC_START) == 0 && CF_IS_COLLECTABLE(cf)) {
		auto_zone_retain(objc_collectableZone(), (void*)cf);
		didAuto = true;
	    }
        }
    } while (__builtin_expect(!success, 0));
#endif
    if (!didAuto && __builtin_expect(__CFOASafe, 0)) {
	__CFRecordAllocationEvent(__kCFRetainEvent, (void *)cf, 0, CFGetRetainCount(cf), NULL);
    }
    return cf;
}
复制代码

结语

对于这个帖子其实可有可无，不过我个人感觉理解了这些，至少在看CF框架的降低了一些难度，毕竟关于CF的帖子很少。这个帖子只是关于自己的一些问题的记录，其中肯定有不对的，还请小伙伴指正。

思考 & 疑问

1.cfinfo为什么这么写，而不是直接用一个32位表示？自己的猜测，可能跟历史原因，因为远古的时候地址总线是16位的有关系。

2.但出现了64位的cpu之后24-32位存储引用计数为什么不用了，而用了_rc来存储，难道是用来干其他的事么

3.19-21位这个还没找到对应的信息。。

4.iOS的64位下的isa的指针，除了内存地址另外的32位是否也是同样信息？

weixin_33966095
关注
  • 0
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
en_microsoft_.net_framework_4_for_server_core_x64_sc_640395.exe.zip
11-18
microsoft_.net_framework_4_for_server_core_x64_sc_640395.exe"，并且有一个关联的文本文件"en_microsoft_.net_framework_4_for_server_core_x64_sc_640395.exe.txt"，可能包含了该安装程序的详细信息、许可证条款...
CFRunloop的多线程隐患
hyun134340的博客
01-08 186
如果你还不了解什么是runloop，可以看这里的详解。苹果generally但是需要注意的是，狡猾的苹果使用了generally这个模糊的词。从实践中来看，CFRunloop在停止runloop的阶段的某些操作是存在多线程隐患的。
CFMessagePort.c
ALDRIDGE1的专栏
06-07 1919
CFMessagePort.c [plain text] /* * Copyright (c) 2014 Apple Inc. All rights reserved. * * @APPLE_LICENSE_HEADER_START@ * * This file contains Original Code and/or Modifications of Original Cod
iOS 查漏补缺 - RunLoop
Write the code Change the world
03-16 551
RunLoop 在 0202 年的今天其实已经不是个新鲜的话题了，关于这方面的文章网上有很多大神总结得非常精辟。 作为 iOS 查漏补缺系列，这篇文章是笔者探索 RunLoop 底层的一些知识点总结，同时也借鉴了网上一些优秀的 RunLoop 技术文章的内容。 本文内容如有错误，欢迎指正。 RunLoop 前导知识 iOS/OS X 系统架构 iOS 进化史 Mac OS Classic 拥...
RunLoop总结：RunLoop基础知识
weixin_30362083的博客
12-20 146
没有实际应用场景，很难理解一些抽象空洞的东西，所以前面几篇文章先介绍了RunLoop的几个使用场景。 另外AsyncDisplayKit中也有大量使用RunLoop的示例。 关于实际的使用RunLoop 的案例和使用场景就不总结了，今天总结一点RunLoop的基础知识和概念。 什么是RunLoop？ 顾名思义，它就是一个运行循环。一个RunLoop 就是一个用于处理...
iOS中的3种卡顿检测
gcs的博客
01-16 4019
市面上的iOS卡顿分析方案有三种：监控FPS、监控RunLoop、ping主线程。 前面2个都比较熟悉，第三个是最近才了解到的。 方案一：监控FPS 一般来说，我们约定60FPS即为流畅。那么反过来，如果App在运行期间出现了掉帧，即可认为出现了卡顿。 监控FPS的方案几乎都是基于CADisplayLink实现的。简单介绍一下CADisplayLink：CADisplayLink是一个和屏幕刷新率保持一致的定时器，一但 CADisplayLink 以特定的模式注册到runloop之后，每当屏幕需要刷
CoreFoundation.h_以及同目录下所有头文件
11-28
CoreFoundation是Apple操作系统的核心框架，它是许多Apple技术的基础，包括Objective-C的Foundation框架和Swift的Standard Library。在iOS和macOS开发中，CoreFoundation提供了一系列的C语言接口，用于处理基本的...
core_cm3_core_cm3_core_cm3.h_
10-01
* @file core_cm3.h * @brief CMSIS Cortex-M3 Core Peripheral Access Layer Header File * @version V1.30 * @date 30. October 2009 *
Core_v5.2_蓝牙核心规范_Core_v5.2_
10-02
该规范定义了创建可互操作的蓝牙设备所需的技术。
WMI.zip_core temp_temp_wmi
09-24
4. **编程语言**：Core Temp的源代码可能是用C++、C#或其他支持系统底层操作的编程语言编写的。这些语言允许程序员直接与硬件交互，包括读取和解释处理器的温度传感器数据。 5. **温度监测**：在计算机硬件中，温度...
Runloop 学习之概念
csdn_coder_zxq的博客
05-31 177
Runloop 学习之概念 原文 runloop 介绍 RunLoop 还是比较顾名思义的一个东西，说白了就是一种循环，只不过它这种循环比较高级。一般的 while 循环会导致 CPU 进入忙等待状态，而 RunLoop 则是一种“闲”等待 一个RunLoop对象，主要包含了一个线程，若干个Mode，若干个commonMode，还有一个当前运行的Mode 当我们需要一个常驻线程，可以让...
ios Core Foundation 框架 详解
qq_27909209的博客
09-07 3495
先来说说「Core Foundation」（以下简称CF）的历史吧。当年乔布斯被自己创办的公司驱逐后，成立了「NeXT Computer」,其实做的还是老本行：卖电脑，但依旧不景气。好在NeXTSTEP系统表现还不错，亏损不至于太严重。正好此时苹果的市场份额大跌，急需一个新的操作系统，结果大家都知道了，乔布斯借此收购，重新回到了苹果。 这里就牵扯到了一个问题，如何让旧有的系统（Mac OS 9）...
nvidia docker 容器中devel runtime base三种文件的区别
一新新的小白的博客
03-23 6205
最近需要将深度学习项目部署到docker环境中，因此躲不开跳入nvidia docker的坑中，首先确认是非常好用的工具，但就是太干净了里面什么也没有，需要花些时间去配置。这里将统一cuda版本的三个镜像文件版本的区别记录如下： 仅从docker hub/nvidia/cuda 看到三个版本的image文件镜像大小不同，具体区别为： base版本： 该版本是从cuda9.0开始，包含了部署预构建cuda应用程序的最低限度（libcudart）。 如果用户需要自己安装自己需要的cuda包，可以选择使用这个im
docker-cuda之base，runtime，devel的区别
xiangxianghehe的博客
03-23 2336
本文系转载，出处：https://blog.csdn.net/u011622208/article/details/113650011 Description CUDA图像有三种风格，可以通过NVIDIA公共集线器存储库获得。 基础（base）:从CUDA 9.0开始，包含了部署预构建CUDA应用程序的最低限度(libcudart)。 如果你想手动选择你想要安装的CUDA包，请使用这个映像。 运行时（runtime）:通过添加CUDA工具包中的所有共享库扩展基本映像。 如果您有一个使用多个CUDA库的预构建
内核崩溃捕获机制之kdump详解
热门推荐
LDF-Dicky的博客
02-12 2万+
文章转载自: http://www.361way.com/centos-kdump/3751.html 一、什么是kdump kdump 是一种先进的基于 kexec 的内核崩溃转储机制。当系统崩溃时，kdump 使用 kexec 启动到第二个内核。第二个内核通常叫做捕获内核，以很小内存启动以捕获转储镜像。第一个内核保留了内存的一部分给第二内核启动用。由于 kdump 利用 kexec 启动...
位段（bit-field）
IT-Goer
04-02 565
一、位段结构 struct node { unsigned int a:4; //位段a，占4位 unsigned int :0; //无名位段，占0位 unsigned int b:4; //位段b，占4位 int c:32; //位段c，占32位 int :6; //无名
[iOS知识简记]-CoreFoundation-源码分析
demondev
09-17 446
CFRunLoop.h/.c 每个线程创建的struct __CFRunLoop都会存储到下面静态dict里。 static CFMutableDictionaryRef __CFRunLoops = NULL; _CFRunLoopGet0里首次调用时，触发静态变量__CFRunLoops的创建。 存储代码： CFDictionarySetValue(__CFRunLoops, pthread...
iOS NSData探秘
u011025344的专栏
08-20 852
请先参考 http://zhiwei.li/text/2012/03/objetive-c内存布局/ http://zhiwei.li/text/2010/11/objective-c中的meta-class/ http://zhiwei.li/text/2010/05/objective-c类对象/     /Applications/Xcode.app/Co
CFArray的历史渊源及实现原理
weixin_34405332的博客
08-03 326
在 iOS 开发中，NSArray 是一个很重要的数据结构。尤其 TableView 中的数据缓存与更新， NSArray 来缓存数据以及对于显示数据的修改操作。而在 Core Foundation 中 CFArray 与 NSArray 相互对应，这引起了笔者对 Core Foundation 和 Foundation 库中的原生数据结构实现产生兴趣...
core_cm3.c与core_cm4.c的区别
最新发布
07-15
`core_cm3.c` 和 `core_cm4.c` 是针对不同的 ARM Cortex-M 内核版本提供的 CMSIS(Core Microcontroller Software Interface Standard) 核心支持文件。 ARM Cortex-M3 和 Cortex-M4 是 ARM 公司开发的两种低功耗...

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值