Problems to be solved in previous projects:
I The VC in the live broadcasting room has more than 20000 lines of code, and the decoupling problem; The existing problems are as follows:
1. all sub modules are held by VC in the form of attributes
2. after each sub module loads and processes the data, it calls back the results to the VC through the agent
3. UI events generated by sub modules (except the function of triggering public components) need to trigger the logic of other sub modules of the live studio VC, and they are also imported to the VC through proxy callback.
These three situations are the root causes of the unlimited expansion of VC code in the current live broadcasting room.
Solution: adopt protocol oriented programming to decouple and establish a component tree with tree structure.
1. the parent component uses the subcomponent structure to combine sub component modules, so that each sub module does not have to declare an attribute.
2. each sub component is exposed to other components in the component tree in the form of protocol, and can complete its own functions.
3. each subcomponent can find the component component of any specified protocol in the component tree through parentcomponentforprotocol and subcomponentforprotocol. In this way, even if each sub component needs to communicate with other component modules of the VC in the live room, it can be directly completed internally without any code callback to the VC in the live room.
4. because each component exposes its functions in the form of protocols, these protocols can be abstracted into a basic framework pod library, which perfectly solves the dependency between sub components.
II Targetaction used in project Modularization:(in contrast, as a module decoupling scheme, ctmediator has some problems worth discussing.)
1）CTMediatorUsing the runtime method, dynamically generating class and method selectors leads to type uncertainty. Methods and parameters are completely determined by strings and param dictionaries. The readability of the method itself is very poor and the reader is confused.
2) It is impossible to dynamically implement sub module route nesting and memory dynamic loading and dynamic release of sub routes
From the point of view of the author’s solution, they all feel troublesome. This categorypod is the protocol file provided by the independent function component module. Why not use the protocol directly.
III Solve the problem of the overflow of simple interest, which cannot be recovered
At present, the Componentization of different modules of the project (such as login module, recharge module, etc.) is realized by simple interest; But the problem of simple interest is that there is no dynamic memory load / release. If the login component is made, the recharge component can be implemented as a child component of the entire app root node. When a memory warning is received, the login succeeds or the recharge is completed. Release these child components.
IV Unit testing is more convenient
V After the code structure is clear, the bugs will be greatly reduced