- 强制杀进程关掉idea
- 找到目录
C:\Users\Administrator\AppData\Local\JetBrains\IdeaIC2021.2 - 删掉
index和caches目录 - 重新启动idea
adb调试安卓项目，运行时获取PlayerPrefefs缓存
- 反编译APK文件
- 修改文件目录中的AndroidManifest.xml文件，在
标签中添加android:debuggable="true"属性 - 回编apk，对齐align，重签名
- 运行app
- 执行
adb shell run-as <package_name> cat shared_prefs/<package_name>.v2.playerprefs.xml
使用 AlphaSSL 泛域名证书
AlphaSSL
AlphaSSL证书是全球著名SSL证书颁发机构GlobalSign旗下的信息安全产品，是专业的SSL证书提供商，专业提供便宜SSL证书
支持的SSL证书类型较为单一
AlphaSSL证书属于入门级SSL证书，目前仅支持域名验证(DV SSL证书)，所以价格便宜，通常一年只要几百元，便可为个人网站提供最基本的安全保护。
审核简单、签发速度快
AlphaSSL证书按照网站保护域名数量不同，有单域名证书和通配符证书可供选择，申请流程很简单，CA机构只需验证域名所有权，域名验证通过后CA便会签发证书。
此外，AlphaSSL证书除了价格便宜之外，还带有兼容性强、强大的加密功能的优点。所有流行的浏览器和移动设备都可以识别AlphaSSL证书。AlphaSSL证书是从2048位的GlobalSign根证书颁发的，该证书是世界上运营时间最长，最受信任的权威之一，同时还将在客户和网站之间获得256位加密强度，这是当今使用率最高的加密强度。
通过上文介绍，目前AlphaSSL证书仅有DV SSL证书可选，如果是企业网站的话，还是选GlobalSign旗下品牌的安全级别高的企业型OV SSL证书或增强型EV SSL证书，以加强网站信息安全保护。
购买一个Token
申请流程参考
Unity中ab包压缩方案 LZMA 和LZ4
LZMA
1.LZMA采用流压缩方式（stream-based），压缩率会比LZ4更高，体现在包体更小，但是问题也很严重。LZMA只支持顺序读取，所以加载AB包时，需要将整个包解压，会造成卡顿和额外内存占用。这也是为什么在有些复杂UI上首次打开会造成卡顿。
2.加载AB包后将所有资源进行了缓存，导致了如果AB包资源利用率在短时间利于率不高的时候，造成了很高的内存浪费。
3.一套引用计数规则非常复杂，当资源过多的时候建立引用关系都是很费时的，其中的常驻包的设置逻辑也是非常具有不确定性。
LZ4优化
1.LZ4采用块压缩方式（chunk-based），块压缩的数据被分为大小相同的块，被分别压缩，虽然压缩率不及LZMA，但是读取效率比LZMA高非常多
2.LZ4压缩的AB包，使用LoadFromFile()或LoadFromStream()只会加载AB包的Header，相比于直接加载解压整块AB包，效率更进一步提高。另外一个很重要的点，由于可以只加载Header，因此AB包可以做到一旦加载到内存后就再不卸载，此时只需要管理从AB包中读取出来的资源的生命周期。
3.对于之前使用引用计数的优化，由于Unity原本资源管理就是使用引用计数去维护，这里再建立一套内部的引用计数，不仅多余而且很浪费CPU资源，而且效果不一定很好。这个时候我们可以建立一套弱引用管理体系，通过弱引用去持有资源，在触发Resource.UnloadUnusedAssets()再去清除弱引用失效的对象。
将LZMA的压缩方式修改为LZ4
将打包参数添加BuildAssetBundleOptions.ChunkBasedCompression即可
BuildAssetBundleOptions buildOption = BuildAssetBundleOptions.IgnoreTypeTreeChanges | BuildAssetBundleOptions.DeterministicAssetBundle | BuildAssetBundleOptions.ChunkBasedCompression; LZ4读取AB包 //读取ab包 AssetBundle.LoadFromFileAsync(url) 这里需要注意一点的就是，LoadFromFileAsync与WWW或UnityWebRequest区别在于是在windows下不需要file://前缀
原文链接：https://blog.csdn.net/qq_38721111/article/details/129184791
谈一谈Unity 的 Scriptable Build Pipeline
Unity的Scriptable Build Pipeline (SBP) 提供了一种更灵活的构建方式，以package 的形式提供，将一些常用的构建类和接口从C++层移动到了C#层。，与传统的构建接口不同，SBP在构建时并不会生成manifest,而是会在library下生成缓存，实际首次构建时长会比buildpipeline慢一些，但如果再次调用构建接口，就会使用缓存来增量构建，减少构建时长。除此之外，SBP在构建完成后会在AB包目录输出构建步骤的耗时的详细信息和耗时日志，可以用Trace Event Profiling Tool打开， 方便profiler不同的构建步骤。Unity的Scriptable Build Pipeline (SBP) 提供了一种更灵活的构建方式，以package 的形式提供，将一些常用的构建类和接口从C++层移动到了C#层。，与传统的构建接口不同，SBP在构建时并不会生成manifest,而是会在library下生成缓存，实际首次构建时长会比buildpipeline慢一些，但如果再次调用构建接口，就会使用缓存来增量构建，减少构建时长。除此之外，SBP在构建完成后会在AB包目录输出构建步骤的耗时的详细信息和耗时日志，可以用Trace Event Profiling Tool打开， 方便profiler不同的构建步骤。
以下是个人总结的一些SBP的优点与缺点。
优点：
良好的设计接口,能更灵活的控制构建过程，例如深度定制AB包构建内容，指定单个Ab包压缩格式、依赖查找回调等。 将构建任务粒度拆分更细，例如压缩、打图集、编译脚本，文件系列化等。为构建并行化为了准备 使用BuildCache，加快构建速度，不同构建机之间可以共享同一份BuildCache 构建更细粒度的步骤profiler
缺点：
Task的设计看起来很美好，但大部份任务并不支持并行化，自定义task的可行性比较低 增量构建不完善，依然有bug,使用buildcache后bug会传播到其它构建线 过度的设计，看似提供了更灵活的接口，实则很难正确的实现这些接口，比如看似可以通过IBundleBuildContent的BundleLayout来控制每个ab包的内容，但由于unity的依赖关系很难从上层应用通过Unity提供的接口计算正确，所以从上层来控制每个ab包的内容基本上不可能 单个ab包的压缩格式通过回调来指定的做法比较不合理，这样做需要用字典来存储每个ab包压缩格式，增加了额外内存和构建时长，同时这样的代码写起来也比较麻烦。一种比较简单的做法是在AssetBundleBuild中增加一个压缩格式参数 Build Cache在Library下占用硬盘空间较大