• C/C++中写的程序可以避开JVM的内存开销过大的相知、处理高性能的计算、调用系统服务等，但是java调用jni空方法和java调用java方法相比，性能非常低的。所以一般只用来处理一些对运算有要求，或者需要对接口隐蔽的功能。

• JNI　一般编写流程　其实就是为了避免一些错误　用javah生成jni函数名，还是值得推荐使用的。验证过，可以生成。比较使用的小技巧。

image.png

javac src/com/example/com/enjoy/test/test.java -d ./bin
javah -jni -classpath ./bin -d ./jni com.example.com.enjoy.test.test

image.png

• apk crash 有log 可以定位，程序的anr 会在记录在／data/anr/traces.txt　mtk aee log也有。
  但是NDK Crash 定位就很难了　，容易出错的地方有　内存地址访问错误 使用野指针　　内存泄露　　堆栈溢出　　初始化错误　　类型转换错误　数字除０（１１／０）　等等

使用ndk-stack 进行定位到行。

image.png

• 因为 Java 默认使用 Unicode 编码,而 C/C++默认使用 UTF 编码,所以在本地代码中操作字符串的时候,必须使用合适的 JNI 函数把 jstring 转换成 C 风格的字符串。 JNI 支持字符串在 Unicode和 UTF-8 两种编码之间转换,GetStringUTFChars 可以把一个 jstring 指针(指向 JVM 内部的 Unicode字符序列)转换成一个 UTF-8 格式的 C 字符串。
  -调用完 GetStringUTFChars 之后不要忘记安全检查,因为 JVM 需要为新诞生的字符串分配内存空间,当内存空间不够分配的时候,会导致调用失败,失败后 GetStringUTFChars 会返回 NULL,并抛出一个 OutOfMemoryError 异常。JNI 的异常和 Java 中的异常处理流程是不一样的,Java 遇到异常如果没有捕获,程序会立即停止运行。而 JNI 遇到未决的异常不会改变程序的运行流程,也就是程序会继续往下走
• 接口找不到
  在Java中调用JNI接口时，出现异常，察看日志，发现有如下错误：
  WARN/dalvikvm(422): No implementation found for native Lcom/whty/wcity/HelixPlayer;.setDllPath (Ljava/lang/String;)V
  检查了几遍代码，Cpp中确实定义了这个接口，而且仔细对照了Java的包名、类名，确实没有错误，那为什么会出现这种问题呢。后来突然想到，JNI接口 都是以C的方式定义的，现在使用C++实现，函数定义前是否需要加上extern "C"呢？为此定义了一个头文件，在CPP文件中include该头文件，头文件加上如下代码片断：

ifdef __cplusplus

extern "C" {

endif

endif

...

ifdef __cplusplus

}
再次尝试，调用成功！

• MTK flash tool 刷机问题　ubuntu 下刷机　出现了异常。
  BROM ERROR : STATUS_ERR (-1073676287)
  STATUS_BROM_CMD_SEND_DA_FAIL
  chip mismatch MT0000

这几个问题　　直接用ｏｋ机器的
/etc/udev/rules.d/　　目录下文件全部替换即可

jni读写文件　open 时候出错 fd 返回-1 文件节点权限是666
刚开始以为是权限问题，chmod 666后发现还是不行使用java 文件流进行读写　发现读是ok的
写时候出现异常 后面公司大神改了下驱动　　将模块驱动中映射的open函数直接返回０
还是不行 。
最后自己怀疑是selinux 问题

image.png

我的avc 异常：
[ 138.125449] <6>.(6)[283:logd.auditd]type=1400 audit(1496479197.368:93): avc: denied { read write } for pid=3144 comm="m.enjoy.testjni" name="ttctl" dev="tmpfs" ino=11250 scontext=u:r:system_app:s0 tcontext=u:object_r:ttctl_device:s0 tclass=chr_file permissive=0
修改：　
/alps/device/mediatek/common/sepolicy/system_app.te
+allow system_app ttctl_device:chr_file { read write ioctl open };
还没验证　　下周再验证吧。编译实在是太慢了。
周一了周六遗留的问题解决了看log很重要，但是ioctl　返回值-1剩下就要看驱动了。

-在framework PowerManger中添加 接口，update-api 发现mmm但编译之后 一直报方法未重写，但实际已经重写，不明原因，直接根目录下全编一次就好了。

• 报checkJni错误一般在jni映射函数中出错了，比如返回类型没写对