Xcode12模板位置:
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/Library/Xcode/Templates/File Templates/iOS/Source/Cocoa Touch Class.xctemplate
1、设置导航栏为透明
self.navigationBar.setBackgroundImage(UIImage(), for: .default)
self.navigationBar.shadowImage = UIImage()
self.navigationBar.isTranslucent = true
2、bridging-header是swift刚出的时候，官方提供一种混编的方式。现在cocoapods 的版本已经支持swift 了，当你在安装pods的时候，添加下面这句话.
# Uncomment this line if you're using Swift
use_frameworks!
它在cocoa pods中已经对Swift进行了配置，所以可以直接使用,不需要创建bridging-header。
推荐swift项目学习：
U17
LBXMLYFM-Swift
3、必要构造器
我们可以通过required关键字来实现必要构造器，子类必须实现父类的必要构造器。
class Animal {
var name: String
required init(name: String) {
self.name = name
}
}
class Dog: Animal {
var foot: Int
//在重写父类必要构造器的时候不需要加override
required init(name: String) {
foot = 4
super.init(name: name)
}
}
Dog(name: "dog")
有一点需要注意的就是：如果子类继承的构造器能满足必要构造器的要求，则无须在子类中显式提供必要构造器的实现。
class Animal {
var name: String
required init(name: String) {
self.name = name
}
}
class Dog: Animal {
var foot = 2
}
Dog(name: "dog")
在我们日常开发中，我们会经常自定义UITableViewCell的子类来实现我们定制化的需求，如果我们没有实现required init?(coder aDecoder: NSCoder)方法的话，我们的代码是编译报错的。查看文档我们发现该方法为NSCoding的方法，且该方法为UIView 必要构造器，所以它的子类必须实现该方法。
class CustomTableViewCell: UITableViewCell {
override init(style: UITableViewCell.CellStyle, reuseIdentifier: String?) {
super.init(style: style, reuseIdentifier: reuseIdentifier)
}
required init?(coder aDecoder: NSCoder) {
fatalError("init(coder:) has not been implemented")
}
}
4、访问级别
Swift 为代码中的实体提供了五种不同的访问级别。这些访问级别不仅与源文件中定义的实体相关，同时也与源文件所属的模块相关。
open 和 public 级别可以让实体被同一模块源文件中的所有实体访问，在模块外也可以通过导入该模块来访问源文件里的所有实体。通常情况下，你会使用 open 或 public 级别来指定框架的外部接口。open 和 public 的区别在后面会提到。
internal 级别让实体被同一模块源文件中的任何实体访问，但是不能被模块外的实体访问。通常情况下，如果某个接口只在应用程序或框架内部使用，就可以将其设置为 internal 级别。
fileprivate 限制实体只能在其定义的文件内部访问。如果功能的部分实现细节只需要在文件内使用时，可以使用 fileprivate 来将其隐藏。
private 限制实体只能在其定义的作用域，以及同一文件内的 extension 访问。如果功能的部分细节只需要在当前作用域内使用时，可以使用 private 来将其隐藏。
open 为最高访问级别（限制最少），private 为最低访问级别（限制最多）。
open 只能作用于类和类的成员，它和 public 的区别主要在于 open 限定的类和成员能够在模块外能被继承和重写，在下面的 子类 这一节中有详解。将类的访问级别显示指定为 open 表明你已经设计好了类的代码，并且充分考虑过这个类在其他模块中用作父类时的影响。
5、pod不重新安装已有的库
pod install --no-repo-update
6、swift 闭包 循环引用
参考链接：
Swift闭包循环引用
Swift与OC真正去理解Block解决循环引用的技巧
7、Swift 5.1 - 字符串
Swift 5.1 (3) - 字符串
iOS Swift中String的常用操作以及数据转化
8、tableView.deselectRow(at: indexPath, animated: true) 注意事项
这里不单单取消选中，还会把cell所有的子控件设置为选中或者高亮
9、VC的便利构造方法
convenience init(type: ContentType) {
// 便利构造函数中 一定不会有super 对于属性的赋值 一般在self.init()之后 只有self被初始化后,才能对其进行赋值, 不能使用let修饰属性 var 并且告诉编译器其强制解包 一定有值
self.init()
self.type = type
}
override init(nibName nibNameOrNil: String?, bundle nibBundleOrNil: Bundle?) {
super.init(nibName: nibNameOrNil, bundle: nibBundleOrNil)
}
required init?(coder aDecoder: NSCoder) {
fatalError("init(coder:) has not been implemented")
}
10、实现TableView下拉关闭
let cv:CGFloat = -150 //下拉关闭数值
func scrollViewDidScroll(_ scrollView: UIScrollView) {
let offset = tableView.contentOffset.y;
print(message: offset)
if (offset < cv) {
close()
}
}
11、关于UILabel设置AttributedString以后末尾...不出现的问题
需要重新设置一次label的lineBreakMode属性
editLabel.attributedText = PublicTools.load_attributedString(model.editor_note.trimmingCharacters(in: .newlines), font: FMFont13, color: CFontColor8, alignment: .left, lineSpacing: kLabelSpace)
editLabel.lineBreakMode = .byTruncatingTail
12、当两个UILabel并排显示时，如何设置约束，让A或者B能显示你想要的需求，就需要用到下面两个约束
ContentHuggingPriority ==> 表示当前的Label的内容不想被拉伸
playCountLabel.setContentHuggingPriority(UILayoutPriority(rawValue: 1000), for: .vertical)
ContentCompressionResistancePriority ==> 表示当前的Label的内容不想被收缩
playCountLabel.setContentCompressionResistancePriority(UILayoutPriority(rawValue: 1000), for: .horizontal)
默认情况下: HuggingPriority == 250, CompressionResistancePriority == 750
12、@discardableResult的作用
在Swift中，当有返回值的方法未得到接收和使用时通常会出现警告
在正式编译中不会影响编译结果，但是也妨碍代码的美观整洁，在方法上加上“@discardableResult”就可以取消这个警告
@discardableResult
public func handleUrl(url: String, completion:
还有一种取消警告的方法，不加@discardableResult直接加通配符接收方法返回值
_ = XX
13、dynamic关键字
如果您有过OC的开发经验，那一定会对OC中@dynamic关键字比较熟悉，它告诉编译器不要为属性合成getter和setter方法。
Swift中也有dynamic关键字，它可以用于修饰变量或函数，它的意思也与OC完全不同。它告诉编译器使用动态分发而不是静态分发。OC区别于其他语言的一个特点在于它的动态性，任何方法调用实际上都是消息分发，而Swift则尽可能做到静态分发。
因此，标记为dynamic的变量/函数会隐式的加上@objc关键字，它会使用OC的runtime机制。
虽然静态分发在效率上可能更好，不过一些app分析统计的库需要依赖动态分发的特性，动态的添加一些统计代码，这一点在Swift的静态分发机制下很难完成。这种情况下，虽然使用dynamic关键字会牺牲因为使用静态分发而获得的一些性能优化，但也依然是值得的。
使用动态分发，您可以更好的与OC中runtime的一些特性（如CoreData，KVC/KVO）进行交互，不过如果您不能确定变量或函数会被动态的修改、添加或使用了Method-Swizzle，那么就不应该使用dynamic关键字，否则有可能程序崩溃。
