Skip to content
This repository has been archived by the owner on Oct 4, 2019. It is now read-only.

Class filtering : we need to go deeper

PaulTaykalo edited this page Nov 13, 2012 · 3 revisions

You need to know about this.
When Dynamic Code Injection is enabled on project, then 'ALL' objects will have swizzled -(id)init and -(void)dealloc methods.
Actually... NSObject's -(id)init and -(void)dealloc methods are swizzled. This is the way how dyci works. We need this to notify objects that already exists in memory about injections.

But... we don't need this logic in some 'Specific' classes. Reasons can be varied. Some classes simply doesn't work with swizzled methods.. Using this logic in other classes can lead to big overhead.

Currently, NSObject+DYCInjection category have + (BOOL)shouldPerformRuntimeCodeInjectionOnObject:(id)instance; method that will return NO on objects that have classes with next prefixes:

  • _ (Some specific private classes)
  • CF - Core Foundation Classes (Filtered because it wont' work correctly with dyci)
  • CA - Core Animation Classes (Filtered to remove overhead)
  • NS - Foundation Classes (Filtered to remove overhead)
  • UI - UIKit Classes (Filtered to remove overhead)
  • Web - WebKit Classes (Filtered because of incorrect work with dyci, and to remove overhead)
Clone this wiki locally