The evolution and optimization of Ctrip's mobile terminal architecture

Since 2013, we have carried out different paths of diversity architecture exploration, in the course of practice also experienced a variety of twists and pressures, and finally achieved 2015 years of this new architecture, the wireless server based on the API Gateway Architecture framework, the client's modular development, testing and deployment, Supports module-level dynamic upgrades as well as code-level hot fixes with live load, on-demand lazyloding, and remote loading during runtime, and
and gradually promote the hundreds of-person client research and development team from the overburdened, inefficient large version of the Big Train development model to separate iterations between the modules, the release of lightweight development direction evolution.

At the same time during the architecture exploration, Ctrip did a lot of app-related performance optimization, such as the optimization of the bottom network channel governance, application layer plug-in container loading start speed and storage optimization, business middleware hybrid optimization and so on, gradually ensure that with the business of continuous iteration, to ensure that the user's better optimization experience.

App service-side architecture changes early app server architecture

The Early app server architecture uses a traditional PC wireless development architecture that adds some wireless-side rest interfaces directly to app access on the basis of PC Web applications, without regard to the scalability, flexibility, security, and other factors of the architecture.

Figure 1 Ctrip Wireless server architecture V1

1, the server-side system is provided to the PC-side browser on the one hand in Web application, on the other hand to support mobile, on the basis of Web application to add some rest interface directly for the app access. Accordingly, the wireless interface and the Web application as the same project development, as the same application deployment, this architecture design idea is very direct and natural, can quickly copy PC-side function to the app, its thought design is in the existing Web application patching, reflects the PC thinking wireless, The simple use of the app as a copy of the PC-side application, and the two are physically bundled together, in the early can meet the business needs of the time, but with the development of the platform, as well as the complexity and diversity of the business, this architecture design brings a number of problems gradually exposed, One of the most prominent urgently needed solutions are three problems: coupling, repetitive wheel building, system stability, as shown below:

• Strong coupling

Wireless interface and Web applications tightly coupled, web-side modification will affect the wireless interface, web-side publishing causes the wireless interface passive publishing, web-side bugs affect the availability of wireless interfaces, in turn, any changes in the wireless interface will affect the Web application.

In addition, the hotel wireless interface and ticket wireless interface, or other BU wireless interface, there are more serious coupling problems, the problem of this coupling, the most serious and most obvious is the BU interface adjustment or modification bug, it may affect the stability of other BU interface, resulting in each release, To bring more tests back to work.

• Re-build the wheel

In addition to providing business data to the app, the wireless interface also needs to take into account a range of non-functional aspects of interface functional verification, such as communication protocol and data format encapsulation, security control, logging, performance monitoring, which are applicable to each wireless interface. If the app and backend systems are connected directly, it means that each backend system needs to support these common functions separately, leading to repetitive development. Once these general requirements change (such as the encryption enhancement of data transfer), all back-end systems are forced to synchronize the modification and on-line, which poses a great challenge to project management and product launch.

• Stability

Apps and multiple back-end systems directly connected, as long as a system problem, will affect the usability of the app, such as the hotel service problems such as slow or excessive CPU resources, its ticket services or other services will be affected, its typical disadvantage is the lack of fault isolation mechanism, lack of load balancing, lack of monitoring, Lack of fusing and other problems affecting the stability of the backend, resulting in the robustness of the app is very poor, very fragile.

Ctrip app service-side architecture V2.0

Based on the three serious drawbacks of schema V1.0, we began to try a new wireless architecture V2: The API Gateway-based wireless server architecture.

The Wireless API Gateway architecture based on 2 shows the following features.

• Peer Isolation

The app is actually equivalent to the PC-side browser, the PC-side application has a service side, the app also needs its own independent server, two service sides need to target their own characteristics, independent development, independent deployment, at the same time to achieve the logical and physical decoupling, from the architectural level to completely get rid of PC thinking wireless.

• Unified Services

The core logic is stripped out of the Web application and transformed by service, the service is realized without distinguishing between PC and wireless, and the app and Web application all depend on these services, a set of interfaces, multiparty calls.

• Unified Wireless API Gateway portal to maintain system stability

Provides a unified wireless gateway, all app calls point to this gateway, the gateway includes a universal layer, interface routing layer, adaptation layer. The general-purpose layer includes communication protocol adaptation, data encapsulation, security, monitoring, logging, isolation, fusing, current limit, anti-crawl These system-level functions, each interface call requires the same logic, these functions are unified by the gateway pre-processing, avoid duplication of development. When implemented, each generic processing logic is encapsulated as an interceptor, follows a unified filtering interface, and is configurable, and the gateway calls these interceptors in turn to support the flexible expansion of common logic.

Wireless API Gateway should now be a lot of companies have their own implementation, the current market also provides a lot of open source projects Zuul, Archaius, Hystrix, Eureka and so on to help us to achieve their gatway.

Functional features of API Gateway

Figure 2 Ctrip Wireless Server architecture V2.0

Ctrip's Netflix-based open source project Zuul developed the wireless Apigateway architecture as shown in 2, and its gateway function is to receive all API requests from the wireless side and route them to the correct target application server, providing current-limiting, isolation, and fusing functions. Ensure the long-term stable operation of wireless services, with the elastic fault-tolerant mechanism also reduces the daily operation and maintenance work. At the same time, the gateway provides multi-dimensional monitoring data, and with the alarm system docking, real-time monitoring of the situation on the line to achieve operation and maintenance automation. Its API gateway has several core functions: routing, isolation, current limiting, fusing, anti-crawling, monitoring alarms, as follows:

• Interface routing: A core feature that requires routing requests to the correct destination based on various criteria. In the implementation of the routing service, the gateway periodically from the routing service to obtain the routing table, to understand the effect of decoupling, real-time update, after the general logic preprocessing, the wireless interface request will be further distributed to the backend processing (each adapter). The URL and adapter are mapped in the configuration file, and the distribution logic finds the corresponding adapter based on the URL information in the request, and then gives the request to adapter processing.
• Isolation: Because Gateway receives all of the business requests, the requests are diverse and cannot affect other request processing when a certain type of request goes wrong. In this case, Gateway implements resource isolation, preventing certain types of requests from consuming resources, and then affecting other services.
• Current limit: The capacity limit is set for any type of request and cannot be handled indefinitely. The gateway can set the concurrency limit for each type of request, and when it reaches the upper limit, the gateway will not forward the request, but return it directly, protecting the backend service. If the back-end service is overloaded, the request is still forwarded, which only worsens the problem.
• Fuse: When a service fails to provide service, the gateway will not resolve the problem and often worsen the problem if it intermittently forwards the request to it. Gateway introduces a fuse mechanism that, when a service has reached a threshold for the error rate over a period of time, the gateway stops forwarding the request to the service, called a fuse, and after a certain period of time the gateway detects if the service is back to normal and normally starts to forward normally. If not normal continue to fuse.
• Anti-crawl: Gateway actively docking secure interface, will be based on IP, clientId, and algorithm check blocking illegal requests, protection of back-end services.
• Monitoring alarms: The gateway has access to cat, Clog, and docking operation alarm tools. When there is a problem, will be timely alarm, early detection of problems, reduce losses.

API Gateway Smart Lift level

Gateway supports centralized control while also bringing a single point of issue. Assuming a service interface in the background, for some reason, the performance of a serious problem, the corresponding adapter processing is slow, the gateway is located on the server's thread is quickly exhausted, resulting in a single interface to bring down the entire system. This problem, simply by increasing the number of machines, the level of expansion of the gateway is not solved, in practice, we introduced the intelligent lifting level mechanism to quickly isolate the impact of a single interface, thus realizing the interface of the automatic isolation fuse mechanism, the implementation principle of 3 is shown.

Figure 3 Gateway Interface Auto-upgrade downgrade flowchart

For a particular interface, if within a certain time interval (such as 5 minutes), its time-out failure rate to a certain percentage (such as 5%), the gateway will be degraded processing of the interface, randomly discard some of the traffic, such as only allow 50% traffic pass. Next 5 minutes, if the failure rate has not improved, allow traffic to pass down to 25%, and so on. If the success rate improves, the gateway to the interface to do upgrade processing, increase the traffic ratio, in order to recover quickly, generally up to 4 times times the original traffic, and then in the next time period to evaluate whether to trigger the lifting level.

The whole process of automatic intelligent processing (in order to prevent false positives, can support manual intervention), so that the single interface problems, will not affect the entire gateway processing power.

A summary of the evolution of Ctrip app server architecture

Ctrip App server architecture through a series of split and integration, not only optimizes the company's overall application architecture, but also to build a good foundation for the app to be bigger and stronger, the benefits are all aspects, increase the scalability of the architecture, robustness, stability, flexibility, and improve the team's development efficiency and team long-term benefits, It is manifested in:

• Achieve PC-side application and mobile application separation, so that the two completely decoupled, their independent development, the app from the parasitic vines into Bingdilian. Ctrip's first step in making the gateway architecture is to do business decoupling between the PC and the wireless side, as well as business decoupling between the BU, to realize the independent deployment and independent release of the BU Wireless business and PC business.
• The underlying SOA service provides logic and data based on unified business rules that do not differentiate between PCs, wireless, or other channels (such as the Open API), avoid duplication of development, and prevent the business logic from being contaminated. All front ends are treated equally, and if additional ends are added at a later time, they do not need to be changed, and their scalability and flexibility will meet the needs of new business development.
• According to the characteristics of wireless, it supports centralized processing at the system level and decentralized processing at the business level. Universal logic supports plug-in extensions, which can be incrementally supplemented as needed, and adapter enables seamless conversion of internal and external interfaces, enabling logic enhancements such as service aggregation, client performance embedding, and interface performance monitoring for wireless scenarios.
• Mobile research and development team and line of business development team to do their part, each team focused on their own parts, the mobile team is responsible for the app client and gateway General logic processing, PC server is responsible for the PC-related business logic processing, H5 server responsible for H5 related business logic processing, each research and development team independent research and development and release, Decoupling, that is, the line-of-business development teams are responsible for the underlying SOA services and front-end adapter adaptation.

Ctrip app client architecture changes app early architecture

The first version of the Ctrip app was released in 2011, when the app architecture was simple, essentially encapsulating a data service layer, the proxy data layer, based on the traditional MVC architecture, as shown in 4.

Figure 4 Ctrip early client architecture V1

In the early stages of Ctrip's business development, mobile app has gone from scratch, in order to seize the market quickly, its mobile app development of the MVC frame constitutes the "fast track approach" idea of the first choice.

In the MVC architecture shown in 4, the Business Control layer is responsible for the implementation of the main logical functions in the entire app; the business logic model layer is responsible for the description of data structure and the function of the persistence; The data Service layer acts as the proxy media layer of the data, and is mainly responsible for communicating with the control layer. This includes mechanisms for implementing data communication, serialization, and deserialization of the underlying framework, while the mobile interface UI View layer is responsible for rendering the entire app's UI as the presentation layer. This structure is clear and concise, and this system architecture is supported by Android and iOS at the language framework level, so it is well suited for startup development of apps.

But this architecture in the late development due to its ultra-high coupling and nature, thus creating a large controller layer, which has been criticized. The final MVC from Model-view-controller to the end of the Massive-view-controller, the most serious result is the control layer of code more and more, in Ctrip many classes, earlier than 2000 lines, There are some high coupling between the control layer and the view layer. The corresponding app engineering architecture is shown in 5: There is only one engineering structure for both iOS and Android ctripwireless.

Figure 5 Pre-Ctrip app Engineering architecture diagram

The benefit of a single project to implement an app is that the interface of each line of business is easy to communicate, simple to call, and free to use any public and business components in the project, and access to learning costs is low. But as the business becomes more and more complex, and the needs of the BU business communication interact more and more, the business coupling of each BU becomes more and more serious, which is the foreshadowing of the post-plugin bundle architecture.

Based on the rapid development of Ctrip's business, and then more than 100 million active users, daily users tens of thousands of days, quickly touched the Android virtual machine mechanism of the design defects, that is, mobile on Android face two more serious problems, The serious result of these two problems is that in 2.3 of the system, users can not install and use directly.

One is the single-Dex 65535 method number limit, and the second is the linear memory allocator (LINEARALLOC) limit. Today's Android developers see neither of these limitations as unfamiliar. The former is because Android's early
Period design, the method ID in the Dex file is marked with a 16-bit integer, and the number of methods in a single Dex file cannot exceed the debug apk that has not been proguard in the 65535,eclipse environment.

The latter is the Dalvik virtual machine used to load the heap memory size of the class is hard-coded, 2.3 Below is 5m,2.3 above is 8M, so the app can not install the reason is because the heap memory is exhausted resulting in dexopt failure.

Now it's definitely not a problem, because Google has given some reliable solutions, with more advanced Gradle + Android Studio, and developers may not be able to meet these two classic questions at all. The official Multidex division Dex mechanism solves the problem of method number limitations, where the main Dex minimization principle, combined with the Dalvik linearalloc heap size adjustment (modified
To 16M), which makes the probability of dexopt failure fall sharply. There is no such restriction on the linearalloc of art.

But we come back to see, that in the user Android 2.3 also accounted for 50% of the era, how to adjust the software architecture to solve this problem, the experience of which we are worthy of reference and learning place.

APP V2.0 Architecture

Based on the problems we have encountered, we have re-adjusted and optimized the original architecture, and proposed the mobile architecture V2.0, the main design idea is:

In the fast-growing business, the app has already hosted a lot of business functions when it's 5.0, but some of them are less frequent, and some of the features that were proven to be ineffective before a quick trial and error are still in the existing version. These infrequently used features should not always occupy the program resources, so vertical separation from the architecture, to ensure the experience of the main important scenes, is the main design idea of this period, this period of architecture design Figure 6.

Figure 6 Ctrip Mobile Architecture V2

The first step in implementing this architecture is to decouple the functions of the BU lines, which cost the entire team about 3 app-wide cycles over a period of 3 months.

The important idea of functional decoupling is to implement the thought of the separation of the light and the primary and the the key, and to make important adjustments in the organization structure of the code module, to ensure the fast iteration and stable performance of the main important application functions, and to dynamically load the new features with low frequency, using H5 container. So in the V2.0 architecture, Ctrip app is a typical hybrid app, you can see the core modules in the first hotel and ticket use native for development, the other modules are basically used H5 to achieve.

Based on the V2.0 architecture, a series of work is done to transform the features of the app into H5 implementations, such as customer value and low conversion rate. The benefit of this is to focus on optimizing the native business experience while also reducing the limit on Android because of the excessive number of methods.

At this stage of the V2.0 also did one thing to solve the problem of Dex 65535, the project will be no longer used in the class and no longer use the method of centralized cleanup, the advantage is that the code is also clean up, If the number of methods is not too much, you can reduce the number of methods to less than 65536 by cleaning up the unused jar packages, the jar packages that were introduced repeatedly, and the third-party jar packages, which generally have the best number of methods in the jar. Clearing one or two useless jar packages can greatly reduce the number of methods.

At the same time, this stage also defines a principle, some information to explain the display or the activity preferential page, the non-user main process page all uses the H5 to realize, on the one hand reduces the development cost, but also is in order to deal with the method number increase pressure.

The above three methods are from the traditional point of view of technical defense to prevent the introduction of more methods and classes, and in the original project to thin body, but neither of these methods can essentially solve the single Dex 65535 method limit app can not install the problem, to fundamentally solve this problem, You have to reduce the size of a single Dex and use the new technology offensive method to solve the problem once and for all.

So the next big decision is to decouple the BU, each BU separate project, each independent plug-in has a separate UI interface logic and resources, storage and network communication data processing logic, through the common base library interface to access network services, image Library, location library and so on. The V2.0 architecture corresponds to the app engineering structure shown in 7.

Figure 7 Schematic diagram of the schema V2.0 corresponding to the project structure

Ctrip dex dynamic Load Scheme implementation

At that time, in order to completely solve the problem of method number overflow, based on the above decoupling on the basis of a multi-Dex subcontracting scheme, then Ctrip's approach is to learn from the Facebook offer to dynamic subcontracting, an apk in the Dex file into multiple, and then dynamically loaded Dex file. Let's start with a brief description of what Facebook is thinking:

• Dex Form

Ctrip is exactly the same as the Dex form of Facebook, because we also compiled it using Facebook's open Source Tool, Buck.

• Rules for Dex class subcontracting

Facebook puts the logic of loading Dex in a separate nodex process, which is a very simple, lightweight process. It does not have any contentprovider, only a limited number of activity, Service.

android:name="com.facebook.nodex.startup.splashscreen.NodexSplashActivity">

So the dependency set is application, nodexsplashactivity indirect dependency set, and this part of logic should be relatively stable, we do not need to do dynamic scanning. This enables a very lightweight dependency set scheme.

• How to load Dex

The load of the Dex logic is also very simple, as Nodexsplashactivity's intent-f ilter is specified as main and launcher. First pull up the nodex process, and then initialize NodexSplashActivityActivity , if Dex has been initialized at this point, jump directly to the main page.

Facebook loads Dex's scenario, which is loaded as shown in Flowchart 8.

Figure 8 Facebook loading Dex flowchart

The advantage of this approach is that the dependency set is very simple and does not get stuck when you load Dex for the first time. However, its shortcomings are also obvious, that is, each time you start the main process, you need to start an additional nodex process. Although the Nodex process logic is very simple, it also requires more than 100ms of load time. But Ctrip was very sensitive to the start-up time, and it was hard to push the product to adopt the program.

Based on the shortcomings of this scheme, we have optimized the program, that is, the main process can directly load the Dex solution, the specific scheme strategy is as follows.

• Dex Form

The Dex form is not the focus, assuming we use the current Dex form, the Assets/secondary-program-dex-jars/secondary-n.dex.jar.

• Rules for Dex class subcontracting

The main Dex should be simple, like Facebook, with only a few classes related to Dex loading, and this part of the code is relatively stable. I don't have to change any of the non-loading related code.

• How to load Dex

This is the point where we should implement such subcontracting rules by what loading scenarios. First of all, it is clear that if you click on the icon, there is no need to start a process is feasible, but the problem is that when application is initialized, or at Attachbasecontext, we cannot ensure that the main interface activity will be entered. Perhaps the system to start a service or receiver or notification, this way of jumping is not.

Figure 9 Multiple Dex load flowchart

As shown in 9, there are two key issues that need to be addressed:

1. How do I suspend the main process?
2. Is the ANR generated during the process of suspending the main process?

With regard to issue 1, process synchronization can use PTHREAD_MUTEX_XXX, pthread_cond_xxx, but the mutex or cond is placed in shared memory, which is more complex to implement. So the last time I implemented it was one of the simplest ways to detect if Tempfile is present every 95ms, and if it exists, go directly to the main program and judge in the worker thread that loads Dex, and create Tempfile if load Dex succeeds.

Regarding issue 2, while suspending the main process, to start a worker thread to load Dex, that is, this thread is a non-UI thread, does not cause the blocking of the main thread of the UI, after many tests, and indeed no ANR phenomenon, this through the analysis of the nature of the ANR phenomenon can be reached this conclusion.

Based on Facebook, we optimized the dynamic load Dex solution, which solves the problem of being unable to install because of the excessive number of methods, without worrying about the growing number of methods in the code as the business grows.

At the same time, at the beginning of 2015, Ctrip began to move from Eclipse tools to the way Android Studio + Gradle was built, while Google supported the Mutildex party
The official programme was subsequently used directly.

After decoupling the V2.0 architecture, the dependencies of the different BU projects are lifted, which solves the problem of the mutual dependence of different BU, and can support multiple teams to develop concurrently. However, the stage architecture of this phase has the following two significant problems:

• SOURCE Dependency

That will exist if other BU project modification, if not timely notify the other personnel, the whole global error, the entire project compiles can not pass, affecting other BU normal development work.

• Slow build compile speed

Packaging is not configurable, build speed is slow, because Ctrip bu many, business is very full and complex, probably decoupled to have 10 of several projects, because it is not optional so need to compile, so the construction speed is the slowest time almost 30 minutes, generally more than 10 minutes, so the overall development efficiency is lower, The experience of the developer is also poor.

App Architecture V3.0

Based on the above shortcomings, we have also optimized the architecture of the V2.0, and proposed the V3.0 architecture, which is shown in Figure 10 of the architecture. The V3.0 architecture was completed on the basis of V2.0 's engineering decoupling upgrade, and the V3.0 architecture is a dynamically loaded plug-in architecture based on bundles, in which almost any organizational form in the project can be seen as bundles, and the final Ctrip app is composed of a series of bundles, Run in the bundle container dynamlicloader that can hold the load.

Figure Ten V3.0 Frame composition

10, the application layer of hotels, air tickets, train tickets, etc. are independent of the APK, they independently developed, not affected by each other. The final unification is integrated into the unified Ctrip apk in the form of plugins. The communication between hotel and ticket takes two ways, bus data bus jump and URL scheme jump.

The V3.0 architecture corresponds to the engineering structure shown in Figure 11.

Figure 11 Schematic diagram of the schema V3.0 corresponding to the project structure

11, the existing engineering structure has more than 30 bundles (APK), and with the future of business development, its bundle is more and more. In order to solve the problem of too much compiler speed, we adopt the configuration file to dynamically and flexibly configure, each BU need to use what bundle, through a simple sentence configuration, add it to the project, While other bundles that do not need to be called in Support AAR (. A) and source dependencies, add dependencies as needed.

In order to solve the problem of the Dex method that we met V2.0, we built a dynamically loaded plug-in framework based on the current status of Ctrip app Dynamicloader, support the instant load, load on demand, remote loading three ways. Immediate loading, that is, just starting to load directly, on-demand loading is used when the load, remote loading is just beginning without this project, and then the user through the remote security
This function can be used directly in the installation. This mechanism also supports our subsequent use of the hotfix mechanism. Here the first simple summary of the current market appears a relatively famous open source plug-in framework as shown in table 1.

Table 1 Market Mainstream plug-in technology comparison

As shown in table 1, Ctrip in the first half of 2015 began to study their own plug-in framework, but also on the market at that time plug-in technology to do research, the final results, then the mainstream framework in the market can not meet Ctrip at that time the current project structure and plug-in demand, that is, access to its plug-in, Ctrip's various BU team need a lot of additional development costs to achieve the overall migration, but also can not effectively guarantee the subsequent plug-in stability, based on this background, Ctrip's plug-in came into being, its realization principle is through the system of ClassLoader dynamic loading class, Through the system Assetmanager to dynamically load the resources of the plug-in, at the same time by modifying the AAPT source code to replace the system appt solve the problem of conflict between the BU resources. The key is that the original code of the BU and the existing development model do not need additional to change to increase the additional development costs, the idea of plug-in is the idea of all bundles of components, each bundle has its own version number, through the Bundlemanager to manage the bundle upgrade.

In the V3.0 architecture push phase, in order to support loading on demand, the bundle load speed, we agreed to a rule: that each bundle load time does not need more than 500ms. So the big bundle needs to be split, such as the hotel and the ticket inside and split their own 6 bundles.

The V3.0 architecture is more suitable for medium to large teams, and after decoupling, it can support concurrent development of multiple teams, and can be developed and released simultaneously with multiple versions. The work of each BU team is to provide a bundle before publishing, and then to integrate it into the unified apk of Ctrip during the release integration phase.

In the past 2015 years, Ctrip has gradually stabilized its software architecture. Based on V2.0 's original plugin loading, this paper studies the technical architecture of Android applications in more industries, and also combines the implementation of official Multidex.

V3.0 on the basis of V2.0 decoupling, the implementation of the dynamic loading plug-in framework, and on this basis to increase the dynamic hot patch function, through the Ctrip internal hotfix release platform, the implementation of the Ctrip client Patch version update direct coverage, users do not need to install a new version can be serious bug fixed. Similar to Ali's Andfix thermal repair technology framework.

App Architecture v4.x

V3.0 architecture has been able to support rapid and efficient parallel development of multiple teams, but technology is always moving forward, so the future of v4.x architecture we are still moving further into the exploration, such as we do native app can be deployed like a Web site at any time, that is, take it, Can cross-platform experience good native app development, can achieve dozens of engineering second-level deployment compile, thus greatly improve the development efficiency, these issues are our native developers have been exploring the pursuit of the topic.

Currently Ctrip is advancing and has been working on the technical architecture:

• The moles framework based on reactnative was introduced;
• Thermal deployment scenarios based on Freelline and Layoutcast;
• More lightweight component and service of bundle;
• Framework design based on MVP and AOP.

Summarize

Architecture is well worth sharing and discussing, and a good technology architecture can continue to support great business dreams. However, no matter what good scalability of the technical architecture, can not be separated from the business, and eventually will continue to evolve with the business, while its architecture is also in different degrees of evolution and optimization. A good architecture must first of all be able to solve the actual technical problems encountered by the company and meet the current structure of the company's technical status, and then bring technical innovation to lead the business development.

Next to do the architecture, to understand what the purpose of this design, through the architecture design to make the program modular, so that the internal module of high aggregation and low coupling between the modules, to achieve basic compliance with Dimitri, dependency inversion, Richter replacement, interface isolation and other principles. The advantage of this is that in the process of development, developers only need to focus on one point, improve the efficiency of program development, and make it easier to conduct subsequent testing and positioning problems. However, the design can not be contrary to the purpose, for different levels of engineering, the specific structure of the implementation of the way must be different, should not be committed to design and design, in order to structure the structure of the problem.

The evolution and optimization of Ctrip's mobile terminal architecture