【原】iOS动态性(三) Method Swizzling以及AOP编程:在运行时进行代码注入

简介:

概述

今天我们主要讨论iOS runtime中的一种黑色技术,称为Method Swizzling。字面上理解Method Swizzling可能比较晦涩难懂,毕竟不是中文,不过你可以理解为“移花接木”或者“偷天换日”。

用途

介绍某种技术的用途,最简单的方式就是抛出一些应用场景来引出这种技术的必要性。因此,这里我举个例子如下。

假设工程中有很多ViewController,我需要你统计每个页面间跳转的次数。要求:对原工程的改动越少越好。

针对以上需求,你可能会立马想出以下两种方案:

方案一:

  在每个ViewController的 viewWillAppear 或者 viewDidAppear 方法中对记录跳转次数的某个全局变量(设为 g_viewTransCount )进行计数自增,代码应该是这样的:

1
2
3
4
5
- ( void )viewDidAppear:( BOOL )animated
{
     [ super  viewDidAppear:animated];
     g_viewTransCount++;
}

每个ViewController类中都需要做此操作,显然不合适。因为跳转次数统计这种业务与APP的主业务并没有强关联,上面的代码会造成耦合度过高。随着APP业务的不断扩大,代码中这样的杂质代码会越来越大,维护也越来越困难。而且该方案也违背了我们的要求:对原工程的改动越少越好。因此方案一是个很差的方法。于是我们有了方案二。

 

方案二:

  有没有某种方法可以不用对每个ViewCotroller都修改呢?有!让每个ViewController都继承某个新的ViewController(设为BaseViewController),然后将统计的代码放到BaseViewCotroller的 viewWillAppear或者viewDidAppear中。这种方案看似较合理,但有以下弊端:

  • 继承自BaseViewCotroller的ViewController中仍旧需要显式调用 [super viewDidAppear:animated]; 
  • 需要到所有ViewController的头文件中更改其superClass为BaseViewController

可见,方案二虽然相比方案一少一些看得到的“代码杂质”,但对工程的改动同样是巨大的,尤其当工程比较庞大时。

正因为以上方案的不完美,才引出本文的黑科技:Method Swizzling。

先概括一下在上述情景下使用Method Swizzling有哪些优势:

  • 不需要改动现有工程的任何文件
  • 本次统计的代码可复用给其他工程

实现

接下来就是激动人心的Coding Time了。让我们解开Method Swizzling的神秘面纱。直接上代码,有注释。在工程中新建一个UIViewController的category:

 

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
26
27
28
29
30
31
32
33
34
35
36
37
#import "UIViewController+swizzling.h"
#import <objc/runtime.h>
 
@implementation  UIViewController (swizzling)
 
+ ( void )load
{
     SEL  origSel =  @selector (viewDidAppear:);
     SEL  swizSel =  @selector (swiz_viewDidAppear:);
     [UIViewController swizzleMethods:[ self  class ] originalSelector:origSel swizzledSelector:swizSel];
}
 
//exchange implementation of two methods
+ ( void )swizzleMethods:(Class) class  originalSelector:( SEL )origSel swizzledSelector:( SEL )swizSel
{
     Method origMethod = class_getInstanceMethod( class , origSel);
     Method swizMethod = class_getInstanceMethod( class , swizSel);
     
     //class_addMethod will fail if original method already exists
     BOOL  didAddMethod = class_addMethod( class , origSel, method_getImplementation(swizMethod), method_getTypeEncoding(swizMethod));
     if  (didAddMethod) {
         class_replaceMethod( class , swizSel, method_getImplementation(origMethod), method_getTypeEncoding(origMethod));
     else  {
         //origMethod and swizMethod already exist
         method_exchangeImplementations(origMethod, swizMethod);
     }
}
 
- ( void )swiz_viewDidAppear:( BOOL )animated
{
     NSLog (@ "I am in - [swiz_viewDidAppear:]" );
     //handle viewController transistion counting here, before ViewController instance calls its -[viewDidAppear:] method
     //需要注入的代码写在此处
     [ self  swiz_viewDidAppear:animated];
}
 
@end

 

上述代码做了这么一件事:在UIViewController的viewDidAppear:方法调用前插入了跳页计数处理,这一切都在运行时完成。对于上述代码有以下几处需要介绍的:

 + (void)load 方法是一个类方法,当某个类的代码被读到内存后,runtime会给每个类发送 + (void)load 消息。因此 + (void)load 方法是一个调用时机相当早的方法,而且不管父类还是子类,其 + (void)load 方法都会被调用到,很适合用来插入swizzling方法

最核心的代码要数 + (void)swizzleMethods:(Class)class originalSelector:(SEL)origSel swizzledSelector:(SEL)swizSel 了。从函数签名可以看出,该函数是为了交换两个方法内部实现。将目光移到Line23,交换两个方法的内部实现主要依靠两个runtime API:

 

1
2
class_replaceMethod( class , swizSel, method_getImplementation(origMethod), method_getTypeEncoding(origMethod));
method_exchangeImplementations(origMethod, swizMethod);

 

  

 

再看一下Line32, - (void)swiz_viewDidAppear:(BOOL)animated 函数看起来像死循环,实际上不会的。原因请看我在下图的注释:

 

此外,通过断点可以进一步判断出view controller的viewDidAppear实际方法体与category的swiz_viewDidAppear方法的执行先后顺序。为了更直观地说明二者的顺序,我们可以看一下我打出的Log:

通过Log所打印出的顺序足以验证我们的想法。

以上的method swizzling可以应用于iOS的任何类中对其进行代码注入,并且丝毫不影响现有工程的代码。例如,我再举个例子(没办法,我就是喜欢举例子,但我无非是想让你掌握的更多一些)。你想统计整个工程中所有按钮的点击事件的次数,也就是touchUpInside event发生的次数。刚开始你可能会觉得稍微有些没有头绪,因为注入代码的“切入点”相比于UIViewController的viewDidLoad等方法而言不是那么好找。这时候如果你能仔细考虑以下问题或许能找到思路:

  • touchUpInside event发送给什么对象?
  • 该对象本通过什么途径接受这个消息?

第一个问题很好回答,event是发送给UIButton实例,本质上是发送给UIControl实例;

第二个问题你不懂的话就去看看UIControl的头文件找找线索,于是在头文件中我们找到这样一个函数:

 

1
- ( void )sendAction:( SEL )action to:( id )target forEvent:(UIEvent *)event;

 

看起来很靠近我们的需求, 事实上的确如此。这要从iOS的事件传递机制说起,当你在iOS设备上触摸一个点时这个触摸动作被包装成一个UIEvent按照UIApplication->UIWindow->UIView的顺序传递下去,当发现最后的接受者是UIControl时就会发送上述消息。因此,我们可以对sendAction:方法进行swizzling代码注入来达到统计按钮点击次数的目的。更深入一些,则需要针对不同的action、target、event的状态进行判断,以达到更精准的统计。关于这一部分内容我将在下一篇iOS动态性系列文章中详细探讨,敬请期待!

 

OK,文章就到这里,小伙伴们洗洗睡吧。哈哈,开个玩笑,俗话说,“好戏都在后头”,接下来的部分更好用。看来以上的method swizzling代码你是否觉得太复杂了?此外,当你尝试对多个类进行swizzle时会发现很多代码是冗余的,每个category文件的框架都长得差不多。那是否有进一步封装的可能性呢?那是必须的。庆幸的是有团队已经帮我们封装了,我们直接拿来用就可以。这就是有名的Aspect库。

AOP编程以及Aspect库

Aspect库是对面向切面编程(Aspect Oriented Programming)的实现,里面封装了Runtime的方法,也封装了上文的Method Swizzling方法。因此我们也可以看到,Method Swizzling也是AOP编程的一种。Aspect的用途很广泛,这里不具体展开,想了解更多的可以看一下官方github的介绍,已经够详细了。这里我们只介绍其基础应用。Aspect只提供了两个接口:

 

1
2
3
4
5
6
7
8
9
10
11
12
13
14
+ ( id <AspectToken>)aspect_hookSelector:( SEL )selector
                       withOptions:(AspectOptions)options
                        usingBlock:( id )block
                             error:( NSError  **)error {
     return  aspect_add(( id ) self , selector, options, block, error);
}
 
/// @return A token which allows to later deregister the aspect.
- ( id <AspectToken>)aspect_hookSelector:( SEL )selector
                       withOptions:(AspectOptions)options
                        usingBlock:( id )block
                             error:( NSError  **)error {
     return  aspect_add( self , selector, options, block, error);
}

 

使用起来也非常方便,使用Aspect对本文最初提出的需求“统计每个页面间跳转的次数”进行改造,代码变成这样子:

 

1
2
3
4
5
6
7
[UIViewController aspect_hookSelector: @selector (viewDidLoad)
                               withOptions:AspectPositionBefore
                                usingBlock:^( id <AspectInfo> info){
                                    g_viewTransCount++
                                    NSLog (@ "[ASPECT] inject in class instance:%@" , [info instance]);
                                }
                                     error: NULL ];

 

  

 

将以上代码放到AppDelegate的 didFinishLaunchingWithOptions 函数最开始处即可,你可以参考我在文末贴出的代码,使用一个专门的管理类来管理这些AOP代码。

相比于上半部分的原始Method Swizzling代码,使用Aspect有以下好处:

  • 原则上不需要新建任何文件。这点很好理解,原始Method Swizzling需要新建category文件,当代码注入的需要较多时会出现过多的文件以及冗余代码。
  • 可以对类的实例进行代码注入,因为Aspect提供了实例方法以及类方法

写在最后

Method Swizzling以及Runtime的一些特性就是iOS里的黑科技,如果能灵活应用的话可以在保证解决问题的前提下降低模块之间的耦合度,提高代码的可复用性。至于Method Swizzling与Aspect库的选择因人而异,我个人建议在最初阶段先放下Aspect而只用Method Swizzling原始代码去实现代码注入。掌握本质总是不吃亏的。

本文转自编程小翁博客园博客,原文链接:http://www.cnblogs.com/wengzilin/p/4704996.html,如需转载请自行联系原作者

相关文章
|
2月前
|
iOS开发 MacOS Perl
解决Xcode运行IOS报错:redefinition of module ‘Firebase‘和could not build module ‘CoreFoundation‘
解决Xcode运行IOS报错:redefinition of module ‘Firebase‘和could not build module ‘CoreFoundation‘
100 4
|
1月前
|
Swift iOS开发 UED
揭秘一款iOS应用中令人惊叹的自定义动画效果,带你领略编程艺术的魅力所在!
【9月更文挑战第5天】本文通过具体案例介绍如何在iOS应用中使用Swift与UIKit实现自定义按钮动画,当用户点击按钮时,按钮将从圆形变为椭圆形并从蓝色渐变到绿色,释放后恢复原状。文中详细展示了代码实现过程及动画平滑过渡的技巧,帮助读者提升应用的视觉体验与特色。
45 11
|
2月前
|
Swift iOS开发 UED
【绝妙创意】颠覆你的视觉体验!揭秘一款iOS应用中令人惊叹的自定义动画效果,带你领略编程艺术的魅力所在!
【8月更文挑战第13天】本文通过一个具体案例,介绍如何使用Swift与UIKit在iOS应用中创建独特的按钮动画效果。当按钮被按下时,其形状从圆形变化为椭圆形,颜色则从蓝色渐变为绿色;释放后,动画反向恢复原状。利用UIView动画方法及弹簧动画效果,实现了平滑自然的过渡。通过调整参数,开发者可以进一步优化动画体验,增强应用的互动性和视觉吸引力。
44 7
|
2月前
|
安全 测试技术 调度
iOS开发-多线程编程
【8月更文挑战第12天】在iOS开发中,属性的内存管理至关重要,直接影响应用性能与稳定性。主要策略包括:`strong`(强引用),保持对象不被释放;`weak`(弱引用),不保持对象,有助于避免循环引用;`assign`(赋值),适用于基本数据类型及非指针对象类型;`copy`(复制),复制对象而非引用,确保不变性。内存管理基于引用计数,利用自动引用计数(ARC)自动管理对象生命周期。此外,需注意避免循环引用,特别是在block中。最佳实践包括理解各策略、避免不必要的强引用、及时释放不再使用的对象、注意block中的内存管理,并使用工具进行内存分析。正确管理内存能显著提升应用质量。
|
2月前
|
开发工具 iOS开发
解决Flutter运行报错Could not run build/ios/iphoneos/Runner.app
解决Flutter运行报错Could not run build/ios/iphoneos/Runner.app
108 2
|
2月前
|
iOS开发
解决Flutter运行IOS报错:Podfile is out of date
解决Flutter运行IOS报错:Podfile is out of date
51 1
|
2月前
|
Android开发 iOS开发
[ionic]解决运行Android、IOS出现Could not find the web assets directory
[ionic]解决运行Android、IOS出现Could not find the web assets directory
28 1
|
3月前
|
移动开发 开发工具 Android开发
探索安卓与iOS开发的差异:平台特性与编程实践
【7月更文挑战第8天】在移动开发的广阔天地中,安卓和iOS这两大操作系统各自占据着半壁江山。它们在用户界面设计、系统架构及开发工具上展现出截然不同的特色。本文将深入探讨这两个平台在技术实现和开发生态上的关键差异,并分享一些实用的开发技巧,旨在为跨平台开发者提供有价值的见解和建议。
|
3月前
|
IDE 开发工具 Android开发
安卓与iOS开发环境对比分析:选择适合自己的编程平台
移动应用开发的两大阵营——安卓和iOS,各自拥有不同的开发环境和工具集。本文通过深入比较这两个平台的编程语言、集成开发环境(IDE)、用户界面设计、测试框架以及部署流程,旨在为开发者提供一个全面的视角来选择最符合个人或项目需求的开发环境。
|
4月前
|
安全 IDE Android开发
探索Android与iOS开发的差异:平台特性与编程实践
【6月更文挑战第17天】在移动应用开发的广阔天地中,Android和iOS两大平台各自占据半壁江山。它们在用户群体、系统架构以及开发环境上的差异,为开发者带来了不同的挑战和机遇。本文深入探讨了这两个平台在技术实现、界面设计、性能优化等方面的主要区别,并提供了实用的开发建议,旨在帮助开发者更好地理解各自平台的特性,从而创造出更加优秀的移动应用。