🙋🏻 ♀️ Editor’s note: The author of this article is Wei Jun, a front-end engineer of Ant Group, who introduces some technical architecture thinking and practice of Yuque when doing desktop terminal, and shares some common desktop application solutions and experiences precipitated

As a productivity tool provided by Yuque to users, Yuque desktop has maintained high-frequency iteration and healthy business growth for more than two years since its launch. This time mainly introduces some of our technical architecture thinking and practice when doing desktop, and will also share some of the common desktop application solutions and experiences we have precipitated.

The article will be divided into four parts, first of all, it will briefly introduce the application architecture and key points of the current Yuque desktop, then introduce several architectural key items in the architecture, and finally summarize.

Yufinch is a note-taking and documentation knowledge base tool hatched from the Ant Experience Technology Department. Two years ago, we launched the Yuque desktop client in view of the characteristics of Yuque users and the follow-up development strategy to provide creators with a better creative experience.

Compared with the products and services provided by existing browsers, the desktop products we provide mainly consider the following points:

Give the user an immersive authoring experience, unlike browsers with other windows, tabs to interfere with, and the user mind to run out of hands.

Open faster, can be launched with one click or evoke with various shortcut tools.

Multi-window, system menus and shortcuts, reading and writing to files, integration with system software, etc. to improve creative efficiency.

Expect to be able to create without obstacles when you are offline or have a weak network.

The R&D side is mainly divided into three layers on the left, the lowest layer is the infrastructure of Yuque, which relies on a large number of cloud services provided or packaged by Yuque background, as well as the security capabilities and storage modules that the underlying layer depends on.

The middle layer is some of the capabilities of the application architecture, the above is the auxiliary ability used at the code level, as well as the module of the main process, and then there are some management capabilities and some UI-related functional modules provided to the application, and the top layer is the business application built based on the underlying architecture. Including several modules of the desktop application core and some business modules undertaken by the sub-application method (the concept of sub-application will be described in detail later) 

At the same time, there are also many dependent capabilities on the far right to assist research and development to complete the release, quality and stability management of the Yuque desktop terminal.

Compared with ordinary web applications, we feel that the desktop has the following capabilities: including security, software upgrades, and the basic capabilities common to the desktop:

Security is the lifeblood of a productivity tool software, especially as a knowledge management tool, which is very important for safety.

Another big difference between client software and the web is that when there is a feature update, there is an upgrade process, unlike the web to directly refresh the page. As a rapidly iterative product, the desktop terminal of Yuque has also stepped on a lot of pits for upgrading.

The Whisperer desktop consists of two main parts: a package that includes basic modules such as Electron and Node.js, and its own business code.

Mac OS: The upgrade process under Mac is relatively simple, after the software download is completed, hdiutil is used to simulate the user’s manual installation process, and the user can restart to complete the installation.

Windows: Due to the particularity of the environment, after downloading the installation package, the installation interface is automatically opened through the main process to guide the user to manually install step by step.

In fact, this solution satisfies our early function iterations very well, but with the increase in user volume, it also encounters many problems.

Like what:

Each upgrade consumes a huge amount of bandwidth: For each UV installed with nearly 100M downloads, each time the version is pushed, it encounters an OSS traffic alarm, which corresponds to the cost.

Poor installation experience: Because each upgrade is almost a new installation process under Windows, the experience is also relatively poor, and users often complain.

So we investigated a incremental update scheme, an Electron program includes Electron core package and business code, in fact, each change is only the business code, so in theory, each update only needs to incrementally update the business code.

After the Mac increment is downloaded directly to the delta code, it can be replaced.

Windows is more complicated, we mainly encounter two problems:,

File occupancy issues: Due to Windows system characteristics, a file cannot be deleted if it is in use. So if you want to replace, definitely close the program, and then delete it and then start it.

So we wrote a .exe executable to close the program, update the file, and start the whisper.

UAB permission control: Another problem with file writing is that C drive files generally require authorization to operate. We can’t get such high permissions when we start the software. However, a new PowerShell feature has been added to Windows 7 and later, which can guide users to authorize and get more advanced permissions through this function.

Of course, there are also many details encountered in the process, such as the Chinese and English problems of the path in the replacement process, the location of user-defined environment variables, and so on

In addition, in the process of making software, we have also precipitated some components that are not coupled with the business:

In terms of architecture, compared with how cool the technology is used, what is more important is whether the R&D delivery efficiency is high, the performance is good, and the stability is not high. We believe that the following three points are important criteria for judging the quality of architecture.

In terms of desktop functionality, more than 60% of the functional modules, including the editor, are consistent with the web, so the beginning is to use a homogeneous scheme.

Some lessons learned from the isomorphic process:

Although the isomorphic model can solve some of the problems we encountered at that time, with the increase of business scale and function, some problems have been exposed:

Migrating to the Common directory has various dependency issues: many features were already available before desktop, and some complex components are also time-consuming to migrate to Common.

Lack of dynamic capabilities, iterative lag (web and desktop features are inconsistent): After a component is released on the web, the desktop side needs to be released to support it, so it is often encountered that the web and desktop are inconsistent.

Prone to multi-terminal compatibility issues (environmental dependencies, etc.): Although we have defined some specifications, it is difficult to avoid environmental dependencies completely.

The lack of a separate sandbox is easy to affect the main application (memory leak, style): the web may run out and go, can be refreshed, etc., it is not easy to encounter problems, but the desktop side is resident, if there is some memory leakage or style pollution problems, it directly affects the overall availability.

For these reasons, we upgraded the code reuse architecture to a sub-application model, using desktop-side containers to nest an html online or offline page. In simple terms, the sub-application mode can be understood as the various small program modules that Alipay nine squares into.

Fast iteration: Provides independent release iteration capabilities, so there is no need to follow the overall release of the desktop. Moreover, the business students directly follow the entire delivery process, without the participation of desktop students, improving the delivery efficiency.

End-related capabilities: Each sub-application can use the JSBridge capabilities provided by the desktop by default, which is naturally the same as the desktop modules.

Independent sandbox: independent of the desktop main window, the use of desktop containers to complete the rendering, so it can completely achieve process-level isolation, memory overhead between each other at a glance, better to do control, to ensure the overall application stability.

Load initialization: In addition to some of the above advantages, there will also be some problems, such as slow loading speed, etc., we have solved this problem to a certain extent through webview warm-up, caching, etc.

Performance is a problem that desktop software must face and needs to be continuously optimized from different angles

It mainly includes these aspects:

Startup speed optimization: Startup speed is the user’s first image, we mainly cache the main process code, display loading as soon as possible to avoid white screen, the main window and some tasks of the rendering process are executed at the same time to achieve concurrent effect.

Main process optimization: The main process and the rendering process execution are synchronized, if the main process does too many tasks, it will cause the user to use it and even crash. So minimize what the main process does.

Web optimization: At the same time, many of the optimizations done on the web before can be used by the same. e.g. lazy loading, merging modules, etc. (combining multiple modules also has overhead itself)

Webview optimization: For example, warm up the webview and perform some performance control measures to avoid getting out of control.

Performance optimization is not really about doing something that can be completely solved, but a long-term process. Maybe when we add new features in the future, there is a memory leak problem in the code, which can easily lead to performance pulling down the crotch. So we also established some persistence mechanisms:

Mainly including:

Daily observation: in the development mode, establish the ability to observe performance indicators, so that you know what you want;

Automated tasks: There will also be automated tasks on a daily basis, simulating real users to use for a long time, timely discovery of memory leaks and other issues;

Performance dashboard: For the online performance water level, there can be a full perception ability, which can be focused on during the grayscale release process.

The stability of the desktop is also more demanding than that of the web

From the perspective of the R&D process, we mainly have two things:

Single test, integration test: Use code testing to aid overall stability

UIA: Improve stability and detect anomalies in a timely manner by automating UIA test regression that simulates user behavior.

Note: UIA is an automation solution developed by Yuque engineers, see: Macaca MacOS (https://github.com/macacajs/macaca-macos)

In addition, a stability dashboard and real-time alarms have been established to sense online performance. In order to ensure the stability of each release and reduce the cost of regression, we use the agile R&D model of weekly preview release to break down the integration risks caused by large releases.

A little interesting, then a little attention 💁🏼 ♀️

👇🏾 Click “Read the original article” to interact with us in the comments section