preface

Using string + Runtime to decouple the named domain level is extreme, the code is hard core, and the data type is hard to determine, which is also the weakness of Objc’s own dynamically weakly typed language.

Have done quite long iOS, I am in front of the article on the basis of the analysis of a few of their own experience, such as inappropriate place, you can correct ha. Demo address

I’ve designed an architecture before

In the component

  • 1. Normal business module, nothing to say, can write UI, business logic, tools such as this

  • 2.AppDelegate is a receiving class in this module, which is responsible for decoupling the mixed business of the main project. For example, the share component can put events such as share key registration into this class

  • 3.ActionService classification is equivalent to an interface exposed by the component. We use macros to standardize its naming and then use router to call it.

      UCACTION_SERVICE_EXTERN_METHOD(ModuleA, getVC, argu) {
      	return [ModuleAVC new];
      }
    Copy the code

UCACTION_SERVICE_EXTERN_METHOD is a macro that concatenates the component name and method name into an object method.

Outside the component

  • Call UCROUTER_OPEN_NATIVE(ModuleA, getVC, nil) by typing the component name, interface name, or pass it if there are no parameters.

  • 2.AppDelegateExchange Is responsible for exchanging methods in UCAppDelegateReduce and appDelegate, a widget I wrote, and then following its own lifecycle into each component’s appDelegate implementation, supporting displacement enumeration configurations, supporting Swift .

    + (void)load { UCAppDelegateMethodExchangeManager *manager = [UCAppDelegateMethodExchangeManager share]; UCAppDelegateConfigModel *model1 = [[UCAppDelegateConfigModel alloc] [[UCAppDelegateConfigModel alloc] initWithModuleName:@"ModuleAAppDelegate" sendMessageType:didFinishLaunchingWithOptions]; UCAppDelegateConfigModel *model2 = [[UCAppDelegateConfigModel alloc] initWithModuleName:@"ModuleBAppDelegate" sendMessageType:handleOpenURL | didFinishLaunchingWithOptions]; [manager startExchangeMethodWithOriginalAppDelegateName:@"AppDelegate" newModuleAppDelegateConfigArray:@[model1, model2]]; }Copy the code
  • ActionService is an empty class, and each component implements one of its classes as an external interface.

Recent experience of disassembling components in the project

Recently, when I was dismantling the login module in the main project, I wanted to make the decoupling mode of correct dependence and no dependence on Runtime. As long as the components are imported, it will import all the dependent components to achieve a complete function. This method is ideal, and I made it today.

In fact, new projects, new modules you do components well, as little as possible to rely on external, business disassembly point is not difficult to do. Open the old business is still very big, there are a lot of not belong to the login module but also integrated in the login file, I am drunk, it is a joke. If you import a, he relies on a lot of you have to think of some way to go to solve, this is a vicious circle, look at the name on this domain decoupling is lazy, but breaking old projects components or pretty good, I in order to correctly design rely on the other components are changed a lot, all does not belong to the business module clear away. Now you can import and log in and you can import dependent modules, it’s a complete function and you can run it.

conclusion

Therefore, we should consider his business responsibilities when writing the project, try to keep module responsibilities single, try to keep dependency vertical, if horizontal dependency or try to use router or protocol to solve it.

In addition, do not componentize in order to do componentize, you can put some business may be able to reuse can be dismantled.

If you want to disassemble, you can start from the Service layer, such as sharing, payment and map, which are relatively small with the business. After laying the foundation, it will be better to disassemble the business.

Finally, the idea of AppDelegate decoupling is quite good. His dynamic distribution is stable and easy to expand after more than 400 UT tests. This point can be used to see.