HarrisonXi
HarrisonXi
@hong4cong 请重开issue提问，指向 @isaced
找个初始化VV的时间点，设置下`[VVConfig setAlwaysRefresh:YES];`，动态增量refresh的逻辑有点问题
已重现此问题，在排查中
和之前的研发沟通了一下，目前此 Layout 基本属于废弃状态。 最早的时候这个 Layout 是用来实现 Banner 的，所以要维持内部元素永驻内存（为了维持它滚出页面时的滚动 offset 状态），避免被重用导致各种问题。所以 pageScrollLayout 在添加元素时强制将内部元素的 reuseIdentifer 全部清空了，并且从来没有测试过 reloadLayout 之类的可能。 目前来看逻辑已经难以维护，有点接近上帝才知道的状态了……所以综合来说现在的建议： 1. 如果是做 banner 可以考虑实现一个带滚动的 element（组件），配合 container-oneColumn 使用。（我们自己目前是这么做的） 2. 对这个 Layout 整体取消重用方案，每次 reload 之前重新生成一次所有的...
可以尝试修复方案，注释掉我所注释的对应行： ``` - (void)addSubview:(UIView *)view { if (view && view.reuseIdentifier) { // view.reuseIdentifier = @""; [self.scrollView addSubview:view]; ``` 注：并未经过充分测试
是的，element + oneColumn。 主要是这种 Layout 在需求上存在设计难点（而不是实现难点）： 1. banner 如果重用，可能存在多次上报曝光问题。所以 banner 控件最好由用户自行控制。 2. 如果每次滚动到 PageLayout 处时它都回归原始状态，对 pageIndex != 0 的元素曝光量很不友好。但如果 Layout 本身需要维持 pageIndex 信息，违背了只进行“布局”的初衷。 比较难取舍。
@yoowei oneColumn应该不会出现类似情况，你可以另开一个问题说得更清楚点
额，不要慌，这是我在 demo 里偷懒了…… 这里就是计算高度的 protocol 方法，在这里返回根据模型计算得到的高度即可，Tangram 会通过这个借口取高度。
如果要根据image的高度来动态计算，的确会比较难受。 阿里CDN的图片地址都是带宽高比的，例如 [https://img.alicdn.com/tfs/TB1JIM.klfH8KJjy1XbXXbLdXXa-167-70.jpg](https://img.alicdn.com/tfs/TB1JIM.klfH8KJjy1XbXXbLdXXa-167-70.jpg) ，我们就可以根据 URL 里的宽高比来计算。 如果你们的图片是宽高比不固定，URL 还不带尺寸，建议方案： 1. 服务端下发图片的时候用模型下发，带上宽高比。 即 {imgUrl : "xxx"} => {img : {url : "xxx", width : 100, height : 100}} 2. 预加载图片获得宽高比。 3. 固定图片宽高比。