I am participating in the 2022 Spring Recruitment series of activities – experience review, click to view the details of the activity.

preface

Recently, a React Native outbound visit project was launched. The users are external visitors of the company. The external visitors go on field visits according to the business of the company, collect and record some data. At present, the project is in trial operation stage and has not been formally delivered. After the APP project was launched, users encountered various problems in real use, and some problems were also difficult to deal with (such as weak network situation). This time, we mainly reviewed the problems related to weak network (or network instability) in actual scenarios of APP.

Original APP demand proposed by project demander (only the part affected by weak network is listed)
  1. APP functions should support normal operation even without network
  2. Automatic data synchronization in offline mode. (Including pictures, recordings, client operations, calling back-end business interfaces, and realizing data synchronization of client offline operations to the server)
  3. 5 minutes automatic upload APP positioning. (Regulatory requirements)
Problems encountered in weak network during the trial run of APP

Premise: The APP functions normally when the network is normal and when there is no network, but in the trial operation stage, users in some parts of China (such as Sichuan) will actually have a large number of weak network signals, such as underground garages or old urban areas, when operating the APP, there will be abnormal functions, which are shown as follows:

  • Failed to upload photos or recordings
  • APP regularly upload and synchronize task request, interface timeout in weak network condition, page operation flow after a wave of “network exception” pop up
  • Some page data cannot be displayed after operations. For example, if the status of a data changes, the system returns an empty list
  • Page switching jump, data is empty, or the page is blank
  • Offline data operation, data synchronization behind the network, in the case of weak network, data synchronization between the server and APP is chaotic
  • Some core business processes fail. Intuitively, the data status verification fails
  • The “loading” message is always present when you take a photo and save it
  • Functional exceptions reported by different users were also inconsistent
Problem analysis

The trial operation mode of the project is that users in Beijing will first run for three days. After passing the trial operation in Beijing, users in other parts of China will be gradually opened. Beijing area users formal trial in three days, work in the day time development testing personnel take turns to visit Beijing r&d center, on-site guidance in doubt, the APP in the Beijing area during the test run, didn’t find weak network related issues, a functional optimization fine-tuning, try other domestic areas, individual user feedback function abnormal situation, After the users in Sichuan started the trial, a large number of abnormal APP functions were reported within a week. Through communication with users in Sichuan, we found that the problem was caused by weak network signal in some parts of Sichuan.

When the internal network test of the functional developer is OK, the tester uses Charles packet capture tool to set weak network parameters, and the independent test finds that the normal operation of the core process of APP is affected. The analysis from the technical implementation layer is as follows

  • The interface for uploading pictures and recordings in the APP times out on the weak network. As a result, the data on the server cannot be matched, and the status check of some data on the APP fails
  • In the case of weak network, some page data cannot be displayed after operations. The data is empty or the page is blank. In the case of weak network, the APP rendering engine is executing and JS engine is waiting for the request response. The code for JS to control the display of data has not been executed yet. After a long time (some pages exceed 60s), the data can be displayed normally
  • Manually set offline network, connected network and weak network in Charles tool. When switching between the three network conditions, the APP functional process cannot go through, and the process cannot be carried out due to data chaos
  • APP background timing request data synchronization process, the code will be polling calls offline cases user operation interface, to synchronize data to a server, weak interface response slow large network request timeout, offline page operation process go after a wave of a pile of “network anomaly” prompt pop-up, “network anomaly” by the request of the front-end control the pop-up blocker
  • Offline data operation, network data synchronization, after MMKV used in the APP store operation data, a network after according to operation steps, in order to invoke the back-end corresponding operation interface, the backend interface implementations have queue, part of the part in the cache, directly read a part of the database, weak network circumstances, the local operating results and the service side return data inconsistencies, The user cannot continue the flow operations
  • Different models of mobile phones do not support the positioning function, and some mobile phones cannot be located when running in the workspace
    • The mobile phone is purchased by the company and customized in batches directly from the mobile phone manufacturer, because the project requires compliance supervision of users
    • The price of the customized phone is more than 1000 cheap Android machine, the hardware configuration is mediocre
    • Working space provided by the mobile phone manufacturer used (Tracking manager)
    • The phone can only run apps that are open in the workspace, other functions are disabled, and permissions are set directly from the system level

The reasons can be summarized as three aspects

  • The offline synchronization scheme has defects. Currently offline synchronization mechanism, front-end offline operation, local storage data, monitoring the web polling timer after sending each operation records, operation records synchronization is call the corresponding backend interface, front end and contain user operation call interface, interface and the corresponding parameters, according to the operation records and stored in an array, the timer periodically offline array data, The front-end invokes the back-end interface during the polling synchronization process on the network. At this time, users will directly fetch the unsynchronized data returned by the back-end when they operate on the APP or refresh, which will cause data confusion. The front-end does some processing, but it cannot completely solve the confusion during data synchronization.
  • In the case of weak network, JS request blocks the execution of JS code, rendering engine executes, but the corresponding JS engine code does not execute, resulting in users thinking APP function is abnormal. Chrome and Firefox use different threads to send JS requests and execute JS respectively. This is the optimization of the JS engine by the browser, but not on the APP
  • Different models of mobile phones and different Versions of Android have different support for native function calls
To solve
  • As for the offline synchronization scheme, SQLite is recommended for the front-end scheme before the project starts. In offline cases, data generated by APP operation will be directly stored in the database, and data will be directly synchronized when the network is connected. In this way, the workload of the front and back ends will be less, and the implementation of the scheme will be relatively reliable. However, the technical manager (back-end development manager) and back-end personnel of this solution do not agree with this method. The back-end thinks that it is too troublesome to operate in this way. The synchronization operation data should be stored in the front end and controlled by the front end, while the back-end only provides a synchronization interface and the rest is processed by the front end. During the development, I encountered problems caused by the defects of the scheme, which were solved unilaterally by the front end. All of them were put into use online, but the adjustment scheme could not be replaced. There were too much logic related to the business function codes of this part, and the time was not allowed. Some user experience was lost by loading and data locking, and data was updated 5 minutes after the process was finished. The front-end group was changed intermittently for more than a month, which could be regarded as a complete restoration of this function.
  • About code blocking, timing request to calculate the request response time, set the threshold, if the response time is long, stop the timer and other request tasks, a few minutes later to trigger the timer again, adjust the code implementation, operation waiting, button disable, add friendly prompt and other solutions
    • Weak network, it is difficult to define in the actual scene, what is the weak network speed? Is the user operation level affected by the network to calculate weak network?
  • Mobile phone different type compatibility, compatibility problems in working space (pursuit butler), etc., all types of mobile phone flash test, to test the APP directly installed on the system is normal, then test after brushing, have installed APP function is normal after work space, optimizing adjustment until the APP can run normally on all models.
    • Different workspace strategies in different regions are inconsistent, leading to some inexplicable problems in APP use by users in different regions in China (even in Beijing Development Center), because abnormal problems caused by the workspace will be solved after IT personnel in the corresponding region rebrush the workspace
Daily development status of the company

  • Online project daily function maintenance and modification, front and back end personnel 1 to 1, the progress gap is generally good

  • In developing a large number of new features, 1 case front-end development obviously lagged behind the backend development, if the business line before and after the end do new projects, the company has a department of front-end back-end 3:7, front of delayed, back-end progress fast front end more than a month, the project manager head still let this situation lasted for a long time, Become mindless compression development time, high frequency of overtime, overtime hours a month 80h+ (this task progress management is amazing)

  • If it involves technical solution adjustment, function modification and other work contents, front-end modification is generally front-end modification. Although there are relevant technical leaders and architecture team, the project will not participate in the development stage after the construction of the architecture (as front-end developer, I have no voice, and one of the most difficult things in daily work).

  • Testing, UI is a separate department not divided by business lines, belongs to the public resources, there is a need to deploy the form

Checking thinking

  1. Technical scheme at the early stage of the design to be thoughtless, offline synchronization problems related function during the development phase, solved after a period of time it is found that the existing solutions are defective, but due to time factor, also is unable to adjust the whole technical implementation scheme of the project, became a principal unilaterally offline synchronization problems solved by the front end, this problem thoroughly, Front-end developers work under a lot of pressure
  2. In the functional development and testing stage, the real scene was not completely restored, such as the bad network signal in Sichuan and other areas
  3. After the function development went online, some developers were not willing to cooperate. As long as there was no problem with their own part, the code would not change, and eventually the problems on the APP were basically front-end problems
  4. Different phone models have compatible functions and work space compatible processing. In the early evaluation, developers do not know the actual phone model and the APP is still running in the work space
  5. End respectively before and after due to some problems can be solved in the front end staff to solve, not well divided responsibility, lead to the front-end code business complexity is higher and higher, code logic is becoming more and more complex, involving the logical part of the changes is becoming more and more difficult, the cooperation process before and after the development process of mood swings, quarrel quarrel, Since this project was composed of personnel from different business lines of the company, the project leader could not deal with such personnel problems well. The leader only mentioned the need for harmony in the meeting without taking any concrete actions
  6. It was the first time for the front-end developer of the team to use ReactNative to develop the APP. Some problems were solved relatively slowly, but the construction period was still evaluated according to the familiar technology stack. As a result, the front-end construction period was always delayed and the team worked overtime frequently to catch up with the progress
  7. In the limited development time, the online on schedule, front-end function style adjustment, operation optimization and other time is not included in the task schedule
  8. The development time is tight and the task is heavy. The front-end developers failed to sort out the code logic in the early stage, and the troubleshooting of problems in the later stage is more difficult
  9. The console.log output in the JS engine blocking code in APP development is also affected, making normal debugging analysis more difficult
  10. At the stage of project development, technical personnel work overtime with high frequency and high intensity, and their work efficiency is low. They also have no life. When they go home, they just sleep, and their happiness index decreases
  11. In this project, the internal person in charge is the front end, who is also responsible for the development of main functions. The front end developers are relatively active in cooperation. For some exposed problems, they can think well through the overall technical situation, and actively feedback to the leaders to cooperate with them to solve some business problems
  12. In the case of tight time and heavy tasks, the front end uses the new technology stack, which is a good training of their learning and practical ability

How to be better

  • For the work of things, are for life and work, not happy is common things, ordinary heart to treat, let oneself live a little relaxed and happy
  • Stay overnight together, side by side overtime, the harvest of overtime comrade-in-arms
  • Daily energy allocation, to maintain a certain amount of free time to manage their own life, learning, promotion, etc
    • The people on the assembly line in the electronics factory are hard workers, and it’s not unusual to work ten hours a day, but their wages are so low
    • People worth over $100 million get together every day to drink tea, talk, play golf, and talk money
    • Put down your phone, close your computer, go out more, meet your classmates and friends, and get into the real world
    • Try to break the circle and make money by integrating social resources. It’s hard. How do you know if you don’t try

Suddenly, I want to ask a question

Why is the front end always working overtime at high frequency?

What can I do for the management and the front end development player that front work simple, modify the function is also easily change front, the back-end business logic and involved, cannot easily move, products UI design front end that can achieve anything, without the back-end to participate in, the front-end development can be based on UI library literally change, literally see the function of the front end also can quickly realize online, The general view is that the front-end work is simple, the salary is not more, there are problems with the front-end change is also very quickly