Android-语言设置流程分析

    以Android5.1工程源码为基础,从设置app入手来分析和学习语言切换的过程:

    一、语言设置界面：

    首先在设置app中找到语言设置这个Preference，目前设置中界面大多都是Fragment，先找到语言和输入法的PreferenceScreen，与其对应的Fragment是InputMethodAndLanguageSettings.java，在其onCreate()方法中，首先是增加语言设置的preference：    

找到language_settings.xml，可发现如下代码：   

于是断定LocalePicker就是语言设置的Fragment，它是ListFragment的子类，继承于framework中LocalePicker,并实现了父类的一个接口，其回调方法是onLocaleSelected()，Locale中文含义大致是语言环境，所以可推测这是设置语言后的一个回调方法，不确定的话，可打断点测试一下。然而此类中并没有关于语言设置界面数据适配的太多逻辑，只是通过父类的方法创建了一个view:   

   所以更多逻辑应该在framework中的LocalePicker.java中。既然是ListFragment，那就必须有Adapter,在此类中有构建了一个Adapter：

而此方法通过getAllAssetLocales()方法获取系统支持语言的信息：

    此方法中还会通过Resources.getSystem().getAssets().getLocales()去获得系统支持的语言信息，然后添加LocaleInfo里边，再通过Adapter适配到ListView中。getLocales()方法属于类AssetManager.java：

乍一看，是个native方法，那不就是跟JNI有关系了，所以只能到相应JNI目录下去找了，路径：android5.1\frameworks\base\core\jni，对应文件：android_util_AssetManager.cpp（浏览下这个文件，发现这个家伙有点不得了啊，什么resource，theme等都跟它有关系,看样子还的加油学学JNI啊!），然后找到对应的native方法：

通过上面初步的分析，语言的List界面就基本出来了，在getAllAssetLocales()方法中打了个断点，查看了下locales被赋值以后的值：

二、语言设置功能实现过程：

上面提到了设置中的LocalePicker类实现了父类接口中的onLocaleSelected()方法：   

  又看到ActivityManagerNative.getDefault()，所以可以直接到ActivityManagerService.java中找对应的方法，此方法中先是把选择的语言设置到Configuration中，记录下来。设置了不代表系统就知道这档子事，所以还需要am去更新一下，说的俗气一点：am老大知道了这档子事，然后大吼一声，我这里有个东西改变了，小伙伴们刷新一下！在ActivityManagerService中找到updateConfiguration()方法：

看到Settings.System.clearConfiguration(values)不要以为这里把values清除了额，其实这个方法只是把系统字体的特效清除了，比如字体的大小：   

然后调用updateConfigurationLocked()方法：

此方法主要做两件事：第一，改变当前的configuration，将新的数据放进去。第二，保证正在运行的应用程序界面更新最新的configuration。先调用updateFrom()方法，遍历configuration包含的属性是否改变，如果有改变就返回一个对应的整数，如果没有改变就返回0。就语言改变而言，根据上面的分析，configuration至少有3个属性发生了改变：fontscale（之前没有设置字体的效果就不会改变）、locale和布局的direction。

    有了新的数据就要保存，保存在configuration中不是个事。对于Android系统而言，改变语言，有两个地方的数据需要更新，一个是SystemProperties，另一个是数据库。前者以键值对的形式存放数据，多用于System，后者保存于DataBase中，多用于应用程序获取，算是对外开放的数据。上面方法中对这两个地方都进行了数据保存操作:

    1)SystemProperties：调用saveLocaleLocked()方法：

    2)database:调用Settings.System.putConfiguration()方法：

   

    该保存的数据保存了，但是Resource还不知道这档子事，因为Android代码和资源是分开的，Resource不知道Configuration发生了变化，Resource就不会去加载正确的资源。所以接下来此方法调用了mSystemThread.applyConfigurationToResources(configCopy)来完成这件事，mSystemThread是一个ActivityThread对象，其初始化在ActivityManagerService的构造函数中完成：   

        

    此方法中Resource和ApplicationPackageManager都会去更新configuration，configuration所包含的属性都会遍历到，该更新的数据更新，该清除的缓存清除。

    到这里，第一件事算是做完了，就要做第二件事，让新的configuration更新到所有界面，updateConfigurationLocked()方法通过遍历保存在ProcessRecord中的进程，然后通过scheduleConfigurationChanged()方法更新它们的configuration：

  此处通过Binder机制调用ApplicationThreadNative.java中的scheduleConfigurationChanged()方法，最后调用到ActivityThread中的内部类ApplicationThread的scheduleConfigurationChanged()方法，函数调用堆栈如图：

    

    

      

 

    到这里设置语言以后，代码跑的流程就基本结束了，需要一提的是performConfigurationChanged()方法。为什么要提它呢？因为有时候写应用的时候activity需要关注一些configChanged，如：android:configChanges="orientation|keyboardHidden|screenSize"，然后重写onConfigurationChanged()方法。然而触发这个方法回调的触发点在哪里呢？这里就以设置语言为例，设置语言触发了configuration的改变。先来看下performConfigurationChanged()方法：    

    如果configuration确实改变了，那么此方法中就会调用cb.onConfigurationChanged(config)。cb代表ComponentCallbacks2，而ComponentCallbacks2 又继承于ComponentCallbacks，所以onConfigurationChanged()方法属于ComponentCallbacks，同样Activity类也实现了ComponentCallbacks2这个接口，如此一来这个回调的过程就连接上了。也充分说明了为什么在configuration改变以后，activity关注的config会回调其父类的onConfigurationChanged()方法。

 

    最后就是广播configuration改变了，updateConfigurationLocked()广播了ACTION_CONFIGURATION_CHANGED和ACTION_LOCALE_CHANGED，使用的方法是broadcastIntentLocked()，此方法广播成功返回BROADCAST_SUCCESS。具体就不多说了。