Skip to main content

Method Swizzling trong iOS với Swift 4


Method Swizzling là một thủ thuật siêu mạnh nhưng ít được biết tới và sử dụng (kiểu như phép thuật Hắc Ám trong Harry Potter) được cung cấp bởi Objective-C Runtime. Vì thế đương nhiên thủ thuật này có từ thời Objective-C và nay vẫn được sử dụng ngon lành với Swift.

Method Swizzling là gì?

Method Swizzling là thủ thuật giúp thay thế nội dung implement của một method có sẵn bằng nội dung khác tuỳ ý khi app đang chạy (runtime, khác với compile time). Thử lấy một ví dụ: UIColor có hàm description in ra giá trị RGBA. Hàm này được gọi khi ta thực hiện print.
print(UIColor.blue)
Output
UIExtendedSRGBColorSpace 0 0 1 1
Thay vì việc in ra giá trị RGBA ta muốn in ra giá trị Hex thì phải làm thế nào? Cách đơn giản nhất là viết 1 hàm tính ra Hex String rồi gọi trực tiếp hàm đó như sau:
extension UIColor {
    var hexString: String {
        var r: CGFloat = 0
        var g: CGFloat = 0
        var b: CGFloat = 0
        var a: CGFloat = 0
        getRed(&r, green: &g, blue: &b, alpha: &a)
        let rgb: Int = (Int)(r * 255) << 16 | (Int)(g * 255) << 8 | (Int)(b * 255) << 0
        return String(format: "#%06x", rgb)
    }
}

print(UIColor.blue.hexString)
Output :
#0000ff
Tuy nhiên ta không muốn phải gọi thêm .hexString mà muốn gọi print(UIColor.blue) cũng in ra Hex thì phải làm thế nào. Và đây là lúc cần dùng đến Method Swizzling.

Implement Method Swizzling như thế nào?

Ta sử dụng hàm method_exchangeImplementations để chuyển đổi implementation giữa 2 selector. Thực hiện hoán đổi implementation của description và hexDescription như đoạn code bên dưới.
extension UIColor {
    @objc func hexDescription() -> String {
        return hexString
    }
    func swizzleDesription() {
        if let aClass = object_getClass(self),
            let originalMethod = class_getInstanceMethod(aClass, #selector(getter: description)),
            let swizzledMethod = class_getInstanceMethod(aClass, #selector(hexDescription)) {
            method_exchangeImplementations(originalMethod, swizzledMethod)
            print("\nSwizzle\n")
        }
    }
}
Test thử hàm swizzleDesription ta vừa tạo ra.
let color = UIColor.blue
print("description: \(color)")
print("hexDescription: \(color.hexDescription())")

color.swizzleDesription()

print("description: \(color)")
print("hexDescription: \(color.hexDescription())")
Ta thu được output như bên dưới:
description: UIExtendedSRGBColorSpace 0 0 1 1
hexDescription: #0000ff

Swizzle

description: #0000ff
hexDescription: UIExtendedSRGBColorSpace 0 0 1 1
Vậy là 2 hàm description và hexDescription đã được hoán đổi implement lẫn nhau. Quá khủng phải không? Nếu ta swizzle thêm lần nữa thì sao?
let color = UIColor.blue
print("description: \(color)")
print("hexDescription: \(color.hexDescription())")

color.swizzleDesription()

print("description: \(color)")
print("hexDescription: \(color.hexDescription())")

color.swizzleDesription()

print("description: \(color)")
print("hexDescription: \(color.hexDescription())")
Implement của 2 hàm sẽ quay lại như ban đầu. Ta thu được output như bên dưới:
description: UIExtendedSRGBColorSpace 0 0 1 1
hexDescription: #0000ff

Swizzle

description: #0000ff
hexDescription: UIExtendedSRGBColorSpace 0 0 1 1

Swizzle

description: UIExtendedSRGBColorSpace 0 0 1 1
hexDescription: #0000ff

Ứng dụng Method Swizzling

Method Swizzling được sử dụng chủ yếu để thay đổi implement của những method trong standard library. Điều này cũng dễ hiểu vì với những method do ta viết ra, ta toàn quyền customize chúng thì cần gì phải swizzle nữa. Hàm description như ở ví dụ bên trên là 1 standard method của UIColor. Sau khi bị swizzle, implement của hàm bị thay đổi. Giả sử không chỉ đoạn code của ta, mà cả những đoạn code trong các framework, library mà ta sử dụng cũng dùng đến hàm description này, kết quả thu được có thể khác với những ý đồ mà framework, library đó mong muốn. Đây là con dao 2 lưỡi mà ta cần đặc biệt chú ý khi sử dụng Method Swizzling. Method Swizzling được khuyến cáo là không sử dụng quá 1 lần vì việc swizzle nhiều lần sẽ khiến ta không kiểm soát được đâu mới là implement thực sự của method, dẫn đến bug ngoài ý muốn. Theo mình nếu không thực sự cần thiết, ta nên tránh sử dụng Method Swizzling, có thể sử dụng để debug các static library, kiểm tra xem các method có được static library đó gọi hay không.


Comments

Post a Comment

Popular posts from this blog

Swift Tool Belt, Part 1: Adding a Border, Corner Radius, and Shadow to a UIView with Interface Builder

During my iOS work, I’ve assembled a set of code that I bring with me on every iOS project. I’m not talking about large frameworks or CocoaPods here. These are smaller Swift extensions or control overrides that are applicable to many projects. I think of them as my tool belt. In this post, I’ll show you an extension that will add a border, a corner radius, and a shadow to any UIView, UIButton, or UILabel and allow you to preview what it will look like in Interface Builder. Back in 2014, I wrote a blog post on Expanding User-Defined Runtime Attributes in Xcode where I added a border, corner radius, and shadow to a UIView using Interface Builder’s user-defined runtime attributes. This solution had no type checking—you had to type the property you wanted to modify by hand and often had to look up what it was called. You also had to run your project in order to see the effect of the runtime attribute. Starting with Xcode 6 , there is a new mech...
Post a Comment
Read more

Alamofire vs URLSession

Alamofire vs URLSession: a comparison for networking in Swift Alamofire and URLSession both help you to make network requests in Swift. The URLSession API is part of the foundation framework, whereas Alamofire needs to be added as an external dependency. Many  developers  doubt  whether it’s needed to include an extra dependency on something basic like networking in Swift. In the end, it’s perfectly doable to implement a networking layer with the great URLSession API’s which are available nowadays. This blog post is here to compare both frameworks and to find out when to add Alamofire as an external dependency. Build better iOS apps faster Looking for a great mobile CI/CD solution that has tons of iOS-specific tools, smooth code signing, and even real device testing? Learn more about Bitrise’s iOS specific solutions! This shows the real power of Alamofire as the framework makes a lot of things easier. What is Alamofire? Where URLSession...
Post a Comment
Read more

Frame vs Bounds in iOS

This article is a repost of an answer I wrote on Stack Overflow . Short description frame = a view’s location and size using the parent view’s coordinate system ( important for placing the view in the parent) bounds = a view’s location and size using its own coordinate system (important for placing the view’s content or subviews within itself) Details To help me remember frame , I think of a picture frame on a wall . The picture frame is like the border of a view. I can hang the picture anywhere I want on the wall. In the same way, I can put a view anywhere I want inside a parent view (also called a superview). The parent view is like the wall. The origin of the coordinate system in iOS is the top left. We can put our view at the origin of the superview by setting the view frame’s x-y coordinates to (0, 0), which is like hanging our picture in the very top left corner of the wall. To move it right, increase x, to move it down increase y. To help me remember bound...
Post a Comment
Read more