You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@weex.apache.org by 申远 <sh...@gmail.com> on 2017/04/19 09:26:50 UTC
Proposal of Flatten view for Weex Android
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.
[image: 屏幕快照 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.
[image: 屏幕快照 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
Re: Proposal of Flatten view for Weex Android
Posted by 申远 <sh...@gmail.com>.
View is not an evil nor angle, it is just complicated and costs CPU/Memory.
With the concept of view, the following feature is easy to implement.
Animation
Event(Including gesture)
Hardware Acceleration
Update a partial rect(the view) in the window
So the deterministic algorithm will promote a draw command to view if any of the above feature is used in weex component in the inital version of flatten mechanism. As time goes, there is a chance that simple event like click will be implemented in flatten mechanism. But for the initial version, the answer is NOT SUPPORTED.
> 在 2017年4月19日，17:54，Adam Feng <cx...@gmail.com> 写道：
>
> Good idea, I think "flatten mechanism as an experimental performance feature not a default behavior” is necessary. During the experiment period, you can add a flag or a config or an attribute to enable the optimization.
>
> Besides，what do you think about the events and animation system? Can the “flattened” components still respond to the event such as click and any other gestures? Can they still be animated ?
>
> I’m really curious about the magic mechanism and expect it can improve our performance and stability dramatically.
>
> Thanks.
> Adam Feng
>
> On 2017年4月19日 +0800 PM5:27, wrote:
>>
>> oval
Re: Proposal of Flatten view for Weex Android
Posted by Adam Feng <cx...@gmail.com>.
Good idea, I think "flatten mechanism as an experimental performance feature not a default behavior” is necessary. During the experiment period, you can add a flag or a config or an attribute to enable the optimization.
Besides，what do you think about the events and animation system? Can the “flattened” components still respond to the event such as click and any other gestures? Can they still be animated ?
I’m really curious about the magic mechanism and expect it can improve our performance and stability dramatically.
Thanks.
Adam Feng
On 2017年4月19日 +0800 PM5:27, wrote:
>
> oval
Re: Proposal of Flatten view for Weex Android
Posted by 申远 <sh...@gmail.com>.
Component can bind to a view or so called drawCommand in order to achieve flatten system. And there are several ways to do so
A FlatView class extends View and implements drawCommand. All components in flatten mechanism return subclass of FlatView. And there is two drawing types in FlatView(Android View/Flatten Mechanism)
A Virtual View is created and not mounted to Android View System. Components in flatten mechanism use that virtual view and an dependent drawCommand implementation.
A full refactor to components.
There may exists solution 4 or 5, I still need time to figure out which one is better.
> 在 2017年4月19日，18:08，sospartan <so...@gmail.com> 写道：
>
> 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, 申远 <shenyuancs@gmail.com <ma...@gmail.com>> wrote:
>
> The figure in the previous in case image download error.
>> 在 2017年4月19日，17:26，申远 <shenyuancs@gmail.com <ma...@gmail.com>> 写道：
>>
>> 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
Re: Proposal of Flatten view for Weex Android
Posted by sospartan <so...@gmail.com>.
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, 申远 <sh...@gmail.com> wrote:
> The figure in the previous in case image download error.
>
> 在 2017年4月19日，17:26，申远 <sh...@gmail.com> 写道：
>
> 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
Re: Proposal of Flatten view for Weex Android
Posted by 申远 <sh...@gmail.com>.
The figure in the previous in case image download error.
> 在 2017年4月19日，17:26，申远 <sh...@gmail.com> 写道：
>
> 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
>