# Thinking about “redundancy” in iOS architecture design
Those of you who do client development know that business needs are constantly changing, and you never know how they will change in the future. As a developer, you definitely don’t like requirements change. Originally said good, are almost finished, the product manager changed his mind: we don’t do so, you see me seventy-two changes.
We don’t want to be caught up in the complexity of change. The world is not so easy to steal lazy, if do not want to deal with the change. You need to get ahead of the change. Technology takes a step forward and stays ahead of the business, not behind it. This requires redundancy thinking. When doing business development, as a Coder, we need to think about how the business may change and whether the current program structure is flexible enough to facilitate adjustment. When business requirements adjust, they can be met with minimal cost. And this is “redundant” thinking.
Design for change, not just requirements.
I say “redundant” here, because the development test thought more than a few steps, but also pave the way for possible future changes. And some students insist that the program design to meet the current needs, not the concept of excessive design somewhat inconsistent. In my opinion, designing to meet current requirements is the way of traditional software development, which is no longer applicable in the process of Internet software development. Internet software products, especially those on terminals, have frequent version iterations and rapid function updates. It has been difficult to have stable demand, change is its essential feature. Therefore, we are required to make a certain design for this change when developing.
Look for patterns of change
Design mechanics instead of just meeting requirements
Mechanism and policy are separated
Let’s start with the idea of separating mechanism from strategy. What we want to design is a set of protocols that can meet the above requirements, followed by implementation, and finally specific application in our APP. This is also a very important summary of my year. This design is also reflected in several libraries that are becoming open source. To be more specific, a mechanism is an abstract set of rules, such as:
F of x is equal to x squared, and x is a member of RCopy the codePolicies are applied in specific scenarios, such as when x=2:
f(2)=4 x=2
Copy the codeIn the face of requirements, we need to start with what is on the surface and take a deeper look at what is changing beneath the requirements. For example, we’ve all dealt with tableView-related requirements.
At version 1.0, the product told you we were going to do feeds. Is there a display style that currently looks like this:
A few days after 1.0 was released, the product said our Feed presentation style was too simple. Now we need to support link skipping, Coders and if you look at the UI, it looks like this:
So we started adding new subclasses of UITableViewCell… Version 1.1 was released.
Versions 1.2, 1.3, 1.4… Finally one day I couldn’t stand it
This is where refactoring comes in. We start to pull out the common parts of the Feed and put them in the base class, using techniques such as class inheritance to control project complexity and improve development efficiency. At this point, we ask the question:
Could these refactorings be done earlier than 1.0?
There are, of course, two sides to this argument,
One side thinks that code corruption is an inevitable phenomenon accompanying project advancement, so it is not necessary to spend more labor to design in advance.
On the other hand, we firmly believe that there are certain laws behind everything. Although code corruption is an inevitable phenomenon, it can still be greatly slowed down by certain technical means. * * *
First of all, there’s no right or wrong here. If it’s right or wrong, it’s gonna be a war of words. Let’s just say I’m inclined to agree with the second view. In the early stage of project design, we can carry out software design by predicting the functional trend. Look beyond the surface UI and business logic to see the underlying change logic. This is exactly what I’ve been looking forward to: a good separation of mechanics and policy.
First of all, through the business logic on the surface, we can think deeply about the underlying change rules behind the business or function. Design libraries based on these rules, and then select appropriate strategies to apply in the current business. One more idea:
Design for change, not just requirements
Several real design cases for change
With the dry ideas out of the way, let’s take a look at some of the concrete applications that we’ve all enjoyed.
Talk is cheap, show me your code.
Increase the dynamics of the Client side or increase the interaction between CS
In general we think of client development as being very solid, very hard, and very difficult to change once it’s released. Especially iOS client, due to the restrictions of AppStore review, distribution is relatively difficult. A “hard” thing is not as easy to cope with change as a “soft” thing. This change may be a business requirement, a software BUG, or a sudden system crisis… .
Gold is folded with strength, water with softness. — Jin Ge Hong, Bao Pu Zi, Guang Myself
So in order to cope with these changes, we need to make our Client like water: it holds everything and doesn’t break. We need to give them the ability to do that. There are two strategies:
- Increase the interaction between CS, through the Server to issue instructions to operate the client
- Add client-side dynamics, such as JSPatch, and solutions like OCScript.
Let the client become like a robot that can accept instructions, and can flexibly respond to various needs and emergencies under the cooperation of the server.
dynamic
First of all, dynamics is something that the industry has been exploring. Webview-based solutions such as Hybird, RubyMotion and ReactNative, as well as Wexx by Alibaba team are all excellent attempts. ReactNative and Wexx, in particular, have recently been added to the technology stack by many teams to enable their clients to support dynamic release, often referred to as plug-in.
In the second half of last year, didi and shouq teams also launched two amazing schemes respectively, one is didi DynamicCocoa and the other is shouq OCScript. The compiler level is modified by delivering the intermediate language and running virtual machines of the corresponding language on the client to interpret and execute the corresponding language. Make the client look like a container for delivering business logic.
If we think purely from the perspective of business requirements, it may be difficult to come up with these solutions. The great gods behind these schemes also designed and constructed these institutional schemes after deep thinking. The dynamic support to do so deep, is also extremely awesome things. Expect them to open source.
Interactive client
The interactive client strategy is more like a scaled-down “dynamic” strategy. We preset some instructions in the client that we can respond to. When necessary, the server sends specific instructions to trigger the execution of the corresponding logic of the client. Enable clients to respond passively to business requirements and emergencies. Let’s talk about some specific applications:
Imperative caching
After we built the architecture of a server-client imperative interaction (where the server sends instructions to the client to perform certain actions), we did something interesting. For example, the command cache: the server sends the file cache instruction to the client, and the client cache the file after receiving the instruction.
Once we built this simple system, we did a lot of interesting things with it.
Reduce the size of secure packets by precaching
Interface development often uses a lot of image resources, especially PNG format resources, although it can be compressed, but some large size of Beijing resource pictures may reach hundreds of KB. This is also important for an IPA package.
Initially, we may have sacrificed user experience for package size. Use web resources for such images. This makes it difficult to ensure that when the user jumps to the screen, they see the correct background image in the first place. Even when the network is bad, the pictures can’t be downloaded at all.
So, we did something like this:
- Version 2.1 will introduce A, B, C three large – volume images
- Before version 2.1 was released, pre-cache instructions were issued to full clients: cache A, B, C images.
- After the release of version 2.1, when users enter the corresponding page after upgrading, they will directly read the corresponding picture from the local cache for display.
This allows for both user experience and reduced package size.
Reduce CDN stress by precaching
During the operation of the activity, especially during major holidays, once the user volume surges during the period after the release of the activity, CDN will be overloaded. A large number of users visit the page for the first time and download a large number of file resources. At this time, it is completely possible to issue the pre-cache instruction before the activity to alleviate the problem of CDN overload.
Dyeing log reporting
Log reporting is also an interesting directive in the list of directives supported by our client. When the client had a problem, we were at a loss at first. Later, Crash was reported, but only in the extreme case of Crash. There are a lot of cases where there is no Crash, but it is difficult to track when the user does something wrong, or the product logic itself has a problem. At this point we need to look at the logs in the production environment. This is a common strategy in server development.
So we built an instruction that, when fired, would use asymmetric encryption to upload the user’s local typed production Log to the specified address. This directive is user linked, and we issue instructions to a single user based on UID.
And then I can, through the admin side, get the corresponding Log, decrypt it and look at it. Look at possible problems in the production log.
Build operational clients
The idea of being operational comes from someone else’s writing. This means enabling your client to support the needs of the operations staff, dynamically changing what is displayed, and even function points. Although we do not release, we can support dynamic replacement of content and dynamic online and offline of function points. Even when certain functions are online, they can be dynamically added to the corresponding safeguard functions (such as logging, data reporting and other safeguard functions). Here’s the data part.
For the design of the data reporting function, scalability is the key consideration, because the requirements for the type of data cannot be determined at one time, and often new data requirements will be added as the product is iterated. At this time, if the new requirements can be fulfilled by adding data set codes at the target monitoring point without modifying the reporting module, it shows that the reporting system has good expansibility. Of course, this only adds the data reporting infrastructure on the client side, and the real operation depends on the team to build a powerful big data analysis platform. After the data is reported, it is just a pile of digital garbage, and the process that truly gives the digital garbage information value is analysis. Imagine that as a product manager, you will receive emails about product data when you arrive at the company every day, and you can see fresh data reports, zigzzging graphs, and dynamic combustion charts, etc. All of these will provide valuable support for your work and the products you are responsible for. You should be grateful to have such a good operation team.
Welcome to iOS development public account iOS development knowledge: scan the qr code below to follow
Copyright notice: please reserve the author’s information, malicious reprint the author will reserve the right to pursue legal responsibility. BY:yishuiliunian