Sent: Tuesday, 20 October, 2015 8:02 PM

这两天在做UI端的performance优化，昨天Ross发现在My Opportunity Application初始化的时候，会发出一个额外odata call去获取attachment数据:

但是这个odata call会返回一个空的response:

比较奇怪的是application的初始化并没有执行任何跟attachment相关的代码，唯一有可能的地方就是UI的定义，在初始化XML View的时候发出了odata请求：

把items的绑定从XML View移除，放到当用户真正点击attachment tab的时候再用javascript做绑定：

再测试，发现application初始化的时候返回空值的odata call不会出现了，但是在点击attachment tab的时候，发出了两次对attachment的请求：

其中第二条odata call就是之前初始化app时候发出的多余请求，说明框架内部对控件初次绑定的时候是需要请求数据的，于是debug了一下bindAggregation的实现:

在sap-ui-core.js中定义了一个私有的_bindAggregation方法:

在这个方法中，框架先从控件中获取Model，根据已经绑定到控件的Data Model的类型决定Binding的类型，如果不存在Model，则默认用ODataListBinding:

上面返回空值的odata call就是a调用initialize()这一句发出的，如果控件没有Model，这里的a就是一个ODataListBinding

再回过来看刚才还有一个odata call (network里面的第一条)，获取了attachment数据之后将数据set到控件的JSON Model里面：

于是将bind aggregation的逻辑移到这个odata call的回调里面做，这个时候控件已经绑定了JSON Model，所以determine出来的binding类型是JSONListBinding，就不会再发一次多余的odata call了。

总结：如果给UI5控件绑定数据的时候是自己写逻辑用JSON Model的，要注意一下控件初始化还没有数据的时候，有没有额外的odata call，造成不必要的开销。

查了一下UI5的API，好像没找到UI5控件支持绑定了OData 之后，数据延迟加载的属性……