这是一个创建于 123 天前的主题，其中的信息可能已经有所发展或是发生改变。
本人是小公司安卓开发一枚，平时地位低微，边缘业务，最近老板接了个活临时需要安卓协助，具体内容是和 u3d 交互，实现音视频的断点续传，要求必须是安卓原生开发的，不能有任何第三方框架，u3d 之前已经写好了，但是客户不认同，要求必须由安卓原生实现，所以请教诸位大佬，有提前踩过坑的吗？我要了 5 天工时，昨天已经过了一天还没什么思路。被采纳必定请大佬喝 Manner
18 条回复 • 2024-08-28 17:16:55 +08:00
 |
1
LLaMA2 123 天前
描述不够明确
打回重写 |
 |
2
iOCZS 123 天前
那就是要用 OpenGL ES 这种底层 API ？
|
 |
4
rainywinter 123 天前
unity3d 原生不是 c#？
|
 |
6
chenjiajia9411 123 天前
|
 |
7
chashao 123 天前
类似这种 c#调用 java 吧？你可以用 unity 先新建个 example 项目，然后在项目里调通下载流程，最后把这个项目给你们的 unity 同事参考就行 https://blog.csdn.net/u014361280/article/details/107692986
 虽然我们项目用的是自研游戏引擎，但是应该也是差不多，由中台的同事提供下载 sdk （ java ）我们在游戏客户端里 jni 调用。 |
 |
8
xmai 123 天前
安卓端使用 RandomAccessFile 进行文件的读写，手搓一个文件分片实现一个简单的传输协议支持下断点续传，u3d 通过使用 AndroidJavaClass 和 AndroidJavaObject 配合可以调用几乎所有的 java 类和对象的静态方法，非静态方法，获取静态或非静态对象。
|
 |
10
ZGame 123 天前
跟 u3d 也有类似 jsBridge 的接口吧。
1.流程应该是这样 用户在 u3d 里触发下载 u3d 端 会吧下载地址,版本号等等的告诉 android 端开始下载 2.Android 获取请求,根据下载地址,版本号等等 ,先去本地数据库里查找是否有下载过,如果下载过的话,则从数据库里匹配出下载地址,断点续传默认是分片下载的 所以实际上你 android 本地应该是两张表 download_source_config (id,版本号,本地文件夹,url 下载地址下载名称,块大小,hash 校验) download_source_slice(header_id,下载块名称(类似 1.temp,状态) 然后就是根据有多少个 slice 放入队列依次下载, 每个块下载完了 之后修改表的状态,并且修改后缀, 最后所有块下载完了 将块文件合并成一个,然后转成对应文件, 修改两个表。 最后发送消息给 u3d 端 告知下载完成可以提供使用相关文件了。 要实现断点续传原理其实都不难的用 okhttp 或者其他的都可以,但是细节挺多的.. |
 |
11
waitMeOY OP |
|
13
iOCZS 122 天前
@waitMeOY 断点续传的核心是服务端支持 range 请求，前端的话你多线程构造多个 range 请求，每个下载对应的分片就好，如果下载中断，下次就要重新下载未完成的分片，下载完所有分片后，就写入一个文件里进行合并。但是我更倾向于多文件的多线程下载，而不是单文件多线程下载。这样只要顺序下载，记录每个文件的当前进度，会比较简单。
|
|
14
LLaMA2 122 天前
你 client 侧只负责下载,分段下载的核心逻辑如#13 楼所说的(range 请求),
不是你 client 操心的,你只管按要求传参数,都是 server 一侧要实现的东西 还要用到#8 楼所说的 RandomAccessFile, 最后记得计算本地文件 md5 和服务器校对是否一致 |
|
15
waitMeOY OP @iOCZS @rainywinter @LLaMA2 @chenjiajia9411 @chashao @xmai @ZGame 现在有个问题，就是下载完成之后要比源文件要小一点，但是 MD5 又是一样的，不知道是什么问题导致的。大佬们有什么思路吗
|
|
16
xmai 121 天前  1
1. 文件系统或存储差异，可能会导致文件大小的差异，但只要数据内容一致，𝑴𝑫5 校验和会相同。
2. 对下载的文件和服务器源文件进行字节级别比较文件内容，以确保下载文件与源文件完全一致。 3. 除了 MD5 ，还可以使用其他更强的哈希算法比如𝑺𝑯𝑨1 、𝑺𝑯𝑨256 来验证文件完整性。 |
|
17
waitMeOY OP @xmai 这是我问 GPT 这种现象产生的原因和消除办法，大佬看着哪种有可行性呢？
你遇到的这种情况确实有点不寻常，因为通常如果文件的 MD5 值相同，那么文件内容应该是完全一样的，包括文件大小。这里有几个可能的情况可以考虑： 下载工具或方法：使用的下载工具或库可能在处理文件结束时有特殊的压缩或编码处理，尽管这种情况比较少见。检查一下使用的下载工具或库的文档，看看是否有相关的说明。 文件系统差异：不同的文件系统有时候会对文件的存储方式有所不同，这可能会导致文件实际占用的磁盘空间有所差异，但理论上不应影响文件的实际大小。 元数据或隐藏数据：某些文件可能包含额外的元数据或隐藏数据，这部分数据可能在文件传输过程中被剥离或未被计算在内。 MD5 碰撞：虽然非常不可能，但理论上存在不同内容的文件具有相同 MD5 值的可能（即 MD5 碰撞）。不过，这种情况在实际应用中极为罕见，几乎可以忽略不计。 缓存或数据未刷新问题：有时候操作系统或某些程序可能会缓存文件信息，包括大小等，导致显示的信息未更新。可以尝试重新启动设备或清除缓存后再检查文件大小。 建议的步骤是： 确认文件完整性：再次检查下载的文件的 MD5 ，确保检查是正确的。 使用不同的工具或方法重新下载文件，看看问题是否重现。 检查和比较两个系统（源系统和目标系统）上的文件大小信息，看看是否有环境或配置上的差异可能影响到文件大小的显示。 如果可以提供更多关于下载工具和文件类型的详细信息，可能有助于进一步分析这个问题。 您说： 那有什么办法消除这种差异 ChatGPT 说： ChatGPT 要解决或消除下载文件大小与源文件不同的问题，你可以按照以下步骤操作： 验证下载方法： 检查工具/库：确保你使用的下载工具或库是最新的，并且检查是否有已知的问题或特殊的配置选项。如果可能，尝试使用不同的工具或库进行下载，比如从 cURL 切换到 wget ，或者使用专门的 FTP 客户端等。 直接下载：如果你是通过浏览器或脚本下载，尝试直接从服务器或命令行工具下载，看看是否存在同样的问题。 文件系统和格式： 格式兼容性：检查源文件系统和目标文件系统的格式，例如从 NTFS 到 FAT32 ，不同的文件系统处理文件大小和元数据的方式可能不同。 对齐设置：在某些操作系统中，文件系统的对齐方式可能导致文件占用的“磁盘空间”与实际大小不同。这通常不影响文件的实际内容，但可能会影响报告的大小。 确认文件完整性： 使用多种哈希算法：除了 MD5 ，你也可以使用 SHA-256 或其他更安全的哈希算法来验证文件的完整性。这有助于排除 MD5 碰撞的可能性（虽然非常罕见）。 文件比较工具：使用文件比较工具（如 diff, cmp ）在二进制级别比较源文件和下载文件，确保它们在内容上完全一致。 环境和配置审查： 服务器设置：检查服务器上的设置，看是否有任何压缩或处理可能影响下载的文件。 网络环境：确认下载过程中没有网络设备（如代理服务器或防火墙）对数据流进行了压缩或更改。 用户和权限设置： 文件访问权限：检查文件的访问权限设置，确保下载过程中没有权限问题导致文件数据丢失或截断。 操作系统差异：如果你在不同的操作系统间传输文件，了解这些系统可能如何不同地处理文件数据和元数据。 通过这些步骤，你可以更好地诊断和解决文件大小差异的问题，确保文件的完整性和一致性。如果问题依旧存在，可能需要深入检查具体的应用场景和技术细节。 |
Select Language