One of the series of composition principle analysis, the design principle of composition

Preface ：

compose At present, it is more and more popular ,19 year

Its principle is far from complete in an article , So I'm going to make a series .

Today's first article , Let's talk about Compose Design principle , Talk in the most popular way .

One . Native XML Disadvantages of layout

speak compose Before principle , We can think about it first , Native XML What are the problems with the layout of ？

1. Performance issues .

Although than H5 The first kind is much better , But its own disadvantages also exist . I think the biggest problem is when nesting multiple layers , The computational complexity of the plot increases exponentially . So this leads to when our layout nesting levels are too many , You will find that there will be a jam in the refresh , Rendering efficiency is particularly low .

2. Loading problem .

Layout file XML Finally packed into APK When , Still XML In the form of . But the XML convert to ViewGroup In fact, it is in inflate perhaps setContentView When （ In fact, the second method is also called in the first way ）. And read XML Belong to IO operation , analysis XML become ViewGroup There is also a lot of logic , So this time-consuming is unavoidable . General page loading XML All the time 30ms about , This leads to startup Activity When , It will cost more 30ms Time for .

3. Cross platform issues .

The reason is relatively simple , If H5 You only need to develop one , Android /IOS/ Web pages can be used . But if the three terminals are developed separately , It takes three times as much work to develop .

Two . How to solve ：

I thought about this problem a long time ago , So I have also made some attempts in personal projects , Some works well , Others failed .

Solve performance problems

For the first performance problem mentioned above , I think the biggest problem is to ensure absolute safety , So there are too many useless calculations , And it's an exponential calculation . So I sometimes have some very complex layouts or layouts with many elements in my personal projects , Will try to return directly to the width and height , Instead of counting its children View The width and height of . Wait until the execution draw When , Calculate at one time , Each child View Calculate only once , Then use it directly canvas draw . The final effect is actually good , See my other article for details ：

Solve the loading problem ：

For the second loading problem above , My friend gave me a hint before , Insert customization when compiling and packaging gradle Mission , Convert the layout file to compiled class Package files . This is a simple implementation , The effect is actually very good . But the problem is that there will be a lot of customization View Also loaded xml file , So there are too many points to be compatible . and XML Replace with View after , The code at the call also needs to be modified , Then recompile , It will become very complicated . Of course , It works in theory , It's just a matter of complexity .

Solve cross platform problems ：

java It's actually cross platform , Then based on java In fact, Android can also achieve cross platform . At least cross platform for a certain function . and java The principle of cross platform is similar , Layout is responsible for logical calculation , Finally, just issue the drawing command to Native layer , Then forward it to the hardware side .

3、 ... and .Compose How to solve

I've seen it preliminarily compose Principle , I was stunned , Its design idea coincides with my optimization idea above . Of course , There must be differences .

Compose The calculation area in the middle is based on LayoutNode The way , Every view Corresponding to one LayoutNode. Simply speaking , Namely Compose Optimized for measurement , Each node will only calculate once , Efficiency is greatly improved .

The problem of loading does not exist , Because the layout itself is to use KT Written , So there is no problem of parsing .

Cross platform , As long as the virtual machine is supported, its parsing logic can be executed , Draw the final product hardware . The rendering carrier on Android is still canvas. in other words , In fact, on Android , Just write the layout in a different way , The final rendering method has not changed .