深入排查 FLAG 导致的 Activity 无法正常启动

发表于 3年以前  | 总阅读数:337 次

深入源码排查 FLAG_ACTIVITY_NEW_TASK 导致的 Activity 无法正常启动

引言

众所周知 Android 中 Activity 有四种启动模式,决定了是否创建新的 Activity 实例或复用当前实例。但是实际上 Activity 的启动十分复杂,不单单是 android:launchMode 就能决定的,多个 Intent Flag 都能改变启动的行为模式,除此之外还会根据 android:taskAffinity 的值来判断对应任务栈是否存在。

基本 LaunchMode 行为模式

首先复习一下最基本的 LaunchMode 行为模式:

  • standard:默认值,每次启动都会创建一个新的 Activity 实例。
  • singleTop:如果待启动 Activity 处于栈顶则重用实例回调其 onNewIntent() 方法,否则新建实例。
  • singleTask:如果已有任务栈中存在该 Activity 实例,则将实例之上的其他 Activity 清空并回调实例的 onNewIntent() 方法,否则新建栈创建 Activity 实例。
  • singleInstance:在单独一个栈中创建,该栈不会再创建其他 Activity,当系统中存在实例时回调实例的 onNewIntent() 方法。

这是我们最熟知的启动模式,但是需要注意的是:上述行为模式仅限于未添加任何 Flag,并且没有改变 taskAffinity 的前提下。

Service 启动 Activity

如前所述,如果单纯的 Activity 启动 Activiy 且不添加任何 Flag 是没问题的,但是如果我们使用 Service 启动 Activity 就会遇到一个异常,在 Framework(本文 Framework 源码均来自 Android 11 版本)的源码中会抛出异常:

//android.app.ContextImpl
@Override
public void startActivity(Intent intent, Bundle options) {
    ……
    if ((intent.getFlags() & Intent.FLAG_ACTIVITY_NEW_TASK) == 0
            && (targetSdkVersion < Build.VERSION_CODES.N || targetSdkVersion >= Build.VERSION_CODES.P)
            && (options == null || ActivityOptions.fromBundle(options).getLaunchTaskId() == -1)) {
        throw new AndroidRuntimeException(
                "Calling startActivity() from outside of an Activity "
                        + " context requires the FLAG_ACTIVITY_NEW_TASK flag."
                        + " Is this really what you want?");
    }
    ……
}

所以在 Service 中启动 Activity 必须添加 FLAG_ACTIVITY_NEW_TASK,原因也很简单,每个 Activity 启动都需要一个任务栈,非 Activity 的 context 存在后台启动的可能,而此时前台是其他 App 的任务栈,甚至我们的 App 根本没有创建过任务栈,为了防止这些无法预料的情况出现,被强制要求添加这个 Flag。

standard 是四种启动模式中最简单也最常见的,其他三种各有各的流程,唯独 standard 直接简单粗暴创建一个新的实例放到栈顶。那么问题来了,是否所有的 standard 都能创建一个新的实例呢?

无法启动的 standard Activity

复现流程

将所有不影响异常的业务代码删除之后得到的最精简复现流程如下:

  1. Service 附加 FLAG_ACTIVITY_NEW_TASK 启动 A_Activity:
  startActivity(Intent(this, AActivity::class.java).apply { addFlags(Intent.FLAG_ACTIVITY_NEW_TASK) })
  1. A_Activity 启动 B_Activity:
  startActivity(Intent(this, BActivity::class.java))
  1. Service 附加 FLAG_ACTIVITY_NEW_TASK 启动 A_Activity:
  startActivity(Intent(this, AActivity::class.java).apply { addFlags(Intent.FLAG_ACTIVITY_NEW_TASK) })

会发现 A_Activity 无法被启动,A_Activity 和 B_Activity 均未回调 onCreateonResume 或者 onNewIntent 等生命周期函数,也没有任何 Crash 或者 ANR 的日志发生,点击 B_Activity 可以正常操作。

原因推测

首先排除 Service 的 Context 的原因,因为我们可以构造如下流程,实验会发现 A_Activity 依然无法启动:

  1. MainActivity 中先 finish 后附加 FLAG_ACTIVITY_NEW_TASK 启动 A_Activity:
  finish()
startActivity(Intent(this, AActivity::class.java).apply { addFlags(Intent.FLAG_ACTIVITY_NEW_TASK) })
  1. A_Activity 启动 B_Activity:
  startActivity(Intent(this, BActivity::class.java))
  1. B_Activity 附加 FLAG_ACTIVITY_NEW_TASK 启动 A_Activity:
  startActivity(Intent(this, AActivity::class.java).apply { addFlags(Intent.FLAG_ACTIVITY_NEW_TASK) })

那么从使用排除法得到 FLAG_ACTIVITY_NEW_TASK 有可能是原因了。另外细心观察上面的步骤,会发现第一步先 finishstartActivity,如果去掉 finish 做实验会发现其实可以成功启动 A_Activity,那么另一个原因应该就是 finish 了。

源码追踪

startActivityInner

Framework 的 Activity 启动源码非常繁杂,但是真正对 Activity 栈进行操作的函数是 ActivityStarter#startActivityInner,所以我们将着重分析这个方法。

//com.android.server.wm.ActivityStarter
int startActivityInner(final ActivityRecord r, ActivityRecord sourceRecord,
        IVoiceInteractionSession voiceSession, IVoiceInteractor voiceInteractor,
        int startFlags, boolean doResume, ActivityOptions options, Task inTask,
        boolean restrictedBgActivity, NeededUriGrants intentGrants) {
    setInitialState(r, options, inTask, doResume, startFlags, sourceRecord, voiceSession,
            voiceInteractor, restrictedBgActivity);

    // 计算 Activity 的启动 Flag
    computeLaunchingTaskFlags();
    ……
    // 确定是否将新 Activity 插入现有任务栈中,如果是则返回对应的 ActivityRecord,否则返回 null
    final Task reusedTask = getReusableTask();
    ……
    // 计算是否存在可用的任务栈
    final Task targetTask = reusedTask != null ? reusedTask : computeTargetTask();
    final boolean newTask = targetTask == null;
    mTargetTask = targetTask;

    computeLaunchParams(r, sourceRecord, targetTask);

    // 检查是否允许在给定任务栈或者新栈上启动 Activity
    int startResult = isAllowedToStart(r, newTask, targetTask);
    if (startResult != START_SUCCESS) {
        return startResult;
    }

    final ActivityRecord targetTaskTop = newTask ? null : targetTask.getTopNonFinishingActivity();
    if (targetTaskTop != null) {
        // 为了这次启动回收目标任务栈
        startResult = recycleTask(targetTask, targetTaskTop, reusedTask, intentGrants);
        if (startResult != START_SUCCESS) {
            return startResult;
        }
    } else {
        mAddingToTask = true;
    }
    ……
}

由于 startActivityInner 方法依然比较长,所以将只看几个可能产生影响的地方,对任务栈有影响的关键方法是 getReusableTaskrecycleTask

getReusableTask

首先先看看 getReusableTask 的源码:

//com.android.server.wm.ActivityStarter
private Task getReusableTask() {
    // 新 Activity 放到现有任务栈中的条件:
    // 1. Flags 包含 FLAG_ACTIVITY_NEW_TASK 但是不包含 FLAG_ACTIVITY_MULTIPLE_TASK
    // 2. launchMode 是 singleInstance 或 singleTask
    boolean putIntoExistingTask = ((mLaunchFlags & FLAG_ACTIVITY_NEW_TASK) != 0 &&
            (mLaunchFlags & FLAG_ACTIVITY_MULTIPLE_TASK) == 0)
            || isLaunchModeOneOf(LAUNCH_SINGLE_INSTANCE, LAUNCH_SINGLE_TASK);
    putIntoExistingTask &= mInTask == null && mStartActivity.resultTo == null;
    ActivityRecord intentActivity = null;
    if (putIntoExistingTask) {
        if (LAUNCH_SINGLE_INSTANCE == mLaunchMode) {
            // singleInstance 相关
            intentActivity = mRootWindowContainer.findActivity(mIntent, mStartActivity.info,
                    mStartActivity.isActivityTypeHome());
        } else if ((mLaunchFlags & FLAG_ACTIVITY_LAUNCH_ADJACENT) != 0) {
            // 分屏相关
            intentActivity = mRootWindowContainer.findActivity(mIntent, mStartActivity.info,
                    !(LAUNCH_SINGLE_TASK == mLaunchMode));
        } else {
            // 除上述情况之外的情况寻找最合适的任务栈
            intentActivity =
                    mRootWindowContainer.findTask(mStartActivity, mPreferredTaskDisplayArea);
        }
    }
    ……
    return intentActivity != null ? intentActivity.getTask() : null;
}

根据上述源码,由于我们的 Flags 中包含 FLAG_ACTIVITY_NEW_TASK 但是不包含 FLAG_ACTIVITY_MULTIPLE_TASK,所以会从现有的任务栈中寻找一个最合适的任务栈并将待启动的 Activity 插入其中,在我们举的例子中,会获取到 B_Activity 所在的任务栈。

recycleTask

接着来看看 recycleTask 的源码:

//com.android.server.wm.ActivityStarter
int recycleTask(Task targetTask, ActivityRecord targetTaskTop, Task reusedTask,
        NeededUriGrants intentGrants) {
    // 不同用户下不回收任务栈,直接启动 Activity 并添加到任务栈中
    if (targetTask.mUserId != mStartActivity.mUserId) {
        mTargetStack = targetTask.getStack();
        mAddingToTask = true;
        // 第一处 return
        return START_SUCCESS;
    }
    ……
    setTargetStackIfNeeded(targetTaskTop);
    ……
    // START_FLAG_ONLY_IF_NEEDED 表示启动和被启动者是同一个
    if ((mStartFlags & START_FLAG_ONLY_IF_NEEDED) != 0) {
        if (!mMovedToFront && mDoResume) {
            ……
            mTargetStack.moveToFront("intentActivityFound");
        }
        resumeTargetStackIfNeeded();
        // 第二处 return
        return START_RETURN_INTENT_TO_CALLER;
    }

    complyActivityFlags(targetTask,
            reusedTask != null ? reusedTask.getTopNonFinishingActivity() : null, intentGrants);
    ……
    if (mAddingToTask) {
        // 第三处 return
        return START_SUCCESS;
    }
    ……
    resumeTargetStackIfNeeded();
    mLastStartActivityRecord =
            targetTaskTop.finishing ? targetTask.getTopNonFinishingActivity() : targetTaskTop;
    // 第四处 return
    return mMovedToFront ? START_TASK_TO_FRONT : START_DELIVERED_TO_TOP;
}

根据单步调试,我们可以知道 recycleTask 返回的结果是 START_DELIVERED_TO_TOP,在 startActivityInnerrecycleTask 部分的相关代码是:

//com.android.server.wm.ActivityStarter#startActivityInner
startResult = recycleTask(targetTask, targetTaskTop, reusedTask, intentGrants);
if (startResult != START_SUCCESS) {
    return startResult;
}

即根本没有运行 startActivityInner 后半部分代码,启动失败原因就在于此,因此不再逐一解析 recycleTask,而是着眼于为何没有返回 START_SUCCESS,可以逐一寻找 recycleTask 中所有 return 的地方:

  1. 同一用户环境下,因此不会返回 START_SUCCESS
  2. START_FLAG_ONLY_IF_NEEDED 表示启动和被启动者是同一个 Activity,因此不会返回 START_RETURN_INTENT_TO_CALLER
  3. 根据 mAddingToTask 是否为 true 来确定是否返回 START_SUCCESS,关联方法是 complyActivityFlags,此处需要分析一下为何 mAddingToTaskfalse
  4. 根据 mMovedToFront 判断返回为 START_TASK_TO_FRONT 还是 START_DELIVERED_TO_TOP,关联的方法是 setTargetStackIfNeeded,由于上一步已经断绝了返回 START_SUCCESS 的可能,无法正常创建一个 Activity 实例了,就不再分析此方法。

complyActivityFlags

//com.android.server.wm.ActivityStarter
private void complyActivityFlags(Task targetTask, ActivityRecord reusedActivity,
        NeededUriGrants intentGrants) {
    ActivityRecord targetTaskTop = targetTask.getTopNonFinishingActivity();
    final boolean resetTask =
            reusedActivity != null && (mLaunchFlags & FLAG_ACTIVITY_RESET_TASK_IF_NEEDED) != 0;
    if (resetTask) {
        targetTaskTop = mTargetStack.resetTaskIfNeeded(targetTaskTop, mStartActivity);
    }

    if ((mLaunchFlags & (FLAG_ACTIVITY_NEW_TASK | FLAG_ACTIVITY_CLEAR_TASK))
            == (FLAG_ACTIVITY_NEW_TASK | FLAG_ACTIVITY_CLEAR_TASK)) {
        // 如果设置了 FLAG_ACTIVITY_NEW_TASK 和 FLAG_ACTIVITY_CLEAR_TASK
        // 清除目标任务栈上所有的 Activity,并将待启动 Activity 的 intent 信息设置给目标任务栈
        targetTask.performClearTaskLocked();
        targetTask.setIntent(mStartActivity);
        mAddingToTask = true;
    } else if ((mLaunchFlags & FLAG_ACTIVITY_CLEAR_TOP) != 0
            || isDocumentLaunchesIntoExisting(mLaunchFlags)
            || isLaunchModeOneOf(LAUNCH_SINGLE_INSTANCE, LAUNCH_SINGLE_TASK)) {
        // 如果设置了 FLAG_ACTIVITY_CLEAR_TOP;文档模式;launchMode 是 singleInstance 或 singleTask
        // 清除待启动 Activity 在任务栈之上的所有 Activity
        final ActivityRecord top = targetTask.performClearTaskForReuseLocked(mStartActivity,
                mLaunchFlags);

        if (targetTaskTop.getTask() == null) {
            targetTask.addChild(targetTaskTop);
        }

        if (top != null) {
            if (top.isRootOfTask()) {
                top.getTask().setIntent(mStartActivity);
            }
            deliverNewIntent(top, intentGrants);
        } else {
            mAddingToTask = true;
            if (targetTask.getStack() == null) {
                mTargetStack =
                        getLaunchStack(mStartActivity, mLaunchFlags, null /* task */, mOptions);
                mTargetStack.addChild(targetTask, !mLaunchTaskBehind /* toTop */,
                        (mStartActivity.info.flags & FLAG_SHOW_FOR_ALL_USERS) != 0);
            }
        }
    } else if ((mLaunchFlags & FLAG_ACTIVITY_CLEAR_TOP) == 0 && !mAddingToTask
            && (mLaunchFlags & FLAG_ACTIVITY_REORDER_TO_FRONT) != 0) {
        // 如果设置了 FLAG_ACTIVITY_REORDER_TO_FRONT、没有设置 FLAG_ACTIVITY_CLEAR_TOP 且待启动 Activity 已经在运行中
        // 将待启动 Activity 提到栈顶并回调 onNewIntent
        final ActivityRecord act =
                targetTask.findActivityInHistory(mStartActivity.mActivityComponent);
        if (act != null) {
            final Task task = act.getTask();
            task.moveActivityToFrontLocked(act);
            act.updateOptionsLocked(mOptions);
            deliverNewIntent(act, intentGrants);
            mTargetStack.mLastPausedActivity = null;
        } else {
            mAddingToTask = true;
        }
    } else if (mStartActivity.mActivityComponent.equals(targetTask.realActivity)) {
        // 待启动 Activity 的完整组件名如果和目标栈启动栈的 Activity 相同
        if (targetTask == mInTask) {
            // 目标任务栈和指定任务栈相同
            // 不新建 Activity 实例
        } else if (((mLaunchFlags & FLAG_ACTIVITY_SINGLE_TOP) != 0
                        || LAUNCH_SINGLE_TOP == mLaunchMode)
                && targetTaskTop.mActivityComponent.equals(mStartActivity.mActivityComponent)
                && mStartActivity.resultTo == null) {
            // singleTop 模式下
            // 回调 onNewIntent
            if (targetTaskTop.isRootOfTask()) {
                targetTaskTop.getTask().setIntent(mStartActivity);
            }
            deliverNewIntent(targetTaskTop, intentGrants);
        } else if (!targetTask.isSameIntentFilter(mStartActivity)) {
            // 目标任务栈和待启动 Activity 的 Intent Filter 不同
            // 新建 Activity 实例
            mAddingToTask = true;
        } else if (reusedActivity == null) {
            // 没用复用的 Activity
            // 新建 Activity 实例
            mAddingToTask = true;
        }
    } else if (!resetTask) {
        // 一般从快捷图标或通知中启动
        // 需要添加新的 Activity 到 Task 最上面
        mAddingToTask = true;
    } else if (!targetTask.rootWasReset) {
        // 希望把待启动 Activity 放到目标任务栈底部,但是现在的代码结构做不到,只把待启动 Activity 的 Intent 设置给目标任务栈
        targetTask.setIntent(mStartActivity);
    }
}

当我们单步调试进 complyActivityFlags 会发现,只设置了 FLAG_ACTIVITY_NEW_TASK,没有设置 FLAG_ACTIVITY_CLEAR_TASKFLAG_ACTIVITY_CLEAR_TOPFLAG_ACTIVITY_REORDER_TO_FRONT;启动模式是 standard;虽然待启动 Activity 的完整组件名如果和目标栈启动栈的 Activity 相同,但是却又不符合下面的所有判断;虽然可以进入 !resetTask 的分支却被上一个分支截胡……总之完美避过了所有能正常启动的 case。

resumeTopActivityInnerLocked

那么不能创建新的 Activity 实例会发生什么呢,这就需要关注 recycleTask 中的一个方法:resumeTargetStackIfNeeded,位于 complyActivityFlags 之后,用于将目标返回栈栈顶的 Activity 回调 onResume 方法,即虽然没有启动 A_Activity,但是把 B_Activity 给重新可见了。由于调用链路过长不多分析,但是层层调用后有一点需要关注,在 ActivityStack#resumeTopActivityInnerLocked 中:

//com.android.server.wm.ActivityStack#resumeTopActivityInnerLocked
if (mResumedActivity == next && next.isState(RESUMED)
        && taskDisplayArea.allResumedActivitiesComplete()) {
    executeAppTransition(options);
    if (DEBUG_STATES) Slog.d(TAG_STATES,
            "resumeTopActivityLocked: Top activity resumed " + next);
    return false;
}

B_Activity 本身就是 RESUMED 状态,所以会进入这个分支,不再继续 resumeTopActivityInnerLocked 后面的回调 onResume 逻辑直接返回。这就解释了为何 B_Activity 没有生命周期变化。

原因总结

我们原因推测时猜想 FLAG_ACTIVITY_NEW_TASK 可以得到证实,那么猜想 MainActivity 的 finish 是在哪里造成影响的呢?其实是 complyActivityFlags 的分支顺序,如果不 finish,目标任务栈启动栈的 Activity 是 MainActivity,跟 A_Activity 不同名,所以会进入 !resetTask 分支,但是如果 finish 掉 MainActivity,目标任务栈启动栈的 Activity 就是第一次启动的 A_Activity,会被截胡而无法进入 !resetTask 分支。

简单总结一下就是因为启动 Flag,启动模式,现有栈的情况种种机缘巧合,让分支逐一落空导致没有任何 Activity 被启动,既不会回调 onNewIntent 也不会新建一个 Activity 实例。原本会将目标返回栈栈顶的 Activity(即 B_Activity)重新 resume,但是巧合的是 B_Activity 本来就是 RESUMED 状态,所以也就不会回调 B_Activity 的 onResume。种种巧合之下的结果就是看上去什么都没有发生,新启动的 Activity 没有启动,上一个 Activity 的生命周期也不会发生变化。

解决办法

梳理清楚了流程解决方案就很简单了,很多地方都有能打破这种奇葩 case 的可能,让 startActivityInner 正常进行后面的逻辑处理,仅列举几个简单的方法,根据自身的业务自行处理:

  • 使得 getReusableTaskputIntoExistingTaskfalse:比如设置第二次启动 A_Activity 的 Flag 为 FLAG_ACTIVITY_NEW_TASK | FLAG_ACTIVITY_MULTIPLE_TASK;或者如果在允许的条件下(比如不是复现流程时的 Service 中启动),直接去掉 FLAG_ACTIVITY_NEW_TASK 即可。
  • 只要让 complyActivityFlags 能进入 mAddingToTasktrue 的 case ,这里分支非常多,所以方案也更多:比如设置第二次启动 A_Activity 的 Flag 为 FLAG_ACTIVITY_NEW_TASK | FLAG_ACTIVITY_CLEAR_TASK;或者就像前面分析 finish 的影响,注意栈的情况不要使得启动栈的 Activity 和待启动的 Activity 相同。

再现异常

复现流程

根据我们的业务需求,我们选择的方案如下:

  1. Service 附加 FLAG_ACTIVITY_NEW_TASK | FLAG_ACTIVITY_CLEAR_TASK 启动 A_Activity,A_Activity 的 launchMode 为 singleInstance
  startActivity(Intent(this, AActivity::class.java).apply { addFlags(Intent.FLAG_ACTIVITY_NEW_TASK or Intent.FLAG_ACTIVITY_CLEAR_TASK) })
  1. A_Activity 启动 B_Activity:
  finish()//注:此处 finish 和异常无关,仅为业务需求,即使去掉也会发生异常
startActivity(Intent(this, BActivity::class.java))
  1. 同步骤 1 启动 A_Activity。
  2. 同步骤 2 启动 B_Activity。

此时会出现 B_Activity 没有新建实例,而是会回调 onRestart 启动了第一次创建的 B_Activity。

源码追踪

根据上面的分析我们轻车熟路了,这又是某些 case 下没有创建 B_Activity 的实例而直接回调的 onResume 导致的。但是之前无法启动 A_Activity 是因为添加了 FLAG_ACTIVITY_NEW_TASK,然而现在启动 B_Activity 可什么 Flag 都没加,就是最简单的 startActivity,B_Activity的 launchMode 也是最基本的 standard

其实原因依然隐藏在源码中,startActivityInner 会调用 computeLaunchingTaskFlags 来计算启动时的 Flag:

private void computeLaunchingTaskFlags() {
    ……
    if (mInTask == null) {
        if (mSourceRecord == null) {
            if ((mLaunchFlags & FLAG_ACTIVITY_NEW_TASK) == 0 && mInTask == null) {
                Slog.w(TAG, "startActivity called from non-Activity context; forcing " +
                        "Intent.FLAG_ACTIVITY_NEW_TASK for: " + mIntent);
                mLaunchFlags |= FLAG_ACTIVITY_NEW_TASK;
            }
        } else if (mSourceRecord.launchMode == LAUNCH_SINGLE_INSTANCE) {
            mLaunchFlags |= FLAG_ACTIVITY_NEW_TASK;
        } else if (isLaunchModeOneOf(LAUNCH_SINGLE_INSTANCE, LAUNCH_SINGLE_TASK)) {
            mLaunchFlags |= FLAG_ACTIVITY_NEW_TASK;
        }
    }
}

在不指定启动栈时,三种情况下系统会默认给 Flag 加上 FLAG_ACTIVITY_NEW_TASK:

  1. 没有源 Activity(比如A启动B,则A为源 Activity)
  2. 源 Activity 的 launchMode 是 singleInstance
  3. 待启动 Activity 的 launchMode 是 singleInstancesingleTask

原因就显而易见了,我们的 A_Activity 的 launchMode 是singleInstance,所以系统给 Flag 加上了 FLAG_ACTIVITY_NEW_TASK,于是又回到了之前分析的场景中。

解决办法

解决办法上一个场景中也给出了,启动 B_Activity 时加上 FLAG_ACTIVITY_MULTIPLE_TASK即可:

finish()//注:此处 finish 和异常无关,仅为业务需求
startActivity(
    Intent(this, BActivity::class.java)
        .apply { addFlags(Intent.FLAG_ACTIVITY_MULTIPLE_TASK) })

总结

Activity 启动这块是非常复杂的,影响的因素也非常多,上面的两个场景还是属于比较简单的,仅仅是 FLAG_ACTIVITY_NEW_TASK 就造成了这么多的问题,而且看起都非常诡异难以排查,更不用说各种启动模式和 Flag 叠加时可能会遇到更多的坑点,不过一旦遇到了这些神坑,其实深入源码去研究有时候反而能更快得到结论。

本文由哈喽比特于3年以前收录,如有侵权请联系我们。
文章来源:https://mp.weixin.qq.com/s/uwIcmz-LfhzbSseeGnW_Vw

 相关推荐

刘强东夫妇:“移民美国”传言被驳斥

京东创始人刘强东和其妻子章泽天最近成为了互联网舆论关注的焦点。有关他们“移民美国”和在美国购买豪宅的传言在互联网上广泛传播。然而,京东官方通过微博发言人发布的消息澄清了这些传言,称这些言论纯属虚假信息和蓄意捏造。

发布于:1年以前  |  808次阅读  |  详细内容 »

博主曝三大运营商,将集体采购百万台华为Mate60系列

日前,据博主“@超能数码君老周”爆料,国内三大运营商中国移动、中国电信和中国联通预计将集体采购百万台规模的华为Mate60系列手机。

发布于:1年以前  |  770次阅读  |  详细内容 »

ASML CEO警告:出口管制不是可行做法,不要“逼迫中国大陆创新”

据报道,荷兰半导体设备公司ASML正看到美国对华遏制政策的负面影响。阿斯麦(ASML)CEO彼得·温宁克在一档电视节目中分享了他对中国大陆问题以及该公司面临的出口管制和保护主义的看法。彼得曾在多个场合表达了他对出口管制以及中荷经济关系的担忧。

发布于:1年以前  |  756次阅读  |  详细内容 »

抖音中长视频App青桃更名抖音精选,字节再发力对抗B站

今年早些时候,抖音悄然上线了一款名为“青桃”的 App,Slogan 为“看见你的热爱”,根据应用介绍可知,“青桃”是一个属于年轻人的兴趣知识视频平台,由抖音官方出品的中长视频关联版本,整体风格有些类似B站。

发布于:1年以前  |  648次阅读  |  详细内容 »

威马CDO:中国每百户家庭仅17户有车

日前,威马汽车首席数据官梅松林转发了一份“世界各国地区拥车率排行榜”,同时,他发文表示:中国汽车普及率低于非洲国家尼日利亚,每百户家庭仅17户有车。意大利世界排名第一,每十户中九户有车。

发布于:1年以前  |  589次阅读  |  详细内容 »

研究发现维生素 C 等抗氧化剂会刺激癌症生长和转移

近日,一项新的研究发现,维生素 C 和 E 等抗氧化剂会激活一种机制,刺激癌症肿瘤中新血管的生长,帮助它们生长和扩散。

发布于:1年以前  |  449次阅读  |  详细内容 »

苹果据称正引入3D打印技术,用以生产智能手表的钢质底盘

据媒体援引消息人士报道,苹果公司正在测试使用3D打印技术来生产其智能手表的钢质底盘。消息传出后,3D系统一度大涨超10%,不过截至周三收盘,该股涨幅回落至2%以内。

发布于:1年以前  |  446次阅读  |  详细内容 »

千万级抖音网红秀才账号被封禁

9月2日,坐拥千万粉丝的网红主播“秀才”账号被封禁,在社交媒体平台上引发热议。平台相关负责人表示,“秀才”账号违反平台相关规定,已封禁。据知情人士透露,秀才近期被举报存在违法行为,这可能是他被封禁的部分原因。据悉,“秀才”年龄39岁,是安徽省亳州市蒙城县人,抖音网红,粉丝数量超1200万。他曾被称为“中老年...

发布于:1年以前  |  445次阅读  |  详细内容 »

亚马逊股东起诉公司和贝索斯,称其在购买卫星发射服务时忽视了 SpaceX

9月3日消息,亚马逊的一些股东,包括持有该公司股票的一家养老基金,日前对亚马逊、其创始人贝索斯和其董事会提起诉讼,指控他们在为 Project Kuiper 卫星星座项目购买发射服务时“违反了信义义务”。

发布于:1年以前  |  444次阅读  |  详细内容 »

苹果上线AppsbyApple网站,以推广自家应用程序

据消息,为推广自家应用,苹果现推出了一个名为“Apps by Apple”的网站,展示了苹果为旗下产品(如 iPhone、iPad、Apple Watch、Mac 和 Apple TV)开发的各种应用程序。

发布于:1年以前  |  442次阅读  |  详细内容 »

特斯拉美国降价引发投资者不满:“这是短期麻醉剂”

特斯拉本周在美国大幅下调Model S和X售价,引发了该公司一些最坚定支持者的不满。知名特斯拉多头、未来基金(Future Fund)管理合伙人加里·布莱克发帖称,降价是一种“短期麻醉剂”,会让潜在客户等待进一步降价。

发布于:1年以前  |  441次阅读  |  详细内容 »

光刻机巨头阿斯麦:拿到许可,继续对华出口

据外媒9月2日报道,荷兰半导体设备制造商阿斯麦称,尽管荷兰政府颁布的半导体设备出口管制新规9月正式生效,但该公司已获得在2023年底以前向中国运送受限制芯片制造机器的许可。

发布于:1年以前  |  437次阅读  |  详细内容 »

马斯克与库克首次隔空合作:为苹果提供卫星服务

近日,根据美国证券交易委员会的文件显示,苹果卫星服务提供商 Globalstar 近期向马斯克旗下的 SpaceX 支付 6400 万美元(约 4.65 亿元人民币)。用于在 2023-2025 年期间,发射卫星,进一步扩展苹果 iPhone 系列的 SOS 卫星服务。

发布于:1年以前  |  430次阅读  |  详细内容 »

𝕏(推特)调整隐私政策,可拿用户发布的信息训练 AI 模型

据报道,马斯克旗下社交平台𝕏(推特)日前调整了隐私政策,允许 𝕏 使用用户发布的信息来训练其人工智能(AI)模型。新的隐私政策将于 9 月 29 日生效。新政策规定,𝕏可能会使用所收集到的平台信息和公开可用的信息,来帮助训练 𝕏 的机器学习或人工智能模型。

发布于:1年以前  |  428次阅读  |  详细内容 »

荣耀CEO谈华为手机回归:替老同事们高兴,对行业也是好事

9月2日,荣耀CEO赵明在采访中谈及华为手机回归时表示,替老同事们高兴,觉得手机行业,由于华为的回归,让竞争充满了更多的可能性和更多的魅力,对行业来说也是件好事。

发布于:1年以前  |  423次阅读  |  详细内容 »

AI操控无人机能力超越人类冠军

《自然》30日发表的一篇论文报道了一个名为Swift的人工智能(AI)系统,该系统驾驶无人机的能力可在真实世界中一对一冠军赛里战胜人类对手。

发布于:1年以前  |  423次阅读  |  详细内容 »

AI生成的蘑菇科普书存在可致命错误

近日,非营利组织纽约真菌学会(NYMS)发出警告,表示亚马逊为代表的电商平台上,充斥着各种AI生成的蘑菇觅食科普书籍,其中存在诸多错误。

发布于:1年以前  |  420次阅读  |  详细内容 »

社交媒体平台𝕏计划收集用户生物识别数据与工作教育经历

社交媒体平台𝕏(原推特)新隐私政策提到:“在您同意的情况下,我们可能出于安全、安保和身份识别目的收集和使用您的生物识别信息。”

发布于:1年以前  |  411次阅读  |  详细内容 »

国产扫地机器人热销欧洲,国产割草机器人抢占欧洲草坪

2023年德国柏林消费电子展上,各大企业都带来了最新的理念和产品,而高端化、本土化的中国产品正在不断吸引欧洲等国际市场的目光。

发布于:1年以前  |  406次阅读  |  详细内容 »

罗永浩吐槽iPhone15和14不会有区别,除了序列号变了

罗永浩日前在直播中吐槽苹果即将推出的 iPhone 新品,具体内容为:“以我对我‘子公司’的了解,我认为 iPhone 15 跟 iPhone 14 不会有什么区别的,除了序(列)号变了,这个‘不要脸’的东西,这个‘臭厨子’。

发布于:1年以前  |  398次阅读  |  详细内容 »
 相关文章
Android插件化方案 5年以前  |  237276次阅读
vscode超好用的代码书签插件Bookmarks 2年以前  |  8110次阅读
 目录