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(Andr
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 dra
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 method
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
The figure in the previous in case image download error.
> 在 2017年4月19日，17:26，申远 写道：
>
> 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 of
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
