obb是一个固定路径的可读写文件，下载新版本替换不就行了

obb是一个固定路径的可读写文件，下载新版本替换不就行了

你测试可行？？？

最简单的，把x86库删了，首包大小自己减减，其他全走热更，就不用obb了

最简单的，把x86库删了，首包大小自己减减，其他全走热更，就不用obb了

你就是没出海吧。。母的不是减包。。
而是利用谷歌的obb下载启动减少更新。快。

唉，现在的人，不把别人踩一下都不舒服
我知道obb怎么回事， 我们项目上过台湾
也支持过网友用我说的方式上过线，可行吗， 也可行
用不用随你，我需要证明什么么， 好像也不需要

唉，现在的人，不把别人踩一下都不舒服
我知道obb怎么回事， 我们项目上过台湾
也支持过网友用我说的方式上过线，可行吗， 也可行
用不用随你，我需要证明什么么， 好像也不需要

😔忽略前一句。
意思就是说现在出海，用户下载直接如果利用obb就完整包了啊。 就是不想走自己的热更再让用户下载。会影响转化率。

PS 没有说要证明什么，目前库是可行，只是看了下回复都不是回答命题。

好吧，回到之前的问题， so库有组装zip的逻辑
原来的方案是apk+patch+so = new apk
可能的solution是apk + obb + patch + so = new apk
如果Unity不支持一个new apk，就退化成（apk + apk_patch + so) + (obb + obb_patch)

印象中，我们当年obb也走了cdn，没走google的下载链接

好吧，回到之前的问题， so库有组装zip的逻辑
原来的方案是apk+patch+so = new apk
可能的solution是apk + obb + patch + so = new apk
如果Unity不支持一个new apk，就退化成（apk + apk_patch + so) + (obb + obb_patch)

印象中，我们当年obb也走了cdn，没走google的下载链接

表示我没脑子思考了。。。只求有个具体的方案。。。demo

好吧，回到之前的问题， so库有组装zip的逻辑
原来的方案是apk+patch+so = new apk
可能的solution是apk + obb + patch + so = new apk
如果Unity不支持一个new apk，就退化成（apk + apk_patch + so) + (obb + obb_patch)

印象中，我们当年obb也走了cdn，没走google的下载链接

public static string AndroidInstallFolder
        {
            get
            {
                //Get Activity then Context
                AndroidJavaClass unityPlayer = new AndroidJavaClass("com.unity3d.player.UnityPlayer");
                AndroidJavaObject currentActivity = unityPlayer.GetStatic<AndroidJavaObject>("currentActivity");
                AndroidJavaObject unityContext = currentActivity.Call<AndroidJavaObject>("getApplicationContext");
                string p = unityContext.Call<string>("getPackageResourcePath");
                return p;
            }
        }

花了点时间研究，可以固定读取这个安装路径。就可以避免unity的接口获取的路径不一样。（因为热更下载ab可能是调用unity接口的话。设置给启动目录就行。