在Activity 的 onCreate() 方法(貌似在onStart和onResume也一样)中, 调用 mScrollView.scrollTo(0, 100); 是无效
scrollTo() 是直接指定滚动条的位置, 但是由于这个动作不是单纯关于 ScrollView 而已, 还要根据 ScrollView 里面包含的View 的实际信息. 所以这动作必须在页面加载完成以后才能执行.
在Activity 初始化过程中, 要指定滚动条位置, 必须用下面的代码：
01.mScrollView.post(new Runnable() {
02.@Override
03.public void run() {
04.mScrollView.scrollTo(0, 1000);
05.}
06.});
post() 方法的说明:
Causes the Runnable to be added to the message queue. The runnable will be run on the user interface thread.
这段代码确确实实起到了作用, post() 方法是View 类就有的, 看来类似的问题不只 ScrollView 存在呢!
为了大概知道是什么原因, 我们从调试入手吧!
第一步, 先直接用 mScrollView.scrollTo(0, 1000); , 调试发现, activity 初始化过程中, scrollTo() 方法有被执行, 用F5, 内部执行了17 步.
第二步, 用post() 方法, 调试发现, activity 初始化过程中, post()执行, activity 初始化后, scrollTo() 方法才被执行, 用F5, 内部执行了25 步, 其中第18 步是 onScrollChanged(mScrollX, mScrollY, oldX, oldY);但是效果的出现是在消息循环后.
第三步, 在onTouchEvent方法中, 执行调用mScrollView.scrollTo(0, 100); scrollTo() 方法有被执行, 用F5, 调试, 内部步骤很多, 绝对超过25了, 后面没耐心数了. 效果是在哪里出现也不清楚了.
我看了ScrollView 的源代码
01./**
02. * mailto:%7B@inheritDoc}
03. *
04. * <p>This version also clamps the scrolling to the bounds of our child.
05. */
06.@Override
07.public void scrollTo(int x, int y) {
08.// we rely on the fact the View.scrollBy calls scrollTo.
09.if (getChildCount() > 0) {
10.View child = getChildAt(0);
11.x = clamp(x, getWidth() - mPaddingRight - mPaddingLeft, child.getWidth());
12.y = clamp(y, getHeight() - mPaddingBottom - mPaddingTop, child.getHeight());
13.if (x != mScrollX || y != mScrollY) {
14.super.scrollTo(x, y);
15.}
16.}
17.}
它的父类View
01.public void scrollTo(int x, int y) {
02.if (mScrollX != x || mScrollY != y) {
03.int oldX = mScrollX;
04.int oldY = mScrollY;
05.mScrollX = x;
06.mScrollY = y;
07.onScrollChanged(mScrollX, mScrollY, oldX, oldY);
08.if (!awakenScrollBars()) {
09.invalidate();
10.}
11.}
12.}
看来是 if (mScrollX != x || mScrollY != y) 这个判断语句有没有通过是关键所在. 这也间接说明了, 在Activity 没初始化完成, ScrollView 对象获取的一些信息是不准确的, 直接导致了scrollTo() 方法无效.
