学习 SwiftUI 肯定要看 View 协议，下面是 View 协议的相关代码。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

public protocol View {

    /// The type of view representing the body of this view.
    ///
    /// When you create a custom view, Swift infers this type from your
    /// implementation of the required ``View/body-swift.property`` property.
    associatedtype Body : View

    /// The content and behavior of the view.
    ///
    /// When you implement a custom view, you must implement a computed
    /// `body` property to provide the content for your view. Return a view
    /// that's composed of built-in views that SwiftUI provides, plus other
    /// composite views that you've already defined:
    ///
    ///     struct MyView: View {
    ///         var body: some View {
    ///             Text("Hello, World!")
    ///         }
    ///     }
    ///
    /// For more information about composing views and a view hierarchy,
    /// see <doc:Declaring-a-Custom-View>.
    @ViewBuilder var body: Self.Body { get }
}

协议中， Body 是一个关联类型，由实例属性 body 推断出来的。 body 是一个被 @ViewBuilder 修饰的，可读的实例属性。感到疑惑的就是 some View 到底是个什么东西，以及 @ViewBuilder 是干嘛的。

CPU 占用率 100 ，哪里出错了？

在写爬虫玩具的搜索页面时用了一个可以自动换行的 WrappingHStack, 最终实现的效果如图所示：

关键代码如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

@StateObject private var vm = SearchViewModel()
@State private var isShowDetailView = false
@State private var searchKey = "" // 1

var body: some View {
    NavigationView {
    VStack {
        NavigationLink(isActive: $isShowDetailView) {
                        HomeView(searchKey: searchKey) // 3
                    } label: {
                        EmptyView()
                    }
                    
        WrappingHStack(tags) { tag in
            // ... ...
        }
    }
    }
    .searchable(text: $searchKey) // 2
    .onSubmit(of: .search) {
        self.isShowDetailView = true
    }
}

虽然效果不错却发现点击搜索框后，只要互动就卡的不行，一旦更改了搜索框的文本，比如键入字母等操作，就会再次执行 body，最终导致 cpu 占用狂飙到 100。根本无法正常使用。

尝试用 SwiftUI 写了一个小玩具，在这期间参考了不少书籍，踩了不少坑。在完善玩具的途中，想着写一些文章记录一下。虽然自己 pc 也有有记录，但是传到个人博客上的文章在写的时候还是会费点心思，最起码格式会规范一些，也算是督促自己。 那么就以 SwiftUI Frame 为开篇吧。

Frame

在 UIKit 框架中的 frame 为 UIView 的一个属性，类型为 CGRect 的一个结构体。

而 SwiftUI 中 frame 则是两个函数，一个是不带理想值的版本，一个是有理想值的版本。这里暂且只看不带理想值的简短版本 frame(width:height:alignment:)，完整的函数声明是这样的：

1
2
3
4
5

func frame(
    width: CGFloat? = nil,
    height: CGFloat? = nil,
    alignment: Alignment = .center
) -> some View

之前我用过一些免费的图床，比如微博图床，然而后面有一些图片链接失效了。所以在没有长久有效的图床时，把图片放在本地的资源文件夹里不失为一种方法。

开启资源文件夹

修改 _config.yml 文件
post_asset_folder: true

这样在创建新文章的时候，同时也会创建一个与文字同名的文件夹。可以把一些资源文件放在这个文件夹里面，然后用相对路径来引用。

但是 hexo 的图片标签很奇怪{% asset_img slug [title] %} 远不如 md 标签 ![]() 简洁。

幸好，hexo 目前也支持了 md 图片标签，只是需要安装 hexo-renderer-marked 。

一直看动漫，而每一季度的番剧版权都很分散，于是手机上装了Acfun、 BiliBili、爱奇艺、优酷、搜狐视频等App。

在锁定竖屏时，这几个App在视频播放时，初始情况都为竖屏，点击旋转按钮切换为横屏。

用的时间久了就发现大家在播放视频时做屏幕强制旋转的方式都有点不一样。可以划分为两派：Acfun 、 BiliBili、爱奇艺 和 搜狐视频 转动的是播放视频的 view.transform ；优酷 转动的是 UIDevice 的 Orientation。

假如竖屏下以小视频播放，同时视频下有其他视图。那么这两种转动方式在 UI 上的差异为：

• 转动 view.transform 仅是视频图层转动，其他图层不转动。
• 转动 UIDevice 其他图层也会转动。

设置 estimatdItemSize

设置 layout 的 estimatdItemSize 预估高度
layout.estimatedItemSize = CGSizeMake(itemWidth, itemHeight);
默认值为 CGSizeZero ,给一个非0值开启高度估算。

如果我只是简单的播放一个视频，而不需要考虑播放器的界面。iOS9.0 之前使用 MPMoviePlayerController , 或者内部自带一个 view 的 MPMoviePlayerViewController . iOS9.0 之后，可以使用 AVPictureInPictureController, AVPlayerViewController, 或者 WKWebView。

以上系统提供的播放器由于高度的封装性， 使得自定义播放器变的很难。 所以，如果我需要自定义播放器样式的时候，可以使用 AVPlayer。 AVPlayer 存在于 AVFoundtion 中，更接近于底层，也更加灵活。

导航条影响 scrollView 及其子类的偏移量

在 iOS 开发中，我们有时候会遇到系统默认生成的一些布局 比如：如果 navigationBar下面直接是一个scrollView或者其子类。那么scrollView 及其子类 内部布局会从（0，64）开始，自动向下偏移64个点。 64pt = 状态栏高度20pt + 导航栏高度44pt。

如图所示：一个 tableViewController 被设置为 navigatiViewController 的根视图。

创建GitHubPages仓库

git 官方参考地址:https://pages.github.com

安装 hexo

hexo 官网帮助文档:官网帮助文档
根据提示安装 Homebrew ， Node.js ， 以及 hexo

hexo 建立本地站点

npm install 创建本地站点
hexo server 启动服务

创建新文章

hexo new "name"