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
>
