您当前的位置:首页 > 手机百科 > iphone百科

一键释放iOS 64位App潜力

时间:2022-07-07 12:54:51  来源:腾讯技术工程  作者:

作者:eddiecmchen,PCG客户端开发工程师

| 导语 把我的iphone XR扶起来,它还能再顶一会儿~

背景

远在IOS 11时期(2017年),苹果就发公告要求所有需要上架AppStore的应用都必须支持64位。32位应用不再支持上架与运行。

一键释放iOS 64位App潜力

 

升级64位应用有什么好处呢?(以下内容纯摘抄,客官可以直接跳过)

  • 指针字长更长,可使用的虚拟内存更大,摆脱32位下受限的4G内存空间
    • 16 bit = 65,536 bytes (64 Kilobytes)
    • 32 bit = 4,294,967,296 bytes (4 Gigabytes)
    • 64 bit = 18,446,744,073,709,551,616 (16 Exabytes)
  • 寄存器更多,减少内存读写,加快执行速度

这里我们要注意的是:虚拟内存确实比纯32位多了,但是App到底能用多少,是否跟宣传一样接近16EB?下面将会展开聊聊,我们先来看一个Crash。

一个长期存在的幽灵

我们先来看下面的一个内存导致的崩溃,JSC在使用bmalloc尝试进行内存分配时,提示OOM导致了SIGTRAP。

Last Exception :
0  JAVAScriptCore                 0x000000018b777570 _pas_panic_on_out_of_memory_error
1  JavaScriptCore                 0x000000018b72e918 _bmalloc_try_iso_allocate_impl_impl_slow
2  JavaScriptCore                 0x000000018b73d3d8 _bmalloc_heap_config_specialized_local_allocator_try_allocate_small_segregated_slow +  5952
3  JavaScriptCore                 0x000000018b7276f8 _bmalloc_allocate_impl_casual_case +  800
4  JavaScriptCore                 0x000000018c60d494 JSC::PropertyTable::create(JSC::VM&, unsigned int) +  244
5  JavaScriptCore                 0x000000018c66ba74 JSC::Structure::materializePropertyTable(JSC::VM&, bool) +  324
6  JavaScriptCore                 0x000000018c66dfac JSC::Structure::changePrototypeTransition(JSC::VM&, JSC::Structure*, JSC::JSValue, JSC::DeferredStructureTransitionWatchpointFire&) +  612
7  JavaScriptCore                 0x000000018c559930 JSC::JSObject::setPrototypeDirect(JSC::VM&, JSC::JSValue) +  192
8  JavaScriptCore                 0x000000018c559e40 JSC::JSObject::setPrototypeWithCycleCheck(JSC::VM&, JSC::JSGlobalObject*, JSC::JSValue, bool) +  316
9  JavaScriptCore                 0x000000018c4f580c JSC::globalFuncProtoSetter(JSC::JSGlobalObject*, JSC::CallFrame*) +  192
10 JavaScriptCore                 0x000000018ba1f7a8 _vmEntryToNative +  280
11 JavaScriptCore                 0x000000018c1b0cd0 JSC::Interpreter::executeCall(JSC::JSGlobalObject*, JSC::JSObject*, JSC::CallData const&, JSC::JSValue, JSC::ArgList const&) +  616
12 JavaScriptCore                 0x000000018c474ecc JSC::GetterSetter::callSetter(JSC::JSGlobalObject*, JSC::JSValue, JSC::JSValue, bool) +  212
13 JavaScriptCore                 0x000000018c5b6264 JSC::JSGenericTypedArrayView<JSC::Uint8Adaptor>::put(JSC::JSCell*, JSC::JSGlobalObject*, JSC::PropertyName, JSC::JSValue, JSC::PutPropertySlot&) +  612
14 JavaScriptCore                 0x000000018c2c2ecc _llint_slow_path_put_by_id +  3244
// 忽略多余重复堆栈
37 JavaScriptCore                 0x000000018ba1f5fc _vmEntryToJavaScript +  264
38 JavaScriptCore                 0x000000018c1b0c7c JSC::Interpreter::executeCall(JSC::JSGlobalObject*, JSC::JSObject*, JSC::CallData const&, JSC::JSValue, JSC::ArgList const&) +  532
39 JavaScriptCore                 0x000000018bac7ae4 _JSObjectCallAsFunction +  568
40 mttlite                        0x0000000102a54914 hippy::napi::JSCCtx::CallFunction(std::__1::shared_ptr<hippy::napi::CtxValue> const&, unsigned long, std::__1::shared_ptr<hippy::napi::CtxValue> const*) (js_native_api_value_jsc.cc:406)
41 mttlite                        0x0000000102a664e0 _ZNSt3__110__function6__funcIZN11TimerModule5StartERKN5hippy4napi12CallbackInfoEbE3$_4NS_9allocatorIS8_EEFvvEEclEv (memory:3237)
42 mttlite                        0x0000000102a63018 hippy::base::TaskRunner::Run() (memory:3237)
43 mttlite                        0x0000000102a64974 ThreadEntry (thread.cc:0)
44 libsystem_pthread.dylib        0x00000001dc129348 __pthread_start +  116
------

Exception Type: SIGTRAP 
Exception Codes: fault addr: 0x000000018b777570
Crashed Thread: 48 hippy.js

这个OOM问题,与iOS上常见的OOM不一样。按照常规的理解,当App内存不足的时候,正常会触发系统的Jetsam机制杀死App。在系统日志中会留下Jetsam相关日志,理论上不会在Bugly等异常上报中发现。但这一类崩溃却一直在产生上报,并且低内存的崩溃堆栈表现形式有很多种。

以上的JSC崩溃问题已经存在很长一段时间了(至少2年),而且崩溃堆栈都集中在JSC执行JS代码的过程中,长期缺乏JS相关的监控与Debug工具导致该问题一直无法解决。

虽然堆栈上有明确的原因说明是OOM,但我们观察到有不少用户实际上物理内存空间还是足够的:

一键释放iOS 64位App潜力

 

两年前,冲浪的时候偶然看来了来自微视同学的Case总结:《OOM与内存》

当时跟hippy SDK的同事也讨论过是否存在类似的内存不足情况。但由于大家对JSC黑盒都不熟悉,而且崩溃的JS堆栈也不确切。当时的建议是:少在后台加载JSC。最终也并没有解决该问题。

两年后,当浏览器集成flutter,类似的JS崩溃直接翻倍(21H2 0.08% -> 22H1 0.16%)。没办法,还是要看类似JSC和Dart VM的内存分配机制是怎样的,再挖掘一下是否存在解()决()方案。

JSC、DartVM的虚拟内存分配

翻阅相关虚拟机的内存管理相关代码,可以找到底层的内存分配基本实现都是基于mmap处理的。

// WebKit bmalloc VMAllocate
inline void* tryVMAllocate(size_t vmSize, VMTag usage = VMTag::Malloc)
{
    vmValidate(vmSize);
    void* result = mmap(0, vmSize, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANON | BMALLOC_NORESERVE, static_cast<int>(usage), 0);
    if (result == MAP_FAILED)
        return nullptr;
    return result;
}
// Dart VM的虚拟内存
VirtualMemory* VirtualMemory::Allocate(intptr_t size,
                                       bool is_executable,
                                       const char* name) {
  ASSERT(Utils::IsAligned(size, PageSize()));

  const int prot = PROT_READ | PROT_WRITE | (is_executable ? PROT_EXEC : 0);

  int map_flags = MAP_PRIVATE | MAP_ANONYMOUS;
#if (defined(DART_HOST_OS_macOS) && !defined(DART_HOST_OS_IOS))
  if (is_executable && IsAtLeastOS10_14()) {
    map_flags |= MAP_JIT;
  }
#endif  // defined(DART_HOST_OS_MACOS)

  // Some 64-bit microarchitectures store only the low 32-bits of targets as
  // part of indirect branch prediction, predicting that the target's upper bits
  // will be same as the call instruction's address. This leads to misprediction
  // for indirect calls crossing a 4GB boundary. We ask mmap to place our
  // generated code near the VM binary to avoid this.
  void* hint = is_executable ? reinterpret_cast<void*>(&Allocate) : nullptr;
  void* address = mmap(hint, size, prot, map_flags, -1, 0);
  if (address == MAP_FAILED) {
    return nullptr;
  }
  return new VirtualMemory(address, size);
}

VirtualMemory::~VirtualMemory() {
  if (address_ != nullptr) {
    if (munmap(address_, size_) != 0) {
      int error = errno;
      const int kBufferSize = 1024;
      char error_buf[kBufferSize];
      FATAL("munmap error: %d (%s)", error,
            Utils::StrError(error, error_buf, kBufferSize));
    }
  }
}

当map_flags包含MAP_ANON时,并且fd传入-1时,mmap将直接使用虚拟内存进行分配,不需要依赖文件描述符。

mmap在xnu上的实现

/*
 * mmap stub, with preemptory failures due to extra parameter checking
 * mandated for conformance.
 *
 * This is for UNIX03 only.
 */
void *
mmap(void *addr, size_t len, int prot, int flags, int fildes, off_t off)
{
    /*
     * Preemptory failures:
     * 
     * o    off is not a multiple of the page size
     * o    flags does not contain either MAP_PRIVATE or MAP_SHARED
     * o    len is zero
     */
    extern void cerror_nocancel(int);
    if ((off & PAGE_MASK) ||
        (((flags & MAP_PRIVATE) != MAP_PRIVATE) &&
         ((flags & MAP_SHARED) != MAP_SHARED)) ||
        (len == 0)) {
        cerror_nocancel(EINVAL);
        return(MAP_FAILED);
    }

    void *ptr = __mmap(addr, len, prot, flags, fildes, off);
    
    if (__syscall_logger) {
        int stackLoggingFlags = stack_logging_type_vm_allocate;
        if (flags & MAP_ANON) {
            stackLoggingFlags |= (fildes & VM_FLAGS_ALIAS_MASK);
        } else {
            stackLoggingFlags |= stack_logging_type_mapped_file_or_shared_mem;
        }
        __syscall_logger(stackLoggingFlags, (uintptr_t)mach_task_self(), (uintptr_t)len, 0, (uintptr_t)ptr, 0);
    }

    return ptr;
}

上面的调用会传递到内核kern_mman.c的实现函数mmap(proc_t p, struct mmap_args *uap, user_addr_t *retval)

/*
 * XXX Internally, we use VM_PROT_* somewhat interchangeably, but the correct
 * XXX usage is PROT_* from an interface perspective.  Thus the values of
 * XXX VM_PROT_* and PROT_* need to correspond.
 */
int
mmap(proc_t p, struct mmap_args *uap, user_addr_t *retval)
{
        /*
         * 上面忽略了一部分代码
         */
        result = vm_map_enter_mem_object(user_map,
            &user_addr, user_size,
            0, alloc_flags, vmk_flags,
            tag,
            IPC_PORT_NULL, 0, FALSE,
            prot, maxprot,
            (flags & MAP_SHARED) ?
            VM_INHERIT_SHARE :
            VM_INHERIT_DEFAULT);

        /* If a non-binding address was specified for this anonymous
         * mapping, retry the mapping with a zero base
         * in the event the mapping operation failed due to
         * lack of space between the address and the map's maximum.
         */
        if ((result == KERN_NO_SPACE) && ((flags & MAP_FIXED) == 0) && user_addr && (num_retries++ == 0)) {
            user_addr = vm_map_page_size(user_map);
            goto map_anon_retry;
        }
        /*
         * 下面忽略了一部分代码
         */
}

其中又会调用vm_map.c内部的vm_map_enter_mem_object,而该方法最终会在vm_map_enter中依据对象进行内存分配:

// 下面这个只截了个头,大概带一下,我也没调过代码~
/*
 *  Routine:    vm_map_enter
 *
 *  Description:
 *      Allocate a range in the specified virtual address map.
 *      The resulting range will refer to memory defined by
 *      the given memory object and offset into that object.
 *
 *      Arguments are as defined in the vm_map call.
 */
kern_return_t
vm_map_enter(
    vm_map_t                map,
    vm_map_offset_t         *address,       /* IN/OUT */
    vm_map_size_t           size,
    vm_map_offset_t         mask,
    int                     flags,
    vm_map_kernel_flags_t   vmk_flags,
    vm_tag_t                alias,
    vm_object_t             object,
    vm_object_offset_t      offset,
    boolean_t               needs_copy,
    vm_prot_t               cur_protection,
    vm_prot_t               max_protection,
    vm_inherit_t            inheritance)

其中vm_map_enter在分配过程中会对hole_entry→vme_end作判断,vme_end即最大的可分配空间。

xnu上虚拟内存的分配范围

本来我只是观察到苹果在iOS15上增加了com.apple.developer.kernel.increased-memory-limit的能力声明。本着死马当活马医的想法,尝试在新版本上添加该声明以缓解一部分问题。

结果偶然看到部分开发者提问:该能力可配合com.apple.developer.kernel.extended-virtual-addressing使用。看到后我一下子反应过来,顺手搜到了今年二月国外有大佬做了相关的探索:

Size Matters: An Exploration of Virtual Memory on iOS

文章阐述了iOS的内存管理机制和虚拟内存空间分配在不同的机型上存在上限,代码如下:

#define ARM64_MIN_MAX_ADDRESS (SHARED_REGION_BASE_ARM64 + SHARED_REGION_SIZE_ARM64 + 0x20000000) // end of shared region + 512MB for various purposes
const vm_map_offset_t min_max_offset = ARM64_MIN_MAX_ADDRESS; // end of shared region + 512MB for various purposes

if (arm64_pmap_max_offset_default) {
    max_offset_ret = arm64_pmap_max_offset_default;
} else if (max_mem > 0xC0000000) {
    max_offset_ret = min_max_offset + 0x138000000; // Max offset is 13.375GB for devices with > 3GB of memory
} else if (max_mem > 0x40000000) {
    max_offset_ret = min_max_offset + 0x38000000;  // Max offset is 9.375GB for devices with > 1GB and <= 3GB of memory
} else {
    max_offset_ret = min_max_offset;
}

并且总结了一个上限值与机型表格:

RAM

Address Space

Usable

Devices

> 3 GiB

15.375 GiB

7.375 GiB

- iPhone XS – iPhone 13
- iPad Air (4th generation)
- iPad Pro (12.9-inch), (10.5-inch), (11-inch)

> 1 GiB

11.375 GiB

3.375 GiB

- iPhone 6s – X, SE, XR
- iPad (5th generation) – iPad (8th generation)
- iPad Air 2, iPad Air (3rd generation)
- iPad mini 4, iPad mini (5th generation)
- iPad Pro (9.7-inch)

<= 1 GiB

10.5 GiB

2.5 GiB

- iPhone 5s, iPhone 6
- iPad Air
- iPad mini 2, iPad mini 3

而xnu的源码(pmap.c)中还透露了内核内存分配存在jumbo机制。当iOS App带有指定的能力声明时,xnu内核将会以jumbo模式运行,虚拟内存地址空间将会直接分配为最大值64GB:

if (option == ARM_PMAP_MAX_OFFSET_JUMBO) {
    if (arm64_pmap_max_offset_default) {
        // Allow the boot-arg to override jumbo size
        max_offset_ret = arm64_pmap_max_offset_default;
    } else {
        max_offset_ret = MACH_VM_MAX_ADDRESS;     // Max offset is 64GB for pmaps with special "jumbo" blessing
    }
}

并且该上限值会在进程启动时进行调整,具体代码可以在kern_exec.c中找到:

/*
 * Apply the requested maximum address.
 */
if (error == 0 && imgp->ip_px_sa != NULL) {
    struct _posix_spawnattr *psa = (struct _posix_spawnattr *) imgp->ip_px_sa;

    if (psa->psa_max_addr) {
        vm_map_set_max_addr(get_task_map(new_task), (vm_map_offset_t)psa->psa_max_addr);
    }
}

甚少文档记录的entitlement

com.apple.developer.kernel.extended-virtual-addressing

苹果的文档仅有一句话说明该能力:

Use this entitlement if your app has specific needs that require a larger addressable space. For example, games that memory map assets to stream to the GPU may benefit from a larger address space.

举个例子:有的游戏需要将资源通过mmap的形式传递到GPU中渲染时,更大的地址空间可提高其运行效率。

描述上看,配置该选项时,将开启上面xnu的jumbo mode,地址的扩充刚好能解决上面的崩溃问题。

做一次极限测试

为验证地址分配的极限值,简单做个实验(测试设备使用iPhone XR iOS 16 Beta 2):

通过malloc进行连续的内存分配(也可以用vm_allocate,阈值不一样),阈值卡在1009字节(为什么是1009字节,这里可以参考【ios 内核】源码解读(3) 详解ios是怎么malloc的(上) - 钟路成的博客 (luchengzhong.Github.io))。

for (size_t i = 0; i < SIZE_T_MAX; i++) {
    void *a = malloc(1009);
    if (a == NULL) {
        NSLog(@"error count: %lu", i);
        break;
    }
}

结果如下:

size = 1009 > SMALL_THRESHOLD (64位系统下1008字节,32位系统下496)

内存扩展前malloc失败阈值约 7065482 * 1009 = 6.63 GB

内存扩展后malloc失败阈值约 56753881 * 1009 = 53.33 GB

当然,在xnu的单元测试代码中,也可找到jumbo mode相关的测试代码,与上面的测试结果完全一致,即最多可分配53GB的空间。

#define GB (1ULL * 1024 * 1024 * 1024)

/*
 * This test expects the entitlement to be the enabling factor for a process to
 * allocate at least this many GB of VA space. i.e. with the entitlement, n GB
 * must be allocatable; whereas without it, it must be less.
 * This value was determined experimentally to fit on applicable devices and to
 * be clearly distinguishable from the default VA limit.
 */
#define ALLOC_TEST_GB 53

T_DECL(TESTNAME,
    "Verify that a required entitlement is present in order to be granted an extra-large "
    "VA space on arm64",
    T_META_NAMESPACE("xnu.vm"),
    T_META_CHECK_LEAKS(false))
{
    int i;
    void    *res;

    if (!dt_64_bit_kernel()) {
        T_SKIP("This test is only applicable to arm64");
    }

    T_LOG("Attemping to allocate VA space in 1 GB chunks.");

    for (i = 0; i < (ALLOC_TEST_GB * 2); i++) {
        res = mmap(NULL, 1 * GB, PROT_NONE, MAP_PRIVATE | MAP_ANON, 0, 0);
        if (res == MAP_FAILED) {
            if (errno != ENOMEM) {
                T_WITH_ERRNO;
                T_LOG("mmap failed: stopped at %d of %d GB allocated", i, ALLOC_TEST_GB);
            }
            break;
        } else {
            T_LOG("%d: %pn", i, res);
        }
    }

#if defined(ENTITLED)
    T_EXPECT_GE_INT(i, ALLOC_TEST_GB, "Allocate at least %d GB of VA space", ALLOC_TEST_GB);
#else
    T_EXPECT_LT_INT(i, ALLOC_TEST_GB, "Not permitted to allocate %d GB of VA space", ALLOC_TEST_GB);
#endif
}

可见,当开启com.apple.developer.kernel.extended-virtual-addressing时,内核的可分配空间确实有明显提升。

上线效果与结论

从QQ浏览器的上线效果来看,JS相关的内存分配Crash在14.0以上系统几乎全部消失。上线第一天App崩溃率环比下降接近50%,效果显著。

一键释放iOS 64位App潜力

 

简单总结:

  1. 苹果很少在公开文档中说明64位App在虚拟内存使用上存在限制。而且很多App也并没有像浏览器内一样,为业务灵活性而选择将hippy、flutter等技术进行大规模的组合使用,所以可能很多App其实并不会遇到虚拟内存不足的情况。
  2. 上线效果也说明浏览器在混合开发的场景下,内存优化仍然存在很大的空间。因为Extended Virtual Addressing仅能缓解虚拟内存不足的情况,并不意味着App的物理内存也得到增加,对FOOM的治理仍然需要持续。
  3. 鉴于司内有不少的著名组件都会使用mmap机制进行内存管理,建议在使用相关组件时,控制好mmap的大小。
  4. 如果有需要在iPhone 12 Pro、M1 iPad、M1上运行应用,并希望解放更多的物理内存,建议增加com.apple.developer.kernel.increased-memory-limit的能力声明,实测在iPhone 13 Pro下可以增加1GB的可用物理内存。
  5. ReactNative和类似框架在项目中使用较多的,建议需要考虑多个Context的复用,减少创建重复内容,司内外都有实践证明该措施十分有效。
  6. 对于flutter一类的内存优化,可翻阅engine的相关代码。flutter vm在创建时允许外部传参控制vm行为,包括:old heap size、leak vm等。合适的参数可比较有效控制内存占用。

以上源码相关的内容仅个人阅读理解,如有错误请指出。



Tags:iOS   点击:()  评论:()
声明:本站部分内容及图片来自互联网,转载是出于传递更多信息之目的,内容观点仅代表作者本人,不构成投资建议。投资者据此操作,风险自担。如有任何标注错误或版权侵犯请与我们联系,我们将及时更正、删除。
▌相关推荐
iOS 17.5进一步开放 游戏可官网下载直接安装
苹果iOS 17.5版本系统将在近期开放测试,在该版本中,苹果会进一步开放侧载功能,让用户能够如同安卓手机那样,随意安装应用。据外媒消息称,苹果iOS 17.5版本系统将在近期开放测试,在...【详细内容】
2024-04-02  Search: iOS  点击:(13)  评论:(0)  加入收藏
揭秘 iOS 17.4:欧盟独享功能,其他地区无法体验
【环球网科技综合报道】据外媒消息,随着iOS 17.4的发布,欧洲用户能够独享一些全球其他地区无法获得的新功能。这得益于欧洲联盟的《数字市场法案》,苹果不得不向侧载等功能开放...【详细内容】
2024-03-18  Search: iOS  点击:(18)  评论:(0)  加入收藏
苹果iOS17.4值得升级吗?续航信号评测来了
苹果iOS17.4值得升级吗?很多iPhone用户都在纠结这个版本续航和信号都有没提升,纠结是否需要升级,那么这个版本信号信号到底怎样呢?下面就给大家分享iPhone13升级iOS17.4的续航信...【详细内容】
2024-03-07  Search: iOS  点击:(13)  评论:(0)  加入收藏
苹果“安全”神话破灭?!iOS首次出现木马病毒
一直以来,iOS系统都以“安全性极高”闻名手机圈。在封闭软硬件生态加持下,iOS确实要比安卓系统更安全点。但是,小雷要说但是了嚯,最近iOS却首次出现了木马病毒。图源:苹果近日,在...【详细内容】
2024-02-19  Search: iOS  点击:(70)  评论:(0)  加入收藏
木马病毒蔓延至iOS:苹果用户如何防范?
近期,网络安全公司Group-IB发布了一份引人注目的报告,揭示了黑客已经开始针对iPhone用户发起银行木马攻击。这一事件标志着iOS系统首次遭受此类安全威胁,为全球的苹果用户敲响...【详细内容】
2024-02-18  Search: iOS  点击:(52)  评论:(0)  加入收藏
黑客利用iOS系统中的三个零日漏洞在iPhone上安装间谍软件
2月7日,据谷歌威胁分析小组(TAG)发布的报告,黑客成功利用存在于苹果iOS系统中的三个零日漏洞,在iPhone上安装了由Variston开发的间谍软件。Variston是一家位于巴塞罗那的网络公司...【详细内容】
2024-02-07  Search: iOS  点击:(64)  评论:(0)  加入收藏
一夜之间,iOS放开了侧载和NFC等限制:苹果的欧洲福利
在最新的iOS更新中,苹果似乎放宽了一些长期以来受到限制的功能。据报道,新版本的iOS开放了侧载和NFC等功能的访问,这对于欧洲地区的用户来说无疑是一个巨大的福利。侧载,即从第...【详细内容】
2024-01-26  Search: iOS  点击:(59)  评论:(0)  加入收藏
部分iPhone用户升级iOS 17.3失败 提示“无法验证更新”
【CNMO新闻】近日,CNMO从外媒获悉,部分iPhone用户在升级iOS 17.3时遇到问题,手机会提示“无法验证更新”。iOS 17.3据悉,苹果社区的一些成员和部分Reddit用户反映,他们无法下载更...【详细内容】
2024-01-26  Search: iOS  点击:(60)  评论:(0)  加入收藏
苹果iOS 17.3正式版发布:修复诸多安全漏洞
北京时间2023年1月23日凌晨,苹果向iPhone用户推送了iOS 17.3更新(内部版本号为21D50),此次更新距离上次时隔34天。iOS 17.3的安装包大小为600MB左右。尽管更新包容量不大,但iOS 1...【详细内容】
2024-01-23  Search: iOS  点击:(44)  评论:(0)  加入收藏
电脑启动故障排查:硬盘丢失、BIOS恢复失败,一篇文章帮你解决!
如果系统无法启动到Windows,可能是因为 BIOS 损坏,通常表现为No POST 或No Boot。系统的BIOS/UEFI 是硬件和软件之间的桥梁,因此如果系统无法启动,可能是 BIOS 出现故障。您可以...【详细内容】
2024-01-19  Search: iOS  点击:(59)  评论:(0)  加入收藏
▌简易百科推荐
iPhone Wi-Fi 无法打开?这五种原因及解决方法,让你快速恢复网络!
当 iPhone 无法打开 Wi-Fi 时,可能涉及多种原因,包括软件问题、网络设置、硬件故障等。下面将详细介绍可能导致 iPhone 无法打开 Wi-Fi 的各种原因,并提供相应的解决方法,帮助你...【详细内容】
2024-04-11  编程资料站    Tags:iPhone   点击:(8)  评论:(0)  加入收藏
iPhone 来电拦截:从系统到应用,全面保护你的隐私!
iPhone手机提供了多种方法来拦截陌生来电,用户可以根据自己的需求和偏好选择合适的方式。下面我将详细介绍iPhone手机拦截陌生来电的几种方法,帮助你更好地保护隐私和管理通讯...【详细内容】
2024-04-10  编程资料站     Tags:iPhone   点击:(8)  评论:(0)  加入收藏
iPhone 来电拦截:从系统到应用,全面保护你的隐私!
iPhone手机提供了多种方法来拦截陌生来电,用户可以根据自己的需求和偏好选择合适的方式。下面我将详细介绍iPhone手机拦截陌生来电的几种方法,帮助你更好地保护隐私和管理通讯...【详细内容】
2024-04-10  编程资料站    Tags:iPhone   点击:(7)  评论:(0)  加入收藏
苹果再发多模态论文!陪我们走过十年的“Hey Siri”会被更智能的交互方式取代吗?
编辑 | 伊风出品 | 51CTO技术栈(微信号:blog51cto) 全面发力AI的苹果,再出新研究! 随着人工智能技术的发展,我们熟悉的“Hey Siri”或将成为历史。 苹果团队最新出炉的论文《利用...【详细内容】
2024-03-26    51CTO  Tags:多模态   点击:(11)  评论:(0)  加入收藏
苹果手机投屏到Windows电脑,帮父母轻松攻克手机难题
明窗净几夜未央,键盘轻敲解忧忙。父母笑颜消难题,孝心科技共光芒。QQ、微信、小红书等社交软件不仅年轻人在用,老年人也逐步使用社交软件建立起自己的朋友圈。但这些“新”软件...【详细内容】
2024-03-18  AirDroid    Tags:投屏   点击:(10)  评论:(0)  加入收藏
苹果iPhone快充,为何27W成极限?三大原因道破真相
最近有小伙伴私信 der,说国产手机都卷到 200W 快充了,苹果 iPhone 最高怎么还是 27W 功率?有人说,27W 够用了,反正 30 分钟能够充至 50% 电量;有人说,是苹果摆烂,故意不做快充恶心人...【详细内容】
2024-02-22  科技好兄der    Tags:iPhone快充   点击:(32)  评论:(0)  加入收藏
Apple Pencil如何连接iPad?这里提供详细步骤
如果你刚拿起一支Apple Pencil,想和iPad一起使用,你需要先连接设备。将Apple Pencil与iPad配对的方法因你拥有的铅笔而异。一旦你将Apple Pencil连接到iPad,你就可以利用这些方...【详细内容】
2024-02-03  驾驭信息纵横科技    Tags:Apple Pencil   点击:(54)  评论:(0)  加入收藏
苹果的电池健康度,80%和100%到底有多大差别?
很多果粉在购买新机后,都会有个小习惯,那就是查看手机电池的健康度。由此也产生了一个疑问,手机从100%掉到80%,究竟有多大的区别?80%的健康度,是否是衡量更换电池的准则呢?想要查看...【详细内容】
2024-01-22  科普DoReMi  今日头条  Tags:电池健康度   点击:(38)  评论:(0)  加入收藏
iPhone抹掉数据后能恢复吗?看完这篇文章你就知道了!
随着科技的飞速发展,智能手机已经成为我们生活中不可缺少的一部分。如果手机出现卡顿、运行缓慢等问题,那么抹掉数据可以帮助清理手机的缓存和临时文件,从而提高手机的性能。但...【详细内容】
2024-01-19  数据恢复软件    Tags:iPhone   点击:(62)  评论:(0)  加入收藏
苹果微信无法登录?解决方案来啦!让你的微信重回正常!
当我们遇到微信无法登录的问题时,可能会感到焦虑和困惑。苹果手机微信无法登录的问题可能是很多原因导致的。在解决这个问题之前,我们先要分析可能的原因,才能提供相应的解决方...【详细内容】
2024-01-18  数据恢复软件    Tags:苹果微信   点击:(65)  评论:(0)  加入收藏
站内最新
站内热门
站内头条