阅读 141

记一次App中多进程初始化导致百度定位失效问题

一、背景

项目中用到了多个第三方的SDK,其中有些外部服务是需要在AndroidManifest中配置的,并且通过形如android:process=":remote"配置单独的进程。如百度定位,对应service配置如下:

<service
    android:name="com.baidu.location.f"
    android:enabled="true"
    android:exported="false"
    android:process=":remote" />
复制代码

应用宝最近升级了App的信息安全政策,对于App中有访问过国外IP的行为,都会予以临时下架。项目中需要针对应用宝包渠道作特殊处理,将用到的国外第三方SDK去除。

为了项目整体维护方便,采用方案Android Gradle基于参数化配置实现差异化构建,配置完成并构建。

即,以应用宝渠道去掉Flurry为例,通过Gradle设置参数标识后,Flurry初始化等各相关调用方法中,采用了mock方式的空方法实现,并不依赖Flurry SDK。

构建完成后,接到线上用户反馈百度定位功能失效。


二、排查与解决

Android Gradle基于参数化配置实现差异化构建,方案本身已经比较成熟,项目中多处针对差异化的构建场景下都有所使用。构建完成后的安装包,也分别反编译并核验过最终的mock效果。

经调试发现,针对去掉Flurry的构建,在百度定位时不能如期取得定位结果,定位功能直接失效。

经排查,具体原因如下:

对于AndroidManifest中配置了多进程的service,App启动时会同时会启动对应进程,也就是说,此时除了App主进程外,还会对应有其他配置了的进程。并且,对自定义的Application而言,会分别多次实例化。Application的每次实例化,由于实在不同的进程中,相互之间是没关系的。

项目中针对不同的组件,如日志组件、Flurry等,在Application中初始化时,有着各自对进程的判断信息,如日志组件仅是针对App主进程中才初始化(做了专门的进程判断),Flurry则是针对所有进程都会初始化(没有做进程判断,至于为什么不做主进程判断,有其他方面考虑)。且Flurry的初始化是封装在特定的FlurryHelper类中,对上述的mock写法,FlurryHelper中为了输出对应日志,又用到了日志组件。

/**
 * mock Flurry工具类
 *
 */
public final class FlurryHelper {
    public static final String TAG = "FlurryUtil";

    public synchronized static void initFlurry(Context context, boolean innerProcess) {
        CLog.d(TAG, "flurry init...mock");
    }

    public static void onStart(Context context){
        CLog.d(TAG, "flurry onStart...mock");
    }

    public static void onEndSession(Context context){
        CLog.d(TAG, "flurry onEndSession...mock");
    }
}
复制代码

于是,问题产生了,对于百度定位进程而言,无论是App一开始启动时,还是后续进行定位服务时,启动的百度定位进程,在执行Application初始化时,最终都调用到了mock写法中的FlurryHelper对应方法,而其中,日志组件是并未初始化的,导致百度定位进程事实上的运行时异常而终止。

Android官方的系统中,App中只要有进程发生未捕获异常,都会有运行时异常终止弹窗。当然了,对于集成第三方SDK的进程,虽然在当前App中有进程异常终止弹窗,但force stopping确认后,但并不影响对App中与此第三方SDK无关的功能使用。只是会让用户感觉有所困惑。

国内App手机厂商,一般都对此做了进一步优化。如集成第三方SDK的进程崩溃,往往都直接没有异常终止弹窗提示到用户。此时,对用户而言,App中非主进程的崩溃是无感知的。当然了,对应的功能还是会受到影响。

这也就解释了,App没有任何崩溃感知的情况下,百度定位功能却莫名失效了。


解决:

知道问题原因后,其实解决起来非常容易,直接将mock的FlurryHelper中的日志组件替换成Android原生日志类Log即可。


三、结语

项目中,往往都会有意无意中使用到多进程,尤其对应AndroidManifest中配置的多进程,是往往容易被忽略的。多进程在初始化时,会分别执行各自的Application实例的初始化。而Application初始化中,一般都会进行其他各组件等初始化。此时,需要确认清组件与进程之间的依赖关系。如有必要,组件初始化时需要进行进程判断。特别需要注意的是,在多进程场景下的组件间的依赖关系,以及对应的初始化先后顺序等。

国内的手机厂商,针对App中非主进程的崩溃,往往用户层面是无法感知的。但对应的功能依然会受到影响。因此,涉及到此类多进程时,需要格外小心。

end~

关注下面的标签,发现更多相似文章
评论