Q&A

I. Project architecture

1.MVC, MVP and MVVM modes

MVC (Model, View, Controller)

MVC is a relatively intuitive architectural mode, and the core is to regulate through the Controller layer. First, take a look at the official MVC schematic diagram:

  • The Model and View can never talk to each other, only through the Controller

  • The Controller can talk directly to the Model (read/write calls to Model), and the Model communicates indirectly with the Controller through NOtification and KVO mechanisms

A Controller can talk to a View directly and manipulate the View directly through an IBoutlet that corresponds directly to the View’s controls (for example, creating a Button: Declare an IBOutlet UIButton * BTN), and the View reports the time to the Controller via an action (the user clicked the button). The Controller is the direct data source for the View

  • Advantages: There is a clear way to organize a project in a chaotic way. Control through Controller, and separate the View presentation from the Model changes

  • Disadvantages: Increasingly bulky Controller. With the increase of business logic, a large number of codes are put into the Controller, resulting in the Controller becoming more and more bloated and accumulating thousands of lines of code, which takes time and effort to maintain in the later stage

MVP (Model, View, Presenter)

MVP mode is an evolved version of MVC mode, in which Model is not much different from Model layer in MVC mode. It mainly provides data storage function and is generally used to encapsulate JSON data acquired by network. View has some differences with the View layer in MVC. The View layer in MVP can be viewController, View and other controls. The Presenter layer acts as an intermediary between the Model and the View, retrieving data from the Model layer and passing it to the View.

As you can see from the above figure, the Presenter layer is added from the MVC pattern to separate the complex business logic, network requests and so on from UIViewController.

  • Advantages The model and view are completely separated, and the view can be modified without affecting the model. More efficient use of the Model, View does not rely on Model, so it can be said that the View can achieve a complete separation of business logic

  • Disadvantages In Presenter, in addition to handling business logic, they also need to deal with the coordination of the View-Model two layers, which can lead to the redundancy of the Presenter layer

MVVM (Model, Controller/View, ViewModel)

In MVVM, the View and the ViewCOntroller are tied together, we treat them as one component, and neither the View nor the ViewCOntroller can refer directly to the Model, but rather to the ViewModel, the ViewModel. The viewModel is a place to put business logic, such as user input validation logic, view display logic, network request logic, etc. This design pattern slightly increases the amount of code, but reduces the complexity of the code

  • Advantages Views can be independent of Model changes and modifications, and a ViewModel can be bound to different views, reducing coupling and increasing reuse
  • Disadvantages Too simple projects are not suitable, large projects with too much view state are too costly to build and maintain

The rational use of architectural patterns is beneficial to the project and team development, but when it comes to which design pattern to choose and which design pattern is better, just as said at the beginning of this article, different design patterns only make different scenarios have more choices. Choose the most appropriate solution based on the project scenario and development requirements.

2. How have you applied RAC to resolve different API dependencies

Signal dependency: The usage scenario is that signal B will be executed only when signal A is finished, which is similar to request dependency. For example, request B will be executed only after request A is completed. We need to pay attention to signal A must be executed to send the completed signal, otherwise signal B cannot be executed

RACSignal * concatSignal = RACSignal * concatSignal = RACSignal * concatSignal = RACSignal * concatSignal = [self.signalA concat:self.signalB] // concatSignal subscribeNext:^(id x) {NSLog(@"%@",x);}];Copy the code

What is the difference between 3.@weakify and WeakSelf defined by our macro?

@Weakify can be used with multiple parameters

4. The architecture of microservices

The microservices architecture has the following advantages:

  • 1. Flexible and independent scalability

    Flexible scaling is one of the key advantages of microservices architecture. Unlike a monolithic architecture, each module can be horizontally extended and independent of other modules. Therefore, the microservices architecture is well suited for large projects.

  • 2. Independent technology stack

    In microservices architecture, software engineers have the opportunity to build apps using a variety of tools and technologies. The code can be written in different programming languages, which adds more flexibility to the APP development process.

  • 3. Better fault isolation

    If one service fails, it does not affect the functionality of other services. Compared to other architectural styles, in microservices, the system continues to work, and problems in monolithic mode affect the entire APP.

  • 4. Easy deployment and integration

    While developers must deploy the APP again even with small code changes, deployment becomes faster and easier in the microservices architecture.

    Because all services are built around a single business process, programmers don’t have to modify and redeploy the entire APP, just the areas you need. Therefore, it is relatively easy to improve the product.

    Microservices can be deployed independently through the automatic deployment mechanism. In addition, by using open source continuous integration tools, developers greatly simplify integration with third-party services.

  • 5. Easy to understand

    Another advantage of microservices architecture is that it is easy to understand how the system works and how it was developed. When a new regiment

    This is especially useful when team members come to the project and have to dig into it quickly. So how to use this idea to build our App in iOS? It’s something for us developers to explore

Second, design mode

1. What are the common design patterns on iOS?

  • Singleton mode:

    Singletons ensure that there is only one instance object of the class in the lifetime of the application and that it is easily accessible to the outside world. In ios SDK,UIApplication, NSBundle, NSNotificationCenter, NSFileManager, NSUserDefault, NSURLCache, and so on are singletons.

  • Delegation mode:

    A Delegate is a protocol implemented through the @ Protocol. Common examples include tableView, textField, etc.

  • Observer mode:

    The observer pattern defines a one-to-many dependency that allows multiple observer objects to listen on a subject object simultaneously. In iOS, there are two specific implementations of observer mode: Notification mechanism and KVO mechanism (key-value Observing).

2. What are the disadvantages of routine meetings?

  • Main advantages:

    Provides controlled access to a unique instance.

    2. Since only one object exists in system memory, system resources can be saved. For some objects that need to be created and destroyed frequently, singleton mode can undoubtedly improve system performance.

    3. Allow a variable number of instances.

  • Main disadvantages:

    1. Because there is no abstraction layer in the simple interest pattern, it is very difficult to extend the singleton class.

    2. The singleton class is too heavy, which violates the “single responsibility principle” to some extent.

    3. Abuse of singletons will bring some negative problems. For example, in order to save resources, the database connection pool object is designed as a singleton class, which may lead to too many programs sharing the connection pool object and connection pool overflow. If an instantiated object is not used for a long time, the system considers it garbage and collects it, resulting in a loss of object state.

3. Six design principles for programming?

  • 1. Principle of single responsibility

    In layman’s terms, a class does only one thing

    CALayer: Display of animations and views.

    UIView: only responsible for event passing and event response.

  • 2. Open and close principle

    Closed for modifications, open for extensions. Consider future extensibility rather than going back and forth

  • 3. Interface isolation principle

    Use multiple specialized protocols instead of one big, bloated protocol, such as UITableviewDelegate + UITableViewDataSource

  • 4. Dependency inversion principle

    Abstraction should not depend on concrete implementation, concrete implementation can depend on abstraction. The calling interface doesn’t feel what’s going on inside

  • 5. Richter’s substitution principle

    The parent class can be seamlessly replaced by the child class, and the original functionality is not affected, such as KVO

  • Demeter’s Rule

    One object should know as little as possible about the other, achieving high aggregation and low coupling

4. How to design an image caching framework?

  • This can be done by mimicking SDWebImage.

  • Constitute a

  • Manager

  • Memory cache

  • Disk cache

  • Internet downloads

  • Code Manager

Image decoding

Image decompression

  • The image is stored with the hash value of the image as the Key

Memory design considerations

The Size of storage

Because the memory space is limited, we give different schemes for different sizes of pictures

  • 50 under 10K

  • 20 under 100Kb

  • 10 with a size greater than 100kb

Elimination strategy

There are three times when LRU (least Recently used algorithm) triggers the elimination strategy of memory

  • 1. Regular inspection (not recommended, consumption of performance)

  • 2. Increase check trigger frequency (be careful about overhead)

  • 1. Switching between front and back

  • 2. Every time you read or write

Disk design considerations

storage

Size limits (there are fixed sizes)

Removal policy (can be set to 7 or 15 days)

  • Network design considerations

Maximum number of concurrent image requests

Request Timeout Policy

Request priority

Image decoding

  • Apply policy mode to decode different image formats such as JPG, PNG and GIF

  • The timing of the image decoding

  • When the child thread image has just finished downloading

  • When the child thread has just finished reading from disk

  • Avoid decompression and decoding in the main thread to avoid stalling

5. How to design a time frame?

recorder

  • Page type recorder

  • Flow recorder

  • The custom type

Record manager

  • Memory record cache

  • Disk storage

  • uploader

How to reduce the loss rate of data?

  • Periodically Writing data to disk

  • Whenever a certain value is reached, it is written to disk

Record the timing of the upload

  • You can upload it while switching between front and back

  • Uploads can be uploaded when switching from netless to netted

Selection of upload timing

  • Immediately upload

  • Time to upload

  • Delay to upload