插件工程异常

一、背景介绍

云助手最初的引入库，是内置在系统的 /system/framework/cloud.jar，其包含了统计、云服务等方面的接口类，后来将统计、云服务单独解耦，故将云助手的引用更新为直接引用工程Cloud

二、产生问题、原因深究、解决方案

（1）
产生问题：云助手ClassNotFoundException crash

原因深究：云助手是运行在32位的环境中，Cloud工程是运行在64位的环境，当32位的云助手调用64位的Cloud的api的时候，就会出现异常ClassNotFoundException

解决方案：Cloud修改为32位、64位环境都支持的应用，在Android.mk文件中LOCAL_MULTILIB设置为both

（2）
产生问题：桌面home crash

      Build fingerprint:'i/ido/ido:7.0/NRD90M/1.1.1:user/test-keys'

      Revision:'0'

      ABI:'arm64'

      pid:6002,tid:6230,name:Thread-8 >>>com.i.home <<< signal 11(SIGSEGV),code 1(SEGV_MAPERR),fault addr 0x2

     ... ...

     backtrace:

     #00 pc 0000000000000290fc /systemlib64/libart.so(offset 0x22c000)

原因探究：
1、从bugreport上面来看的话，没有java栈的调用情况，所以根本无从下手。 初步定位在statsdk中方法valueToJSon()出现npe
2、云助手的dex同时被两个进程引用着（桌面com.i.home，云助手com.i.cloudassistant），桌面和云助手工程中都引用了statsdk，但是版本不相同； 桌面进程中不但存在自己compile的statsdk版本，也存在load到桌面的云助手dex中的statsdk版本，在桌面调用统计中会产生混乱的情况，故crash

解决方案：使用在AndroidManifest.xml文件中声明<uses-library android:name="stat.jar"/>，在build文件引用方式provided ‘com.i:statssdk:alpha-SNAPSHOT’，引用系统中的统计sdk，在云助手的dex中就不会在打入statsdk的代码

三、延伸
dx编译jar包进dex文件的时候不管你是什么method最后都是一个method idx(index限制为65536) art解释执行的时候是通过找到dex文件跳转idx来进行
在两个apk，同一个jar被同时打入两个dex，idx大概率是不一样的。

使用同一个dex gradle是不能用compile的要用provide，要么art搜索dex的时候可能会因为顺序导致找错了dex文件进而加载class 跳转method都有可能会出错

前提如果 云助手不独立运行 都是通过module的方式 进入home运行的话，编译云助手的时候
provide 统计sdk
home compile统计sdk