我的程序生涯可谓是充满了曲折和成长的旅程。从一开始的业余爱好，到如今的职业发展，我经历了许多挑战和机遇，也积累了不少宝贵的经验。

回顾起来，我最初接触编程是在大学期间。当时，我被计算机的神秘和无限可能性所吸引，开始学习编写简单的代码。起初，我对编程还不太熟悉，但是通过不断的学习和实践，我渐渐掌握了一些基本的编程语言和技巧。

毕业后，我决定将编程作为我的职业。我投身于软件开发行业，从一名初级程序员开始。在职场中，我面对了各种项目和团队合作的挑战。通过不断学习和与同事的交流，我的编程能力得到了提升，我也逐渐熟悉了软件开发的流程和方法。

随着时间的推移，我逐渐担任更高级的职位，并开始负责一些重要项目的开发。同时，我也积极追求自我提升，不断学习新的编程技术和工具。我学习了机器学习和数据科学的知识，掌握了一些流行的开发框架和库。这些新技能不仅提升了我的职业竞争力，还让我能够解决更加复杂的问题。

在职场上，我也遇到了一些奇葩和不愉快的经历。有一次，我加入了一家初创公司，他们开发了一款虚拟现实游戏。我被聘为首席程序员，负责游戏的核心功能开发。开始时，我对这个机会充满了期待，希望能够在这个新兴行业有所突破。

然而，不久之后，我发现这家公司的管理层存在着一些奇葩的决策和不合理的要求。他们对于开发进度的期望过高，要求我们在短时间内完成大量的工作。同时，他们也没有给予足够的资源和支持，导致我们在技术上遇到了很多困难。

更糟糕的是，公司的管理层对于员工的待遇也非常吝啬。工资低于行业平均水平，福利待遇简直可以说是微乎其微。而且，他们还经常加班，但却不提供加班补偿。这让我感到非常不满和失望。

在与同事的交流中，我发现大家都对公司的管理方式感到不满。许多人都在考虑离职，寻找更好的机会。尽管我对这个项目充满了热情，但最终我还是做出了离职的决定。

离开这家公司后，我感到一种解脱和自由。我决定重新评估自己的职业规划，并寻找更好的工作环境。我参加了一些技术研讨会和行业活动，扩展了人脉和知识面。

通过努力和坚持，我最终找到了一家知名游戏开发公司的工作机会。这家公司有着良好的声誉和优秀的团队氛围。在这里，我得到了更好的薪资待遇和职业发展机会。与同事们的合作也非常愉快，他们互相支持和激励，共同追求技术的进步和项目的成功。

在新的公司，我不仅继续提升自己的技术能力，还积极参与项目的管理和领导工作。我逐渐晋升为高级程序员，并负责指导和培养新人。我享受着这种成长和发展的过程，同时也在职业道路上收获了不断增长的薪资。

除了职业发展，我还热衷于扩展自己的知识领域。我广泛阅读与编程相关的书籍，不仅加深了对技术的理解，还开拓了思维的广度。这些书籍不仅拓宽了我的知识面，也为我在工作中遇到的问题提供了解决思路。

在编程道路上，我结识了许多优秀的同行和导师。他们在我职业发展中起到了关键的作用。他们与我分享自己的经验和知识，给予了我很多指导和支持。有时候，在解决问题的过程中，他们的帮助让我事半功倍。

总结而言，我的程序生涯经历了起伏和挑战，但也收获了许多成长和成功。通过不断学习和努力，我掌握了新的技能，取得了薪资的增长，结识了良师益友。我学会了在职场中勇敢面对困难，果断做出改变并寻找更好的机会。这些经历让我明白了职业选择的重要性，一个良好的工作环境和管理团队对于个人的成长和幸福感至关重要。

在我的职业规划中，我也意识到了不断学习和适应新技术的重要性。随着科技的迅猛发展，编程领域也在不断演进。我持续关注行业的趋势，并主动学习新的编程语言、框架和工具。这使我能够跟上潮流，提升自己的竞争力，并为公司的发展做出贡献。

此外，我也始终注重个人的硬件装备。一台高效的电脑和适合编程需求的工具是提高工作效率的关键。我不断更新我的硬件设备，并保持其良好状态，以确保在工作中能够高效地完成任务。

在这个职业生涯中，我经历了职场的起伏和挑战，但我始终坚持不懈地追求自己的梦想和目标。通过遇到的困难和不愉快的经历，我学会了坚持和勇敢面对挑战，也学会了在逆境中寻找机会和改变。

通过不断学习、拓展技能、寻找良师益友和适应职业发展的机会，我在程序生涯中取得了成长和进步。我不仅拥有了稳定的职业发展和增长的薪资，还培养了自己的领导能力和团队合作精神。

总的来说，程序生涯是一段充满挑战和机遇的旅程。通过坚持不懈的努力和持续学习，我在职业道路上取得了一定的成就。我相信，只要保持对技术的热情和对自我提升的追求，我将继续在编程的世界中不断成长和创造出更多的价值。

自己总结了一句话。

对于命运，不必抱怨什么。因为，你就是你的上帝。

                                                              ---- 致自己

问题：iOS推送证书不受信任

问题分析：

苹果已经使用了新的签名证书。

原文: Apple Worldwide Developer Relations Intermediate Certificate Expiration

解决方法：

打开苹果官方证书下载链接：Apple PKI

本文阐述了个人对移动端页面加载耗时监控的一些理解，主要从：节点划分及对应的实现方案，线上监控注意点，后续还能做的事 三个方面来和大家分享。

前言

移动端的页面加载速度，作为最为影响用户体验的因素之一，是我们做移动端性能优化的重点方向之一。

而优化的效果体现，需要置信的指标进行衡量（常见方法论：寻找方向->确定指标->实践->量化收益），而本文想要分享的就是：如何真实、完整、方便的获得页面加载时间，并会向线上监控环节，有一定延伸。

本文的示例代码都是OC（因为Java和kotlin我也不会😅），但相关思路和方案也适用于Android（Android端已实现并上线）。

页面加载耗时

常见方案

页面加载时长是一直以来大家都在攻坚的方向，所以市面上也有非常非常多的度量方案，从节点划分角度看：

较为基础的：ViewController 的 init -> viewDidLoad -> viewDidAppear

更进一步的：ViewController 的 init -> viewDidLoad -> viewDidAppear -> user Interactable

主流方案：ViewController 的 init -> viewDidLoad -> viewDidAppear -> view render completed -> user Interactable

还有什么地方可以改进的吗？

对于这些成熟方案，我还有什么可以更进一步的吗？主要总结为以下几个方面吧：

• 完整反映用户体感

我们做性能优化，归根结底，更是用户体验优化，在满足功能需要的同时，不影响用户的使用体验。 所以，我个人认为，大多数的性能指标，都要考虑到用户体验这个方向；页面启动速度这一块，更是如此；而传统的方案，能够完整的反应用户体感吗？ 我觉得还是有一部分的缺失的：用户主动发起交互到ViewController这个阶段。这一部分有什么呢，不就是直接tap触发的action里vc就初始化了吗？ 实际在一些较为复杂、大型的项目中，并不然，中间可能会有很多其他处理，例如：方法hook、路由调度、参数解析、containerVC的初始化、动态库加载等等。这一部分的耗时，实际上也是用户体感的一部分，而这一部分的耗时，如果不加监控的话，也会对整体耗时产生劣化。（这里可能会有小伙伴问了，这些东西，不应该由各自负责的同学，例如负责路由的同学，自行监控吗？这里我想阐述的一个观点时，时长类的监控，如果由几个时间段拼接，相比于endTime - startTime，难免会产生gap，即，加入endTime = 10，startTime = 0，那么中间分成两段，很有可能endTime2 = 10，startTime2 = 6；endTime1 = 4，startTime1 = 0，造成总时长不准。总而言之，还是希望得到一个能够完整反映用户体感的时长。）

• 数据采集与业务解耦

这一点其实市面上的很多方案已经做得很好了。解耦，一方面是为了，提效：避免后续有新的页面需要监控时，需要进行新的开发；另一方面，也是避免业务迭代对于监控数据的影响：如果是手动侵入性埋点，很难保证后续新增的耗时任务对监控数据不产生影响。 而本文方案，不需要在业务代码中插入任何代码，大都是通过方法hook来实现数据采集的；而对范围、以及匹配关系等的控制，也都是通过配置来完成的。

具体实现

节点确定&数据采集方式

根据一个页面（ViewController）的加载过程中，开发主要进行的处理，以及可能对用户体感产生影响的因素，将页面加载过程划分为如上图所示的11个节点，具体解释及实现方案如下：

1. 用户行为触发页面跳转

由于页面的跳转一般是通过用户点击、滑动等行为触发的，因此这里监听用户触摸屏幕的时间点；但有效节点仅为VC在初始化前的最后一次点击/交互。

具体实现： hook UIWidow 的 sendEvent:方法，在swizzle方法内记录信息；为了性能考虑，目前仅记录一个uint64_t的时间戳，且仅内存写； 注意这里需要记录手指抬起的时间，即 touch.phase == UITouchPhaseEnded，因为一般action被调用的时机就是此时； 同时，为了适配各种行为触发的新页面出现，还增加了一个手动添加该节点的方法，使一些较复杂且不通用，业务特性较强的初始化场景，也能够有该节点数据，且不依赖hook；但注意该手动方法为侵入式数据采集方式。

2. ViewController的初始化

具体实现：hook UIViewController或你的VC基类 的 - (instancetype)init 的方法；

3. 本地UI初始化

不依赖于网络数据的UI开始初始化。

这个节点，我实际上并没有在本次实现，这里的一个理想态是：将这部分行为（即UI初始化的代码），通过协议的方式，约束到指定方法中；例如，架构层面约束一个setupSubviews的接口，回调给各业务VC，供其进行基础UI绘制（目前这种方式再一些更复杂的业务场景下实现并运行较好）；有这个基础约束的前提下，才能准确的采集我理想中该节点的耗时。而我目前所负责的模块，并没有这种强约束，而又不能简单的去认为所有基础UI都是在viewDidLoad中去完成的。因此需要 对原有架构的一定修改 或 能够保证所有基础UI行为都在viewDidLoad中实现，才能够实现该节点数据的准确采集。 因此2 ~ 3和3 ~ 4间的耗时，被融合为了一段2 ~ 4的耗时。

4. 本地UI初始化完成

不依赖于网络数据的UI初始化完成。

具体实现：监听主线程的闲时状态，VC初始化 节点后的首个闲时状态表示 本地UI初始化完成；（闲时状态即runloop进入kCFRunLoopBeforeWaiting）

5. 发起网络请求

调用网络SDK的时间点。

这里描述的就是上面的节点划分图的第二条线，因为两条线的节点间没有强制的线性关系，虽然图中当前节点是放在了VC初始化平行的位置，但实际上，有些实现会在VC初始化之前就发起网络请求，进行预加载，这种情况在实现的时候也是需要兼容的。

具体实现：hook 业务调用网络SDK发起请求方法的api；这里的网络库各家实现方案就可能有较大差异了，根据自身情况实现即可。

6. 网络SDK回调

网络SDK的回调触发的时间点。

具体实现：hook 网络SDK向业务层回调的api；差异性同5。

7. send request

8. receive response

真正 发出网络请求 和 收到response 的时间点，用于计算真正的网络层耗时。 这俩和5、6是不是重复了啊？并不然，因为，网络库在接收到发起网络请求的请求后，实际上在端阶段，还会进行很多处理，例如公参的处理、签名、验签、json2Model等，都会产生耗时；而真正离开了端，在网上逛荡那一段，更是几乎“完全不可控”的状态。所以，分开来统计：端部分 和 网络阶段，才能够为后续的优化提供数据基础，这也是数据监控的意义所在。

具体实现： 实际上系统网络api中就有对网络层详细性能数据的收集

- (void)URLSession:(NSURLSession *)session 
              task:(NSURLSessionTask *)task 
didFinishCollectingMetrics:(NSURLSessionTaskMetrics *)metrics;

根据官方文档中的描述

可以发现，我们实际上需要的时长就是从 fetchStartDate 到 responseEndDate 间的时间。 因此可以该delegate，获取这两个时间点。

9. 详细UI初始化

详细UI指，依赖于网络接口数据的UI，这部分UI渲染完成才是页面达到对用户可见的状态。

具体实现：这里我们认为从网络SDK触发回调时，即开始进行详细UI的渲染，因此该节点和节点6是同一个节点。

10. 详细UI渲染完成

页面对用户来说，真正达到可见状态的节点。

具体实现： 对于一个常规的App页面来说，如何定义一个页面是否真正渲染完成了呢？

被有效的视图铺满。

什么是有效视图呢？视频，图片，文字，按钮，cell，能向用户传递信息，或者产生交互的view； 铺满，并不是指完全铺满，而是这些有效视图填充到一定比例即可，因为按照正常的视觉设计和交互体验，都不会让整个屏幕的每一个像素点都充满信息或具备交互能力；而这个比例，则是根据业务的不同而不同的。 下面则是上述逻辑的实现思路：

确定有效视图的具体类

UITextView 
UITextField
UIButton
UILabel
UIImageView
UITableViewCell
UICollectionViewCell

主流方案中比较常见的，是前几种类，并不包括最后的两个cell；而这里为什么将cell也作为有效视图类呢？ 首先，出于业务特征考虑，目前应用该套监控方案的页面，主要是以卡片列表样式呈现的；而且个人认为，市面上很多App的页面也都是列表形式来呈现内容的；当然，如果业务特征并不相符，例如全屏的视频播放页，就可以不这样处理。 其次，将cell作为有效视图，确实能够极大的降低每次计算覆盖率的耗时的。性能监控本身产生的性能消耗，是性能方向一直以来需要着重关注的点，毕竟你一个为了性能优化服务的工具，反而带来了不小的劣化，怎样也说不太过去啊😂~ 我也测试了是否包含cell对计算耗时的影响： 下表中为，在一个层级较为复杂的业务页面，页面完全渲染完成之后，完成一次覆盖率达到阈值的扫描所需的时长。

而且，有效视图的类，建议支持在线配置，也可以是一些自定义类。

将cell作为有效视图，大家可能会产生一个新的顾虑：占位cell的情况，再具体点，就是常见的骨架图怎么办？骨架图是什么，就是在网络请求未返回的时候，用缓存的data或者模拟样式，渲染出一个包含大致结构，但不包含具体内容的页面状态，例如这种：

这种情况下，cell已经铺满了屏幕，但实际上并未完成渲染。这里就要依赖于节点的前后顺序了，详细UI是依赖于网络数据的，而骨架图是在网络返回之前绘制完成的，所以真正的覆盖率计算，是从网络数据返回开始的，因此骨架图的填充完成节点，并不会被错误统计未详细UI渲染完成的节点。

覆盖率的计算方式

如上图所示，开辟两个数组a、b，数组空间分别为屏幕长宽的像素数，并以0填充，分别代表横纵坐标； 从ViewController的view开始递归遍历他的subView，遇见有效视图时，将其frame的width和height，对应在数组a、b中的range的内存空间，都填充为1，每次遍历结束后，计算数组a、b中内容为1的比例，当达到阈值比例时，则视为可见状态。 示例代码如下：

- (void)checkPageRenderStatus:(UIView *)rootView {
    if (kPhoneDeviceScreenSize.width <= 0 || kPhoneDeviceScreenSize.height <= 0) {
        return;
    }

    memset(_screenWidthBitMap, 0, kPhoneDeviceScreenSize.width);
    memset(_screenHeightBitMap, 0, kPhoneDeviceScreenSize.height);

    [self recursiveCheckUIView:rootView];
}

- (void)recursiveCheckUIView:(UIView *)view {
    if (_isCurrentPageLoaded) {
        return;
    }

    if (view.hidden) {
        return;
    }

    // 检查view是否是白名单中的实例，直接用于填充bitmap
    for (Class viewClass in _whiteListViewClass) {
        if ([view isKindOfClass:viewClass]) {
            [self fillAndCheckScreenBitMap:view isValidView:YES];
            return;
        }
    }

    // 最后递归检查subviews
    if ([[view subviews] count] > 0) {
        for (UIView *subview in [view subviews]) {
            [self recursiveCheckUIView:subview];
        }
    }
}

- (BOOL)fillAndCheckScreenBitMap:(UIView *)view isValidView:(BOOL)isValidView {

    CGRect rectInWindow = [view convertRect:view.bounds toView:nil];

    NSInteger widthOffsetStart = rectInWindow.origin.x;
    NSInteger widthOffsetEnd = rectInWindow.origin.x + rectInWindow.size.width;
    if (widthOffsetEnd <= 0 || widthOffsetStart >= _screenWidth) {
        return NO;
    }
    if (widthOffsetStart < 0) {
        widthOffsetStart = 0;
    }
    if (widthOffsetEnd > _screenWidth) {
        widthOffsetEnd = _screenWidth;
    }
    if (widthOffsetEnd > widthOffsetStart) {
        memset(_screenWidthBitMap + widthOffsetStart, isValidView ? 1 : 0, widthOffsetEnd - widthOffsetStart);
    }

    NSInteger heightOffsetStart = rectInWindow.origin.y;
    NSInteger heightOffsetEnd = rectInWindow.origin.y + rectInWindow.size.height;
    if (heightOffsetEnd <= 0 || heightOffsetStart >= _screenHeight) {
        return NO;
    }
    if (heightOffsetStart < 0) {
        heightOffsetStart = 0;
    }
    if (heightOffsetEnd > _screenHeight) {
        heightOffsetEnd = _screenHeight;
    }
    if (heightOffsetEnd > heightOffsetStart) {
        memset(_screenHeightBitMap + heightOffsetStart, isValidView ? 1 : 0, heightOffsetEnd - heightOffsetStart);
    }

    NSUInteger widthP = 0;
    NSUInteger heightP = 0;
    for (int i=0; i< _screenWidth; i++) {
        widthP += _screenWidthBitMap[i];
    }
    for (int i=0; i< _screenHeight; i++) {
        heightP += _screenHeightBitMap[i];
    }

    if (widthP > _screenWidth * kPageLoadWidthRatio && heightP > _screenHeight * kPageLoadHeightRatio) {
        _isCurrentPageLoaded = YES;
        return YES;
    }

    return NO;
}

但是也会有极端情况（类似下图）

无法正确反应有效视图的覆盖情况。但是出于性能考虑，并不会采用二维数组，因为w*h的量太大，遍历和计算的耗时，会有指数级的激增；而且，正常业务形态，应该不太会有类似的极端形态。

即使真的会较高频的出现类似情况，也有一套备选方案：计算有效视图的面积 占 总面积 的比例；该种方式会涉及到UI坐标系的频繁转换，耗时也会略差于当前的方式。

在某些业务场景下，例如 无/少结果情况，关于页面等，完全渲染后，也无法达到铺满阈值。 这种情况，会以用户发生交互（同 1、用户行为触发页面跳转 的获取方式）和 主线程闲时状态超过5s （可配）来做兜底，看是否属于这种状态，如果是，则相关性能数据不上报，因为此种页面对性能的消耗较正常铺满的情况要低，并不能真实的反应性能消耗、瓶颈，因此，仅正常铺满的业务场景进行监控并优化，即可。

扫描的触发时机

以帧刷新为准，因为只有每次帧刷新后，UI才会真正产生变化；出于性能考虑，不会每帧都进行扫描，每间隔x帧（x可配，默认为1），扫描一次；同时，考虑高刷屏 和 大量UI绘制时会丢帧 的情况，设置 扫描时间间隔 的上下限，即：满足 隔x帧 的前提下，如果和上次扫描的时间差小于 下限，仍不扫描；如果 某次扫描时，和上次扫描的时间间隔 大于 上限，则无论中间隔几帧，都开启一次扫描。

11. 用户可交互

用户可见之后的下一个对用户来说至关重要的节点。如果只是可见，然后就疯狂占用主线程或其他资源，造成用户的点击等交互行为，还是会被卡主，用户只能看，不能动，这个体感也是很差的；

具体实现：详细UI渲染完成 后的 首次主线程闲时状态。

监控方案

这里由于各家的基建并不相同，因此只是总结一些小的建议，可能会比较零散，大家见谅。

1. 建议采样收集

首先，数据的采集或者其他的新增行为/方法，一定是会产生耗时的，虽然可能不多，但还是秉着尽善尽美的原则，还是能少点就少点的，所以数据的采集，包括前面的hook等等一切行为，都只是随机的面向一部分用户开放，降低影响范围； 而且，如果数据量极大，全量的数据上报，其实对数据链路本身也会产生压力、增加成本。 当前，采样的前提是基本数据量足够，不然的话，采样样本量过小，容易对统计结果产生较大波动，造成不置信的结果。

1. 可配置

除了基本的是否开启的开关之外，还有其他的很多的点 需要/可以/建议 使用线上配置控制。个人认为，线上配置，除了实现对逻辑的控制，更重要的一个作用，就是出现问题时及时止损。 举一些我目前使用的配置中的例子： - 有效视图类 - 渲染完成状态，横纵坐标的填充百分比阈值 - 终态的兜底阈值 - VC的类名、对应的网络请求 等等。

1. 本地异常数据过滤

由于我们的样本数据量会非常大，所以对于异常数据我们不需要“手软”，我们需要有一套本地异常数据过滤的机制，来保证上报的数据都是符合要求的；不然我们后续统计处理的时候，也会因此出现新的问题需要解决。

后续还能做的事

这一部分，是对后续可实现方案的一个美好畅想~

1）页面可见态的终点，不只是覆盖率

其实，实际业务场景中，很多cell，即使绘制完，并渲染到屏幕上，此时，用户可见的也没有达到我们真正希望用户可见的状态，很多内容，都还是一个placeholder的状态。例如，通过url加载的image，我们一般都是先把他的size算好，把他的位置留好，cell渲染完就直接展示了；再进一步，如果是一个视频的播放卡片，即使网络图片加载好了，还要等待视频帧的返回，才能真正达到这张卡片的业务终态\color{red}{业务终态}业务终态（求教这里标红后如何能够让字体大小一致）。

这个非常后置，而且我们端上可能也影响不了什么的节点，采集起来有意义吗？

我觉得这是一个非常有价值的节点。一直都在说“技术反哺业务”，那么业务想要用户真正看到的那个终态，就是很重要的一环；因此，用户能在什么时间点看到，从业务角度说，能够影响其后续的方案设计（表现形式），完善用户体感对业务指标的影响；从技术角度说，可以感知真实的全链路的表现（不只是端），从而有针对性的进行优化。

如何获取到所有的业务终态呢？

这里一定是和业务有所耦合的，因为每个业务的终态，只有业务自身才知道；但是我们还是要尽量降低耦合度。 这里可以用协议的方式，为各个业务增加一个达到终态的标识，那么在某个业务达到终态之后，设置该标识即可，这里就是唯一对业务的侵入了；然后和计算覆盖率类似，这里的遍历，是业务维度（这里想象为卡片更好理解一点），只有全部业务的标识都ready之后，才是真正达到业务上的终态。

2）性能指标 关联 业务行为

其实，现在性能监控，各类平台，各个团队，或多或少的都在做，我相信，性能数据采集的代码，在工程中，也不仅仅只有一份；这个现状，在很多成一定规模的互联网公司中都可能存在。

而如果您和我一样，作为一个业务团队，如何在不重复造轮子的情况下，夹缝中求生存呢？

我个人目前的理解：将 性能表现 与 业务场景 相关联。

帧率、启动耗时、CPU、内存等等，这些性能指标数据的获取，在业界都有非常成熟的方案，而且我们的工程里，一定也有相关的代码；而我们能做的，仅仅是，调一下人家的api，然后把数据再自己上传一份（甚至有的连上传都包含了），就完事了吗？

这样我觉得并不能体现出我们自建监控的价值。个人理解，监控的意义在于：暴露问题 + 辅助定位问题 + 验证问题的解决效果。

所以我们作为业务团队，将 性能数据 和 我们的业务做了什么 bind 到一起了，是不是就能一定程度上完成了上面的目的呢？

我们可以明确，我们什么样的业务行为，会影响我们的性能数据，也就是影响我们的用户基础体验。这样，不仅会帮助我们定位问题的原因，甚至会影响产品侧的一些产品能力设计方案。

完成这些建设之后，可能我们的监控就可以变成这样，甚至更好的状态：

3）完善全链路对性能表现的关注

性能数据的关注、监控，不应该仅仅在线上阶段，开发期 → 测试期 → 线上，全链路各个环节都应该具有。

• 目前各家都比较关注线上监控，相信都已经较为完善；

• 测试期的业务流程性能脚本；对于测试的性能测试方案，开放应该参与共建或者有一定程度的参与，这样才能从一定程度上保证数据的准确性，以及双方性能数据的相互认可；

• 开发期，目前能够提供展示实时CPU、FPS、内存数据的基础能力的工具很常见，也比较容易实现；但实际上，在日常开发的过程中，很难让RD同时关注需求情况与性能数据表现。因此，还是需要一些工具来辅助：例如，我们可以对某些性能指标，设置一些阈值，当日常开发中，超过阈值时，则弹窗提醒RD确认是否原因、是否需要优化，例如，详细UI绘制阶段的耗时阈值是800ms，如果某位同学在进行变更后，实际绘制耗时多次超越该值，则弹窗提醒。

作者：XTShow
来源：juejin.cn/post/7184033051289059384

什么是Sourcery?

Sourcery 是当下最流行的 Swift 代码生成工具之一。其背后使用了 SwiftSyntax[1]，旨在通过自动生成样板代码来节省开发人员的时间。Sourcery 通过扫描一组输入文件，然后借助模板的帮助，自动生成模板中定义的 Swift 代码。

示例

考虑一个为摄像机会话服务提供公共 API 的协议：

protocol Camera {
func start()
func stop()
func capture(_ completion: @escaping (UIImage?) -> Void)
func rotate()
}

当使用此新的 Camera service 进行单元测试时，我们希望确保 AVCaptureSession 没有被真的创建。我们仅仅希望确认 camera service 被测试系统（SUT）正确的调用了，而不是去测试 camera service 本身。
因此，创建一个协议的 mock 实现，使用空方法和一组变量来帮助我们进行单元测试，并断言（asset）进行了正确的调用是有意义的。这是软件开发中非常常见的一个场景，如果你曾维护过一个包含大量单元测试的大型代码库，这么做也可能有点乏味。
好吧~不用担心！Sourcery 会帮助你！⭐️ 它有一个叫做 AutoMockable[2] 的模板，此模板会为任意输入文件中遵守 AutoMockable 协议的协议生成 mock 实现。

注意：在本文中，我扩展地使用了术语 Mock，因为它与 Sourcery 模板使用的术语一致。Mock 是一个相当重载的术语，但通常，如果我要创建一个 双重测试[3]，我会根据它的用途进一步指定类型的名称（可能是 Spy 、 Fake 、 Stub 等）。如果您有兴趣了解更多关于双重测试的信息，马丁·福勒（Martin Fowler）有一篇非常好的文章，可以解释这些差异。

现在，我们让 Camera 遵守 AutoMockable。该接口的唯一目的是充当 Sourcery 的目标，从中查找并生成代码。

import UIKit

// Protocol to be matched
protocol AutoMockable {}

public protocol Camera: AutoMockable {
func start()
func stop()
func capture(_ completion: @escaping (UIImage?) -> Void)
func rotate()
}

此时，可以在上面的输入文件上运行 Sourcery 命令，指定 AutoMockable 模板的路径：

sourcery --sources Camera.swift --templates AutoMockable.stencil --output .

💡 本文通过提供一个 .sourcery.yml 文件来配置 Sourcery 插件。如果提供了配置文件或 Sourcery 可以找到配置文件，则将忽略与其值冲突的所有命令行参数。如果您想了解有关配置文件的更多信息，Sourcery的 repo 中有一节[4]介绍了该主题。
命令执行完毕后，在输出目录下会生成一个 模板名 加 .generated.swift 为后缀的文件。在此例是 ./AutoMockable.generated.swift：

// Generated using Sourcery 1.8.2 — https://github.com/krzysztofzablocki/Sourcery
// DO NOT EDIT
// swiftlint:disable line_length
// swiftlint:disable variable_name

import Foundation
#if os(iOS) || os(tvOS) || os(watchOS)
import UIKit
#elseif os(OSX)
import AppKit
#endif

class CameraMock: Camera {

//MARK: - start

var startCallsCount = 0
var startCalled: Bool {
return startCallsCount > 0
}
var startClosure: (() -> Void)?

func start() {
startCallsCount += 1
startClosure?()
}

//MARK: - stop

var stopCallsCount = 0
var stopCalled: Bool {
return stopCallsCount > 0
}
var stopClosure: (() -> Void)?

func stop() {
stopCallsCount += 1
stopClosure?()
}

//MARK: - capture

var captureCallsCount = 0
var captureCalled: Bool {
return captureCallsCount > 0
}
var captureReceivedCompletion: ((UIImage?) -> Void)?
var captureReceivedInvocations: [((UIImage?) -> Void)] = []
var captureClosure: ((@escaping (UIImage?) -> Void) -> Void)?

func capture(_ completion: @escaping (UIImage?) -> Void) {
captureCallsCount += 1
captureReceivedCompletion = completion
captureReceivedInvocations.append(completion)
captureClosure?(completion)
}

//MARK: - rotate

var rotateCallsCount = 0
var rotateCalled: Bool {
return rotateCallsCount > 0
}
var rotateClosure: (() -> Void)?

func rotate() {
rotateCallsCount += 1
rotateClosure?()
}

}

上面的文件（AutoMockable.generated.swift）包含了你对mock的期望：使用空方法实现与目标协议的一致性，以及检查是否调用了这些协议方法的一组变量。最棒的是… Sourcery 为您编写了这一切！🎉

怎么运行 Sourcery？

怎么使用 Swift package 运行 Sourcery？
至此你可能在想如何以及怎样在 Swift package 中运行 Sourcery。你可以手动执行，然后讲文件拖到包中，或者从包目录中的命令运行脚本。但是对于 Swift Package 有两种内置方式运行可执行文件：
通过命令行插件，可根据用户输入任意运行
通过构建工具插件，该插件作为构建过程的一部分运行。
在本文中，我将介绍 Sourcery 命令行插件，但我已经在编写第二部分，其中我将创建构建工具插件，这带来了许多有趣的挑战。

创建插件包

让我们首先创建一个空包，并去掉测试和其他我们现在不需要的文件夹。然后我们可以创建一个新的插件 Target 并添加 Sourcery 的二进制文件作为其依赖项。
为了让消费者使用这个插件，它还需要被定义为一个产品：

// swift-tools-version: 5.6
import PackageDescription

let package = Package(
name: "SourceryPlugins",
products: [
.plugin(name: "SourceryCommand", targets: ["SourceryCommand"])
],
targets: [
// 1
.plugin(
name: "SourceryCommand",
// 2
capability: .command(
intent: .custom(verb: "sourcery-code-generation", description: "Generates Swift files from a given set of inputs"),
// 3
permissions: [.writeToPackageDirectory(reason: "Need access to the package directory to generate files")]
),
dependencies: ["Sourcery"]
),
// 4
.binaryTarget(
name: "Sourcery",
path: "Sourcery.artifactbundle"
)
]
)

让我们一步一步地仔细查看上面的代码：

1.定义插件目标。
2.以 custom 为意图，定义了 .command 功能，因为没有任何默认功能（ documentationGeneration 和 sourceCodeFormatting）与该命令的用例匹配。给动词一个合理的名称很重要，因为这是从命令行调用插件的方式。
3.插件需要向用户请求写入包目录的权限，因为生成的文件将被转储到该目录。
4.为插件定义了一个二进制目标文件。这将允许插件通过其上下文访问可执行文件。
💡 我知道我并没有详细介绍上面的一些概念，但如果您想了解更多关于命令插件的信息，这里有一篇由 Tibor Bödecs 写的超级棒的文章⭐。如果你还想了解更多关于 Swift Packages 中二级制的目标（文件），我同样有一篇现今 Swift 包中的二进制目标。

编写插件

现在已经创建了包，是时候编写一些代码了！我们首先在 Plugins/SourceryCommand 下创建一个名为 SourceryCommand.swift 的文件，然后添加一个 CommandPlugin 协议的结构体，这将作为该插件的入口：

import PackagePlugin
import Foundation

@main
struct SourceryCommand: CommandPlugin {
func performCommand(context: PluginContext, arguments: [String]) async throws {

}
}

然后我们为命令编写实现：

func performCommand(context: PluginContext, arguments: [String]) async throws {
// 1
let configFilePath = context.package.directory.appending(subpath: ".sourcery.yml").string
guard FileManager.default.fileExists(atPath: configFilePath) else {
Diagnostics.error("Could not find config at: \(configFilePath)")
return
}

//2
let sourceryExecutable = try context.tool(named: "sourcery")
let sourceryURL = URL(fileURLWithPath: sourceryExecutable.path.string)

// 3
let process = Process()
process.executableURL = sourceryURL

// 4
process.arguments = [
"--disableCache"
]

// 5
try process.run()
process.waitUntilExit()

// 6
let gracefulExit = process.terminationReason == .exit && process.terminationStatus == 0
if !gracefulExit {
Diagnostics.error("🛑 The plugin execution failed")
}
}

让我们仔细看看上面的代码：

1.首先 .sourcery.yml 文件必须在包的根目录，否则将报错。这将使 Sourcery 神奇的工作，并使包可配置。
2.可执行文件路径的 URL 是从命令的上下文中检索的。
3.创建一个进程，并将 Sourcery 的可执行文件的 URL 设置为其可执行文件路径。
4.这一步有点麻烦。Sourcery 使用缓存来减少后续运行的代码生成时间，但问题是这些缓存是在包文件夹之外读取和写入的文件。插件的沙箱规则不允许这样做，因此 --disableCache 标志用于禁用此行为并允许命令运行。
5.进程同步运行并等待。
6.最后，检查进程终止状态和代码，以确保进程已正常退出。在任何其他情况下，通过 Diagnostics API 向用户告知错误。
就这样！现在让我们使用它

使用（插件）包

考虑一个用户正在使用插件，该插件将依赖项引入了他们的 Package.swift 文件：

// swift-tools-version: 5.6
// The swift-tools-version declares the minimum version of Swift required to build this package.

import PackageDescription

let package = Package(
name: "SourceryPluginSample",
products: [
// Products define the executables and libraries a package produces, and make them visible to other packages.
.library(
name: "SourceryPluginSample",
targets: ["SourceryPluginSample"]),
],
dependencies: [
.package(url: "https://github.com/pol-piella/sourcery-plugins.git", branch: "main")
],
targets: [
.target(
name: "SourceryPluginSample",
dependencies: [],
exclude: ["SourceryTemplates"]
),
]
)

💡 注意，与构建工具插件不同，命令插件不需要应用于任何目标，因为它们需要手动运行。
用户只使用了上面的 AutoMockable 模板（可以在 Sources/SourceryPluginSample/SourceryTemplates 下找到），与本文前面显示的示例相匹配：

protocol AutoMockable {}

protocol Camera: AutoMockable {
func start()
func stop()
func capture(_ completion: @escaping (UIImage?) -> Void)
func rotate()
}

根据插件的要求，用户还提供了一个位于 SourceryPluginSample 目录下的 .sourcery.yml 配置文件：

sources:
- Sources/SourceryPluginSample
templates:
- Sources/SourceryPluginSample/SourceryTemplates
output: Sources/SourceryPluginSample

运行命令

用户已经设置好了，但是他们现在如何运行包？🤔 有两种方法：

命令行

运行插件的一种方法是用命令行。可以通过从包目录中运行 swift package plugin --list 来检索特定包的可用插件列表。然后可以从列表中选择一个包，并通过运行 swift package <command's verb> 来执行，在这个特殊的例子中，运行： swift package sourcery-code-generation。
注意，由于此包需要特殊权限，因此 --allow-writing-to-package-directory 必须与命令一起使用。
此时，你可能会想，为什么我要费心编写一个插件，仍然必须从命令行运行，而我可以用一个简单的脚本在几行 bash 中完成相同的工作？好吧，让我们来看看 Xcode 14 中会出现什么，你会明白为什么我会提倡编写插件📦。

Xcode

这是运行命令插件最令人兴奋的方式，但不幸的是，它仅在 Xcode 14 中可用。因此，如果您需要运行命令，但尚未使用 Xcode 14，请参阅命令行部分。
如果你正好在使用 Xcode 14，你可以通过在文件资源管理器中右键单击包，从列表中找到要执行的插件，然后单击它来执行包的任何命令。

下一步

这是插件的初始实现。我将研究如何改进它，使它更加健壮。和往常一样，我非常致力于公开构建，并使我的文章中的所有内容都开源，这样任何人都可以提交问题或创建任何具有改进或修复的 PRs。这没有什么不同😀, 这是 公共仓库的链接。
此外，如果您喜欢这篇文章，请关注即将到来的第二部分，其中我将制作一个 Sourcery 构建工具插件。我知道这听起来不多，但这不是一项容易的任务！

前言

Sendable 和 @Sendable 是 Swift 5.5 中的并发修改的一部分，解决了结构化的并发结构体和执行者消息之间传递的类型检查的挑战性问题。

使用 Sendable

应该在什么时候使用 Sendable？
Sendable协议和闭包表明那些传递的值的公共API是否线程安全的向编译器传递了值。当没有公共修改器、有内部锁定系统或修改器实现了与值类型一样的复制写入时，公共API可以安全地跨并发域使用。
标准库中的许多类型已经支持了Sendable协议，消除了对许多类型添加一致性的要求。由于标准库的支持，编译器可以为你的自定义类型创建隐式一致性。
例如，整型支持该协议：

extension Int: Sendable {}

一旦我们创建了一个具有 Int 类型的单一属性的值类型结构体，我们就隐式地得到了对 Sendable 协议的支持。

// 隐式地遵守了 Sendable 协议
struct Article {
var views: Int
}

与此同时，同样的 Article 内容的类，将不会有隐式遵守该协议：

// 不会隐式的遵守 Sendable 协议
class Article {
var views: Int
}

类不符合要求，因为它是一个引用类型，因此可以从其他并发域变异。换句话说，该类文章(Article)的传递不是线程安全的，所以编译器不能隐式地将其标记为遵守Sendable协议。

使用泛型和枚举时的隐式一致性

很好理解的是，如果泛型不符合Sendable协议，编译器就不会为泛型添加隐式的一致性。

// 因为 Value 没有遵守 Sendable 协议，所以 Container 也不会自动的隐式遵守该协议
struct Container<Value> {
var child: Value
}

然而，如果我们将协议要求添加到我们的泛型中，我们将得到隐式支持:

// Container 隐式地符合 Sendable，因为它的所有公共属性也是如此。
struct Container<Value: Sendable> {
var child: Value
}

对于有关联值的枚举也是如此：

如果枚举值们不符合 Sendable 协议，隐式的Sendable协议一致性就不会起作用。

你可以看到，我们自动从编译器中得到一个错误：

Associated value ‘loggedIn(name:)’ of ‘Sendable’-conforming enum ‘State’ has non-sendable type ‘(name: NSAttributedString)’

我们可以通过使用一个值类型String来解决这个错误，因为它已经符合Sendable。

enum State: Sendable {
case loggedOut
case loggedIn(name: String)
}

从线程安全的实例中抛出错误

同样的规则适用于想要符合Sendable的错误类型。

struct ArticleSavingError: Error {
var author: NonFinalAuthor
}

extension ArticleSavingError: Sendable { }

由于作者不是不变的（non-final），而且不是线程安全的（后面会详细介绍），我们会遇到以下错误：

Stored property ‘author’ of ‘Sendable’-conforming struct ‘ArticleSavingError’ has non-sendable type ‘NonFinalAuthor’

你可以通过确保ArticleSavingError的所有成员都符合Sendable协议来解决这个错误。

如何使用Sendable协议

可变的非最终类无法遵守 Sendable 协议

由于该类是非最终的，我们无法符合Sendable协议的要求，因为我们不确定其他类是否会继承User的非Sendable成员。因此，我们会遇到以下错误:

Non-final class ‘User’ cannot conform to Sendable; use @unchecked Sendable

正如你所看到的，编译器建议使用@unchecked Sendable。我们可以把这个属性添加到我们的User类中，并摆脱这个错误:

class User: @unchecked Sendable {
let name: String

init(name: String) { self.name = name }
}

然而，这确实要求我们无论何时从User继承，都要确保它是线程安全的。由于我们给自己和同事增加了额外的责任，我不鼓励使用这个属性，建议使用组合、最终类或值类型来实现我们的目的。

如何使用 @Sendabele

前言

什么是Core Data

数据模型文件 - Data Model

数据模型中的表格 - Entity

属性 - Attributes

关系 - Relationship

一对一和一对多 - to one和to many

Core Data框架的主仓库 - NSPersistentContainer

import CoreData

❝

早期，在iOS 10之前，还没有NSPersistentContainer这个类，所以Core Data提供的几种各司其职的工具，我们都要写代码一一获得，写出来的代码较为繁琐，所以NSPersistentContainer并不是一开始就有的，而是苹果框架设计者逐步优化出来的较优设计。

图4: NSPersistentContainer和其他成员的关系

NSPersistentContainer的初始化

private func createPersistentContainer() {
let container = NSPersistentContainer(name: "Model")
}

private func createPersistentContainer() {
let container = NSPersistentContainer(name: "Model")
container.loadPersistentStores { (description, error) in
if let error = error {
fatalError("Error: \(error)")
}
print("Load stores success")
}
}

❝

从代码设计的角度看，为什么NSPersistentContainer不直接在构造函数里完成数据库的加载？这就涉及到一个面向对象的开发原则，即构造函数的初始化应该是（原则上）倾向于原子级别，即简单的、低开销内存操作，而对于性能开销大的，内存之外的存储空间处理（比如磁盘，网络），应尽量单独提供成员函数来完成。这样做是为了避免在构造函数中出错时错误难以捕捉的问题。

表格属性信息的提供者 - NSManagedObjectModel

private func parseEntities(container: NSPersistentContainer) {
let entities = container.managedObjectModel.entities
print("Entity count = \(entities.count)\n")
for entity in entities {
print("Entity: \(entity.name!)")
for property in entity.properties {
print("Property: \(property.name)")
}
print("")
}
}

private func createPersistentContainer() {
let container = NSPersistentContainer(name: "Model")
container.loadPersistentStores { (description, error) in
if let error = error {
fatalError("Error: \(error)")
}

self.parseEntities(container: container)
}
}

Entity count = 2

Entity: Book
Property: isbm
Property: name
Property: page
Property: borrowedBy

Entity: Reader
Property: idCard
Property: name
Property: borrow

Entity对应的类

var book: Book! // 纯测验代码，无业务价值

❝

关于类名，官方教程里一般会把类名更改为Entity名 + MO，比如我们这个Entity名为Book，那么如果是按照官方教程的做法，可以在面板中编辑Class的名字为BookMO，这里MO大概就是Model Object的简称吧。

但是我这里为简洁起见，就不做任何更改了，Entity名为Book，那么类名也一样为Book。

❝

另外，你也可以自己去定义Entity对应的类，这样有个好处是可以给类添加一些额外的功能支持，这部分Core Data提供了编写的规范，但是大部分时候这个做法反而会增加代码量，不属于常规操作。

数据业务的操作员 - NSManagedObjectContext

数据的插入 - NSentityDescription.insertNewObject

private func createBook(container: NSPersistentContainer,
name: String, isbm: String, pageCount: Int) {
let context = container.viewContext
let book = NSEntityDescription.insertNewObject(forEntityName: "Book",
into: context) as! Book
book.name = name
book.isbm = isbm
book.page = Int32(pageCount)
if context.hasChanges {
do {
try context.save()
print("Insert new book(\(name)) successful.")
} catch {
print("\(error)")
}
}
}

private func createPersistentContainer() {
let container = NSPersistentContainer(name: "Model")
container.loadPersistentStores { (description, error) in
if let error = error {
fatalError("Error: \(error)")
}

//self.parseEntities(container: container)
self.createBook(container: container,
name: "算法（第4版）",
isbm: "9787115293800",
pageCount: 636)
}
}

Insert new book(算法（第4版）) successful.

至此，书本的插入工作顺利完成！

❝

因为这个示例没有去重判定，如果程序运行两次，那么将会插入两条书名都为"算法（第4版）"的book记录。

数据的获取

private func readBooks(container: NSPersistentContainer) {
let context = container.viewContext
let fetchBooks = NSFetchRequest<Book>(entityName: "Book")
do {
let books = try context.fetch(fetchBooks)
print("Books count = \(books.count)")
for book in books {
print("Book name = \(book.name!)")
}
} catch {

}
}

打印结果：

Books count = 1
Book name = 算法（第4版）

数据获取的条件筛选 - NSPredicate

private func readBooks(container: NSPersistentContainer) {
let context = container.viewContext
let fetchBooks = NSFetchRequest<Book>(entityName: "Book")
fetchBooks.predicate = NSPredicate(format: "name = \"算法（第4版）\"")
do {
let books = try context.fetch(fetchBooks)
print("Books count = \(books.count)")
for book in books {
print("Book name = \(book.name!)")
}
} catch {
print("\(error)")
}
}

通过代码：

fetchBooks.predicate = NSPredicate(format: "name = \"算法（第4版）\"")

fetchBooks.predicate = NSPredicate(format: "page > 100")

这样将筛选出page数量大于100的书籍。

数据的修改

let context = container.viewContext
let fetchBooks = NSFetchRequest<Book>(entityName: "Book")
fetchBooks.predicate = NSPredicate(format: "isbm = \"9787115293800\"")
do {
let books = try context.fetch(fetchBooks)
if !books.isEmpty {
books[0].name = "算法（第5版）"
if context.hasChanges {
try context.save()
print("Update success.")
}
}
} catch {
print("\(error)")
}

数据的删除

let context = container.viewContext
let fetchBooks = NSFetchRequest<Book>(entityName: "Book")
fetchBooks.predicate = NSPredicate(format: "isbm = \"9787115293800\"")
do {
let books = try context.fetch(fetchBooks)
for book in books {
context.delete(books[0])
}
if context.hasChanges {
try context.save()
}
} catch {
print("\(error)")
}

扩展和进阶主题的介绍

1. Relationship部分的开发，事实上通过之前的知识可以独立完成。
2. 回滚操作，相关类：UndoManager。
3. Entity的Fetched Property属性。
4. 多个context一起操作数据的冲突问题。
5. 持久化层的管理，包括迁移文件地址，设置多个存储源等。

结语

Core Data在圈内是比较出了名的“不好用”的框架，主要是因为其抽象的功能和机制较为不容易理解。本文已经以最大限度的努力试图从设计的角度去阐述该框架，希望对你有所帮助。

前言

有时候集成一个特定的库（比如 PayPal）是必须的，有时候是避免去开发一些非常复杂的功能，有时候仅仅只是避免重复造轮子。

虽然这些都是合理的考量，但使用第三方库的风险和相关成本往往被忽视或误解。在某些情况下，风险是值得的，但是在决定冒险之前，首先要能够明确的定义风险。为了使风险评估更加的透明和一致，我们制定了一个流程来衡量我们将其集成到app有多大的风险。

风险

大多数大型组织，包括我们，都有某种形式的代码审查，作为开发实践的一部分。对这些团队来说，添加一个第三方库就相当于添加了一堆由不属于团队成员开发，未经审查的代码。这破坏了团队一直坚持的代码审查原则，交付了质量未知的代码。这给app的运行方式以及长期开发带来了风险，对于大型团队而言，更是对整体业务带来了风险。

运行时风险

库代码通常来说，对于系统资源，和app拥有相同级别的访问权限，但它们不一定应用团队为管理这些资源而制定的最佳实践。这意味着它们可以在没有限制的情况下访问磁盘，网络，内存，CPU等等，因此，它们可以（过度）将文件写入磁盘，使用未优化的代码占用内存或CPU，导致死锁或主线程延迟，下载（和上传！）大量数据等等。更糟糕的是他们会导致崩溃，甚至崩溃循环。两次。

其中许多情况直到 app 已经上架才被发现，在这种情况下，修复它需要创建一个新版本，并通过审核，这通常需要大量时间和成本。这种风险可以通过一个变量控制是否调用来进行一定程度的控制，但是这种方法也并非万无一失（看下文）。

开发风险

引用一个同事的话：“每一行代码都是一种负担”，对不是你自己写的代码而言，这句话更甚。库在适配新技术或API时可能很慢，这阻碍了代码开发，或者太快，导致开发的版本过高。

库在采用新技术或API时可能很慢，阻碍了代码库，或者太快，导致部署目标太高。每当 Apple 和 Google 每年发布一个新 OS 版本时，他们通常要求开发人员根据SDK的变化更新代码，库开发人员也必须这样做。这需要协调一致的努力、优先事项的一致性以及及时完成工作的能力。

随着移动平台的不断变化，以及团队（成员）也不是一成不变，这将会成为一个持续不断的风险。当被集成的库不存在了，而库又需要更新时，会花很多时间来决定谁来做。事实证明一旦一个库存在，就很少也很难被移除，因此我们将其视为长期维护成本。

商业风险

如同我上面所说，现代的操作系统并没有对 app 代码和库代码进行区分，因此除了系统资源之外，它们还可以访问用户信息。作为 app 的开发者，我们负责恰当的使用这部分信息，也需要为任何第三方库负责。

如果用户给了 Lyft app 地理位置授权，任何第三方库也将自动得获得授权。他们可以将那些（地理位置）数据上传到自己服务器，竞对服务器，或者谁知道还有什么地方。当一个库需要我们没有的权限时，那问题就更大了。

同样，一个系统的安全取决于其最薄弱的环节，但如果其中包含未经审核的代码，那么你就不知道它到底有多安全。你精心设计的安全编码实践可能会被一个行为不当的库所破坏。苹果和谷歌实施的任何政策都是如此，例如“你不得对用户追踪”。

减少风险

当对一个库（是否）进行使用评估时，我们首先要问几个问题，以了解对库的需求。

我们内部能做么？

有时候我们只需要简单的粘贴复制真正需要的部分。在更复杂的场景中，库与自定义后端通信，我们对该API进行了逆向，并自己构建了一个迷你SDK（同样，只构建了我们需要的部分）。在90%的情况下，这是首选，但在与非常特定的供应商或需求集成时并不总是可行。

有多少用户从该库中受益？

在一种情况下，我们正在考虑添加一个风险很大的库（根据下面的标准），旨在为一小部分用户提供服务，同时将我们的所有用户都暴露在该库中。对于我们认为会从中受益的一小部分客户，我们冒了为我们所有用户带来问题的风险。

这个库有什么传递依赖？

我们还需要评估库的所有依赖项的以下标准。

退出标准是什么？

如果集成成功，是否有办法将其转移到内部？如果不成功，是否有办法删除？

评价标准

如果此时团队仍然希望集成库，我们要求他们根据一组标准对库进行“评分”。下面的列表并不全面，但应该能很好地说明我们希望看到的。

阻断标准

这些标准将阻止我们从技术上或者公司政策上集成此库，在进行下一步之前，我们必须解决：

过高的 deployment target/target SDKs。 我们支持过去4年主流的操作系统（版本），所以第三方库至少也需要支持一样多。

许可证不正确/缺失。 我们将许可文件与应用捆绑在一起，以确保我们可以合法使用代码并将其归属于许可持有人。

没有冲突的传递依赖关系。 一个库不能有一个我们已经包含但版本不同的传递依赖项。

不显示它自己的 UI 。 我们非常小心地使我们的产品看起来尽可能统一，定制用户界面对此不利。

它不使用私有 API 。 我们不愿意冒 app 因使用私有 API 而被拒绝的风险。

主要关注点

闭源。 访问源代码意味着我们可以选择我们想要包含的库的哪些部分，以及如何将该源代码与应用程序的其余部分捆绑在一起。对于我们来说，一个封闭源代码的二进制发行版更难集成。

编译时有警告。 我们启用了“警告视为错误”，具有编译警告的库是库整体质量（下降）的良好指示。

糟糕的文档。 我们希望有高质量的内联文档，外部”如何使用“文档，以及有意义的更新日志。

二进制体积。 这个库有多大？一些库提供了很多功能，而我们只需要其中的一小部分。尤其是在没有访问源码权限的情况下，这通常是一个全有或全无的情况。

外部的网络流量。 与我们无法控制的上游服务器/端点通信的库可能会在服务器关闭、错误数据被发回等时关闭整个应用程序。这也与我上面提到的隐私问题相同。

技术支持。 当事情不能正常工作时，我们需要能够报告/上报问题，并在合理的时间内解决问题。开源项目通常由志愿者维护，也很难有一个时间线，但至少我们可以自己进行修改。这在闭源项目是不可能的。

无法禁用。 虽然大多数库特别要求我们初始化它，但有些库在实例化时更“主动”，并且在我们不调用它的情况下可以自己执行工作。这意味着当库导致问题时，我们无法通过功能变量或其他机制将其关闭。

我们为所有这些（和其他一些）标准分配了点数，并要求工程师为他们想要集成的库汇总这些点数。虽然默认情况下，低分数并不难被拒绝，但我们通常会要求更多的理由来继续前进。

最后

虽然这个过程看起来非常严格，在许多情况下，潜在风险是假设的，但我们有我在这篇博文中描述的每个场景的实际例子。将评估记录下来并公开，也有助于将相对风险传达给不熟悉移动平台工作方式的人，并证明我们没有随意评估风险。

本文在“扫一扫功能的不断迭代，基于设计模式的基本原则，逐步采用设计模式思想进行代码和架构优化”的背景下，对设计模式在扫一扫中新的应用进行了总结。

背景

扫一扫是淘宝镜头页中的一个重要组成，功能运行久远，其历史代码中较少采用面向对象编程思想，而较多采用面向过程的程序设计。

随着扫一扫功能的不断迭代，我们基于设计模式的基本原则，逐步采用设计模式思想进行代码和架构优化。本文就是在这个背景下，对设计模式在扫一扫中新的应用进行了总结。

扫一扫原架构

扫一扫的原架构如图所示。其中逻辑&展现层的功能逻辑很多，并没有良好的设计和拆分，举几个例子：

1. 所有码的处理逻辑都写在同一个方法体里，一个方法就接近 2000 多行。

2. 庞大的码处理逻辑写在 viewController 中，与 UI 逻辑耦合。

按照现有的代码设计，若要对某种码逻辑进行修改，都必须将所有逻辑全量编译。如果继续沿用此代码，扫一扫的可维护性会越来越低。

因此我们需要对代码和架构进行优化，在这里优化遵循的思路是：

1. 了解业务能力

2. 了解原有代码逻辑，不确定的地方通过埋点等方式线上验证

3. 对原有代码功能进行重写/重构

4. 编写单元测试，提供测试用例

5. 测试&上线

扫码能力综述

扫一扫的解码能力决定了扫一扫能够处理的码类型，这里称为一级分类。基于一级分类，扫一扫会根据码的内容和类型，再进行二级分类。之后的逻辑，就是针对不同的二级类型，做相应的处理，如下图为技术链路流程。

设计模式

责任链模式

上述技术链路流程中，码处理流程对应的就是原有的 viewController 里面的巨无霸逻辑。通过梳理我们看到，码处理其实是一条链式的处理，且有前后依赖关系。优化方案有两个，方案一是拆解成多个方法顺序调用；方案二是参考苹果的 NSOperation 独立计算单元的思路，拆解成多个码处理单元。方案一本质还是没解决开闭原则（对扩展开放，对修改封闭）问的题。方案二是一个比较好的实践方式。那么怎么设计一个简单的结构来实现此逻辑呢？

码处理链路的特点是，链式处理，可控制处理的顺序，每个码处理单元都是单一职责，因此这里引出改造第一步：责任链模式。

责任链模式是一种行为设计模式， 它将请求沿着处理者链进行发送。收到请求后， 每个处理者均可对请求进行处理， 或将其传递给链上的下个处理者。

本文设计的责任链模式，包含三部分：

1. 创建数据的 Creator

2. 管理处理单元的 Manager

3. 处理单元 Pipeline

三者结构如图所示

创建数据的 Creator

包含的功能和特点：

1. 因为数据是基于业务的，所以它只被声明为一个 Protocol ，由上层实现。

2. Creator 对数据做对象化，对象生成后 self.generateDataBlock(obj, Id) 即开始执行

API 代码示例如下

/// 数据产生协议 <CreatorProtocol>
@protocol TBPipelineDataCreatorDelegate <NSObject>
@property (nonatomic, copy) void(^generateDataBlock)(id data, NSInteger dataId);
@end
复制代码

上层业务代码示例如下

@implementation TBDataCreator
@synthesize generateDataBlock;
- (void)receiveEventWithScanResult:(TBScanResult *)scanResult                                                        eventDelegate:(id <TBScanPipelineEventDeletate>)delegate {
    //对数据做对象化 
    TBCodeData *data = [TBCodeData new];
    data.scanResult = scanResult;
    data.delegate = delegate;
    
    NSInteger dataId = 100; 
    //开始执行递归
    self.generateDataBlock(data, dataId);
}
@end
复制代码

管理处理单元的 Manager

包含的功能和特点：

1. 管理创建数据的 Creator

2. 管理处理单元的 Pipeline

3. 采用支持链式的点语法，方便书写

API 代码示例如下

@interface TBPipelineManager : NSObject
/// 添加创建数据 Creator
- (TBPipelineManager *(^)(id<TBPipelineDataCreatorDelegate> dataCreator))addDataCreator;
/// 添加处理单元 Pipeline
- (TBPipelineManager *(^)(id<TBPipelineDelegate> pipeline))addPipeline;
/// 抛出经过一系列 Pipeline 的数据。当 Creator 开始调用 generateDataBlock 后，Pipeline 就开始执行
@property (nonatomic, strong) void(^throwDataBlock)(id data);
@end
复制代码

实现代码示例如下

@implementation TBPipelineManager
- (TBPipelineManager *(^)(id<TBPipelineDataCreatorDelegate> dataCreator))addDataCreator {    
    @weakify
    return ^(id<TBPipelineDataCreatorDelegate> dataCreator) {
        @strongify
        if (dataCreator) {
            [self.dataGenArr addObject:dataCreator]; 
        }
        return self;
    };
}

- (TBPipelineManager *(^)(id<TBPipelineDelegate> pipeline))addPipeline {
    @weakify
    return ^(id<TBPipelineDelegate> pipeline) {
        @strongify
        if (pipeline) {
            [self.pipelineArr addObject:pipeline];
            
            //每一次add的同时，我们做链式标记（通过runtime给每个处理加Next）
            if (self.pCurPipeline) {
                NSObject *cur = (NSObject *)self.pCurPipeline;                
                cur.tb_nextPipeline = pipeline;
            }
            self.pCurPipeline = pipeline;
        }
        return self;
    };
}

- (void)setThrowDataBlock:(void (^)(id _Nonnull))throwDataBlock {
    _throwDataBlock = throwDataBlock;
    
    @weakify
    //Creator的数组，依次对 Block 回调进行赋值，当业务方调用此 Block 时，就是开始处理数据的时候    
    [self.dataGenArr enumerateObjectsUsingBlock:^(id<TBPipelineDataCreatorDelegate>  _Nonnull obj, NSUInteger idx, BOOL * _Nonnull stop) {
        obj.generateDataBlock = ^(id<TBPipelineBaseDataProtocol> data, NSInteger dataId) {                 @strongify
            data.dataId = dataId;
            //开始递归处理数据
            [self handleData:data];
        };
    }];
}

- (void)handleData:(id)data {
    [self recurPipeline:self.pipelineArr.firstObject data:data];
}

- (void)recurPipeline:(id<TBPipelineDelegate>)pipeline data:(id)data {
    if (!pipeline) {
        return;
    }
    
    //递归让pipeline处理数据
    @weakify
    [pipeline receiveData:data throwDataBlock:^(id  _Nonnull throwData) {
        @strongify 
        NSObject *cur = (NSObject *)pipeline;
        if (cur.tb_nextPipeline) {
            [self recurPipeline:cur.tb_nextPipeline data:throwData];
        } else {
            !self.throwDataBlock?:self.throwDataBlock(throwData);
        }
    }];
}
@end
复制代码

处理单元 Pipeline

包含的功能和特点：

1. 因为数据是基于业务的，所以它只被声明为一个 Protocol ，由上层实现。

API 代码示例如下

@protocol TBPipelineDelegate <NSObject>
//如果有错误，直接抛出
- (void)receiveData:(id)data throwDataBlock:(void(^)(id data))block;
@end
复制代码

上层业务代码示例如下

//以A类型码码处理单元为例
@implementation TBGen3Pipeline
- (void)receiveData:(id <TBCodeDataDelegate>)data throwDataBlock:(void (^)(id data))block {    
    TBScanResult *result = data.scanResult;
    NSString *scanType = result.resultType;
    NSString *scanData = result.data;
    
    if ([scanType isEqualToString:TBScanResultTypeA]) {
        //跳转逻辑
        ...
        //可以处理，终止递归
        BlockInPipeline();
    } else {
        //不满足处理条件，继续递归：由下一个 Pipeline 继续处理
        PassNextPipeline(data);
    }
}
@end
复制代码

业务层调用

有了上述的框架和上层实现，生成一个码处理管理就很容易且能达到解耦的目的，代码示例如下

- (void)setupPipeline { 
    //创建 manager 和 creator
    self.manager = TBPipelineManager.new;
    self.dataCreator = TBDataCreator.new;
    
    //创建 pipeline
    TBCodeTypeAPipelie *codeTypeAPipeline = TBCodeTypeAPipelie.new;
    TBCodeTypeBPipelie *codeTypeBPipeline = TBCodeTypeBPipelie.new;
    //... 
    TBCodeTypeFPipelie *codeTypeFPipeline = TBCodeTypeFPipelie.new;
    
    //往 manager 中链式添加 creator 和 pipeline
    @weakify
    self.manager
    .addDataCreator(self.dataCreator)
    .addPipeline(codeTypeAPipeline) 
    .addPipeline(codeTypeBPipeline)
    .addPipeline(codeTypeFPipeline)
    .throwDataBlock = ^(id data) {
        @strongify 
        if ([self.proxyImpl respondsToSelector:@selector(scanResultDidFailedProcess:)]) {                   [self.proxyImpl scanResultDidFailedProcess:data];
        }
    };
}
复制代码

状态模式

回头来看下码展示的逻辑，这是我们用户体验优化的一项重要内容。码展示的意思是对于当前帧/图片，识别到码位置，我们进行锚点的高亮并跳转。这里包含三种情况：

1. 未识别到码的时候，无锚点展示

2. 识别到单码的时候，展示锚点并在指定时间后跳转

3. 识别到多码额时候，展示锚点并等待用户点击

可以看到，这里涉及到简单的展示状态切换，这里就引出改造的第二步：状态模式

状态模式是一种行为设计模式， 能在一个对象的内部状态变化时改变其行为， 使其看上去就像改变了自身所属的类一样。

本文设计的状态模式，包含两部分：

1. 状态的信息 StateInfo

2. 状态的基类 BaseState

两者结构如图所示

状态的信息 StateInfo

包含的功能和特点：

1. 当前上下文仅有一种状态信息流转

2. 业务方可以保存多个状态键值对，状态根据需要执行相应的代码逻辑。

状态信息的声明和实现代码示例如下

@interface TBBaseStateInfo : NSObject {
    @private 
    TBBaseState<TBBaseStateDelegate> *_currentState; //记录当前的 State
}
//使用当前的 State 执行
- (void)performAction;
//更新当前的 State
- (void)setState:(TBBaseState <TBBaseStateDelegate> *)state;
//获取当前的 State
- (TBBaseState<TBBaseStateDelegate> *)getState;
@end

@implementation TBBaseStateInfo
- (void)performAction {
    //当前状态开始执行 
    [_currentState perfromAction:self];
}
- (void)setState:(TBBaseState <TBBaseStateDelegate> *)state {
    _currentState = state;
}
- (TBBaseState<TBBaseStateDelegate> *)getState {
    return _currentState;
}
@end
复制代码

上层业务代码示例如下

typedef NS_ENUM(NSInteger,TBStateType) {

    TBStateTypeNormal, //空状态

    TBStateTypeSingleCode, //单码展示态

    TBStateTypeMultiCode, //多码展示态

};



@interface TBStateInfo : TBBaseStateInfo

//以 key-value 的方式存储业务 type 和对应的状态 state

- (void)setState:(TBBaseState<TBBaseStateDelegate> *)state forType:(TBStateType)type;

//更新 type，并执行 state

- (void)setType:(TBStateType)type;

@end



@implementation TBStateInfo



- (void)setState:(TBBaseState<TBBaseStateDelegate> *)state forType:(TBStateType)type {    

    [self.stateDict tb_setObject:state forKey:@(type)];

}



- (void)setType:(TBStateType)type {

    id oldState = [self getState]; 

    //找到当前能响应的状态

    id newState = [self.stateDict objectForKey:@(type)];

    //如果状态未发生变更则忽略

    if (oldState == newState) 

        return;

    if ([newState respondsToSelector:@selector(perfromAction:)]) {

        [self setState:newState];

        //转态基于当前的状态信息开始执行

        [newState perfromAction:self];

    }

}

@end

复制代码

状态的基类 BaseState

包含的功能和特点：

1. 定义了状态的基类

2. 声明了状态的基类需要遵循的 Protocol

Protocol 如下，基类为空实现，子类继承后，实现对 StateInfo 的处理。

@protocol TBBaseStateDelegate <NSObject>

- (void)perfromAction:(TBBaseStateInfo *)stateInfo;

@end

复制代码

上层（以单码 State 为例）代码示例如下

@interface TBSingleCodeState : TBBaseState
@end

@implementation TBSingleCodeState

//实现 Protocol
- (void)perfromAction:(TBStateInfo *)stateAction {
    //业务逻辑处理 Start
    ...
    //业务逻辑处理 End
}

@end
复制代码

业务层调用

以下代码生成一系列状态，在合适时候进行状态的切换。

//状态初始化
- (void)setupState {
    TBSingleCodeState *singleCodeState =TBSingleCodeState.new; //单码状态
    TBNormalState *normalState =TBNormalState.new; //正常状态
    TBMultiCodeState *multiCodeState = [self getMultiCodeState]; //多码状态
    
    [self.stateInfo setState:normalState forType:TBStateTypeNormal];
    [self.stateInfo setState:singleCodeState forType:TBStateTypeSingleCode];
    [self.stateInfo setState:multiCodeState forType:TBStateTypeMultiCode];
}

//切换常规状态
- (void)processorA {
    //...
    [self.stateInfo setType:TBStateTypeNormal];
    //...
}

//切换多码状态
- (void)processorB {
    //...
    [self.stateInfo setType:TBStateTypeMultiCode];
    //...
}

//切换单码状态
- (void)processorC {
    //...
    [self.stateInfo setType:TBStateTypeSingleCode];
    //...
}
复制代码

最好根据状态机图编写状态切换代码，以保证每种状态都有对应的流转。

代理模式

在开发过程中，我们会在越来越多的地方使用到上图能力，比如「淘宝拍照」的相册中、「扫一扫」的相册中，用到解码、码展示、码处理的能力。

因此，我们需要把这些能力封装并做成插件化，以便在任何地方都能够使用。这里就引出了我们改造的第三步：代理模式。

代理模式是一种结构型设计模式，能够提供对象的替代品或其占位符。代理控制着对于原对象的访问， 并允许在将请求提交给对象前后进行一些处理。 本文设计的状态模式，包含两部分：

1. 代理单例 GlobalProxy

2. 代理的管理 ProxyHandler

两者结构如图所示

代理单例 GlobalProxy

单例的目的主要是减少代理重复初始化，可以在合适的时机初始化以及清空保存的内容。单例模式对于 iOSer 再熟悉不过了，这里不再赘述。

代理的管理 Handler

维护一个对象，提供了对代理增删改查的能力，实现对代理的操作。这里实现 Key - Value 的 Key 为 Protocol ，Value 为具体的代理。

代码示例如下

+ (void)registerProxy:(id)proxy withProtocol:(Protocol *)protocol {
    if (![proxy conformsToProtocol:protocol]) {
        NSLog(@"#TBGlobalProxy, error"); 
        return;
    }
    if (proxy) {
        [[TBGlobalProxy sharedInstance].proxyDict setObject:proxy forKey:NSStringFromProtocol(protocol)];
    }
}

+ (id)proxyForProtocol:(Protocol *)protocol {
    if (!protocol) {
        return nil;
    }
    id proxy = [[TBGlobalProxy sharedInstance].proxyDict objectForKey:NSStringFromProtocol(protocol)];
    return proxy;
}

+ (NSDictionary *)proxyConfigs {
    return [TBGlobalProxy sharedInstance].proxyDict;
}

+ (void)removeAll {
    [TBGlobalProxy sharedInstance].proxyDict = [[NSMutableDictionary alloc] init];
}
复制代码

业务层的调用

所以不管是什么业务方，只要是需要用到对应能力的地方，只需要从单例中读取 Proxy，实现该 Proxy 对应的 Protocol，如一些回调、获取当前上下文等内容，就能够获取该 Proxy 的能力。

//读取 Proxy 的示例
- (id <TBScanProtocol>)scanProxy {
    if (!_scanProxy) {
        _scanProxy = [TBGlobalProxy proxyForProtocol:@protocol(TBScanProtocol)];
    }
    _scanProxy.proxyImpl = self;
    return _scanProxy;
}

//写入 Proxy 的示例（解耦调用）
- (void)registerGlobalProxy {
    //码处理能力
    [TBGlobalProxy registerProxy:[[NSClassFromString(@"TBScanProxy") alloc] init]                                   withProtocol:@protocol(TBScanProtocol)]; 
    //解码能力
    [TBGlobalProxy registerProxy:[[NSClassFromString(@"TBDecodeProxy") alloc] init]                                 withProtocol:@protocol(TBDecodeProtocol)];}
复制代码

扫一扫新架构

基于上述的改造优化，我们将原扫一扫架构进行了优化：将逻辑&展现层进行代码分拆，分为属现层、逻辑层、接口层。已达到层次分明、职责清晰、解耦的目的。

总结

上述沉淀的三个设计模式作为扫拍业务的 Foundation 的 Public 能力，应用在镜头页的业务逻辑中。

通过此次重构，提高了扫码能力的复用性，结构和逻辑的清晰带来的是维护成本的降低，不用再大海捞针从代码“巨无霸”中寻找问题，降低了开发人日。

作者：阿里巴巴大淘宝技术
来源：https://juejin.cn/post/7127858822395199502

iOS 消息调用属于基本知识，苹果官方有一个详细的介绍图：

1 - (BOOL)resolveInstanceMethod:(SEL)sel ; 
2 - (id)forwardingTargetForSelector:(SEL)aSelector ;

1 + (BOOL)resolveClassMethod:(SEL)sel ; 
2 - (void)doesNotRecognizeSelector:(SEL)aSelector ;

if (@available(iOS 13.0, *)) {
   self.overrideUserInterfaceStyle =  UIUserInterfaceStyleDark;//UIUserInterfaceStyleLight
} else {
    // Fallback on earlier versions
}

注意当我们在window上设置 overrideUserInterfaceStyle的时候，就会影响 window下所有的controller,view，包括后续推出的 controller。

UIStatusBarManager *statusBarManager = [UIApplication sharedApplication].keyWindow.windowScene.statusBarManager;
UIView *statusBar;
#pragma clang diagnostic push
#pragma clang diagnostic ignored "-Wundeclared-selector"
if([statusBarManager respondsToSelector:@selector(createLocalStatusBar)]) {
            
    UIView *localStatusBar= [statusBarManager performSelector:@selector(createLocalStatusBar)];
    if ([localStatusBar respondsToSelector:@selector(statusBar)]) {
                
        statusBar = [localStatusBar performSelector:@selector(statusBar)];
    }    
}

if(@available(iOS 13.0, *)) {

    //上面获取statusBar代码        
} else {
    
    UIView *statusBar = [[UIApplication sharedApplication] 
    valueForKey:@"statusBar"];

}

//在ios13使用会引发崩溃
[self.textField setValue:self.placeholderColor 
forKeyPath:@"_placeholderLabel.textColor"];

'Access to UITextField's _placeholderLabel ivar is prohibited. 
This is an application bug'

NSMutableAttributedString *placeholderString = [[NSMutableAttributedString alloc] initWithString:placeholder 
attributes:@{NSForegroundColorAttributeName : self.placeholderColor}];
_textField.attributedPlaceholder = placeholderString;

erminating app due to uncaught exception'NSInternalInconsistencyException', reason: 'Missing or detached view for search bar layout'

for (UIView *view in _searchBar.subviews.lastObject.subviews) {
   if ([view isKindOfClass:NSClassFromString(@"UISearchBarBackground")]) {
        view.layer.contents = nil;
        break;
    }
 }

UITextField *searchFiled = [self valueForKey:@"_searchField"];

@property (nonatomic, readonly) UISearchTextField *searchTextField;

UIKIT_CLASS_AVAILABLE_IOS_ONLY(13.0)
@interface UISearchTextField : UITextField
///功能省略
@end

UITextField *searchField;
 if(@available(iOS 13.0, *)) {
    //UISearchBar的self.searchTextField属性是readonly，不能直接用
    searchField =  self.searchTextField; 
 } else {
    searchField = [self valueForKey:@"_searchField"];
 }

- (UIModalPresentationStyle)modalPresentationStyle {
    return UIModalPresentationFullScreen;
}

'MPMoviePlayerController is no longer available. Use AVPlayerViewController in AVKit.'

UIWindow* window = nil;
if (@available(iOS 13.0, *)) {
    for (UIWindowScene* windowScene in [UIApplication sharedApplication].connectedScenes) {
        if (windowScene.activationState == UISceneActivationStateForegroundActive) {
            window = windowScene.windows.firstObject;
            break;
        }
    }
}else{
    window = [UIApplication sharedApplication].keyWindow;
}

if ( @available(iOS 13.0, *)) {
    self.segmentedControl.selectedSegmentTintColor = [UIColor yellowcolor];
} else {
    self.segmentedControl.tintColor = [UIColor yellowcolor];
}

前言

小编最近在项目中遇到了一个问题，除刘海屏以外的iOS设备可以正常的搜索到硬件设备，但是刘海屏就不行。因此，小编花了一点时间研究了一下iOS设备获取当前设备的网络状态。

实现

因为iOS的系统是封闭的，所以是没有直接的APi去获取当前的网络状态。但是道高一尺，魔高一尺。开发者总会有办法获取自己想要的东西。

1.网络状态获取

获取当前的网络类型

获取当前的网络类型是通过获取状态栏，然后遍历状态栏的视图完成的。

先导入头文件，如下：

#import "AppDelegate.h"

实现方法如下：

+ (NSString *)getNetworkType
{
    UIApplication *app = [UIApplication sharedApplication];
    id statusBar = nil;
//    判断是否是iOS 13
    NSString *network = @"";
    if (@available(iOS 13.0, *)) {
        UIStatusBarManager *statusBarManager = [UIApplication sharedApplication].keyWindow.windowScene.statusBarManager;
        
#pragma clang diagnostic push
#pragma clang diagnostic ignored "-Wundeclared-selector"
        if ([statusBarManager respondsToSelector:@selector(createLocalStatusBar)]) {
            UIView *localStatusBar = [statusBarManager performSelector:@selector(createLocalStatusBar)];
            if ([localStatusBar respondsToSelector:@selector(statusBar)]) {
                statusBar = [localStatusBar performSelector:@selector(statusBar)];
            }
        }
#pragma clang diagnostic pop
        
        if (statusBar) {
//            UIStatusBarDataCellularEntry
            id currentData = [[statusBar valueForKeyPath:@"_statusBar"] valueForKeyPath:@"currentData"];
            id _wifiEntry = [currentData valueForKeyPath:@"wifiEntry"];
            id _cellularEntry = [currentData valueForKeyPath:@"cellularEntry"];
            if (_wifiEntry && [[_wifiEntry valueForKeyPath:@"isEnabled"] boolValue]) {
//                If wifiEntry is enabled, is WiFi.
                network = @"WIFI";
            } else if (_cellularEntry && [[_cellularEntry valueForKeyPath:@"isEnabled"] boolValue]) {
                NSNumber *type = [_cellularEntry valueForKeyPath:@"type"];
                if (type) {
                    switch (type.integerValue) {
                        case 0:
//                            无sim卡
                            network = @"NONE";
                            break;
                        case 1:
                            network = @"1G";
                            break;
                        case 4:
                            network = @"3G";
                            break;
                        case 5:
                            network = @"4G";
                            break;
                        default:
//                            默认WWAN类型
                            network = @"WWAN";
                            break;
                            }
                        }
                    }
                }
    }else {
        statusBar = [app valueForKeyPath:@"statusBar"];
        
        if ([[[self alloc]init]isLiuHaiScreen]) {
//            刘海屏
                id statusBarView = [statusBar valueForKeyPath:@"statusBar"];
                UIView *foregroundView = [statusBarView valueForKeyPath:@"foregroundView"];
                NSArray *subviews = [[foregroundView subviews][2] subviews];
                
                if (subviews.count == 0) {
//                    iOS 12
                    id currentData = [statusBarView valueForKeyPath:@"currentData"];
                    id wifiEntry = [currentData valueForKey:@"wifiEntry"];
                    if ([[wifiEntry valueForKey:@"_enabled"] boolValue]) {
                        network = @"WIFI";
                    }else {
//                    卡1:
                        id cellularEntry = [currentData valueForKey:@"cellularEntry"];
//                    卡2:
                        id secondaryCellularEntry = [currentData valueForKey:@"secondaryCellularEntry"];

                        if (([[cellularEntry valueForKey:@"_enabled"] boolValue]|[[secondaryCellularEntry valueForKey:@"_enabled"] boolValue]) == NO) {
//                            无卡情况
                            network = @"NONE";
                        }else {
//                            判断卡1还是卡2
                            BOOL isCardOne = [[cellularEntry valueForKey:@"_enabled"] boolValue];
                            int networkType = isCardOne ? [[cellularEntry valueForKey:@"type"] intValue] : [[secondaryCellularEntry valueForKey:@"type"] intValue];
                            switch (networkType) {
                                    case 0://无服务
                                    network = [NSString stringWithFormat:@"%@-%@", isCardOne ? @"Card 1" : @"Card 2", @"NONE"];
                                    break;
                                    case 3:
                                    network = [NSString stringWithFormat:@"%@-%@", isCardOne ? @"Card 1" : @"Card 2", @"2G/E"];
                                    break;
                                    case 4:
                                    network = [NSString stringWithFormat:@"%@-%@", isCardOne ? @"Card 1" : @"Card 2", @"3G"];
                                    break;
                                    case 5:
                                    network = [NSString stringWithFormat:@"%@-%@", isCardOne ? @"Card 1" : @"Card 2", @"4G"];
                                    break;
                                default:
                                    break;
                            }
                            
                        }
                    }
                
                }else {
                    
                    for (id subview in subviews) {
                        if ([subview isKindOfClass:NSClassFromString(@"_UIStatusBarWifiSignalView")]) {
                            network = @"WIFI";
                        }else if ([subview isKindOfClass:NSClassFromString(@"_UIStatusBarStringView")]) {
                            network = [subview valueForKeyPath:@"originalText"];
                        }
                    }
                }
                
            }else {
//                非刘海屏
                UIView *foregroundView = [statusBar valueForKeyPath:@"foregroundView"];
                NSArray *subviews = [foregroundView subviews];
                
                for (id subview in subviews) {
                    if ([subview isKindOfClass:NSClassFromString(@"UIStatusBarDataNetworkItemView")]) {
                        int networkType = [[subview valueForKeyPath:@"dataNetworkType"] intValue];
                        switch (networkType) {
                            case 0:
                                network = @"NONE";
                                break;
                            case 1:
                                network = @"2G";
                                break;
                            case 2:
                                network = @"3G";
                                break;
                            case 3:
                                network = @"4G";
                                break;
                            case 5:
                                network = @"WIFI";
                                break;
                            default:
                                break;
                        }
                    }
                }
            }
    }

    if ([network isEqualToString:@""]) {
        network = @"NO DISPLAY";
    }
    return network;
}

获取当前的Wifi信息

获取当前的Wifi信息需要借助系统的SystemConfiguration这个库。
先导入头文件，如下：

#import <SystemConfiguration/CaptiveNetwork.h>

实现方法如下：

#pragma mark 获取Wifi信息
+ (id)fetchSSIDInfo
{
    NSArray *ifs = (__bridge_transfer id)CNCopySupportedInterfaces();
    id info = nil;
    for (NSString *ifnam in ifs) {
        info = (__bridge_transfer id)CNCopyCurrentNetworkInfo((__bridge CFStringRef)ifnam);
        
        if (info && [info count]) {
            break;
        }
    }
    return info;
}
#pragma mark 获取WIFI名字
+ (NSString *)getWifiSSID
{
    return (NSString *)[self fetchSSIDInfo][@"SSID"];
}
#pragma mark 获取WIFI的MAC地址
+ (NSString *)getWifiBSSID
{
    return (NSString *)[self fetchSSIDInfo][@"BSSID"];
}

获取当前的Wifi信号强度

获取信号强度与获取网络状态有点类似，通过遍历状态栏，从而获取WIFI图标的信号强度。在获取前需注意当前状态是否为WIFI。如下：

+ (int)getWifiSignalStrength{
    
    int signalStrength = 0;
//    判断类型是否为WIFI
    if ([[self getNetworkType]isEqualToString:@"WIFI"]) {
//        判断是否为iOS 13
        if (@available(iOS 13.0, *)) {
            UIStatusBarManager *statusBarManager = [UIApplication sharedApplication].keyWindow.windowScene.statusBarManager;
             
            id statusBar = nil;
#pragma clang diagnostic push
#pragma clang diagnostic ignored "-Wundeclared-selector"
            if ([statusBarManager respondsToSelector:@selector(createLocalStatusBar)]) {
                UIView *localStatusBar = [statusBarManager performSelector:@selector(createLocalStatusBar)];
                if ([localStatusBar respondsToSelector:@selector(statusBar)]) {
                    statusBar = [localStatusBar performSelector:@selector(statusBar)];
                }
            }
#pragma clang diagnostic pop
            if (statusBar) {
                id currentData = [[statusBar valueForKeyPath:@"_statusBar"] valueForKeyPath:@"currentData"];
                id wifiEntry = [currentData valueForKeyPath:@"wifiEntry"];
                if ([wifiEntry isKindOfClass:NSClassFromString(@"_UIStatusBarDataIntegerEntry")]) {
//                    层级：_UIStatusBarDataNetworkEntry、_UIStatusBarDataIntegerEntry、_UIStatusBarDataEntry
                    
                    signalStrength = [[wifiEntry valueForKey:@"displayValue"] intValue];
                }
            }
        }else {
            UIApplication *app = [UIApplication sharedApplication];
            id statusBar = [app valueForKey:@"statusBar"];
            if ([[[self alloc]init]isLiuHaiScreen]) {
//                刘海屏
                id statusBarView = [statusBar valueForKeyPath:@"statusBar"];
                UIView *foregroundView = [statusBarView valueForKeyPath:@"foregroundView"];
                NSArray *subviews = [[foregroundView subviews][2] subviews];
                       
                if (subviews.count == 0) {
//                    iOS 12
                    id currentData = [statusBarView valueForKeyPath:@"currentData"];
                    id wifiEntry = [currentData valueForKey:@"wifiEntry"];
                    signalStrength = [[wifiEntry valueForKey:@"displayValue"] intValue];
//                    dBm
//                    int rawValue = [[wifiEntry valueForKey:@"rawValue"] intValue];
                }else {
                    for (id subview in subviews) {
                        if ([subview isKindOfClass:NSClassFromString(@"_UIStatusBarWifiSignalView")]) {
                            signalStrength = [[subview valueForKey:@"_numberOfActiveBars"] intValue];
                        }
                    }
                }
            }else {
//                非刘海屏
                UIView *foregroundView = [statusBar valueForKey:@"foregroundView"];
                     
                NSArray *subviews = [foregroundView subviews];
                NSString *dataNetworkItemView = nil;
                       
                for (id subview in subviews) {
                    if([subview isKindOfClass:[NSClassFromString(@"UIStatusBarDataNetworkItemView") class]]) {
                        dataNetworkItemView = subview;
                        break;
                    }
                }
                       
                signalStrength = [[dataNetworkItemView valueForKey:@"_wifiStrengthBars"] intValue];
                        
                return signalStrength;
            }
        }
    }
    return signalStrength;
}

2.Reachability的使用

下载开源类Reachability，然后根据文档使用即可（该类把移动网络统称为WWAN）：+ (NSString *)getNetworkTypeByReachability

{
    NSString *network = @"";
    switch ([[Reachability reachabilityForInternetConnection]currentReachabilityStatus]) {
        case NotReachable:
            network = @"NONE";
            break;
        case ReachableViaWiFi:
            network = @"WIFI";
            break;
        case ReachableViaWWAN:
            network = @"WWAN";
            break;
        default:
            break;
    }
    if ([network isEqualToString:@""]) {
        network = @"NO DISPLAY";
    }
    return network;
}

上次发布了这篇文章之后，有人问我，怎么才能获取设备的IP地址呢？在这里，小编附上获取iP地址的方法。
先导入头文件，如下：

#import <ifaddrs.h>
#import <arpa/inet.h>

实现方法，如下：

#pragma mark 获取设备IP地址
+ (NSString *)getIPAddress
{
    NSString *address = @"error";
    struct ifaddrs *interfaces = NULL;
    struct ifaddrs *temp_addr = NULL;
    int success = 0;
    // 检索当前接口,在成功时,返回0
    success = getifaddrs(&interfaces);
    if (success == 0) {
        // 循环链表的接口
        temp_addr = interfaces;
        while(temp_addr != NULL) {
//                开热点时本机的IP地址
                if ([[NSString stringWithUTF8String:temp_addr->ifa_name] isEqualToString:@"bridge100"]
                    ) {
                    address = [NSString stringWithUTF8String:inet_ntoa(((struct sockaddr_in *)temp_addr->ifa_addr)->sin_addr)];
                }
            if(temp_addr->ifa_addr->sa_family == AF_INET) {
                // 检查接口是否en0 wifi连接在iPhone上
                if([[NSString stringWithUTF8String:temp_addr->ifa_name] isEqualToString:@"en0"]) {
                    // 得到NSString从C字符串
                    address = [NSString stringWithUTF8String:inet_ntoa(((struct sockaddr_in *)temp_addr->ifa_addr)->sin_addr)];
                }
            }
            temp_addr = temp_addr->ifa_next;
        }
    }
    // 释放内存
    freeifaddrs(interfaces);
    return address;
}

iOS 开发小记

8.10日遇见问题新接手的苹果账号无法真机运行，查询一番以为是证书的问题。登录到苹果的官网发现手机有个7天无效的问题。

最终解决的方式是换了个手机 添加到真机运行中就可以了

但是无法运行的手机，估计是需要等到七天之后查看结果。七天之后应该是有所变化

产生这个问题的原因：有大佬解答是因为 苹果账号被封过。导致手机的UUID被标记。换到其他的苹果账号会有这种情况的发生

（我遇到过的是被封过开发者账号的，一个开发者账号被封，里面的测试机也会被苹果标记，再换其他的开发者账号，就可以关联到一起了）

前言

    这一年是2040年，我们最新的 MacBook M30X 处理器可以感知到瞬间编译大型 Swift 项目，听起来很神奇，对吧？除此之外，编译代码库只是我们迭代周期的一部分。包括：
    1、重新启动它（或将其部署到设备）
    2、导航到您在应用程序中的先前位置
    3、重新生成您需要的数据。
    如果您只需要做一次的话，听起来还不错。但是如果您和我一样，在特别的一天中，对代码库进行 200 - 500 次迭代，该怎么办呢？它增加了。
    有一种更好的方法，被其他平台所接受，并且可以在 Swift/iOS 生态系统中实现。我已经用了十多年了。
    从今天开始，您想每周节省多达 10 小时的工作时间吗？

热重载

    热重载是关于摆脱编译整个应用程序并尽可能避免部署/重新启动周期，同时允许您编辑正在运行的应用程序代码并且能立即看到更改。
    这种流程改进可以每天为您节省数小时的开发时间。我跟踪我的工作一个多月，对我来说，每天节省了 1-2 小时。
    坦白地说，如果每周节省10个小时的开发时间都不能说服您去尝试，那么我认为任何方法都不能说服你。

其他平台在做什么？

    如果您只使用 Apple 平台，您会惊讶地发现有好多平台几十年前已经采用了热重载。无论您是编写 Node 还是任何其他 JS 框架，都有一个使用热重载的设置。Go 也提供了热重载（本博客使用了该特性）
    另一个例子是谷歌的 Flutter 架构，从一开始就设计用于热重载。如果您与从事 Flutter 工作的工程师交谈，你会发现他们最喜欢 Flutter 开发者体验的一点就是能够实时编写他们的应用程序。当我为《纽约时报》写了一个拼字游戏时，我很喜欢它。
    微软最近推出了 Visual Studio 2022，并为 .NET 和 标准 C++ 应用程序提供热重载，在过去的十年中，微软在开发工具和经验方面一直在大杀四方，所以这并不令人惊讶。

苹果生态系统怎么样？

    早在 2014 年推出时，很多人都对 Swift Playgrounds 感到敬畏，因为它们允许我们快速迭代并查看代码的结果，但它们并不能很好地工作，因为它存在崩溃、挂起等问题。不能支持整个iPad环境。
    在它们发布后不久，我启动了一个名为 Objective-C Playgrounds 的开源项目，它比官方 Playgrounds 运行得更快、更可靠。我的想法是设计一个架构/工作流程，利用我已经使用了几年的 DyCI 代码注入工具，该工具已经由 Paul 制作。
    自从 Swift Playgrounds 存在以来，已经过去了八年，而且它们变得更好了，但它们可靠吗？人们是否在使用它们来推动开发？

    SwiftUI 出现了，它是一项了不起的技术（尽管仍然存在错误），它引入了与 Playgrounds 非常相似的 Swift Previews 的想法，它们有什么好处吗？
    类似的故事，当它工作的时候是很好的，但是在更大的项目中，它的工作是不可靠的，而且往往中断的次数比它们工作的次数多。如果你有任何错误，他们不会为你提供调试代码的能力，因此，采用的情况有限。

我们需要等待 Apple 吗？

    如果你关注我一段时间，你就已经知道答案了，绝对不要。毕竟，我的职业生涯是构建普通 Apple 解决方案无法解决的问题：从像 Sourcery 这样的语言扩展、像 Sourcery Pro 这样的 Xcode 改进，再到 LifetimeTracker 以及许多其他开源工具。
    我们可以利用我最初在 2014 Playgrounds 中使用的相同方法。我已经使用它十多年了，并且在数十个 Swift 项目中使用它并取得了巨大的成功！
    许多年前，我从使用 DyCI 切换到 InjectionForXcode，通过利用 LLVM 互操作而不是任何 swizzling ，它的效果更好。它是一个完全免费的开源工具，您可以在菜单栏中运行，它是由多产的工程师 John Holdsworth 创建的。你应该看看他的书 Swift Secrets。
    我意识到 Playgrounds 的方法可能过于笨重，所以今天，我开源了。一个非常专注的名为 Inject 的微型库，与 InjectionForXcode 搭配使用时，将使您的 Apple 开发更加高效和愉快！
    但不要只相信我的话。看看 Alexandra 和 Nate 的反馈，在我将这个工作流程引入 The Browser Company 设置之前，他们已经非常精通了，这使得它更加令人印象深刻。

Inject

    这个小型库是完全通用的，无论您使用 UIKit、 AppKit 还是 SwiftUI，您都可以使用它。
    您无需为生产应用程序添加条件或删除 Inject 代码。它变成了无操作内联代码，将在非调试版本中被编译过程剥离。您可以在每个视图中集成一次，并持续使用数年。
    请参考 GitHub repo中关于配置项目的说明。现在让我们来看看您有哪些工作流程选项。

工作流

    SwiftUI
        只需要两行字就可以使任何 SwiftUI 启用实时编程，而当您这样做时，您将拥有比使用 Swift Previews 更快的工作流程，同时能够使用实际的生产数据。
        这是我的 Sourcery Pro 应用程序的示例，其中加载了我所有的实际数据和逻辑，使我能够即时快速迭代整个应用程序设计，而无需任何重新启动、重新加载或类似的事情。
        看看这个开发工作流程有多快吧，告诉我你宁愿在我每次接触代码时等待Xcode的重新构建和重新部署。

    UIKit / AppKit
        我们需要一种方法来清理标准命令式UI框架的代码注入阶段之间的状态。
        我创建了 Host 的概念并且在这种情况下工作的很好。有两个：

        - Inject.ViewHost
        - Inject.ViewControllerHost

        我们如何集成它？我们把我们想迭代的类包装在父级，因此我们不修改要注入的类型，而是改变父级的调用站点。
        例如，如果你有一个 SplitViewController ，它创建了 PaneA 和 PaneB ，而你想在PaneA 中迭代布局/逻辑代码，你就修改 SplitViewController 中的调用站点。

        paneA = Inject.ViewHost(
            PaneAView(whatever: arguments, you: want)
        )

        这就是你需要做的所有改变。注入现在允许你更改 PaneAView 中的任何东西，除了它的初始化API。这些变化将立即反映在你的应用程序中。

        一个更具体的例子？
        1、我下载了 Covid19 App
        2、添加 -Xlinker -interposable 到 Other Linker Flags
        3、交换了一行 Covid19TabController.swift:L63 行

        从这句：

        let vc = TwitterViewController(title: Tab.twitter.name, usernames: Twitter.content)

        替换为：

        let vc = Inject.ViewControllerHost(TwitterViewController(title: Tab.twitter.name, usernames: Twitter.content))

        现在，我可以在不重新启动应用程序的情况下迭代控制器设计。

这是如何运作的呢?

逻辑注入如何呢？

它有多可靠？

主要NSObject中的alloc是与自定义类的alloc的源码流程的区别，以及为什么NSObject中的alloc不走源码工程。

在上一篇文章中分析了alloc的源码，这篇文章是作为对上一篇文章的补充，去探索为什么NSObject的alloc方法不走源码工程。

NSObject的alloc无法进入源码的问题

首先在objc4-781可编译源码中的main函数中增加一个NSObject定义的对象，NSObject 和 LGPersong同时加上断点

在alloc的源码实现中加一个断点，同时需要暂时关闭断点

运行target，断点断在NSObject部分，打开alloc源码的断点，然后继续执行，会出现以下这种现象

探索Why

【第一步】探索[NSObject alloc]走的是哪步源码

接下来，我们就来探索为什么NSObject的alloc会出现这种情况，首先，

• 打开Debug --> Debug Workflow --> 勾选 Always Show Disassemly，开启汇编调试

  关闭源码的断点，只留main中的断点，重新运行程序，然后通过下图的汇编可以发现NSObject并没有走 alloc源码，而是走的objc_alloc

然后关闭汇编调试，在全局搜索 objc_alloc，在objc_alloc中加一个断点，先暂时关闭，

重新运行进行调试，断住，然后打开objc_alloc的断点，发现会进入objc_alloc的源码实现，此时查看 cls 是 NSObject

【第二步】探索 NSObject 为什么走 objc_alloc？

首先，我们来看看 NSObject 与 LGPerson的区别

• NSObject 是iOS中的基类，所有自定义的类都需要继承自NSObject
• LGPerson 是继承自NSObject类的，重写了NSObject中的alloc方法

然后根据第一步中汇编的显示，可以看出，NSObject 和 LGPerson 都调用了objc_alloc，所以这里就有两个疑问：

• 为什么NSObject 调用alloc方法 会走到 objc_alloc 源码？
• 为什么LGPerson中的alloc 会走两次？即调用了alloc，进入源码，然后还要走到 objc_alloc？

LGPerson中alloc 走两次 的 Why？

首先，需要在源码中调试，在main中LGPerson加断点，断在LGPerson，再在alloc 、 objc_alloc 和 calloc 源码加断点,运行demo，会断在objc_alloc源码中（重新运行前需要暂时关闭源码中的所有断点）

继续运行，发现LGPerson 第一次的alloc会走到 objc_alloc --> callAlloc方法中最下方的objc_msgSend，表示向系统发送消息

• 继续执行代码，发现会走到 alloc --> callAlloc --> _objc_rootAllocWithZOne，也就是iOS-底层原理 02：alloc & init & new 源码分析源码分析中的alloc流程.

  以下是第二次走到calloc方法中的调用堆栈情况

所以由上述调试过程可以得出，LGPerson走两次的原因是首先需要去查找sel，以及对应的imp的关系，当前需要查找的是 alloc的方法编号，但是为什么会找到objc_alloc？这个就需要问系统了，肯定是系统在底层做了一些操作。请接着往下看

NSObject中alloc 走到 objc_alloc 的 why？

这部分需要通过 LLVM源码（即llvm-project） 来分析

准备工作：首先需要一份llvm源码

在llvm源码中搜索objc_alloc

搜索shouldUseRuntimeFunctionForCombinedAllocInit，表示版本控制

搜索tryEmitSpecializedAllocInit，非常著名的特殊消息发送，在这里也没有找到 objc_alloc

继续尝试，开启上帝视角，通过alloc字符串搜索，如果还找不到，还可以通过omf_alloc:找到tryGenerateSpecializedMessageSend，表示尝试生成特殊消息发送

然后在这个case中可以找到调用alloc，转而调用了objc_objc的逻辑，其中的关键代码是EmitObjCAlloc

跳转至EmitObjCAlloc的定义可以看到alloc 的处理是调用了 objc_alloc

由此可以得出 NSObject中的alloc 会走到 objc_alloc，其实这部分是由系统级别的消息处理逻辑，所以NSObject的初始化是由系统完成的，因此也不会走到alloc的源码工程中

总结

总结下NSObject中alloc 和自定义类中alloc的调用流程

NSObject

自定义类

作者：style_月月
链接：https://blog.csdn.net/lin1109221208/article/details/108480971

著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

准备工作

环境版本 & 最新objc源码

• mac OS 10.15
• Xcode 11.4
• objc4-781

依赖文件下载

需要下载以下依赖文件

源码编译

源码编译就是不断的调试修改源码的问题，主要有以下问题

问题一：unable to find sdk 'macosx.internal'

选择 target -> objc -> Build Settings -> Base SDK -> 选择 macOS 【target中的 objc 和 obc-trampolines都需要更改】

问题二：文件找不到的报错问题

【1】‘sys/reason.h’ file not found

在Apple source的 macOS10.15 --> xnu-6153.11.26/bsd/sys/reason.h 路径自行下载

在objc4-781的根目录下新建CJLCommon文件, 同时在CJLCommon文件中创建sys文件

最后将 reason.h文件拷贝到sys文件中

设置文件检索路径：选择 target -> objc -> Build Settings，在工程的 Header Serach Paths 中添加搜索路径 $(SRCROOT)/CJLCommon

【2】‘mach-o/dyld_priv.h’ file not found

• 在CJLCommon文件中 创建 mach-o 文件
• 找到文件：dyld-733.6 -- include -- mach-o -- dyld_priv.h

拷贝到 mach-o文件中

• 拷贝到文件后，还需要修改 dyld_priv.h 文件，即在 dyld_priv.h文件顶部加入一下宏：

【3】‘os/lock_private.h’ file not found 和 ‘os/base_private.h’ file not found

• 在CJLCommon中创建 os文件
• 找到lock_private.h、base_private.h文件：libplatform-220 --> private --> os --> lock_private.h 、base_private.h，并将文件拷贝至 os 文件中

【4】‘pthread/tsd_private.h’ file not found 和 ‘pthread/spinlock_private.h’ file not found

在CJLPerson中创建 pthread 文件
找到tsd_private.h、spinlock_private.h文件，h文件路径为：libpthread-416.11.1 --> private --> tsd_private.h、spinlock_private.h，并拷贝到 pthread文件

【5】‘System/machine/cpu_capabilities.h’ file not found

创建 System -- machine 文件
找到 cpu_capabilities.h文件拷贝到 machine文件，h文件路径为：xnu6153.11.26 --> osfmk --> machine --> cpu_capabilities.h

【6】os/tsd.h’ file not found

找到 tsd.h文件，拷贝到os文件, h文件路径为：xnu6153.11.26 --> libsyscall --> os --> tsd.h

【7】‘System/pthread_machdep.h’ file not found

• 在这个地址下载pthread_machdep.h文件，h文件路径为：Libc-583/pthreads/pthread_machdep.h
• 将其拷贝至system文件中

【8】‘CrashReporterClient.h’ file not found

• 这个文件在改地址搜索 Libc-825.24中找到该文件，路径为Libc-825.24/include/CrashReporterClient.h

导入下载的还是报错，可以通过以下方式解决
- 需要在 Build Settings -> Preprocessor Macros 中加入：LIBC_NO_LIBCRASHREPORTERCLIENT
- 或者下载我给大家的文件CrashReporterClient,这里面我们直接更改了里面的宏信息 #define LIBC_NO_LIBCRASHREPORTERCLIENT

【9】‘objc-shared-cache.h’ file not found

文件路径为：dyld-733.6 --> include --> objc-shared-cache.h

• 将h文件报备制拷贝到CJLCommon

【10】Mismatch in debug-ness macros

注释掉objc-runtime.mm中的#error mismatch in debug-ness macros

【11】’_simple.h’ file not found

文件路径为：libplatform-220 --> private --> _simple.h

• 将文件拷贝至CJLCommon中

• 在CJLCommon中创建kern 文件
• 找到 h文件，路径为xnu-6153.11.26 --> osfmk --> kern -->restartable.h
  

【13】‘Block_private.h’ file not found

找到 h 文件，文件路径为libclosure-74 --> Block_private.h










拷贝至CJLCommon目录

【14】libobjc.order 路径问题

问题描述为：can't open order file: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk/AppleInternal/OrderFiles/libobjc.order

• 选择 target -> objc -> Build Settings

• 在工程的 Order File 中添加搜索路径 $(SRCROOT)/libobjc.order

  
  

  
  

【14】Xcode 脚本编译问题
问题描述为：/xcodebuild:1:1: SDK "macosx.internal" cannot be located.

选择 target -> objc -> Build Phases -> Run Script(markgc)
把脚本文本 macosx.internal 改成 macosx

编译调试

新建一个target ：CJLTest

绑定二进制依赖关系

源码调试

自定义一个CJLPerson类

在main.m中 创建 CJLPerson的对象，进行源码调试

作者：style_月月
链接：https://blog.csdn.net/lin1109221208/article/details/108435967

著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

一、目录  

    1、理解二进制在 Swift 中的演变

    2、命令行工具相关

    3、结论

二、前言

    1、理解二进制在 Swift 中的演变

        为了充分理解 Apple 的 Swift 团队在二进制目标和他们引入的一些新 API 方面采取的一些步骤，我们需要理解它们从何而来。在后续的部分中，我们将调研 Apple 架构的演变，以及为什么二进制目标的 API 在过去几年中逐渐形成的，特别是自 Apple 发布了自己的硅芯片之后。

        胖二进制和 Frameworks 框架

        如果你曾必须处理二进制依赖，或者你曾创建一个属于你自己的可执行文件，你将会对 胖二进制 这个术语感到熟悉。这些被扩展（或增大）的可执行文件，是包含了为多个不同架构原生构建的切片。这允许库的所有者分发一个运行在所有预期的目标架构上的单独的二进制。
        当源码不能被暴露或当处理非常庞大的代码仓库时，预编译库成为可执行文件非常有意义，因为预编译源码以及以二进制文件分发他们，将节省构建程序在他们的应用上的构建时间。
        Pods 是一个非常好的例子，当开发者发现他们自己没必要构建那些非常少改动的依赖。这是一个很共通的问题，它激发了诸如 cocoapods-binary之类的项目，该项目预编译了 pod 依赖项以减少客户端的构建时间。

        Frameworks 框架

        嵌入静态二进制文件可能对应用程序来说已经足够了，但如果需要某些资源（如 assets 或头文件），则需要将这些资源与包含所有切片的 胖二进制文件 捆绑在一起，形成所谓的 frameworks 文件。
这就是诸如 Google Cast[5] 之类的预编译库在过渡到使用 xcframework 进行分发之前所做的事情 —— 下一节将详细介绍这种过渡的原因。
        到目前为止，一切都很好。如果我们要为分发预编译一个库，那么胖二进制文件听起来很理想，对吧？并且，如果我们需要捆绑一些其他资源，我们可以只使用一个 frameworks。一个二进制来统治他们所有！

        XCFrameworks 框架

        好吧，不完全是。胖二进制文件有一个大问题，那就是你不能有两个架构相同但命令/指令不同的切片。这曾经很好，因为设备和模拟器的架构总是不同的，但是随着 Apple Silicon 计算机 (M1) 的推出，模拟器和设备共享相同的架构 (arm64)，但具有不同的加载器命令。这与面向未来的二进制目标相结合，正是 Apple 引入 XCFrameworks 的原因。
        XCFrameworks现在允许将多个二进制文件捆绑在一起，解决了 M1 Mac 引入的设备和模拟器冲突架构问题，因为我们现在可以为每个用例提供包含相关切片的二进制文件。事实上，如果我们需要，我们可以走得更远，例如，在同一个 xcframework 中捆绑一个包含 iOS 目标的 UIKit 接口的二进制文件和一个包含 macOS 的 AppKit 接口的二进制文件，然后让 Xcode 基于期望的目标架构决定使用哪一个。
        在 Swift 包中，那先能够以 binaryTarget 被包含进项目的，能够在包中被引入任意其他目标。这相同的操作同样适用于 frameworks。

     2、命令行工具相关

        由于 Swift 5.6 版本中引入了用于 Swift 包管理器的 可扩展构建工具[9] ，因此可以在构建过程中的不同时间执行命令。

        这是 iOS 社区长期以来一直强烈要求的事情，例如格式化源代码、代码生成甚至收集公制代码库的指标。Swift 5.6 中所有这些所谓的 插件最终都需要调用可执行文件来执行特定任务。这是二进制文件再次在 Swift 包中参与的地方。
        在大多数情况下，对于我们 iOS 开发人员来说，这些工具将来自同时支持 macOS 的不同架构切片 —— Apple Silicon 的 arm64 架构和 Intel Mac 的 x86_64 架构。开发者工具如， SwiftLint或 SwiftGen 正是这种案例。在这种情况下，可以使用包含可执行文件（本地或远程）的 .zip 文件的路径创建新的二进制目标。

        Artifact Bundles

        到目前为止，命令行工具所采用的方法仅适用于 macOS 架构。但我们不能忘记，Linux 机器也支持 Swift 包。这意味着如果要同时支持 M1 macs (arm64) 和 Linux arm64 机器，上面的胖二进制方法将不起作用 —— 请记住，二进制不能包含具有相同架构的多个切片。在这个阶段可能有人会想，我们可以不只使用 xcframeworks 吗？不，因为它们在 Linux 操作系统上不受支持！
        Apple 已经考虑到这一点，除了引入 可扩展构建工具[13] 之外，Artifact Bundles和对二进制目标的其他改进也作为 Swift 5.6 的一部分发布。
        工件包(Artifact Bundles) 是包含 工件 的目录。这些工件需要包含支持架构的所有不同二进制文件。二进制文件和支持的架构的路径是使用清单文件 (info.json) 指定的，该文件位于 Artifact Bundle 目录的根目录中。你可以将此清单文件视为一个地图或指南，以帮助 Swift 确定哪些可执行文件可用于哪种架构以及可以在哪里找到它们。

        以 SwiftLint 为例

        SwiftLint 在整个社区中被广泛用作 Swift 代码的静态代码分析工具。由于很多人都非常渴望让这个插件在他们的 SwiftPM 项目中运行，我认为这将是一个很好的例子来展示我们如何将分发的可执行文件从他们的发布页面变成一个与 macOS 架构和 Linux arm64 兼容的工件包。
        让我们从下载两个可执行文件（macOS 和 Linux）开始。
        至此，bundle的结构就可以创建好了。为此，创建一个名为 swiftlint.artifactbundle 的目录并在其根目录添加一个空的 info.json：

        mkdir swiftlint.artifactbundle

        touch swiftlint.artifactbundle/info.json

        现在可以使用 schemaVersion 填充清单文件，这可能会在未来版本的工件包和具有两个变体的工件中发生变化，这将很快定义：

        {

            "schemaVersion": "1.0",
            "artifacts": {
                "swiftlint": {
                    "version": "0.47.0", # The version of SwiftLint being used
                    "type": "executable",
                    "variants": [
                    ]
                },
            }
        }

        需要做的最后一件事是将二进制文件添加到包中，然后将它们作为变体添加到 info.json 文件中。让我们首先创建目录并将二进制文件放入其中（macOS 的一个在 swiftlint-macos/swiftlint，Linux 的一个在 swiftlint-linux/swiftlint）。
        添加这些之后，可以在清单文件中变量：

        {
            "schemaVersion": "1.0",
            "artifacts": {
                "swiftlint": {
                    "version": "0.47.0", # The version of SwiftLint being used
                    "type": "executable",
                    "variants": [
                    {
                        "path": "swiftlint-macos/swiftlint",
                        "supportedTriples": ["x86_64-apple-macosx", "arm64-apple-macosx"]
                    },
                    {
                        "path": "swiftlint-linux/swiftlint",
                        "supportedTriples": ["x86_64-unknown-linux-gnu"]
                    },
                    ]
                },
            }
        }

        为此，需要为每个变量指定二进制文件的相对路径（从工件包目录的根目录）和支持的三元组。如果您不熟悉 目标三元组，它们是一种选择构建二进制文件的架构的方法。请注意，这不是 主机（构建可执行文件的机器）的体系结构，而是 目标 机器（应该运行所述可执行文件的机器）。

        这些三元组具有以下格式： ---- 并非所有字段都是必需的，如果其中一个字段未知并且要使用默认值，则可以省略或替换为 unknown 关键字。
        可执行文件的架构切片可以通过运行 file 找到，这将打印捆绑的任何切片的供应商、系统和架构。在这种情况下，为这两个命令运行它会显示：

        swiftlint-macos/swiftlint

        swiftlint: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit executable x86_64] [arm64]

        swiftlint (for architecture x86_64): Mach-O 64-bit executable x86_64

        swiftlint (for architecture arm64): Mach-O 64-bit executable arm64

        swiftlint-linux/swiftlint

        -> file swiftlint
        swiftlint: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, with debug_info, not stripped

       这带来了上面显示的 macOS 支持的两个三元组（x86_64-apple-macosx、arm64-apple-macosx）和 Linux 支持的一个三元组（x86_64-unknown-linux-gnu）。

        与 XCFrameworks 类似，工件包也可以通过使用 binaryTarget 包含在 Swift 包中。

    3、结论

        简而言之，我们可以总结 2022 年如何在 Swift 包中使用二进制文件的最佳实践，如下所示：

        1、如果你需要为你的 iOS/macOS 项目添加预编译库或可执行文件，您应该使用 XCFramework，并为每个用例（iOS 设备、macOS 设备和 iOS 模拟器）包含单独的二进制文件。
        2、如果你需要创建一个插件并运行一个可执行文件，你应该将其嵌入为一个工件包，其中包含适用于不同支持架构的二进制文件。

接口API

下面我们先看一下接口的API

/**
 This category adds methods to the UIKit framework's `UIProgressView` class. The methods in this category provide support for binding the progress to the upload and download progress of a session task.
 */
@interface UIProgressView (AFNetworking)

///------------------------------------
/// @name Setting Session Task Progress
///------------------------------------

/**
 Binds the progress to the upload progress of the specified session task.

 @param task The session task.
 @param animated `YES` if the change should be animated, `NO` if the change should happen immediately.
 */
- (void)setProgressWithUploadProgressOfTask:(NSURLSessionUploadTask *)task
                                   animated:(BOOL)animated;

/**
 Binds the progress to the download progress of the specified session task.

 @param task The session task.
 @param animated `YES` if the change should be animated, `NO` if the change should happen immediately.
 */
- (void)setProgressWithDownloadProgressOfTask:(NSURLSessionDownloadTask *)task
                                     animated:(BOOL)animated;

@end

该类为UIKit框架的UIProgressView类添加方法。 此类别中的方法为将进度绑定到会话任务的上载和下载进度提供了支持。

该接口比较少，其实就是一个上传任务和一个下载任务分别和进度的绑定，可动画。

这里大家还要注意一个关于类的继承的细节。

// 上传
@interface NSURLSessionUploadTask : NSURLSessionDataTask
@interface NSURLSessionDataTask : NSURLSessionTask

// 下载
@interface NSURLSessionDownloadTask : NSURLSessionTask

给大家贴出来就是想让大家注意下这个结构。

runtime获取是否可动画

这里还是用runtime分别绑定下载和上传是否可动画。

- (BOOL)af_uploadProgressAnimated {
    return [(NSNumber *)objc_getAssociatedObject(self, @selector(af_uploadProgressAnimated)) boolValue];
}

- (void)af_setUploadProgressAnimated:(BOOL)animated {
    objc_setAssociatedObject(self, @selector(af_uploadProgressAnimated), @(animated), OBJC_ASSOCIATION_RETAIN_NONATOMIC);
}

- (BOOL)af_downloadProgressAnimated {
    return [(NSNumber *)objc_getAssociatedObject(self, @selector(af_downloadProgressAnimated)) boolValue];
}

- (void)af_setDownloadProgressAnimated:(BOOL)animated {
    objc_setAssociatedObject(self, @selector(af_downloadProgressAnimated), @(animated), OBJC_ASSOCIATION_RETAIN_NONATOMIC);
}

这个还算是很好理解的，有了前面的基础，这里就不多说了。

接口的实现

下面我们就看一下接口的实现。

1. 上传任务

static void * AFTaskCountOfBytesSentContext = &AFTaskCountOfBytesSentContext;
static void * AFTaskCountOfBytesReceivedContext = &AFTaskCountOfBytesReceivedContext;

- (void)setProgressWithUploadProgressOfTask:(NSURLSessionUploadTask *)task
                                   animated:(BOOL)animated
{
    if (task.state == NSURLSessionTaskStateCompleted) {
        return;
    }
    
    [task addObserver:self forKeyPath:@"state" options:(NSKeyValueObservingOptions)0 context:AFTaskCountOfBytesSentContext];
    [task addObserver:self forKeyPath:@"countOfBytesSent" options:(NSKeyValueObservingOptions)0 context:AFTaskCountOfBytesSentContext];

    [self af_setUploadProgressAnimated:animated];
}

这里逻辑很清晰，简单的说一下，如果任务是完成状态，那么就直接return，然后给task添加KVO观察，观察属性是state和countOfBytesSent，最后就是设置是否可动画的状态。

2. 下载任务

- (void)setProgressWithDownloadProgressOfTask:(NSURLSessionDownloadTask *)task
                                     animated:(BOOL)animated
{
    if (task.state == NSURLSessionTaskStateCompleted) {
        return;
    }
    
    [task addObserver:self forKeyPath:@"state" options:(NSKeyValueObservingOptions)0 context:AFTaskCountOfBytesReceivedContext];
    [task addObserver:self forKeyPath:@"countOfBytesReceived" options:(NSKeyValueObservingOptions)0 context:AFTaskCountOfBytesReceivedContext];

    [self af_setDownloadProgressAnimated:animated];
}

这里逻辑很清晰，简单的说一下，如果任务是完成状态，那么就直接return，然后给task添加KVO观察，观察属性是state和countOfBytesReceived，最后就是设置是否可动画的状态。

KVO观察实现

下面看一下KVO观察的实现，这里也是这个类的精髓所在。

- (void)observeValueForKeyPath:(NSString *)keyPath
                      ofObject:(id)object
                        change:(__unused NSDictionary *)change
                       context:(void *)context
{
    if (context == AFTaskCountOfBytesSentContext || context == AFTaskCountOfBytesReceivedContext) {
        if ([keyPath isEqualToString:NSStringFromSelector(@selector(countOfBytesSent))]) {
            if ([object countOfBytesExpectedToSend] > 0) {
                dispatch_async(dispatch_get_main_queue(), ^{
                    [self setProgress:[object countOfBytesSent] / ([object countOfBytesExpectedToSend] * 1.0f) animated:self.af_uploadProgressAnimated];
                });
            }
        }

        if ([keyPath isEqualToString:NSStringFromSelector(@selector(countOfBytesReceived))]) {
            if ([object countOfBytesExpectedToReceive] > 0) {
                dispatch_async(dispatch_get_main_queue(), ^{
                    [self setProgress:[object countOfBytesReceived] / ([object countOfBytesExpectedToReceive] * 1.0f) animated:self.af_downloadProgressAnimated];
                });
            }
        }

        if ([keyPath isEqualToString:NSStringFromSelector(@selector(state))]) {
            if ([(NSURLSessionTask *)object state] == NSURLSessionTaskStateCompleted) {
                @try {
                    [object removeObserver:self forKeyPath:NSStringFromSelector(@selector(state))];

                    if (context == AFTaskCountOfBytesSentContext) {
                        [object removeObserver:self forKeyPath:NSStringFromSelector(@selector(countOfBytesSent))];
                    }

                    if (context == AFTaskCountOfBytesReceivedContext) {
                        [object removeObserver:self forKeyPath:NSStringFromSelector(@selector(countOfBytesReceived))];
                    }
                }
                @catch (NSException * __unused exception) {}
            }
        }
    }
}

这里还是很简单的吧。

• 如果keyPath是@"countOfBytesSent"，那么就获取countOfBytesExpectedToSend，计算进度百分比，在主线程调用[self setProgress:[object countOfBytesSent] / ([object countOfBytesExpectedToSend] * 1.0f) animated:self.af_uploadProgressAnimated];得到进度。
• 如果keyPath是@"countOfBytesReceived"，那么就获取countOfBytesExpectedToReceive，计算进度百分比，在主线程调用[self setProgress:[object countOfBytesReceived] / ([object countOfBytesExpectedToReceive] * 1.0f) animated:self. af_downloadProgressAnimated];得到进度。
• 如果keyPath是@"state"并且任务是完成状态NSURLSessionTaskStateCompleted，那么就要移除对这几个keyPath的观察者。

后记

本篇主要分析了UIProgressView+AFNetworking分类，主要实现了上传任务和下载任务与进度之间的绑定。

转载自：https://cloud.tencent.com/developer/article/1872398

回顾

上一篇主要分析了UIProgressView+AFNetworking分类，主要实现了上传任务和下载任务与进度之间的绑定。这一篇主要分析UIRefreshControl+AFNetworking这个分类。

接口API

下面我们先看一下接口的API

/**
 This category adds methods to the UIKit framework's `UIProgressView` class. The methods in this category provide support for binding the progress to the upload and download progress of a session task.
 */
@interface UIProgressView (AFNetworking)

///------------------------------------
/// @name Setting Session Task Progress
///------------------------------------

/**
 Binds the progress to the upload progress of the specified session task.

 @param task The session task.
 @param animated `YES` if the change should be animated, `NO` if the change should happen immediately.
 */
- (void)setProgressWithUploadProgressOfTask:(NSURLSessionUploadTask *)task
                                   animated:(BOOL)animated;

/**
 Binds the progress to the download progress of the specified session task.

 @param task The session task.
 @param animated `YES` if the change should be animated, `NO` if the change should happen immediately.
 */
- (void)setProgressWithDownloadProgressOfTask:(NSURLSessionDownloadTask *)task
                                     animated:(BOOL)animated;

@end

该类为UIKit框架的UIProgressView类添加方法。 此类别中的方法为将进度绑定到会话任务的上载和下载进度提供了支持。

该接口比较少，其实就是一个上传任务和一个下载任务分别和进度的绑定，可动画。

这里大家还要注意一个关于类的继承的细节。

// 上传
@interface NSURLSessionUploadTask : NSURLSessionDataTask
@interface NSURLSessionDataTask : NSURLSessionTask

// 下载
@interface NSURLSessionDownloadTask : NSURLSessionTask

给大家贴出来就是想让大家注意下这个结构。

---

runtime获取是否可动画

这里还是用runtime分别绑定下载和上传是否可动画。

- (BOOL)af_uploadProgressAnimated {
    return [(NSNumber *)objc_getAssociatedObject(self, @selector(af_uploadProgressAnimated)) boolValue];
}

- (void)af_setUploadProgressAnimated:(BOOL)animated {
    objc_setAssociatedObject(self, @selector(af_uploadProgressAnimated), @(animated), OBJC_ASSOCIATION_RETAIN_NONATOMIC);
}

- (BOOL)af_downloadProgressAnimated {
    return [(NSNumber *)objc_getAssociatedObject(self, @selector(af_downloadProgressAnimated)) boolValue];
}

- (void)af_setDownloadProgressAnimated:(BOOL)animated {
    objc_setAssociatedObject(self, @selector(af_downloadProgressAnimated), @(animated), OBJC_ASSOCIATION_RETAIN_NONATOMIC);
}

这个还算是很好理解的，有了前面的基础，这里就不多说了。

---

接口的实现

下面我们就看一下接口的实现。

1. 上传任务

static void * AFTaskCountOfBytesSentContext = &AFTaskCountOfBytesSentContext;
static void * AFTaskCountOfBytesReceivedContext = &AFTaskCountOfBytesReceivedContext;

- (void)setProgressWithUploadProgressOfTask:(NSURLSessionUploadTask *)task
                                   animated:(BOOL)animated
{
    if (task.state == NSURLSessionTaskStateCompleted) {
        return;
    }
    
    [task addObserver:self forKeyPath:@"state" options:(NSKeyValueObservingOptions)0 context:AFTaskCountOfBytesSentContext];
    [task addObserver:self forKeyPath:@"countOfBytesSent" options:(NSKeyValueObservingOptions)0 context:AFTaskCountOfBytesSentContext];

    [self af_setUploadProgressAnimated:animated];
}

这里逻辑很清晰，简单的说一下，如果任务是完成状态，那么就直接return，然后给task添加KVO观察，观察属性是state和countOfBytesSent，最后就是设置是否可动画的状态。

2. 下载任务

- (void)setProgressWithDownloadProgressOfTask:(NSURLSessionDownloadTask *)task
                                     animated:(BOOL)animated
{
    if (task.state == NSURLSessionTaskStateCompleted) {
        return;
    }
    
    [task addObserver:self forKeyPath:@"state" options:(NSKeyValueObservingOptions)0 context:AFTaskCountOfBytesReceivedContext];
    [task addObserver:self forKeyPath:@"countOfBytesReceived" options:(NSKeyValueObservingOptions)0 context:AFTaskCountOfBytesReceivedContext];

    [self af_setDownloadProgressAnimated:animated];
}

这里逻辑很清晰，简单的说一下，如果任务是完成状态，那么就直接return，然后给task添加KVO观察，观察属性是state和countOfBytesReceived，最后就是设置是否可动画的状态。

KVO观察实现

下面看一下KVO观察的实现，这里也是这个类的精髓所在。

- (void)observeValueForKeyPath:(NSString *)keyPath
                      ofObject:(id)object
                        change:(__unused NSDictionary *)change
                       context:(void *)context
{
    if (context == AFTaskCountOfBytesSentContext || context == AFTaskCountOfBytesReceivedContext) {
        if ([keyPath isEqualToString:NSStringFromSelector(@selector(countOfBytesSent))]) {
            if ([object countOfBytesExpectedToSend] > 0) {
                dispatch_async(dispatch_get_main_queue(), ^{
                    [self setProgress:[object countOfBytesSent] / ([object countOfBytesExpectedToSend] * 1.0f) animated:self.af_uploadProgressAnimated];
                });
            }
        }

        if ([keyPath isEqualToString:NSStringFromSelector(@selector(countOfBytesReceived))]) {
            if ([object countOfBytesExpectedToReceive] > 0) {
                dispatch_async(dispatch_get_main_queue(), ^{
                    [self setProgress:[object countOfBytesReceived] / ([object countOfBytesExpectedToReceive] * 1.0f) animated:self.af_downloadProgressAnimated];
                });
            }
        }

        if ([keyPath isEqualToString:NSStringFromSelector(@selector(state))]) {
            if ([(NSURLSessionTask *)object state] == NSURLSessionTaskStateCompleted) {
                @try {
                    [object removeObserver:self forKeyPath:NSStringFromSelector(@selector(state))];

                    if (context == AFTaskCountOfBytesSentContext) {
                        [object removeObserver:self forKeyPath:NSStringFromSelector(@selector(countOfBytesSent))];
                    }

                    if (context == AFTaskCountOfBytesReceivedContext) {
                        [object removeObserver:self forKeyPath:NSStringFromSelector(@selector(countOfBytesReceived))];
                    }
                }
                @catch (NSException * __unused exception) {}
            }
        }
    }
}

这里还是很简单的吧。

• 如果keyPath是@"countOfBytesSent"，那么就获取countOfBytesExpectedToSend，计算进度百分比，在主线程调用[self setProgress:[object countOfBytesSent] / ([object countOfBytesExpectedToSend] * 1.0f) animated:self.af_uploadProgressAnimated];得到进度。
• 如果keyPath是@"countOfBytesReceived"，那么就获取countOfBytesExpectedToReceive，计算进度百分比，在主线程调用[self setProgress:[object countOfBytesReceived] / ([object countOfBytesExpectedToReceive] * 1.0f) animated:self. af_downloadProgressAnimated];得到进度。
• 如果keyPath是@"state"并且任务是完成状态NSURLSessionTaskStateCompleted，那么就要移除对这几个keyPath的观察者。

后记

本篇主要分析了UIProgressView+AFNetworking分类，主要实现了上传任务和下载任务与进度之间的绑定。

本文转载自腾讯社区:作者conanma  https://cloud.tencent.com/developer/article/1872401

回顾

上一篇主要讲述了UIRefreshControl+AFNetworking这个分类，将刷新状态和任务状态进行了绑定和同步。这一篇主要讲述AFAutoPurgingImageCache有关的缓存。

接口API

按照老惯例，我们还是先看一下接口API文档。这个接口文档包括三个部分，两个协议一个类。

• 协议AFImageCache
• 协议AFImageRequestCache
• 类AFAutoPurgingImageCache

1. AFImageCache

这个协议包括四个方法

/**
 Adds the image to the cache with the given identifier.

 @param image The image to cache.
 @param identifier The unique identifier for the image in the cache.
 */
- (void)addImage:(UIImage *)image withIdentifier:(NSString *)identifier;

/**
 Removes the image from the cache matching the given identifier.

 @param identifier The unique identifier for the image in the cache.

 @return A BOOL indicating whether or not the image was removed from the cache.
 */
- (BOOL)removeImageWithIdentifier:(NSString *)identifier;

/**
 Removes all images from the cache.

 @return A BOOL indicating whether or not all images were removed from the cache.
 */
- (BOOL)removeAllImages;

/**
 Returns the image in the cache associated with the given identifier.

 @param identifier The unique identifier for the image in the cache.

 @return An image for the matching identifier, or nil.
 */
- (nullable UIImage *)imageWithIdentifier:(NSString *)identifier;

该协议定义了包括加入、移除、获取缓存中的图片。

2. AFImageRequestCache

该协议包含下面几个方法，这里注意这个协议继承自协议AFImageCache

@protocol AFImageRequestCache <AFImageCache>

/**
 Asks if the image should be cached using an identifier created from the request and additional identifier.
 
 @param image The image to be cached.
 @param request The unique URL request identifing the image asset.
 @param identifier The additional identifier to apply to the URL request to identify the image.
 
 @return A BOOL indicating whether or not the image should be added to the cache. YES will cache, NO will prevent caching.
 */
- (BOOL)shouldCacheImage:(UIImage *)image forRequest:(NSURLRequest *)request withAdditionalIdentifier:(nullable NSString *)identifier;

/**
 Adds the image to the cache using an identifier created from the request and additional identifier.

 @param image The image to cache.
 @param request The unique URL request identifing the image asset.
 @param identifier The additional identifier to apply to the URL request to identify the image.
 */
- (void)addImage:(UIImage *)image forRequest:(NSURLRequest *)request withAdditionalIdentifier:(nullable NSString *)identifier;

/**
 Removes the image from the cache using an identifier created from the request and additional identifier.

 @param request The unique URL request identifing the image asset.
 @param identifier The additional identifier to apply to the URL request to identify the image.
 
 @return A BOOL indicating whether or not all images were removed from the cache.
 */
- (BOOL)removeImageforRequest:(NSURLRequest *)request withAdditionalIdentifier:(nullable NSString *)identifier;

/**
 Returns the image from the cache associated with an identifier created from the request and additional identifier.

 @param request The unique URL request identifing the image asset.
 @param identifier The additional identifier to apply to the URL request to identify the image.

 @return An image for the matching request and identifier, or nil.
 */
- (nullable UIImage *)imageforRequest:(NSURLRequest *)request withAdditionalIdentifier:(nullable NSString *)identifier;

@end

根据请求和标识对图像进行是否需要缓存、加入到缓存或者移除缓存等进行操作。

3. AFAutoPurgingImageCache

这个是这个类的接口，大家注意下这个类遵循协议AFImageRequestCache。

/**
 The `AutoPurgingImageCache` in an in-memory image cache used to store images up to a given memory capacity. When the memory capacity is reached, the image cache is sorted by last access date, then the oldest image is continuously purged until the preferred memory usage after purge is met. Each time an image is accessed through the cache, the internal access date of the image is updated.
 */
@interface AFAutoPurgingImageCache : NSObject <AFImageRequestCache>

/**
 The total memory capacity of the cache in bytes.
 */
// 内存缓存总的字节数
@property (nonatomic, assign) UInt64 memoryCapacity;

/**
 The preferred memory usage after purge in bytes. During a purge, images will be purged until the memory capacity drops below this limit.
 */
// 以字节为单位清除后的首选内存使用情况。 在清除过程中，图像将被清除，直到内存容量降至此限制以下。
@property (nonatomic, assign) UInt64 preferredMemoryUsageAfterPurge;

/**
 The current total memory usage in bytes of all images stored within the cache.
 */
// 当前所有图像内存缓存使用的总的字节数
@property (nonatomic, assign, readonly) UInt64 memoryUsage;

/**
 Initialies the `AutoPurgingImageCache` instance with default values for memory capacity and preferred memory usage after purge limit. `memoryCapcity` defaults to `100 MB`. `preferredMemoryUsageAfterPurge` defaults to `60 MB`.
// 初始化，memoryCapcity为100M，preferredMemoryUsageAfterPurge为60M

 @return The new `AutoPurgingImageCache` instance.
 */
- (instancetype)init;

/**
 Initialies the `AutoPurgingImageCache` instance with the given memory capacity and preferred memory usage
 after purge limit.

 @param memoryCapacity The total memory capacity of the cache in bytes.
 @param preferredMemoryCapacity The preferred memory usage after purge in bytes.

 @return The new `AutoPurgingImageCache` instance.
 */
- (instancetype)initWithMemoryCapacity:(UInt64)memoryCapacity preferredMemoryCapacity:(UInt64)preferredMemoryCapacity;

@end

内存中图像缓存中的AutoPurgingImageCache用于存储图像到给定内存容量。 达到内存容量时，图像缓存按上次访问日期排序，然后最旧的图像不断清除，直到满足清除后的首选内存使用量。 每次通过缓存访问图像时，图像的内部访问日期都会更新。

AFAutoPurgingImageCache接口及初始化

从接口描述中我们可以看出来，类的初始化规定了内存总的使用量以及清楚以后的内存最优大小。

- (instancetype)init {
    return [self initWithMemoryCapacity:100 * 1024 * 1024 preferredMemoryCapacity:60 * 1024 * 1024];
}

- (instancetype)initWithMemoryCapacity:(UInt64)memoryCapacity preferredMemoryCapacity:(UInt64)preferredMemoryCapacity {
    if (self = [super init]) {
        self.memoryCapacity = memoryCapacity;
        self.preferredMemoryUsageAfterPurge = preferredMemoryCapacity;
        self.cachedImages = [[NSMutableDictionary alloc] init];

        NSString *queueName = [NSString stringWithFormat:@"com.alamofire.autopurgingimagecache-%@", [[NSUUID UUID] UUIDString]];
        self.synchronizationQueue = dispatch_queue_create([queueName cStringUsingEncoding:NSASCIIStringEncoding], DISPATCH_QUEUE_CONCURRENT);

        [[NSNotificationCenter defaultCenter]
         addObserver:self
         selector:@selector(removeAllImages)
         name:UIApplicationDidReceiveMemoryWarningNotification
         object:nil];

    }
    return self;
}

我们看一下这个初始化方法中都做了什么事情

设置置缓存图像的字典

self.cachedImages = [[NSMutableDictionary alloc] init];

常见和UUID关联的并发队列

NSString *queueName = [NSString stringWithFormat:@"com.alamofire.autopurgingimagecache-%@", [[NSUUID UUID] UUIDString]];
self.synchronizationQueue = dispatch_queue_create([queueName cStringUsingEncoding:NSASCIIStringEncoding], DISPATCH_QUEUE_CONCURRENT);

增加移除所有图像的通知

[[NSNotificationCenter defaultCenter]
         addObserver:self
         selector:@selector(removeAllImages)
         name:UIApplicationDidReceiveMemoryWarningNotification
         object:nil];

- (BOOL)removeAllImages {
    __block BOOL removed = NO;
    dispatch_barrier_sync(self.synchronizationQueue, ^{
        if (self.cachedImages.count > 0) {
            [self.cachedImages removeAllObjects];
            self.currentMemoryUsage = 0;
            removed = YES;
        }
    });
    return removed;
}

这里就是在上面生成的队列中，清空数组，重置一些属性值。

AFCachedImage接口及初始化

这里我们就看一下AFCachedImage的接口及初始化。

@interface AFCachedImage : NSObject

@property (nonatomic, strong) UIImage *image;
@property (nonatomic, strong) NSString *identifier;
@property (nonatomic, assign) UInt64 totalBytes;
@property (nonatomic, strong) NSDate *lastAccessDate;
@property (nonatomic, assign) UInt64 currentMemoryUsage;

@end

- (instancetype)initWithImage:(UIImage *)image identifier:(NSString *)identifier {
    if (self = [self init]) {
        self.image = image;
        self.identifier = identifier;

        CGSize imageSize = CGSizeMake(image.size.width * image.scale, image.size.height * image.scale);
        CGFloat bytesPerPixel = 4.0;
        CGFloat bytesPerSize = imageSize.width * imageSize.height;
        self.totalBytes = (UInt64)bytesPerPixel * (UInt64)bytesPerSize;
        self.lastAccessDate = [NSDate date];
    }
    return self;
}

这个初始化方法里面初始化图像的字节数，并更新上次获取数据的时间。

协议方法的实现

1. AFImageCache协议的实现

将图像根据标识添加到内存

- (void)addImage:(UIImage *)image withIdentifier:(NSString *)identifier;

- (void)addImage:(UIImage *)image withIdentifier:(NSString *)identifier {
    dispatch_barrier_async(self.synchronizationQueue, ^{
        AFCachedImage *cacheImage = [[AFCachedImage alloc] initWithImage:image identifier:identifier];

        AFCachedImage *previousCachedImage = self.cachedImages[identifier];
        if (previousCachedImage != nil) {
            self.currentMemoryUsage -= previousCachedImage.totalBytes;
        }

        self.cachedImages[identifier] = cacheImage;
        self.currentMemoryUsage += cacheImage.totalBytes;
    });

    dispatch_barrier_async(self.synchronizationQueue, ^{
        if (self.currentMemoryUsage > self.memoryCapacity) {
            UInt64 bytesToPurge = self.currentMemoryUsage - self.preferredMemoryUsageAfterPurge;
            NSMutableArray <AFCachedImage*> *sortedImages = [NSMutableArray arrayWithArray:self.cachedImages.allValues];
            NSSortDescriptor *sortDescriptor = [[NSSortDescriptor alloc] initWithKey:@"lastAccessDate"
                                                                           ascending:YES];
            [sortedImages sortUsingDescriptors:@[sortDescriptor]];

            UInt64 bytesPurged = 0;

            for (AFCachedImage *cachedImage in sortedImages) {
                [self.cachedImages removeObjectForKey:cachedImage.identifier];
                bytesPurged += cachedImage.totalBytes;
                if (bytesPurged >= bytesToPurge) {
                    break ;
                }
            }
            self.currentMemoryUsage -= bytesPurged;
        }
    });
}

这里用到了两个阻塞

第一个阻塞

dispatch_barrier_async(self.synchronizationQueue, ^{
    AFCachedImage *cacheImage = [[AFCachedImage alloc] initWithImage:image identifier:identifier];

    AFCachedImage *previousCachedImage = self.cachedImages[identifier];
    if (previousCachedImage != nil) {
        self.currentMemoryUsage -= previousCachedImage.totalBytes;
    }

    self.cachedImages[identifier] = cacheImage;
    self.currentMemoryUsage += cacheImage.totalBytes;
});

这里的作用其实很清楚，就是先根据image和identify实例化AFCachedImage对象。然后在字典中根据identifier查看是否有AFCachedImage对象，如果有的话，那么就减小当前使用内存的值。并将前面实例化的AFCachedImage对象存入字典中，并增加当前使用内存的值。

第二个阻塞

dispatch_barrier_async(self.synchronizationQueue, ^{
    if (self.currentMemoryUsage > self.memoryCapacity) {
        UInt64 bytesToPurge = self.currentMemoryUsage - self.preferredMemoryUsageAfterPurge;
        NSMutableArray <AFCachedImage*> *sortedImages = [NSMutableArray arrayWithArray:self.cachedImages.allValues];
        NSSortDescriptor *sortDescriptor = [[NSSortDescriptor alloc] initWithKey:@"lastAccessDate"
                                                                       ascending:YES];
        [sortedImages sortUsingDescriptors:@[sortDescriptor]];

        UInt64 bytesPurged = 0;

        for (AFCachedImage *cachedImage in sortedImages) {
            [self.cachedImages removeObjectForKey:cachedImage.identifier];
            bytesPurged += cachedImage.totalBytes;
            if (bytesPurged >= bytesToPurge) {
                break ;
            }
        }
        self.currentMemoryUsage -= bytesPurged;
    }
});

这里完成的功能是，首先判断如果当前内存使用量大于内存总量，那么就需要清理了，这里需要计算需要清理多少内存，就是当前内存值 - 最优内存值。然后sortedImages实例化字典中所有的图片，并对这些图片进行按照时间的排序，遍历这个排序后的数组，逐一从字典中移除，终止条件就是移除的字节数大于上面计算的要清除的字节数值。最后，更新下当前内存使用的值。

根据指定标识将图像移出内存

- (BOOL)removeImageWithIdentifier:(NSString *)identifier;

- (BOOL)removeImageWithIdentifier:(NSString *)identifier {
    __block BOOL removed = NO;
    dispatch_barrier_sync(self.synchronizationQueue, ^{
        AFCachedImage *cachedImage = self.cachedImages[identifier];
        if (cachedImage != nil) {
            [self.cachedImages removeObjectForKey:identifier];
            self.currentMemoryUsage -= cachedImage.totalBytes;
            removed = YES;
        }
    });
    return removed;
}

这个还是很好理解的，在定义的并行队列中，取出identifier对应的AFCachedImage对象，然后从字典中移除，并更新当前内存的值。

从内存中移除所有的图像

- (BOOL)removeAllImages;

- (BOOL)removeAllImages {
    __block BOOL removed = NO;
    dispatch_barrier_sync(self.synchronizationQueue, ^{
        if (self.cachedImages.count > 0) {
            [self.cachedImages removeAllObjects];
            self.currentMemoryUsage = 0;
            removed = YES;
        }
    });
    return removed;
}

其实就是一句话，清空字典，更新当前内存使用值。

根据指定的标识符从内存中获取图像

- (nullable UIImage *)imageWithIdentifier:(NSString *)identifier;

- (nullable UIImage *)imageWithIdentifier:(NSString *)identifier {
    __block UIImage *image = nil;
    dispatch_sync(self.synchronizationQueue, ^{
        AFCachedImage *cachedImage = self.cachedImages[identifier];
        image = [cachedImage accessImage];
    });
    return image;
}

- (UIImage*)accessImage {
    self.lastAccessDate = [NSDate date];
    return self.image;
}

其实就是从字典中取值，并更新上次获取图像的时间。

2. AFImageRequestCache协议的实现

根据请求和标识符将图像加入到内存

- (void)addImage:(UIImage *)image forRequest:(NSURLRequest *)request withAdditionalIdentifier:(nullable NSString *)identifier;

- (void)addImage:(UIImage *)image forRequest:(NSURLRequest *)request withAdditionalIdentifier:(NSString *)identifier {
    [self addImage:image withIdentifier:[self imageCacheKeyFromURLRequest:request withAdditionalIdentifier:identifier]];
}

- (NSString *)imageCacheKeyFromURLRequest:(NSURLRequest *)request withAdditionalIdentifier:(NSString *)additionalIdentifier {
    NSString *key = request.URL.absoluteString;
    if (additionalIdentifier != nil) {
        key = [key stringByAppendingString:additionalIdentifier];
    }
    return key;
}

这里其实是调用上面我们讲过的那个根据identifier取出AFCachedImage对象的那个方法。不过下面这个identifier是通过调用下面这个方法生成的。、

根据请求和标识符将图像移出内存

- (BOOL)removeImageforRequest:(NSURLRequest *)request withAdditionalIdentifier:(nullable NSString *)identifier;

- (BOOL)removeImageforRequest:(NSURLRequest *)request withAdditionalIdentifier:(NSString *)identifier {
    return [self removeImageWithIdentifier:[self imageCacheKeyFromURLRequest:request withAdditionalIdentifier:identifier]];
}

这个，就是还是利用那个生成indentifier的方法，获取identify，然后调用前面我们讲过的方法移除对应的图像。

根据请求和标识符获取内存中图像

- (nullable UIImage *)imageforRequest:(NSURLRequest *)request withAdditionalIdentifier:(nullable NSString *)identifier;

- (nullable UIImage *)imageforRequest:(NSURLRequest *)request withAdditionalIdentifier:(NSString *)identifier {
    return [self imageWithIdentifier:[self imageCacheKeyFromURLRequest:request withAdditionalIdentifier:identifier]];
}

这个，就是还是利用那个生成indentifier的方法，获取identify，然后调用前面我们讲过的方法获取对应的图像。

是否将图像缓存到内存

- (BOOL)shouldCacheImage:(UIImage *)image forRequest:(NSURLRequest *)request withAdditionalIdentifier:(nullable NSString *)identifier;

- (BOOL)shouldCacheImage:(UIImage *)image forRequest:(NSURLRequest *)request withAdditionalIdentifier:(nullable NSString *)identifier {
    return YES;
}

本文转载自：https://cloud.tencent.com/developer/article/1872403

ios15适配

• 1、UITabar、NaBar新增scrollEdgeAppearance，来描述滚动视图滚动到bar边缘时的外观，即使没有滚动视图也需要去指定scrollEdgeAppearance，否则可能导致bar的背景设置无效。具体可以参考UIBarAppearance
• 2、tableView 增加sectionHeaderTopPadding属性，默认值是UITableViewAutomaticDimension，可能会使tableView sectionHeader多处一段距离，需要设置 为
• 3、IDFA 请求权限不弹框问题，解决参考iOS15 ATTrackingManager请求权限不弹框
• 4、iOS15终于迎来了UIButton的这个改动

ios14适配

• 1、更改了cell布局视图，之前将视图加载在cell上,将会出现contentView遮罩,导致事件无法响应,必须将customView 放在 contentView 上
• 2、UIDatePicker默认样式不再是以前的，需要设置preferredDatePickerStyle为 UIDatePickerStyleWheels。
• 3、IDFA必须要用户用户授权处理，否则获取不到IDFA
• 4、 UIPageControl的变化 具体参考iOS 14 UIPageControl对比、升级与适配

ios13适配

-1、 iOS 13 推出暗黑模式，UIKit 提供新的系统颜色和 api 来适配不同颜色模式，xcassets 对素材适配也做了调整

• 2、支持第三方登录必须，就必须Sign In with Apple
• 3、MPMoviePlayerController 废弃
• 4、iOS 13 DeviceToken有变化
• 5、模态弹出默认不再是全屏。
• 6、私有方法 KVC 不允许使用
• 7、蓝牙权限需要申请
• 8、LaunchImage 被弃用
• 9、新出UIBarAppearance统一配置navigation bars、tab bars、 toolbars等bars的外观。之前设置na bar和tab bar外观的方法可能会无效

ios12适配

• 1、C++ 标准库libstdc++相关的3个库(libstdc++、libstdc++.6、libstdc++6.0.9 ）废弃，使用libc++代替
• 2、短信 验证码自动填充api

if (@available(iOS 12.0, *)) {

        codeTextFiled.textContentType = UITextContentTypeOneTimeCode;

    }

ios11适配

• 1、ViewController的automaticallyAdjustsScrollViewInsets属性被废弃，用scrollView的contentInsetAdjustmentBehavior代替。
• 2、safeAreaLayoutGuide的引入
• 3、tableView默认开启了Size-self
• 4、新增的prefersLargeTitles属性
• 5、改善圆角，layer新增了maskedCorners属性
• 6、tableView右滑删除新增api
• 7、导航条的层级发生了变化。
  ios11适配相关

ios10适配

• 1、通知统一使用UserNotifications.framework框架
• 2、UICollectionViewCell的的优化，新增加Pre-Fetching预加载机制
• 3、苹果加强了对隐私数据的保护，要对隐私数据权限做一个适配，iOS10调用相机，访问通讯录，访问相册等都要在info.plist中加入权限访问描述，不然之前你们的项目涉及到这些权限的地方就会直接crash掉。
• 4、AVPlayer增加了多个属性，timeControlStatus、
  automaticallyWaitsToMinimizeStalling
• 5、tabar未选中颜色设置 用 unselectedItemTintColor代替

大家好啊，新手一枚，请多关照哈。。。。。。。。。。

在项目开发中，很多地方用到了列表，而 React-Native 官网中提供的组件 ListView，虽然能够满足我们的需求，但是性能问题并没有很好的解决，对于需要展现大量数据的列表，app 的内存将会非常庞大。针对 React-Native 的列表性能问题，现在提供几套可行性方案：

1.利用 Facebook 提供的建议对 ListView 进行优化

Facebook 官方对 ListView 的性能优化做了简单介绍，并提供了以下几个方法：

• initialListSize
• 这个属性用来指定我们第一次渲染时，要读取的行数。如果我们想尽可能的快，我们可以设置它为1, 然后可以在后续的帧中，填弃其它的行。每一次读取的行数，由 pageSize 决定.
• pageSize
• 在使用了 initialListSize 之后，ListView 根据 pageSize 来决定每一帧读取的行数，默认值为1, 但如果你的的 views 非常的小，并且读取时占的资源很少, 你可以调整这个值，在找到适合你的值。
• scrollRenderAheadDistance
• 如果我们的列表有2000个项，而让它一次性读取，它会导致内存和计算资源的耗尽。所以 scrollRenderAhead distance 可以指定，超出当前视图多少，继续宣染。
• removeClippedSubviews
• “当它设置为true时，当本地端的superview为offscreen时 ，不在屏幕上显示的子视图offscreen（它的overflow的值为hidden) 会被删除。它可以改善长列表的滚动的性能，默认值为true.
  这对于大的ListViews来说是一个非常重要。在Android, overflow的值通常为hidden. 所以我们并不需要担心它的设置，但是对于iOS来说，你需要设置row Container的样式为overflow: hidden。

在使用了上述方法后，我们可以看到app的内存占用有了一定的下降（加载100张图片时的效果）：

使用前：

使用后：

3.桥接 Native tableview

第二种方法里面，能够比较好的解决屏幕外的 cell 内存问题，但是和 native tableview 相比，并没有 native 的 cell 重用机制完美，那么，我们可以讲 native 的 tableview 桥接到 React-native 中来，让我们可以在 React-Native 中也可以重用 cell

我们创建一些 VirtualView，他只是遵从了 RCTComponent 协议，其实并不是一个真正的 View，我把它形成一个组件，把它 Bridge 到 JS，这就使得，你在写 JSX 的时候，就可以直接用 VirtualView 来去做布局了。在RN里面做布局的时候我们用VirtualView来做布局。但是最终在 insertReactSubview 时，我们把这些 VirtualView 当做数据去处理，通过 VirtualView 和RealView 的对应关系，把它转化成一个真实的 View 对象添加到 TableView 中去。

但是使用这种方法，我们需要将 tableview 的所有常用数据源方法和代理方法都桥接到 React-Native 中来，甚至对于一些 cell 组件，我们也需要自己桥接，并不能像 React-Native 那样使用自己的组件。当我们的需求比较复杂或者需求发生变化时，就需要重新桥接我们的自定义 cell，这样工作量就会比较大。大多数的 cell 里面如果做展示来用的话，Label 和 Image 基本上能够满足大多数的需求了。所以我们现在只是做了 Label 和 Image 的对应工作，但在 RN 的一些官方控件，在这个 view 里面都是没法直接使用的。

4.用 JS 实现一套 cell 重用的逻辑

基于 RN 的 ScrollView，我们也监听 OnScroll()，他往上滑的时候，我们需要把上面的 cellComponent 挪下来，挪到上面去用。但是这个方式最终的效果并不是特别好。

问题在于，如果我们所有的 Cell 都是一样高的，里面的元素不是很多的情况下，性能还相对好一些，我们每次 OnScroll 的时候，他处理的Cell比较少。如果你希望有一个界面滚动能够达到流畅的话，所有的处理都需要在 16ms 内完成，但是这又造成了 onScroll 都要去刷新页面，导致这样的交互会非常非常多，导致你从 JS，到 native 的 bridge 要频繁的通讯，JS 中的很多处理方式都是异步的，使得这个方案的效果没有达到很好的预期。

总结

从上面的几种方案可以看出，方案1、2、3、4都能够比较好的解决列表的性能问题 ，而且各有优缺点，那么，我们在项目开发中该如何应用呢？

• 当我们在进行列表展示的时候，如果数据量不是特别的庞大（不是无限滚动的），且界面比较复杂的时候，方案1能够比较好的解决性能问题，而且操作起来比较简单，只需要对 listview 的一些属性进行基本设置。
• 当我们需要展示很多数据的时候（不是无限滚动的），我们可以使用方案2，对那些超出屏幕外的部分，对他进行组件最小化
• 当我们需要展示大量数据（可以无限滚动的），我们可以通过方案3/4，来达到重用的目的

本文转载自：https://cloud.tencent.com/developer/article/1930849

在分析alloc源码之前，先来看看一下3个变量 内存地址 和 指针地址 区别：

分别输出3个对象的内容、内存地址、指针地址，下图是打印结果

结论：通过上图可以看出，3个对象指向的是同一个内存空间，所以其内容 和 内存地址是相同的，但是对象的指针地址是不同的

%p -> &p1：是对象的指针地址，
%p -> p1： 是对象指针指向的的内存地址

这就是本文需要探索的内容，alloc做了什么？init做了什么？

准备工作

• 下载 objc4-781 源码
• 编译源码，可参考iOS-底层原理 03：objc4-781 源码编译 & 调试

alloc 源码探索

alloc + init 整体源码的探索流程如下

• 【第一步】首先根据main函数中的LGPerson类的alloc方法进入alloc方法的源码实现（即源码分析开始），

• 【第二步】跳转至_objc_rootAlloc的源码实现

• 【第三步】跳转至callAlloc的源码实现

如上所示，在calloc方法中，当我们无法确定实现走到哪步时，可以通过断点调试，判断执行走哪部分逻辑。这里是执行到_objc_rootAllocWithZone

slowpath & fastpath

其中关于slowpath和fastpath这里需要简要说明下，这两个都是objc源码中定义的宏，其定义如下

其中的__builtin_expect指令是由gcc引入的，
1、目的：编译器可以对代码进行优化，以减少指令跳转带来的性能下降。即性能优化
2、作用：允许程序员将最有可能执行的分支告诉编译器。
3、指令的写法为：__builtin_expect(EXP, N)。表示 EXP==N的概率很大。
4、fastpath定义中__builtin_expect((x),1)表示 x 的值为真的可能性更大；即 执行if 里面语句的机会更大
5、slowpath定义中的__builtin_expect((x),0)表示 x 的值为假的可能性更大。即执行 else 里面语句的机会更大
6、在日常的开发中，也可以通过设置来优化编译器，达到性能优化的目的，设置的路径为：Build Setting --> Optimization Level --> Debug --> 将None 改为 fastest 或者 smallest

cls->ISA()->hasCustomAWZ()

其中fastpath中的 cls->ISA()->hasCustomAWZ() 表示判断一个类是否有自定义的 +allocWithZone 实现，这里通过断点调试，是没有自定义的实现，所以会执行到 if 里面的代码，即走到_objc_rootAllocWithZone

【第四步】跳转至_objc_rootAllocWithZone的源码实现

【第五步】跳转至_class_createInstanceFromZone的源码实现，这部分是alloc源码的核心操作，由下面的流程图及源码可知，该方法的实现主要分为三部分
cls->instanceSize：计算需要开辟的内存空间大小
calloc：申请内存，返回地址指针
obj->initInstanceIsa：将 类 与 isa 关联

根据源码分析，得出其实现流程图如下所示：

alloc 核心操作

核心操作都位于calloc方法中

cls->instanceSize：计算所需内存大小

计算需要开辟内存的大小的执行流程如下所示

• 1、跳转至instanceSize的源码实现

通过断点调试，会执行到cache.fastInstanceSize方法，快速计算内存大小

• 2、跳转至fastInstanceSize的源码实现，通过断点调试，会执行到align16

• 3、跳转至align16的源码实现，这个方法是16字节对齐算法

内存字节对齐原则

在解释为什么需要16字节对齐之前，首先需要了解内存字节对齐的原则，主要有以下三点

数据成员对齐规则：struct 或者 union 的数据成员，第一个数据成员放在offset为0的地方，以后每个数据成员存储的起始位置要从该成员大小或者成员的子成员大小（只要该成员有子成员，比如数据、结构体等）的整数倍开始（例如int在32位机中是4字节，则要从4的整数倍地址开始存储）
数据成员为结构体：如果一个结构里有某些结构体成员，则结构体成员要从其内部最大元素大小的整数倍地址开始存储（例如：struct a里面存有struct b，b里面有char、int、double等元素，则b应该从8的整数倍开始存储）
结构体的整体对齐规则：结构体的总大小，即sizeof的结果，必须是其内部做大成员的整数倍，不足的要补齐
为什么需要16字节对齐

需要字节对齐的原因，有以下几点：

通常内存是由一个个字节组成的，cpu在存取数据时，并不是以字节为单位存储，而是以块为单位存取，块的大小为内存存取力度。频繁存取字节未对齐的数据，会极大降低cpu的性能，所以可以通过减少存取次数来降低cpu的开销
16字节对齐，是由于在一个对象中，第一个属性isa占8字节，当然一个对象肯定还有其他属性，当无属性时，会预留8字节，即16字节对齐，如果不预留，相当于这个对象的isa和其他对象的isa紧挨着，容易造成访问混乱
16字节对齐后，可以加快CPU读取速度，同时使访问更安全，不会产生访问混乱的情况
字节对齐-总结

在字节对齐算法中，对齐的主要是对象，而对象的本质则是一个 struct objc_object的结构体，
结构体在内存中是连续存放的，所以可以利用这点对结构体进行强转。
苹果早期是8字节对齐，现在是16字节对齐
下面以align（8） 为例，图解16字节对齐算法的计算过程，如下所示

首先将原始的内存 8 与 size_t(15)相加，得到 8 + 15 = 23
将 size_t(15) 即 15进行~（取反）操作，~（取反）的规则是：1变为0，0变为1
最后将 23 与 15的取反结果 进行 &（与）操作，&（与）的规则是：都是1为1，反之为0，最后的结果为 16，即内存的大小是以16的倍数增加的