###
NativeAddon其实简单到每个人都可以写，但它难就难在深，深入下去所需的知识储备量是巨大的。你想要了解的更多，想获得更好的效果，就需要对其深入，而你所面对的一切，都是未知的，这就是问题之所在。
所以开发过NativeAddon的人大多都明白，在没有任何文档或是注解的情况下正确使用一条函数是多么的困难，NativeAddon可以说得上是所有插件类型当中最玄学的插件了，而且一个NativeAddon能否开发成功甚至还包含着运气的成分，当然其自身实力依旧重要，了解很多设计或架构模式能够有利于你更为清晰的分析MinecraftPE的本质，以便于你能够正确使用MinecraftPE的方法。
###

【梳理逻辑】
开发NativeAddon时的思考方式和ModPE完全不同，NativeAddon是建立在hook这一概念之上的，所以很多时候在编写NativeAddon时，你只需要考虑hook。那么，如何对MinecraftPE原有的一条函数进行hook以达到我们的目的呢？
这时候就需要用到substrate库了，实际上我们只会用到它里面的MSHookFunction，具体来说是template <typename Type_>
static inline void MSHookFunction(Type_ *symbol, Type_ *replace, Type_ **result)，通过观察它的参数命名易知想要对一条函数进行替换我们需要这条函数的原地址，将它替换的函数地址，以及一个原函数的函数指针来作为容器保留原函数，实际上最后这一个参数是可以省略的，它将会默认保留为NULL。

然后编写我们用于替换的函数，其中有一个很简单的逻辑用于判断输入的标签(版权文字的标签即是menu.copyright)，当请求的标签符合我们的要求时，返回字符串"©Mojang AB / San Angeles"，这条函数就结束了，而当标签不满足"版权文字"时，就返回原有字符内容，这也是为什么需要一个效果和原函数完全相同的函数指针。
static std::string hook_getI18nText (std::string const& input)
{
if (input == "menu.copyright")
return "©Mojang AB / San Angeles";
return base_getI18nText(input);
}
到这里已经不难想象出效果，即主界面原有的文字"©Mojang AB"被修改成了"©Mojang AB / San Angeles"。

纯代码:
#include <string>
#include <dlfcn.h>
#include "substrate.h"
static std::string (*base_getI18nText)(std::string const&) = nullptr;
static std::string hook_getI18nText (std::string const& input)
{
if (input == "menu.copyright")
return "©Mojang AB / San Angeles";
return base_getI18nText(input);
}
JNIEXPORT jint JNI_OnLoad(JavaVM* vm, void*)
{
void* handler = dlopen("libminecraftpe.so", RTLD_LAZY);
MSHookFunction(dlsym(handler, "_ZN4I18n3getERKSs"), (void*)& hook_getI18nText, (void**)& base_getI18nText);
return JNI_VERSION_1_6;
}

我们可以看到代码量其实并不大，在某些功能的实现上甚至比ModPE还要小巧简单。
最后将其编译，加载进游戏当中，我们就能看到如下图所示效果。

帮顶

我还是学了c++再来吧

柯基奇天下无敌！ᕕ( ⁰ ▽ ⁰ )ᕗ

罕见大佬复活

不错正好在学C++

支持！

极地喵老婆

有点印象，是不是又换id了

支持一下吧，貌似很久没有像这样的技术贴了