"Tao begets one, life begets two, two begets three, and three begets all things." -- Tao Te ChingCopy the code

Picasso is a high-performance cross-platform dynamic framework developed by the Mobile RESEARCH and development team of Dianping. After more than two years of gestation and development, it has achieved large-scale application in multiple business groups of Meituan.

Picasso comes from our rethinking of big front-end practices and achieving high performance page rendering goals with a simple and efficient architecture. In practice, the migration of Native technology to Picasso technology can even be used as a performance optimization tool; At the same time, Picasso has made a breakthrough in his work spanning the small program end and the Web end. He is expected to achieve a high-performance big front-end practice based on the unified big front-end practice of the four terminals (Android, iOS, H5 and wechat small program). At the same time, Picasso layout DSL strong expression ability and Picasso code generation technology can further improve productivity.

Dynamic client

In 2007, Apple released the first iPhone, which “redefined the mobile phone” and ushered in the mobile Internet boom. Android, iOS and other mobile technologies have broken the situation that Web application development technology is about to become dominant, and a large number of applications have sprung up like mushrooms after rain. Mobile development technology provides users with better mobile terminal use and interaction experience, but its “static” development mode has brought heavy burden to the Internet team that needs rapid iteration.

Client “static” development mode

Compared with Web development technology, client development technology is inherently “static”, which can be viewed from two dimensions of space and time.

From the perspective of space, integrated release is required. Meituan App carries a large number of businesses, and it is the company with the most cross-business convergence and horizontal developers. Although the developers have made great efforts to complete the decoupling and separation of components between businesses, the following problems are still inevitable:

  1. The compilation time is too long. Integration compilation takes longer and longer as code complexity increases. The r&d effort is consumed by waiting for compilation, and integration checking becomes a huge challenge.
  2. App packages are growing too fast. This is consistent with the rapid development of the Internet momentum, but with new user expansion and business iterative evolution formed a sharp contradiction.
  3. Runtime coupling is severe. In the package released by integration, any abnormal behavior such as Crash or memory leak caused by any functional component will lead to the decline of the availability of the entire App, bringing great losses.
  4. Integration is difficult. Code reuse and coupling between business lines, business layer, framework layer, basic service layer is complicated, need to split out a considerable number of compatible layer code, affecting the overall development efficiency.

From the point of view of time, centralized release, online Bug repair or hot fix, high cost. The addition of new features must also wait for a uniform release cycle, which is unacceptable for a rapidly growing business. App development also faces the serious long tail problem of not being able to provide the latest features to users using older versions, which seriously harms the interests of users and business parties.

This “static” mode of development will have a negative impact on r&d efficiency and operational quality. For traditional desktop application development, the static development model may be relatively acceptable. However, for the mobile Internet industry with booming business, the contradiction between static development mode and agile iterative release demand is becoming increasingly prominent.

The tendency for client dynamics

How to solve the problems caused by the “static” mode of client development?

The industry’s early answer was to use Web technology

However, there is a gap in performance and interactive experience between Web technology and Native platform. In scenarios where performance and interactive experience can be compromised, Web technologies can be supported by custom containers, offline, and other technologies to host operational pages that require rapid iteration.

Another idea suggested by the industry is to optimize Web implementations

Using the flexibility and high performance of mobile client technology, reengineering a “standard Web browser”, making “Web technology” have high performance, good interactive experience and dynamic Web technology. In this technology wave, Facebook became a pioneer again, launching React Native technology (RN). RN, however, has an odd design approach. It’s not compatible with the standard Web and doesn’t even make an effort to align Android and iOS behaviors. As a result, all of the companies that are doing this need to do secondary development to basically align with the two-end appeal. You also need to do your best to pay for RN’s compatibility problems, stability problems, and even performance problems.

And we said Picasso

Picasso took a different approach. While achieving high performance dynamics, he was able to integrate dynamic pages, dynamic modules and even dynamic views into the business development code, which won the approval of many mobile r&d teams.

Breakthrough progress has also been made in the practice of Picasso framework across Web end and small program end. In addition to achieving the goal of big front-end integration with four ends unified, Picasso’s layout concept is expected to support high-performance rendering of four ends, in combination with Picasso code generation technology and Strong expression ability of Picasso. Productivity has been further improved on the basis of large front end unification.

Picasso kinetic theory

Picasso application developers write layout logic using general-purpose programming language-based layout DSL code. Layout logic According to the given screen width and height and business data, the layout information, view structure information, text, image URL and other necessary business rendering information can be calculated to accurately adapt the screen and business data, which is called PModel. As an intermediate result of Picasso layout rendering, PModel corresponds to the final rendered view structure; Picasso rendering engine builds the Native view tree recursively based on the information of PModel and completes the filling of business rendering information to complete Picasso rendering process. It should be noted that the rendering engine does not do adaptation calculations, and uses the layout DSL to express the layout requirements at the same time, which is called “expression as calculation”.

In the bigger picture, Picasso developers write Picasso applications in TypeScript in VSCode; After submitting the code, Lint can be automatically checked and packaged through the Picasso Continuous Integration system, and grayscale released in the Picasso distribution system. Finally, The Picasso application is delivered to the client in the form of JavaScript package, which is interpreted and executed by the Picasso SDK. Achieve dynamic client business logic.

During application development, TypeScript’s static typing system, coupled with VSCode and Picasso Debug plug-ins, offers a development experience of intelliscopation and breakpoint debugging comparable to traditional mobile client development ides. Picasso CI works with TypeScript’s type system to avoid low-level errors and facilitate multi-party and multi-team collaboration; At the same time, it can effectively solve the long tail problem of capability support through “compatible computing”.

Picasso was a DSL layout

Picasso did a systematic analysis of the dominant mobile layout engines and systems, including:

  1. Android development commonly used LinearLayout.
  2. Front end and Picasso similar dynamic frame used FlexBox.
  3. Apple’s AutoLayout.

Apple’s official AutoLayout lacks a good DSL, so we will directly compare AutoLayout DSL solutions contributed by the mobile developer community.

First, the AutoLayout system was the worst performing in terms of performance, with the time spent on “layout calculations” increasing exponentially as requirements increased in complexity. The FlexBox and The LinearLayout have greater performance advantages than The AutoLayout. But LinearLayout and FlexBox introduce performance problems by allowing developers to add unnecessary view layers to concepts needed for layout.

In terms of flexibility, LinearLayout and FlexBox layouts have strong conceptual constraints. One emphasizes linear layout, the other emphasizes concepts such as box patterns and scaling, and these models have to use programming languages to intervene when layout requirements and model concepts do not match. And because of the isolation of the layout system, such intervention is not easy to do, which affects the flexibility and expression ability of the layout to a certain extent. A DSL designed with a general-purpose programming language, coupled with AutoLayout’s layout logic, provides theoretical maximum flexibility. But all three were trying to solve “the problem of expressing layout logic in a declarative way,” and the introduction of programming language-based DSLS made layout computing engines redundant.

The core of Picasso’s layout DSL is:

  1. Design based on general-purpose programming language.
  2. Support for the anchor point concept (as shown above).

Using the anchor point concept, it is easy and clear to set the “anchor” view position of two anchors that are not in the same coordinate axis. Anchors also provide semantic support for describing “relative” positional relationships. In fact, the need for layout is more likely to be described in the human mind as something like “B is to the right of A, spaced 10 apart, and aligned at the top” rather than “A and B are in A horizontal layout container…” . The anchor concept eliminates the semantic gap between requirements description and the underlying implementation of the view system through a minimalist implementation.

Here are some typical examples of anchor points:

1 Center aligned:

    view.centerX = bgView.width / 2
    view.centerY = bgView.height /2
Copy the code

2 Right align:

    view.right = bgView.width - 10
    view.centerY = bgView.height / 2
Copy the code

3. Relative arrangement:

    viewB.top = viewA.top
    viewB.left = viewA.right + 10
Copy the code

4 “Fancy” layout:

    viewB.top = viewA.centerY
    viewB.left = viewA.centerX
Copy the code

Picasso anchor point layout logic has the most flexible expression ability in theory, and can achieve the expression layout demand of “what you think is what you get”. But there are times when we find that such expressive ability is “overdone” in certain situations. Similar to the layout requirements below, four view elements should be arranged horizontally, spaced 10 apart, and aligned at the top. There might be anchor layout logic code like this:

v1.top = 10 v1.left = 10 v2.top = v1.top v3.top = v2.top v4.top = v3.top v2.left = v1.right + 10 v3.left = v2.right + 10  v4.left = v3.right + 10Copy the code

Obviously, such code is not particularly ideal, because there is a lot of repetitive logic that can be abstracted. For such demand scenarios, Picasso provides the hLayout function, which perfectly solves the problem of horizontal layout:

    hlayout([v1, v2, v3, v4],
           { top: 10, left: 10, divideSpace: 10 })
Copy the code

You can find that this is exactly the same with the classic LinearLayout of the Android platform. Corresponding to the HLayout function is vLayout, a pair of sibling functions that almost fully implement the semantics of Android LinearLayout. The implementation logic is less than 300 lines. The emphasis here is not on the two layout functions, but on the unlimited abstract expression ability of Picasso Layout DSL. If a business scenario needs a Flexbox or other conceptual model, business applications can quickly implement it on demand.

In terms of performance, The Picasso anchor layout system avoids the “declarative to imperative” calculation process, completely eliminates the involvement of the layout computing engine, and achieves the effect of “demand expression is calculation”, providing the best performance in theory.

Thus, Picasso layout DSL is superior to the above layout system both in terms of performance potential and expressiveness. The design of Picasso layout DSL was the cornerstone of Picasso’s ability to build a high-performance four-terminal dynamic framework.

Thanks to the expressiveness and scalability of Picasso layout DSL, Picasso also has a unique advantage in automatically generating layout code, which is more maintainable and extensible. With the popularity of Picasso, the current process of “visual reduction” in front-end development will be a thing of the past, and the experience of front-end developers will be freed from the repetitive labor of “copying” visual art.

Picasso High Performance Rendering

The industry’s expectation for dynamic solutions has always been “close to native performance”, but Picasso achieved the equivalent of native rendering efficiency in complex business scenarios that could go beyond the basic practice of native technology. According to the current practice of Picasso in Meituan Mobile team, the same page can achieve better performance by using Picasso technology.

Picasso achieved high performance based on efficient native rendering on the host, but achieving the effect of “outperforming blue” is somewhat counterintuitive, and there is a theoretical inevitability behind this:

  • Picasso’s anchor layout allows layout expression and layout calculation to happen simultaneously. Redundant and repeated layout calculations are avoided.

  • Picasso’s layout concept flattened the hierarchy of views. All views stand on their own, with no redundant hierarchies for layout logic.

  • Picasso design supports the calculation process. Part of the process that would otherwise need to be evaluated in the main thread can be done in the background thread.

In normal native business coding, these optimizations are difficult to make the best of, because the increase in application logic complexity is unacceptable for the performance gain from each small point. Picasso rendering engine is a “unified reuse” of performance optimization that can be done by traditional native business logic development, realizing the goal of one-time optimization and overall benefits.

Picasso’s use within Meituan

Picasso cross-platform high-performance dynamic framework has attracted wide attention since it was released within the Group. The group also recognized the direction of client dynamic, and actively carried out Picasso application practice in business scenarios in urgent need of agile release capability. After more than two years of internal iteration, Picasso’s reliability, performance and business adaptability have been recognized by the group, and Picasso dynamic technology has been widely used.

With Picasso’s bridging capabilities, top-tier Applications based on Picasso can still leverage the high-quality infrastructure accumulated by mobile technology teams within the group, while already forming an initial internal ecosystem, Multiple departments have contributed animation capabilities, dynamic module capabilities, reusable Web container bridge infrastructure capabilities, a number of business components and common components to Picasso Ecology.

In addition to maintaining the Picasso SDK, Picasso Continuous integration system, including vscode-based breakpoint debugging, Liveload and other core development tool chains, the Picasso team also provided a unified distribution system for the group. It laid a solid foundation for the big front-end team of the group to carry out Picasso dynamic practice.

As of press time, BG, the leading Picasso application within the Group, has realized That Picasso dynamic technology covers more than 80% of business development. It is believed that after a longer incubation period, Picasso will become the “magic weapon” of Meituan mobile development technology and help the company’s technical team achieve rapid development.

Here are some examples of Picasso’s use in Meituan:

Picasso has a big future

Picasso succeeded in moving the client in a dynamic direction, addressing the pain points caused by the traditional “static” model of client development. To sum up:

  1. If you want to publish quickly, use Picasso.
  2. If you want high delivery quality, use Picasso.
  3. If you want a great user experience, use Picasso.
  4. If you want high performance, use Picasso.
  5. If you want to automate layout code generation, use Picasso.
  6. If you want to be productive, use Picasso.

So far, Picasso has not stopped his pace of continuous innovation. At present, Picasso has made breakthrough in the adaptation of the Web terminal and wechat mini program terminal. Just like His achievements in the mobile terminal, Picasso will unify the four terminals (Android, iOS, Web and mini program) and at the same time, Build big front-end practices that are faster and stronger.

The industry has a lot of imagination and longing for the future of big front-end integration. Picasso dynamic practice has opened a new possibility for the future of big front-end.

Picasso is not open yet. If you are interested in Picasso, you are welcome to join the family of Dianping.

Author’s brief introduction

Xiaoyan Picasso, head of the core SDK team, has eight years of mobile app development experience. He joined Dianping in 2012. Picasso core SDK team is committed to exploring better client dynamic practices, contributing to and maintaining high-performance and reliable Picasso SDK, and promoting the guidance and construction of Picasso application and grand ecosystem.

Dawei Picasso Project leader, mobile technology leader of the review platform. While continuously delivering platform products, the review platform continues to output the framework and scheme supporting the group’s mobile technology; The mobile technology team of the review platform is also a broad Picasso team. It has fully participated in the construction of Picasso tool chain, Picasso continuous integration system, Picasso distribution system, and Picasso core UI components. The review platform will continue to facilitate the dynamic evolution of the group’s mobile terminal business.