普通视图
Codable编解码数据时的一些边界问题
我正在参加「掘金·启航计划」
键名与属性名不匹配
Apple提倡开发者在编码时使用驼峰命名,如果后端返回的数据中字段采用的是蛇形命名,比如:
{
"nick_name": "张三",
"formal_name": "张老三"
}
那么我们要如何统一编码风格呢?
Apple贴心的为我们提供了不同的解码策略,其中就包含了处理这种字段使用蛇形命名方案的策略,只要在解码前置处理即可
JSONDecoder().keyDecodingStrategy = .convertFromSnakeCase
然而要使用这个方法,需要保证所有的 JSON 响应都遵守蛇形命名规则,然而问题在于,在不断地迭代当中,我们无法保证亲爱的后端同事会不会在某一个版本心血来潮地对命名规则做出调整。所以尽管这种方法很方便,但是并不可取。
更具有可持续性的策略是使用 CodingKeys 指定明确的映射。
extension Person {
private enum CodingKeys: String, CodingKey {
case nickName = "nick_name"
case formalName = "formal_name"
}
}
拓展: JSONDecoder为日期解析提供了一个方便的方法dateDecodingStrategy,我们可以根据后端返回的时间类型来指定合适的策略,直接在数据解析的过程当中,悄悄地将时间转为我们需要的。有兴趣的读者可以自行查阅。
空值处理
在JSON解析的过程中,遇到null是常事,Swift中可以将模型属性设为可选类型,比如var name: String? ,或者给定默认值var name: String = ""。
随机类型处理
相比JSONSerialization,Codable十分不灵活,几乎所有和 JSONSerialization 有关的字典都是 [String:Any] 类型的,把它变成 Decodable 类型有点困难。
假设我们需要一个这样的数据模型
struct Person: Decodable {
var name: String
var age: Int
var others: [String: Any]
}
当你建好了一个这样的数据模型,编译器不出意外的报错了,原因是[String: Any] 类型不遵循 Codable 协议,因为它的值类型 Any 不遵从 Codable。不幸的是, [String: Codable] 也不行,因为需要指定确切的类型。
如果我们明确所有数据的值都是一种类型的,比如说都是 String,那么把类型直接定义成 [String: String]就可以了。然而如果想要处理混合类型的值,甚至包括嵌套的数组和字典,那就只能寻找另外的解决方案了。
使用类型无关的AnyCodable 是一种解决方案,它的接口和 AnyHashable 差不多。
示例:
struct Person: Decodable {
var name: String
var age: Int
var others: [String: AnyDecodable]
}
参考
Combine:订阅、绑定和内存管理
我正在参加「掘金·启航计划」
sink
sink负责订阅Publisher,并返回一个AnyCancellabel。
完整签名:
public func sink(receiveCompletion: @escaping ((Subscribers.Completion<Self.Failure>) -> Void), receiveValue: @escaping ((Self.Output) -> Void)) -> AnyCancellable
它接受两个闭包回调做为参数,receiveCompletion 在发布结束事件时被调用,receiveValue 在发布值时被调用。
来自喵神《SwiftUI和Combine编程》中的发布-订阅流程图:
![]()
在使用 sink 完成订阅时,会创建一个特殊的 Subscriber 类型 Subscribers.Sink,并被纳入上面的流程中。它会自动声明想要接收无限多个新值,并订阅相应的 Publisher 对象。接下来,Publisher 会将新的值和结束事件作为参数传递给 sink 传入的两个闭包,从而将响应式的事件流转化为普通的指令操作。
Backpressure(背压)
Subscriber 可以在订阅初期通过 Subscription.request 或者通过 Subscriber.receive 返回特定的 Subscribers.Demand 值来指定能够处理的值的个数。这种背压机制 (Backpressure),可以让我们指定合适的背压策略,来控制可接收的值的上限,防止出现上游的发布速度超过下游消费速度的问题。
assign
Combine内建的另一个Subscriber就是assign,它可以用来将 Publisher 的输出值通过 key path 绑定到一个对象的属性上去。
使用assign时有几点需要注意的地方:
-
只有 class 上用 var 声明的属性才可以通过 assign 来直接赋值
-
上游 Publisher 的 Failure 的类型必须是 Never。如果上游 Publisher 可能会发生错误,必须先对它进行处理,比如使用
replaceError或者catch来把错误在绑定之前就处理掉。 -
在核心概念 中已经有过说明,使用
assign(to:on:)并存储生成的 AnyCancellable,可能会引起引用循环,所以请尽量使用assign(to:)来替代assign(to:on:)
引用共享
一个Publisher可能会有多个Subscriber,如果这个Publisher是一个网络请求的话,由于 dataTaskPublisher 是Struct,遵循值语义,多次订阅会复制多份,每一份都是一个新的Publisher,而这会造成多次请求,这是很浪费资源的。
解决上面问题的方法就是使用share()来共享Publisher。share()操作会把原来的Publisher包装到class内,对它的进一步变形也会适用于引用语义。
Cancellable & AnyCancellable
使用sink或者assign订阅Publisher时,会返回一个类型为AnyCancellable类型的值;而Timer在执行connect()操作后得到的是一个遵循Cancellable协议的值。
对于 Cancellable 来说,需要在合适的时候主动调用 cancel() 方法来完结。如果在没有调用 cancel() 的情况下就将 connect 的返回值忽略或者释放掉,那么Timer会一直计时,永远不会被终结掉。所以对于需要connect的Publisher,需要显式的调用cancel()来结束事件。
AnyCancellable 是一个 class,它可以对自身的生命周期进行管理。在 AnyCancellable 被释放时,它对应的订阅操作也会停止。
在应用中,我们会在实例当中创建一个Set<AnyCancellable>存储属性,并将sink或者assign返回的AnyCancellable存储其中。这样,当该实例 deinit 时,AnyCancellable 的 deinit 也会触发,并自动释放资源。这跟 RxSwift 中的 DisposeBag 很类似。
参考
王巍 《SwiftUI和Combine编程》
Combine:错误处理
Combine:核心概念
Combine: 概览
Combine: Debugging
使用 LLDB 提高开发中的调试效率
UITableView 性能优化
SwiftUI 学习之propertyWrapper
通过 Xcode 启动终端
使用过其他 IDE 的同学应该知道,大多数都集成了终端,而 Xcode 却没有。当我们要对一个项目执行命令行时,总要将项目拖到终端窗口中,这样很不方便。那如何使用 Xcode 一键启动终端并 cd 到当前项目目录呢?这篇文章就来介绍一种方案。
新建脚本文件:
编辑脚本文件:
#!/usr/bin/env bash
open -a iTerm "`pwd`"
脚本文件默认没有执行权限,启动终端,使用命令行
chmod +x <脚本路径>
赋予脚本权限。
在 Xcode → Preferences → Behaviors 中添加自定义 Open Terminal 选项,设置脚本路径及惯用快捷键
![]()
完成之后就可以在 Xcode中通过快捷键一键调起终端并 cd 到项目目录。
配置起来很简单,使用起来很划算哦😏
iOS 线程保活
- 小知识,大挑战!本文正在参与“程序员必备小知识”创作活动。
开发中,经常会遇到将耗时操作放到子线程中执行,来提升应用性能的场景。当子线程中的任务执行完毕后,线程就被立刻销毁。
如果开发中需要经常在子线程中执行任务,那么频繁的创建和销毁线程就会造成资源的浪费,这不符合我们的初衷。 此时就需要我们对线程进行保活,保证线程在应该处理事情的时候醒来,空闲的时候休眠。
我们知道 RunLoop 可以在需要处理事务的时候醒来执行任务,空闲的时候休眠来节省资源,利用这个特性就可以来处理线程的保活,控制线程的生命周期。
从探索到成功
- (void)viewDidLoad {
[super viewDidLoad];
LSThread *thread = [[LSThread alloc] initWithTarget:self selector:@selector(run) object:nil];
[thread start];
}
- (void)run {
NSLog(@"func -- %s thread -- %@", __func__, [NSThread currentThread]);
[[NSRunLoop currentRunLoop] run];
NSLog(@"--- 结束 ---");
}
LSThread 继承自 NSThread ,重写了 dealloc 方法
- (void)dealloc {
NSLog(@"%s", __func__);
}
执行之后的结果:
![]()
可以看到线程没能保活:
- 虽然启动了 RunLoop,依然执行了下面的结束 log
- 线程在执行完毕之后被销毁了
为了保证线程执行完毕不被销毁,可以强引用线程
self.thread = [[LSThread alloc] initWithTarget:self selector:@selector(run) object:nil];
[self.thread start];
但是这样并不能解决 RunLoop 问题。那么已经启动了 RunLoop,为什么并没有保持它的持续运行呢?
我们来看一下 run 方法的定义
If no input sources or timers are attached to the run loop, this method exits immediately.
意思是如果没有sources或timers附加到RunLoop,那么这个方法会立即退出。
那么我们给 RunLoop 添加一个 source 或者 timer 应该就可以解决这个问题了
[[NSRunLoop currentRunLoop] addPort:[[NSPort alloc] init] forMode:NSDefaultRunLoopMode];
再次运行并没有执行结束 log,线程保活成功。
![]()
下面继续来完善我们的需求。当持有线程的控制器销毁时,新建的子线程也应该跟着被销毁,在控制器里添加 dealloc
- (void)dealloc {
NSLog(@"--- 销毁控制器 --- %s", __func__);
}
在控制器出现时,创建子线程,控制器消失时控制台输出如下
![]()
控制器和子线程都没有被销毁。查看代码
self.thread = [[LSThread alloc] initWithTarget:self selector:@selector(run) object:nil];
这里控制器强引用了 thread,thread 又在内部持有了控制器 self,造成了引用循环。
那么要打破这个引用循环可以使用 Block
self.thread = [[LSThread alloc] initWithBlock:^{
NSLog(@"func -- %s thread -- %@", __func__, [NSThread currentThread]);
[[NSRunLoop currentRunLoop] addPort:[[NSPort alloc] init] forMode:NSDefaultRunLoopMode];
[[NSRunLoop currentRunLoop] run];
NSLog(@"--- 结束 ---");
}];
执行结果
![]()
控制器被成功释放,但是子线程并没有被销毁,那么这个子线程变成了一个全局性质的。到这里就要说一下 RunLoop 的启动了。
RunLoop 有三种启动方式
- (void)run;
- (void)runUntilDate:(NSDate *)limitDate;
- (void)runMode:(NSString *)mode beforeDate:(NSDate *)limitDate;
run 方法内部会在NSDefaultRunLoopMode模式下重复调用runMode:beforeDate:方法。
runUntilDate: 方法可以设置超时时间,在超时时间到达之前,RunLoop会一直运行,在此期间RunLoop会处理来自sources的数据,并且 像 run 一样,也会在NSDefaultRunLoopMode模式下重复调用runMode:beforeDate:方法。
runMode:beforeDate: 方法RunLoop会运行一次,超时时间到达或者第一个source被处理,则RunLoop就会退出。
关于 run 方法 Apple 文档中有说如果希望退出 RunLoop,不应使用此方法。
如果RunLoop没有input sources或者附加的timer,RunLoop就会退出。虽然这样可以将RunLoop退出,但是Apple不建议我们这么做,系统内部有可能会在当前线程的RunLoop中添加一些输入源,所以通过手动移除input source或者timer这种方式,并不能保证RunLoop一定会退出。
那么问题就很明了了,我们不应该使用 run 方法来启动 RunLoop,因为它创建的是一个不会退出的循环,使用这个方法的子线程自然无法被销毁。我们可以像run 一样利用runMode:beforeDate: 方法来创建一个符合我们条件的子线程:
[[NSRunLoop currentRunLoop] runMode:NSDefaultRunLoopMode beforeDate:[NSDate distantFuture]];
把它放到一个 while 循环中,利用一个是否停止 RunLoop 的全局标记来辅助处理线程的生命周期问题
__weak typeof(self) weakSelf = self;
self.thread = [[LSThread alloc] initWithBlock:^{
NSLog(@"func -- %s thread -- %@", __func__, [NSThread currentThread]);
[[NSRunLoop currentRunLoop] addPort:[[NSPort alloc] init] forMode:NSDefaultRunLoopMode];
// [[NSRunLoop currentRunLoop] run];
while (!weakSelf.isStopedThread) {
[[NSRunLoop currentRunLoop] runMode:NSDefaultRunLoopMode beforeDate:[NSDate distantFuture]];
}
NSLog(@"--- 结束 ---");
}];
停止 RunLoop 的方法
- (void)stop {
self.isStopedThread = YES;
CFRunLoopStop(CFRunLoopGetCurrent());
}
这里有一点需要注意,停止操作一定要在我们的目标线程执行,比如我们直接调用 stop 方法并不能达到我们预期的效果,这是因为stop 默认在主线程执行,没有拿到目标线程,停止无效。
- (void)stopAction {
[self performSelector:@selector(stop) onThread:self.thread withObject:nil waitUntilDone:YES];
self.thread = nil;
}
在当前线程调用stop ,我们的目的就达到了,顺利的结束了 RunLoop,线程也跟着销毁了。
![]()
Flutter 生命周期
如果曾对 iOS 中的 ViewController 有过接触,那就很容易理解生命周期在 UI 绘制中的重要作用。Flutter 中也存在生命周期,它的回调方法都体现在 State 中,源码参考。
Flutter 的生命周期分为页面(Widget)和 APP 两块。理解Flutter生命周期, 对写出一个合理的 Widget 和一个健壮的 APP 至关重要。
页面的生命周期
以 StatefulWidget 为例,来看一下 Flutter 页面的生命周期是怎样的。 Widget 的生命周期大体上可以分为三个阶段:
1. 初始化
createState
//这个方法是必须重写的
@override
_LifecycleWidgetState createState() => _LifecycleWidgetState();
当构建一个 StatefulWidget 时这个方法会被首先调用,而且这个方法是必须要重写的。
initState
@override
void initState() {
super.initState();
}
这个方法调用发生在 createState之后,是除构造方法之外,调用的第一个方法,它的作用类似于 Android 的 onCreate()和 iOS 的 viewDidLoad()。这个方法中通常会做一些初始化工作,比如 channel 的初始化、监听器的初始化等。
与 dispose() 相对应。
2. 状态改变
-
didChangeDependencies@override void didChangeDependencies() { super.didChangeDependencies(); }这个方法要求必须要调用父类的方法
super.didChangeDependencies,当依赖的 State 的对象改变时会调用。- 在第一次构建 Widget 时,在
initState()之后立即调用此方法。 - 如果 StatefulWidgets 依赖于 InhertedWidget,那么当当前 State 所依赖 InheritedWidget 中的变量改变时会再次调用它。
- 在第一次构建 Widget 时,在
-
build
@override
Widget build(BuildContext context) {
return Container();
}
是一个必须实现的方法,在这里实现要呈现的页面内容。它会在didChangeDependencies()之后立即调用,另外当调用 setState() 后也会再次调用这个方法
didUpdateWidget
@override
void didUpdateWidget(covariant LifecycleWidget oldWidget) {
super.didUpdateWidget(oldWidget);
}
调用 setState 将 Widget 的状态改变时 didUpdateWidget 会被调用,Flutter 会创建一个新的 Widget 来绑定这个 State,并在这个方法中传递旧的 Widget ,因此如果想比对新旧 Widget 并且对 State 做一些调整,可以使用它。
另外如果某些 Widget 上涉及到 controller 的变更,那么一定要在这个回调方法中移除旧的 controller 并创建新的 controller 监听。
3. 销毁
-
deactivate@override void deactivate() { super.deactivate(); }这个方法不常用,它会在组件被移除时调用,而且是在
dispose调用之前 -
dispose@override void dispose() { super.dispose(); }与
initState()对应。组件销毁时调用,通常该方法中执行一些释放资源的工作,如监听器的移除,channel 的销毁等,相当于 iOS 的
dealloc。方法参考
App 的生命周期
App 中会有比如从前台切入到后台再从后台切回到前台的场景,在 iOS 中这些生命周期都可以在 AppDelegate 中被体现,那么 Flutter 中我们该如何处理这些场景?对于 App 级别的生命周期与上述 Widget 生命周期相比,稍有不同。
如果想监听 App 的生命周期需要使用 WidgetsBinding 来监听 WidgetsBindingObserver,WidgetsBindingObserver是一个 Widgets 绑定观察器,通过它来监听应用的生命周期,使用混入的方式绑定观察器,并且需要在 dispose 回调方法中移除这个监听。
重写 didChangeAppLifecycleState ,当生命周期发生变化的时候会回调这个方法,
class _LifecycleAPPState extends State<LifecycleAPP>
with WidgetsBindingObserver {
@override
void initState() {
//添加监听
WidgetsBinding.instance!.addObserver(this);
super.initState();
}
@override
Widget build(BuildContext context) {
return Container();
}
@override
void didChangeAppLifecycleState(AppLifecycleState state) {
super.didChangeAppLifecycleState(state);
print(state);
}
@override
void dispose() {
// 移除监听
WidgetsBinding.instance!.removeObserver(this);
super.dispose();
}
}
Flutter 封装了一个枚举 AppLifecycleState 来描述 APP 的生命周期:
enum AppLifecycleState {
resumed, // 进入前台
inactive, // app 处于非活跃状态,并且未接收到用户输入的时候调用。比如接听来电
paused,// 进入后台
detached, // app 仍寄存在Flutter引擎上,但与原生平台分离
}
我们可以拿到这个 state 在 didChangeAppLifecycleState()来做一些我们需要的处理逻辑。