With the development of the business or the growth of the project, in order to better maintain the code, at the end of the development of the project, some of the project’s public components and underlying services will be encapsulated. Recently, due to the development of a person responsible for a number of SDK, following the company may also continue to develop new SDK, for the development of every new SDK, if I were from the bottom of the base (network, analytical tools, etc.) to the business logic layer RE development, will need a lot of time, and will find different SDK in addition to the specific business logic is not the same thing in the development process, the other is basically the same. Therefore, the need for rapid trial and error to develop a SDK, then withdraw from the package based component library and public service imperative, or else the code copied to copy, it is easy to make mistakes, thankless work.
multi SDK architecture
The overall architecture idea is to pump out the common component library and the public service code library and make a generic libCommon.a for other SDK uses, which has a lot of benefits:
- A universal library is developed for a lifetime;
- For new SDK development, you only need to focus on the development of specific SDK business logic; save development time;
In the general base library, there are two parts, one is the common component library, the other is the public service module.
- Public service module: we usually only need the SDK section to start the business for us, or add some callback processing. His head file will only have one.
- Public module: there are many sub modules, such as data analysis, string handling, storage, network database and so on, so we need to open a lot of header files, so I think the first use Framework to encapsulate common components, and then let the libCommon.a to refer to Framework, finally I use this in SDK by libCommon.a Framework. The overall architecture will turn out as follows:
First of all, why do I want to make multiple public components into a Framework, because in that case, SDK does not need to add a lot of.H header files when it is called. The idea is very perfect, but the reality is very cruel, I am in the process of the realization of libCommon.a refers to a Framework, but I continue to use the time in my libSDK1.a, that will be in error (Undefined symbols for architecture x86_64), the methods defined in the Framework inside can not find the reason for this is. No files found at run time, so when the dynamic link to find a way out of the question. Here we need to understand the principles of compiling Static, Library, and Framework.
- Static Library compiles all the code into it at compile time;
- When the Framework compiler is the link function at the time of the call will go to look for, so in the compilation process inside the Framework assembly code is not compiled into libCommon.a, so we still need to call in the upper Framework, so here is not suitable for me to develop a scene, because I Framework package do not want to open, I only know and use internal.
, and finally I returned to the origin, compiled the public components into a static library, and then exposed multiple header files for processing.