) UI.

Many software engineers, especially Windows software developers, have more or less experience in UI development. For a software product, the UI is crucial from any angle. The software UI is like a person's face. A person's first impression is very important, and so is a software. If it is difficult to use it for the first time, the chances of using it for the second time will be much lower. Therefore, the software UI is becoming more and more beautiful, and the user experience is getting better and better. Of course, the cost is that the UI system becomes increasingly complex and increasingly difficult. For Program In many cases, UI development is always a tedious and repetitive task. From my experience, the development of UI, especially the development of GUI, is also evolving.

Speaking of programming, I have to talk about my first experience. The first time I got in touch with a computer, I was 92 years old. The school opened a course called "Labor Technology" or "computer. It is actually learning basic programming. The Apple II machine used at that time. The most classic screen is black and white, not pure black and white, and green. The basic interpretation environment of Rom is directly entered when the machine is started. The cursor flashes and waits for the input basic statement. There is no hard disk, and there are 5.25 floppy drives, but I have never heard of a floppy disk. At that time, it was the greatest pleasure to print out some images composed of asterisks (*) through some basic statements. At that time, my understanding of computers was extremely limited. Naturally, I had never heard of the GUI concept, let alone the concept of GUI. Even though it had been ten years since the world's first commercial GUI system was released.

The first time I wrote the GUI was 96 years after I went to college. At that time, Windows 95 was very popular. There are already a lot of 486. But at that time, most of the Games were in the DOS system. Game machine rooms are everywhere on the street, and there are countless places around the school. Most of the machines in the game machine room are on the peer network. There are even many diskless workstations. Most of the Games were played by students. At that time, the students, including those in the computer department, were not very familiar with DOS operations. The boss of the data center won't even connect to the computer line, let alone the DOS commands. Therefore, I wrote a game portal interface that imitates the Windows interface under DOS. Using TC + ASM is actually quite simple. Initialize the screen as a graphic mode, and draw a full set of buttons similar to those in windows on the screen. Enter the game name on each button. You can use the keyboard arrow or mouse to select a button. Press ENTER or click to enter the game. You can flip pages without a scroll bar. The game name and corresponding execution file are written in the configuration file. At that time, I felt quite satisfied that the button selection box adopted a timer to change the color from 0 to. It looked colorful and eye-catching. The most effort is to display Chinese characters. At that time, it was not so comfortable. You need to read the model from the dot matrix font and click it one by one. The most proud thing is that this GUI applet gives the boss of a data center the right to use the computer for free at any time.

After learning the windows program, I started to write it based on the SDK. What I can't stand most is the long message processing function. And it is always getting longer and longer. The most troublesome thing is to re-compile everything above the UI. In addition, the coordinates of each control must be calculated. When I came into contact with MFC at the end of about 98, it was indeed a lot better for UI development. Gradually I can feel that UI development is a very boring thing. In addition, each control is a good character and has no beauty.

The first self-painted GUI was first introduced in the second half of. I just graduated and saw the beautiful product interface in the company at that time, almost all Windows except open/SaveFile dialog are self-painted. The engine did not know which predecessor wrote it. Although the product UI is very beautiful, the engine is not so comfortable to use. It is not a library yet. The product needs to be developed based on the source code and needs to be configured Code The business logic is always mixed with the UI logic. Modifying the UI is even more painful. Fortunately, it is no longer necessary to calculate coordinates for the control, because every control in each window is implemented through graphs. The widget is located by a separate grayscale image called mask. More than a year later, the company thought the engine was really not very useful. Therefore, we decided to develop another engine. The goal is to make UI development more convenient and provide dynamic layout controls during runtime. So it is called dynamicgui. This engine is indeed much better than the first one. First, it is an independent DLL. Source code-Level Reuse is no longer required. This also makes the UI logic and business logic relatively better separated. Next, we will provide a chart for each status of each control, and a mask chart that functions the same as above. In addition to recognizing the widget location, the mask can also identify the widget type. The gradient of the grayscale image can also achieve smooth transition. So it can also be called the mask-driven UI engine. Message Processing of the control is similar to that of MFC using a reflection mechanism. Each control can process its own messages. The most important improvement I think is to provide a very important tool that can automatically cut and pack UED images. And the C ++ code is automatically generated. Programmers only need to write business logic code in empty functions. However, this engine has a common drawback with the previous one, that is, the image resources are very heavy. The UI resources of each product are large. Fortunately, at that time, we were doing Desktop products, and users seemed not very concerned about this. Of course, it also has an impact on program performance. Dynamicgui has been in use for about two years. Two versions are made. One is that the control is non-window, and the other is that all spaces are windows. The two versions have their own advantages. Implementation Based on Windows is simpler, and message processing is also simpler. Non-window performance is advantageous. However, the implementation is more complicated. Then we made another engine, which is similar in nature. The only difference is that the image is no longer a jpg image, but instead a PSD image. The image is merged by layers. Then another UI engine is built on the embedded platform. Because it is used in embedded devices, there are several aspects to consider: 1. Memory and CPU are quite rare resources, so the skin should not only support images but also support solid color rendering. 2. The runtime window must be serialized to the storage device (usually flash) and reloaded if necessary. 3. In view of the diversity of hardware and operating systems of embedded devices, a good cross-platform architecture must be considered. 4. no longer use the mask driver, but the configuration file driver. At that time, XML was not popular, so we used our own defined format. It took some time to implement the entire engine. For cross-platform implementation, the main interfaces of hardware devices (such as 3D hardware acceleration, hardware decoding, and multiplication) and the main interfaces of the operating system (such as file systems and threads) are encapsulated, timer, etc ). In addition to hardware and operating system interfaces, the bottom layer of the entire engine is a graphics engine. For example, framebuffer in Linux, GDI in windows, or some 3D engines. At this layer, you have your own window management system and Message Management System. The top is the general UI engine. Manage layout, skin, rendering, etc.

after that, the main work is back to windows, and the UI engine is still insufficient. However, the implementation is basically not out of the above box. There is no essential difference between the mask driver and the XML driver. The biggest function of the engine is to create an interface through mask or XML. The programmer is freed from the layout adjustment/Paster. You can focus more on implementing other software functions. However, programmers still need to care about the number of controls on the interface and what each control is. You must also be clear about the name (ID) of each control in XML. Although this is small, it is annoying. If the name is not good, you may always need to read the configuration file. It's boring. If you use a tool to automatically name it, it will be even more difficult. To further free programmers from repetitive work, there is also a version of the engine. It is developed based on the above version. The biggest difference is that programmers no longer need to worry about the controls on the interface. It does not care what the control is. These are all automatically driven by XML. From the previous versions, XML or other forms of configuration files are passively improving information, that is, when the program needs information, it needs to ask the configuration file and then parse it. In turn, let XML determine what elements are required on the UI and what functions are implemented. Then the UI engine implements the XML driver. To put it bluntly, it is actually quite simple. In general, every control in the XML configuration file provides a name for the program to use. To implement the XML driver, the most important thing in the XML configuration file is not to provide a name but to implement the function, sometimes you do not need to provide a name. This function description usually corresponds to a function of the program. In this way, the XML driver is implemented. Instead of simply calling the xml configuration file using a program. This version does not use the scripting language, so not all UI behaviors can be described. Therefore, this version only partially implements the XML driver.

At this stage, a complete UI engine is script-driven. A few days ago, I also talked with Zhi Yong about the advantages of the Script driver. For programs: many UI logic is driven by scripts. This greatly improves the flexibility and scalability of the program. The script capability is naturally not comparable to that of XML. In fact, apart from the program perspective, it is also very helpful from the software development perspective. Few mature commercial products have been developed by one person. At the beginning, we said that the UI of a product directly affects the product. The UI design is by no means a programmer's strength. Generally, the product interface is completed by a full-time UI Designer or UED. There is a problem here. The UI Designer usually designs some images and then delivers the images to the developers for implementation in the software. During the design process, the UI Designer cannot see how the UI is running in real time. However, software developers may not be able to fully understand the UI Designer through images, in this way, it is possible that the UI designed by the UI Designer can see the real effect only after the development is complete. In terms of some processes, the UI Designer cannot simply use pictures to express them. This will inevitably lead to communication costs and efficiency between UI designers and developers. In addition, the developer may not be able to use any images obtained from the UI Designer immediately, because the image may need to be cut to conform to the requirements of the UI engine. And write these names to the configuration file... In fact, there is a lot of work in the middle. If the UI engine can completely separate the UI logic from the business logic, you can directly view the program running interface by adding a script to the UI Designer's image, this will inevitably greatly improve the efficiency of UI designers and software developers. If you add another job: script engineer. Then the software development engineers will be able to completely free themselves from the UI development. Focus on implementing business content. The UI part is handed over to the UI Designer and script engineer. I think this is a new software development division. It can be said that there are specializations in the industry, so that UI designers, script engineers and core business development engineers can do what they are good. The efficiency will naturally be much higher. In principle, the Script driver is also very simple, that is, the application will open some objects to the script for script access or control. It is usually called a "controlled object ". Then run the script through the script engine, and the script will operate on the object developed by the application to the script in some cases. Of course, this is also possible, that is, when an application is running, it executes the corresponding event handler in the script when some events occur. Using the com mechanism on Windows can easily support vbs or JS scripts. Of course, you can also use Lua and other scripts. The cost of implementation is not very high.

As we talked about many UI engines, some people may ask what kind of UI engine can be regarded as a good UI engine? I don't think it's easy to answer this question. Because every UI engine is developed for specific application scenarios. No UI engine can be used in all application scenarios. From the perspective of Windows platform desktop program development, I think a good UI engine has the following features:

1. Easy to use: provide external interfaces to be as clear and simple as possible. Users can use it without special training or learning;
2. Efficiency: the efficiency must be high. The initialization window, rendering, and message delivery speed must be fast enough. Memory usage must be low;
3. provides a tool to automatically generate the layout configuration file. You do not need to manually write the configuration file. This is particularly important;
4. provides graphic cutting tools. For cutting graphics. Use of the graphic layout tool after cutting; whether there are perfect tools is an important indicator to measure the quality of a UI engine;
5. Various complex UI la s can be used. In addition, the runtime scheduling can be automated;
6. Easy Localization
7. Multi-layer rendering: each window or space supports multi-layer rendering;
8. Single Window: To achieve brilliant results, non-window controls are implemented in the window. This method is more secure, and it is relatively difficult for malicious users to simulate window control behaviors or perform analysis based on subwindows;
9. The rendering engine is better to use a 3D rendering engine, such as direct3d or OpenGL. With the fifth point added, the effect is much easier. Performance will be much better;
10. supports graphic rendering and color rendering;
11. Script-driven;

From the perspective of design implementation, we also need to have some features:

1. I think the core of a UI system should be the properties of controls or windows and messages/events. Therefore, attribute processing and message processing are critical. If the two contents are not processed well, the efficiency will be poor;
2. Be flexible enough to provide adequate controls. At the same time, you can easily add controls or even add them at runtime;
3. provides unified resource (image, text, Font, etc.) management, preferably with the concept of scheme. Saves memory due to resource overhead;
4. Use a unified rendering interface to switch between different rendering engines;
5. I am not very keen on cross-platform, because cross-platform, performance, flexibility, and so on always need a compromise. We cannot expect that all aspects of a system are the best.
6. For flexibility, I do not advocate the more flexible the better. The reason is the same as 5. We always need some restrictions for doing something, such as using the environment. Enough. But the scalability must be good.

Compare and analyze the current UI engine:

1. It is good in terms of ease of use, clear interfaces, and more in line with the Windows habits;
2. The performance is slightly weaker. Based on performance tests, we mainly focus on processing attributes and messages. The original message uses a string, and then the number is optimized. In fact, using strings has the advantages of strings. In fact, using strings is not the root cause of performance degradation. For example, we have one hundred different messages. You need to identify the sent message. If you compare the sent strings with the 100 message strings, the performance is naturally not good. The simplest optimization is to divide 100 message strings into 20 groups by length. First, the length of the sent message is calculated. Then, you only need to compare them in the group with the same length. This simple optimization can reduce the limit to 100 strings to only 5 strings. The cost is only to calculate the length of a string;
3. Unified resource and rendering interfaces are not provided. More importantly, no proper tools are provided to help developers and uidesigners reduce their work;
4. It would be nice to support 3D rendering engine and single window. Both the performance and UI effect take a step;