众所周知 Android 中 Activity 有四种启动模式,决定了是否创建新的 Activity 实例或复用当前实例。但是实际上 Activity 的启动十分复杂,不单单是 android:launchMode
就能决定的,多个 Intent Flag 都能改变启动的行为模式,除此之外还会根据 android:taskAffinity
的值来判断对应任务栈是否存在。
首先复习一下最基本的 LaunchMode 行为模式:
onNewIntent()
方法,否则新建实例。onNewIntent()
方法,否则新建栈创建 Activity 实例。onNewIntent()
方法。这是我们最熟知的启动模式,但是需要注意的是:上述行为模式仅限于未添加任何 Flag,并且没有改变 taskAffinity 的前提下。
如前所述,如果单纯的 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将所有不影响异常的业务代码删除之后得到的最精简复现流程如下:
FLAG_ACTIVITY_NEW_TASK
启动 A_Activity: startActivity(Intent(this, AActivity::class.java).apply { addFlags(Intent.FLAG_ACTIVITY_NEW_TASK) })
startActivity(Intent(this, BActivity::class.java))
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 均未回调 onCreate
、onResume
或者 onNewIntent
等生命周期函数,也没有任何 Crash 或者 ANR 的日志发生,点击 B_Activity 可以正常操作。
首先排除 Service 的 Context 的原因,因为我们可以构造如下流程,实验会发现 A_Activity 依然无法启动:
finish
后附加 FLAG_ACTIVITY_NEW_TASK
启动 A_Activity: finish()
startActivity(Intent(this, AActivity::class.java).apply { addFlags(Intent.FLAG_ACTIVITY_NEW_TASK) })
startActivity(Intent(this, BActivity::class.java))
FLAG_ACTIVITY_NEW_TASK
启动 A_Activity: startActivity(Intent(this, AActivity::class.java).apply { addFlags(Intent.FLAG_ACTIVITY_NEW_TASK) })
那么从使用排除法得到 FLAG_ACTIVITY_NEW_TASK
有可能是原因了。另外细心观察上面的步骤,会发现第一步先 finish
再 startActivity
,如果去掉 finish
做实验会发现其实可以成功启动 A_Activity,那么另一个原因应该就是 finish
了。
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
方法依然比较长,所以将只看几个可能产生影响的地方,对任务栈有影响的关键方法是 getReusableTask
和 recycleTask
。
首先先看看 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
的源码:
//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
,在 startActivityInner
中 recycleTask
部分的相关代码是:
//com.android.server.wm.ActivityStarter#startActivityInner
startResult = recycleTask(targetTask, targetTaskTop, reusedTask, intentGrants);
if (startResult != START_SUCCESS) {
return startResult;
}
即根本没有运行 startActivityInner
后半部分代码,启动失败原因就在于此,因此不再逐一解析 recycleTask
,而是着眼于为何没有返回 START_SUCCESS
,可以逐一寻找 recycleTask
中所有 return
的地方:
START_SUCCESS
START_FLAG_ONLY_IF_NEEDED
表示启动和被启动者是同一个 Activity,因此不会返回 START_RETURN_INTENT_TO_CALLER
mAddingToTask
是否为 true
来确定是否返回 START_SUCCESS
,关联方法是 complyActivityFlags
,此处需要分析一下为何 mAddingToTask
为 false
mMovedToFront
判断返回为 START_TASK_TO_FRONT
还是 START_DELIVERED_TO_TOP
,关联的方法是 setTargetStackIfNeeded
,由于上一步已经断绝了返回 START_SUCCESS
的可能,无法正常创建一个 Activity 实例了,就不再分析此方法。//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_TASK
、FLAG_ACTIVITY_CLEAR_TOP
、FLAG_ACTIVITY_REORDER_TO_FRONT
;启动模式是 standard
;虽然待启动 Activity 的完整组件名如果和目标栈启动栈的 Activity 相同,但是却又不符合下面的所有判断;虽然可以进入 !resetTask
的分支却被上一个分支截胡……总之完美避过了所有能正常启动的 case。
那么不能创建新的 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
正常进行后面的逻辑处理,仅列举几个简单的方法,根据自身的业务自行处理:
getReusableTask
中 putIntoExistingTask
为 false
:比如设置第二次启动 A_Activity 的 Flag 为 FLAG_ACTIVITY_NEW_TASK | FLAG_ACTIVITY_MULTIPLE_TASK
;或者如果在允许的条件下(比如不是复现流程时的 Service 中启动),直接去掉 FLAG_ACTIVITY_NEW_TASK
即可。complyActivityFlags
能进入 mAddingToTask
为 true
的 case ,这里分支非常多,所以方案也更多:比如设置第二次启动 A_Activity 的 Flag 为 FLAG_ACTIVITY_NEW_TASK | FLAG_ACTIVITY_CLEAR_TASK
;或者就像前面分析 finish
的影响,注意栈的情况不要使得启动栈的 Activity 和待启动的 Activity 相同。根据我们的业务需求,我们选择的方案如下:
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) })
finish()//注:此处 finish 和异常无关,仅为业务需求,即使去掉也会发生异常
startActivity(Intent(this, BActivity::class.java))
此时会出现 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
:
singleInstance
singleInstance
或 singleTask
原因就显而易见了,我们的 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 叠加时可能会遇到更多的坑点,不过一旦遇到了这些神坑,其实深入源码去研究有时候反而能更快得到结论。
本文由哈喽比特于2年以前收录,如有侵权请联系我们。
文章来源:https://mp.weixin.qq.com/s/uwIcmz-LfhzbSseeGnW_Vw
京东创始人刘强东和其妻子章泽天最近成为了互联网舆论关注的焦点。有关他们“移民美国”和在美国购买豪宅的传言在互联网上广泛传播。然而,京东官方通过微博发言人发布的消息澄清了这些传言,称这些言论纯属虚假信息和蓄意捏造。
日前,据博主“@超能数码君老周”爆料,国内三大运营商中国移动、中国电信和中国联通预计将集体采购百万台规模的华为Mate60系列手机。
据报道,荷兰半导体设备公司ASML正看到美国对华遏制政策的负面影响。阿斯麦(ASML)CEO彼得·温宁克在一档电视节目中分享了他对中国大陆问题以及该公司面临的出口管制和保护主义的看法。彼得曾在多个场合表达了他对出口管制以及中荷经济关系的担忧。
今年早些时候,抖音悄然上线了一款名为“青桃”的 App,Slogan 为“看见你的热爱”,根据应用介绍可知,“青桃”是一个属于年轻人的兴趣知识视频平台,由抖音官方出品的中长视频关联版本,整体风格有些类似B站。
日前,威马汽车首席数据官梅松林转发了一份“世界各国地区拥车率排行榜”,同时,他发文表示:中国汽车普及率低于非洲国家尼日利亚,每百户家庭仅17户有车。意大利世界排名第一,每十户中九户有车。
近日,一项新的研究发现,维生素 C 和 E 等抗氧化剂会激活一种机制,刺激癌症肿瘤中新血管的生长,帮助它们生长和扩散。
据媒体援引消息人士报道,苹果公司正在测试使用3D打印技术来生产其智能手表的钢质底盘。消息传出后,3D系统一度大涨超10%,不过截至周三收盘,该股涨幅回落至2%以内。
9月2日,坐拥千万粉丝的网红主播“秀才”账号被封禁,在社交媒体平台上引发热议。平台相关负责人表示,“秀才”账号违反平台相关规定,已封禁。据知情人士透露,秀才近期被举报存在违法行为,这可能是他被封禁的部分原因。据悉,“秀才”年龄39岁,是安徽省亳州市蒙城县人,抖音网红,粉丝数量超1200万。他曾被称为“中老年...
9月3日消息,亚马逊的一些股东,包括持有该公司股票的一家养老基金,日前对亚马逊、其创始人贝索斯和其董事会提起诉讼,指控他们在为 Project Kuiper 卫星星座项目购买发射服务时“违反了信义义务”。
据消息,为推广自家应用,苹果现推出了一个名为“Apps by Apple”的网站,展示了苹果为旗下产品(如 iPhone、iPad、Apple Watch、Mac 和 Apple TV)开发的各种应用程序。
特斯拉本周在美国大幅下调Model S和X售价,引发了该公司一些最坚定支持者的不满。知名特斯拉多头、未来基金(Future Fund)管理合伙人加里·布莱克发帖称,降价是一种“短期麻醉剂”,会让潜在客户等待进一步降价。
据外媒9月2日报道,荷兰半导体设备制造商阿斯麦称,尽管荷兰政府颁布的半导体设备出口管制新规9月正式生效,但该公司已获得在2023年底以前向中国运送受限制芯片制造机器的许可。
近日,根据美国证券交易委员会的文件显示,苹果卫星服务提供商 Globalstar 近期向马斯克旗下的 SpaceX 支付 6400 万美元(约 4.65 亿元人民币)。用于在 2023-2025 年期间,发射卫星,进一步扩展苹果 iPhone 系列的 SOS 卫星服务。
据报道,马斯克旗下社交平台𝕏(推特)日前调整了隐私政策,允许 𝕏 使用用户发布的信息来训练其人工智能(AI)模型。新的隐私政策将于 9 月 29 日生效。新政策规定,𝕏可能会使用所收集到的平台信息和公开可用的信息,来帮助训练 𝕏 的机器学习或人工智能模型。
9月2日,荣耀CEO赵明在采访中谈及华为手机回归时表示,替老同事们高兴,觉得手机行业,由于华为的回归,让竞争充满了更多的可能性和更多的魅力,对行业来说也是件好事。
《自然》30日发表的一篇论文报道了一个名为Swift的人工智能(AI)系统,该系统驾驶无人机的能力可在真实世界中一对一冠军赛里战胜人类对手。
近日,非营利组织纽约真菌学会(NYMS)发出警告,表示亚马逊为代表的电商平台上,充斥着各种AI生成的蘑菇觅食科普书籍,其中存在诸多错误。
社交媒体平台𝕏(原推特)新隐私政策提到:“在您同意的情况下,我们可能出于安全、安保和身份识别目的收集和使用您的生物识别信息。”
2023年德国柏林消费电子展上,各大企业都带来了最新的理念和产品,而高端化、本土化的中国产品正在不断吸引欧洲等国际市场的目光。
罗永浩日前在直播中吐槽苹果即将推出的 iPhone 新品,具体内容为:“以我对我‘子公司’的了解,我认为 iPhone 15 跟 iPhone 14 不会有什么区别的,除了序(列)号变了,这个‘不要脸’的东西,这个‘臭厨子’。