Thoughts and experience in Android development software architecture

1. Bud

As a programmer with little programming experience, I always think that architect is a mysterious profession, and architecture design is even more grand. After several projects this year, I have previously written about my practical experience in refactoring projects from MVC to MVP, and I have also said that I am ready to refactor the current projects under my hands. However, some time ago, I changed my mind. The reconstruction of the development model is just a change of routine. Perhaps in the process of reconstruction, the logic of the business is sorted out, and some optimizations are made based on the code design of predecessors. However, this is far from enough. This is not my ideal development scenario. In the process of project development, many problems were found, but they were all scattered problems. I often hope to change the status quo and program more elegantly, but the actual situation is trapped in an endless cycle of iterative function development and bug fixing. Now looking back, my ideal should be that development should be guided by planning and design, so architecture design is particularly important.

2. Introduction to the architecture

1. Read "The Beauty of Architecture" on architecture

I have only read the first part of "The Beauty of Architecture": On Architecture, and have a general understanding of architecture. The following figure is a summary of the knowledge points in this part:

Concepts that inspired me from the book:

• Architecture is a compromise, a trade-off. What architects need to learn is balance, the balance between quality and cost;
• The architect’s primary concern is not the functionality of the system, but meeting requirements and satisfying quality;
• What architectural design needs to do is to separate concerns and design a certain structure for each concern, which is conducive to answering the problem defined by this concern;
• A good architecture should be able to guide product, development, and test personnel to feel very comfortable and reliable with the design, and the design should cover all stakeholders and concerns of the software system;
• Design only what you know you need, any extra design is a waste;
• The architecture affects almost all people and things related to the system and determines whether the software system is healthy.

2. Analyze the architecture evolution of various apps in the industry

Here, we just searched some articles on the architecture evolution of various apps through Google, and analyzed why they evolved? How did they evolve? What benefits did they bring?

A simple summary is as follows:

(1) Why architecture needs to evolve

• Project requirements are expanding, and the old architecture is not adaptable to new requirements
• As the number of development team members increases, the requirements for collaboration become higher
• Introduction of new technologies
• Higher software quality requirements

(2) How did they evolve?

• The Ele.me Mobile App Architecture Evolution 2016-01-20
  • Common components
  • Business Components
  • Module decoupling
  • Excalibur mapping system, registration mechanism
  • Introducing the Hybrid Framework
  • React-Native & Hot Patch
• Ctrip Mobile App Architecture Optimization Journey 2016-04-07
  • Adjust the engineering structure, decouple the business, make products independent of each other, and use event bus or URL bus for page jumps
  • Unify basic functional business components and SDK
  • Performance data collection and monitoring
  • Native plug-in and HotFix
• The Evolution of Nuomi Mobile Component Architecture 2016-05-24
  • Componentization
  • Unified service entrance
  • Hybrid framework optimization
• Suning 11.11: Suning.com Mobile Terminal Architecture Optimization Practice 2016-11-11
  • Layered decoupling to solve vertical decoupling
  • Intermediary reference structure (protocol and url), horizontal decoupling
  • H5 container optimization
  • Network link optimization
  • Mobile App Performance Monitoring System

(3) Benefits

• Modular decoupling has been carried out, and the products are relatively independent, which makes it more flexible to deal with changes in demand and technology updates, and makes team collaboration more convenient. It also reduces a lot of useless work and leaves some technical accumulation for the team.
• Necessary unified standards have been carried out, the organizational structure is clearer and the system is healthier;
• Introduced a new technical framework to provide a better product experience;
• We have carried out system optimization work, the software quality is higher and the experience is better;

3. Google search keywords: architecture design

Search engines are the best learning tools for us. I searched for keywords such as architecture design, read some articles, and carefully read Keegan Xiaogang's blog series "Xiaogang's Architecture Thinking". I read these articles when they were first published, but I didn't understand them very well at the time, probably because I didn't have a general understanding of architecture. When I consulted a senior, he told me about his understanding of architecture and recommended these articles again. So I read them again several times. The figure below is a summary of the knowledge about architecture design in the article.

(1) Knowledge Overview

(2) Personal summary

The architecture is divided into three stages: planning, design, and construction. The design of the architecture has different functions in each stage. In the planning stage, we consider product requirements, quality requirements, technical feasibility analysis, and preliminary research. In the design stage, we consider how to split a complex system and design how to organize these split modules. In the construction stage, we consider specific implementation issues and ensure a certain degree of scalability because the architecture is constantly evolving. The article quotes a model diagram from the book "Software Architecture Design", and I think it is necessary to post it here. Recently, I have also been thinking about the modular design of software. Maybe everyone has their own understanding of modular design, so I will not discuss it here. As shown below:

I didn’t understand this picture very well at first, so I tried to draw some pictures to express my ideas. But when I looked back at this picture again, I suddenly understood it.

The design of architecture can be considered from two dimensions: architectural thinking and architectural principles. Thinking is our way of thinking and our method of solving problems. Principles are the direction in which we think about problems and some of our standards for solving problems.

III. Definition of Architecture

The industry has different opinions on the definition of architecture. I have also consulted some experienced seniors in the industry through WeChat. The book "Software Architecture Design" summarizes the definition of architecture into two categories: composition and decision-making:

• Compositionalism: Architecture = Components + Interactions: The architecture of a software system describes the system as computing components and the interactions between components.
• Decision-making school: Architecture = set of important decisions: Software architecture is a collection of decisions made in some important aspects.

Keegan Xiaogang mentioned in "Xiaogang's Architecture Thinking: What is Architecture": Software architecture is the process and result of planning, designing and building software. The book "The Beauty of Architecture" proposed in 1.1.3 The Meaning of Architecture: Architecture describes the structure used to design and build a system. "Software Architecture in Practice, Second Edition" proposed: The software architecture of a program or computer is a structure or a set of structures of the system, which includes software elements, the externally visible properties of these elements, and the relationships between the elements.

I have not experienced large-scale software systems, and I have only done mobile app development, so I can only give a narrow understanding from the perspective of mobile app architecture design. I believe that mobile app architecture is a consensus formed by the coordinated management of products and technologies. Most app development, especially that of small teams, is driven by products. When demand comes, it is implemented by technology. When demand changes, it is changed. After all, the development of the application layer is responsible for the business and must ensure normal release. Therefore, in most cases, programmers have to compromise in front of product managers, which makes the work of developers very passive. Therefore, there are jokes about programmers and product dogs. The reason for this phenomenon is that the relevant stakeholders of the project have not reached a consensus on products and technologies, which is exactly the problem that mobile architecture design needs to solve.

4. Products

Products are the result of our product managers' design and the final result of developers' development. They are the common goal of both groups. As software architects, you should fully understand the design concept of the product. In addition to understanding the functional business that has been designed, you must also have a certain degree of foresight and grasp the development trend of the product. The following mainly discusses products from the perspective of development.

1. Product design (what to do)

As a developer, I cannot talk about product design professionally, but I still want to talk about product design from a developer's perspective. What is product design? I think it can be thought of from the following aspects.

(1) User groups (who uses it)

As the name implies, the products we design and develop are ultimately for people to use. So first of all, we have to identify who the users of the product are? The user group represents the market for our product. So whether the product is good or not is ultimately determined by the market and the users. Without users, without understanding users, and without paying attention to the user experience, everything is in vain.

(2) Core concept (what to do)

Do you know what kind of product you have worked so hard to develop line by line every day? It may be easy for us developers to fall into the iteration of one version after another. These endless tasks make people forget to think and forget to ask product personnel, what are we going to do in the end? What will our product be like in a year? What is our ultimate vision? How will we realize our ultimate vision step by step? You may say, what does this have to do with my development. When I receive the requirements, I will develop and implement it. However, there are many complaints in our team. The product personnel keep making changes, and I change the code back and forth. Our leader emphasizes that our developers should have their own initiative in this regard and can refute the unreasonable design of the product. However, the premise is that you at least understand the core concept of the product and what we want to do in the end.

2. Iteration plan (how to plan)

For a product, users have many needs, and they keep changing over time. There are two types of needs: one is the instinctive needs of human nature, and the other is the needs generated by our products. Both of these needs are reasonable, and they are exactly what we need to satisfy users. How can we plan to implement various needs? In agile development, we put these needs into a "requirement pool" and then plan and arrange them in different versions of iterations. This work is not only decided by product personnel, but developers should also play a certain role in decision-making. Product personnel need to consider from the perspective of the product, and developers need to consider from the perspective of technical implementation. The final plan should be a joint decision of both. It is particularly important to note that according to the characteristics of the product, technical personnel should also put forward technical requirements. A reasonable iteration plan can ensure a normal development rhythm and achieve iteration goals.

3. Development resources (what to use)

(1) Development team configuration (people)

The book "Peopleware" mentions that the human factor is very important in software development, and it is very important to configure the development team properly. An App development team needs at least 5 roles, namely product, interaction, UI, software, and testing. Different roles are also divided into different levels, such as software is divided into primary, intermediate, and advanced. Only by properly matching different roles and different levels can we achieve higher work efficiency and ensure the smooth progress of product development.

(2) Data content configuration (object)

The product ultimately presents data to users, and there are two types of data. One is private data, which is produced by the developer himself. The other is platform-generated data, which is produced by users. If it is self-generated data, you have to consider the source of the data, the coverage of the data, the accuracy of the data, the legality of the data, etc. If the data is produced by users, you have to consider the motivation, entry point, data security, and dissemination of the data, etc.

(3) Development investment budget (money)

Everything is ready, only the east wind is missing. To complete the development of an app, a professional development team is needed, and the labor cost here is also very high. Of course, I will only talk about the development budget here, and I will not talk about the operation. We have to consider how long the development cycle is, how many people are needed, and how to do the later maintenance. For example, an APP requires 5 people to develop, 2 months, and two versions. If calculated based on a salary of 10,000 per person, it will also cost 100,000. This is probably the lowest level of algorithm. Therefore, if it is a startup company, when we form a development team, we also have to look at the budget and how much money can be used to do a lot of things. Of course, if it is those bosses who don’t care about getting investment, it’s another matter. However, too many companies that died this year used to be big spenders. Once the money is burned, it’s gone. If it’s a big company, it may not be so stingy. However, we should also consider how much resources the development team will consume the company and whether we can get corresponding or higher output.

(4) Third-party resources

For current development, many resources can be obtained through third-party cooperation, such as servers, cloud storage, payment interfaces, login interfaces, content data, and some open source frameworks in the development process. We need to select, negotiate business, and integrate them into our own APP.

4. Product quality (how is it made)

(1) User experience

Now for us, user experience is a word that is overused. That is because user experience is really important and determines the success or failure of a product. After the product is developed, it will eventually reach the hands of users. Whether the product is good or not, the users have the final say. What factors affect the user experience? I think it can be seen from the responsibilities of the five roles. Does the product design directly hit the user's pain points? Does the interaction meet people's preferences and habits? Does the UI make users feel comfortable? Is the performance of the software good? Does the software have many defects?

(2) Software performance

From a technical perspective, we can analyze the quality of a software product through its performance. This year, many technical articles are talking about performance optimization. The performance of software is mainly judged from several aspects, such as software startup speed, fluency, memory, power consumption, traffic, APK size, etc. If you want to make a good application, performance optimization should be incorporated into daily development and carried out continuously. I will not go into details about how to optimize it here.

(3) Product safety

Product security can be viewed from two perspectives: the manufacturer of the product and the end user of the product. For manufacturers, there are many contents that need to be protected by law, and there is a lot of sensitive information, core technology, network interfaces, etc. that cannot be leaked. For users, we must store a lot of user information locally or on the server, such as account passwords. Once some information is leaked, it will seriously harm the personal interests of users. Therefore, in order to protect ourselves and the interests of users, we must produce a safe and reliable product. Then for an application developer, our compiled apk will eventually be in the hands of users. Therefore, we need to protect our applications through some technical means such as code obfuscation, data encryption, and permission restrictions.

(4) Quality evaluation

I think whether an application is good or not can be judged mainly from the above three dimensions: user experience, software performance, and product security. So, how should we organize these evaluations? Are we doing these things? For now, I believe that most product, development, and test personnel are more or less involved in these tasks, but perhaps they have not quantified some data and have not systematically organized these tasks. At present, most applications have integrated behavior collection, and the number of product downloads and user activity are also the main parameters that reflect the user experience of the product. The development team has been working on performance optimization, such as exception repair, bug repair, content leakage, overdrawing, and apk slimming. We have also carried out code obfuscation, data encryption, and apk signature encryption. However, do you know the quality of your product? Compared with similar products, what do you do well and what do you do poorly? Therefore, I think it is a very meaningful thing to systematically organize these fragmented tasks, quantify some influencing factors, and let us understand our product quality more clearly.

5. Risk avoidance

(1) Risk of human resource changes

People are fickle, especially in IT, where personnel turnover is even more frequent, including internal adjustments, employee job-hopping, etc. Therefore, for a development team, the risk of personnel changes must be considered. If someone is gone, can the project run normally? Can the development teams cross-familiarize with each other's business?

(2) Risks of upper-level decision-making

Have you ever experienced a situation where a project was stopped halfway through? At this time, you are only doing half of it. If this happens, what should we do? Suppose just now your boss said that you can no longer do your current project, then how can you recover the losses to the greatest extent? How to finish the project so that you don’t end up with a mess when the project is suddenly restarted?

(3) Project delay risk

When developing a project, we will conduct a review and then develop it according to the iteration plan. However, there will be many problems that affect our expectations during the development process, such as demand changes, technical difficulties, etc. Project delays are a common problem in the development of software projects. For some iterations, it may not have a significant impact on the entire project, but this problem must be considered. In addition, we should strictly control the progress of the project, balance these issues, and ensure that the product can be delivered on time.

(4) Software defect risk

We should be able to provide a stable version at any time, which is what our leader requires. It is normal for software defects to exist. We keep writing bugs and fixing them. For those deeply hidden bugs, they may not be tested and finally circulate to users. How can we complete emergency repairs at this time? How can we respond quickly to provide users with a stable and reliable version? These are what we need to consider. At any time, there should be a Plan B.

(5) Risk of human error

Some time ago, due to an operational error, the company accidentally sent an apk to the wrong model when updating it, causing the users of that model to be unable to use the program after the upgrade. Then, due to the lack of maintenance for this model, the code could not be found, and only an apk file could be found, so the only option was to decompile and upgrade. I think there are many human errors like this, such as code submission errors, integration path errors, etc. People are always careless, so when designing, we should take these factors into consideration, how to actively warn when errors occur, how to initiate emergency plans when user errors have already occurred, and minimize the adverse effects.

6. Product Delivery

(1) Test version

In agile iterative development, we can basically submit two test versions a week. We can submit a testable version when we develop a part or fix a part, which can minimize development risks and is conducive to software stability.

(2) Grayscale mechanism

If your product has a large enough user base, you should carefully consider releasing a new version at this time, because users are the testers of your product. Currently, most people use a grayscale release strategy, first releasing it to a small number of users to see their feedback, and then gradually releasing it to all users.

(3) Version management

We have many versions in the development process, and there are many ways to divide them. For example, debug and release versions. Sometimes we also need to provide data versions with test data for the content, and sometimes we need to develop the next version of the function before the previous version is officially released. How do we manage the codes of each version and how do we distinguish these versions by version names? We need to formulate certain management specifications, and whether this specification is agreed upon by the development team is very important.

5. Technology Development

I have been talking a lot before, but I have finally come to this point. For a developer, the key question is how to do it. I only know Android development, so I will only discuss Android below. I will mainly talk about how to do it from the following aspects.

1. Technology selection

(1) Development Platform

Currently, mobile development mainly focuses on two camps: Android and iOS. I won’t say much about the others.

(2) Development Tools

• Compilation tools: Eclipse & Ant, Android Studio & Gradle. As an Android developer, you should undoubtedly choose Android Studio & Gradle.
• Code repository: Git, SVN, tools include Turtle, AndroidStudio also integrates VCS;
• Maven repository: You can use nexus to create your own Maven repository.
• Continuous integration: Jinkens, Buildbot, Travis CI, Strider, Integrity;

(3) Development language

Java, Kotin, Grovvy, SQL, etc.;

(4) Development model

MVC, MVP, MVVM, clean, etc., each has its own advantages and disadvantages, which will not be described in detail here;

(5) Open source framework

It is said that you should not reinvent the wheel, because your wheel may not be better than others. For us developers, one very good thing is that we have too many open source and free third-party libraries for us to use, which saves us a lot of work and makes development more efficient. However, how to choose and whether to introduce is a question we need to consider. The following lists some commonly used third-party libraries, please click for more.

• Network: OKHttp, android-asyn-http, volley, Retrofit
• Event Bus: otto, EventBus
• Dependency Injection: Dagger, RoboGuice, ButterKnife
• Images: Fresco, Glide, Picasso
• Database: GreenDao, Ormlite, LitePal
• Json parsing: Gson, Jackson, FastJson
• Responsive programming: RxJava, RxAndroid
• Abnormal statistics platform: Tencent Bugly, Crashlytics
• Performance optimization: blockcanary, leakcanary

(6) Emerging Technologies

In software development, new technologies are developing very rapidly, but it takes a long time for us to actually implement them in projects, because new technologies have to be learned and there are risks that new technologies are not mature enough and have defects. Of course, we should actively introduce good new things to keep up with the times. The following may not be new things, but they are also new technologies that have been sought after in recent years.

• AndroidSupport: DataBinding, MaterialDesign, etc.;
• Hybrid development: ReactNative, Hybrid, Weex, etc.;
• Programming language: Java8, Kotlin;
• Hot fixes: AndFix, HotFix, Tinker, etc.;
• Build: InstantRun, Freeline

2. Business Splitting

When we split the business, I think we can divide the business into three categories:

(1) Common basic services

Basic business mainly refers to some basic functions of our app. For example, our company has a BFC team that has developed SDKs for file upload and download, network request, behavior collection, account system, etc., which relieves us of some repetitive labor. How to define what business is basic business? I think it can be distinguished in this way. If your business is needed by ordinary application apps in the industry, then these are basic businesses with universal applicability. We split them according to different functions.

(2) General technology business

I think general technology business is a business related to your own app and has strong technical characteristics. It may be the core technology part of your application. For example, the image processing of beauty software and the image recognition of Xiaoyuan Search are general technology businesses. The characteristic of general technology business is that there will be technologies needed in the same type of app as yours, and we can split it according to different technical fields.

(3) Specific functional services

Specific function business is the specific function of your own app, which can generally be divided into different modules according to the function. For example, my current one-click search (similar to Xiaoyuan search question) mainly has three functions: search question, look up words, and translate. Then it can be split into three major parts. Searching questions requires steps such as taking pictures, framing questions, image processing, and network requests. Each step can be regarded as a small business and split accordingly. Most of the specific function businesses are only applicable to your own APP.

The above statement is only based on my own experience. In our actual development, there may be some special cases or different splitting methods. In short, the splitting of business still needs to be based on the actual situation.

3. Architecture design (separation of concerns, abstraction)

(1) Core concepts

Separation of concerns

There is no architecture in the world. Once the concerns are separated, there is architecture. We divide the development of a software system from multiple dimensions, design each field, and organize each field in a systematic way. This organizational structure is architecture. However, how to reasonably separate the concerns of a complex system is very challenging.

abstract

Abstraction, this is the last point emphasized to me when I asked a senior for advice. If you follow the interaction and write the app page by page, then obviously, you have not abstracted your business, but only implemented it. As a design concept of Java, it also emphasizes the concept of abstraction. So what is abstraction? Abstraction is what you want to do! A simpler understanding is to write interfaces instead of classes. I don’t know if you have had this experience. In the development of our MVP, we have a Model and an IModel, but we didn’t know how to write IModel until we finished writing the Model, and it became a manual labor of copying and pasting. If you do this, you can think about it yourself. If we write IModel first instead of Model, what kind of experience is that? This is to abstract your business. In the design of the architecture, you only need to know what you want to do? You don’t need to pay too much attention to how you implement it specifically. This is design.

(2) Design Thinking

Procedure Oriented

As we all know, in C language development, our logic is mostly based on the task flow. This is a typical example of process orientation. Process orientation focuses on the work flow and completing tasks step by step.

Object Oriented

Java language is a typical representative of object-oriented development, which is well known to us. We design computers according to human thinking. Each object has its own attributes and its own operation methods. There are inheritance, combination and other relationships between objects. We complete our program by organizing these relationships. Just like people and things in society, the various complex relationships between people complete the operation of various social activities.

Aspect-Oriented

Aspect-oriented programming is created to make up for some defects in object-oriented programming. We encapsulate some functions together and provide external interfaces for easy calling anywhere. For example, SharedPreferences, Json, Xml, File, Device, System, Log, format conversion, etc. are usually in the until package. It is equivalent to a cross section. We can complete operations facing this cross section at any time, and there is no need to repeat the design in our own logic.

Service Oriented

Service-oriented means splitting the system into independent programs or components and providing a service to the outside world. Each service communicates with each other through a certain protocol, such as HTTP, and is deployed separately, thus achieving the purpose of loose coupling.

The above four types of thinking focus on different perspectives on the problem. Different perspectives lead to different solutions to the problem. Of course, each perspective has its own advantages and disadvantages. So, in Android development, is it just designed according to OOP principles? Obviously not. In the face of different needs and different scenarios, we need to adjust our thinking in time, use it flexibly, find the most suitable perspective, and come up with the best design solution. This is what we pursue.

(3) Design principles

High cohesion

How to understand high cohesion? I think when we split, a certain subdivision field only completes a single function, and handles its internal affairs by itself. From the surface, for example, a model class provides an interface to the outside world, so it has an input and an output. Looking at this interface alone, it is highly cohesive. Of course, its internal organizational structure may vary greatly, so the form of cohesion is different. So we classify them into functional cohesion, sequential cohesion, temporal cohesion, etc.

Low coupling

Coupling refers to the dependency between modules. Mutual dependence will inevitably lead to checks and balances. Therefore, if the coupling is too high, it will lead to ripple effects, which is something we don't want to see and will greatly affect the iteration of program versions and bug fixes. According to the different dependencies, we divide them into indirect coupling, data coupling, content coupling, switch coupling, control coupling, external coupling, etc. To complete the development of a system, we must organize the modules effectively. This organizational relationship cannot avoid coupling. What we need to do is to minimize these dependencies, especially avoid cross-dependencies, reduce the coupling to a minimum, and make our program design more flexible.

Moderate design

If we don't consider it carefully when designing, then the design is not enough and cannot meet the existing or foreseeable needs. From the perspective of development, it will lead to many problems in the later development. If you think too much, it is easy to over-design, so that a simple system is designed to be very complicated, which will add a lot of meaningless work to the current development and reduce the development efficiency. So what kind of design is a reasonable design? I think it can meet both existing and foreseeable needs, and can be easily expanded when facing the adjustment of the architecture. Such a design is a very good design. How can such an effect be achieved? I personally think that when designing the system, the granularity of separation of concerns needs to be grasped. The system is just an organization of different single small modules. Then these small modules are the basis of architectural design, which is like the bricks for building a house. What are these bricks? They can be a public method that provides an interface to the outside world, a private internal method, or a member variable held by someone. Of course, looking at the big picture, it can be a certain functional module. In the architectural evolution of each app in the above industry, modular transformation is emphasized. Therefore, only by separating your systems well can you organize them flexibly and respond to ever-changing situations with the same approach.

(4) Design plan

The following figure has been mentioned in the article, and I will introduce it again here because it really inspired me and expressed what I thought. When facing a complex system, how do we separate and organize it? I think this figure has conveyed the essence of it, so I think it is a guiding model for architectural design. No matter what MVC, MVP, MVVM, etc. you are, you can understand it from it.

Model decomposition

Based on my personal understanding in practical development, I have simplified this diagram again as follows:

Horizontal block

According to the simplified model in the figure above, we can understand that we divide modules horizontally according to business functions. For example, the theme store can be divided into wallpaper, ringtone and other modules, and each module is decoupled. At the same time, the business of each layer is divided into blocks again. For example, wallpaper has image request, loading, caching, cropping and so on in the data layer.

Vertical stratification

Next, we divide the business of each module into presentation layer, business layer, and data layer according to their responsibilities. The data layer is mainly responsible for data acquisition and packaging, while the business layer mainly coordinates the needs of the upper layer and finally returns the data to the presentation layer. The work of the presentation layer is to display the data on the UI interface, and respond to various instructions from people to switch the UI and operate new data.

Interface communication

From a horizontal perspective, we divide the business into blocks to ensure that there is no dependency between blocks, ensuring absolute decoupling. From a vertical perspective, the dependency between each layer is obviously unavoidable, so we can ensure that the upper layer only depends on the interface of the lower layer, thereby achieving the purpose of reducing its coupling.

As shown in the figure above, after the three steps of horizontal block division, vertical layering, and interface communication, we can decompose a system well and get an ideal model. Of course, this is an ideal model. In our actual development, we may not be able to avoid some special situations such as crossover, and we still need to proceed from the actual situation. But one thing is that we can ensure the separation of interfaces to achieve the purpose of lower coupling.

Unified Management

Unified management means that some things in our design need to be managed in a unified way. Through the above principles, we have disassembled a complex system and achieved the purpose of separating concerns in architectural design. However, in actual development, in addition to splitting the business, we also need to manage some businesses in a unified way. For example, the switch management of some modes, for example, when we need to switch between the test environment and the formal environment when making network requests, we can put these mode switching switches in one place to facilitate our management, instead of going to various places to modify them. For example, can our request URL address be written together for unified management? In some applications, a middleman will be used to uniformly manage the flow of data and page jumps. This is also a solution that can be tried. For details, please refer to the module manager and Url jump manager mentioned in the architecture optimization practice of Suning.com mobile terminal. Unified management means putting some features of a certain type of small module that has been split into a certain place for unified management. But there will be a problem. For example, the unified switch management mentioned in the previous example will cause switch coupling. How to avoid it? I think the switch can be written into its own module by default, and the modification interface can be made public to facilitate the upper layer to make unified modifications to achieve the purpose of unified management. In this way, even if the module is separated, it will not be affected. However, in this case, its security is affected to a certain extent. Architecture design is always like this. You always need to choose a compromise solution that suits you.

We divide a system into different small blocks through the above-mentioned horizontal block division and vertical layering method. These small blocks are responsible for a single responsibility, and then indirectly connect the blocks through interfaces, relying on interfaces rather than instances to weaken the coupling caused by the communication between modules. Of course, the above model is only an ideal model. If it is a very complex system, more layers can be split between the layers. For example, in the data layer, we use Model to complete it under the development of MVP mode. When the business of the Model layer becomes very complex, some people will consider splitting the Data layer and putting it at the bottom layer, the most basic data operation, etc. Finally, in order to facilitate our combination and management of modules, we can consider opening interfaces in small modules for unified control and management by the upper layer. Finally, I want to say that when we separate and disassemble the business, we can consider following the above solution, and finally we have to design according to the actual situation.

4. Development and implementation

After completing our design work, we enter the development and coding stage, in which we mainly express our design and finally achieve tangible results. Before entering this stage, our design cannot be just a document, but should be a kind of consensus reached by developers and architecture designers. No matter how good the design is, it also needs to be well expressed and implemented. The following mainly discusses the issues that need to be considered during the implementation process.

(1) Project subcontracting

The subcontracting structure of a project reflects the architecture of a software. We are always confused when we are doing subcontracting. Because we have many ways of division, for example, we can divide it into activity, fragment, adapter, util, etc. according to the function of the class. Sometimes, we divide it according to the functional modules. For example, there is a word search module and a question search module in the one-click search, and there are also small peripheral general functional modules such as network requests and software upgrades. The problem is that there are some things that can be reused between modules, so there is obvious code redundancy when we split it. If we divide it according to both schemes at the same time, there will definitely be confusion in the architecture. How can we achieve a balance between the two? I think this also needs to be based on the size of the project. If it is a very small project and there is no possibility of business expansion, we can adopt the first scheme mentioned above, and simply classify it. However, for larger projects, I recommend using the second scheme. Below, I will simply list a model for reference only:

 + app
 +main
 +com.jfg
 +common //Common basic services
 +util
 +wedget
 +base
 + function //General technical business
 +camera
 +sensor
 +moudule //Special function business
 +modeA
 +model
                    +presenter
 + view  
 +modeB
 +model
                    +presenter
 + view  
 +modeC
 +demo //Main program
 +app
 +activity

As shown above, we split and subcontract the common basic business according to the initial project business. In most cases, this package is unchanged and provides basic services for the app. However, we try not to put it in this common package. If this common package becomes large enough, we must think about whether it should be split. Because common gives people the feeling of everything, it makes it difficult for us to quickly recognize the responsibilities of this package. We can understand that the common package is some business designed for aspects, but it is not absolute. Next, let's talk about the module package. In fact, the business is modularized here. As above, we split moudleA and moudleB, and there is no connection between the two. However, we will have a problem, that is, some of the business of moudleA and moudleB is the same, and we seem to repeat a lot of physical work when we split them. This should be the trouble faced by most developers. How to balance this? This is what I think. If there are overlapping businesses between moudle and moudleB, we extract these businesses into function packages or common packages, which reduces the level of the business. We allow each module business of the module package to rely on the basic services provided by function and common. In order to better distinguish between module A and module B, which overlap but logically belong to each other, we have two ways to do it. The first is to abstract the two businesses to a certain extent, and put the implementation process into each module business. The second solution is to define two interface classes, each defining its own interface. The methods of these two interface classes are implemented in the specific implementation class, and the same logical operations are performed internally. In this way, from the outside, moduleA and moduleB are logically separated. In short, how to subpackage still needs to weigh the pros and cons, and try to divide with one mindset to avoid design confusion.

(2) Abstract interface

If you say that abstraction is important in architecture design, you may be a little confused, but if you are asked to write interface or abstract class first instead of class, you may feel the meaning of abstraction. We decompose a system into several large modules, a module is divided into different levels, and each level is further divided into different detailed businesses. Finally, we know clearly what we need to do to complete a certain function? Yes, what we need to do is an interface. When we code, we write the interface first and then the implementation, which helps us to split and abstract the business. We all know that in general, we need to provide some conditions to do something, and there will be a return result after it is done. These can be done in the design of the interface. We need to pay attention to that an interface only does one thing. If two things are very similar, we should try to split them instead of merging them. In terms of interface naming, we should make the name clear. How to judge is that if your interface has no comments, it is also good for people to know what your interface does.

(3) Data storage

Commonly used data storage methods include SQLite, SharedPreference, files, etc. Can cache also be considered as a type? What I want to emphasize here is that you should pay attention to the standardization and security of data storage. If it is a database, it is also necessary to consider its scalability. If it does not meet the requirements, it will need to be upgraded.

(4) Performance management

This comes from a little experience in performance optimization. For server-side development, we cherish server resources very much, which should be visible and need money to buy. However, for client development, we often overlook this point. Although mobile devices now have large memory, performance is also a very important indicator for writing an excellent program. Performance optimization processing means we are correcting errors, so we should make fewer mistakes in the future. The performance experience is not good enough, which is nothing more than the uncontrolled use of the memory, CPU, and GPU resources of the machine equipment, resulting in a waste of resources. When the machine equipment cannot bear it, the application will experience card segments, crashes, abnormalities and other adverse reactions, which seriously affect the application experience. What we have to do is to have a strong sense of performance management, borrow memory, CPU, GPU and other resources on demand, and make sure that there is a return after borrowing, that is, remember to release the resources after use.

(5) Special treatment

During the development process, there are always many problems that are not solved according to normal thinking. This is thanks to our strong testing team. Different methods can get different results, which gives us a lot of bugs. Therefore, we need to pay special attention to the handling of some special cases in software development, which are often logical blind spots in the end. The following is a brief summary of some:

Functionality conflicts

Functional conflicts can be divided into two types, one is the functional conflict within the application, and the other is the functional conflict between applications. For example, if function A and function B both use a certain resource file, there will be problems if they are used at the same time. We usually add a synchronization lock to prevent this conflict. There are many conflicts outside the application, such as multimedia, alarm clocks, calendars, ringtones, calls, etc., which may cause these conflicts. For example, you are playing a video and a call comes in. Which one should I prioritize? Also, when the alarm rings, a vertical screen interface pops up, then it will force the current interface to become vertical screen. What if you are in horizontal screen at this time? There are many similar cases, which will be summarized in detail later.

Extreme Operation

Our testers like to click a button frantically, or install countless applications on the machine to fill up the memory, or fill the disk with various files. Although these scenarios are not what rational users would do, they are actually program defects. Therefore, we must pay attention to dealing with these problems.

Network Issues

Unavailable networks, networks with weak signals, networks switching between wifi and data, 2G and 4G networks, network request timeouts, etc. all require us to handle them according to the actual situation, such as whether to remind the user when switching back to data for downloading. These processes are also standard for each application, so I won't go into details.

Handle null

This should be the most common problem. Most of the problems we usually encounter when fixing bugs or capturing background exceptions are null pointer exceptions. First, we need to figure out what the reason is for null? Then we need to judge whether it is null and warn.

(6) Log printing

I singled out the log printing here because I think it needs to be taken seriously. What is the log used for? Obviously, it is used to help us find problems. In most cases, we print when problems arise, and there are many tags. We use Log.d for errors, and Log.e for information. When we check problems, we have to read a lot of code logic and finally locate the location. We spend a lot of time reading the code when fixing bugs, which greatly affects work efficiency. If we have a good standard design for log at the beginning of coding, we use Log.e for abnormal places, Log.w for possible problems, etc., Log.i for key information, and Log.d for temporary debugging. Wouldn't it be good to distinguish them like this? We can distinguish the information we need in the console. We should make full use of this tool to help us quickly locate problems.

(7) Software Refactoring

Refactoring is done because of business needs and higher quality requirements for code. Refactoring is everywhere. We should not refactor for the sake of refactoring, nor should we stagnate and not refactor when we should, owing too much technical debt. Refactoring can be as small as the refactoring of a method or as large as the refactoring of the entire system architecture. Refactoring is a necessary process for software iteration and upgrading, and it is also a necessary means for us to meet current needs, adapt to future development, and obtain good scalability. Refactoring is not difficult, nor is it a big deal. The key is whether the purpose, ideas, and design behind the refactoring are clear.

(8) Compatibility and Adaptation

Compatibility and adaptation is a headache for us in development. Android devices have different screen sizes and different Android system versions. In addition to targeted processing, we also need to remind product designers to consider compatibility issues at the beginning of design.

5. Software Testing

Software testing is a very important process in our development. In addition to being able to objectively sense the quality level of the software we develop, the ultimate goal is to help developers fix software defects and improve the quality of the software. In addition to the self-testing before the developer submits the test, we need professional testers to conduct the test. The efficiency of manual testing is relatively low, so we should consider completing automated testing through technical means, such as unit testing. This is conducive to the stability of the software and also helps developers improve the quality of the code.

6. Development Specifications

(1) Consistent design

What kind of design is a standardized design? I personally think that a project that maintains a consistent design concept is a standardized design. We can understand it this way: in a certain type of situation, we follow a similar solution to solve this type of problem. Facing a complex system, one design concept may not meet the needs of the architecture, but we only need to understand that this kind of thing is done this way, and that kind of thing is done that way, and the flexible combination between them does not overlap, giving people a clear sense of design ideas.

(2) Clear coding

What kind of code is high-quality code? I think code with simple structure, clear logic, and easy to understand at a glance is a high-quality code. Therefore, we can put aside those coding standards, naming standards, etc., and re-examine our own code to see if it is comfortable to read. If a new colleague comes and knows nothing about you or the project, can he quickly understand your thinking? The last few points need to be raised. First, use design patterns with caution, second, write as few document comments as possible, and third, follow the six object-oriented design principles of Java. I think these three points are the principles of coding. Following these principles and forming a habit will naturally become a norm.

(3) Document validity

What kind of document is an effective document? I think that the document that can explain the core issues is an effective document. As software developers, we don't have the patience to read a complex and lengthy document. Documents only need to present us with problems that the code cannot explain, help us quickly understand the project structure, memorize key issues, and trace historical records. There are many forms of documents, such as our Git commit records, tags, project structure diagrams, core function flow charts, etc. In short, documents are for people to read, so it is better to use as few documents as possible to explain the core issues.

7. Daily work

As a qualified software developer, we have many daily tasks, such as bug fixing, exception handling, Monkey, performance optimization, code quality improvement, etc. You are not required to do these things every day, but you must pay attention to them every day and keep them in mind. Only in this way can you develop a good programming habit and write excellent code and excellent programs.

VI. Overall planning

1. Development Driver

The normal operation of a project must be led by one party, who constantly puts forward product requirements and organizes project members to work together to complete product development and delivery. The following are two types of driver development models.

TDD: Test-Driven Development

Test-driven development refers to development work led by testing. Starting from the use of the product, test requirements are put forward for the product's functions, and various roles in the project are organized to complete development tasks.

BDD: Behavior Driven Development

Agile development is behavior-driven development that places more emphasis on product design and encourages each role in the project to put forward their own views on project development in order to obtain better product features and complete product development.

2. Agile development

The following picture is a picture about agile development on the Internet. At present, our team is basically conducting agile development based on this model. I think agile development emphasizes the communication and quick response between various roles at any time. We do not conduct a complete and detailed design of the entire system, but conduct phased design and development work and seek continuous iterative updates. In the process of agile development, the common problems are untimely communication and large product changes, so how to dynamically coordinate management becomes very important. We have review meetings with personnel from various relevant roles through demand review, interactive review, visual review, bug review, etc., and jointly make decisions to ensure the smooth progress of software development. It has to be said that there are still many problems in this process, such as communication problems, product change problems, and procedural problems in the development process of product function details. I will not go into details here, and I will summarize them later when I have time.

3. Reach consensus

One feature of agile development is that product development decisions are made by all members of the project, and the issues in each role area are finally decided by the role itself. Then a problem arises, and the issues decided by each role are checked and balanced by other roles. For example, the functions designed by the product manager have technical difficulties for developers, and there are logical loopholes in the interactive design. I think these problems are the real reasons why a product cannot be completed as expected. So, which role will coordinate and manage these problems? Usually, we have architects, project managers, bosses and other roles to control and manage the project.

The design of software architecture is based on product requirements and determines the final form of the product. However, for us who are in agile development, product requirements change very quickly, and we developers are required to respond to such changes quickly. Therefore, it is very important to keep the overall architecture of the software and the design of the product updated synchronously.

For developers, we must first have an overall understanding of the project and keep abreast of the dynamics of the product. These include product design, iteration plans, development resources, quality requirements, delivery requirements, risk avoidance plans, etc. Then, according to the changes in product requirements, dynamically adjust your own software architecture. These tasks include technology selection, architecture design, code refactoring, document updates, etc. to adapt to new requirements, and share this architecture with relevant personnel to reach a consensus. This consensus can only be achieved through overall planning of products and technologies. Only when all relevant stakeholders in the project can reach this consensus, our communication will be more effective and we can produce products that satisfy all parties.

VII. Conclusion

At the end of writing, I looked back and found that my overall understanding of the architecture stood on the side of the decision-making faction, that is, this consensus is a collection of decisions made in some important aspects of product planning, design, and development. These decisions are the consensus reached by members of various roles in our project through planning meetings, review meetings, iteration meetings, etc., and are ultimately reflected in our products. Product, interaction, UI, development, testing, each role is responsible for their own field and also needs to keep abreast of information in other fields at all times so that they can make the right decisions. However, in the architectural design of software technology implementation, I tend to be a composition faction, splitting and combining the business of the software system to achieve system operation. I must admit that my understanding is still not clear enough at the moment. Most of the aspects in this article are still general. There are still many things to study if you go deeper into each problem. I hope to have a deeper understanding in my future work.

8. References

• Xiaogang's Architecture Thinking Series
• The Ele.me mobile app architecture evolution
• Ctrip Mobile App Architecture Optimization Journey
• The Evolution of Nuomi Mobile Component Architecture
• Architecture Optimization Practice of Suning.com Mobile Terminal
• Thoughts on the overall architecture design of Android App
• What frameworks are generally used for Android development?
• The road to decoupling mobile Tmall
• What is Agile Software Development?
• The Beauty of Architecture
• Software Architecture Design

postscript

After studying and thinking about architecture for a period of time, I found that these theories can be applied not only in software architecture, but also in work and life. Try to separate our work tasks, reduce the overlap between each task, avoid doing things one-sidedly, and complete each task in an orderly manner. In this way, your work goals are clear and it is easier to achieve the set goals. Similarly, we can also plan our lives through this theory. Separate our careers, families, interests and hobbies, and then separate each of them into more detailed focus points, and set small goals for each focus point at different stages. In this way, we can have a clearer understanding of ourselves, what do we already have? What do we want in the end? How do we plan? What do we do now? Of course, not every step can be taken according to the set goals. We need to constantly update our understanding of ourselves and make more appropriate decisions.