iOS开发中,ScrollView放大后,子视图位置计算的数据分析

在做类似于网易新闻图集的项目时,遇到了ScrollView放大缩小过程中,图片可能窜到不理想位置的情况,通过将各个属性打印出来的方法对次进行简单的分析.

主视图为mainScroll,放大的是其子视图PhotoView.

在scrollViewDidZoom:(UIScrollView *)scrollView这个代理方法中,通过打印两个View的fram,bounds,contentSize属性观察位置变化

NSLog(@"mainScrollViewInfo
frame
%@
bounds
%@
contenSize
%@",NSStringFromCGRect(mainScrollView.frame),NSStringFromCGRect(mainScrollView.bounds),NSStringFromCGSize(mainScrollView.contentSize));

        NSLog(@"photoViewInfo
frame
%@
bounds
%@",NSStringFromCGRect(photoView.frame),NSStringFromCGRect(photoView.bounds));

放大倍数为1的打印结果:

mainScrollView的属性

frame

{{0, 0}, {320, 458}}

bounds

{{0, 0}, {320, 458}}

contenSize

{320, 240}

photoView的属性

{{0, 109}, {320, 240}}

bounds

{{0, 0}, {320, 240}}

放大倍数为2的属性 

mainScrollView的属性

frame

{{0, 0}, {320, 458}}

bounds

{{160, 22}, {320, 458}}

contenSize

{640, 480}

photoView的属性

{{0, 109}, {320, 240}}

bounds

{{0, 0}, {320, 240}}

由此可见,在scrollView的放大过程中,photoView的属性没有改变,而scrollView的bounce和contentSize一直在变化中,导致其center一直在变化.

当然phtoView的frame不变是因为在缩放过程中一直在对其位置进行计算并赋值

CGRect kBounds = mainScrollView.bounds;
        photoView.center = CGPointMake(kBounds.origin.x + kBounds.size.width/2, (kBounds.origin.y +kBounds.size.height)/2);

通过观察mainScrollView的bounds和contentSize的变化,我们可以得出结论:

在从1倍大小放大到2倍时,contentSize的横向扩展了320,其中向左向右各扩展了160(一半),而纵向扩展的22全部来自于上部.

读者可以理解为,在mainScrollView的缩放过程中,mainScrollView的容量尺寸大小变为原来的二倍,而当前屏幕上显示的这部分内容,是最初显示在屏幕上的那部分mainScrollView(已成为放大后mainScrollView的一部分),其位置是在横向上移动到放大后的mainScrollView的中间,纵向上移动到放大后mainScrollView的底部.

我的程序中需要将photoView始终保持在scrollView的中心,通过精确计算各个视图的各个属性,最终确定了photoView在缩放过程中的实时位置,也就是缩放过程中mainScrollView的center位置.

原创,转载请注明出处