手游服务端架设教程(手游服务端源码修改)

03 开荒时代

这段代码看似没啥问题，但是却忽略了SimpleDateFormat是个线程不安全的类，所以这就会引起坑。

前面介绍了在插件编译时，给 java 代码中插入了一些逻辑，实现了插件动态根据宿主环境获取资源 id 的效果。但是 xml 编译完之后，资源 id 都直接编译成了数字，xml 中也无法插入逻辑，因此我们只能在插件运行前，根据宿主环境进行修改。

资源固定提高了宿主接入框架的成本。

这些变量的名称，根本读不出来，更别说实际意义了。

优势:

说完业务功能当中碰到的挑战，我们接下来看一下系统承载带来的挑战。虚幻引擎DS一个进程只能承载一个场景。而且因为它要模拟的内容很多，单个进程的资源开销也是偏大的，因为MMO中场景的数量很多，最终也导致进程数量也会很多。

简单介绍 Android 插件化中资源部分的动态化。

好的代码格式应当遵守以下几点：

必须把宿主的所有资源都进行固定。如果只固定插件使用的资源，当一个宿主有两个插件时，两个插件各自给宿主固定自己需要的资源，在代码合并时，很容易引发冲突，因为资源固定的值是不允许重复的；

云编译系统是一个编译集群，每次一个编译记录只能占用一台主机，是否可以把一些比较耗时长的任务拆分到其他空闲机器协同来编译，然后再回传编译结果。

此时就很容易看懂if的逻辑了

实际项目中分组为21个，一般情况下，开发同学只是修改局部部分文件，再次编译的时候，只有其中1-2个分组有变动，只需要重执行有过变动的分组即可，提高了执行效率。

SonarLint 对问题分成了三种类型

那么为什么 libTest 方法中是通过 field 引用，而 appTest 中就变成数字了呢？

自定义共享缓存

《晶核》的ARPG属性导致我们需要开发的技能机制非常的复杂，我们现在有8个转职之后的职业，每个职业有二十多个各具特色的技能。而且还需要考虑移动、跳跃和位移技能、空中战斗结合在一起的情况，在开发的时候碰到了和位移相关的很多问题。接下来通过一个视频给大家简单展示一下《晶核》中的技能机制。

那么，假设宿主中有一张图片名为 icon，直播插件中的 xml 通过 @drawable/icon 引用了这张图片，同时也在代码中通过 R.drawable.icon 引用了它，实际直播插件中是没有 icon 这张图片的，它存在于宿主中。宿主编译完后，按照前面的知识点，宿主中的 icon 对应的数值被编译成 0x7f010001。

实操过程中发现大部分情况文件越大 dex 执行时间越长，网络传输是有损耗的，所以并不是所有的 dex 操作都值得分发到远程，只有超过一定阈值的时候，才会分发到远程。

所以一般推荐使用聚合/组合代替继承。

设计一个接口：

不过这个修改方式也有一个问题，因为每修改一次GTranslate插件的语言设置都会重置代码，所以大家在修改之前一定要先确定好需要使用的的语言，然后保存，保存好后再参考上面的代码修改。

前期只同步自己

除了以上四类挑战以外，我们还碰到了一些其他的挑战。比如说在大地图长期存在一段时间之后，我们发现玩家走动的时候总会有一些拉拽的情况。通过分析之后发现是因为float类型的时间戳在描述时间的时候，连续运行超过4个多小时之后，它的时间精度已经描述不了毫秒级别的精度了，会出现时间精度上的损失。最终反映在移动计算的时候，就会出现计算出来的移动位移有偏差，最终导致拉拽的情况。发现这个问题之后，我们就对时间精度进行了扩展。把游戏当中所有时间精度相关的字段都从 float 扩展到了 double， 彻底解决了这个问题。

10人群密度

有了这俩插件，看谁还能说我代码写的不规范了。

下载三方 aar；

SonarLint 插件可以帮助我遵循最佳实践和标准。编写符合标准和最佳实践的代码可以确保应用程序的质量和可靠性。 SonarLint 插件可以检测代码中的违反规则的地方，例如不安全的类型转换、未使用的变量和方法、不正确的异常处理等等。通过使用 SonarLint 插件，可以学习如何编写符合最佳实践和标准的代码，并使代码更加健壮和可靠。

Apk 其实就是一个 zip 文件，修改 apk 中的文件内容，首先想到的最简单的方法就是读取 zipFile 里面的文件，修改之后重压缩。

确定了修改时机和修改内容，接下来就要详细介绍怎么修改这些文件了。

上面的代码，只需要使用yaml.safe_load()方法，读取department_list.yml文件中的数据，分别传入到用例 test_department_list() 方法中完成输入与结果的验证。

java 代码在编译成 class 之后，对于引用宿主资源 id 的代码，有的会编译成数值，有的依旧是通过 R 引用。对于后者，我们可以很容易找出来，对于前者就有些困难了，因为单纯去扫描 class 中 0x7f 开头的数字，很容易误判，把一个无意义的数字也当作资源 id 处理。

经过一段时间观察，目前功能稳定，有效的的解决dex执行缓慢问题，同时整体编译速度维持在正常水平。

左侧是对各个文件的分析结果，右侧是对这个问题的建议和修改示例。

前文一直在说 xml 中使用的宿主资源，看上面这个配置文件发现 fileNames 中怎么会有 resoureces.arsc ？它明明不是 xml 文件？