Java Android架构：守护进程还是API，JNI与否

简要描述我需要做的事情： 我修改了android框架，并创建了需要与在用户空间中运行的C语言程序通信的应用程序。这个C程序基本上是我编写的一个存根，用于与驱动程序和一堆API接口。它实际上在复杂性方面是空的，因为它仅用作隐藏机制的单个入口点，但它只有几千行长

我和我的实习导师对如何做到这一点有不同的看法：

1/应用程序和修改后的框架（客户端）使用套接字与C程序通信，C程序被转换为守护进程（服务器）。该框架不使用任何JNI，而使用java套接字，应用程序可能需要继续使用套接字的JNI实现（还没有为.apk尝试java套接字）。这已经被测试过了

2/框架和应用程序都调用C程序，使用起来有点像库。这意味着-IMO-我们要么从java“exec”（bad），要么在JNI中实现整个代码（目前为2000多行）

我有偏见的看法是： 一,/

二,/

---

安卓的正确做法是什么？有一种方法看起来比它的对应方法更优雅吗？

鉴于你认为+-，我认为你的导师支持2。你能说明原因吗？我也支持1，因为我已经完成了一个已经作为2/完成的项目，并恢复到1/（虽然不是套接字，而是命名管道，所以一些JNI毕竟留在了那里）。别误会我的意思，我喜欢JNI，但是知道它的便利性是很好的。他并不完全支持2/但是在做出选择之前他需要所有的信息。这很好，但我不能挤出比我已经做的更多，所以我需要一些帮助：D。谢谢你的反馈。

+ it's proven to work
+ there is a clear separation between low-level and high-level
+ there might be no JNI usage
+ because I use a C daemon, I can simulate the behaviour on x86 (using an environment provided by the manufacturer)
- architecture is somewhat complex
- depending on whether the .apk can use a java socket or not, the framework and the .apk won't use the exact same mechanisms to
interface with the daemon (java socket and JNI C socket)

+ architecture would be simple (with the whole C in the JNI)
- maintaining is going to be a pain
- it's not simulable, development has to either be on target or on emulator
- the android FW has to use JNI (couldn't make this work so far because of a libc error)
- useless use of JNI (from what I understand, should be used for heavy calculations/low-level interfacing)