前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
圈层
工具
发布
首页
学习
活动
专区
圈层
工具
MCP广场
社区首页 >专栏 >Android视图状态及重绘流程分析,带你一步步深入了解View(三)

Android视图状态及重绘流程分析,带你一步步深入了解View(三)

作者头像
用户1158055
发布于 2018-01-05 09:20:44
发布于 2018-01-05 09:20:44
1.3K00
代码可运行
举报
文章被收录于专栏:郭霖郭霖
运行总次数:0
代码可运行

在前面一篇文章中,我带着大家一起从源码的层面上分析了视图的绘制流程,了解了视图绘制流程中onMeasure、onLayout、onDraw这三个最重要步骤的工作原理,那么今天我们将继续对View进行深入探究,学习一下视图状态以及重绘方面的知识。如果你还没有看过我前面一篇文章,可以先去阅读 Android视图绘制流程完全解析,带你一步步深入了解View(二) 。

相信大家在平时使用View的时候都会发现它是有状态的,比如说有一个按钮,普通状态下是一种效果,但是当手指按下的时候就会变成另外一种效果,这样才会给人产生一种点击了按钮的感觉。当然了,这种效果相信几乎所有的Android程序员都知道该如何实现,但是我们既然是深入了解View,那么自然也应该知道它背后的实现原理应该是什么样的,今天就让我们来一起探究一下吧。

一、视图状态

视图状态的种类非常多,一共有十几种类型,不过多数情况下我们只会使用到其中的几种,因此这里我们也就只去分析最常用的几种视图状态。

1. enabled

表示当前视图是否可用。可以调用setEnable()方法来改变视图的可用状态,传入true表示可用,传入false表示不可用。它们之间最大的区别在于,不可用的视图是无法响应onTouch事件的。

2. focused

表示当前视图是否获得到焦点。通常情况下有两种方法可以让视图获得焦点,即通过键盘的上下左右键切换视图,以及调用requestFocus()方法。而现在的Android手机几乎都没有键盘了,因此基本上只可以使用requestFocus()这个办法来让视图获得焦点了。而requestFocus()方法也不能保证一定可以让视图获得焦点,它会有一个布尔值的返回值,如果返回true说明获得焦点成功,返回false说明获得焦点失败。一般只有视图在focusable和focusable in touch mode同时成立的情况下才能成功获取焦点,比如说EditText。

3. window_focused

表示当前视图是否处于正在交互的窗口中,这个值由系统自动决定,应用程序不能进行改变。

4. selected

表示当前视图是否处于选中状态。一个界面当中可以有多个视图处于选中状态,调用setSelected()方法能够改变视图的选中状态,传入true表示选中,传入false表示未选中。

5. pressed

表示当前视图是否处于按下状态。可以调用setPressed()方法来对这一状态进行改变,传入true表示按下,传入false表示未按下。通常情况下这个状态都是由系统自动赋值的,但开发者也可以自己调用这个方法来进行改变。

我们可以在项目的drawable目录下创建一个selector文件,在这里配置每种状态下视图对应的背景图片。比如创建一个compose_bg.xml文件,在里面编写如下代码:

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
<selector xmlns:android="http://schemas.android.com/apk/res/android">

    <item android:drawable="@drawable/compose_pressed" android:state_pressed="true"></item>
    <item android:drawable="@drawable/compose_pressed" android:state_focused="true"></item>
    <item android:drawable="@drawable/compose_normal"></item>

</selector>

这段代码就表示,当视图处于正常状态的时候就显示compose_normal这张背景图,当视图获得到焦点或者被按下的时候就显示compose_pressed这张背景图。

创建好了这个selector文件后,我们就可以在布局或代码中使用它了,比如将它设置为某个按钮的背景图,如下所示:

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    android:orientation="vertical" >
    
	<Button 
	    android:id="@+id/compose"
	    android:layout_width="60dp"
	    android:layout_height="40dp"
	    android:layout_gravity="center_horizontal"
	    android:background="@drawable/compose_bg"
	    />
    
</LinearLayout>

现在运行一下程序,这个按钮在普通状态和按下状态的时候就会显示不同的背景图片,如下图所示:

这样我们就用一个非常简单的方法实现了按钮按下的效果,但是它的背景原理到底是怎样的呢?这就又要从源码的层次上进行分析了。

我们都知道,当手指按在视图上的时候,视图的状态就已经发生了变化,此时视图的pressed状态是true。每当视图的状态有发生改变的时候,就会回调View的drawableStateChanged()方法,代码如下所示:

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
protected void drawableStateChanged() {
    Drawable d = mBGDrawable;
    if (d != null && d.isStateful()) {
        d.setState(getDrawableState());
    }
}

在这里的第一步,首先是将mBGDrawable赋值给一个Drawable对象,那么这个mBGDrawable是什么呢?观察setBackgroundResource()方法中的代码,如下所示:

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
public void setBackgroundResource(int resid) {
    if (resid != 0 && resid == mBackgroundResource) {
        return;
    }
    Drawable d= null;
    if (resid != 0) {
        d = mResources.getDrawable(resid);
    }
    setBackgroundDrawable(d);
    mBackgroundResource = resid;
}

可以看到,在第7行调用了Resource的getDrawable()方法将resid转换成了一个Drawable对象,然后调用了setBackgroundDrawable()方法并将这个Drawable对象传入,在setBackgroundDrawable()方法中会将传入的Drawable对象赋值给mBGDrawable。

而我们在布局文件中通过android:background属性指定的selector文件,效果等同于调用setBackgroundResource()方法。也就是说drawableStateChanged()方法中的mBGDrawable对象其实就是我们指定的selector文件。

接下来在drawableStateChanged()方法的第4行调用了getDrawableState()方法来获取视图状态,代码如下所示:

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
public final int[] getDrawableState() {
    if ((mDrawableState != null) && ((mPrivateFlags & DRAWABLE_STATE_DIRTY) == 0)) {
        return mDrawableState;
    } else {
        mDrawableState = onCreateDrawableState(0);
        mPrivateFlags &= ~DRAWABLE_STATE_DIRTY;
        return mDrawableState;
    }
}

在这里首先会判断当前视图的状态是否发生了改变,如果没有改变就直接返回当前的视图状态,如果发生了改变就调用onCreateDrawableState()方法来获取最新的视图状态。视图的所有状态会以一个整型数组的形式返回。

在得到了视图状态的数组之后,就会调用Drawable的setState()方法来对状态进行更新,代码如下所示:

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
public boolean setState(final int[] stateSet) {
    if (!Arrays.equals(mStateSet, stateSet)) {
        mStateSet = stateSet;
        return onStateChange(stateSet);
    }
    return false;
}

这里会调用Arrays.equals()方法来判断视图状态的数组是否发生了变化,如果发生了变化则调用onStateChange()方法,否则就直接返回false。但你会发现,Drawable的onStateChange()方法中其实就只是简单返回了一个false,并没有任何的逻辑处理,这是为什么呢?这主要是因为mBGDrawable对象是通过一个selector文件创建出来的,而通过这种文件创建出来的Drawable对象其实都是一个StateListDrawable实例,因此这里调用的onStateChange()方法实际上调用的是StateListDrawable中的onStateChange()方法,那么我们赶快看一下吧:

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
@Override
protected boolean onStateChange(int[] stateSet) {
    int idx = mStateListState.indexOfStateSet(stateSet);
    if (DEBUG) android.util.Log.i(TAG, "onStateChange " + this + " states "
            + Arrays.toString(stateSet) + " found " + idx);
    if (idx < 0) {
        idx = mStateListState.indexOfStateSet(StateSet.WILD_CARD);
    }
    if (selectDrawable(idx)) {
        return true;
    }
    return super.onStateChange(stateSet);
}

可以看到,这里会先调用indexOfStateSet()方法来找到当前视图状态所对应的Drawable资源下标,然后在第9行调用selectDrawable()方法并将下标传入,在这个方法中就会将视图的背景图设置为当前视图状态所对应的那张图片了。

那你可能会有疑问,在前面一篇文章中我们说到,任何一个视图的显示都要经过非常科学的绘制流程的,很显然,背景图的绘制是在draw()方法中完成的,那么为什么selectDrawable()方法能够控制背景图的改变呢?这就要研究一下视图重绘的流程了。

二、视图重绘

虽然视图会在Activity加载完成之后自动绘制到屏幕上,但是我们完全有理由在与Activity进行交互的时候要求动态更新视图,比如改变视图的状态、以及显示或隐藏某个控件等。那在这个时候,之前绘制出的视图其实就已经过期了,此时我们就应该对视图进行重绘。

调用视图的setVisibility()、setEnabled()、setSelected()等方法时都会导致视图重绘,而如果我们想要手动地强制让视图进行重绘,可以调用invalidate()方法来实现。当然了,setVisibility()、setEnabled()、setSelected()等方法的内部其实也是通过调用invalidate()方法来实现的,那么就让我们来看一看invalidate()方法的代码是什么样的吧。

View的源码中会有数个invalidate()方法的重载和一个invalidateDrawable()方法,当然它们的原理都是相同的,因此我们只分析其中一种,代码如下所示:

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
void invalidate(boolean invalidateCache) {
    if (ViewDebug.TRACE_HIERARCHY) {
        ViewDebug.trace(this, ViewDebug.HierarchyTraceType.INVALIDATE);
    }
    if (skipInvalidate()) {
        return;
    }
    if ((mPrivateFlags & (DRAWN | HAS_BOUNDS)) == (DRAWN | HAS_BOUNDS) ||
            (invalidateCache && (mPrivateFlags & DRAWING_CACHE_VALID) == DRAWING_CACHE_VALID) ||
            (mPrivateFlags & INVALIDATED) != INVALIDATED || isOpaque() != mLastIsOpaque) {
        mLastIsOpaque = isOpaque();
        mPrivateFlags &= ~DRAWN;
        mPrivateFlags |= DIRTY;
        if (invalidateCache) {
            mPrivateFlags |= INVALIDATED;
            mPrivateFlags &= ~DRAWING_CACHE_VALID;
        }
        final AttachInfo ai = mAttachInfo;
        final ViewParent p = mParent;
        if (!HardwareRenderer.RENDER_DIRTY_REGIONS) {
            if (p != null && ai != null && ai.mHardwareAccelerated) {
                p.invalidateChild(this, null);
                return;
            }
        }
        if (p != null && ai != null) {
            final Rect r = ai.mTmpInvalRect;
            r.set(0, 0, mRight - mLeft, mBottom - mTop);
            p.invalidateChild(this, r);
        }
    }
}

在这个方法中首先会调用skipInvalidate()方法来判断当前View是否需要重绘,判断的逻辑也比较简单,如果View是不可见的且没有执行任何动画,就认为不需要重绘了。之后会进行透明度的判断,并给View添加一些标记位,然后在第22和29行调用ViewParent的invalidateChild()方法,这里的ViewParent其实就是当前视图的父视图,因此会调用到ViewGroup的invalidateChild()方法中,代码如下所示:

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
public final void invalidateChild(View child, final Rect dirty) {
    ViewParent parent = this;
    final AttachInfo attachInfo = mAttachInfo;
    if (attachInfo != null) {
        final boolean drawAnimation = (child.mPrivateFlags & DRAW_ANIMATION) == DRAW_ANIMATION;
        if (dirty == null) {
            ......
        } else {
            ......
            do {
                View view = null;
                if (parent instanceof View) {
                    view = (View) parent;
                    if (view.mLayerType != LAYER_TYPE_NONE &&
                            view.getParent() instanceof View) {
                        final View grandParent = (View) view.getParent();
                        grandParent.mPrivateFlags |= INVALIDATED;
                        grandParent.mPrivateFlags &= ~DRAWING_CACHE_VALID;
                    }
                }
                if (drawAnimation) {
                    if (view != null) {
                        view.mPrivateFlags |= DRAW_ANIMATION;
                    } else if (parent instanceof ViewRootImpl) {
                        ((ViewRootImpl) parent).mIsAnimating = true;
                    }
                }
                if (view != null) {
                    if ((view.mViewFlags & FADING_EDGE_MASK) != 0 &&
                            view.getSolidColor() == 0) {
                        opaqueFlag = DIRTY;
                    }
                    if ((view.mPrivateFlags & DIRTY_MASK) != DIRTY) {
                        view.mPrivateFlags = (view.mPrivateFlags & ~DIRTY_MASK) | opaqueFlag;
                    }
                }
                parent = parent.invalidateChildInParent(location, dirty);
                if (view != null) {
                    Matrix m = view.getMatrix();
                    if (!m.isIdentity()) {
                        RectF boundingRect = attachInfo.mTmpTransformRect;
                        boundingRect.set(dirty);
                        m.mapRect(boundingRect);
                        dirty.set((int) boundingRect.left, (int) boundingRect.top,
                                (int) (boundingRect.right + 0.5f),
                                (int) (boundingRect.bottom + 0.5f));
                    }
                }
            } while (parent != null);
        }
    }
}

可以看到,这里在第10行进入了一个while循环,当ViewParent不等于空的时候就会一直循环下去。在这个while循环当中会不断地获取当前布局的父布局,并调用它的invalidateChildInParent()方法,在ViewGroup的invalidateChildInParent()方法中主要是来计算需要重绘的矩形区域,这里我们先不管它,当循环到最外层的根布局后,就会调用ViewRoot的invalidateChildInParent()方法了,代码如下所示:

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
    public ViewParent invalidateChildInParent(final int[] location, final Rect dirty) {
        invalidateChild(null, dirty);
        return null;
    }

这里的代码非常简单,仅仅是去调用了invalidateChild()方法而已,那我们再跟进去瞧一瞧吧:

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
public void invalidateChild(View child, Rect dirty) {
    checkThread();
    if (LOCAL_LOGV) Log.v(TAG, "Invalidate child: " + dirty);
    mDirty.union(dirty);
    if (!mWillDrawSoon) {
        scheduleTraversals();
    }
}

这个方法也不长,它在第6行又调用了scheduleTraversals()这个方法,那么我们继续跟进:

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
public void scheduleTraversals() {
    if (!mTraversalScheduled) {
        mTraversalScheduled = true;
        sendEmptyMessage(DO_TRAVERSAL);
    }
}

可以看到,这里调用了sendEmptyMessage()方法,并传入了一个DO_TRAVERSAL参数。了解Android异步消息处理机制的朋友们都会知道,任何一个Handler都可以调用sendEmptyMessage()方法来发送消息,并且在handleMessage()方法中接收消息,而如果你看一下ViewRoot的类定义就会发现,它是继承自Handler的,也就是说这里调用sendEmptyMessage()方法出的消息,会在ViewRoot的handleMessage()方法中接收到。那么赶快看一下handleMessage()方法的代码吧,如下所示:

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
public void handleMessage(Message msg) {
    switch (msg.what) {
    case DO_TRAVERSAL:
        if (mProfile) {
            Debug.startMethodTracing("ViewRoot");
        }
        performTraversals();
        if (mProfile) {
            Debug.stopMethodTracing();
            mProfile = false;
        }
        break;
    ......
}

熟悉的代码出现了!这里在第7行调用了performTraversals()方法,这不就是我们在前面一篇文章中学到的视图绘制的入口吗?虽然经过了很多辗转的调用,但是可以确定的是,调用视图的invalidate()方法后确实会走到performTraversals()方法中,然后重新执行绘制流程。之后的流程就不需要再进行描述了吧,可以参考 Android视图绘制流程完全解析,带你一步步深入了解View(二) 这一篇文章。

了解了这些之后,我们再回过头来看看刚才的selectDrawable()方法中到底做了什么才能够控制背景图的改变,代码如下所示:

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
public boolean selectDrawable(int idx) {
    if (idx == mCurIndex) {
        return false;
    }
    final long now = SystemClock.uptimeMillis();
    if (mDrawableContainerState.mExitFadeDuration > 0) {
        if (mLastDrawable != null) {
            mLastDrawable.setVisible(false, false);
        }
        if (mCurrDrawable != null) {
            mLastDrawable = mCurrDrawable;
            mExitAnimationEnd = now + mDrawableContainerState.mExitFadeDuration;
        } else {
            mLastDrawable = null;
            mExitAnimationEnd = 0;
        }
    } else if (mCurrDrawable != null) {
        mCurrDrawable.setVisible(false, false);
    }
    if (idx >= 0 && idx < mDrawableContainerState.mNumChildren) {
        Drawable d = mDrawableContainerState.mDrawables[idx];
        mCurrDrawable = d;
        mCurIndex = idx;
        if (d != null) {
            if (mDrawableContainerState.mEnterFadeDuration > 0) {
                mEnterAnimationEnd = now + mDrawableContainerState.mEnterFadeDuration;
            } else {
                d.setAlpha(mAlpha);
            }
            d.setVisible(isVisible(), true);
            d.setDither(mDrawableContainerState.mDither);
            d.setColorFilter(mColorFilter);
            d.setState(getState());
            d.setLevel(getLevel());
            d.setBounds(getBounds());
        }
    } else {
        mCurrDrawable = null;
        mCurIndex = -1;
    }
    if (mEnterAnimationEnd != 0 || mExitAnimationEnd != 0) {
        if (mAnimationRunnable == null) {
            mAnimationRunnable = new Runnable() {
                @Override public void run() {
                    animate(true);
                    invalidateSelf();
                }
            };
        } else {
            unscheduleSelf(mAnimationRunnable);
        }
        animate(true);
    }
    invalidateSelf();
    return true;
}

这里前面的代码我们可以都不管,关键是要看到在第54行一定会调用invalidateSelf()方法,这个方法中的代码如下所示:

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
public void invalidateSelf() {
    final Callback callback = getCallback();
    if (callback != null) {
        callback.invalidateDrawable(this);
    }
}

可以看到,这里会先调用getCallback()方法获取Callback接口的回调实例,然后再去调用回调实例的invalidateDrawable()方法。那么这里的回调实例又是什么呢?观察一下View的类定义其实你就知道了,如下所示:

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
public class View implements Drawable.Callback, Drawable.Callback2, KeyEvent.Callback,
AccessibilityEventSource {
    ......
}

View类正是实现了Callback接口,所以刚才其实调用的就是View中的invalidateDrawable()方法,之后就会按照我们前面分析的流程执行重绘逻辑,所以视图的背景图才能够得到改变的。

另外需要注意的是,invalidate()方法虽然最终会调用到performTraversals()方法中,但这时measure和layout流程是不会重新执行的,因为视图没有强制重新测量的标志位,而且大小也没有发生过变化,所以这时只有draw流程可以得到执行。而如果你希望视图的绘制流程可以完完整整地重新走一遍,就不能使用invalidate()方法,而应该调用requestLayout()了。这个方法中的流程比invalidate()方法要简单一些,但中心思想是差不多的,这里也就不再详细进行分析了。

这样的话,我们就将视图状态以及重绘的工作原理都搞清楚了,相信大家对View的理解变得更加深刻了。感兴趣的朋友可以继续阅读 Android自定义View的实现方法,带你一步步深入了解View(四) 。

本文参与 腾讯云自媒体同步曝光计划,分享自作者个人站点/博客。
原始发表:2014-01-09 ,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 作者个人站点/博客 前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
暂无评论
推荐阅读
硅基光电子集成芯片(PIC)如何大规模生产?
 本文聚焦大规模硅基光电子集成芯片(SiPIC)的技术发展与挑战,指出其与集成电路发展趋势相似,但受光学衍射极限和材料限制,集成密度提升难度大。文中分析了设计制造全流程(如 MPW 模式、版图设计、工艺验证)、片上器件集成(IO 器件、波导、调制器等)及大规模生产挑战(电学 / 光学组件一致性、良率控制),并展望通过异质集成、先进封装、自动化设计工具等技术突破瓶颈,推动其在光通信、光子 AI、激光雷达等领域的规模化应用。
AIGC部落
2025/06/07
860
硅基光电子集成芯片(PIC)如何大规模生产?
OFC 2025预热(二):短距光互连的明星初创公司们
今天来看看OFC 2025上那些明星初创公司都介绍了哪些有意思的进展。主要介绍的公司之前都有陆续写过,包括Ayar labs,、Lightmatter、Celestial AI、OpenLight、Xscape、Lucidean等。Lightmatter和Celestial AI的验证结果展示感觉是脚步最快、最惊艳的(也体现到他们的融资上),Ayar Labs在瞄准大规模制造优化耦合封装方案,而Xscape、Lucidean公司也有了不俗的进展,Nubis展示了新的应用场景,奇点光子开始露面,Openlight平台在持续演进,昨天Tower新闻稿提到的400G/lane技术看会不会在会场有介绍。
光芯
2025/04/08
3230
OFC 2025预热(二):短距光互连的明星初创公司们
数据中心光开关(科普综述翻译)
翻译一篇关于数据中心光开关的综述,作者包括欧洲的剑桥大学、埃因霍温科技大学,日本AIST团队,美国哥伦比亚大学团队以及国内浙江大学团队等。
光芯
2025/04/08
910
数据中心光开关(科普综述翻译)
光交换系统与Flex-grid技术综述
(原文链接https://doi.org/10.1007/978-981-97-2282-2_39)
光芯
2025/04/08
1200
光交换系统与Flex-grid技术综述
IEDM 2024:台积电的硅光(高性能工艺平台、CPO、光计算) 进展(一)
台积电在IEDM 2024会议上有好多论文,其中硅光的也有好几篇,看了之后还是很震撼的。
光芯
2025/04/08
2870
IEDM 2024:台积电的硅光(高性能工艺平台、CPO、光计算) 进展(一)
GlobalFoundry的300mm硅光子工艺平台
这篇笔记主要参考GlobalFoudry(以下简称GF)最近发表的文章"300mm Monolithic Silicon Photonics Foundry Technology"(https://ieeexplore.ieee.org/document/8678809) ,介绍下GF的硅光子工艺平台。
光学小豆芽
2020/08/13
2.4K0
PsiQuantum的超高水平集成光平台
链接:https://youtube.com/watch?v=rR1hmp2pHkI
光芯
2025/04/08
970
PsiQuantum的超高水平集成光平台
OFC 2025 PDP:单波400G的III-V(NTT/华为)、铌酸锂(Hyperlight/住友)及硅光(Aloe)
OFC 2025 PDP又增添了好几个单波400G的验证结果,其中有华为的540 Gbps EML传光纤30km的报道(OFC 2025 PDP:华为的110 GHz带宽、540 Gbps EML+30km传纤实验)。除此之外,Hyperlight用Ciena的3nm 448Gbps Serdes完成了8×400G的3.2T 2km DR8和FR8实验;NTT也演示了8通道的无制冷高带宽的InP MZM的3.2T 500m传输;住友基于前两年做的集成电光均衡器的高带宽铌酸锂(封装后带宽>100GHz)演示了单波400Gbps 传输(不过是C波段的),PDP之外Coherent是发布了新闻稿会在OFC现场演示400 Gbps的差分EML。
光芯
2025/04/08
5100
OFC 2025 PDP:单波400G的III-V(NTT/华为)、铌酸锂(Hyperlight/住友)及硅光(Aloe)
OFC2022: Intel的硅光版图
今年的OFC会议上,Intel有多个报告,报道了其在硅光领域的核心器件进展以及未来的布局,小豆芽这里简单整理下,供大家参考。
光学小豆芽
2022/03/29
4.8K1
OFC2022: Intel的硅光版图
IMEC:可编程硅光子调制器实现强度与相位响应全局优化
◆引言 在集成光子系统中,电光调制器(E/O Modulator)是光通信、微波光子学、LiDAR等领域的核心器件,其性能直接决定了系统的带宽、线性度与动态范围。然而,传统调制器(如基于载流子耗尽的pn结调制器、微环调制器MRM、SiGe电吸收调制器EAM)受限于物理机制与工艺缺陷,往往在强度调制(IM)与相位调制(PM)之间难以兼顾,且存在非线性失真、插入损耗高、波长敏感性等问题。例如: - pn结调制器:相位调制伴随寄生强度调制(Spurious IM),导致信号失真; - MRM:高带宽但波长敏感,且响应为非线性Lorentzian曲线; - SiGe EAM:紧凑但调制效率低,消光比不足。 针对这些挑战,根特大学团队提出了一种电路级可编程调制器设计,通过将现有调制器嵌入可调谐马赫-曾德尔干涉仪(MZI)中,通过调整该MZI的静态传输响应,可以补偿嵌入式调制器电光响应中的缺陷,根据应用需求实现改进的调制响应曲线、更低的插入损耗、更高的调制效率或更高的无杂散动态范围。如果嵌入式调制器组件可以提供较大的相位调制,可编程调制器电路可以调整为作为强度调制器、相位调制器,或者两种调制方式的组合来工作。实验表明,该设计在SFDR(无杂散动态范围)、消光比、线性度等关键指标上均突破现有记录。
光芯
2025/04/08
1300
IMEC:可编程硅光子调制器实现强度与相位响应全局优化
光芯片的材料体系比较
我们在阅读各类光芯片的相关文章时,每个实验室都有自己的绝活,可以用自己所擅长的微加工手段制成光芯片,完成特定的功能。这篇笔记主要总结与比较下不同材料体系的优劣。
光学小豆芽
2020/08/13
4.3K1
OFC 2025:IBM开发应用于CPO的高密度聚合物波导光子模块
在服务器硬件中,计算单元的带宽每两年以约 3 倍的速度增长,而互连技术仅以 1.4 倍的速度发展,导致 “带宽鸿沟” 持续扩大。传统可插拔收发模块虽能扩展传输距离,但在高密度集成和功耗上存在局限。
光芯
2025/04/22
1280
OFC 2025:IBM开发应用于CPO的高密度聚合物波导光子模块
惠普实验室:大规模III-V/Si异质集成光子器件平台助力下一代光计算(二)
在人工智能和机器学习快速发展的背景下,构建高效的光子集成电路对于提升计算性能至关重要。传统的电子计算架构在处理大规模 AI 任务时面临着诸多挑战,如能耗高、计算速度受限等,而光子集成电路凭借其独特的优势成为解决这些问题的关键研究方向。 (一)张量化光神经网络(TONN) TONN 的出现源于对 AI 计算效率的追求,模型压缩技术中的修剪方法为其提供了灵感。在传统的光神经网络中,随着模型规模的扩大,计算资源的消耗呈指数级增长,严重限制了其应用范围。
光芯
2025/04/08
920
惠普实验室:大规模III-V/Si异质集成光子器件平台助力下一代光计算(二)
惠普实验室:大规模III-V/Si异质集成光子器件平台助力下一代光计算(一)
(原文链接:https://ieeexplore.ieee.org/document/10835188)
光芯
2025/04/08
1610
惠普实验室:大规模III-V/Si异质集成光子器件平台助力下一代光计算(一)
重磅!诺基亚完成欧洲800G光通信突破,引领光通信技术浪潮
诺基亚携手Zayo Europe完成欧洲首例800G超长距传输,创下千公里级光通信新纪录。
通信行业搬砖工
2025/04/13
1410
重磅!诺基亚完成欧洲800G光通信突破,引领光通信技术浪潮
Cornell Univ.:5.3Tb/s/mm², 120fJ/bit的3D集成高密硅光互联
Cornell大学的三位大佬Keren Bergman,Michal Lipson, Alexander Gaeta最近的公司Xscape photonics最近拿了个$44M的A轮融资,投资方有Nvidia和Cisco等。主要产品是基于双微环光频梳的波长数量可配置的多波长光源,用于数据中心和高性能计算的高速通信。主要想做的系统大概就是底下这个图所示,也是利用微环的波分特性,引进波长维度实现高带宽密度的光互联。今天先来看看Keren Bergman 2023年发表的关于高带宽密度、极低功耗的光互联芯片的工作。
光芯
2025/04/08
710
Cornell Univ.:5.3Tb/s/mm², 120fJ/bit的3D集成高密硅光互联
微腔光频梳在超宽带通信中的研究进展与技术突破
本文是Bill Corcoran, Arnan Mitchell, Roberto Morandotti, Leif K. Oxenløwe & David J. Moss等作者于2025年5月7日发表在《Nature Photonics》上的综述文章(https://www.nature.com/articles/s41566-025-01662-9),系统梳理了集成光学克尔微梳在超宽带光通信中的核心技术演进、多维应用场景及前沿挑战,揭示了其从实验室走向商业化的关键路径。
光芯
2025/05/08
1750
微腔光频梳在超宽带通信中的研究进展与技术突破
非互易+非易失磁光材料异质集成实现高性能光子存内计算
UCSB和东京工业大学的团队在NP上报道了利用非互易磁光效应材料与集成光波导器件的异质集成,实现高速(1GHz)、高效(143fJ/bit)、高可靠性(24亿次循环)的光子存内计算架构。
光芯
2025/04/08
1100
非互易+非易失磁光材料异质集成实现高性能光子存内计算
OpenLight & Tower:III-V on Si异质集成实现更高性能+更低成本
ECOC 2024上,Openlight介绍了自家的III-V-on-Silicon异质集成平台,在面向1.6T短距传输场景,他们提到基于异质集成的1.6T DR8和1.6T 2×FR4 PIC,相比传统的EML方案以及传统的硅光方案,成本和功耗都有非常显著的下降。
光芯
2025/04/08
1600
OpenLight & Tower:III-V on Si异质集成实现更高性能+更低成本
Intel的硅光子技术
上一篇笔记主要介绍了IBM的硅光封装方案 IBM的硅光封装方案。作为半导体行业的执牛首者,Intel经过十多年(2004年起)的硅光技术积累,已经在2016年发布了其硅光的产品,包括PSM4和CWDM4两种。这篇笔记主要整理下Intel公司的硅光子相关技术方案。
光学小豆芽
2020/08/13
4.4K0
推荐阅读
相关推荐
硅基光电子集成芯片(PIC)如何大规模生产?
更多 >
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档