企业网站设计与优化,wordpress投稿者查看评论,博物馆 网站 建设,dchaser wordpress01 概览
在APP的开发中#xff0c;磁盘管理已成为不可忽视的部分。随着功能的复杂化和数据量的快速增长#xff0c;如何高效管理磁盘空间直接关系到用户体验和APP性能。本文将结合磁盘管理的实践经验#xff0c;详细介绍iOS沙盒环境下的文件存储规范#xff0c;探讨业务缓…01 概览
在APP的开发中磁盘管理已成为不可忽视的部分。随着功能的复杂化和数据量的快速增长如何高效管理磁盘空间直接关系到用户体验和APP性能。本文将结合磁盘管理的实践经验详细介绍iOS沙盒环境下的文件存储规范探讨业务缓存、用户资产及系统缓存的清理策略。同时分享自动清理与手动清理相结合的机制展示如何在不同触发条件下合理执行磁盘清理。文章使用文心一言辅助编写。
02 磁盘系统介绍
2.1 ios沙盒系统
沙盒机制是iOS系统中的一种安全体系。每个iOS程序都有一个独立的文件系统而且只能在对应的文件系统中进行操作此区域被称之为沙盒SandBox。APP中所有文件都保存在此如文本文件、图片、图标、媒体资源、Mach-O等。主要包含4个目录 MyApp.app、Documents、Library、tmp。
MyApp.app目录包含应用程序及其所有资源即.ipa安装包解压后的.app内容仅支持只读访问。Documents目录用于存储用户生成的内容可以通过文件共享提供给用户并由iCloud备份。Library目录则用于存放非用户数据文件的顶级目录通常包含几个标准子目录如Application Support和Caches并由iCloudCaches除外备份。而tmp目录用于写入临时文件这些文件不需要在应用程序启动之间保留当不再需要时应由应用程序删除且不被iCloud备份。
2.2 获取目录API
NSSearchPathForDirectoriesInDomains()函数用于查找目录返回指定范围内的指定名称的目录的路径集合。
// 获取沙盒主目录路径
NSString *homeDir NSHomeDirectory();
// 获取Documents目录路径
NSString *docDir [NSSearchPathForDirectoriesInDomains(NSDocumentDirectory, NSUserDomainMask, YES) firstObject];
// 获取Library的目录路径
NSString *libDir [NSSearchPathForDirectoriesInDomains(NSLibraryDirectory, NSUserDomainMask, YES) lastObject];
// 获取Caches目录路径
NSString *cachesDir [NSSearchPathForDirectoriesInDomains(NSCachesDirectory, NSUserDomainMask, YES) firstObject];
// 获取tmp目录路径
NSString *tmpDir NSTemporaryDirectory();
//应用程序程序包的路径
[[NSBundle mainBundle] bundlePath];
2.3 文件存储规范
iOS项目开发中文件管理至关重要。我们结合Apple官方指导与项目实践形成了一套详细的文件使用规范。这些规范不仅遵循了iCloud备份策略还充分考虑了文件类型特性和业务需求。结合业务使用场景能够更准确地判断哪些文件是临时数据、哪些是用户生成的重要文件为后续进行磁盘监控和清理提供了便利。
MyApp.app 用途应用程序的包此目录包含应用程序Mach-O可执行文件及其所有资源iCloud默认不备份此目录。 使用规范 开发者不能写入此目录。写入此目录会影响签名导致APP无法启动。 开发者可以获得对应用程序包中存储的任何资源的只读访问权限。
Documents 用途存储用户生成的内容的顶级目录iCloud默认备份此目录。 使用规范 该目录应仅包含开发者可能希望向用户公开的文件。
Documents/Inbox 用途存储通过外部共享方式导入到APP的文件iCloud默认备份此目录。 使用规范 开发者不应自行在此目录下创建文件。 开发者可读可删将此目录中文件移出后再编辑。
Library 用途存储非用户数据文件的顶级目录iCloud默认备份此目录Caches除外。 使用规范 可以创建自定义子目录用于保存不向用户公开的任何文件。 各业务方需要创建业务相关的子目录存储数据。
Library/Caches 用途用于存放再次下载或重新生成的数据iCloud不会备份此目录。 使用规范 存放可以重新下载或生成的数据如图片缓存文件、临时文件等。 系统在系统储存不足时可能会删除该目录以释放磁盘空间。 各业务数据缓存文件应放在/Library/Caches的子目录下方便管理。
Library/Application Support 用途用于存储APP配置和数据文件iCloud默认备份此目录。 使用规范 存放程序配置和数据文件如配置文件、模板等不应存放缓存文件。 避免在此目录下创建不必要的文件以减少备份时间和存储空间占用。
Library/Preferences 用途用于存储应用程序的首选项值iCloud默认备份此目录。 存放建议 开发者不应自行在此目录下创建文件。 NSUserDefaults或CFPreferences来获取和设置APP的首选项值。
tmp 用途用于存放临时数据iCloud不会备份此目录。 存放建议 仅存放临时数据开发者应在使用完这些文件后及时删除。 系统会清除目录下文件应用程序终止后可能不存在。 不推荐业务方使用此目录存放重要数据。
2.3.1 文件命名规则 文件夹命名推荐Pascal命名法第一个字母大写。 一个业务最多3个二级路径 业务数据放在Library/下的一个目录下。 数据缓存文件放在Library/Caches的一个目录下。 用户数据放Documents/下的一个目录下。
2.3.2 iCloud备份与恢复
iCloud会默认同步Documents、Library 目录下的文件Caches子目录除外用户在设置中开启iCloud同步功能同步APP数据时会上传所有沙盒数据。如果没有按照规范创建目录会导致大量缓存文件被上传到iCloud严重占用用户iCloud 空间严重时甚至会被Apple官方警告。如果将数据写入这些目录但是又不希望同步到iCloudiOS提供了API可以排除默认同步的目录需要开发者在创建文件时主动设置。
由于无法查看iCloud备份的沙盒文件内容使用Mac本地备份的方式模拟iCloud备份行为。iPhone连接Mac打开访达选择将数据备份到Mac恢复备份。测试发现Document文件夹下的子目录和子文件属性被设置为NSURLIsExcludedFromBackupKey恢复备份后不在符合预期。不过用电脑备份和iCloud有个差异Library/Caches下的文件也会被备份。
注意此方法对于在App Store的应用即使在恢复备份前将APP删除也会在恢复备份后自动下载APP并且恢复数据。对于不在App Store的应用比如我们的测试DemoAPP在恢复备份前不要删除DemoAPP否则无法查看效果。因为无法下载不在Appstore的APP安装包所以备份内容也无法还原。测试APP在恢复备份后重新安装就可以查看完整的沙盒文件。 API设置对于性能的损耗 iPhone12 总计 14780 个文件总计耗时 1124.180794 ms平均每次耗时0.076ms iPhone6p总计 11650 个文件总计耗时 3730.319023 ms平均每次耗时0.32ms NSURLIsExcludedFromBackupKey不需要每次使用目录或文件时都调用只需要设置一次即可。设置属性后该目录下所有子目录和文件都不会同步到iCloud但是子目录和文件的属性NSURLIsExcludedFromBackupKey依旧为NO。 创建文件URL时需要调用[NSURL fileURLWithPath:] 然后获取和设置 NSURLIsExcludedFromBackupKey。
NSURL *pathurl [NSURL fileURLWithPath:path];
BOOL success NO;
success [pathurl setResourceValue:(YES) forKey:NSURLIsExcludedFromBackupKey error:nil];
2.4 磁盘大小计算方式
在系统中可以查看一个APP占用磁盘大小iPhone 存储空间通常由APP 大小和文稿数据大小组成。getResourceValue:forKey:error: 或者attributesOfItemAtPath:error: 直接获取的是“文件大小”不是文件占用的磁盘物理空间。计算文件的磁盘占用大小需要通过磁盘块的方式。标准头文件stat.h的st_blocks可以获取到块的数量st_blocks * 512计算出文件的磁盘占用大小。 扇区block是磁盘读写的最小物理单位。之所以扇区大小是 512 字节这种做法源自较早的磁盘扇区大小标准。这种设计是基于早期磁盘技术的物理限制尽管现代硬盘的物理扇区大小可能已经增加到了 4096 字节但 512 字节的逻辑块大小在许多文件系统和操作系统的接口中仍然被保留。iOS系统存储单位为十进制且保留有效小数机制为四舍五入。 (unsigned long long)fileSizeOnDisk:(nonnull NSString *)filePath {
struct stat fileStat;
int res stat([filePath cStringUsingEncoding:NSUTF8StringEncoding], fileStat);
if (-1 res) {
return 0;}
long long fileSize fileStat.st_blocks / 8 * fileStat.st_blksize;
return fileSize ;
}
2.5 APP包大小
APP包大小是手机沙盒的重要组成部分包体积直接影响用户转化率。用户可以在iPhone存储空间设置中查看设备上各APP大小和文稿与数据大小。
百度APP在iOS17系统的iPhone存储空间设置中系统不显示APP大小只有文稿与数据大小。经过调研发现在iOS17系统APP使用ODR功能后会导致APP大小被计算到了iOS系统数据。推测是iOS17系统BUGiOS18系统已经恢复正常。
03 磁盘清理
在综合性 APP 的开发中多个业务方共同使用沙盒空间磁盘缓存的管理面临诸多挑战。每个业务方对磁盘使用的整体感知较弱难以准确评估自身的空间占用大小是否合理磁盘占用很容易出现无限增长的问题。同时不同业务方可能独立设计了缓存清理策略缺乏统一规范难以满足统一管理的需求。
为解决这些问题从全局出发设计一套高效的磁盘清理方案。这套方案结合自动清理与手动清理的机制对磁盘使用进行统一管理。自动清理负责监测磁盘占用情况通过设置清理阈值和判断条件在空间不足时通知或触发业务方执行清理操作。清理范围以业务缓存为主支持按业务个性化配置清理规则确保管理灵活高效。手动清理则面向用户提供简单直观的操作界面允许用户自主选择清理范围管理下载文件等数据从而平衡自动化与用户自主权。
此外在iOS平台上系统本身具有定期清理临时文件和部分缓存内容的机制。设计磁盘清理方案时合理利用这些系统行为同时避免依赖其不可控性。通过以上策略可以在确保磁盘空间高效管理的同时最大限度地保障用户体验为综合性APP提供可靠的存储管理支持。 3.1 自助清理
3.1.1 业务限额
为了管理和规范业务方对磁盘的使用根据业务的使用场景和必要性评估每个业务方需要使用的磁盘空间每一个业务占用的缓存大小会被分配一个限额业务需要保证自身缓存占用限制在限额以下。业务方从磁盘组件获取业务自身限额值保证自身缓存占用在限额以内而磁盘组件会从磁盘剩余大小、APP已使用大小、业务使用频率等条件实时分配合适的限额给各个业务方。
3.1.2 磁盘等级
根据设备的剩余磁盘空间与应用程序所占用的磁盘空间大小我们可以将磁盘状态细分 为Normal、Warning、以及Critical三个等级每个等级都反映了用户磁盘空间的使用状况。当处于Normal时表明用户的手机尚拥有充裕的剩余空间且APP所占用的磁盘空间相对较小。在此情境下我们可以适度增加分配给各个业务方的限额使得业务方有机会缓存更多内容从而实现以空间换取时间的性能优化进一步提升用户体验。
然而一旦进入Critical等级意味着用户的手机剩余空间已所剩无几或是 APP占用了过多的空间。这种情况下用户的手机很容易出现卡顿现象甚至面临存储空间告急的困境。更为严重的是这可能会迫使用户做出卸载APP的极端选择。因此在Critical等级下我们必须对业务方使用磁盘空间的行为进行严格限制并强制要求业务方彻底清理任何不必要的缓存以确保用户的手机能够维持基本的运行需求。
3.1.3 状态检测
磁盘状态检测是磁盘组件的核心功能检测 APP 运行期间设备磁盘的使用情况判断是否需要触发自动清理操作。APP 启动后周期性的执行磁盘使用状态检查自动触发相应的清理机制。通过不同条件触发磁盘清理以优化应用性能并提升用户体验。为此设计了多种触发清理机制的机制确保不同情况下都能触发清理操作
等级根据磁盘使用等级的变化来决定是否清理
版本如果应用版本发生升级会强制业务方执行一次清理。 时间根据磁盘等级设定兜底的定期清理间隔。
3.1.4 触发清理
业务方在各自的组件中注册磁盘清理回调protocol不同的业务模块能够响应磁盘等级变化并进行相应的处理实现了磁盘清理服务与业务模块之间的解耦合。业务在收到磁盘状态等级变化时重新查询业务限额并调整自身策略管控和优化自身占用缓存保证保证自身缓存占用在限额以内。
磁盘组件会逐一调用各业务模块注册的清理回调通过protocol抽象各模块的清理逻辑实现了对多业务模块的统一管理和扩展性支持。结合信号量机制实现同步等待确保每个模块的清理任务按顺序完成。所有清理任务完成后磁盘组件会触发全局回调进行状态更新。
3.2 手动清理
手动清理沿用自动清理的设计思路业务方实现清理协议注册到磁盘组件然后由磁盘组件统一管控。和自动清理不同的是手动清理提供了一个用户可视化页面并且详细列出可清理的内容供用户选择。支持深度清理在大多数情况下业务逻辑要求清除所有缓存数据。除此之外还另外添加了用户资产管理功能。
3.2.1 用户资产管理
用户资产定义为用户自主下载并保存的各类文件包括但不限于视频、图片、安装包、PDF 文档、Excel 表格以及 Word 文件等。百度APP是一个综合性 APP 兼具浏览器的功能。用户在浏览网页的过程中会下载各种内容。特别是在 iOS 设备上用户还可能会下载一些无法安装的安装包。尽管这些文件是用户主动下载的但实际上它们可能并无实际用途且长期占用用户的磁盘空间。用户资产管理模块可以帮助用户轻松地识别并清理那些不再需要或无效的用户资产从而有效释放存储空间提升设备的整体性能。
3.3 系统缓存清理
3.3.1 tmp目录
iOS的tmp目录是系统缓存目录Apple官方文档的说明是使用此目录写入不需要在APP启动之间保留的临时文件。当不再需要文件时APP应从该目录中删除这些文件系统也可能会在APP未使用时清除此目录。实际使用过程中发现依赖系统清理该文件夹具有不可控性因此需要对该文件夹进行清理tmp目录主要包含以下文件 1. 下载缓存文件
NSURLSessionDownloadTask进行文件下载的过程中系统为了确保数据的完整性和安全性会在文件下载完成前将其暂时保存在以.tmp为扩展名的临时文件中。这些临时文件的命名遵循CFNetworkDownload_xxxx.tmp的格式其中CFNetworkDownload_是固定的前缀而后续的xxxx部分则根据每个下载任务的不同而有所区别。
NSURLSessionConfiguration配置会导致这些临时文件被存储在沙盒的不同位置。defaultSessionConfiguration创建的下载任务其临时文件会被保存在沙盒的tmp文件夹内。backgroundSessionConfiguration临时文件的存储位置则有所不同。在后台下载模式下为确保即使应用进入后台下载任务也能继续进行。这些文件会存放在Library/Caches/com.apple.nsurlsessiond/Downloads/bundle_id。
然而需要注意的是沙盒中的tmp文件夹主要用于存放临时文件这些文件在磁盘空间不足时可能会被系统自动清理。因此如果下载任务被取消且临时文件没有被及时移动到其他安全的存储位置它们可能会因为 tmp 文件夹的清理机制而被删除。这将导致用户无法从上次中断的位置继续下载即无法实现断点续传。
2. tmp目录清理
统计tmp目录下可以被清理的文件可以选择全部清理也可以按照业务实际应用场景选择过期清理等方案。
/// 统计 /tmp 目录下需要清理的缓存文件(NSArrayNSURL * *)calculateTmpSysCache {
// 匹配文件名的模式
NSArray *regexPatterns [CFNetworkDownload, WKWebFileUpload, NSIRD_ 正在存储文稿];
NSString *tmpPath NSTemporaryDirectory();
if (!tmpPath) return [];
NSMutableArray *tmpNeedCleanCache [NSMutableArray array];
NSFileManager *fileManager [NSFileManager defaultManager];
for (NSString *fileName in [fileManager enumeratorAtPath:tmpPath]) {
NSString *fullPath [tmpPath stringByAppendingPathComponent:fileName];
NSURL *fileURL [NSURL fileURLWithPath:fullPath];
// 检查是否符合清理条件
if ([self shouldCleanFile:fullPath patterns:regexPatterns]) {[tmpNeedCleanCache addObject:fileURL];}}
return tmpNeedCleanCache;
}
3.3.2 WKWebView清理
WKWebView是iOS和MacOS上用于加载和展示网页内容的控件它利用了多种缓存机制来提升加载速度和用户体验。以下是WKWebView缓存产生的几个主要原因 资源缓存HTTP 缓存WKWebView会缓存通过网络请求加载的网页资源如 HTML、CSS、JS、图片等以减少重复下载提升网页的加载速度。这些资源通常存储在本地磁盘上。 Cookie 缓存网站使用的Cookie会被WKWebView缓存用于维护会话状态、用户登录信息等。 Session Storage和Local StorageWKWebView支持HTML5的sessionStorage和localStorage用于本地存储网站数据以便后续访问时能够直接从缓存中读取而无需重新下载。 WebKit CacheWebKit内部缓存WebKit内部有一套复杂的缓存系统用于管理各种网页资源、脚本、图像等的缓存。WKWebView依赖这些机制来加速网页内容加载。 Service Workers和离线缓存一些网页使用Service Workers来实现离线功能或加速加载特定资源WKWebView会缓存这些资源以便在后续使用时能够从本地获取。
1. WKWebView缓存清理方法
清理指定数据类型的缓存通过WKWebsiteDataStore可以清理特定类型的缓存比如Cookies、缓存、localStorage等。该方法可以清理指定类型的缓存数据并支持自定义时间范围。以下代码展示了如何清理WKWebView的缓存数据
// 获取所有类型的缓存
NSSet *websiteDataTypes [NSSet setWithArray:[
WKWebsiteDataTypeCookies, // Cookie
WKWebsiteDataTypeLocalStorage, // localStorage
WKWebsiteDataTypeIndexedDBDatabases, // IndexedDB
WKWebsiteDataTypeWebSQLDatabases, // WebSQL
WKWebsiteDataTypeFetchCache, // Fetch API
WKWebsiteDataTypeDiskCache, // 磁盘缓存
WKWebsiteDataTypeMemoryCache, // 内存缓存
WKWebsiteDataTypeOfflineWebApplicationCache // 离线应用缓存
]];
// 获取过去时间的日期比如一个月前
NSDate *dateFrom [NSDate dateWithTimeIntervalSince1970:0];
// 清理特定类型的数据
[[WKWebsiteDataStore defaultDataStore] removeDataOfTypes:websiteDataTypesmodifiedSince:dateFromcompletionHandler:^{
NSLog(清理缓存完成);
}];
清理指定域名的数据如果只想清理某个特定网站的缓存可以通过查询 WKWebsiteDataRecord 来实现
// 获取指定域名的数据
[[WKWebsiteDataStore defaultDataStore] fetchDataRecordsOfTypes:[WKWebsiteDataStore allWebsiteDataTypes]completionHandler:^(NSArrayWKWebsiteDataRecord * *records) {
for (WKWebsiteDataRecord *record in records) {
if ([record.displayName containsString:example.com]) { // 指定域名[[WKWebsiteDataStore defaultDataStore] removeDataOfTypes:record.dataTypesforDataRecords:[record]completionHandler:^{
NSLog(清理 % 的缓存完成, record.displayName);}];}}
}];
2. WKWebView清理实践
在WKWebView的清理实践中先计算NetworkCache文件夹的大小一旦超过设定的限制即会触发清理流程。在清理过程中为了保证缓存带来的性能优化和磁盘空间占用达到平衡我们并没有选择全部删WKWebView的所有缓存而是按照文件的修改日期进行排序确保最老的文件在后续的清理中会被优先处理。 (void)cleanUpWKWebViewCacheWithLimit {dispatch_after(dispatch_time(DISPATCH_TIME_NOW, (int64_t)(NSEC_PER_SEC * SOME_DELAY)), dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
// 设置缓存上限为10MB
unsigned long long cacheLimit SOME_CACHE_LIMIT;
// 获取WebKit网络缓存目录
NSString *networkCachePath [NSHomeDirectory() stringByAppendingPathComponent:/Library/Caches/WebKit/NetworkCache];
// 计算缓存总大小
unsigned long long totalSize [self calculateDirectorySize:networkCachePath];
if (totalSize cacheDiskLimit) {
return;}
// 获取Records子目录路径
NSString *networkCacheRecordsPath [networkCachePath stringByAppendingPathComponent:/Version 16/Records];
// 获取所有文件列表安时间排序判断需要清理的文件
NSArray *filelist [self listFilesInDirectory:networkCacheRecordsPath];
if (filelist.count 0) {
return;}
if (available(iOS 9.0, *)) {
dispatch_async(dispatch_get_main_queue(), ^{
WKWebsiteDataStore *dataStore [WKWebsiteDataStore defaultDataStore];
NSSet *dataTypes [NSSet setWithArray:[WKWebsiteDataTypeDiskCache]];[dataStore removeDataOfTypes:dataTypes modifiedSince:SOME_DAY_AGO completionHandler:^{
// 清理完成}];});}});
}
3.3.3 dyld缓存清理
dyld是iOS和MacOS系统中的一个关键组件负责在程序启动时加载和链接动态库如框架和共享库。在iOS 13及更早版本中dyld可能会在tmp目录下创建一些临时缓存文件用于加速后续的程序启动过程。这些缓存文件包含了动态库的加载信息使得系统在下次启动相同程序时能够更快地找到并加载所需的库。
然而iOS13系统之前会在每次APP升级后的首次启动生成一个新的dyld缓存保存在tmp/com.apple.dyld并且之前的APP版本的dyld缓存也不会自动删除。该部分缓存会随着版本升级不断累加需要管理这部分缓存实际上还有部分用户从 iOS13 系统升级到更高系统这部分缓存就会一直遗留在用户手机中高达上百 MB。iOS14 系统则是迁移到了Library/Caches/com.apple.dyld且系统会自动清理。
/// 清理iOS13系统生成的tmp/com.apple.dyld缓存文件(void)cleanTmpDyld {
NSString *tmpDyldPath [NSHomeDirectory() stringByAppendingPathComponent:tmp/com.apple.dyld];
if ([[NSFileManager defaultManager] fileExistsAtPath:tmpDyldPath]) {
// 系统版本大于iOS14
if (available(iOS 14.0, *)) {[PFMDiskSizeUtils cleanupDirectoryAtPath:tmpDyldPath];} else {
// 保留计数限制为 1,保留最新的[PFMDiskSizeUtils cleanDiskCaches:tmpDyldPath reservedCountLimit:1];}}
}
3.3.4 其他系统缓存清理 Documents/Inbox是iOS应用接收文件的默认目录直接清理即可 Library/Preferences目录下属于应用的临时 .plist 文件。这些文件通常由 NSUserDefaults自动生成有时在写入或更新过程中会生成临时文件。
/// 清除 Documents/Inbox 目录(void)cleanUpInboxPath {
NSString *inboxPath [NSHomeDirectory() stringByAppendingPathComponent:/Documents/Inbox];
if (inboxPath) {[PFMDiskSizeUtils cleanupDirectoryAtPath:inboxPath];}
}/// 清除 Library/Preferences/bundleId.plist.xxxx文件(void)cleanUpUserDefaultsTempPlistFiles {
NSString *preferencesPath [NSHomeDirectory() stringByAppendingPathComponent:/Library/Preferences];
NSDirectoryEnumerator *dirEnumerator [[NSFileManager defaultManager] enumeratorAtPath:preferencesPath];
NSString *deleteFilePrefix [[[NSBundle mainBundle] bundleIdentifier] stringByAppendingString:.plist.];
NSString *file;
while (file [dirEnumerator nextObject]) {
if ([file hasPrefix:deleteFilePrefix]) {
NSString *deleteFilePath [preferencesPath stringByAppendingPathComponent:file];
NSDate *fileModifyDate [[[NSFileManager defaultManager] attributesOfItemAtPath:deleteFilePath error:nil] objectForKey:NSFileModificationDate ];[PFMDiskSizeUtils cleanupDirectoryAtPath:deleteFilePath]}}
}
04 总结
本篇文章围绕百度APP的磁盘清理问题从iOS沙盒文件存储机制出发系统性地阐述了磁盘管理的重要性和技术实现。文章探讨了自动清理与手动清理的结合策略通过多维度触发机制和灵活的用户交互设计平衡了系统性能与用户体验。后续我们还会分享磁盘监控和磁盘异常问题治理相关的文章。
————END————
推荐阅读
读友好的缓存淘汰算法
如何定量分析 Llama 3大模型系统工程师视角的 Transformer 架构
微服务架构革新百度Jarvis2.0与云原生技术的力量
技术路线速通用飞桨让京剧人物照片动起来
无需业务改造一套数据库满足 OLTP 和 OLAPGaiaDB 发布并行查询能力
