BubblePopup

气泡弹框，气泡提示框，可用于新手引导，功能提示。

在平时的开发中，通常新手引导页或功能提示页会出现气泡弹窗来做提示。如果遇到了这类功能通常需要花费一定的精力来写这么一个工具的，这里写了一个气泡弹窗工具，希望能帮你提升一些开发效率。

使用方法

• 从gitHub上下载代码到本地，代码地址：github.com/zhfei/Bubbl…
• 调用BubblePopupManager文件内的单例方法，在指定的页面上添加气泡提示。 普通文本气泡弹窗使用方式如下：

BubblePopupManager.shared.addPopup(toView: self.view, tips: "冒泡弹窗", popupType: .dotLine, positionType: .bottom, popupPoint: nil, linkPoint: CGPoint(x: sender.frame.midX, y: sender.frame.minY), maxWidth: 200.0)

自定义View气泡弹窗使用方式如下：

BubblePopupManager.shared.addPopup(toView: self.view, customContentView: MyContentView(), popupType: .triangle, positionType: .bottom, popupPoint: CGPoint(x: sender.frame.midX, y: sender.frame.minY), linkPoint: nil, maxWidth: 200.0)

注意：自定义内容View只能使用frame布局，不能使用约束。

设计模式

气泡弹窗View的结构设计采用的设计模式为组合模式

把气泡弹窗分为3个部分：气泡背景，气泡指示器，气泡提示内容。

在创建气泡弹窗时，根据子类的自定义实现，将这三部分分别创建并组装到一起。实现了功能的灵活插拔和自定义扩展。

气泡弹窗View类图

气泡弹窗生成算法采用的设计模式为模版方法模式

在气泡构建基类中设置好气泡的构建步骤，把必要的部分或者提供默认实现的部分在父类中提供默认的实现，对其他需要自定义实现的部分，只在父类中写了一个抽象方法，具体实现交给子类自己实现。

虚线气泡弹窗类图

三角形气泡弹窗类图

核心实现

• BubblePopupManager： 使用气泡弹窗工具的入口，通过它创建并添加一个气泡弹窗到指定的View上。

• BubblePopupBuilder： 气泡弹窗构建者基类，使用模版方法模式定义了气泡的构建流程，子类可以自定义各自的实现。

• DotLineBubblePopupBuilder： 虚线气泡弹窗基类，它是基类BubblePopupBuilder的子类，内部包含了虚线气泡弹窗生成时所需要的工具方法和必要属性，方便创建top,bottom,left,right虚线气泡弹窗。

• TriangleBubblePopupBuilder ： 三角形气泡弹窗基类，它是BubblePopupBuilder的子类，内部包含了三角形气泡弹窗生成时所需要的工具方法和必要属性，方便创建top,bottom,left,right三角形气泡弹窗

• BubblePopup： 气泡弹窗View，它内部使用组合模式将子部件组合起来，组成了一个气泡弹窗。

• BubbleViewFactory： 气泡弹窗子视图创建工程，用于创建气泡弹窗所需要的子视图,并将各个子视图组装成一个最终的气泡弹窗。

BubblePopupBuilder

BubblePopupBuilder是所有气泡弹窗的公共基类，对于里面定义的属性和方法的功能分别为

• 属性：属性里保存的是气泡弹窗公共的，必要的数据。
• 方法：在基类提供的方法中主要用于定义气泡的构建流程。 核心方法如下：

   func setupUI() {

        addBubbleContentView(to: bubblePopup)

        addBubbleBGView(to: bubblePopup)

        updateLayout(to: bubblePopup)

        addBubbleFlagView(to: bubblePopup)

    }

其中气泡内容展示视图和气泡背景视图有默认实现，子类可以直接使用默认样式。

而气泡标识View和气泡布局方法则需要子类自己实现，因为不同类型的气泡弹窗它们的气泡标识设布局方式是不一样的。

DotLineBubblePopupBuilder

虚线气泡基类DotLineBubblePopupBuilder，它继承自BubblePopupBuilder

• 属性：增加了虚线弹窗必要的linkPoint属性，即：虚线与气泡弹窗的连接点。 增加了一个坐标系转换懒加载属性，用于将用户设置的屏幕坐标点转成气泡内部的视图坐标系中的点。

• 重要方法说明：

getDrawDotLineLayerRectParams

用于虚线图层绘制：获取虚线绘制时所需要的绘制元素坐标，如：虚线的开始，结束坐标，连接点圆的直径等。

getDotLineLayerContainerViewFrame

更新虚线容器View的位置大小信息：获取不同情况下的虚线容器Frame。

layoutDotLineBubblePopupView

更新虚线气泡弹窗的frame。

updateBGBubbleViewFrame

更新气泡背景的frame。

这里提供的方法属于工具方法，子类可以通过传递自己的类型来得到对应的结果。这里按道理可以使用设计模式中策略模式来对算法进行封装，如：在基类定义一个抽象方法，将上面则4个工具方法分拆到各自的子类中，让子类在对应的自己的类中实现这个方法。

这里没有这样做原因是：这些方法在子类中的实现代码并不复杂，用一个方法根据条件集中返回是比较方便的，而分拆到不同类中反而很麻烦。所以选择在基类中以方法工具的形式统一放置了。

DotLineTopBubblePopupBuilder

top型虚线气泡弹窗DotLineTopBubblePopupBuilder，它继承自DotLineBubblePopupBuilder，属于一直具体的弹窗类型。

它里面只对下面两个方法进行了重写，根据自己的类型进行子类个性化实现。

override func updateLayout

override func addBubbleFlagView

具体实现如下：

class DotLineTopBubblePopupBuilder: DotLineBubblePopupBuilder {

     

    override func updateLayout(to bubblePopup: BubblePopup) {

        layoutDotLineBubblePopupView(bubblePopup: bubblePopup, positionType: .top)

    }

     

    override func addBubbleFlagView(to bubblePopup: BubblePopup) {

        assert(!self.targetPoint.equalTo(.zero), "气泡提示点无效")

         

        let flagFrame = getDotLineLayerContainerViewFrame(position: .top, targetPoint: self.targetPoint)

        let params = getDrawDotLineLayerRectParams(position: .top)

        let flagBubbleView = BubbleViewFactory.generateDotLineBubbleFlagView(flagFrame: flagFrame, position: .top, params: params)

        bubblePopup.bubbleFlagView = flagBubbleView

        bubblePopup.addSubview(flagBubbleView)

    }

     

}

其他bottom, left, right类型相似。

TriangleBubblePopupBuilder

三角形气泡基类TriangleBubblePopupBuilder，它继承自BubblePopupBuilder

• 属性：相对于基类增加了popupPoint属性，它是三角形顶点指向的坐标点 增加了一个坐标系转换懒加载属性，用于将用户设置的屏幕坐标点转成气泡内部的视图坐标系中的点。

• 重要方法说明：

getDrawTriangleLayeyRectParams

为三角形图层绘制提供不同气泡类型所需要的绘制元素坐标，如：三角形的三个顶点。

getTriangleLayerContainerViewFrame

获取不同情况下三角形图层容器的Frame，用于更新三角形图层容器View的位置大小。

layoutTriangleBubblePopupView

更新三角形气泡弹窗的frame。

updateTriangleBGBubbleView

更新气泡背景的frame。

三角形弹窗基类TriangleBubblePopupBuilder的设计方式和虚线弹窗基类是一样的。
这里的方法属于工具方法，子类可以通过传递自己的类型来得到对应的结果，通过牺牲一点开发模式的规范化来换取开发效率的提升。

在三角形气泡基类的下面同样有4个子类top,bottom,left ,right进行各种的自定义实现。

TriangleTopBubblePopupBuilder

top型三角形气泡弹窗DotLineTopBubblePopupBuilder，它继承自DotLineBubblePopupBuilder，属于一直具体的弹窗类型。

它里面只对下面这两个方法做了重写，根据自己的类型进行子类个性化实现。

override func updateLayout

override func addBubbleFlagView

具体实现如下：

class TriangleTopBubblePopupBuilder: TriangleBubblePopupBuilder {

    override func updateLayout(to bubblePopup: BubblePopup) {

        layoutTriangleBubblePopupView(bubblePopup: bubblePopup, positionType: .top)

    }

    override func addBubbleFlagView(to bubblePopup: BubblePopup) {

        assert(!self.targetPoint.equalTo(.zero), "气泡提示点无效")

         

        let flagFrame = getTriangleLayerContainerViewFrame(position: .top, targetPoint: self.targetPoint)

        let params = getDrawTriangleLayeyRectParams(position: .top)

        let flagBubbleView = BubbleViewFactory.generateTriangleBubbleFlagView(flagFrame: flagFrame, position: .top, params: params)

        bubblePopup.bubbleFlagView = flagBubbleView

        bubblePopup.addSubview(flagBubbleView)

    }

}

其他bottom, left, right类型相似。

弹窗效果展示

三角形气泡弹窗

虚线气泡弹窗

自定义气泡弹窗

上一篇我们介绍了移动开发常见的内存泄漏问题，见《百度工程师移动开发避坑指南——内存泄漏篇》。本篇我们将介绍Swift语言部分常见问题。

对于Swift开发者，Swift较于OC一个很大的不同就是引入了可选类型（Optional），刚接触Swift的开发者很容易在相关代码上踩坑。

本期我们带来与Swift可选类型相关的几个避坑指南：可选类型要判空；避免使用隐式解包可选类型；合理使用Objective-C标识符；谨慎使用强制类型转换。希望能对Swift开发者有所帮助。

一、可选类型（Optional）要判空

在Objective-C中，可以使用nil来表示对象为空，但是使用一个为nil的对象通常是不安全的，如果使用不慎会出现崩溃或者其它异常问题。在Swift中，开发者可以使用可选类型表示变量有值或者没有值，可以更加清晰的表达类型是否可以安全的使用。如果一个变量可能为空，那么在声明时可以使用?来表示，使用前需要进行解包。例如：

var optionalString: String?

在使用可选类型对象时，需要进行解包操作，有两种解包方式：强制解包与可选绑定。

强制解包使用 ! 修饰一个可选对象 ，相当于告诉编译器『我知道这是一个可选类型，但在这里我可以保证他不为空，编译时请忽略此处的可空校验』，例如：

let unwrappedString: String = optionalString!  // 运行时报错：Thread 1: Fatal error: Unexpectedly found nil while unwrapping an Optional value

这里使用 ! 进行了强制解包，如果optionalString为nil，将会产生运行时错误，发生崩溃。**因此，在使用 ! 进行强制解包时，必须保证变量不为nil，要对变量进行判空处理，**如下：

if optionalString != nil {

    let unwrappedString = optionalString!

}

相较于强制解包的不安全性，一般而言推荐另一种解包方式，即可选绑定。例如：

if let optionalString = optionalString {

    // 这里optionalString不为nil，是已经解包后的类型，可以直接使用

}

综上，在对可选类型进行解包时应尽量避免使用强制解包，采用可选绑定替代。如果一定要使用强制解包，那么必须在逻辑上完全保证类型不为空，并且做好注释工作，以增加后续代码的可维护性。

二、避免使用隐式解包可选类型（Implicitly Unwrapped Optionals）

由于可选类型每次使用之前都需要进行显式解包操作，有时变量在第一次赋值之后，就会一直有值，如果每次使用都显式解包，显得繁琐，Swift引入了隐式解包可选类型，隐式解包可选类型可以使用 ! 来表示，并且使用时不需要显式解包，可以直接使用，例如：

var implicitlyUnwrappedOptionalString: String! = "implicitlyUnwrappedOptionalString"

var implicitlyString: String = implicitlyUnwrappedOptionalString

上述例子的隐式解包，在编译和运行过程中都不会发生问题，但如果在两行代码中间插入一行 implicitlyUnwrappedOptionalString = nil将会产生运行时错误，发生崩溃。

在我们实际项目中，一个模块通常由多人维护，通常很难保证变量在第一次赋值之后一直不为nil或者只有在第一次正确赋值之后使用，从安全角度考虑，在使用隐式解包类型之前也要进行判空操作，但这样就和使用可选类型没有区别。对于可选类型（?），不经过解包直接使用编译器会报告错误，对于隐式解包类型，则可直接使用，编译器无法帮助我们做出是否为空的检查。因此，在实际项目中，不推荐使用隐式解包可选类型，如果一个变量是非空的，则选择非空类型，如果不能保证是非空的，则选择使用可选类型。

三、合理使用Objective-C标识符

与Swift不同的是，OC是一种动态类型语言，对于OC而言没有optional这个概念，无法在编译期间检查对象是否可空。苹果在 Xcode 6.3 中引入了一个 Objective-C 的新特性：Nullability Annotations，允许编码时使用nonnull、nullable、null_unspecified等标识符告诉编译器对象是否是可空或者非空的，各标识符含义如下：

nonnull，表示对象是非空的，有__nonnull和_Nonnull等价标识符。

nullable，表示对象可能是空的，有__nullable 和_Nullable等价标识符。

null_unspecified，不知道对象是否为空，有__null_unspecified等价标识符。

OC标识符标注的对象类型和Swift类型对应关系如下：

除了以上标识符外，现在通过Xcode创建的头文件默认被 NS_ASSUME_NONNULL_BEGIN 和 NS_ASSUME_NONNULL_END 包住，即在这之间声明的对象默认标识符是 nonnull 的。

在Swift与OC混编场景，编译器会根据OC标识符将OC的对象类型转换成Swift类型，如果没有显式的标识，默认是null_unspecified。例如：

@interface ExampleOCClass : NSObject

// 没有指定标识符，且没有被NS_ASSUME_NONNULL_BEGIN和NS_ASSUME_NONNULL_END包裹，标识符默认为null_unspecified

+ (ExampleOCClass *)getExampleObject; 

@end



@implementation ExampleOCClass

+ (ExampleOCClass *)getExampleObject {

    return nil; // OC代码直接返回nil

}

@end

class ViewController: UIViewController {

    override func viewDidLoad() {

        super.viewDidLoad()

        let _ = ExampleOCClass.getExampleObject().description // 报错：Thread 1: Fatal error: Unexpectedly found nil while implicitly unwrapping an Optional value

    }

}

在上面例子中，Swift代码调用OC接口获取一个对象，编译器隐式的将OC接口返回的对象转换为隐式解包类型来处理。由于隐式解包类型可以不显式解包直接使用，使用者往往会忽略OC返回的是隐式解包类型，不通过判空而直接使用。但当代码执行时，由于OC接口返回了一个nil，导致Swift代码解包失败，发生运行时错误。

在实际编码中，推荐显式指定OC对象为nonnull或者nullable，针对上述代码进行修改后如下：

@interface ExampleOCClass : NSObject

/// 获取可空的对象

+ (nullable ExampleOCClass *)getOptionalExampleObject;

/// 获取不可空的对象

+ (nonnull ExampleOCClass *)getNonOptionalExampleObject;

@end



@implementation ExampleOCClass

+ (ExampleOCClass *)getOptionalExampleObject {

    return nil;

}

+ (ExampleOCClass *)getNonOptionalExampleObject {

    return [[ExampleOCClass alloc] init];

}

@end

class ViewController: UIViewController {

    override func viewDidLoad() {

        super.viewDidLoad()

        // 标注nullable后，编译器调用接口时，会强制加上 ?

        let _ = ExampleOCClass.getOptionalExampleObject()?.description 

        // 标注nonnull后，编译器将会把接口返回当做不可空来处理

        let _ = ExampleOCClass.getNonOptionalExampleObject().description 

    }

}

在OC对象加上nonnull或者nullable标识符后，相当于给OC代码增加了类似Swift的『静态类型语言的特性』，使得编译器可以对代码进行可空类型检测，有效的降低了混编时崩溃的风险。但这种『静态特性』并不对OC完全有效，例如以下代码，虽然声明返回类型是nonnull的，但是依然可以返回nil:

@implementation ExampleOCClass

+ (nonnull ExampleOCClass *)getNonOptionalExampleObject {

    return nil; // 接口声明不可空，但实际上返回一个空对象，可以通过编译，如果Swift当作非空对象使用，则会发生崩溃

}

@end

class ViewController: UIViewController {

    override func viewDidLoad() {

        super.viewDidLoad()

        ExampleOCClass.getNonOptionalExampleObject().description

    }

}

基于以上例子，依然会产生运行时错误。从安全性的角度上来说，似乎Swift最好在使用所有OC的接口时都进行判空处理。但实际上这将导致Swift的代码充斥着大量冗余的判空代码，大大降低代码的可维护性，同时也违背了『暴露问题，而非隐藏问题』的编码原则，并不推荐这么做，合理的做法是在OC侧做好安全校验，OC对返回类型应做好检验，保证返回类型的正确性，以及返回值和标识符能够对应。

综合来看，OC侧标识符最好遵循如下使用原则：

1、不推荐使用NS_ASSUME_NONNULL_BEGIN和NS_ASSUME_NONNULL_END，因为默认修饰符是nonnull的，在实际开发中很容易忽略返回的对象是否为空。返回空则会导致Swift运行时错误。推荐所有涉及混编的OC接口都需要显式使用相应的标识符修饰。

2、OC接口要谨慎使用 nonnull 修饰 ，必须确保返回值不可能是空的情况下使用，任何不能确定不可空的接口都需要标注为nullable。

3、为避免Swift侧不必要的类型、判空等校验（违背Swift设计理念），在理想状态下需在OC侧进行类型的校验，保证返回对象和标注的标识符完全正确，这样Swift则可以完全信赖OC返回的对象类型。

4、在Swift调用OC代码时，要关注OC返回的类型，尤其是返回隐式解包类型时，要做好判空处理。

5、在OC代码支持Swift调用前，提前对OC代码做好返回类型和标识符的检查，确保返回Swift的对象是安全的。

四、谨慎使用强制类型转换

GEEK TALK

Swift 作为强类型语言，禁止一切默认类型转换，这要求编码者需要明确定义每一个变量的类型，在需要类型转换时必须显式的进行类型转换。Swift可以使用as和as?运算符进行类型转换。

as运算符用于强制类型转换，在类型兼容情况下，可以将一个类型转换为另一个类型，例如：

var d = 3.0 // 默认推断为 Double 类型

var f: Float = 1.0 // 显式指定为 Float 类型

d = f // 编译器将报错“Cannot assign value of type 'Float' to type 'Double'”  

d = f as Double // 需要将Float类型转换为Double类型，才能赋值给f

除了以上列举的基本类型外，Swift还兼容基础类型与对应的OC类型的转换，比如NSArray/Array、NSString/String、NSDictionary/Dictionary。

如果类型转换失败，将会导致运行时错误。例如：

let string: Any = "string"

let array = string as Array // 运行时错误

这里string变量实际是一个String类型，尝试将String类型转换成Array类型，将导致运行时错误。

另一种类型转换的方式是使用as?运算符，如果转换成功，返回一个转换类型的可选类型，如果转换失败，返回nil。例如：

let string: Any = "string"

let array = string as? Array // 转换失败，不会产生运行时错误

这里由于无法将String类型转换为Array类型，因此转换失败，array变量的值为nil，但不会产生运行时错误。

综合来看，在进行类型转换时，需要注意以下几点：

1、类型转换只能在兼容的类型之间进行，例如Double和Float可以相互转换，但String和Array之间不能相互转换。

2、如果使用as进行强制类型转换，需要确保转换是安全的，否则将会导致运行时错误。如果不能确保转换类型之间是兼容的，则应该使用as?运算符，例如将网络数据解析成模型数据时，无法保证网络数据的类型，应该使用as?。

3、在使用as?运算符进行类型转换时，需要注意返回值可能为nil的情况。

----------  END  ----------

推荐阅读【技术加油站】系列：

百度工程师移动开发避坑指南——内存泄漏篇

百度程序员开发避坑指南（Go语言篇）

百度程序员开发避坑指南（3）

百度程序员开发避坑指南（移动端篇）

百度程序员开发避坑指南（前端篇）

方案一

double systemVersion = [UIDevice currentDevice].systemVersion.boolValue;



if (systemVersion >= 7.0) {

    // >= iOS 7.0

} else {

    // < iOS 7.0

}



if (systemVersion >= 10.0) {

    // >= iOS 10.0

} else {

    // < iOS 10.0

}

如果只是大致判断是哪个系统版本，上面的方法是可行的，如果具体到某个版本，如 10.0.1，那就会有偏差。我们知道 systemVersion 依旧是10.0。

方案二

NSString *systemVersion = [UIDevice currentDevice].systemVersion;

NSComparisonResult comparisonResult = [systemVersion compare:@"10.0.1" options:NSNumericSearch];



if (comparisonResult == NSOrderedAscending) {

    // < iOS 10.0.1

} else if (comparisonResult == NSOrderedSame) {

    // = iOS 10.0.1

} else if (comparisonResult == NSOrderedDescending) {

    // > iOS 10.0.1

}



// 或者



if (comparisonResult != NSOrderedAscending) {

    // >= iOS 10.0.1

} else {

    // < iOS 10.0.1

}

有篇博客提到这种方法不靠谱。比如系统版本是 10.1.1，而我们提供的版本是 8.2，会返回NSOrderedAscending，即认为 10.1.1 < 8.2 。

其实，用这样的比较方式 NSComparisonResult comparisonResult = [systemVersion compare:@"10.0.1"]，的确会出现这种情况，因为默认是每个字符逐个比较，即 1(0.1.1) < 8(.2)，结果可想而知。但我是用 NSNumericSearch 方式比较的，即数值的比较，不是字符比较，也不需要转化成NSValue(NSNumber) 再去比较。

方案三

if (NSFoundationVersionNumber >= NSFoundationVersionNumber_iOS_7_0) {

    // >= iOS 7.0

} else {

    // < iOS 7.0

}



// 或者



if (kCFCoreFoundationVersionNumber >= kCFCoreFoundationVersionNumber_iOS_7_0) {

    // >= iOS 7.0

} else {

    // < iOS 7.0

}

这些宏定义是 Apple 预先定义好的，如下：

#if TARGET_OS_IPHONE

...

#define NSFoundationVersionNumber_iOS_9_4 1280.25

#define NSFoundationVersionNumber_iOS_9_x_Max 1299

#endif

细心的童靴可能已经发现问题了。Apple 没有提供 iOS 10 以后的宏？，我们要判断iOS10.0以后的版本该怎么做呢？
有篇博客中提到，iOS10.0以后版本号提供了，并且逐次降低了，并提供了依据。

#if TARGET_OS_MAC

#define NSFoundationVersionNumber10_1_1	425.00

#define NSFoundationVersionNumber10_1_2	425.00

#define NSFoundationVersionNumber10_1_3	425.00

#define NSFoundationVersionNumber10_1_4	425.00

...

#endif

我想这位童鞋可能没仔细看， 这两组宏是分别针对iPhone和macOS的，不能混为一谈的。

所以也只能像下面的方式来大致判断iOS 10.0， 但之前的iOS版本是可以准确判断的。

if (NSFoundationVersionNumber > floor(NSFoundationVersionNumber_iOS_9_x_Max)) {

    // > iOS 10.0

} else {

    // <= iOS 10.0

}

方案四

在iOS8.0中，Apple也提供了NSProcessInfo 这个类来检测版本问题。

@property (readonly) NSOperatingSystemVersion operatingSystemVersion NS_AVAILABLE(10_10, 8_0);

- (BOOL) isOperatingSystemAtLeastVersion:(NSOperatingSystemVersion)version NS_AVAILABLE(10_10, 8_0);

所以这样检测：

if ([[NSProcessInfo processInfo] isOperatingSystemAtLeastVersion:(NSOperatingSystemVersion){.majorVersion = 8, .minorVersion = 3, .patchVersion = 0}]) {

     // >= iOS 8.3

} else {

     // < iOS 8.3

}

用来判断iOS 10.0以上的各个版本也是没有问题的，唯一的缺点就是不能准确版本是哪个版本，当然这种情况很少。如果是这种情况，可以通过字符串的比较判断。

方案五

通过判断某种特定的类有没有被定义，或者类能不能响应哪个特定版本才有的方法。
比如，UIAlertController 是在iOS 8.0才被引进来的一个类，我们这个依据来判断版本

if (NSClassFromString(@"UIAlertController")) {

    // >= iOS 8.0

} else {

    // < iOS 8.0

}

说到这里，就顺便提一下在编译期间如何进行版本控制，依然用UIAlertController 来说明。

NS_CLASS_AVAILABLE_IOS(8_0) @interface UIAlertController : UIViewController

NS_CLASS_AVAILABLE_IOS(8_0) 这个宏说明，UIAlertController 是在iOS8.0才被引进来的API，那如果我们在iOS7.0上使用，应用程序就会挂掉，那么如何在iOS8.0及以后的版本使用UIAlertController ，而在iOS8.0以前的版本中仍然使用UIAlertView 呢？

这里我们会介绍一下在#import <AvailabilityInternal.h> 中的两个宏定义：

*__IPHONE_OS_VERSION_MIN_REQUIRED

*__IPHONE_OS_VERSION_MAX_ALLOWED

从字面意思就可以直到，__IPHONE_OS_VERSION_MIN_REQUIRED 表示iPhone支持最低的版本系统，__IPHONE_OS_VERSION_MAX_ALLOWED 表示iPhone允许最高的系统版本。

__IPHONE_OS_VERSION_MAX_ALLOWED 的取值来自iOS SDK的版本，比如我现在使用的是Xcode Version 8.2.1（8C1002），SDK版本是iOS 10.2，怎么看Xcode里SDK的iOS版本呢？

进入PROJECT，选择Build Setting，在Architectures中的Base SDK中可以查看当前的iOS SDK版本。

打印这个宏，可以看到它一直输出100200。

__IPHONE_OS_VERSION_MIN_REQUIRED 的取值来自项目TARGETS的Deployment Target，即APP愿意支持的最低版本。如果我们修改它为8.2，打印这个宏，会发现输出80200，默认为10.2。

通常，__IPHONE_OS_VERSION_MAX_ALLOWED 可以代表当前的SDK的版本，用来判断当前版本是否开始支持或具有某些功能。而__IPHONE_OS_VERSION_MIN_REQUIRED 则是当前SDK支持的最低版本，用来判断当前版本是否仍然支持或具有某些功能。

回到UIAlertController 使用的问题，我们就可以使用这些宏，添加版本检测判断，从而使我们的代码更健壮。

 - (void)showAlertView {

#if defined(__IPHONE_OS_VERSION_MIN_REQUIRED) && __IPHONE_OS_VERSION_MIN_REQUIRED < __IPHONE_9_0

    UIAlertView *alertView = [[UIAlertView alloc] initWithTitle:@"Title" message:@"message" delegate:nil cancelButtonTitle:@"Cancel" otherButtonTitles:@"OK", nil];

    [alertView show];

#else

    if (NSFoundationVersionNumber >= NSFoundationVersionNumber_iOS_8_0) {

        UIAlertController *alertViewController = [UIAlertController alertControllerWithTitle:@"Title" message:@"message" preferredStyle:UIAlertControllerStyleAlert];



        UIAlertAction *cancelAction = [UIAlertAction actionWithTitle:@"Cancel" style:UIAlertActionStyleCancel handler:nil];

        UIAlertAction *otherAction = [UIAlertAction actionWithTitle:@"OK" style:UIAlertActionStyleDefault handler:nil];



        [alertViewController addAction:cancelAction];

        [alertViewController addAction:otherAction];



        [self presentViewController:alertViewController animated:YES completion:NULL];

    }

#endif

}

方案六

iOS 11.0 以后，Apple加入了新的API，以后我们就可以像在Swift中的那样，很方便的判断系统版本了。

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

	// iOS 11.0 及以后的版本

} else {

	// iOS 11.0 之前

}

参考链接

前言

相信这几天各大互联网应用首页置灰已经接踵而至，事情缘由我就不太赘述。毫无疑问，我司从30号当晚就收到紧急需求，我们要求1号必须紧急发版，除了常规的首页支持配置的动态置灰外，我们还要求另外一个需求就是，启动图也需要支持动态配置灰功能，经过几个同事的努力，于1号当晚顺利的发版了，第二天一早便成功上线，在此记录一下实现iOS启动图动态置灰的方案心得。

方案过程

实话说，当我接到此需求时，我负责的是实现iOS启动图动态置灰，当时我不太确认是否能实现，我能想到的是马上搜百度、谷歌、掘金等看是否有现成的轮子，答案肯定是有的，分别是

• BBADynamicLaunchImage

此方案非常轻量级，只有BBADynamicLaunchImage一个类，功能也只有一个，即查找系统缓存的启动图路径，使用我们提供的UIImage替换掉。其他版本控制本非必要需求我们自己代码控制即可。最终我也是直接采用了这个方案，其他控制由我代码自己编写核心方法如下。PS：（虽然提供iOS13之前的启动图路径查找，但是经过我实测一台iOS12的设备是不生效的，只有iOS13意思机型生效）

/// 系统启动图缓存路径



+ (NSString *)launchImageCacheDirectory {



NSString *bundleID = [NSBundle mainBundle].infoDictionary[@"CFBundleIdentifier"];



NSFileManager *fm = [NSFileManager defaultManager];



// iOS13之前



NSString *cachesDirectory = [NSSearchPathForDirectoriesInDomains(NSCachesDirectory, NSUserDomainMask, YES) firstObject];



NSString *snapshotsPath = [[cachesDirectory stringByAppendingPathComponent:@"Snapshots"] stringByAppendingPathComponent:bundleID];



if ([fm fileExistsAtPath:snapshotsPath]) {



return snapshotsPath;



}



// iOS13



NSString *libraryDirectory = [NSSearchPathForDirectoriesInDomains(NSLibraryDirectory, NSUserDomainMask, YES) firstObject];



snapshotsPath = [NSString stringWithFormat:@"%@/SplashBoard/Snapshots/%@ - {DEFAULT GROUP}", libraryDirectory, bundleID];



if ([fm fileExistsAtPath:snapshotsPath]) {



return snapshotsPath;



}



return nil;



}

• LLDynamicLaunchScreen

稍微吐槽下这个库，此库也是我一开始使用的。它也是基于BBADynamicLaunchImage做了一些拓展。比如版本控制，但是它内置的版本控制有漏洞，它只支持CFBundleShortVersionString,也就是我们俗称的大版本，如果我build号改了版本号不变岂不是有问题？（这也是我打包后不生效调试了好久才发现的问题）而且要支持动态置灰，不发版恢复原图就更加有问题。最后也是弃用了，当然这个库支持暗黑模式下的启动图，但是我本身app就是不支持的这个功能就聊胜于无了，最终该用了上边的方案，动态控制由我自己处理。

启动图如何置灰

要实现启动图和原图一模一样只是变成灰白，这里就稍微要花一点点心思了。众所周知我们现在iOS启动图都是直接用LaunchScreen这个Storyborad生成的，那我们是否能加载这个LaunchScreen，然后截取UIView的图片，之后再通过bitmap转换成一张灰白图？答案是显而易见的，代码如下。

首先我们要给LaunchScreen定义一个id,因为默认没有人去加载它，它也没有id。

代码如下：

生成启动图原图或灰白图方法，注意此方法要在主线程跑。

+ (UIImage *)createLaunchScreenImage:(BOOL)isNeedGray {



UIStoryboard *sb = [UIStoryboard storyboardWithName:@"LaunchScreen" bundle:nil];



UIViewController *vc = [sb instantiateViewControllerWithIdentifier:@"LaunchScreen"];



[vc loadViewIfNeeded];



vc.view.frame = UIScreen.mainScreen.bounds;



UIImage *image = [vc.view snapshotImage];



if (isNeedGray) {



image = [image createGrayImage];



}



return image;



}

UIView截图

func snapshotImage() -> UIImage? {



UIGraphicsBeginImageContextWithOptions(self.bounds.size, self.isOpaque, 0);



self.layer.render(in: UIGraphicsGetCurrentContext()!)



let image = UIGraphicsGetImageFromCurrentImageContext()



UIGraphicsEndImageContext()



return image



}

生成灰白图方法，由于启动图必须size匹配，所以scale那些要处理好。

-(UIImage*)createGrayImage {



int width = self.size.width * self.scale;



int height = self.size.height * self.scale;



CGColorSpaceRef colorSpace = CGColorSpaceCreateDeviceGray();



CGContextRef context =CGBitmapContextCreate(nil,



width,



height,



8,// bits per component



0,



colorSpace,



kCGBitmapByteOrderDefault);



CGColorSpaceRelease(colorSpace);



if(context ==NULL) {



return nil;



}



CGContextDrawImage(context,



CGRectMake(0,0, width, height), self.CGImage);



UIImage*grayImage = [UIImage imageWithCGImage:CGBitmapContextCreateImage(context) scale:self.scale orientation:self.imageOrientation];



CGContextRelease(context);



return grayImage;



}

动态替换

我们只需要请求后台配置,需要灰白就提供灰白图，当配置失效，需要还原时候，根据上面方法，直接渲染一个LaunchScreen原图即可,当然其中还要做好持久化控制，不要处理多次替换，替换生效后不再处理。

末尾

以上就是我实现此次iOS启动图动态置灰的全过程，由于过程的艰辛，加之我自己是一个Swifter。估计不久将来，我也会基于Swift写一个稍微友好点的库，在此立个Flag。

1. Universal link 介绍

1.1 Universal link 是什么

Universal Link 是苹果在 WWDC 上提出的 iOS9 的新特性之一。此特性类似于深层链接，并能够方便地通过打开一个 Https 链接来直接启动您的客户端应用(手机有安装 App)。对比起以往所使用的 URL Scheme,这种新特性在实现 web-app 的无缝链接时能够提供极佳的用户体验。

当你的应用支持 Universal Link(通用链接)，当用户点击一个链接是可以跳转到你的网站并获得无缝重定向到对应的 APP，且不需要通过 Safari 浏览器。如果你的应用不支持的话，则会在 Safari 中打开该链接。在苹果开发者中可以看到对它的介绍是：

Seamlessly link to content inside your app, or on your website in iOS 9 or later. With universal links, you can always give users the most integrated mobile experience, even when your app isn’t installed on their device.

1.2 Universal link 的应用场景

使用 Universal Link(通用链接)可以让用户在 Safari 浏览器或者其他 APP 的 webview 中拉起相应的 APP，也可以在 APP 中使用相应的功能，从而来把用户引流到 APP 中。

这具体是一种怎样的情景呢？举个例子，你的用户 safari 里面浏览一个你们公司的网页，而此时用户手机也同时安装有你们公司的 App；而 Universal Link 能够使得用户在打开某个详情页时直接打开你的 app 并到达 app 中相应的内容页面，从而实施用户想要的操作(例如查看某条新闻,查看某个商品的明细等等)。比如在 Safari 浏览器中进入淘宝网页点击打开 APP 则会使用 Universal Link(通用链接)来拉起淘宝 APP。

1.3 Universal link 跳转的好处

• 唯一性: 不像自定义的 URL Scheme，因为它使用标准的 HTTPS 协议链接到你的 web 站点，所以一般不会被其它的 APP 所声明。另外，URL scheme 因为是自定义的协议，所以在没有安装 app 的情况下是无法直接打开的(在 Safari 中还会出现一个不可打开的弹窗)，而 Universal Link(通用链接)本身是一个 HTTPS 链接，所以有更好的兼容性；

• 安全: 当用户的手机上安装了你的 APP，那么系统会去你配置的网站上去下载你上传上去的说明文件(这个说明文件声明了当前该 HTTPS 链接可以打开那些 APP)。因为只有你自己才能上传文件到你网站的根目录，所以你的网站和你的 APP 之间的关联是安全的；

• 可变: 当用户手机上没有安装你的 APP 的时候，Universal Link(通用链接)也能够工作。如果你愿意，在没有安装你的 app 的时候，用户点击链接，会在 safari 中展示你网站的内容；

• 简单: 一个 HTTPS 的链接，可以同时作用于网站和 APP；

• 私有: 其它 APP 可以在不需要知道你的 APP 是否安装了的情况下和你的 APP 相互通信。

2. Universal link 配置和运行

2.1 配置 App ID 支持 Associated Domains

登录developer.apple.com/ 苹果开发者中心，找到对应的 App ID，在 Application Services 列表里有 Associated Domains 一条，把它变为 Enabled 就可以了。

2.2 配置 iOS App 工程

Xcode 11.0 版本

工程配置中相应功能：targets->Signing&Capabilites->Capability->Associated Domains，在其中的 Domains 中填入你想支持的域名，也必须必须以 applinks:为前缀。

具体步骤如下图:

Xcode 11.0 以下版本

工程配置中相应功能：targets->Capabilites->Associated Domains，在其中的 Domains 中填入你想支持的域名，必须以 applinks:为前缀。

配置项目中的 Associated Domains:

2.2 配置和上传 apple-app-association

究竟哪些的 url 会被识别为 Universal Link，全看这个 apple-app-association 文件Apple Document UniversalLinks.html

• 你的域名必须支持 Https

• 域名 根目录 或者 .well-known 目录下放这个文件apple-app-association，不带任何后缀

• 文件为 json 保存为文本即可

• json 按着官网要求填写即可

apple-app-site-association模板：

{    "applinks": {        "apps": [],        "details": [            {                "appID": "9JA89QQLNQ.com.apple.wwdc",                "paths": [ "/wwdc/news/", "/videos/wwdc/2015/*"]            },            {                "appID": "ABCD1234.com.apple.wwdc",                "paths": [ "*" ]            }        ]    }}

复制代码

说明:

appID： 组成方式是 teamId.yourapp’s bundle identifier。如上面的 9JA89QQLNQ 就是 teamId。登陆开发者中心，在 Account -> Membership 里面可以找到 Team ID。

paths： 设定你的 app 支持的路径列表，只有这些指定的路径的链接，才能被 app 所处理。星号的写法代表了可识 别域名下所有链接。

上传指定文件:上传该文件到你的域名所对应的根目录或者.well-known 目录下，这是为了苹果能获取到你上传的文件。上传完后,自己先访问一下,看看是否能够获取到，当你在浏览器中输入这个文件链接后，应该是直接下载 apple-app-site-association 文件。

2.4 如何验证 Universal link 生效

• 可以使用 iOS 自带的备忘录程序，输入链接，长按链接，如果弹出菜单中有”在‘xxx’中打开”，即表示配置生效。

• 或者将要测试的网址在Safari中打开，在出现的网页上方下滑，可以看到有在”xxx”应用中打开, 出现菜单:

当点击某个链接，直接可以进我们的 app 了，但是我们的目的是要能够获取到用户进来的链接，根据链接来展示给用户相应的内容。

在AppDelegate里中实现代理方法，官方链接：Handling Universal Links

Objective-C:

- (BOOL)application:(UIApplication *)application continueUserActivity:(NSUserActivity *)userActivity restorationHandler:(void (^)(NSArray * _Nullable))restorationHandler {    if ([userActivity.activityType isEqualToString:NSUserActivityTypeBrowsingWeb])    {        NSURL *url = userActivity.webpageURL;        if (url是我们希望处理的)        {            //进行我们的处理        }        else        {            [[UIApplication sharedApplication] openURL:url];        }    }         return YES;}

复制代码

Swift:

func application(_ application: UIApplication,                 continue userActivity: NSUserActivity,                 restorationHandler: @escaping ([Any]?) -> Void) -> Bool{    guard userActivity.activityType == NSUserActivityTypeBrowsingWeb,        let incomingURL = userActivity.webpageURL,        let components = NSURLComponents(url: incomingURL, resolvingAgainstBaseURL: true),        let path = components.path,        let params = components.queryItems else {            return false    }        print("path = (path)")        if let albumName = params.first(where: { $0.name == "albumname" } )?.value,        let photoIndex = params.first(where: { $0.name == "index" })?.value {                print("album = (albumName)")        print("photoIndex = (photoIndex)")        return true            } else {        print("Either album name or photo index missing")        return false    }}

复制代码

3. Universal link 遇到的问题和解决方法

3.1 跨域

前端开发经常面临跨域问题，恩 Universal Link 也有跨域问题，但不一样的是，Universal Link，必须要求跨域，如果不跨域，就不行，就失效，就不工作。（iOS 9.2 之后的改动，苹果就这么规定这么设计的）

这也是上面拿知乎举例子的时候重点强调的一个问题，知乎为什么使用oia.zhihu.com做 Universal Link？

• 假如当前网页的域名是 A

• 当前网页发起跳转的域名是 B

• 必须要求 B 和 A 是不同域名，才会触发 Universal Link

• 如果 B 和 A 是相同域名，只会继续在当前 WebView 里面进行跳转，哪怕你的 Universal Link 一切正常，根本不会打开 App

是不是不太好理解，那直接拿知乎举例子

有心人可能看到，知乎的 Universal Link 配置的是 oia.zhihu.com 这个域名，并且对这个域名下比如/answers /questions /people 等 urlpath 进行了识别，也就是说，知乎的 universal link，只有当你访问 https://oia.zhihu.com/questions/xxxx，在移动端会触发 Universal Link，而知乎正经的 Urlhttps//www.zhihu.com/questions/xxx是不会触发 Universal Link 的，知乎为什么制作，为什么不把他的主域名配置 Universal Link，就是由于 Universal Link 的跨域的原因。

知乎的一般网页 URL 都是http://www.zhihu.com域名，你在微信朋友圈看到了知乎的问题分享，如果 copy url 你就能看到这样的链接

http://www.zhihu.com/question/22…

微信里其实是屏蔽 Schema 的，但是你依然能看到大大的一个按钮App内打开，这确实就是通过 Universal Link 来实现的，但如果知乎把 Universal Link 配在了http://www.zhihu.com域名，那么即便已经安装了 App，Universal Link 也是不会生效的。

一般的公司都会有自己的主域名，比如知乎的http://www.zhihu.com，在各处分享传播的时候，也都是直接分享基于主域名的 url，但为了解决苹果强制要求跨域才生效的问题，Universal Link 就不能配置在主域名下，于是知乎才会准备一个oia.zhihu.com域名，专为 Universal Link 使用，不会跟任何主动传播分享的域名撞车，从而在任何活动 WAP 页面里，都能顺利让 Universal Link 生效。

跨域的另外一个好处是可以突破微信跳转限制，支持微信无缝跳转到 App.

简单一句话

只有当前 webview 的 url 域名，与跳转目标 url 域名不一致时，Universal Link 才生效

3.2 更新

apple-app-association 的更新时机有以下两种：

• 每次 App 安装后的第一次 Launch，会拉取 apple-app-association

• Appstore 每次 App 的版本更新后的第一次 Launch，也会更新 apple-app-association

所以反复重新杀 APP 重开完全没用，删了 App 重装确实有用，但不可能让用户这么去做。也就是说，一旦不小心因为意外 apple-app-association，想要挽回又让那部分用户无感，App 再发一个版本就好了

3.3 Universal Link 用户行为

Universal Link 触发后打开 App，这时候 App 的状态栏右上角会有文字提示来自 XXApp，可以点状态栏的文字快速返回原来的 AP

如果用户点了返回微信，就会被苹果记住，认为用户并不需要跳出原 App 打开新 App，因此这个 App 的 Universal Link 会被关闭，再也无效。

想要开启也不是不行，让用户重新用 safari 打开，universal link 的页面，然后会出现很像苹果 smart bar 的东西，那个东西点了后就能打开

4. H5 端的 Universal Link 业务部署

H5 端的 Universal Link 跳转，从产品经理的角度看，需要满足以下 2 个需求：

• 如果已安装 App，跳转对应界面

• 如果没安装 App，跳转 App 下载界面

H5 端部署 Universal Link 示例：

router.use('/view', function (req, res, next) {    var path = req.path;    res.redirect('https://www.xxx.com/view' + path + '?xxx=xxx');});

复制代码

整个效果就是

• 跳转https://www.xxx.com/view/*

• 已安装 App

• 打开 App 触发 handleUniversalLink

• 走到/view/分支，拼接阅读页路由跳转

• 未安装 AppWebView

• 原地跳转https://``www.xxx.com``/view/*

• 命中服务器的重定向逻辑

• 重定向到https://``www.xxx.com``/view/*

• 打开相应的 H5 页面

在项目中有500.0或者500.00的情况需要处理

实习的同学写了一段这样的代码

public extension String {

    var trimZero: String {

        replacingOccurrences(of: ".00", with: "").replacingOccurrences(of: ".0", with:"")

    }

}

咋一看似乎没啥问题，结果也符合预期

但是上面的case其实没有覆盖全，例如：500.01，那上面的处理方式就有bug了，会被处理成5001

正确的处理方式

public extension String {

    var trimZero: String {

        guard let value = Double(self) else { return self }

        let formatter = NumberFormatter()

        formatter.minimumFractionDigits = 0

        formatter.maximumFractionDigits = 2

        return formatter.string(from: NSNumber(value: value)) ?? self

    }

}

测试结果

参考

• iOS中一个很重要，但是不熟悉的类NumberFormatter

XCode老罢工

从今年开始，项目中一个组件的主工程在开发过程中，运行编译时间耗时长，XCode是不是都会转菊花，平均每次编译的时间大概在5min左右，非常影响开发效率，今日刚好提测完，抽空仔细看看为何如此卡顿。

环境

在卡顿的时候打开活动监视器，发现XCode占用内存非常高，平均在20GB左右，峰值达到60GB

在Command + k 删除DerivedData 里面的缓存之后，还是没有明显的加速结果。

寻找原因

查看编译日志

发现组件内的所有文件在编译的时候都会有几个相似的警告。

这些警告来自同一个文件，通过pch文件引用。

有警告的文件是该组件的网络请求文件，是很早以前建立的，文件里面没有自动生成NS_ASSUME_NONNULL_BEGIN文件内大概有几百个警告。在编译文件的时候，这些警告都会去做缓存、分析。导致运行起来非常卡顿。

解决

消除警告，重新编译，发现项目跑起来非常的舒畅！

如果是有其他第三方库或者组件的警告，可以在podFile中增加 :inhibit_warnings => true 来避免编译的时候检查警告。这种方式也会加快编译速度。

pod 'XXNetEngineModule', :inhibit_warnings => true

可以看到解决完XCode的内存大小基本就在1GB左右。编译速度也基本上能达到秒启（10s内）。

今天凌晨WWDC 2023正式召开，本文分析介绍了其中的精华部分

有关如何观看可以阅读👉 WWDC 2023 观看指南

Keynote

常规硬件发布

Mac

Macbook Air

新款 M2 芯片的15 寸 Macbook Air

• 拥有8核CPU以及10核GPU
• 边框厚度5毫米
• 屏幕亮度最高可达500尼特
• 15.3英寸支持1080P高清摄像头
• 支持Six-Speaker Sound system六声道音响以及Touch ID指纹识别
• 硬盘方面最高可拓展至2TB
• 内存最高可拓展至24GB
• 提供18个小时电池续航
• 售价10499元起，即日起开始预订，下周发售

Mac Studio

新款 Mac Studio 搭载M2 Max和M2 Ultra两款芯片

• 拥有24核心CPU以及76核心GPU
• 配备32核心网络神经引擎
• 支持最高192GB内存拓展
• 8TB硬盘拓展
• 支持8K外接显示
• 售价16499元起，下周起售

Mac Pro

Mac 产品线最强大的一员，Mac Pro 也迎来了 Apple Silicon，至此全系 Mac 产品线已完成从 Intel 芯片向 Apple Silicon 转变

• 配置基本同 Mac Studio
• 售价55999元起

常规软件发布

iOS 17

iOS 17主要进行了细节优化和小功能迭代更新

• 全新自定义来电界面形象

• Facetime新增语音留言

• Messages支持搜索 & 地图信息

• 新增 Check In功能

• 新增全局 Live Sticker

• 改进键盘输入法，增加词语联想输入与纠错功能

• 可交互Widget

• 新系统级App Journal 手记 App [今年稍晚推出]

• NameDrop： AirDrop的升级功能，可在一台手机与另外设备接触时进行隔空投送，如超过隔空投送距离，还可通过蜂窝数据将剩余未传完内容继续投送

• 待机体验功能：将iPhone横放在手机支架上能够显示时钟，天气以及小组件

iOS 开发者需要关心的是：

• 可交互 Widget，已有Widget的App可以重新思考Widget的设计
• 全局Live Sticker，兼容性测试 & 是否需要进行专门适配

iPadOS 17

除了共享上述提到的iOS更新外，iPadOS主要有以下方面的更新

• 去年iOS 16的自定义壁纸功能加入 iPadOS

• 健康 App 登陆 iPadOS，提供大屏健康信息查阅体验

• 更好的系统级 PDF 支持

新一代 macOS 命名为 Sonoma，主要的特点如下

• 加入 Metal 3和MetalFX Upscaling功能

• 添加系统级别游戏模式，为主流手柄提供更好的蓝牙采样支持

• 《死亡搁浅》登录macOS平台，制作人现场展示了“死亡搁浅导演剪辑版”

• 支持添加 Widget 到 macOS 桌面

• 支持添加 iPhone 上的Widget 到 macOS，会通过 iPhone 端进行更新然后传输到 macOS 渲染显示

• 全新设计的智能叠放组件

• 运动方面：更加详细的运动数据记录，同时数据也会同步显示在配对的iPhone上

• 户外方面：支持记录离开信号区的位置，发送卫星求助信息，自动生成海拔图

• 心理健康：增加对抑郁症和焦虑症的自测功能，距离屏幕距离过近时还会进行提醒，降低近视风险

tvOS 17 & AirPods

tvOS 17：

• 支持 FaceTime 和视频流转，可将iPhone与iPad收到的FaceTime来电投射到Apple TV上进行视频通话

• 支持 FaceTime 时的人物居中模式

• 允许第三方视频通话应用程序，利用iPhone和iPad作为直播源，在Apple TV进行FaceTime视频通话

AirPods：

• 添加自适应模式，在通透模式和降噪模式中智能切换

One More Thing

新硬件 VisionPro + 对应新操作系统 visionOS

时隔十年，苹果终于发布自家的 VR/AR 头戴式设备，入局该领域

TLDR：发售价3499$

硬件

• M2 芯片 + R1 芯片
• 2300万像素 Micro-OLED 屏幕
• 单眼分辨率超 4K 电视
• 满电续航 2h
• 12个摄像头 + 5个传感器 + 6个麦克风
• 全新空间音频体验

交互

体验

• 全新 App Store
• 大部分 iOS & iPadOS 可以直接兼容使用
• 首个 3D 相机

新的 VisionPro 和 visionOS 的信息后续会有专门介绍，这里就不再过多展开

Platforms State of the Union

上面的 Keynote 部分是全球消费者比较关注的，而后续的PSTU则是 iOS 开发者更为关心的更新

这里主要突出下 IDE 和 Language 的更新

Xcode 15

• 发布了最新的 Static Linker，据称最快是 ld64 的 5 倍性能提升

• 新的 library format: mergeable libraries ，这是一种动静结合的二进制，Debug 的时候动态链接，Release 的时候静态链接，兼顾性能和开发体验

• 支持自动生成对图片和颜色资源的静态访问API

  • 业务上之前的解决方案可查看 玩转 Swift 的 namespace

• 添加了 Swift Macro 支持，简化了大量的模版代码编写

• 新的 SwiftData 数据库框架

前言

RxSwift是一个基于响应式编程的Swift框架，它提供了一种简洁而强大的方式来处理异步和事件驱动的编程任务。在RxSwift中，核心流程包括观察者、可观察序列和订阅。

RxSwift核心流程三部曲

   // 1.创建序列

   _ = Observable<String>.create { ob in

     // 3.发送信号

      ob.onNext("你好")

      return Disposables.create()

     // 2.订阅序列

    }.subscribe(onNext: { text in

      print("订阅到了\(text)")

    })

  }

• 1.创建序列
• 2.订阅序列
• 3.发送信号

上面三部曲的执行结果：

 第一次玩RxSwift比较好奇为什么会打印订阅到了你好，明明是两个闭包里面的代码。
我们先简单分析下：

• 序列创建create后面带了闭包A，闭包A里面执行了发送信号的流程
• 订阅subsribe后面带了闭包B
• 根据结果我们知道一定是先执行了闭包A，再把闭包A的你好传给了闭包B,然后输出结果

RxSwift核心逻辑分析

创建序列

点进create函数可以看到它是拓展了ObservableType这个协议，同时创建了一个AnonymousObservable内部类（看名字是匿名序列，具备一些通用的特性）分析AnonymousObservable的继承链可以得到下面的关系图：

AnonymousObservable

 AnonymousObservable是接受Element泛型的继承自Producer的类，他接受并保存一个闭包subscribeHandler的参数，这个其实就是上面我们说的闭包A，另外有一个run函数（后面会提到）

Producer

 Producer是接受Element泛型的继承自Observable的类，有一个subscribe的实现，run的抽象方法，这个subscribe非常重要

Observable

 Observable是接受Element泛型的实现ObservableType协议的类，有一个subscribe的抽象方法，asObservable的实现（返回self，统一万物皆序列）
同时Observable有统计引用计数的能力（Resources这个结构体在序列，观察者，销毁者等都用到，可以调试是否有内存泄露），其中的AtomicInt是一把NSLock的锁，保证数据的存取安全

ObservableType

ObservableType是拓展ObservableConvertibleType协议的协议，定义了subscribe协议方法，实现了asObservable()方法，所以这里我们得出结论，不一定要继承Observable的才是序列，只要是实现了ObservableType的subscribe的协议方法的也可以算是序列，进一步佐证万物接序列

ObservableConvertibleType

ObservableConvertibleType是个协议，关联了Element类型，定义asObservable的协议方法

订阅序列

点击subscribe函数

它是ObservableType的拓展能力，创建了一个AnonymousObserver（匿名观察者）
，接受的Element仔细查看继承链代码会发现跟序列创建的泛型是同一个

分析AnonymousObserver的继承链我们可以得到下图：

AnonymousObserver

 AnonymousObserver是接受Element泛型的继承自ObserverBase的类
保存了一个eventHandler的闭包，这个我们定义是闭包C
同时也有统计引用计数的能力，有一个onCore的实现

ObserverBase

ObserverBase是接受Element泛型的实现Disposable和ObserverType两个协议的类，有一个on的实现，onCore的抽象方法

ObserverType

ObserverType关联了Element，定义了on的协议方法，拓展定义了onNext，onCompleted，onError的方法，这三个方法其实都是on一个Event

其中Event是个枚举，有三类事件：next事件、error事件和completed事件。

• next事件：next事件携带了一个值，表示数据的更新或新的事件。
• error事件：error事件表示发生了一个错误，中断了事件的正常流程。
• completed事件：completed事件表示事件流的结束，不再有新的事件产生。 观察者通过订阅可观察序列来接收事件。

Disposable

Disposable这个协议比较简单，定义了dispose方法

订阅流程分析

• 1.调用self.asObservable().subscribe(observer)

  • 这个self是AnonymousObservable的实例
  • 调用asObservable方法通过继承链最终调用Observable的实现，返回self,也就还是AnonymousObservable的实例

• 2.调用AnonymousObservable的实例的subscribe方法，通过继承链调用Producer的subscribe方法

• 3.Producer的run方法在AnonymousObservable有实现

 这个sink的处理是相当不错的，很好的做到了业务下沉，同时很好的运用了中间件和单一职责的设计模式，值得学习。

sink是管道的意思，下水道，什么东西都会往里面丢，这里面有订阅者，销毁者等

• 4. sink.run
• 5. parent.subscribeHandler(AnyObserver(self))这里的parent就是AnonymousObservable的实例，调用subscribeHandler这个也就是我们定义的闭包A 这里解释了订阅的时候会来到我们的闭包A的原因。 这里需要注意到AnyObserver这个类，他里面保存的observer属性其实是AnonymousObservableSink.on函数

发送信号

有了上两步的基础我们分析发送信号的流程应该比较清晰了

• 1. obserber.onNext 其实就是AnyObserver.onNext
• 2. ObserverType.onNext其实就是ObserverType.on
• 3. 其实就是AnyObserver.on

• 4.这个observer就是上面第二步最后的AnonymousObservableSink.on函数

• 5.父类Sink.forwardOn函数 这里的self.observer类型是 AnonymousObserver

• 6.调用AnonymousObserver的父类ObserverBase的on方法

• 7.调用AnonymousObserver的onCore方法

• 8.调用eventHandler，也就是我们定义的闭包C
• 9.闭包C根据Event调用闭包B，闭包B输出了控制台的结果，至此，整个链路执行完毕了。

把整个核心流程用思维导图描述出来：

总结

SwiftData 用于在声明式UI开发(SwiftUI)中进行数据持久化。您可以使用 Swift 代码查询和过滤数据了。

创建模型

使用带有@Model的普通 Swift 类型对数据进行建模，无需关心底层文件存储。

SwiftData 自动推断关系(relationships)，您可以使用清晰的声明比如@Attribute(.unique)来描述属性约束。

@Model

class Recipe {

	@Attribute(.unique) var name: String // 在相同类型的所有模型中属性的值是唯一的。

	var summary: String?

	var ingredients: [Ingredient]

}

自动持久性

SwiftData 使用Model(模型)构建自定义schema，并将其字段有效地映射到底层存储。

由 SwiftData 管理的对象在需要时从数据库中获取，并在适当的时候自动保存，您无需进行额外的工作。

您还可以使用 ModelContext API 进行完全控制。

与 SwiftUI 集成

在 SwiftUI views中使用@Query来获取数据。SwiftData 和 SwiftUI 协同工作，在基础数据更改时提供视图的实时更新，无需手动刷新。

@Query var recipes: [Recipe] // 获取一组模型并使模型与底层数据保持同步的property wrapper(属性包装器)。



var body: some View {

	List(recipes) { recipe in

		NavigationLink(recipe.name, destination: RecipeView(recipe))

	}

}

Swift-native predicates

无需使用复杂 SQL, 使用表达式(编译器自动类型检查)来查询和筛选数据，以便在开发过程中捕获拼写错误。

当表达式无法映射到基础存储引擎时，谓词会提供编译时错误。

let simpleFood = #Predicate<Recipe> { recipe in

	recipe.ingredients.count < 3

}

CloudKit同步

您的数据可以使用DocumentGroup储存在文件中并通过 iCloud Drive 同步到云端,，也可以使用 CloudKit 在设备之间同步数据。

与Core Data兼容

SwiftData 使用经过验证的 Core Data 存储架构，因此您可以在具有相同底层存储的同一App中使用两者。

Xcode 将 Core Data Models转换为类以与 SwiftData 一起使用。

一、前言

非公开分发是苹果新推出的一种分发方式，适用于为有限范围用户开发、不适合在App Store上公开分发的App，比如一些没有注册功能，由公司下发账号密码的企业内部应用。

苹果官方对非公开App分发的描述：
developer.apple.com/cn/support/…

二、苹果分发方式对比

三、非公开分发

作为苹果新推出的分发方式，非公开分发有如下特点：

1. 要为非公开分发的App申请非公开App链接
2. 用个人或公司开发者账号在App Store发布，但是不能直接在App Store搜到，只能通过短链接被访问
3. 由于要上架App Store，和普通app一样，要提交到苹果审核，审核通过之后可访问
4. 已经在App Store中公开上架的app可以申请非公开App链接，转为非公开分发App
5. 非公开分发App的销售范围是App Store支持的所有区域

四、分发非公开App

创建App并提交审核

1. 按照公开分发的方式创建App并填写信息

2. 初始创建App提交审核时，App分发方式选择公开，非公开App链接申请通过后App分发方式会自动转为非公开分发 image.png

3. 审核信息备注里说明App用于非公开分发

4. App提交审核

申请非公开App链接

非公开App链接的申请地址如下：
developer.apple.com/contact/req…

提交非公开分发请求时需要满足以下两点：

1. App已经提交至苹果进行审核或者已经上架，不能为处于Beta版本的App提交非公开请求，否则会被拒
2. 如果使用的是公司开发者账号，只有主账号有提交非公开请求的权限，使用子账号申请时页面打不开，错误信息如下：

非公开链接申请通过后开发者账号邮箱会收到一封通知邮件：

App的分发方式也会自动的变成非公开分发：

如果非公开App链接申请下来之前App审核因为3.2被拒，不用着急，等非公开链接申请通过之后再次提交即可。

非公开App链接申请页信息是英文，输入填写相关信息时用中、英文都可以，问题描述的越详细审核越容易过，我第一次提交后几个小时就过了。

最后

随着苹果公司对企业账号的收紧，2022年不少公司在续费时遇到了账号重新审查，万一审查不过，结果就是账号不能续费无法继续使用，之前通过企业账号分发的App必须考虑别的分发方式。

苹果官方给的建议是Apple 商务管理和非公开 App 分发两种方案，相对于商务管理下载时需要管理兑换码,下载更方便的非公开App分发不失为一种新尝试。

前言：

各位同学大家， 有段时间没有跟大家见面了。 相信很多做IOS手游sdk 的同学 都会用到静态库， 我们不用把我们都源代码都发给对接方 就可以把我们的逻辑跟研发都代码融合在一起

具体实现：

第一步 点击file 

 第二步创建一个project 

 第三步我们选择 static Library 工程

最终我们这样的一个工程

 在xcode 最新版本里面 有的同学 发现没有 Prodoucts 这个目录 这个是因为xcode的bug

mainGroup = 0D7441EC2A0A715000C95252;

productRefGroup = 0D7441EC2A0A715000C95252;

保证这2行后面都配置一样的如果不一样 就复制 mainGroup 后面到productRefGroup 然后保存即可 然后刷新xcode 就就会出现 Prodoucts

暴露头文件 我们需要把我们对外开放都类的头文件 也就是.h文件 暴露出去 然后方便对接方 接入

 如图我们将我们ninefunsdk.h这个文件

 还有我们都 Roleinfo.h 和Seriveinfo. h 文件也需要暴露出去

 打包 cmd +b 

具体接入

效果图

最后总结:

IOS 打包静态库 我们就讲完， 比较简单 我们只需要对流程清除即可 有兴趣同学可以根据教程一步一步学习

最后呢 希望我都文章能帮助到各位同学工作和学习 如果你觉得文章还不错麻烦给我三连 关注点赞和转发 谢谢

为什么要使用多个 Xcode？

有些时候，我们可能需要多个版本的 Xcode，比如：

情景1:
每年的6月 WWDC 大会发布后，都伴随着 iOS 系统的更新，当你想体验下新的功能的时候，你想下载 Xcode 的 Beta 版本尝试适配新版本的变化，但是又不想覆盖原有的 Release 版本。

情景2:
你们公司的项目复杂又庞大，你担心更新 Xcode 后，项目运行报错，不得不回退旧版本的 Xcode。

像上面两种情况，我们就希望多个版本的 Xcode 同时存在，既能体验新版本的功能变化，也能确保我们项目在原有版本正常运行。

Xcodes - 轻松管理多个 Xcode

给大家推荐一款轻松管理 Xcode 的一个工具包 Xcodes，它的下载地址在 GitHub 上，点我直达 。

Xcodes 优点

• 简洁的桌面，可快速发现想要安装的版本。
• 安装包很小，只有 23MB 左右。
• 下载速度快，使用了 aria2 下载工具，比 URLSession 快 3-5 倍。
• 如果网络错误，可自动恢复安装。
• 可选择默认 Xcode。

由于我不知道 aria2 是什么，所以 chatGPT 了一下 😁，下面是 chatGPT 给出的答案

aria2是一款开源的多协议、多线程下载工具，可以用来在命令行界面下载文件。它支持HTTP、HTTPS、FTP、BitTorrent等多种协议，可以同时下载多个文件，并自动利用多个连接和线程来加快下载速度。aria2在Linux、Windows和macOS等多个操作系统上都可用，并且可以通过命令行进行控制和配置。

下载安装

XcodesApp 的 README.md 也有说明可以使用 两种安装方式。

安装方式 1: 借助Homebrew安装

brew install --cask xcodes

安装方式 2: 手动安装 （我是手动安装的）

README.md 里找如上图：滚动到 Manually install(手动安装)这里，点击here 蓝色高亮的地方，会进入 release 下载链接，然后滚动到页面底部，看见下图 Xcodes.zip 点击下载，安装到 /Applications下即可。

使用教程

安装完成后，打开 Xcodes 的页面，非常简洁，能看到目前可安装的最新的 Beta 版本，以及最开始的1.0版本，看见这个觉得很酷 👻

使用 Xcodes 需要登录 Apple ID，以及怎么使用，都用图片说明吧，稍微摸索一下都能看明白，使用起来非常简单。

感谢阅读，如果您感觉这篇文章对您有帮助的话，请给它点赞以鼓励我持续创作 ^‿^

前言

在iOS的日常开发中，特别是设计网络请求时，会用到加密算法，例如在客户端需要发起一个HTTP请求给服务端，其中会传递一些参数，为了防止参数在网络传输过程中被窃取或者篡改，我们就需要使用一些加密算法来对请求参数加密和签名。今天就重点介绍一下AES和HMAC_SHA256两个算法，因为服务端大多数都是使用java语言来编写，AES算法在iOS的Objective-C中和java的实现有些差异，本文重点介绍AES在iOS开发中的应用和需要注意的事项。

AES 加密算法简介

AES是一种典型的对称加密/解密算法，使用加密函数和密钥来完成对明文的加密，然后使用相同的密钥和对应的函数来完成解密。AES的优点在于效率非常高，相比RSA要高得多。AES共有ECB、CBC、CFB和OFB四种加密模式。

在iOS中的实现

Objective-C中支持AES的ECB和CBC两种模式。
1、电码本模式（Electronic Codebook Book (ECB)）
这种模式主要是将明文划分为几个明文段，分块加密，但是加密密钥是相同的。
2、密码分组链接模式（Cipher Block Chaining (CBC)）
这种模式是先将明文切分成若干小段，然后每一小段与初始块或者上一段的密文段进行异或运算后，再与密钥进行加密。

ECB是最简单的一种模式，只需要传入待加密的内容和加密的key即可。（一般不推荐ECB模式）
CBC的特点是，除了需要传入加密的内容和加密的key，还需要传入初始化向量iv。即使每次加密的内容和加密的key相同，只要调整iv就可以让最终生成的密文不同。
在客户端和服务端之间传输数据一般是使用约定好的key对指定参数做AES的CBC加密，初始化向量可以随机动态生成，最终将生成好的密文和随机向量iv拼接在一起传给服务端。如：iv+密文。
iv是指定的长度如16位，这样服务端拿到客户端传输过来的数据可以先取前16位作为iv，剩余的是需要解析的密文。这么做大大提升了数据的安全性和破解难度。即使相同的带加密参数，因为有随机向量的参入，最终生成的密文也不相同。

iOS中一般使用#import <CommonCrypto/CommonCryptor.h>库中的这个函数：

CCCryptorStatus CCCrypt(

    CCOperation op,         /* kCCEncrypt, etc. */

    CCAlgorithm alg,        /* kCCAlgorithmAES128, etc. */

    CCOptions options,      /* kCCOptionPKCS7Padding, etc. */

    const void *key,

    size_t keyLength,

    const void *iv,         /* optional initialization vector */

    const void *dataIn,     /* optional per op and alg */

    size_t dataInLength,

    void *dataOut,          /* data RETURNED here */

    size_t dataOutAvailable,

    size_t *dataOutMoved)

    API_AVAILABLE(macos(10.4), ios(2.0));

• CCOperation：kCCEncrypt 加密，kCCDecrypt 解密

enum {

    kCCEncrypt = 0,

    kCCDecrypt,

};

typedef uint32_t CCOperation;

• CCAlgorithm：加密算法、默认为AES

enum {

    kCCAlgorithmAES128 = 0, /* Deprecated, name phased out due to ambiguity with key size */

    kCCAlgorithmAES = 0,

    kCCAlgorithmDES,

    kCCAlgorithm3DES,

    kCCAlgorithmCAST,

    kCCAlgorithmRC4,

    kCCAlgorithmRC2,

    kCCAlgorithmBlowfish

};

typedef uint32_t CCAlgorithm;

enum {

    /* options for block ciphers */

    kCCOptionPKCS7Padding   = 0x0001,

    kCCOptionECBMode        = 0x0002

    /* stream ciphers currently have no options */

};

typedef uint32_t CCOptions;

• key：密钥
• keyLength：密钥长度
• iv：iv 初始化向量，ECB 不需要。iv定长所以不需要长度（8字节）。
• dataIn：加密/解密的数据
• dataInLength：加密/解密的数据长度
• dataOut：缓冲区（地址），存放密文/明文
• dataOutAvailable：缓冲区大小
• dataOutMoved：加密/解密结果大小

封装如下：

/**

     *  解密字符串

     *

     *  @param string    加密并base64编码后的字符串

     *  @param keyString 解密密钥

     *  @param iv        初始化向量(8个字节)

     *

     *  @return 返回解密后的字符串

     */

- (NSString *)decryptString:(NSString *)string keyString:(NSString *)keyString iv:(NSData *)iv {

    

    // 设置秘钥

    NSData *keyData = [keyString dataUsingEncoding:NSUTF8StringEncoding];

    uint8_t cKey[self.keySize];

    bzero(cKey, sizeof(cKey));

    [keyData getBytes:cKey length:self.keySize];

    

    // 设置iv

    uint8_t cIv[self.blockSize];

    bzero(cIv, self.blockSize);

    int option = 0;

    if (iv) {

        [iv getBytes:cIv length:self.blockSize];

        option = kCCOptionPKCS7Padding;//CBC 加密！

    } else {

        option = kCCOptionPKCS7Padding | kCCOptionECBMode;//ECB加密！

    }

    

    // 设置输出缓冲区

    NSData *data = [[NSData alloc] initWithBase64EncodedString:string options:0];

    size_t bufferSize = [data length] + self.blockSize;

    void *buffer = malloc(bufferSize);

    

    // 开始解密

    size_t decryptedSize = 0;



    CCCryptorStatus cryptStatus = CCCrypt(kCCDecrypt,

                                          self.algorithm,

                                          option,

                                          cKey,

                                          self.keySize,

                                          cIv,

                                          [data bytes],

                                          [data length],

                                          buffer,

                                          bufferSize,

                                          &decryptedSize);

    

    NSData *result = nil;

    if (cryptStatus == kCCSuccess) {

        result = [NSData dataWithBytesNoCopy:buffer length:decryptedSize];

    } else {

        free(buffer);

        NSLog(@"[错误] 解密失败|状态编码: %d", cryptStatus);

    }

    

    return [[NSString alloc] initWithData:result encoding:NSUTF8StringEncoding];

}

上文提到使用CBC模式，可以创建一个随机的iv：

#import <Foundation/Foundation.h>

#import <CommonCrypto/CommonCryptor.h>



NSData *generateRandomIV(size_t length) {

    NSMutableData *randomIV = [NSMutableData dataWithLength:length];

    int result = SecRandomCopyBytes(kSecRandomDefault, length, randomIV.mutableBytes);

    

    if (result == errSecSuccess) {

        return randomIV;

    } else {

        // 处理生成随机IV失败的情况

        return nil;

    }

}



int main(int argc, const char * argv[]) {

    @autoreleasepool {

        // 设置AES加密参数

        NSData *key = [@"YourAESKey123456" dataUsingEncoding:NSUTF8StringEncoding];

        size_t ivLength = kCCBlockSizeAES128; // IV长度为16字节（AES-128）

        

        // 生成随机IV

        NSData *randomIV = generateRandomIV(ivLength);

        

        if (randomIV) {

            // 使用randomIV进行AES加密

            // 这里你可以调用相应的加密方法，传入randomIV作为IV参数

            // 例如，使用CommonCrypto库进行AES加密

            // 具体实现将取决于你所使用的加密库和算法

            

            // 示例：在这里调用AES加密函数，传入key和randomIV

            // ...

        } else {

            NSLog(@"生成随机IV失败");

        }

    }

    return 0;

}

前言

趁着版本空隙，升级到了Xcode15-Beta2本想提前体验下iOS17。本以为这次升级Xcode能直接运行应该没什么大问题，没曾想到一运行后程序直接Crash了，Crash是在YYLabel下的YYAsyncLayer类里面。众所周知，YYLabel是由远古大神ibireme开发的YYKit下属的组件。已经多年没有适配了，但是依然老当益壮，只有部份由于Api变更导致的问题需要简单维护即可。以下就是此次问题定位与修复的全过程。

Crash定位

此次升级后编译我司项目，直接Crash,Crash日志如下。

Crash是在YYTextAsyncLayer类下面的第193行代码如下：

UIGraphicsBeginImageContextWithOptions(self.bounds.size, self.opaque, self.contentsScale);

其实第一眼看代码崩溃提示就很明显了，这次Xcode15在UIGraphicsBeginImageContextWithOptions下面加了断言，如果传入的size width 或者 height其中一个为0，会直接return 返回断言。并且提示我们升级Api为UIGraphicsImageRenderer可以解决此问题。

本着探究的精神，我重新撤回用Xcode14.3.1编译，看为什么不会崩溃，结果其实也会报Invalid size警告但是不会崩溃，警告如下。

解决方案

我们使用UIGraphicsImageRenderer替代老旧的UIGraphicsBeginImageContextWithOptions（其实早已标记为过时），实测即使size为 zero，UIGraphicsImageRenderer在Xcode15下依然会渲染出一个zero size的Image，但是这毫无意义，所以我们简单判断一下，如果是非法的size我们直接retrun，代码如下：

从193行开始一直替换到self.contents = xxx。为止，即可解决此次问题。

if (self.bounds.size.width < 1 || self.bounds.size.height < 1) {



CGImageRef image = (__bridge_retained CGImageRef)(self.contents);



self.contents = nil;



if (image) {



CFRelease(image);



}



return;



}



UIGraphicsImageRenderer *renderer = [[UIGraphicsImageRenderer alloc] initWithSize:self.bounds.size];



UIImage *image = [renderer imageWithActions:^(UIGraphicsImageRendererContext *context) {



if (self.opaque) {



if (!self.backgroundColor || CGColorGetAlpha(self.backgroundColor) < 1) {



CGContextSetFillColorWithColor(context.CGContext, [UIColor whiteColor].CGColor);



[context fillRect:self.bounds];



}



if (self.backgroundColor) {



CGContextSetFillColorWithColor(context.CGContext, self.backgroundColor);



[context fillRect:self.bounds];



}



}



task.display(context.CGContext, self.bounds.size, ^{return NO;});



}];



self.contents = (__bridge id)(image.CGImage);

结尾

以上就是Xcode15修复UIGraphicsBeginImageContextWithOptions由于加了断言导致的Crash问题。我也强烈建议各位有时间检查项目其他代码直接升级成UIGraphicsImageRenderer的方案。如果确实没时间，要加上如下判断，防止Crash。由于我是在Debug上必崩，如果是断言问题Release不一定会有事，但是还是建议大家修改一下。

if (self.size.width < 1 || self.size.height < 1) {



return nil;



}

免责声明：理论上而言，用这招类推可以建置给早期版本的 iOS。但实际上管不管用我就没法保证了，因为我不是 iOS 程式师。

本文专门给那些需要在新版本系统当中用新版本 Xcode 将祖产专案建置给早期系统版本的资工业者们。

Xcode 15 需要打 libarclite 才能给早于 macOS 10.13 的系统建置应用程式。

通用做法就是从 Xcode 14.2 或 Xcode 13 当中提取出 libarclite 套装，然后植入到 Xcode 15 当中。先开启 toolchains 资料夹：

再把 libarclite 的东西放进去（也就是 arc 这个资料夹）：

然而，如果是 macOS 10.9 的话，事情还要复杂一个层次：

macOS 14 Sonoma 开始的 SDK 几乎把整个 Foundation 当中的很多基础类型都重写了。这就导致之前那些被 Swift 从 Objective-C 借走的基础类型全部都得重新打上「NS」开头的后缀才可以直接使用。但这还有一个问题：NSLocalizedString 的建构子不能使用了，因为这玩意在 macOS 14 当中也是被（用纯 Swift）彻底重构的基础类型之一。Apple 毫不留情地给这些基础类型都下了全局的「@available(macOS 10.10, *)」的宣告： 

这样一来，除了 libarclite 以外，还需要旧版 macOS SDK 才可以。虽然 macOS 13 Ventura 的 SDK 也可以凑合用，但（保险起见）笔者推荐 macOS 12 Monterey 的 SDK：Release macOS 12.3 SDK · alexey-lysiuk/macos-sdk (github.com)。该 SDK 的安置位置：

再修改一下 Xcode 专案当中对 macOS SDK 的指定（不用理会 not found）：

这样应该就可以正常组建了。如果有提示说 Date 不符合最新版本要求的话，把 Date 改成 NSDate 即可。

$ EOF.

苹果在 WWDC2020 上发布了 App Clip，有媒体叫做“苹果小程序”。虽然 Clip 在产品理念上和小程序有相似之处，但是在技术实现层面却是截然不同的东西。本文会针对 Clip 的技术层面做全面的介绍。

实现方式：native 代码、native 框架、native app 一样的分发

在实现上，Clip 和原生的 app 使用一样的方式。在 UI 框架上同时支持 UIKit 和 SwiftUI，有些开发者认为只能使用 SwiftUI 开发，这点是错误的。Clip 的定位和 watch app、app extension 类似，和 app 在同一个 project 里，是一个单独的 target。只是 Clip 并没有自己的专属 framework（其实有一个，但是主要包含的是一些特色 api），使用的框架和 app 一致，可以认为是一个精简版的原生 App。

Clip 不能单独发布，必须关联一个 app。因此发布的流程和 app 和一样的，在 apple connect 上创建一个版本，和 app 一起提交审核。和 app 在技术上的最大区别只是大小限制在 10MB 以内，因为 Clip 的基础就是希望用户可以最迅速的被用户使用，如果体积大了就失去了产品的根本。

产品定位：用完即走

苹果对 Clip 的使用场景非常明确：在一个特定的情境里，用户可以快速的使用 app 的核心服务。是小程序内味了！

坦率的说，很难说 Clip 的理念是苹果原创的，在产品的定位上和微信小程序如出一辙。尤其是微信小程序在国内已经完全普及了，微信小程序初始发布的时候也被苹果加了多条限制。其中一条就是小程序不能有虚拟商品支付功能。现在回头看苹果自己的 Clip 可以完美支持 apple pay，很难说苹果没有私心。

触手可及

Clip 使用一段 URL 标识自己，格式遵从 universal link。因为苹果对 Clip 的使用场景非常明确，所以在 Clip 的调起方式做了严格限制。Clip 的调用只能是用户主动要发起才能访问，所以不存在用户在某个 app 里不小心点了一个按钮，就跳转下载了 Clip。

Clip 的发起入口有以下几种：

• NFC
• 二维码
• Safari 中关联了 Clip 的网页
• 苹果消息应用
• Siri 附近建议和苹果地图

NFC 和二维码的入口很容易理解，必须用户主动拿出手机靠近 NFC、打开相机扫描。苹果专属的 Clip 码生成工具在年底才会开放。

Safari 中发起和之前的 universal link 类似，在网站配置了关联的 Clip 信息后，会有一个 banner 提示打开应用。

因为 Clip 提交 app store 审核的信息里也会配置好相关的 url，因此如果在 message 里发了 clip 的链接，操作系统也会在应用里生成一个 Clip 的卡片，用户如果需要可以主动点击。

Siri 附近建议和苹果地图（在 connect 中可以配置 clip 的地理位置）。场景和前面的二维码类似，如果我在地图上看到一个商家，商家有提供服务的 Clip，我可以在地图或者 Siri 建议里直接打开 Clip。

再次总结一下 Clip 的入口限制：只能是用户主动发起才能访问。虽然 Clip 的入口是一段 universal link，在代码里的处理方式也和 universal link 一致，但是为了 Clip 不被滥用，Clip 的调起只能是操作系统调起。App 没有能力主动调起一个 Clip 程序。

无需安装、卸载

因为 Clip 的大小被限制在了 10MB 以下，在当下的网络状态下，可以实现快速的打开。为了给用户使用非常轻松的感觉，在 UI 上不会体现“安装”这样的字眼，而是直接“打开”。预期的场景下用户打开 Clip 和打开一个网页类似。因此在用户的视角里就不存在软件的安装、卸载。

Clip 的生命周期由操作系统全权接管。如果 Clip 用户一段时间后没有使用，操作系统就会自动清除掉 Clip，Clip 里存储的数据也会被一并清除。因此虽然 Clip 提供了存储的能力，但是程序不应该依赖存储的数据，只能把存储当做 cache 来使用，操作系统可能自动清除缓存的数据。

横向比较：PWA、Instant Apps、小程序

Instant Apps

18 年正式发布的 Android Instant apps 和 Clip 在技术上是最接近的。Instant apps 中文被翻成“免安装应用”，在体验上也是希望用户能够最低成本的使用上 app，让用户感受不到安装这个步骤。Instant apps 也可以通过 url 标识（deep link），如果在 chrome 里搜索到应用的网站，chrome 如果识别到域名下有关联应用，可以直接“打开”。消息中的链接也可以被识别。只是 Instant apps 发布的早，国外用户也没有使用二维码的习惯，所以入口上不支持二维码、NFC。

两者的根本区别还是在定位上，Instant apps 提出的场景是提供一个 app 的试用版。因此场景是你已经到了 app 的下载页面，这个时候如果一个 app 几百兆你可能就放弃下载了，但是有一个极简的试用版，就会提高你使用 app 的可能。这个场景在游戏 app 里尤其明显，一方面高质量的游戏 app 体积比较大。另一方面，如果是一个付费下载的应用，如果有一个免费的试用版，也可以增加用户的下载可能。在苹果生态里很多应用会提供一个受限的免费 lite 版本也是一样的需求。

但是 Instant apps 在国内没有产生任何影响。因为政策的原因，Google Play 不支持在国内市场使用。国内的安卓应用市场也是鱼龙混杂，对于 Instant apps 也估计也没有统一支持。另外国内的安卓生态也和欧美地区区别比较大，早期安卓市场上收费的应用很少，对于用户而言需要试用免费 app 的场景很少。另外大厂也可能会推出专门的急速版应用，安装后利用动态化技术下发代码，应用体积也可以控制在 10 MB 以内。

Clip 则是非常明确的面向线下提供服务的场景，在应用能力上可以接入 sign in with apple，apple pay。这样一个全新的用户，可以很快速的使用线下服务并且进行注册、支付。用户体验会好的多。安卓因为国内生态的原因，各个安卓厂商没有统一的新用户可以快速注册的接口，也没有统一的支付接口，很难提供相匹敌的体验。如果开发者针对各个厂商单独开发，那成本上就不是“小程序”了。

Progressive Web App(PWA)

Progressive Web App 是基于 web 的技术。在移动互联网兴起之后，大家的流量都转移到了移动设备上。然而在移动上的 web 体验并不好。于是 W3C 和谷歌就基于浏览器的能力，制定了一套协议，让 web app 可以拥有更多的 native 能力。

PWA 不是特指某一项技术，而是应用了多项技术的 Web App。其核心技术包括 App Manifest、Service Worker、Web Push。

PWA 相当于把小程序里的代码直接下载到了本地，有了独立的 app 入口。运行的时候基于浏览器的能力。但是对于用户感受和原生 app 一样。

我个人对 PWA 技术很有好感，它的初衷有着初代互联网般的美好。希望底层有一套协议后，用户体验还是没有边界的互联网。然而时代已经变了。PWA 在中国基本上是凉了。

PWA 从出生就带了硬伤，虽然谷歌希望有一套 web 标准可以运行在移动设备上，但是对于苹果的商业策略而言，这并不重要。因此 PWA 的一个协议，从制定出来，再到移动设备（iOS）上支持这个特性，几年就过去了。而且对于移动用户而言，可以拥有一个美好的 web app 并不是他们的痛点。

总结起来 PWA 看着美好，但似乎更多是对于 web 开发者心中的美好愿景。在落实中遇到了很多现实的问题，技术支持的不好，开发者就更没有动力在这个技术上做软件生态了。

微信小程序

前面提过在产品理念上小程序和 Clip 很相似，甚至说不定 Clip 是受了小程序的启发。在市场上，小程序是 Clip 的真正对手。

小程序基于微信的 app，Clip 基于操作系统，因此在能力上 Clip 有优势。小程序的入口需要先打开微信，而 Clip 可以通过 NFC 靠近直接激活应用。对于开发者而言，Clip 可以直接获得很多原生的能力（比如 push），如果用户喜欢可以关联下载自己的原生应用。在小程序中，微信出于商业原因开发者不能直接跳转到自有 app，小程序的能力也依赖于微信提供的接口。

对于从 Clip 关联主 app 苹果还挺重视的，提供了几个入口展示关联 app。

首先在 clip 的展示页就会显示：

每次使用 Clip 时也会有一个短暂的浮层展示：

开发者也可以自己通过 SKOverlay 来展示：

不过如果开发者没有自己的独立 app，那么也就只能选择小程序了。小程序发展到现在场景也比最早提出的线下服务更加多了，反而类似 Instant apps，更像一个轻量级的 app。

考虑到国内很多小程序的厂商都没有自己的独立 app，因此 clip 对于这部分群体也并没有什么吸引力。不过对于线下服务类，尤其有支付场景的，Clip 在用户体验上会比小程序好一些。

总结，Clip 的业务场景和小程序有一小部分是重叠的，小程序覆盖的场景还是更多一些。两者在大部分时候并不是互斥式的竞争关系，即便在一些场景下 Clip 有技术优势，商家也不会放弃小程序，因为还有安卓用户嘛。还是看商家在某些场景里，是否愿意为用户多提供一种更好的交互方式。

对比原生 app 的技术限制

虽然 Clip 可以直接使用 iOS framework，但是因为 Clip 的使用场景是新用户的初次、简短、当下（in-the-moment experience）的使用，相比原生 app 苹果还是进行了一些限制。

App 不能访问用户的隐私信息：

• 运动和健身数据
• Apple Music 和多媒体文件
• 通讯录、信息、照片、文件等数据

不过为了能够提供给用户更加轻便的体验，通过专门为 Clip 设计了免申请的通知、定位权限。不过也有限制：免申请的通知只在 8 个小时内有效。位置只能获取一次。如果 app 需要重度使用这两类权限就还是和原来一样，可以弹窗申请。

某些高级应用能力也会受限，需要在完整的应用中才能使用：

• 不能请求追踪授权
• 不能进行后台请求任务
• 没在激活状态蓝牙连接会断开

总的而言虽然有一些限制，但是这些限制的出发点是希望开发者关注 Clip 的正确使用场景。对于 Clip 所提倡的使用场景里，苹果提供的能力是完全够用的。

一些技术细节

可以建立一个共享 targets 的 Asset catalog 来共用图片资源。

在 Clip 中申请的授权，在下载完整应用后会被同步到应用中。

通过 App Group Container 来共享 clip 和 app 的数据。

image

Clip 的 url 可以配置参数：

在 App Store connect 中还可以针对指定的参数配置不一样的标题和图片。比如一家连锁咖啡店，可能不同的店你希望弹出的标题图片是不一样的，可以进行单独的配置。

总结

苹果给定义的 Clip 的关键词是：lightweight、native、fast、focused、in-the-moment experience。

Clip 在特定的线下场景里有着相当好的用户体验。对于已经拥有独立 app 的公司来说，开发一个 clip 应用的成本并不高。我个人还是期待这样一个好的技术可以被更多开发者接纳，可以提供给用户更好的体验。对于小程序，clip 的场景窄的多，两者并不是直接竞争关系。我更愿意看做是特定场景下，对于小程序原生能力不足的一种补充。

前言

公司有个项目一直是用 OC 进行开发，现在想改成 Swift 来开发。那先说一下为什么有这样的想法，我们都知道 Swift 代码更简单，易维护，安全而且快，网络上也是很多描述，那我们主要的是担心一旦变成混编工程，会不会出现很多问题，还有如何解决这些问题。性能问题方面Swift 和 OC 共用一套运行时环境，而且支持 Swift 桥接 到 OC上，所以呢，问题不大。如果有不同的想法，也欢迎留意指教。

桥接文件

我们只要在 OC 项目中，创建一个 swift 文件，系统就会弹出桥接文件，我们点击 "Create Bridging Header"即可。

OC 工程接入 Swift

OC 类 引用 Swift 类

如上面我们创建了一个 swift 文件，里面写一些方法提供给 OC 使用。

@objcMembers class SwiftText: NSObject {



    func sayhello() -> String{



        return "hello world"



    }

}



class SwiftText2: NSObject {



    @objc func sayhello() ->String{



        returnOCAPI.sayOC()

        

    }

}

这里我们有关键字2个，1个是@objcMembers,表示所有方法属性都可以提供给 OC 使用。另外一个是@objc，表示修饰的方法属性才可以提供给OC使用。

那我们 OC 类怎么用这个 swift 文件呢。
先在我们该类添加头文件

#import "项目Target-Swift.h"

然后我们点进去看下。

可以看到我们写的 swift 文件类，方法，属性，都被转化为 OC 了，有了这个我们直接使用即可。

OC类 使用 swift Pod库

说实话，这种用的比较少，但有时候我们真的觉得 swift Pod库 会更好用，那我们怎么去处理呢？

首先我们要搞懂一点，有些是支持使用的，如PromiseKit，有些是不支持使用的如Kingfisher。

先说第一种支持使用的，我们直接导入#import <PromiseKit/PromiseKit.h>即可。

那要是第二种的话，我们还有一种办法，就是先用 swift 写一个该库管理类，然后里面引用我们该库的内容，我们通过 @objc 来提供给我们 OC 使用。

Swift类 引用 OC 类

如果我们编写的 Swift 类，想要用到 我们 OC 的方法，那我们如何处理呢？

我们直接在桥接文件"Target-Bridging-Header.h"里面，直接导入头文件#import "XXX.h"即可使用。

Swift类 使用 OC pod库

其实这个更简单，和 Swift 工程引入 OC pod库一样，在该类里面导入头文件即可。

import MJRefresh

遇到问题

问题1：引入swift pod库 问题

如果我们 OC 项目 是没有 使用use_frameworks!。那我们导入swift Pod库 就会报错。

那我们就在工程配置里面 Build Settings里面，搜索 Defines Module, 更改为 YES 即可。

问题2：OC 类继承问题

OC的类是不能继承至Swift的类，但Swift 类是可以继承 OC类的，其实方式也是"Target-Bridging-Header.h"导入头文件即可。

问题3：宏定义问题

我们自己重新一份
原来的是

#define kScreenWidth        [UIScreen mainScreen].bounds.size.width                      

#define kScreenHeight       [UIScreen mainScreen].bounds.size.height

现在的是

let kScreenWidth = UIScreen.main.bounds.width

let kScreenHeight = UIScreen.main.bounds.height

有一些，我们可以定义问方法来替代宏。

问题4：OC经常调用swift库导入问题

我们知道xxx-Swift.h都是包含所有swift 提供给 OC 使用的类，所以我们可以把xxx-Swift.h放到 pch 文件里面，就可以在任意一个 OC 工程文件直接调用 swift 类。

OC 在线转为 swift

提供一个链接，可以支持 OC 转为 swift。
在线链接

最后

经过上面的总结，OC 项目 使用 swift 开发 的确是问题不大，使用过程中可能也会遇到编译问题，找不到文件问题，只要细心排查，也是很容易解决，那等后续项目用上正轨，还会把遇到的坑填补上来，如有不足，欢迎指点。

NFC 是 Near Field Communication 的缩写，即近场通信，是一种用于短距离无线设备与其他设备共享数据或触发这些设备上的操作的技术。它使用射频场构建，允许没有任何电源的设备存储小块数据，同时还允许其他供电设备读取该数据。

iOS 和 watchOS 设备内置 NFC 硬件已经很多年了。在现实生活中，Apple Pay 就是使用这项技术与商店的支付终端进行交互。然而直到 iOS 11 开发者才能够使用 NFC 硬件。后来 Apple 在 iOS 13 系统中提升了 CoreNFC 的功能，开发者可以借助这项新技术，对 iOS 设备进行编程，使其以新的方式与周围的互联世界进行交互。

说明：本文提供的代码示例所用的开发环境为 Xcode14 + Swift 5.7 + iOS 13。需要登录已付费的开发者账号才能开启 NFC Capability。

工程配置

设置 Capability

在项目导航器中选中项目，转到 Signing & Capabilities 标签页并选择 +Capability，在弹出的列表中选择 Near Field Communication Tag Reading。这会自动生成 entitlements 文件中的必要配置信息，同时为您的应用程序激活 NFC 功能。

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/

DTDs/PropertyList-1.0.dtd">

<plist version="1.0">

<dict>

  <key>com.apple.developer.nfc.readersession.formats</key>

  <array>

    <string>TAG</string>

  </array>

</dict>

设置 Info.plist

添加 NFC 相关的隐私设置，向 Info.plist 文件中添加 Privacy - NFC Scan Usage Description 隐私设置项。

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/

DTDs/PropertyList-1.0.dtd">

<plist version="1.0">

<dict>

  <key>NFCReaderUsageDescription</key>

  <string>应用需要您的同意，才能访问 NFC 进行社保卡信息的读写。</string>

</dict>

添加 AID 相关的设置项，向 Info.plist 文件中添加 ISO7816 application identifiers for NFC Tag Reader Session 配置项。

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/

DTDs/PropertyList-1.0.dtd">

<plist version="1.0">

<dict>

  <key>com.apple.developer.nfc.readersession.iso7816.select-identifiers</key>

  <array>

    <string>A000000632010105</string>

  </array>

</dict>

说明：第三代社保卡使用统一的交通联合卡电子钱包规范，A000000632010105 为交通联合卡 AID 标识。参考网址：wiki.nfc.im/books 。

导入 CryptoSwift 第三方库

在项目导航器中选中项目，右键菜单选择 Add Packages...，在搜索框中输入 github.com/krzyzanowsk… 并点击 Add Package 按钮完成导入。

说明：CryptoSwift 提供了相关的十六进制字符串与 UInt8 相互转换的方法。

代码编程

扩展 NFCISO7816Tag

由于 Apple 是从 iOS 14 系统开始提供了 sendCommand API 的异步调用形式，为兼容 iOS 13 系统，并更好的使用 Swift 提供的 async/await 语法，现对其 NFCISO7816Tag 进行方法扩展。

import CoreNFC

import CryptoSwift



@available(iOS 13.0, *)

extension NFCISO7816Tag {



  @discardableResult

  func sendCommand(_ command: String) async throws -> Data {

    return try await withCheckedThrowingContinuation { continuation in

      // 通过 CryptoSwift 库提供的 API，将十六进制表示命令字符串转换成字节

      let apdu = NFCISO7816APDU(data: Data(hex: command))!

      // 将同步调用形式转换成异步调用形式

      sendCommand(apdu: apdu) { responseData, _, _, error in

        if let error {

          continuation.resume(throwing: error)

        } else {

          continuation.resume(returning: responseData)

        }

      }

    }

  }

}

封装 NFCTagReaderSession

import CoreNFC



@available(iOS 13.0, *)

class NFCISO7816TagSession: NSObject, NFCTagReaderSessionDelegate {



  private var session: NFCTagReaderSession? = nil

  private var sessionContinuation: CheckedContinuation<NFCISO7816Tag, Error>? = nil



  func begin() async throws -> NFCISO7816Tag {

    // 实例化用于检测 NFCISO7816Tag 的会话

    session = NFCTagReaderSession(pollingOption: .iso14443, delegate: self)

    session?.alertMessage = "请将社保卡靠近手机背面上方的 NFC 感应区域"

    session?.begin()

    return try await withCheckedThrowingContinuation { continuation in

      self.sessionContinuation = continuation

    }

  }



  func invalidate(with message: String) {

    // 关闭读取会话，以防止重用

    session?.alertMessage = message

    session?.invalidate()

  }



  // MARK: - NFCTagReaderSessionDelegate



  func tagReaderSessionDidBecomeActive(_ session: NFCTagReaderSession) {}



  func tagReaderSession(_ session: NFCTagReaderSession, didDetect tags: [NFCTag]) {

    // 检测到 NFCISO7816Tag

    if let tag = tags.first, case .iso7816(let iso7816Tag) = tag {

      session.alertMessage = "正在读取信息，请勿移动社保卡"

      // 连接到 NFCISO7816Tag 并将同步调用形式转换成异步调用形式

      session.connect(to: tag) { error in

        if let error {

          self.sessionContinuation?.resume(throwing: error)

        } else {

          self.sessionContinuation?.resume(returning: iso7816Tag)

        }

      }

    }

  }



  func tagReaderSession(_ session: NFCTagReaderSession, didInvalidateWithError error: Error) {

    // 读取过程中发生错误

    self.session = nil

    sessionContinuation?.resume(throwing: error)

  }

}

编写 UI 界面

使用 SwiftUI 编写如下代码所示的页面，包含一个显示卡号的标签和一个读取按钮。

import SwiftUI



struct ContentView: View {

  @State private var cardNo = ""



  var body: some View {

    VStack(alignment: .leading) {

      Text("卡号：\(cardNo)")

        .font(.system(size: 17))

      Button(action: read) {

        Text("读取")

          .padding()

          .frame(maxWidth: .infinity)

          .foregroundColor(.white)

          .background(.blue)

          .cornerRadius(8)

      }

      Spacer()

    }

    .padding()

  }

}

实现读取逻辑

import SwiftUI

import CryptoSwift



struct ContentView: View {

  // var body: some View {...}

  

  private func read() {

    Task {

      let session = NFCISO7816TagSession()

      do {

        // 检测 NFCISO7816Tag

        let tag = try await session.begin()

        // 发送命令 00B0950A12 并截取前 10 个字节转换为 20 位卡号

        let cardNo = try await tag.sendCommand("00B0950A12")[0..<10].toHexString()

        self.cardNo = cardNo

        // 关闭读取会话

        session.invalidate(with: "读取成功")

      } catch {

        print(error)

      }

    }

  }

}

说明：APDU 是卡与读卡器之间传送的信息单元，具体指令描述请参考 wiki.nfc.im/books 。

运行过程截图

数字签名是什么

数字签名是一种数字技术，用于验证和保护数据的完整性。

数字签名是通过一些加密算法将消息或文件与公钥（如果是非对称加密就有公钥不然就不用）绑定在一起，并生成唯一的签名。

数字签名的工作原理

数字签名的核心在于加密算法。最常用的是非对称加密算法，它将原文通过特定HASH函数得到的摘要信息用发送者的私钥加密，与原文一起传送给接收者。接收者只有用发送者的公钥才能解密被加密的摘要信息，然后用HASH函数对收到的原文提炼出一个摘要信息，与解密得到的摘要进行对比。

数字签名也可以使用哈希函数对文件或消息的散列值进行加密，确保消息不会被篡改。(也有人认为摘要算法不能逆向也就是解密所以不是加密算法，在此不做讨论)

数字签名可以与数字证书结合使用，以证明密钥的归属和真实性，从而保护数字签名过程不被破坏。

数字签名的应用

JWT

JWT通常由三个部分组成：头部（Header）、载荷（Payload）和签名（Signature），以点号分隔。第一部分是头部，第二部分是载荷，第三部分是签名。以下是一个包含了用户ID、用户名和时间戳的JWT实例，格式为 Header.Payload.Signature。

// 为方便展示，在'.'处作了换行处理，可以更好地看清楚结构

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.

eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.

SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

Header和Payload都是经过 Base64URL 编码的，所以每个人都能通过解码得到原来的信息，固不应该在里面存一些敏感信息。

Signature就是我们要讨论的数字签名了！Signature 部分是对前两部分的签名，防止数据篡改。首先，需要指定一个密钥（secret）。这个密钥只有服务器才知道，不能泄露给用户。然后，使用 Header 里面指定的签名算法（默认是 HMAC SHA256），按照下面的公式产生签名。Signature = HMACSHA256( base64UrlEncode(header) + "." + base64UrlEncode(payload), secret)

HMAC算法 是一种基于密钥的报文完整性的验证方法。HMAC算法利用哈希运算，以一个密钥和一个消息为输入，生成一个消息摘要作为输出。其安全性是建立在Hash加密算法基础上的。

由于Signature是根据Header和Payload以及服务器的secret来生成的，由于secret只有服务器知道，所以只要Header、Payload、Signature其中一个被篡改了，那么后续验证的时候就不能通过。同时只有知道secret才能产生与Header、Payload配对的Signature，所以也能确认该 Token 是否是该服务器所颁发的。

验证过程是用服务器的密钥通过同样的算法计算出一个新的 Signature 然后和旧的 Signature 进行比较，只要被篡改那么 Signature就会跟着改变，所以通过比较， Signature 一样的话则证明没有被篡改，否则则认为被篡改了。

CA 证书

其实就是这个 CA 证书的数字签名为什么可以防篡改，困扰了我好久，所以才去稍微深入了解了一下然后写下了这篇博客。就是为了这点醋，我才包的这顿饺子~

之前学习 https 的时候，看了各大论坛的帖子发现有挺多帖子对于 CA 证书是怎么做放篡改的讲的不太对或者讲的不太清晰，所以这个问题困扰了我挺久。以下是随便找的一些帖子（对事不对人）：

例1：

例2：

例3：

（例1和例2是随便在掘金上面搜到的相关文章，例3是newbing的回答）

先回顾一下数字证书验证的大概过程：

CA 签发证书的过程：

• 首先 CA 会把持有者的公钥、用途、颁发者、有效时间等信息打成一个包，然后对这些信息进行 Hash 计算，得到一个 Hash 值；
• 然后 CA 会使用自己的私钥将该 Hash 值加密，生成 Certificate Signature，也就是 CA 对证书做了签名；
• 最后将 Certificate Signature 添加在文件证书上，形成数字证书；

客户端校验服务端的数字证书的过程：

• 首先客户端会使用同样的 Hash 算法获取该证书的 Hash 值 H1；
• 浏览器收到证书后可以使用 CA 的公钥解密 Certificate Signature 内容，得到一个 Hash 值 H2 ；
• 最后比较 H1 和 H2，如果值相同，则为可信赖的证书，否则则认为证书不可信。

核心问题在于验证服务器发来的数字证书的数字签名时所用到的公钥是哪里来的。

假设有那么一个场景：

客户端A 和 服务器A 的通信过程中，私钥是Secret_RSA_A，公钥是Secret_PUB_A。服务器A 将自己的证书CA发给客户端A的过程中被 中间人B 给截获了，中间人B 用自己的公钥Secret_PUB_B 替换了 服务器A 发给 客户端A 的CA证书的公钥Secret_PUB_A，并且用和公钥Secret_PUB_B 配对的私钥Secret_RSA_B 对替换公钥后的CA证书的公钥、用途、颁发者、有效时间等信息生成的新HASH 进行加密，生成新的 Certificate Signature 并把原本证书上的 Certificate Signature 替换掉。但客户端A 对这并不知情。然后在后续客户端对该 CA证书验证的过程中，如果使用的是证书上的公钥，那么计算出来的 H1 和 H2 就会一样，也就是认为证书是可信的。（实际上加密使用的是CA私钥而不是服务器私钥所以中间人伪造不了一对新的公私钥，但是如果使用服务器发送过来的公钥去验证的话那么就有可能被伪造）

所以更加安全的做法应该是不使用传过来的证书上面的公钥（证书上的公钥是服务器持有者的公钥而不是CA公钥），而是使用预置在操作系统里面的公钥，因为证书加密是用CA私钥加密的而不是用服务器持有者的私钥进行加密的，传服务器持有者的公钥过来是为了和客户端协商然后生成后续对称加密通信需要用到的秘钥。这也是我之前看到的一些文章没有提到的（如上面的图1/2/3所示，没有针对原作者的意思），容易让人困惑。服务器发送过来的证书中的公钥是服务器的公钥而不是可以解密数字签名的公钥（数字签名的公钥也就是和CA证书配对的公钥）。 通常浏览器和操作系统中集成了 CA 的公钥信息，浏览器收到证书后可以使用操作系统内置的 CA 的公钥解密 Certificate Signature 内容。这行验证过程中存在一个证书信任链的问题。客户端收到服务器发送过来的CA证书后，浏览器开始查找操作系统中已内置的受信任的证书发布机构CA，与服务器发来的证书中的颁发者CA比对，用于校验证书是否为合法机构颁发，如果找不到，浏览器就会报错，说明服务器发来的证书是不可信任的。如果找到，那么浏览器就会从操作系统中取出 颁发者CA 的公钥，然后对服务器发来的证书里面的签名进行解密。

综上，数字签名只能验证数据的完整性（JWT 只有服务端可以验证他的身份，因为它有解密需要的密钥，而客户端是验证不了的），而验证身份需要的是数字证书。

最后

以上是本人在学习数字签名原理的过程中的一些感悟，由于个人的局限性，所以可能存在纰漏的情况，欢迎大家批评指正。

1. 引言

大家好，我是比特桃。Git 作为现在最流行的版本管理工具，想必大家在开发过程中都会使用。由于 Git 中很多操作默认是采用 Merge 进行的，并且相对也不容易出错，所以很多人都会使用 Merge 来进行合并代码。但Rebase 作为 Git 中主要命令之一，我们还是有必要了解一下，在适合的场景中进行使用。

2. Rebase 的作用

Rebase 中文翻译过来：变基，我觉得这个翻译挺生硬的，导致很多人没有彻底理解变基的含义。我个人把 Rebase 意为 认爸爸，比如可以 Rebase 到马爸爸分支上，成为他的合理继承人。


上图为一次 Rebase 的情况，可以看到最终效果仿佛 Feature 分支没有存在过，新提交的 Commit 像真的在主分支上提交一样。而如果我们用 Merge 就会产生一个合并节点：


可能只看到一次合并所产生的 Commit 节点并没有什么，但实际项目中大概率会变成这样：


简直是乱的一批，仿佛看到了多年前其他人写的一堆代码，啥啥啥，这都是啥！反过来看看采用 Rebase 开发的真实项目，没有对比就没有伤害：


这也是为什么尤雨溪也比较推荐使用 rebase的原因：

3. Rebase 怎么用

其实很多人不用 Rebase ，一方面是不了解实际项目协同中怎么用。另一方面是用了，但问题很多，所以就误认为不好用从而再也不用。这里分享一下，我最近在做项目时所采用 Rebase 方面的协同流程（为了好说明，适当的进行了简化）：

3.1 Checkout

首先，我们想从 master 分支上开发新的功能或者修复 bug ，需要 checkout出来一个分支。比如在

A节点中 checkout dev 分支，为了让场景更复杂，在 git checkout dev 分支后。master 上继续有人提交了B、C，形成如下Git 结构：


这里强调一下，很多人用 Rebase 出问题，都是出在了想要 Rebase 的分支是公共分支。其实这里的 dev 应该是只有自己用的分支才合适，回想一下，Git 本身就是分布式版本管理。其实不用远程仓库也是可以非常好的进行版本控制的，我们要将本地分支和远程分支的概念区分的开一些，这俩没有直接联系。所以你本机随便做个 NB 分支一样可以的，Rebase后没人知道你自己起了个什么鬼名字。

3.2 远程管理

如果自己的dev分支并不一定在一台电脑上开展，为了可以自己在多个电脑上开发，我们可以关联了一个自己的远程仓库。这一步是可选的。

3.3 开始变基

现在我们在 dev 上开发了D、E，然后dev rebase master，形成了A、B、C、D、E：


这里虽然看似已经一条直线了，但实际 只有 dev 知道自己的爸爸成为了 master，但 master 并没有认这个儿子。所以我们还需要：master merge dev，这样就在master上形成了一条完美的直线：


最后，再 git push origin master 到远程分支，完成本次开发。

3.4 善后

Rebase 后 dev 由于变基了，相当于已经认贼作父了，现在还想再认回来？休想！所以只能强制解决，在非保护分支中强制push到自己的远程仓库：git push --force origin dev，最后再将dev变基到自己的远程分支：git rebase origin dev，方便自己远程仓库的维护。至此，完成了一次rebase形式的开发，并且可以继续进行下次开发。

4. Rebase 的优缺点

先说说优点：

• 保持提交历史的线性：使用 merge 合并分支时，会创建一个新的合并提交，从而在提交历史中形成一条新的分支。而使用 rebase，可以将提交记录直接添加到目标分支的末尾，从而保持提交历史的线性。
• 减少不必要的合并提交：使用 merge 合并分支时，会创建一个新的合并提交，它可能会包含很多无意义的合并信息。而使用 rebase，可以将提交记录逐个添加到目标分支的末尾，避免了创建不必要的合并提交。
• 更好的代码审查和追溯：使用 rebase，可以让提交历史更加直观和易于理解，从而更容易进行代码审查和问题追溯。
• 避免冲突的产生：在合并分支时，可能会因为两个分支之间存在冲突而导致合并失败。而使用 rebase，可以在变基之前先解决这些冲突，从而避免了合并时出现的冲突。

总之，虽然 rebase 不是适用于所有情况的万能解决方案，但在大多数情况下，使用 rebase 能够帮助我们创建更加干净和直观的提交历史，提高团队的协作效率。

说了这么说好像都在说 Rebase 的优点，那 Rebase就没有缺点嘛？当然不是，要不然大家早就都从 Merge 转 Rebase了。Rebase 的缺点：

• 解决冲突繁琐，rebase冲突 是按每个commit来对比的，merge冲突 是按最终结果来对比的，如果用rebase最好是经常去合并一下代码，不然长周期的开发如果就在最后rebase真的是解冲突解到人傻掉。
• 没有合并记录，Merge 有记录，出了问题好解决。
• 操作步骤相对繁琐。

5. 结语

协同开发最核心的问题其实就是合并，如何合理的合并，优雅的合并，是每个团队需要考虑的问题。Merge 和 Rebase 作为 Git 中主要的命令，其实各有各的优点，两个一起用也是很常见的。根据自身团队及项目情况，选择合适的方式才是最好的。最后，祝大家合并代码一切顺利~

这是我早先实现的一个自定义横滑组件，本文回顾一下当时实现过程遇到的问题和细节，最后有源码地址

文中所有图片托管在Github上

所谓横滑组件其实就如图所示的效果：

列一下UI上的要求：

• 每次滑动一页，有pageEnable的效果
• 每次显示在屏幕中的item其实是三个而不是一个
• 每个item的间距、视图与屏幕边缘的边距严格按照UI上样子

UICollectionView+pageEnable

使用UICollectionView并开启pageEnable是最容易想到的方案，我们来试一下能否满足需要

关键的几个参数如下所示

container.width = 375

collectionView.isPagingEnable = true

collectionView.width = 375

leftPadding = rightPadding = 16

cell.width = container.width - leftPadding - rightPadding

collectionView.contentInset = UIEdgeInset(0,16,0,0)

效果如下所示：

显然，没有达到预期：

• 问题1，每次滑动停止后，cell的位置不对
  • 通过打印contentOffset得知，UIScrollView开启pagingEnable后的自动翻页，每次修改contentOffset的值等于UIScrollView.width
  • 而且我们无法自定义每次翻页移动的距离
• 问题2，由于设置了collectionView.contentInset.left，所以第一cell可以移动到屏幕最左边而不能自动还原到初始位置

不甘心，继续调整

我画了一张图来表示要实现的效果：

• 根据上图的效果，我们希望的效果是每次移动cell时移动的距离(两条红竖线之间的距离)是一个cell的宽度+cell之间的距离--cell.width+interval
• 既然pageEnable特性每次移动的距离一定是scrollView.width，所以我们可以让scrollView.width = cell.width+interval
• 这或许能解决上面显示异常问题

我们更新一下配置参数，如下：

leftPadding = rightPadding = 16

container.width = 375

collectionView.isPagingEnable = true

cell.width = container.width - leftPadding - rightPadding

interval = 8

collectionView.width = cell.width + interval

collectionView.contentInset = UIEdgeInset(0,0,0,interval) // 这一句可能会引起你的困惑，但经过测试必须设置成这样，否则效果有问题，本文不做详细解释，跟scrollView自身对于contentSize和contentOffset的调整有关

来看一下效果：

哇，好像不错！但还是有问题：

• 我们希望同时显示三个cell，但该效果却只能显示1个cell
• 这是因为collectionView的宽度刚好能显示下一个cell和一个interval，没有更多空间来显示其他cell了

这就很尴尬了，为了利用pageEnable的特性，我们不得不修改collectionView的宽度小一些，但这却导致无法足够的cell个数

所以，结论是：❌

UICollectionView + UIScrollView

在调研其他技术方案时，受一Paging a overflowing collection view启发，可以使用一个UICollectionView和一个UIScrollView一同实现类似效果

核心思想如下：

• 单独用一个UIScrollView，利用pageEnable特性来实现符合要求的横滑、拖拽翻页效果
• 单独用一个UICollectionView来利用它的cell显示、复用机制
• UIScrollView是不显示的，只用它的拖拽手势能力。当拖拽UIScrollView时，将contentOffset的移动应用到UICollectionView中

具体实现过程中有些细节需要注意，比如：

1. collectionView的contentInset需要设置
2. 将scrollView的移动应用到collectionView中时如何计算准确
3. 需要关闭collectionView的panGesture

再放一下效果

结论是：✅

源码地址：SlideView.swift

优缺点

优点很明显：

• 既复用了UIScrollView的pageEnable手势和动画效果，也复用了UICollectionView的cell复用机制
• 由于复用了UICollectionView，所以相比通过UIScrollView自定义实现，在一些用户交互体验上可能更好，比如在快速横滑时，自定义的实现可能就没办法快速的准备好每一个cell并无缝从上一页切换过来，可能会有点卡顿
• 所有实现细节都是通过系统官方的public API，不存在任何trick行为，稳定性好

缺点：

在用户体验上没发现缺点。只是在封装为独立组件时需要注意更多细节，比如：

• 该组件将CollectionView封装了起来，所以必须给外部使用者暴露dataSource和delegate等必要的回调和数据源方法

使用UIScrollView完全自定义实现

我还看过另一种方案：

• 自己创建cell视图，添加到UIScrollView上
• 完全由自己来控制cell的复用和显示逻辑
• 滑动手势和效果方面，利用UIScrollViewDelegate方法来控制抬起手指后移动到到下一个或上一个cell的效果（该效果我曾经也实现过，可以参考设计与Swipe-Delete不冲突的UIPageViewController）

这个思路看上去应该是可行的，我也看过类似的源码实现，是Github上的一个代码

但该源码的显示逻辑写的不好：

• 每次切换cell时，会同时通过delegate要求更新所有的cell数据（显示在屏幕中的cell和在缓存池中未用到的cell）

引言

背景： 去掉导航栏下边的黑边在iOS15失效
原因：必须使用iOS13之后的APIUINavigationBarAppearance设置才能生效

UIKIT_EXTERN API_AVAILABLE(ios(13.0), tvos(13.0)) NS_SWIFT_UI_ACTOR

@interface UINavigationBarAppearance : UIBarAppearance

I 导航栏的黑边设置

1.1 去掉导航栏下边的黑边(iOS15适配)

iOS15之前: [self.navigationBar setShadowImage:[[UIImage alloc] init]];

        [vc.navigationController.navigationBar setBackgroundImage:[ImageTools createImageWithColor: [UIColor whiteColor]] forBarMetrics:UIBarMetricsDefault];

iOS15之后

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

        UINavigationBarAppearance *appearance = [[UINavigationBarAppearance alloc] init];

        

        //去掉透明后导航栏下边的黑边

        appearance.shadowImage =[[UIImage alloc] init];

        

        appearance.shadowColor= UIColor.clearColor;





        

        navigationBar.standardAppearance = appearance;

        

        navigationBar.scrollEdgeAppearance = appearance;

        

    }

1.2 设置导航栏下边的黑边(iOS13适配)

// 设置导航栏下边的黑边

+ (void)setupnavigationBar:(UIViewController*)vc{

    

    

    

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

        

        UINavigationBar *navigationBar = vc.navigationController.navigationBar;



        UINavigationBarAppearance *appearance =navigationBar.standardAppearance;

        

    

        appearance.shadowImage =[UIImage createImageWithColor:k_tableView_Line];



        appearance.shadowColor=k_tableView_Line;

        



        navigationBar.standardAppearance = appearance;

        navigationBar.scrollEdgeAppearance = appearance;



    } else {

        // Fallback on earlier versions

        

        UINavigationBar *navigationBar = vc.navigationController.navigationBar;

        [navigationBar setBackgroundImage:[[UIImage alloc] init] forBarPosition:UIBarPositionAny barMetrics:UIBarMetricsDefault]; //此处使底部线条颜色为红色

//        [navigationBar setShadowImage:[UIImage createImageWithColor:[UIColor redColor]]];

        

        [navigationBar setShadowImage:[UIImage createImageWithColor:k_tableView_Line]];

        

    }





    

}

II 去掉TabBar的顶部黑线

• setupshadowColor

- (void)setupshadowColor{

    

    UIView * tmpView = self;

    tmpView.layer.shadowColor = [UIColor blackColor].CGColor;//设置阴影的颜色

    tmpView.layer.shadowOpacity = 0.08;//设置阴影的透明度

    tmpView.layer.shadowOffset = CGSizeMake(kAdjustRatio(0), kAdjustRatio(-5));//设置阴影的偏移量,阴影的大小，x往右和y往下是正

    tmpView.layer.shadowRadius = kAdjustRatio(5);//设置阴影的圆角,//阴影的扩散范围，相当于blur radius，也是shadow的渐变距离，从外围开始，往里渐变shadowRadius距离



    

//去掉TabBar的顶部黑线    

[self setBackgroundImage:[UIImage createImageWithColor:[UIColor clearColor]]];

[self setShadowImage:[UIImage createImageWithColor:[UIColor clearColor]]];

    

}

see also

iOS小技能：自定义导航栏，设置全局导航条外观。（iOS15适配）
blog.csdn.net/z929118967/…

国内要闻

曝小米自研系统为全端系统

日前，有数码博主爆料，小米自研操作系统属于全端自研系统，兼容AOSP（Android 开放源代码项目）。如此看来，小米自研操作系统还可能有车机、平板、手表等终端系统，而且小米走的是华为鸿蒙操作系统的路子，前期先兼容安卓更为稳妥，保住既有的用户量。（手机中国）

华为辟谣网传3.2万名科学家正式移籍：造谣者毫无根据、无中生有

近日，网络上多家平台发布了针对华为公司的系列言论，经证实，该系列言论均为谣言，华为表示，造谣者毫无根据、无中生有。此外，华为呼吁各位网友“勿信勿传，果断举报”。（第一财经）

清华大学联合字节跳动，开源听觉大语言模型 SALMONN

清华大学联合字节火山语音团队提出了一种全新的「听觉」大语言模型——SALMONN (Speech Audio Language Music Open Neural Network)。相较于仅仅支持语音输入或非语音音频输入的其他大模型，SALMONN 对语音、音频事件、音乐等各类音频输入都具有感知和理解能力，相当于给大语言模型「加了个耳朵」，从而涌现出多语言和跨模态推理等高级能力。

钉钉公布 AI 版本商业定价：调用一次大模型不到 5 分钱

8 月 22 日，钉钉召开 2023 生态大会，据总裁叶军介绍：截至今年 3 月末，钉钉软件付费企业数达 10 万家，其中小微企业占 58%，中型企业占 30%，大型企业占 12%；钉钉付费 DAU 超过 2300 万。这也是钉钉首次公布其商业化核心进展。此外，钉钉还公布了大模型落地应用场景的商业化方案：在钉钉专业版年费 9800 元基础上，增加 10000 元即可获得 20 万次大模型调用额度；在专属钉钉年费基础上，增加 20000 元即可获得 45 万次大模型调用额度，约等于平均每次调用只需 0.44~5 分钱。（IT 之家）

吉利回应与百度合作造车：开发一直为吉利主导，百度提供技术支持

不久前，吉利与百度合作造车计划突遭生变，“集度”变身“极越”。近日，在吉利汽车半年业绩发布会上，吉利控股集团CEO李东辉回应腾讯新闻《远光灯》，极越定位为吉利控股旗下高端智能汽车机器人品牌。在极越的开发过程中，一直都是吉利控股来主导的，百度提供了大数据、无人驾驶等领域的技术支持。

非法注册 300 万个微信号！央视曝光特大黑灰产系列案

8月7日、8日、9日中午，中央电视台《今日说法》栏目以《揭秘“黑灰产”》为题，分上、中、下三集对山东淄博周村公安分局破获的特大黑灰产案件侦破过程进行专题报道。犯罪分子批量注册并贩卖微信号，形成产业链。这些微信号多用于电信诈骗等违法犯罪活动。该犯罪团伙共非法注册微信号 300 余万个，非法获利达 1000 余万元。警方通过追查嫌疑人注册微信的手机号码来源，打掉一个号商团伙，揪出二十余名省级运营商“内鬼”。他们利用手中的权力，牟取巨额私利，为犯罪团伙提供非法注册的手机号码。（今日说法）

国际要闻

苹果回应 iPhone14 电池老化快：属于正常现象

苹果公司的 iPhone 14 系列手机上市不到一年，就出现了电池健康度下降过快的问题。一些用户反映，他们的手机电池在使用几个月后，就损耗了 10% 以上的容量。苹果公司表示，这种情况属于正常现象，只有当电池容量低于 80% 时，才能在保修期内享受免费更换服务。

据了解，如果使用非正品电池或者其他 iPhone 14 手机上拆下来的电池进行更换，那么手机将无法识别新电池，并且会禁用电池健康度功能，这意味着用户无法查看电池的剩余容量和性能状况。（IT之家）

Meta 推出 AI 模型 SeamlessM4T，可翻译和转录近百种语言

Meta 近日发布了人工智能模型 SeamlessM4T，可以翻译和转录近 100 种语言的文本和语音。SeamlessM4T 支持对近百种语言进行语音以及文本识别，同时支持近 100 种输入语言和 36 种输出语言的语音到语音翻译。Meta 表示，将会以研究许可证的形式公开发布 SeamlessM4T，以便研究人员和开发人员在此基础上开展工作。Meta 还将发布 SeamlessAlign 的元数据，这是迄今为止最大的开放式多模态翻译数据集，共挖掘了 27 万小时的语音和文本对齐。（品玩）

iPhone 15 系列顶配机型有望首次搭载潜望式镜头

来自摩根士丹利的一份分析师报告指出，iPhone 15 Pro Max（或改名为 iPhone 15 Ultra）将获得苹果有史以来第一款潜望式镜头，其变焦能力从前代的 3 倍将提升到 5-6 倍，表现令人相当期待。这份报告还提到，由于全新传感器的加入，使 iPhone 15 系列顶配机型的备货能力受到影响，或许会在 iPhone 15 系列开售后 3-4 周时间才会陆续发货。毫无疑问，这将会是 iPhone 15 系列中最值得关注的一款机型。（雷科技）

微软宣布将把动视暴雪云游戏权益出售给育碧，以安抚英国监管机构

8 月 22 日消息，据外媒报道，当地时间周一，微软宣布将把动视暴雪的云游戏权益出售给育碧，以重组其拟议的动视暴雪收购交易。报道称，微软此举旨在安抚英国监管机构英国竞争和市场管理局（CMA），因为该机构担心这笔交易会扼杀快速增长的云游戏市场的竞争。当地时间周一，微软与育碧签署了一项为期 15 年的协议，将《使命召唤》等动视暴雪的云游戏相关权益授权给育碧，这是微软为其收购动视暴雪获得反垄断批准的最新举措。（TechWeb）

Meta 推出拥有 12 种复杂技能机器人，上得厅堂下得厨房

耗时 2 年，Meta 联手卡耐基梅隆大学推出通用机器人智能体——RoboAgent，可以通过图像或者语言指令，来指挥机器人完成任务。它拥有 12 种不同的复杂技能，泡茶、烘焙不在话下，未来还能泛化 100 多种未知任务。（网易科技）

IBM 推企业级 AI 平台！剑指企业级 AI 应用三大挑战

日前，IBM 面向中国区正式推出企业级 AI 平台 watsonx，包含企业级 AI 与数据平台 watsonx.ai、湖仓一体的数据存储方案 watsonx.data 以及 AI 治理工具包 watsonx.governance。

程序员专区

微软 Excel 宣布集成 Python

微软已经将 Python 原生集成到 Excel 公测版中，首先向 Microsoft 365 Insiders 推出，从而使用户能够借助 Python 库、数据可视化和分析的能力更好地使用 Excel。目前该功能只能在桌面版 Excel 中使用，但微软表示 Python 计算也可以在微软云中运行。

Google 更新 Android 运行时应用提速最高三成

Android 运行时 (Android Runtime 或 ART)的最新更新将帮助应用在部分设备上的启动时间缩短最多 30%。ART 是 Android 操作系统的引擎，提供了所有 Android 应用和绝大多数服务所依赖的运行时和核心 API。改进 ART 将能让所有开发者受益，让应用执行更快，字节码编译更高效。Google 表示它正致力于让 ART 模块化独立于操作系统更新。ART 的可独立更新将能让用户更快获得性能优化和安全更新，让开发者更快获得 OpenJDK 改进和编译器优化。它的测试显示，ART 13 的运行时和编译器优化在部分设备上实现了最高 30% 的应用启动改进。

前言

在 iOS 16 中，Apple 引入了三种新的宽度样式字体到 SF 字体库。

1. Compressed

2. Condensed

3. Expend

UIFont.Width

Apple 引入了新的结构体 UIFont.Width，这代表了一种新的宽度样式。

目前已有的四种样式。

• standard：我们总是使用的默认宽度。

• compressed：最窄的宽度样式。

• condensed：介于压缩和标准之间的宽度样式。

• expanded：最宽的宽度样式。

SF 字体和新的宽度样式

如何将 SF 字体和新的宽度样式一起使用

为了使用新的宽度样式，Apple 有一个新的 UIFont 的类方法来接收新的 UIFont.Width 。

class UIFont : NSObject {

    class func systemFont(

        ofSize fontSize: CGFloat,

        weight: UIFont.Weight,

        width: UIFont.Width

    ) -> UIFont

}

你可以像平常创建字体那样来使用新的方法。

let condensed = UIFont.systemFont(ofSize: 46, weight: .bold, width: .condensed)

let compressed = UIFont.systemFont(ofSize: 46, weight: .bold, width: .compressed)

let standard = UIFont.systemFont(ofSize: 46, weight: .bold, width: .standard)

let expanded = UIFont.systemFont(ofSize: 46, weight: .bold, width: .expanded)

SwiftUI

更新：在 Xcode 14.1 中，SwiftUI 提供了两个新的 API 设置这种新的宽度样式。
width(_:) 和 fontWidth(_:)。

目前（Xcode 16 beta 6），这种新的宽度样式和初始值设定只能在 UIKit 中使用，幸运的是，我们可以在 SwiftUI 中轻松的使用它。

有很多种方法可以将 UIKit 集成到 SwiftUI 。我将会展示在 SwiftUI 中使用新宽度样式的两种方法。

1. 将 UIfont 转为 Font。
2. 创建 Font 扩展。

将 UIfont 转为 Font

我们从 在 SwiftUI 中如何将 UIFont 转换为 Font 中了解到，Font 有初始化方法可以接收 UIFont 作为参数。

步骤如下

1. 你需要创建一个带有新宽度样式的 UIFont。
2. 使用该 UIFont 创建一个 Font 。
3. 然后像普通 Font 一样使用它们。

struct NewFontExample: View {

    // 1

    let condensed = UIFont.systemFont(ofSize: 46, weight: .bold, width: .condensed)

    let compressed = UIFont.systemFont(ofSize: 46, weight: .bold, width: .compressed)

    let standard = UIFont.systemFont(ofSize: 46, weight: .bold, width: .standard)

    let expanded = UIFont.systemFont(ofSize: 46, weight: .bold, width: .expanded)

    

    var body: some View {

        VStack {

            // 2

            Text("Compressed")

                .font(Font(compressed))

            Text("Condensed")

                .font(Font(condensed))

            Text("Standard")

                .font(Font(standard))

            Text("Expanded")

                .font(Font(expanded))

        }

    }

}

• 创建带有新宽度样式的 UIFont。
• 用 UIFont 初始化 Font， 然后传递给 .font 修改。

创建一个 Font 扩展

这种方法实际上和将 UIfont 转为 Font 是同一种方法。我们只需要创建一个新的 Font 扩展在 SwiftUI 中使用起来更容易一些。

extension Font {

    public static func system(

        size: CGFloat,

        weight: UIFont.Weight,

        width: UIFont.Width) -> Font

    {

        // 1

        return Font(

            UIFont.systemFont(

                ofSize: size,

                weight: weight,

                width: width)

        )

    }

}

创建一个静态函数传递 UIFont 需要的参数。然后，初始化 UIFont 和创建 Font 。

我们就可以像这样使用了。

Text("Compressed")

    .font(.system(size: 46, weight: .bold, width: .compressed))

Text("Condensed")

    .font(.system(size: 46, weight: .bold, width: .condensed))

Text("Standard")

    .font(.system(size: 46, weight: .bold, width: .standard))

Text("Expanded")

    .font(.system(size: 46, weight: .bold, width: .expanded))

如何使用新的宽度样式

你可以在你想使用的任何地方使用。不会有任何限制，所有的新宽度都有一样的尺寸，同样的高度，只会有宽度的变化。

这里是拥有同样文本，同样字体大小和同样字体样式的不同字体宽度样式展示。

新的宽度样式优点

你可以使用新的宽度样式在已经存在的字体样式上，比如 thin 或者 bold ，在你的 app 上创造出独一无二的体验。

Apple 将它使用在他们的照片app ，在 "回忆'' 功能中，通过组合不同的字体宽度和样式在标题或者子标题上。

这里有一些不同宽度和样式的字体组合，希望可以激发你的灵感。

Text("Pet Friends")

    .font(Font(UIFont.systemFont(ofSize: 46, weight: .light, width: .expanded)))

Text("OVER THE YEARS")

    .font(Font(UIFont.systemFont(ofSize: 30, weight: .thin, width: .compressed)))



Text("Pet Friends")

    .font(Font(UIFont.systemFont(ofSize: 46, weight: .black, width: .condensed)))

Text("OVER THE YEARS")

    .font(Font(UIFont.systemFont(ofSize: 20, weight: .light, width: .expanded)))

你也可以用新的宽度样式来控制文本的可读性。

下面的这个例子，说明不同宽度样式如何影响每行的字符数和段落长度

下载这种字体

你可以在 Apple 字体平台 来下载这种新的字体宽度样式。

下载安装后，你将会发现一种结合了现有宽度和新宽度样式的新样式。

基本上，除了在模拟器的模拟系统 UI 中，在任何地方都被禁止使用 SF 字体。请确保你在使用前阅读并理解许可证。

表现

手指按住屏幕下拉，屏幕顶部会多出一块白色区域。手指按住屏幕上拉，底部多出一块白色区域。

产生原因

在 iOS 中，手指按住屏幕上下拖动，会触发 touchmove 事件。这个事件触发的对象是整个 webview 容器，容器自然会被拖动，剩下的部分会成空白。

解决方案

1. 监听事件禁止滑动

移动端触摸事件有三个，分别定义为

1. touchstart ：手指放在一个DOM元素上。

2. touchmove ：手指拖曳一个DOM元素。

3. touchend ：手指从一个DOM元素上移开。

显然我们需要控制的是 touchmove 事件，由此我在 W3C 文档中找到了这样一段话

Note that the rate at which the user agent sends touchmove events is implementation-defined, and may depend on hardware capabilities and other implementation details.（注意，用户代理发送touchmove事件的速率是实现定义的，并且可能取决于硬件功能和其他实现细节。）

If the preventDefault method is called on the first touchmove event of an active touch point, it should prevent any default action caused by any touchmove event associated with the same active touch point, such as scrolling.（如果在活动触摸点的第一个touchmove事件上调用preventDefault方法，它应该防止由与同一个活动触摸点关联的任何touchmove事件（如滚动）引起的任何默认操作。）

touchmove 事件的速度是可以实现定义的，取决于硬件性能和其他实现细节

preventDefault 方法，阻止同一触点上所有默认行为，比如滚动。

由此我们找到解决方案，通过监听 touchmove，让需要滑动的地方滑动，不需要滑动的地方禁止滑动。

值得注意的是我们要过滤掉具有滚动容器的元素。

实现如下：

document.body.addEventListener('touchmove', function(e) {

  if (e._isScroller) return;

  // 阻止默认事件

  e.preventDefault();

}, {

  passive: false

});

2. 滚动妥协填充空白，装饰成其他功能

在很多时候，我们可以不去解决这个问题，换一直思路。

根据场景，我们可以将下拉作为一个功能性的操作。