关于 Vision pro，留存一点感想，或许十年后再来回顾。缺点肯定不少，但是这个产品带来了很有趣的新维度

WWDC直播时，最大的疑问是眼动追踪交互足够准确吗？能即时反馈吗？看过各位媒体的文字或口述体验之后，才知道苹果竟然将这种交互方式做得像来自未来一样，通过你的目光，精准得可以定位到一个小小的字母，随时随地随心而动，简直不可思议。

直播中所展示的三维交互效果，让我想起人类对信息的记录和显示方式。文字、图画刻在石头上，刻在竹简上，纸墨印刷成书册；照片、视频，呈现在手机或者电脑的二维屏幕上。而三维信息，可能从未被如此精确真实地呈现在我们的面前。诚然 3D 电影和许多别的 VR、AR 生产厂商也做了诸多努力和探索，但是那些效果都还不足以 “以假乱真”。从现在开始，消费级的信息记录方式，或许又能上升一个维度。

而直播中最大的震撼其实是迪士尼宣传片的一连串 What if...What if all the things we thought impossible were suddenly possible🤯一连串电影和想象中的角色和景观展现在我的眼前，和现实仿若融为一体。这让我感受到 Vision pro 或许能用一种全新的交互体验，让观众真正地身临其境，沉浸其中，甚至忘记真实和虚幻的界限。

直播接近尾声时，BGM 反复唱着 Be a Dreamer，苹果是个实干的梦想家，他们有足够的底气和积淀去梦想，更用努力和科技，将不可能变成可能，将许许多多科幻片中的梦想带来到 2023 年，用 Vision pro 为所有人铺就了无限大的画布，哦，不是二维的画布，是无限大的梦想空间！

当然，这个空间，目前似乎还只有基础的系统应用，像个刚通水电的毛坯房。他究竟能有怎样的表现，还是得看这些内容生产者开发出怎样的内容。有人诟病苹果在六月份拿出来这样的宣传，却要在明年年初才能售卖。可我相信，过去 APP Store 的成功很可能会在 Vision OS 中再现。WWDC，是苹果开发者大会，即主要面向开发者等专业人士的会议。Apple 召集起这些媒体，摄影师，导演，应用和游戏开发者率先开始了解 Vision pro。这些内容生产者，有他们，就有了 dream maker，造梦人，为普通用户编织光怪陆离的绚烂梦境。

看完各位博主的真机体验，Vision pro 并不是一个取代现有的手机、电脑的产品，这是一个全新的，开创新的体验维度，开创人类新需求的产品。

作为多年的哈迷，感觉现在 Vision pro 的语音输入，手势识别和 3D 交互完全可以让我们拿着魔杖释放咒语，让我们和神奇动物面对面，让我们就像骑着飞天扫帚一样去追踪金色飞贼。因为有了如此先进的科技，魔法世界不再是幻想🥺🤩

更可以想象，无论是工业设计，照片、视频、电视电影还是游戏，都可能会因为这种全新的沉浸式的三维交互体验，而被改写。

你可以和同事一起在虚拟空间中建造模型，模拟生产制造流程。

你可以把与亲朋好友、猫猫狗狗共度的美好时光定格在一片似真似幻的空间。无论何时再回首，他们好像永远在你身边，永不褪色。

电影制作人未来可以使用专门的摄像机制作沉浸式三维电影，在家就能有 100 英尺，接近 30 米的巨幕享受。 篮球比赛你可以选择不同的机位跟踪你喜欢的球星和精彩瞬间。 演唱会你可以在任何地方躺下享受最佳视角和空间音效。

而游戏，新增的交互体验更是给了游戏制作人们无限的想象空间。 操控赛车从北极的冰川到热带的雨林；在枪林弹雨中和队友并肩对抗敌人；在球赛场上面对面激情碰撞。配合上 AI 和语言模型，喜欢的二次元角色仿佛搭着你的肩膀和你耳语；所有的一切，开始“眼见为实”。

Vision pro 的眼部追踪、手势交互和 3D 显示混合现实的完成度，带来了像当年 iPhone 实现多点触控的革命性质变。从技术的进步来说，我个人认为这次的质变可能更加惊艳，更加了不起。但是 3499 美元，加上税可能 3 万人民币。说实话，这不是一个大众消费者能够接受的价格。即使有 air 版本，我感觉可能也需要上万人民币。所以，个人估计，它受欢迎的程度应该会大于等于 mac 小于 iPhone 和 AirPods。

当年 Apple Macintosh 开创了精美的高完成度的计算机图形界面 GUI，让电脑走入消费者群体，可价格太贵，真正让个人电脑普及的是微软；现在，iOS 将手机变成了一个功能强大的多媒体设备，可价格不便宜，真正让千家万户享受到智能手机的是 Android。未来，相比 Vision pro，或许有其他品牌的廉价替代品，更开放的开源混合现实系统，Vision 系列或许都不能获得最大的市场份额。可是由 Vision 所真正掀开的新维度不会被关闭，这个被精心打造出来的梦想空间只会无限延伸，满载着人类的创意和梦想…最后的最后，正如 WWDC 中 Apple 所言：

Be a dreamer. This is just the START.

SwiftUI 是 Apple 新推出的一款能快速搭建页面的 framework。它采用的是声明式语法，简洁明了。

而且它是所见即所得的，你写的代码都能通过 Preview 实时的看到效果，这可以很大的节省开发者开发时间。当你开发一个复杂的项目，需要等待几分钟的时间去编译运行代码，只为了看一个 UILabel 字体大小或者颜色是否改变时，你就能体会到所见即所得的快乐了。

基础控件

当我们新建一个项目，选择 Interface 选择 SwiftUI 时，建好的项目会自带一个 ContentView，这是下面的默认代码：

struct ContentView: View {

    var body: some View {

        VStack {

            Image(systemName: "globe")

                .imageScale(.large)

                .foregroundColor(.accentColor)

            Text("Hello, world!")

        }

        .padding()

    }

}



struct ContentView_Previews: PreviewProvider {

    static var previews: some View {

        ContentView()

    }

}

ContentView 是需要我们根据需求修改代码的部分，下面的 ContentView_Previews 则是为了实时预览的。

Tips：如果注释ContentView_Previews，你会发现预览页面也会消失。

ContentView 代码说明

首先，可以看到 ContentView 有一个 body 的计算属性，该属性代表当前视图的内容。当你实现一个自定义 view 的时候，必须要实现该属性，否则代码会报错。

VStack 代表的是一个垂直布局。里面包含 Image 和 Text，两个控件垂直布局。padding 则代表当前视图外边距的间距。

Text 对应 UILabel

在 SwiftUI 中，用 Text 控件来展示静态文本。下面是它的代码示例：

Text("我是一个文本")

	.font(.title)

	.foregroundColor(.red)

	.frame(width: 100, alignment: .center)

    .lineLimit(1)

    .background(.yellow)

常用的属性基本就这几个：

• font：字体。如果想更加细致化的指定字体，可以用 system，.font(.system(size: 16, weight: .light))。
• foregroundColor：字体颜色。
• frame：控制文本的大小和对齐位置。这个不写的话默认是自适应宽高。如果仅指定宽度就是高度自适应，仅指定高度就是宽度自适应。
• lineLimit：指定行数，默认为 0，不限制行数。
• background：用来设置背景。比如背景形状、背景颜色等等。

Tips：SwiftUI 的布局简化了自动布局和弱化了 frame 指定具体数值的布局方式。默认都是自适应的，这一点和 Flutter 类似，大大提高了开发效率。

Image 对应 UIImageView

在 SwiftUI 中，Image 用来展示图像资源。下面是它的示例代码：

Image(systemName: "globe")

	.resizable()

	.aspectRatio(contentMode: .fit)

	.foregroundColor(.accentColor)

	.background(.red)

常用属性：

• resizable：可调整大小以适应当前布局。
• aspectRatio：调整缩放比。
• foregroundColor、background：参见 Text。

Button 对应 UIButton

在 SwiftUI 中，用 Button 来表示一个按钮。下面是它的示例代码：

Button {

    print("点击了按钮")

} label: {

    Text("按钮文本")

    Image(systemName: "globe")

}

.cornerRadius(10)

.background(.red)

.font(.body)

.border(.black, width: 2)

常用属性：

• font、foregroundColor、background 等属性与 Text 使用一致。
• label：用来自定义按钮的文本和图标。
• cornerRadius：设置圆角。
• border：设置边框。

总结

本文主要讲解了 SwiftUI 的三个基本控件 Text：用来展示静态文本；Image：用来加载图像资源；Button：用来展示按钮。以及三个控件的基本使用。希望通过此文大家可以对 SwiftUI 的语法有个基本的了解。

背景

最近项目中，需要做一个如图所示的倒计时控件，上网搜了一圈，发现大家的方法大同小异，都是把倒计时的秒，转换成时分秒然后拼接字符串，见下图

网上大部分采用的方法
juejin.cn/post/684490… 

在我的项目中，期望这个倒计时控件的format是可以自定义的，所以计算时分秒这样的方式，对于我的需求是不太灵活的

既然format需要自定义，那么很容易想到一个时间格式处理的类：DateFormatter

思路

后端返回的字段

init_time // 需要倒计时的时长，单位ms

format // 展示的倒计时格式

我们的需求其实非常明确，就是完成一个可以自定义format的倒计时label

那我们拆解一下整个需求：

• 自定format的label
  • Date自定义format显示
  • 指定Date自定义format显示
• 可以进行倒计时功能

那么我们怎么才能把要倒计时的时长，转换为时分秒呢？

• 直接计算后端给的init_time，算出是多少小时，多少分钟，多少秒
• 如果我从每天的零点开始计时，然后把init_time作为偏移量不就是我要倒计时的时间吗，而且这个可以完美解决需要自定义format的问题，Date可以直接通过 DateFormatter转化成字符串 

Date自定义format显示

let df = DateFormatter()

    

df.dateFormat = "hh:mm:ss"

  

print("🍀", df.string(from: Date()), "🍀\n\n")



输出：🍀 03:56:28 🍀

指定Date自定义format显示

let df = DateFormatter()



var calendar = Calendar(identifier: .gregorian)



let startOfDate = calendar.startOfDay(for: Date())



df.dateFormat = "hh:mm:ss"



print("🍀", df.string(from: startOfDate), "🍀\n\n")



输出：🍀 12:00:00 🍀

完整功能

func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?) -> Bool {



        initCountdownTimer()



        return true



    }



  private var timer: DispatchSourceTimer?



  private var second = 0



  // 单位ms

  var delayTime = 0



  // 单位ms

  var interval = 1000

  var initSecound = 10

  

  var format = "hh:mm:ss"



  private lazy var startDate: Date = {

        var calendar = Calendar(identifier: .gregorian)

        let startOfDate = calendar.startOfDay(for: Date())

        return Date(timeInterval: TimeInterval(initSecound), since: startOfDate)

  }()



  private lazy var df: DateFormatter = {

        let df = DateFormatter()

        df.dateFormat = format

        return df

  }()



  func initCountdownTimer() {

        timer = DispatchSource.makeTimerSource(queue: .main)

        timer?.schedule(deadline: .now() + .milliseconds(delayTime), repeating: .milliseconds(interval), leeway: .milliseconds(1))

        timer?.setEventHandler { [weak self] in

            self?.updateText()

            self?.second += 1

        }



        timer?.resume()

    }



    func deinitTimer() {

        timer?.cancel()

        timer = nil

    }



    func updateText() {

        if second == initSecound && second != 0 {

            deinitTimer()

        }

        if second == initSecound {

            return

        }

        let date = Date(timeInterval: -TimeInterval(second + 1), since: startDate)

        let text = df.string(from: date)



        print(text)

    }

    

    输出：

    12:00:09

    12:00:08

    12:00:07

    12:00:06

    12:00:05

    12:00:04

    12:00:03

    12:00:02

    12:00:01

    12:00:00

以上整个功能基本完成，但是细心的同学肯定发现了，按道理小时部分应该是00，但是实际是12，这是为什么呢，为什么呢?

我在这里研究了好久，上网查了很多资料

最后去研究了foramt每个字母的意思才知道：

• h 代表 12小时制

• H 代表 24小时制，如果想要显示00，把"hh:mm:ss"改成"HH:mm:ss"即可

时间格式符号字段详见

本案例的目的是理解如何用Metal实现色彩空间转换效果滤镜，转换在不同色彩空间生成的图像；

Demo

• HarbethDemo地址
• iDay每日分享文档地址

实操代码

// 色彩空间转换滤镜

let filter = C7ColorSpace.init(with: .rgb_to_yuv)



// 方案1:

ImageView.image = try? BoxxIO(element: originImage, filters: [filter, filter2, filter3]).output()



// 方案2:

ImageView.image = originImage.filtering(filter, filter2, filter3)



// 方案3:

ImageView.image = originImage ->> filter ->> filter2 ->> filter3

效果对比图

• 不同参数下效果
  
  实现原理

• 过滤器

这款滤镜采用并行计算编码器设计.compute(kernel: type.rawValue)；

/// 色彩空间转换

public struct C7ColorSpace: C7FilterProtocol {

    

    public enum SwapType: String, CaseIterable {

        case rgb_to_yiq = "C7ColorSpaceRGB2YIQ"

        case yiq_to_rgb = "C7ColorSpaceYIQ2RGB"

        case rgb_to_yuv = "C7ColorSpaceRGB2YUV"

        case yuv_to_rgb = "C7ColorSpaceYUV2RGB"

    }

    

    private let type: SwapType

    

    public var modifier: Modifier {

        return .compute(kernel: type.rawValue)

    }

    

    public init(with type: SwapType) {

        self.type = type

    }

}

• 着色器

每条通道乘以各自偏移求和得到Y，用Y作为新的像素rgb；

kernel void C7ColorSpaceRGB2Y(texture2d<half, access::write> outputTexture [[texture(0)]],

                              texture2d<half, access::read> inputTexture [[texture(1)]],

                              uint2 grid [[thread_position_in_grid]]) {

    const half4 inColor = inputTexture.read(grid);

    

    const half Y = half((0.299 * inColor.r) + (0.587 * inColor.g) + (0.114 * inColor.b));

    const half4 outColor = half4(Y, Y, Y, inColor.a);

    

    outputTexture.write(outColor, grid);

}



// See: https://en.wikipedia.org/wiki/YIQ

kernel void C7ColorSpaceRGB2YIQ(texture2d<half, access::write> outputTexture [[texture(0)]],

                                texture2d<half, access::read> inputTexture [[texture(1)]],

                                uint2 grid [[thread_position_in_grid]]) {

    const half4 inColor = inputTexture.read(grid);

    

    const half3x3 RGBtoYIQ = half3x3({0.299, 0.587, 0.114}, {0.596, -0.274, -0.322}, {0.212, -0.523, 0.311});

    const half3 yiq = RGBtoYIQ * inColor.rgb;

    const half4 outColor = half4(yiq, inColor.a);

    

    outputTexture.write(outColor, grid);

}



kernel void C7ColorSpaceYIQ2RGB(texture2d<half, access::write> outputTexture [[texture(0)]],

                                texture2d<half, access::read> inputTexture [[texture(1)]],

                                uint2 grid [[thread_position_in_grid]]) {

    const half4 inColor = inputTexture.read(grid);

    

    const half3x3 YIQtoRGB = half3x3({1.0, 0.956, 0.621}, {1.0, -0.272, -0.647}, {1.0, -1.105, 1.702});

    const half3 rgb = YIQtoRGB * inColor.rgb;

    const half4 outColor = half4(rgb, inColor.a);

    

    outputTexture.write(outColor, grid);

}



// See: https://en.wikipedia.org/wiki/YUV

kernel void C7ColorSpaceRGB2YUV(texture2d<half, access::write> outputTexture [[texture(0)]],

                                texture2d<half, access::read> inputTexture [[texture(1)]],

                                uint2 grid [[thread_position_in_grid]]) {

    const half4 inColor = inputTexture.read(grid);

    

    const half3x3 RGBtoYUV = half3x3({0.299, 0.587, 0.114}, {-0.299, -0.587, 0.886}, {0.701, -0.587, -0.114});

    const half3 yuv = RGBtoYUV * inColor.rgb;

    const half4 outColor = half4(yuv, inColor.a);

    

    outputTexture.write(outColor, grid);

}



kernel void C7ColorSpaceYUV2RGB(texture2d<half, access::write> outputTexture [[texture(0)]],

                                texture2d<half, access::read> inputTexture [[texture(1)]],

                                uint2 grid [[thread_position_in_grid]]) {

    const half4 inColor = inputTexture.read(grid);



    const half3x3 YUVtoRGB = half3x3({1.0, 0.0, 1.28033}, {1.0, -0.21482, -0.38059}, {1.0, 2.21798, 0.0});

    const half3 rgb = YUVtoRGB * inColor.rgb;

    const half4 outColor = half4(rgb, inColor.a);



    outputTexture.write(outColor, grid);

}

色彩空间

• YIQ

在YIQ系统中，是NTSC（National Television Standards Committee）电视系统标准；

• Y是提供黑白电视及彩色电视的亮度信号Luminance，即亮度Brightness；
• I代表In-phase，色彩从橙色到青色；
• Q代表Quadrature-phase，色彩从紫色到黄绿色；

转换公式如下：

• YUV

YUV是在工程师想要在黑白基础设施中使用彩色电视时发明的。他们需要一种信号传输方法，既能与黑白 (B&W) 电视兼容，又能添加颜色。亮度分量已经作为黑白信号存在；他们将紫外线信号作为解决方案添加到其中。

由于 U 和 V 是色差信号，因此在直接 R 和 B 信号上选择色度的 UV 表示。换句话说，U 和 V 信号告诉电视在不改变亮度的情况下改变某个点的颜色。

或者 U 和 V 信号告诉显示器以牺牲另一种颜色为代价使一种颜色更亮，以及它应该移动多少。

U 和 V 值越高（或负值越低），斑点的饱和度（色彩）就越高。

U 值和 V 值越接近零，颜色偏移越小，这意味着红、绿和蓝光的亮度会更均匀，从而产生更灰的点。

这是使用色差信号的好处，即不是告诉颜色有多少红色，而是告诉红色比绿色或蓝色多多少。

反过来，这意味着当 U 和 V 信号为零或不存在时，它只会显示灰度图像。

如果使用 R 和 B，即使在黑白场景中，它们也将具有非零值，需要所有三个数据承载信号。

这在早期的彩色电视中很重要，因为旧的黑白电视信号没有 U 和 V 信号，这意味着彩色电视开箱后只会显示为黑白电视。

此外，黑白接收器可以接收 Y' 信号并忽略 U 和 V 颜色信号，使 YUV 向后兼容所有现有的黑白设备、输入和输出。

如果彩色电视标准不使用色差信号，这可能意味着彩色电视会从 B& 中产生有趣的颜色 W 广播，否则需要额外的电路将黑白信号转换为彩色。

有必要为色度通道分配较窄的带宽，因为没有可用的额外带宽。

如果某些亮度信息是通过色度通道到达的（如果使用 RB 信号而不是差分 UV 信号，就会出现这种情况），黑白分辨率就会受到影响。

YUV 模型定义了一个亮度分量 (Y)，表示物理线性空间亮度，以及两个色度分量，分别称为 U（蓝色投影）和 V（红色投影）。它可用于在 RGB 模型之间进行转换，并具有不同的颜色空间

转换公式如下：

最后

• 慢慢再补充其他相关滤镜，喜欢就给我点个星🌟吧。

✌️.

题目

给你一个二叉树的根节点 root，按 任意顺序，返回所有从根节点到叶子节点的路径。

叶子节点 是指没有子节点的节点。

示例 1：

• 输入：root = [1,2,3,null,5]
• 输出：["1->2->5","1->3"]

示例 2：

• 输入：root = [1]
• 输出：["1"]

提示：

• 树中节点的数目在范围 [1, 100] 内
• -100 <= Node.val <= 100

方法一：深度优先搜索

思路及解法

最直观的方法是使用深度优先搜索。在深度优先搜索遍历二叉树时，我们需要考虑当前的节点以及它的孩子节点。

• 如果当前节点不是叶子节点，则在当前的路径末尾添加该节点，并继续递归遍历该节点的每一个孩子节点。
• 如果当前节点是叶子节点，则在当前路径末尾添加该节点后我们就得到了一条从根节点到叶子节点的路径，将该路径加入到答案即可。

如此，当遍历完整棵二叉树以后我们就得到了所有从根节点到叶子节点的路径。当然，深度优先搜索也可以使用非递归的方式实现，这里不再赘述。

代码

class Solution {

    func binaryTreePaths(_ root: TreeNode?) -> [String] {

        var paths: [String] = []

        constructPaths(root, "", &paths)

        return paths

    }

    

    func constructPaths(_ root: TreeNode?, _ path: String, _ paths: inout [String]) {

        if nil != root {

            var path = path

            path += String(root!.val)

            if nil == root?.left && nil == root?.right {

                paths.append(path)

            } else {

                path += "->"

                constructPaths(root?.left, path, &paths)

                constructPaths(root?.right, path, &paths)

            }

        }

    }

}

复杂度分析

• 时间复杂度：$�({�}^2)$O(N2)，其中 $�$N 表示节点数目。在深度优先搜索中每个节点会被访问一次且只会被访问一次，每一次会对 $���ℎ$path 变量进行拷贝构造，时间代价为 $�(�)$O(N)，故时间复杂度为 $�({�}^2)$O(N2)。

• 空间复杂度：$�({�}^2)$O(N2)，其中 $�$N 表示节点数目。除答案数组外我们需要考虑递归调用的栈空间。在最坏情况下，当二叉树中每个节点只有一个孩子节点时，即整棵二叉树呈一个链状，此时递归的层数为 $�$N，此时每一层的 $���ℎ$path 变量的空间代价的总和为 $�({\sum }_{�=1}^{�}�)=�({�}^2)$O(∑i=1Ni)=O(N2) 空间复杂度为 $�({�}^2)$O(N2)。最好情况下，当二叉树为平衡二叉树时，它的高度为 $\log �$logN，此时空间复杂度为 $�((\log �{)}^2)$O((logN)2)。

方法二：广度优先搜索

思路及解法

我们也可以用广度优先搜索来实现。我们维护一个队列，存储节点以及根到该节点的路径。一开始这个队列里只有根节点。在每一步迭代中，我们取出队列中的首节点，如果它是叶子节点，则将它对应的路径加入到答案中。如果它不是叶子节点，则将它的所有孩子节点加入到队列的末尾。当队列为空时广度优先搜索结束，我们即能得到答案。

代码

class Solution {

    func binaryTreePaths(_ root: TreeNode?) -> [String] {

        var paths: [String] = []

        if nil == root {

            return paths

        }

        var node_queue: [TreeNode] = []

        var path_queue: [String] = []

        

        node_queue.append(root!)

        path_queue.append(String(root!.val))

        

        while !node_queue.isEmpty {

            let node: TreeNode? = node_queue.removeFirst()

            let path: String = path_queue.removeFirst()

            

            if nil == node?.left && nil == node?.right {

                paths.append(path)

            } else {

                if nil != node?.left {

                    node_queue.append(node!.left!)

                    path_queue.append(path + "->" + String(node!.left!.val))

                }

                

                if nil != node?.right {

                    node_queue.append(node!.right!)

                    path_queue.append(path + "->" + String(node!.right!.val))

                }

            }

        }

        return paths

    }

}

复杂度分析

• 时间复杂度：$�({�}^2)$O(N2)，其中 $�$N 表示节点数目。分析同方法一。

• 空间复杂度：$�({�}^2)$O(N2)，其中 $�$N 表示节点数目。在最坏情况下，队列中会存在 $�$N 个节点，保存字符串的队列中每个节点的最大长度为 $�$N，故空间复杂度为 $�({�}^2)$O(N2)。

作为一名 iOS 开发人员，该平台有一些令人兴奋的特性和功能值得探索。 其中，小部件是我的最爱。 小部件已成为 iOS 和 macOS 体验中不可或缺的一部分，并且随着 SwiftUI 中引入的最新功能，它们现在变得更加强大。 在本文中，我们将探讨如何通过交互性和动画使小组件变得栩栩如生，使它们更具吸引力和视觉吸引力。 我们将深入探讨动画如何与小组件配合使用的细节，并展示新的 Xcode Preview API，它可以实现快速迭代和自定义。 此外，我们将探索如何使用熟悉的控件（如 Button 和 Toggle）向小部件添加交互性，并利用 App Intents 的强大功能。 那么让我们开始吧！

小部件中的交互性
小部件在单独的进程中呈现，它们的视图代码仅在归档期间运行。 为了使小组件具有交互性，我们可以使用 Button 和 Toggle 等控件。 但是，由于 SwiftUI 不会在应用程序的进程空间中执行闭包或改变绑定，因此我们需要一种方法来表示可由小部件扩展执行的操作。 App Intents 为此提供了一个解决方案，允许我们定义可由系统调用的操作。 通过导入 SwiftUI 和 AppIntents，我们可以使用接受 AppIntent 作为参数的 Button 和 Toggle 初始值设定项来执行所需的操作。

现在我们要为现有项目创建小组件。

相应地命名它。 请注意，禁用两个复选框

现在我将使用清单和按钮重写现有代码。

struct Provider: TimelineProvider {  

    func placeholder(in context: Context) -> SimpleEntry {  

        SimpleEntry( checkList: Array(ModelData.shared.items.prefix(3)))  

    }  

  

    func getSnapshot(in context: Context, completion: @escaping (SimpleEntry) -> ()) {  

        let entry = SimpleEntry(checkList: Array(ModelData.shared.items.prefix(3)))  

        completion(entry)  

    }  

  

    func getTimeline(in context: Context, completion: @escaping (Timeline<Entry>) -> ()) {  

        //var entries: [SimpleEntry] = []  



        // Generate a timeline consisting of five entries an hour apart, starting from the current date.  

        let data = Array(ModelData.shared.items.prefix(3))  

        let entries = [SimpleEntry(checkList: data)]  



        let timeline = Timeline(entries: entries, policy: .atEnd)  

        completion(timeline)  

    }  

}



struct SimpleEntry: TimelineEntry {  

    var date: Date = .now  



    var checkList: [ProvisionModel]  

}



struct InteractiveWidgetEntryView : View {  

    var entry: Provider.Entry  



    var body: some View {  

        VStack(alignment: .leading, spacing: 5.0) {  

            Text("My List")  

            if entry.checkList.isEmpty{  

                Text("You've bought all🏆")  

            }else{  

                ForEach(entry.checkList) { item in  

                    HStack(spacing: 5.0){  



                        Image(systemName: item.isAdded ? "checkmark.circle.fill":"circle")  

                        .foregroundColor(.green)  





                        VStack(alignment: .leading, spacing: 5){  

                            Text(item.itemName)  

                            .textScale(.secondary)  

                            .lineLimit(1)  

                            Divider()  

                        }  

                    }  

                }  

            }  

        }  

        .containerBackground(.fill.tertiary, for: .widget)  

    }  

}



struct InteractiveWidget: Widget {  

let kind: String = "InteractiveWidget"  

  

var body: some WidgetConfiguration {  

    StaticConfiguration(kind: kind, provider: Provider()) { entry in  

            InteractiveWidgetEntryView(entry: entry)  

        }  

        .configurationDisplayName("My Widget")  

        .description("This is an example widget.")  

    }  

}

提供的代码在 iOS 或 macOS 应用程序中使用 SwiftUI 定义小部件。 让我们分解代码并解释每个部分：

1. Provider：该结构体符合TimelineProvider协议，负责向widget提供数据。 它包含三个功能：
• placeholder(in:)：此函数返回一个占位符条目，表示首次添加小部件时的外观。 它使用派生自 ModelData.shared.items 的清单数组创建 SimpleEntry。
• getSnapshot(in:completion:)：此函数生成一个表示小部件当前状态的快照条目。 它使用派生自 ModelData.shared.items 的清单数组创建 SimpleEntry。
• getTimeline(in:completion:)：此函数生成小部件的条目时间线。 它使用派生自 ModelData.shared.items 的清单数组创建 SimpleEntry 实例的数组，并返回包含这些条目的时间线。
1. SimpleEntry：此结构符合 TimelineEntry 协议，表示小部件时间线中的单个条目。 它包含一个表示条目日期的日期属性和一个 checkList 属性，后者是一个 ProvisionModel 项的数组。
2. InteractiveWidgetEntryView：此结构定义用于显示小部件条目的视图层次结构。 它采用 Provider.Entry 类型的条目作为输入。 在 body 属性内部，它创建一个具有对齐和间距设置的 VStack。 它显示一个标题，并根据 checkList 数组是否为空，显示一条消息或迭代该数组以显示每个项目的信息。
3. InteractiveWidget：该结构定义小部件本身。 它符合Widget协议并指定了Widget的种类。 它提供了一个 StaticConfiguration，其中包含一个 Provider 实例作为数据提供者，并提供一个 InteractiveWidgetEntryView 作为每个条目的视图。 它还设置小部件的显示名称和描述。
4. Preview：此代码块用于在开发过程中预览小部件的外观。 它为 .systemSmall 大小的小部件创建预览，并提供 SimpleEntry 实例作为条目。 总的来说，此代码设置了一个使用 SwiftUI 框架显示清单的小部件。 小部件的数据由 Provider 结构提供，条目的视图由 InteractiveWidgetEntryView 结构定义。 InteractiveWidget 结构配置小部件并提供用于开发目的的预览。

还有按钮动作！

Apple 为此推出了 AppIntents！

我已经创建了视图模型和应用程序意图。

struct ProvisionModel: Identifiable{  

    var id: String = UUID().uuidString  

    var itemName: String  

    var isAdded: Bool = false  

  

}  

  

class ModelData{  

    static let shared = ModelData()  



    var items: [ProvisionModel] = [.init(  

    itemName: "Orange"  

    ), .init(  

    itemName: "Cheese"  

    ), .init(  

    itemName: "Bread"  

    ), .init(  

    itemName: "Rice"  

    ), .init(  

    itemName: "Sugar"  

    ), .init(  

    itemName: "Oil"  

    ), .init(  

    itemName: "Chocolate"  

    ), .init(  

    itemName: "Corn"  

    )]  

}

提供的代码包括两个数据结构的定义：ProvisionModel 和 ModelData。 以下是每项的解释：

ProvisionModel：该结构表示清单中的一个供应项。 它符合可识别协议，该协议要求它具有唯一的标识符。 它具有以下属性：

id：一个字符串属性，保存使用 UUID 生成的唯一标识符。 每个 ProvisionModel 实例都会有一个不同的 id。

itemName：表示供应项目名称的字符串属性。

isAdded：一个布尔属性，指示该项目是否已添加到清单中。 它使用默认值 false 进行初始化。

ModelData：此类充当数据存储和单例，提供对供应项的共享访问。 它具有以下组件：
共享：ModelData 类型的静态属性，表示类的共享实例。 它遵循单例模式，允许跨应用程序访问同一实例。

items：一个数组属性，包含表示供应项的 ProvisionModel 实例。 该数组使用一组预定义的项目进行初始化，每个项目都使用特定的 itemName 进行初始化。 ModelData.shared 实例提供对此数组的访问。
总的来说，此代码为清单应用程序设置了数据模型。 ProvisionModel 结构定义每个供应项的属性，包括其唯一标识符以及是否已添加到清单中。 ModelData 类提供对供应项列表的共享访问，并遵循单例模式以确保访问和修改数据的一致性。

现在是 appIntent 的时候了！

struct MyActionIntent: AppIntent{  

  

    static var title: LocalizedStringResource = "Toggle Task State"  

    @Parameter(title: "Task ID")  

    var id: String  

    init(){  



    }  



    init(id: String){  

    self.id = id  

}  

  

func perform() async throws -> some IntentResult {  

    if let index = ModelData.shared.items.firstIndex(where: { $0.id == id }) {  

        ModelData.shared.items[index].isAdded.toggle()  



        let itemToRemove = ModelData.shared.items[index]  

        ModelData.shared.items.remove(at: index)  



        DispatchQueue.main.asyncAfter(deadline: .now() + 2) {  

        ModelData.shared.items.removeAll(where: { $0.id == itemToRemove.id })  

        }  



        print("Updated")  

        }  



        return .result()  

    }  

}

提供的代码定义了一个名为 MyActionIntent 的结构，该结构符合 AppIntent 协议。 此结构表示在清单应用程序中切换任务状态的意图。 以下是对其组成部分的解释：

title（静态属性）：该属性表示操作意图的标题。 它的类型为 LocalizedStringResource，它是用于本地化目的的本地化字符串资源。

id（属性装饰器）：该属性用@Parameter装饰，表示需要切换的任务的ID。

init()：这是结构的默认初始化程序。 它不执行任何特定的初始化。

init(id: String)：此初始化程序允许您使用特定任务 ID 创建 MyActionIntent 实例。

Perform()（方法）：AppIntent 协议需要此方法，并执行与 Intent 相关的操作。
以下是其实施细目：
它检查 ModelData.shared.items 数组中是否存在与意图中提供的 ID 匹配的任务。

如果找到匹配项，它将使用toggle() 方法切换任务的isAdded 属性。 这会改变任务的状态。
然后，它创建一个局部变量 itemToRemove 来存储切换的任务。
使用remove(at:)方法和找到任务的索引从ModelData.shared.items数组中删除任务。
延迟 2 秒后，使用removeAll(where:) 和检查匹配 ID 的闭包从 ModelData.shared.items 数组中删除 itemToRemove。

最后，“Updated”被打印到控制台。
return .result()：该语句返回一个IntentResult实例，表示intent的完成，没有任何具体的结果值。
总的来说，此代码定义了一个意图，用于执行切换清单中任务状态的操作。 它访问 ModelData 的共享实例，以根据提供的 ID 查找和修改任务。

现在是时候用 AppIntents 替换图像了

Button(intent: MyActionIntent(id: item.id)) {  

    Image(systemName: item.isAdded ? "checkmark.circle.fill":"circle")  

    .foregroundColor(.green)  

    }  

.buttonStyle(.plain)

沙盒机制

概念

iOS 沙盒机制是一种安全策略，它将每个应用程序的数据和资源隔离在一个专用目录中，限制了应用程序访问其他应用程序或系统文件的能力，从而保护了用户数据和系统安全.

目录结构

For security purposes, an iOS app’s interactions with the file system are limited to the directories inside the app’s sandbox directory. During installation of a new app, the installer creates a number of container directories for the app inside the sandbox directory. Each container directory has a specific role. The bundle container directory holds the app’s bundle, whereas the data container directory holds data for both the app and the user. The data container directory is further divided into a number of subdirectories that the app can use to sort and organize its data. The app may also request access to additional container directories—for example, the iCloud container—at runtime.

👆大概内容讲的是出于安全考虑，iOS应用只能在当前APP的沙盒目录下与文件系统进行交互（读取、创建、删除等）.在APP安装时，系统会在当前APP的沙盒目录下创建不同类型不同功能的容器目录（Bundle、Data、iCloud）.Data Container又进一步被划分为Documents、Library、temp、System Data.沙盒目录结构如下图所示：

各目录描述如下图所示：

下面介绍一些关于文件系统中常用的API.

创建NSFileManager

// 1.创建实例

NSFileManager *fileManager = [[NSFileManager alloc] init];



// 2.获取单例

NSFileManager *fileManager = [NSFileManager defaultManager];



// 3.自定义

自定义NSFileManager实现一些自定义功能.

NSFileManager有一个delegate（NSFileManagerDelegate）属性，实现该协议的对象能够对文件的拷贝、移动等操作做更多的逻辑处理，同时能在这些操作发生错误时做一些容错的处理.

// 该协议用于控制文件/文件夹，是否允许移动、删除、拷贝.以及允许这些操作发生错误时进行额外的处理.

@protocol NSFileManagerDelegate <NSObject>



// 控制是否允许该操作：

// 以下每种方法都有一个NSURL和NSString的版本，URL和Path同作用的方法只会调用一次，并且优先调用URL的方法.如果两个方法都没实现，则实现系统的默认值YES.

// 其中srcURL/srcPath分别代表原(文件/文件夹)路径URL(file://xxx)/路径(xxx). xxx为完整路径.

// 其中dstURL/dstPath分别代表目标(文件/文件夹)路径URL(file://xxx)/路径(xxx). xxx为完整路径.



// 错误处理：

// 以下每种方法都有一个NSURL和NSString的版本，URL和Path同作用的方法只会调用一次，并且优先调用URL的方法.如果两个方法都没实现，则不处理错误.



@optional



/// Moving an Item



// 在移动文件/文件夹前调用，控制是否允许移动操作

// 如果两个方法都没有实现，系统默认YES即允许移动. 

- (BOOL)fileManager:(NSFileManager *)fileManager shouldMoveItemAtURL:(NSURL *)srcURL toURL:(NSURL *)dstURL;

- (BOOL)fileManager:(NSFileManager *)fileManager shouldMoveItemAtPath:(NSString *)srcPath toPath:(NSString *)dstPath;



// 移动失败时调用 处理错误信息

- (BOOL)fileManager:(NSFileManager *)fileManager shouldProceedAfterError:(NSError *)error movingItemAtURL:(NSURL *)srcURL toURL:(NSURL *)dstURL；

- (BOOL)fileManager:(NSFileManager *)fileManager shouldProceedAfterError:(NSError *)error movingItemAtPath:(NSString *)srcPath toPath:(NSString *)dstPath;



/// Copy an Item



// 在拷贝文件/文件夹前调用，控制是否允许拷贝操作

// 如果两个方法都没有实现，系统默认YES即允许拷贝. 

- (BOOL)fileManager:(NSFileManager *)fileManager shouldCopyItemAtURL:(NSURL *)srcURL toURL:(NSURL *)dstURL;

- (BOOL)fileManager:(NSFileManager *)fileManager shouldCopyItemAtPath:(NSString *)srcPath toPath:(NSString *)dstPath;



// 拷贝失败时调用 处理错误信息

- (BOOL)fileManager:(NSFileManager *)fileManager shouldProceedAfterError:(NSError *)error copyingItemAtPath:(NSString *)srcPath toPath:(NSString *)dstPath;

- (BOOL)fileManager:(NSFileManager *)fileManager shouldProceedAfterError:(NSError *)error copyingItemAtURL:(NSURL *)srcURL toURL:(NSURL *)dstURL;



/// Delete an Item



// 在拷贝文件/文件夹前调用，控制是否允许删除操作

// 如果两个方法都没有实现，系统默认YES即允许删除. 

- (BOOL)fileManager:(NSFileManager *)fileManager shouldRemoveItemAtPath:(NSString *)path;

- (BOOL)fileManager:(NSFileManager *)fileManager shouldRemoveItemAtURL:(NSURL *)URL;



// 删除失败时调用 处理错误信息

- (BOOL)fileManager:(NSFileManager *)fileManager shouldProceedAfterError:(NSError *)error removingItemAtPath:(NSString *)path;

- (BOOL)fileManager:(NSFileManager *)fileManager shouldProceedAfterError:(NSError *)error removingItemAtURL:(NSURL *)URL;



@end

考虑线程安全的问题，如果需要实现NSFileManagerDelegate协议，通常是新创建NSFileManager实例或是继承NSFileManager后新建实例，确保一个一个实例仅对应一个delegate.

创建文件/文件夹

/// 文件



// 创建文件，会覆盖已存在的文件内容.

// path: 文件路径.

// data: 文件内容.

// attr: 文件属性.例如：设置文件夹可读写权限、文件夹创建日期中.传入nil，则使用系统默认的配置.

// return: YES:文件存在或创建成功. NO:文件创建失败

- (BOOL)createFileAtPath:(NSString *)path 

                contents:(NSData *)data 

              attributes:(NSDictionary<NSFileAttributeKey, id> *)attr;



/// 文件夹



// url: 文件夹路径URL.

// createIntermediate: 是否自动创建目录中不存在的中间目录，如果设置为NO，仅仅会创建路径的最后一级目录，若任意中间路径不存在，该方法会返回NO.同时如果任意中间目录是文件也会失败.

// attributes: nil，则使用系统默认的配置.

// error: 错误信息.

// YES: 文件夹创建成功.YES: createIntermediates为YES且文件夹已存在. NO: 错误发生.

- (BOOL)createDirectoryAtURL:(NSURL *)url 

 withIntermediateDirectories:(BOOL)createIntermediates 

                  attributes:(NSDictionary<NSFileAttributeKey, id> *)attributes 

                       error:(NSError * _Nullable *)error;



// 同上

- (BOOL)createDirectoryAtPath:(NSString *)path 

  withIntermediateDirectories:(BOOL)createIntermediates 

                   attributes:(NSDictionary<NSFileAttributeKey, id> *)attributes 

                        error:(NSError * _Nullable *)error;

其他方式写入文件：NSData、NSString、All kinds Of Collections (写入plist).

删除文件/文件夹

删除操作是指将文件/文件夹从指定目录移除掉.

// 以file://xxx的形式删除文件/文件夹.

// srcURL: 原文件/文件夹目录URL

// dstURL: 目标目录URL.

// error: 错误信息.

// return: YES: 移动成功或URL为nil或delegate停止删除操作. NO: 错误发生.

- (BOOL)removeItemAtURL:(NSURL *)URL 

                  error:(NSError * _Nullable *)error;

// 同上，不过传入的是xxx完整路径.

- (BOOL)removeItemAtPath:(NSString *)path 

                   error:(NSError * _Nullable *)error;



// 将文件/文件夹移入到废纸篓，适用于Macos.iOS上使用会失败.

- (BOOL)trashItemAtURL:(NSURL *)url 

      resultingItemURL:(NSURL * _Nullable *)outResultingURL 

                 error:(NSError * _Nullable *)error;

                 

// 注意： 

// 1.如果删除的是文件夹，则会删除文件夹中所有的内容. 

// 2.删除文件前会调用delegate的-[fileManager:shouldRemoveItemAtURL:]或-[fileManager:shouldRemoveItemAtPath:]方法，用于控制能否删除.如果都没有实现，则默认可以删除. 

// 3.删除失败时会调用delegate的-[fileManager:shouldProceedAfterError:removingItemAtURL:]或-[fileManager:shouldProceedAfterError:removingItemAtPath:]方法，用于处理错误. 

// 如果2个方法都没有实现则删除失败.并且删除方法会返回相应的error信息. 

// 方法返回YES会认为删除成功，返回NO则删除失败，删除方法接收error信息.

文件/文件夹是否存在

// path: 文件/文件夹路径.

// isDirectory: YES: 当前为文件夹. NO: 当前为文件.

// return: YES: 文件/文件夹存在. NO: 文件/文件夹不存在.

- (BOOL)fileExistsAtPath:(NSString *)path 

             isDirectory:(BOOL *)isDirectory;



// 同上，不过不能判断当前是文件还是文件夹.

- (BOOL)fileExistsAtPath:(NSString *)path;

遍历文件夹

有时候我们并不知道文件的具体路径，此时就需要遍历文件夹去拼接完整路径.

/// 浅度遍历: 返回当前目录下的文件/文件夹（包括隐藏文件）.

// 默认带上了options: NSDirectoryEnumerationSkipsSubdirectoryDescendants.

// NSDirectoryEnumerationIncludesDirectoriesPostOrder无效，因为不会遍历子目录.

- (nullable NSArray<NSString *> *)contentsOfDirectoryAtPath:(NSString *)path 

																							        error:(NSError **)error



// url: 文件路径.

// keys: 预请求每个文件属性的key数组.如果不想预请求则传入@[]，传nil会有默认的预请求keys.

// options: 遍历时可选掩码.

// error: 错误信息.

- (nullable NSArray<NSURL *> *)contentsOfDirectoryAtURL:(NSURL *)url 

														 includingPropertiesForKeys:(nullable NSArray<NSURLResourceKey> *)keys 

																								options:(NSDirectoryEnumerationOptions)mask 

																									error:(NSError **)error



/// 深度遍历（递归遍历）: 返回当前目录下的所有文件/文件夹（包括隐藏文件）.

- (nullable NSDirectoryEnumerator<NSString *> *)enumeratorAtPath:(NSString *)path

- (nullable NSDirectoryEnumerator<NSURL *> *)enumeratorAtURL:(NSURL *)url 

																	includingPropertiesForKeys:(nullable NSArray<NSURLResourceKey> *)keys 

																										 options:(NSDirectoryEnumerationOptions)mask 

																								errorHandler:(nullable BOOL (^)(NSURL *url, NSError *error))handler

- (NSArray<NSString *> *)subpathsOfDirectoryAtPath:(NSString *)path 

                                             error:(NSError * _Nullable *)error;

- (NSArray<NSString *> *)subpathsAtPath:(NSString *)path;

获取文件夹

// iOS基本上都是使用NSUserDomainMask.



// 获取指定目录类型和mask的文件夹.类似于NSSearchPathForDirectoriesInDomains方法.

// 常用的directory：

// NSApplicationSupportDirectory -> Library/Application Support.

// NSCachesDirectory -> /Library/Caches.

// NSLibraryDirectory -> /Library.

- (NSArray<NSURL *> *)URLsForDirectory:(NSSearchPathDirectory)directory 

														 inDomains:(NSSearchPathDomainMask)domainMask



// 获取指定directory & domainMask下的文件夹.

// domain: 不能传入NSAllDomainsMask.

// url: 仅当domain = NSUserDomainMask & directory = NSItemReplacementDirectory时有效.

// shouldCreate: 文件不存在时 是否创建.

- (NSURL *)URLForDirectory:(NSSearchPathDirectory)directory 

                  inDomain:(NSSearchPathDomainMask)domain 

         appropriateForURL:(NSURL *)url 

                    create:(BOOL)shouldCreate 

                     error:(NSError * _Nullable *)error;

// 同上

FOUNDATION_EXPORT NSArray<NSString *> *NSSearchPathForDirectoriesInDomains(NSSearchPathDirectory directory, NSSearchPathDomainMask domainMask, BOOL expandTilde);

// 获取/temp目录

FOUNDATION_EXPORT NSString *NSTemporaryDirectory(void);

// 获取沙盒根目录

FOUNDATION_EXPORT NSString *NSHomeDirectory(void);

设置和获取文件/文件夹属性

// 获取指定目录下文件/文件夹的属性[NSFileAttributeKey].(https://developer.apple.com/documentation/foundation/nsfileattributekey).

- (nullable NSDictionary<NSFileAttributeKey, id> *)attributesOfItemAtPath:(NSString *)path 

                                                                    error:(NSError **)error;



// 为指定目录文件/文件夹设置属性.

- (BOOL)setAttributes:(NSDictionary<NSFileAttributeKey, id> *)attributes ofItemAtPath:(NSString *)path error:(NSError * _Nullable *)error;



// 基于NSDictionary提供的便利方法 //

@interface NSDictionary<KeyType, ObjectType> (NSFileAttributes)



// 文件大小

- (unsigned long long)fileSize;



// 文件创建日期

- (nullable NSDate *)fileCreationDate;

// 文件修改日期

- (nullable NSDate *)fileModificationDate;



// 文件类型.NSFileAttributeType

- (nullable NSString *)fileType;



// 文件权限掩码

- (NSUInteger)filePosixPermissions; // 位掩码 可见文件 _s_ifmt.h eg：S_IRWXU

/* File mode */

/* Read, write, execute/search by owner */

#define S_IRWXU         0000700         /* [XSI] RWX mask for owner */

#define S_IRUSR         0000400         /* [XSI] R for owner */

#define S_IWUSR         0000200         /* [XSI] W for owner */

#define S_IXUSR         0000100         /* [XSI] X for owner */

/* Read, write, execute/search by group */

#define S_IRWXG         0000070         /* [XSI] RWX mask for group */

#define S_IRGRP         0000040         /* [XSI] R for group */

#define S_IWGRP         0000020         /* [XSI] W for group */

#define S_IXGRP         0000010         /* [XSI] X for group */

/* Read, write, execute/search by others */

#define S_IRWXO         0000007         /* [XSI] RWX mask for other */

#define S_IROTH         0000004         /* [XSI] R for other */

#define S_IWOTH         0000002         /* [XSI] W for other */

#define S_IXOTH         0000001         /* [XSI] X for other */



// 当前文件/文件夹所处的文件系统编号

- (NSInteger)fileSystemNumber;

这两个方法可以拼接文件的引用URL -> file:///.file/id=fileSystemNumber.fileSystemFileNumber

// 当前文件/文件夹在文件系统中的编号

- (NSUInteger)fileSystemFileNumber;



// 是否是隐藏文件

- (BOOL)fileExtensionHidden;

...



@end

移动文件/文件夹

移动操作是将文件从一个位置移动到另一个位置.

// 以file://xxx的形式移动文件/文件夹.

// srcURL: 原文件/文件夹位置URL.

// dstURL: 目标位置URL.

// error: 错误信息.

// return: YES: 移动成功或manager的delegate停止移动操作. NO: 错误发生.

- (BOOL)moveItemAtURL:(NSURL *)srcURL 

                toURL:(NSURL *)dstURL 

                error:(NSError * _Nullable *)error;

// 同上，不过传入的是xxx完整路径.

- (BOOL)moveItemAtPath:(NSString *)srcPath 

                toPath:(NSString *)dstPath 

                 error:(NSError * _Nullable *)error;



// 注意：

// 1.srcURL/srcPath、dstURL/dstPath任意为nil会crash.

// 2.如果目标目录文件已存在会被覆盖.

// 3.移动文件前会调用delegate的-[fileManager:shouldMoveItemAtURL:toURL:]或-[fileManager:shouldMoveItemAtPath:toPath:]方法，用于控制能否移动.如果都没有实现，则默认可以移动.

// 4.移动失败时会调用delegate的-[fileManager:shouldMoveItemAtURL:toURL:]或-[fileManager:shouldMoveItemAtPath:toPath:]方法，用于处理错误.

// 如果2个方法都没有实现则移动失败.并且移动方法会返回相应的error信息.

// 方法返回YES会认为移动成功，返回NO则移动失败，移动方法接收error信息.

拷贝文件/文件夹

拷贝操作是将原文件从一个位置copy到另一个位置，类似于复制粘贴.

// 以file://xxx的形式拷贝文件/文件夹.

// srcURL: 原文件/文件夹/位置URL.

// dstURL: 目标位置URL.

// error: 错误信息.

// return: YES: 拷贝成功或manager的delegate停止拷贝操作. NO: 错误发生.

- (BOOL)copyItemAtURL:(NSURL *)srcURL 

                toURL:(NSURL *)dstURL 

                error:(NSError * _Nullable *)error;

// 同上，不过传入的是xxx完整路径.

- (BOOL)copyItemAtPath:(NSString *)srcPath 

                toPath:(NSString *)dstPath 

                 error:(NSError * _Nullable *)error;



// 注意:

// 1.srcURL/srcPath、dstURL/dstPath任意为nil会crash.

// 2.如果目标目录已经存在则会发生错误.

// 3.拷贝文件前会调用delegate的-[fileManager:shouldCopyItemAtURL:toURL:]或-[fileManager:shouldCopyItemAtPath:toPath:]方法，用于控制能否拷贝.如果都没有实现，则默认可以拷贝.

// 4.拷贝失败时会调用delegate的-[fileManager:shouldProceedAfterError:copyingItemAtURL:toURL:]或-[fileManager:shouldProceedAfterError:copyingItemAtPath:toPath:]方法，用于处理错误.

// 如果2个方法都没有实现则拷贝失败.并且拷贝方法会返回相应的error信息.

// 方法返回YES会认为拷贝成功，返回NO则拷贝失败，拷贝方法接收error信息.

参考资料

1. developer.apple.com/library/arc…
2. developer.apple.com/documentati…

好物推荐

1. OpenSim：用于快速定位模拟器中项目沙盒目录.

2. Flex：用于真机或模拟器Debug环境下调试.

本文将从以下两个层面解决iOS内存泄漏问题：

• 内存泄漏排查方法（工具）
• 内存泄漏原因分析（解决方案）

在正式开始前，我们先区分两个基本概念：

• 内存泄漏（memory leak）：是指申请的内存空间使用完毕之后未回收。 一次内存泄露危害可以忽略，但若一直泄漏，无论有多少内存，迟早都会被占用光，最终导致程序crash。（因此，开发中我们要尽量避免内存泄漏的出现）
• 内存溢出（out of memory）：是指程序在申请内存时，没有足够的内存空间供其使用。 通俗理解就是内存不够用了，通常在运行大型应用或游戏时，应用或游戏所需要的内存远远超出了你主机内安装的内存所承受大小，就叫内存溢出。最终导致机器重启或者程序crash。

简单来说：

一、排查方法

我们知道，iOS开发有“ARC机制”帮忙管理内存，但在实际开发中，如果处理不好堆空间上的内存还是会存在内存泄漏的问题。如果内存泄漏严重，最终会导致程序的崩溃。

首先，我们需要检查我们的App有没有内存泄漏，并且快速定位到内存泄漏的代码。目前比较常用的内存泄漏的排查方法有两种，都在Xcode中可以直接使用：

• 第一种：静态分析方法（Analyze）
• 第二种：动态分析方法（Instrument工具库里的Leaks）。一般推荐使用第二种。

1.1 静态内存泄漏分析方法：

• 第一步：通过Xcode打开项目，然后点击Product->Analyze，开始进入静态内存泄漏分析。 如下图所示：
  
  

• 第二步：等待分析结果。

• 第三步：根据分析的结果对可能造成内存泄漏的代码进行排查，如下图所示。
  
  

PS：静态内存泄漏分析能发现大部分问题，但只是静态分析，并且并不准确，只是有可能发生内存泄漏。一些动态内存分配的情形并没有分析。如果需要更精准一些，那就要用到下面要介绍的动态内存泄漏分析方法（Instruments工具中的Leaks方法）进行排查。

1.2 动态内存泄漏分析方法：

静态内存泄漏分析不能把所有的内存泄漏排查出来，因为有的内存泄漏发生在运行时，当用户做某些操作时才发生内存泄漏。这是就要使用动态内存泄漏检测方法了。

步骤如下：

• 第一步：通过Xcode打开项目，然后点击Product->Profile，如下图所示：
  
  
• 第二步：按上面操作，build成功后跳出Instruments工具，如上图右侧图所示。选择Leaks选项，点击右下角的【choose】按钮。如下图：
  
  
• 第三步：这时候项目程序也在模拟器或手机上运行起来了，在手机或模拟器上对程序进行操作，工具显示效果如下：
  
  

点击左上角的红色圆点，这时项目开始启动了，由于Leaks是动态监测，所以手动进行一系列操作，可检查项目中是否存在内存泄漏问题。如图所示，橙色矩形框中所示绿色为正常，如果出现如右侧红色矩形框中显示红色，则表示出现内存泄漏。

选中Leaks Checks,在Details所在栏中选择CallTree,并且在右下角勾选Invert Call Tree 和Hide System Libraries，会发现显示若干行代码，双击即可跳转到出现内存泄漏的地方，修改即可。

举个例子：

PS：AFHTTPSessionManager内存泄漏是一个很常见的问题：解决方法有两种：点击这里

二、内存泄漏的原因分析

目前，在ARC环境下，导致内存泄漏的根本原因是代码中存在循环引用，从而导致一些内存无法释放，最终导致dealloc()方法无法被调用。主要原因大概有一下几种类型：

2.1 ViewController中存在NSTimer

如果你的ViewController中有NSTimer，那么你就要注意了，因为当你调用

[NSTimer scheduledTimerWithTimeInterval:1.0 

                                 target:self 

                               selector:@selector(updateTime:) 

                               userInfo:nil 

                                repeats:YES];

• 理由：这时 target: self，增加了ViewController的retain count， 即self强引用timer，timer强引用self。造成循环引用。
• 解决方案：在恰当时机调用[timer invalidate]即可。

2.2 ViewController中的代理delegate

代理在一般情况下，需要使用weak修饰。如果你这个VC需要外部传某个delegate进来，通过delegate+protocol的方式传参数给其他对象，那么这个delegate一定不要强引用，尽量使用weak修饰，否则你的VC会持续持有这个delegate，直到代理自身被释放。

• 理由：如果代理用strong修饰，ViewController（self）会强引用View，View强引用delegate，delegate内部强引用ViewController（self）。造成内存泄漏。
• 解决方案：代理尽量使用weak修饰。

举个例子：代理一般用weak修饰，避免循环引用。

@class QiAnimationButton;

@protocol QiAnimationButtonDelegate <NSObject>



@optional

- (void)animationButton:(QiAnimationButton *)button willStartAnimationWithCircleView:(QiCircleAnimationView *)circleView;

- (void)animationButton:(QiAnimationButton *)button didStartAnimationWithCircleView:(QiCircleAnimationView *)circleView;

- (void)animationButton:(QiAnimationButton *)button willStopAnimationWithCircleView:(QiCircleAnimationView *)circleView;

- (void)animationButton:(QiAnimationButton *)button didStopAnimationWithCircleView:(QiCircleAnimationView *)circleView;

- (void)animationButton:(QiAnimationButton *)button didRevisedAnimationWithCircleView:(QiCircleAnimationView *)circleView;



@end





@interface QiAnimationButton : UIButton



@property (nonatomic, weak) id <QiAnimationButtonDelegate> delegate;



- (void)startAnimation; //!< 开始动画

- (void)stopAnimation; //!< 结束动画

- (void)reverseAnimation; //!< 最后的修改动画

2.3 ViewController中Block

在我们日常开发中，如果block使用不当，很容易导致内存泄漏。

• 理由：如果block被当前ViewController（self）持有，这时，如果block内部再持有ViewController（self），就会造成循环引用。
• 解决方案：在block外部对弱化self，再在block内部强化已经弱化的weakSelf

For Example：

    __weak typeof(self) weakSelf = self;



    [self.operationQueue addOperationWithBlock:^{



        __strong typeof(weakSelf) strongSelf = weakSelf;



        if (completionHandler) {

            

            KTVHCLogDataStorage(@"serial reader async end, %@", request.URLString);

            

            completionHandler([strongSelf serialReaderWithRequest:request]);

        }

    }];

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 来展示：