Great idea！ We also had tried a demo like your scheme to improve the load
performance ；
But this scheme bring some problem ：
1. No js runtime ，better performance but Inflexible，can‘t do some script
operation at runtime；
2. the pre-render data maybe much larger than the js bundle；
Of course , this scheme would much suit for some static scene .
Other way，we are planning to do another better scheme to improve weex load
performance；
The main design scheme is as follows：
1. JS bundle = template + data + JS；
2. Render template first，that the native view will appear first on the
screen；
3. Rebind v-Dom with native-Dom after render;
This scheme may release at the 0.21 version in september.
Thank you !
龙泉 <284437...@qq.com> 于2018年6月28日周四 上午11:25写道：
> Frist, we observed that the cost to open weex pages were much larger than
> the cost to open native pages. Exeample, the cost to launch the Game Index
> Page on our app has been to 1200ms, on condition that we have preloaded
> JsBundle so that we have no network cost.
> In order to understand how the time comsumed, we trace the whole process
> to launch the weex page, we see that executed the JavaScript code on
> CreateInstance step cost most of the time, about 700-800ms. In view of the
> above problems, we will define a startup phase to ensure that no any
> long-running code excuted here.But it isn't the best choice, even though we
> support muti JsBundle, we will face that problem when business developed
> into certain stage. So we can have a better solution to solve it, we can
> preRender the page.
> But if we preRender the page completely, we can't use it on new page due
> to the context isolation on Android. Even more the memory cost and the main
> thread blocking are unacceptable. So we think of an incomplete solution to
> fix this problem.
> We will abstract out the ComponentProxy from Component, while prerender we
> create Component instead of Component, we record all messages the Component
> need,so we can restore the Component when the real render.
> It's no Component creatd so means that no View created, we only leave some
> record on memory, so it's low memory consumption. Even more, we don't need
> to operate View on prerender step means that we can prerender on subthread.
>
> At the same time we also assessed the project will encounter some problems.
> We know that JSC though the Actions operating the dom structure, so what
> we do is to reorganizing these Actions. We sort out some Actions easy to
> handle below:
> GraphicActionAddElement、GraphicActionAddEvent、
> GraphicActionAppendTreeCreateFinish、GraphicActionCreateBody、
> GraphicActionCreateFinish、GraphicActionMoveElement、
> GraphicActionRefreshFinish、GraphicActionRemoveElement、
> GraphicActionRemoveEvent、GraphicActionUpdateAttr、GraphicActionUpdateStyle
> And the Actions below need some modification:
> GraphicActionLayout、ActionGetComponentRect
> And the GraphicActionAnimation is difficult to deal with.
>
> This scheme is the hardest part about how to deal with AnimationAction, we
> hopes everyone's idea.
>
> Anymore, get the width and height of layout area in advance is also a
> problem, but actually we has known it so we can pass data.
>
> This is all ,thank you
>
--
Best Regards!
---------------------
Shihan Zheng (Weex project team member )
