Swift中从动态加载的框架初始化类技术咨询

Got it, let's walk through how to dynamically load Dynamic1.framework and Dynamic2.framework into your mixed Objective-C/Swift Custom.framework using dlopen—all while aligning with the client app's framework usage to support their feature implementations. Here's a practical, actionable breakdown:

• First, ensure your third-party frameworks (Dynamic1.framework, Dynamic2.framework) are built as dynamic frameworks (static frameworks can't be loaded via dlopen).
• Since your Custom.framework uses both Objective-C and Swift, you'll need to handle interop between the two languages when resolving symbols from the loaded frameworks.

If part of your logic lives in Objective-C, here's how to load the frameworks and resolve their functions:

1. Use dlopen to load the framework bundle. You'll need the full path to the framework's binary (usually inside the client app's bundle or a custom location).

   NSString *frameworkPath = [[NSBundle mainBundle] pathForResource:@"Dynamic1" ofType:@"framework"];
   NSString *binaryPath = [frameworkPath stringByAppendingPathComponent:@"Dynamic1"];
   void *frameworkHandle = dlopen([binaryPath UTF8String], RTLD_LAZY);
   

2. Check if the load succeeded before proceeding:

   if (!frameworkHandle) {
       NSLog(@"Failed to load Dynamic1.framework: %s", dlerror());
       return;
   }
   

3. Resolve symbols (functions or classes) from the loaded framework. For example, to get a function pointer:

   typedef void (*Dynamic1FeatureFunc)(void);
   Dynamic1FeatureFunc featureFunc = (Dynamic1FeatureFunc)dlsym(frameworkHandle, "Dynamic1_RunFeature");
   if (featureFunc) {
       featureFunc(); // Execute the loaded function
   } else {
       NSLog(@"Failed to resolve symbol: %s", dlerror());
   }
   

4. Don't forget to unload the framework when you're done (optional, but good practice):

   dlclose(frameworkHandle);
   

For Swift parts of your framework, you'll use the same dlopen/dlsym APIs, but with Swift's type safety in mind:

1. First, bridge to the C APIs by importing Darwin:

   import Darwin
   

2. Load the framework similarly—note that Swift requires explicit handling of C strings:

   guard let frameworkPath = Bundle.main.path(forResource: "Dynamic2", ofType: "framework"),
         let binaryPath = URL(string: frameworkPath)?.appendingPathComponent("Dynamic2").path else {
       print("Could not find Dynamic2.framework path")
       return
   }
   
   let handle = dlopen(binaryPath, RTLD_LAZY)
   guard handle != nil else {
       print("Failed to load Dynamic2.framework: \(String(cString: dlerror()!))")
       return
   }
   

3. Resolve symbols using dlsym, and cast them to the appropriate Swift type. For a function that takes a string and returns an integer:

   typealias Dynamic2FeatureFunc = @convention(c) (UnsafePointer<CChar>) -> Int32
   if let sym = dlsym(handle, "Dynamic2_ProcessString") {
       let featureFunc = unsafeBitCast(sym, to: Dynamic2FeatureFunc.self)
       let input = "Test String"
       let result = featureFunc(input)
       print("Dynamic2 feature result: \(result)")
   } else {
       print("Failed to resolve symbol: \(String(cString: dlerror()!))")
   }
   

4. Clean up when finished:

   dlclose(handle)
   

To support the client app's framework-based feature implementations:

• Detect installed frameworks: Check if the client app has included Dynamic1/Dynamic2 in their bundle before attempting to load them. Use Bundle.main.url(forResource:withExtension:) to verify presence.
• Feature flagging: Expose APIs in Custom.framework that let the client enable/disable specific features based on which frameworks they've included. For example:

  // Objective-C API
  - (BOOL)supportsDynamic1Feature;
  

  // Swift API
  func supportsDynamic2Feature() -> Bool
  

• Handle missing frameworks gracefully: If a client doesn't include one of the dynamic frameworks, your Custom.framework should fall back to default behavior instead of crashing.

If Dynamic1/Dynamic2 include Swift code, note that Swift symbols are mangled (have unique prefixes like _$s). To resolve them:

• You can find the mangled name using nm -gU Dynamic1.framework/Dynamic1 in Terminal.
• Alternatively, if the third-party framework exposes Objective-C-compatible headers (using @objc), you can resolve classes via NSClassFromString instead of dlsym, which avoids dealing with mangled symbols.

• Test on both simulator and physical devices—framework paths can differ slightly.
• Validate edge cases: client app missing one framework, corrupted framework binary, symbol not existing in the framework.
• Use dlerror() liberally to debug loading/resolving issues—it's your best tool for troubleshooting.

内容的提问来源于stack exchange，提问作者Dmitry Simkin