An introduction to iOS application architecture

reason

Engaged in iOS for more than a year, mainly engaged in QQ Wallet SDK development and Tenpay app maintenance, with the slowly familiar with the business, recently in the thinking of these two application architecture design ideas, just yesterday in the watch an iOS Daniel to the Terminal application architecture sharing, by hot iron, Below a brief talk about my understanding of iOS application architecture design, write bad or wrong place, welcome everyone to shoot bricks, we discuss together.

If you ask an iOS or Android app architecture, where do you go from there?

Do not rush to give your answer, you can first think in your mind for 3 minutes, and then look at the following what I want to say.

In fact, for the iOS client application architecture, the complexity is no less than the service side, but the focus and start point is not the same as the server. For example, the client application does not need to consider the service-side large concurrency problem, the normal app does not need to consider at all. Because I personally do Android for a long time, if you are an Android developer, you can focus on some of the architectural ideas I put forward, after all, regardless of what to do, the idea is interlinked, the means of implementation is different.

What are we talking about when we discuss the client application architecture?

In fact, most of the applications on the market is simply to go over and do the following things:

Simply put the API, show the page, and then jump to another place to tune the API, and then show the page.

The app is really the main thing to do these things, but the foundation of these things is to do the architecture to consider things.

• Calling the network API

• Page Show

• Local persistence of data

• Dynamic Deployment Scenarios

Above these four points, a little detail is:

• How do I make it easy for business development engineers to invoke network APIs securely? Then, as much as possible to ensure that users in a variety of network environment can have a good experience?

• How can pages be organized to minimize the coupling of business party code? Minimize the complexity of business-party development interfaces and improve their efficiency?

• How can the data be properly arranged locally when there is a need for local access? How to minimize performance consumption?

• iOS apps have an audit cycle, how can I present new content to users through non-release versions? How do I fix an emergency bug?

The above points are for the app, and some of the following are for the team to say:

• Collect user data to provide references for products and operations

• Reasonable organization of business modules developed by each business party, and related basic modules

• Daily build is automatically packaged to provide a product experience for testing observation performance

So when we talk about client application architectures, it's pretty much what we're talking about.

approach to architectural design

When everything is the hardest time to start, when you start to design and implement a layer of architecture and even the architecture of the entire app, there is a good chance of a temporary failure. No matter what method you adopt, the global view, the high code aesthetic ability, the flexible use of various design patterns must be through it.

The first step: figuring out what problems to solve and finding the necessary and sufficient conditions to solve them

You have to be clear about what you are going to do and what the business wants. Instead of architecting for architecture, it's not about changing the architecture to experience new technologies. It used to be MVC, and recently, MVVM, if the past MVC is a good architecture, there are no particularly big flaws, don't push it down and make it into MVVM.

It is important to understand the real and necessary conditions for business parties! This determines whether your architecture is easy enough to use. In addition, the less parameters are passed, the smaller the coupling is, the less expensive it will be to replace the module or upgrade the module.

Step Two: Problem classification, sub-module

Let's not say more about it.

The third step: to understand the dependencies between the problems, to establish a good module communication norms and design modules

The key is to establish a unified set of communication norms. It is important to note that there must be a unified set of communication norms, not two sets, not multiple sets. You have to stick to your values and don't swing. If a variety of norms come out, on the one hand there are unrealistic technical suspicion, on the other hand will also bring the disaster of follow-up maintenance.

Fourth step: Deduce the possible future trends, add new modules if necessary, and record more basic data for future needs

Many competent architects will consider the future of the architecture at this time, and consider what to do next after completing this round of architecture. A good architecture is a project that works in the current era, but it is definitely not a once and for all project. Software is life, and the architecture you make is the software that determines whether it is bumpy or happy in life.

Fifth step: Solve the most basic problem in the dependency relationship, implement the base module, and then stack the entire architecture with the base module.

This step is also a step in verifying that your previous design is justified, and as this step progresses, you are likely to encounter situations where the architecture needs to be adjusted. This stage must be fastidious and highly responsible to develop, do not muddle through, found that the structure of problems in time to adjust. Otherwise the cost of adjustment will be very big.

Sixth step: Dot, run unit test, run performance test, according to the data to optimize the corresponding place

You have to use this data to go to your leader credit, and you have to use that data to constantly adjust your architecture.

All in all, follow these principles: top-down design (1,2,3,4 step), bottom-up implementation (5), first measurement, and post-optimization (6).

What kind of architecture is a good architecture?

1. Neat code, clear classification

2. Get business parties started without documents, or with few documents

3. Ideas and methods should be unified, try not to diversify

4. No lateral dependencies, no cross-layer access as a last resort

5. There is a limit to where the business party is bound, and the flexible place to create the flexible conditions for the business parties

6. Easy to test, easy to expand

7. Keep a certain amount of advance

8. Fewer interfaces and fewer interface parameters

9. Performance

Here is a detailed explanation for each point:

Code neat, categorical, no common, no core

Code neat is the basic quality of every engineer, do not say you fix the problem of how good the solution, how fast, if the code is not neat, everything is useless. Because your code is for others to see, you have to see it yourself. If one day the structure changes, just change to this place, you easily can not understand. In addition, the broken window theory reminds us that if the code is not neatly classified, the entire architecture will become more and more chaotic with one-time expansion.

Categorical explicit literal meaning everyone must know, but there is another meaning, that is: Do not let a class or a module do two different things. If there is a class or a module to do two different things, on the one hand is not suitable for future expansion, on the other hand will also cause classification difficulties.

Get business parties started without documents, or with few documents

Who's going to read the docs, the business side they've been driven by the product manager so busy. So you want to make your API name as much readable as possible, for iOS, OBJC the language of the characteristics of this to achieve the ultimate, the function of the name long long, it does not matter.

Good function name:

-(Nsdictionary *) Exifdataofimage: (UIImage *) image atindexpath: (Nsindexpath *) Indexpath;

Bad function name:

-(ID) Exifdata: (UIImage *) image position: (ID) Indexpath callback: (id<errordelegate>) delegate;

Why bad?

1. Do not directly return ID or incoming ID, really not, with id<protocol> than ID good. If you can't even do this, think about whether your architecture is problematic.
2. To tell the business party what to preach, such as to send an image, then write the ofimage. If you want to pass the position, write the Indexpath, not the position.
3. There is no reason to pass on the delegate as a parameter, and there will be no case to do so. and delegate This parameter is not a sufficient and necessary condition for this function to solve the problem, if you find that you have to do so, it must be a problem with the architecture!

Ideas and methods should be unified, try not to diversify

There are many options for solving a problem, but once you have identified a scenario, do not use another scenario in a different place. When it comes to architecture, you have to always remember what it was that you decided to deal with this type of problem, and what your intentions were, not wavering. In addition, you initially set up this module must have an idea for a reason, to record your solution, do not then change a place you have a brilliant what, introduced other programs, resulting in heterogeneous.

If a framework solves the same kind of problem with a variety of different methods or classes, I think the architect of this architecture must have started without thinking clearly.

No lateral dependencies, no cross-layer access as a last resort

It is important to have no horizontal dependencies, which determines how much you will need to fix the architecture in the future. To achieve no horizontal dependency, this is a test of the architect's module classification capabilities and familiarity with the business.

Cross-layer access refers to the data flow to a module that has no docking relationship with itself. Sometimes cross-layer access is unavoidable, such as the network underlying signal from 2G to 3G into 4G, which is likely to require cross-layer notification to the view. But this situation is not much, once the emergence of the need to do everything in this layer or to the upper or lower, try not to cross-layer situation. Cross-layer access also increases coupling, and when a layer needs to be replaced, the involved faces are large.

There is a limit to where the business party is bound, and the flexible place to create the flexible conditions for the business parties

Doing this well depends on the experience of the architect. Architects must be able to differentiate between situations that require limited flexibility and those that need to create flexibility. For example, for the core data technology stack, ManagedObject can theoretically appear anywhere, which means that managedobject can be modified anywhere, This causes Managedobjectcontext to synchronize changes from various sources when synchronizing changes. This time it is necessary to limit the flexibility, only open a modified interface, do not expose any managedobject outside.

If we are designing a abtest-related API, we want to increase its flexibility. So that the business side can not only through the Target-action model to achieve abtest, but also can be implemented through block abtest, to the extent possible to meet the flexibility to reduce the cost of business parties.

Easy to test easy to expand

To achieve easy testing and expansion, it is necessary to increase the degree of modularity, to minimize dependencies, easy to mock. In addition, if it is a highly modular architecture, it will be very easy to expand.

Keep a certain amount of advance

Maintaining a modest technical advance makes it relatively easy to update your architecture.

In addition, the advance here is not only technical, but also the product. Who says the architect does not need to deal with the product manager, nothing more with the product manager to chat, listen to his vision of the future of the product, you can in a reasonable place for his imagination to leave a path.

Fewer interfaces and fewer interface parameters

Fewer interfaces with fewer parameters can reduce the cost of using the business side. Of course, the necessary and sufficient conditions are still to be satisfied, how to reduce the number of interfaces and parameters as much as possible if sufficient conditions are satisfied.

High Performance

Why is high performance ranked last?

High performance is important, but it is not the first consideration in the client architecture. The reasons are:

• The client business changes very quickly, the primary consideration when doing architecture is to facilitate the business party to quickly meet the product needs, so need to provide a simple and easy-to-use interface to the business side, rather than provide high-performance interface to the business party.

• The performance of the Apple platform is great, and under normal circumstances there are few user experience issues due to insufficient performance.

• The optimization of Apple platform is relatively limited, and even sometimes the use of fair bet means even unscrupulous sacrifice of stability, performance is likely to be only 100ms to 90ms Gap. 10% performance improvement is good for the service side, because the service is still hundreds of thousands of millions of traffic, hundreds of thousands of million 10ms is very impressive. But for the client's user, he could not perceive the difference between 10ms, if the 10s optimization to 9s users still have a certain sense, but 100ms to 90ms, I think, or do not toss.

But! Not important does not mean to do, about performance optimization There is a lot of learning, need to work slowly accumulate.

Epilogue

Look at the above content, ask again if you ask if there is an iOS or Android app architecture, from what aspects to think about it?

An introduction to iOS application architecture