- background
- The solution
- The principle of
- proven
- Production application Examples
- Ease of use is good
- Polymorphic agreement
- Low learning cost
- Progressive access
- The contrast
- In the late planning
- Idealism,
After nearly 20 months of work, Didi’s cross-platform solution Chameleon is finally open source github.com/didi/chamel… , really focus on one set of code to run multiple.
background
Wechat live 1 billion monthly (more than the number of Internet users, multiple accounts?) , Alipay 400 million, Baidu 330 million; In Q3 2018, Android phones accounted for more than 80% of the smartphone market in China; Both BAT and Android apps are the real user entrance for Chinese Internet users. As small Internet companies, they hope to take advantage of small programs to ride a wave of traffic.
The historical development of computer technology tells us that every new technology will experience the stage of “independent”, and small program technology is no exception. Wechat small program as the founder, although other small programs are deliberately imitate in the implementation principle of technology, interface design, but as a front-line developer in the face of the same application often need to repeat development, testing, formerly 1 unit of work into N units of work.
Didi chuxing’s r&d engineers are among the most prominent victims. The company has access to wechat Wallet, Alipay and Android Apps, and accounts for a large share of user traffic.
A variety of mini-programs have reached all Chinese Internet users, and the project itself has grown since Facebook opened react in 2013. ReactNative, a spin-off of the original WebUI engine, has even more ambitious goals.
Vue. Js was released in 2014 and occupied a large number of user groups against the current. In 2016, Alibaba also released weex project based on Vue, and NativeAPP can be written with Vue.
At the end of 2018, Google officially released future-oriented cross-andoID and IOS Flutter1.0.0, which has a bright future as a future-oriented cross-end framework.
The solution
Although the environment of different end frameworks is constantly changing, no matter all kinds of applets, Weex, React-Native, Flutter and fast applications, they are always the same is the DESIGN idea of MVVM architecture. Chameleon wanted to use one set of code to fulfill all side requirements and converge the same business logic to the same layer of system without making the project less maintainable due to the same abstraction.
Make MVVM cross-end environment unified: Based on the common technical characteristics of various cross-end technologies (Weex, React-Native, WebView browser, Flutter) and product businesses (wechat applets, Kuaiapps, Alipay applets, Baidu Intelligent applets, Toutiao applets, and other applets) — MVVM architecture design, Chameleon, a programming language framework aimed at unifying the MVVM cross-end architecture platform (any terminal designed using the MVVM architecture can be developed and run in Chameleon).
View:
ChameleonSDK includes various applets, Web, and clients (React-Native, Weex, and Flutter). Currently, it supports wechat applets, Web, and Weex, and will support more MVVM as standard applications in the future.
View Model:
CML(Chameleon MarkupLanguage) is a set of label language designed by the framework. It combines basic components, event system, and data binding to build the structure of a page. In order to reduce the learning cost, VueTemplate class is supported.
The principle of
proven
When wechat mini program was released in 2017, Didi, as a whitelist user, first tried to access it. At this time, we specially set up a small project team of 1 or 2 people to complete a project named MPV. The goal of the first phase was to “achieve a set of code to run web and wechat applets without affecting users’ performance and relying on the principles of the framers”. After the development of MPV, more than 90% code reuse has been achieved in several project practices. Overall, the development efficiency and testing efficiency have been significantly improved, while exposing more problems:
- Maintainability issues, no separation of common code and end difference code.
- The direction of MPV is wrong. MPV uses the syntax standard of small program (life cycle of small program, API interface, etc.), which makes it difficult for users to clearly understand the usage specification.
- There are too many small differences around each end.
- The template DSL syntax is not canonical.
- The interface effects at both ends are inconsistent.
- Multi-terminal debugging costs are high.
- Engineering construction is backward.
- There is no direct use of existing ecological components on each side, i.e. there is no standard specification to access existing open source components on one side.
In April 2018, we further expanded the scale of the cross-terminal project and named the cross-n-terminal solution Chameleon/ KMILn /, short for CML. The Chinese word for chameleon means a cross-end holistic solution that can adapt to different environments just like a chameleon.
With the accumulation of MPV practice, Chameleon has not only solved various maintainability problems encountered, but also made the subsequent planning more clear. The goal is really focusing on making a set of code run multi-terminal and providing standard MVV M mode to unify various terminals.
After a year of practice in hundreds of pages by dozens of front-end developers, this week is officially open :github.com/didi/chamel… .
Production application Examples
Ease of use is good
One of the most challenging aspects of the concept of a set of code running multiple sides is how to ensure ease of use.
- Development fast, the overall development process to be efficient.
- Simplicity, large space for customization of each end development, and common code will not be mixed with a certain end of the code.
- Good performance, cannot increase the output file package size.
- Consistency, multi – end to achieve the same effect.
| Develop fast | |||
|---|---|---|---|
| keywords | Engineering development | Project-level unification | Component-level unification |
| describe | Collect the best engineering features: With a variety of data mocks, resource location, proxy debugging, LivereLoad, and more, CML can help developers develop single ends more efficiently than just cross-ends. |
A single set of project code can run multiple ends when the entire business is highly consistent across multiple ends | You’ve developed code with native applets, you’ve developed Web pages with VUE, and you’ve developed recurring components like logins
|
| Simplicity (large space for development and customization at each end) | Performance is good | consistency | ||
|---|---|---|---|---|
| keywords | Polymorphic agreement | Output resource pack size, keeping only single-ended code | Syntax checking | Multiterminal consistent restore |
| describe | The polymorphic protocol can be used for multiple levels of user switching from top to bottom: method level, component level, page level, application level | The compile phase will retain only the parts of the code to be exported, and the built-in components and apis will be packaged as needed | In order to ensure the consistent effect of each end, there is no need to debug each end one by one, and syntax check is done when saving to expose potential problems. | A great deal of work is done in the compile and runtime layers to ensure the consistency of implementation |
Polymorphic agreement
After multi-terminal merger, it is inevitable to realize the differentiation of each end. At the beginning, differentiated code and business logic are mixed together. This is awkward, if you don’t think this is complicated, suppose there are 4 or 5 ends, business logic mixed with cross-end logic, product logic not broken, poor readability, requirements change, pull the whole body, each end has to be tested, cross-end code efficiency becomes counterproductive.
The differentiation code at each end is also mixed with logic
The polymorphic protocol design is inspired by the Apache Thrift – scalable cross-language service development framework, which is also cross-language in nature. It allows Chameleon developers to quickly access the underlying functionality of each client or to differentiate business implementations, avoiding poor readability and maintainability.
The polymorphic protocol defines a standard interface, and each end module implements it independently. The input and output of the interface are checked at compile time and run time.
There are two main objectives:
- Ensure multiple maintainability
- Break up multi-terminal code at compile time
Polymorphic protocol can effectively isolate the common code from the differential code to ensure that “the river does not invade the well” when users extend the functions of individual products with inconsistent effects or specific underlying capabilities according to the standard specifications.
For example, you might use Echarts when you want to develop a charting feature:
- Follow the Web version separately in the project
npm install echartsAnd wechat version download relevant files - Then define a polymorphic component charts
- Define the input and output of this component in charts/ charters. interface
- Call wechat version (wechat applet component folder) and Web version (.vue suffix file) in charts/charts.wx. CML and charts/charts.web. CML respectively.
- Finally, you can use this component in your project
The output package contains the code for only one side of the component; Because of the input and output constraints, the component calls exactly the same, no special logic processing according to the end. You can place the Echart polymorphic component in a separate warehouse for separate maintenance and distribution; Others can use NPM install Echart without having to deal with the internal details.
Low learning cost
The CML syntax of THE VM layer is an abstract DSL of the associated view layer and the logic layer. Its learning cost is the most suggested by many enthusiastic students who help us. Its learning cost is very low, including two-way data binding, event binding, component tree, conditional statement, loop traversal and so on. At first we rejected it, but after some consideration, we compromised to support a VUe-like syntax to make CML easier for developers.
Progressive access
Many people have already developed small programs, but do not want to reinvent most of them, and also want to use CML? Sure, there are two ways to use CML:
| Description/Type | The entire project uses CML | Common components use CML |
|---|---|---|
| The diagram |  |
 |
| instructions | Business layer requirements are highly similar across end environments, There was a need for repeated development and testing for different ends, Then use Chameleon to run the entire project “from top to bottom” in one set of code. |
Common components need to be developed and tested repeatedly, Develop common components using a set of code, Common components can be used directly by each end |
| For example, | Home page, details page, orders | Share component, payment component, Map component, Picker component |
The contrast
Other frameworks in the industry do not have the same goal as us, we want to truly a set of code to run multiple times, while other frameworks are nothing more than “a small program syntax enhancement” or “promote a framework to write small programs”, but there are some overlap, to list the functional comparison:
In the late planning
| The direction of | Direction of the child | Perform project |
|---|---|---|
| Ease of use enhancement |
|
|
| Framework to optimize |
|
|
| End category extension |
|
|
| Component extensions |
|
|
| End capacity expansion |
|
|
| Process optimization |
|
|
| Service extension |
|
|
Idealism,
- We can’t bear to waste our time on repetitive work.
- Either do not do to do to the extreme, a set of code running multi terminal is idealism, this road is very difficult, but we are paranoid to believe that we must do our best to make it, as a not so confident person, not to do good is not dare to release.
- Every detail of the CML framework had to be done to perfection, and we couldn’t tolerate design flaws, so CML weekly meetings would often last six hours into the night.
Quick start: cmljs.org/doc/quick_s…
Frequently asked Questions: cmljs.org/doc/framewo…
Welcome to contribute code: Didi/Chameleon