Zrender Source Code Analysis 1: Overall Structure

Start

Zrender (zlevel render) is a lightweight canvas class library. Here is my GitHub website. Similar class libraries include kinetic. js and easeljs. However, it seems that zrender is not easy to use (probably better suited to Chinese habits). The powerful Chart Tool echarts is built on zrender, after using zrender and echarts to create two visualization projects on canvas, I couldn't help but read the zrender project code (due to the need to modify the Source Code). However, after opening the project, the code structure is clear and the comments are both Chinese and easy to understand. The biggest impression is that there is no streamlined pursuit of code pole (Bian) (TAI) Like jquery. You can see all the meanings at a glance. If you are not familiar with zrender APIs, go to GitHub. Here, we only analyze the source code in details (Qian) (xian.

Overall Structure

I'm afraid the most relevant description of the overall structure is not as good as this figure: after the project is cloned from GitHub and src/zrender. JS is opened, the following results are found:

VaR _ instances ={}; // Map Index of the zrender instance var zrender ={}; zrender. version = '2. 0.0 ';/*** zrender initialization * prevents external direct New zrender instances. Why? * No. It provides global control and reduces global pollution and the risk of name conflicts! ** @ Param {htmlelement} Dom DOM object, which does not help you with document. getelementbyid: * @ Param {object =} Params personalized parameters. For example, if you have a set of custom shapes, you can bring in ** @ return {zrender} zrender instance */zrender. init = function (DOM, Params) {var Zi = new zrender (GUID (), Dom, Params ||{}); _ instances [Zi. id] = Zi; return Zi ;};

I think it is obvious that zrender is used. during initialization of Init (DOM), a new internal zrender object is directly returned, I think the author has already explained the cause (providing global control while reducing global pollution and the risk of naming conflicts !) It is better than new zrender () every time. At least it looks like this, and each instance can be saved for easy maintenance. As for the other three methods, dispose, getinstance, and delinstance, there is nothing to say, but how can they be used in projects.

/*** The zrender instance is destroyed. The indexes recorded in _ instances will also be deleted. * The administrator must be killed. You can use zrender. dispose (zi) destroy the specified zrender instance * Of course, you can also directly Zi. dispose () destroys the ** @ Param {zrender =} Zi zrender object by yourself. If this parameter is not set, all objects are destroyed */zrender. dispose = function (zi) {If (zi) {zi. dispose ();} else {for (var key in _ instances) {_ instances [Key]. dispose () ;}_ instances ={};} return zrender ;};/*** get zrender instance ** @ Param {string} ID zrender object index */zrender. getinstance = funct Ion (ID) {return _ instances [ID] ;};/*** Delete zrender instance, called when zrender instance dispose, * getinstance after deletion returns undefined * PS: only Delete the instance. The deleted instance does not represent that the instance has been dispose ~~ * This is a backdoor that gets rid of global zrender. Dispose () automatic destruction. * take care of yourself ~ ** @ Param {string} ID zrender object index */zrender. delinstance = function (ID) {Delete _ instances [ID]; return zrender ;};

The next step is the core zrender constructor. Here we can clearly see the structure of M (storage) V (painter) C (handler.

/*** Zrender interface class. All interfaces available for external use are here !! * Storage (M), painter (v), and handler (c) are private internal classes. External interfaces are invisible. * unified responses from non-Get interfaces support chain calls ~ ** @ Param {string} ID Unique Identifier * @ Param {htmlelement} Dom DOM object, which does not help you with document. getelementbyid ** @ return {zrender} zrender instance */function zrender (ID, DOM) {This. id = ID; this. ENV = require ('. /tool/ENV '); this. storage = new storage (); this. painter = new painter (DOM, this. storage); this. handler = new handler (DOM, this. storage, this. painter); // animation control this. animatingshapes = []; this. animation = new animation ({stage: {update: getanimationupdater (this)}); this. animation. start ();}

• Storage is only an add/addhover (Del, delhover) Add/addhover (MOD) query (get/itershape/getmaxzlevel) of the Shape image at the JS object level ), something more like a Data Structure
• Painter is responsible for real drawing operations. Here is a heavy part.
• 1. Creates and processes the canvas and its surrounding DOM elements.
• 2. Calls various shapes (predefined) for drawing.
• 3. provides basic operation methods, such as rendering, refresh, resize, and clear.
• Handler is responsible for event processing, solving basic browser compatibility issues, registering and forwarding events, and dragging

For other methods attached to zrender prototype, except for the animation part, all others are called storage, painter, and handler.

End

Limited capabilities, do your best. Next, analyze each small module in detail. You can also view the code that has been processed and annotated in more detail to my GitHub.

Zrender Source Code Analysis 1: Overall Structure