This will be great to android performance. Besides these algorithms you mentioned, I think another big issue is decouple 'view' to component. We always think there will be a 'view' correspond with a component/node, and implementations are depend on that all over the place. See view-related methods in 'WXComponent', these need tons of work. And this will be a big change to our core architecture.
But I like this idea after all, this will be huge improvement in most common scenes. On Wed, Apr 19, 2017 at 5:46 PM, 申远 <[email protected]> wrote: > The figure in the previous in case image download error. > > 在 2017年4月19日，17:26，申远 <[email protected]> 写道： > > As it is known to all that the view hierarchy in android should be reduce > as much as possible. The deeper the view hierarchy is, the worse the > android app performance . But the front-end engineer is often unaware of > the view hierarchy in weex until he/she asked android developer for help. > > I'd like to propose a mechanism for solving the above problem. > > The main problem of deep view hierarchy is that the implementation of view > is expensive and costs lost of CPU/Memory. The cost of a view is basically > linear to the length of view hierarchy. It is also unnecessary to create > view for some components, like <text> and <image> as they mostly draw > nothing but the objects Weex framework provides. There is no reason we > waste limited mobile resource to create view in such scenario. > > Suppose the following component structure is given, the view hierarchy > will be the same to the component hierarchy, where there is at least 10 > views(if there is no children in slider and no wrapper view for slider) and > the height of the tree is 5. > <屏幕快照 2017-04-19 16.59.09.png> > With Flatten mechanism enable, the view hierarchy will looks like below > with 2 views and the height of view tree is 3. Note, only rounded-rect is > marked as view, oval will be marked as a custom drawCommand. > <屏幕快照 2017-04-19 17.08.29.png> > > The above solution is faced with following issues. > 1. A deterministic algorithm is needed for telling whether a component > node will be transformed to view or drawCommand. > 2. "Promote to view" and "Downgrade to drawCommand" mechanisms are needed. > As one may add a gesture to Div D, in which case it is not a drawCommand > anymore and should be promoted to view. Also, one may remove gesture from a > view, in which case it should be downgrade to drawCommand. > 3. As the flatten mechanism is seamless to front-end developer and may > contains potential bugs, a "flatten mechanism enabled" flag should be put > in WxInstance and set to false default. I'd like to think flatten mechanism > as an experimental performance feature not a default behavior. > 4. The detail of deterministic algorithm and "Promote to view" and > "Downgrade to drawCommand" mechanisms is not clear yet. I just hope the big > picture is right, there may be flaws in the Flatten view solution as all > other experimental features are. > > I'd like to hear advice from other android/weex developer. > -- > > > Best regards, > > York Shen > > > -- sospartan Phone:13588488290 HangZhou
