我想在最開始再廢一些周章，來把啟動的過程略微的闡述一下，為的就是接下去描述插件化痛點的時候，你會更加的身臨其境。
activity的啟動過程如下：
- Launcher是系統的apk，點擊界面圖標會調用相應的Activity.startActivity，或者是直接從ActivityA啟動ActivityB
- contextImpl.startActivity()->Instrumentation.executeActivity()
- ActivityManagerNative.getDefault().startActivity()->AMS.startActivity
Instrumentation通過aidl進行跨進程通信，最終調用AMS的startActivity方法 - ActivityStarter.startActivityMayWait()->startActivityLocked()->startActivityUnchecked()
- ActivityStack.resumeFocusedStackTopActivityLocked()->resumeTopActivityUncheckedLocked()->resumeTopActivityInnerLocked()
- ActivityStackSupervisor.startSpecificActivityLocked()->realStartActivityLocked()（如果應用還沒有啟動那么走mService.startProcessLocked方法）
- app.thread.scheduleLaunchActivity()-> sendMessage(H.LAUNCH_ACTIVITY, r)
- H.handleMessage()->handleLaunchActivity()->performLaunchActivity()
如果是初次啟動應用，那么我們接著上面的mService.startProcessLocked去看，直接請求Zygote給啟動應用fork一個進程出來
- startProcessLocked()（經過幾次重載跳轉）->
Process.ProcessStartResult startResult = Process.start(entryPoint,
app.processName, uid, uid, gids, debugFlags, mountExternal,
app.info.targetSdkVersion, app.info.seinfo, requiredAbi, instructionSet,
app.info.dataDir, entryPointArgs);
->Process.startViaZygote() 請求Zygote進程為其生成新進程
- 在startViaZygote方法中設置完各種參數之后，最終調用zygoteSendArgsAndGetResult方法，向Zygote發送創建進程的請求。
內部使用socket通信
zygoteSendArgsAndGetResult(openZygoteSocketIfNeeded(abi), argsForZygote)
- Zygote內部的不斷循環方法runSelectLoop會接受到這個請求
if (i == 0) {
ZygoteConnection newPeer = acceptCommandPeer(abiList);
peers.add(newPeer);
fds.add(newPeer.getFileDesciptor());
} else {
boolean done = peers.get(i).runOnce();
if (done) {
peers.remove(i);
fds.remove(i);
}
}
先進行包裝成ZygoteConnection對象，并將socket的文件標識做保存。然后在下一次的循環中去執行runOnce
- 在runOnce方法中
pid = Zygote.forkAndSpecialize(parsedArgs.uid, parsedArgs.gid, parsedArgs.gids,parsedArgs.debugFlags, rlimits, parsedArgs.mountExternal, parsedArgs.seInfo, parsedArgs.niceName, fdsToClose, parsedArgs.instructionSet,parsedArgs.appDataDir);
通過這個方法去創建進程，實際上就是fork出一個新的虛擬機實例。
- 如果fork成功了，那么返回的pid==0
if (pid == 0) {
// in child
IoUtils.closeQuietly(serverPipeFd);
serverPipeFd = null;
handleChildProc(parsedArgs, descriptors, childPipeFd, newStderr);
// should never get here, the child is expected to either
// throw ZygoteInit.MethodAndArgsCaller or exec().
return true;
} else {
// in parent...pid of < 0 means failure
IoUtils.closeQuietly(childPipeFd);
childPipeFd = null;
return handleParentProc(pid, descriptors, serverPipeFd, parsedArgs);
}
我們接著去執行handleChildProc
- 這里我們做的就是關閉socket通道，并且啟動新的進程
private void handleChildProc(Arguments parsedArgs,
FileDescriptor[] descriptors, FileDescriptor pipeFd, PrintStream newStderr)
throws ZygoteInit.MethodAndArgsCaller {
//關閉socket
closeSocket();
ZygoteInit.closeServerSocket();
...
// End of the postFork event.
Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);
if (parsedArgs.invokeWith != null) {
WrapperInit.execApplication(parsedArgs.invokeWith,
parsedArgs.niceName, parsedArgs.targetSdkVersion,
VMRuntime.getCurrentInstructionSet(),
pipeFd, parsedArgs.remainingArgs);
} else {
//基本走的都是這種啟動方式，通過參數，去尋找目標類的main方法并執行
RuntimeInit.zygoteInit(parsedArgs.targetSdkVersion,
parsedArgs.remainingArgs, null /* classLoader */);
}
}
- zygoteInit
public static final void zygoteInit(int targetSdkVersion, String[] argv, ClassLoader classLoader)
throws ZygoteInit.MethodAndArgsCaller {
...
//初始化
commonInit();
//native的初始化
nativeZygoteInit();
//application的初始化
applicationInit(targetSdkVersion, argv, classLoader);
}
主要的就是applicationInit方法，設置虛擬機的堆大小，和虛擬機的sdkversion
VMRuntime.getRuntime().setTargetHeapUtilization(0.75f);
VMRuntime.getRuntime().setTargetSdkVersion(targetSdkVersion);
并且通過反射的方式去觸發目標類的main方法
try {
cl = Class.forName(className, true, classLoader);
} catch (ClassNotFoundException ex) {
throw new RuntimeException(
"Missing class when invoking static main " + className,
ex);
}
Method m;
try {
m = cl.getMethod("main", new Class[] { String[].class });
} catch (NoSuchMethodException ex) {
throw new RuntimeException(
"Missing static main on " + className, ex);
} catch (SecurityException ex) {
throw new RuntimeException(
"Problem getting static main on " + className, ex);
}
最終觸發，ActivityThread的main方法
對于activity啟動的總結
-
activityA啟動ActivityB
由contextImp發起的startActivity跳轉到instrumentation的executeStartActivity然后交由ActivityStarter做啟動準備，分別又經過ActivityStack棧，觀察是否有棧頂Activity可以直接用來resume，最終交由ActivityStackSupervisor來realStartActivityLocked，然后通過applicationThread的scheduleLaunchActivity方法發送消息給H的handler，經過處理執行handleLaunchActivity到performLaunchActivity
-
Launcher點擊圖標啟動應用
依然有Activity.startActivity啟動應用，直到ActivityStackSupervisor的startSpecificActivityLocked通過啟動service的startProcessLocked，這個是AMS的方法，通過Socket通道，請求Zygote系統進程為目標應用分配VM虛擬機。分配成功之后關閉通道，并且通過反射的方式執行目標類的main方法，也就是ActivityThread的main方法。
走進插件化
講在前面
我們前面廢了相當多的周章，來把啟動的過程詳細的闡述了一下（其實也沒有很詳細），為的就是接下去闡述痛點的時候，你會更加的身臨其境。
本文是基于android7.1的最新源碼分析，你會發現google在不斷的修改并強化activity的啟動過程，它會想方設法的去阻止你進行插件化修改，因為插件化的方式從某些層面來講，并不利于android的生態發展。所以你會發現這篇插件化講解中的啟動的源碼是這樣的，而到了那篇就變了個樣，實際以最新版本源碼為主。
首先，對于插件化，你需要先了解它的模式
插件化干什么
比如說我們的主app相當的巨大，里面集成了大量的模塊，我們的app可能有300+mb，那么這個時候客戶可能就很不愿意去下載您的app。
我們需要把我們app的主干功能保存下來，放在主app當中，然后將其余的模塊功能做成插件的方式，在主app需要使用到的時候再去調用。
這樣我們可以做到
- 并行開發，快速迭代
- 模塊間解耦
- 按需加載，節省內存
- 動態升級，我們只需要更新插件就可以做到功能更新，而無需更新整個app
碰到的坎
那么很明顯了，好處相當多，我們開始準備著手去做了，我們搞了兩個apk，一個是主apk，一個是插件apk。我們琢磨著在主apk中去啟動插件apk中的activity。但是發現行不通。報了一個平時開發中也會遇到的exception，當你沒有將你需要啟動的activity在manifest文件中注冊的時候就會出現的錯誤。
Caused by: android.content.ActivityNotFoundException: Unable to find explicit activity class {org.ding.testmulti/org.ding.testmulti.JustTest}; have you declared this activity in your AndroidManifest.xml?
怎么辦？我們先通過錯誤提示定位到出問題的所在地
at android.app.Instrumentation.checkStartActivityResult(Instrumentation.java:1794)
at android.app.Instrumentation.execStartActivity(Instrumentation.java:1512)
前往execStartActivity方法，問題就出在下面這段代碼
int result = ActivityManagerNative.getDefault()
.startActivity(whoThread, who.getBasePackageName(), intent,
intent.resolveTypeIfNeeded(who.getContentResolver()),
token, target != null ? target.mEmbeddedID : null,
requestCode, 0, null, options);
checkStartActivityResult(result, intent);
也就是說跨進程訪問的AMS的startActivity返回的result是錯誤的result，我們經過一番定位最終發現問題出在ActivityStarter的startActivityMayWait方法中，
ResolveInfo rInfo = mSupervisor.resolveIntent(intent, resolvedType, userId);
返回的是空，
ResolveInfo resolveIntent(Intent intent, String resolvedType, int userId, int flags) {
try {
return AppGlobals.getPackageManager().resolveIntent(intent, resolvedType,
PackageManager.MATCH_DEFAULT_ONLY | flags
| ActivityManagerService.STOCK_PM_FLAGS, userId);
} catch (RemoteException e) {
}
return null;
}
最終我們走的PMS的resolveIntent，如果你看過我的應用安裝分析的話(Android app安裝過程分析（基于Nougat）,你應該會了解，在應用安裝的過程中，PMS會將Manifest文件中的內容依次讀出，并保存在packageInfo當中，以供使用
最終在PMS.java文件中找到resolveIntent方法
@Override
public ResolveInfo resolveIntent(Intent intent, String resolvedType,
int flags, int userId) {
try {
...
final List<ResolveInfo> query = queryIntentActivitiesInternal(intent, resolvedType,
flags, userId);
Trace.traceEnd(TRACE_TAG_PACKAGE_MANAGER);
final ResolveInfo bestChoice =
chooseBestActivity(intent, resolvedType, flags, query, userId);
return bestChoice;
} finally {
Trace.traceEnd(TRACE_TAG_PACKAGE_MANAGER);
}
}
也就是說queryIntentActivitiesInternal方法返回的列表為空，并沒有找到與intent匹配的activity。
當前流行的解決方案
當前失眠流行的插件化代理解決方案有很多，但是基本的原理無外乎如下兩類。分別是hookInstrumentation和hookActivityManagerNative，此處的hook我們可以把它理解成貍貓換太子。就是利用我們自己偽造的來騙過系統，從而達到插件化的效果。
hookInstrumention
市面上使用hookInstrumentation方法的是Small框架，在它的ApkBundleLauncher類中的onCreate方法：
@Override
public void onCreate(Application app) {
super.onCreate(app);
Object/*ActivityThread*/ thread;
List<ProviderInfo> providers;
Instrumentation base;
ApkBundleLauncher.InstrumentationWrapper wrapper;
Field f;
// Get activity thread
thread = ReflectAccelerator.getActivityThread(app);
// Replace instrumentation
try {
//拿到當前thread的Instrumentation對象
//我們主要大費周章的把Instrumentation這個對象取出來是為了對其進行保存，要注意，只要是hook了對象，那么除非真的沒有必要
//一般都需要對這個對象進行緩存，以防不時之需
f = thread.getClass().getDeclaredField("mInstrumentation");
f.setAccessible(true);
base = (Instrumentation) f.get(thread);
wrapper = new ApkBundleLauncher.InstrumentationWrapper(base);
f.set(thread, wrapper);
} catch (Exception e) {
throw new RuntimeException("Failed to replace instrumentation for thread: " + thread);
}
...
}
我們在InstrumentationWrapper中看到它重寫了execStartActivity方法，來進行替換
/** @Override V21+
* Wrap activity from REAL to STUB */
public ActivityResult execStartActivity(
Context who, IBinder contextThread, IBinder token, Activity target,
Intent intent, int requestCode, android.os.Bundle options) {
wrapIntent(intent);
return ReflectAccelerator.execStartActivity(mBase,
who, contextThread, token, target, intent, requestCode, options);
}
/** @Override V20-
* Wrap activity from REAL to STUB */
public ActivityResult execStartActivity(
Context who, IBinder contextThread, IBinder token, Activity target,
Intent intent, int requestCode) {
wrapIntent(intent);
return ReflectAccelerator.execStartActivity(mBase,
who, contextThread, token, target, intent, requestCode);
}
wrapIntent(intent)方法包裝intent，然后對activity進行替換，將realActivity替換成我們提前在Manifest中注冊好的Activity。
在Small的最新版本中，將Activity再替換回來是放在Hook的Handler.CallBack中的(之前是直接走的mInstrumentation的newActivity來進行Activity的復原）
// Inject message handler
try {
f = thread.getClass().getDeclaredField("mH");
f.setAccessible(true);
Handler ah = (Handler) f.get(thread);
f = Handler.class.getDeclaredField("mCallback");
f.setAccessible(true);
f.set(ah, new ApkBundleLauncher.ActivityThreadHandlerCallback());
} catch (Exception e) {
throw new RuntimeException("Failed to replace message handler for thread: " + thread);
}
@Override
public boolean handleMessage(Message msg) {
switch (msg.what) {
case LAUNCH_ACTIVITY:
//在handler收到LAUNCH_ACTIVITY的信號時進行進行替換
redirectActivity(msg);
break;
case CREATE_SERVICE:
ensureServiceClassesLoadable(msg);
break;
default:
break;
}
return false;
}
HookActivityManagerNative
而DroidPlugin使用的是將ActivityManagerNative整個的Hook掉，具體我們見ProxyHool類
public abstract class ProxyHook extends Hook implements InvocationHandler {
public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
try {
if (!isEnable()) {
return method.invoke(mOldObj, args);
}
HookedMethodHandler hookedMethodHandler = mHookHandles.getHookedMethodHandler(method);
if (hookedMethodHandler != null) {
return hookedMethodHandler.doHookInner(mOldObj, method, args);
}
return method.invoke(mOldObj, args);
}
......
}
拿出具體的HookedMethodHandler，然后調用其doHookInner方法
public synchronized Object doHookInner(Object receiver, Method method, Object[] args) throws Throwable {
long b = System.currentTimeMillis();
try {
mUseFakedResult = false;
mFakedResult = null;
boolean suc = beforeInvoke(receiver, method, args);
Object invokeResult = null;
if (!suc) {
invokeResult = method.invoke(receiver, args);
}
afterInvoke(receiver, method, args, invokeResult);
if (mUseFakedResult) {
return mFakedResult;
} else {
return invokeResult;
}
} finally {
long time = System.currentTimeMillis() - b;
if (time > 5) {
Log.i(TAG, "doHookInner method(%s.%s) cost %s ms", method.getDeclaringClass().getName(), method.getName(), time);
}
}
}
通過AOP的方式分別在其方法前后進行hook
我們此處替換掉的ActivityManagerNative，就是在IActivityManagerHookHandle中的startActivity類然后我們看他的beforeInvoke方法
@Override
protected boolean beforeInvoke(Object receiver, Method method, Object[] args) throws Throwable {
RunningActivities.beforeStartActivity();
boolean bRet;
if (Build.VERSION.SDK_INT < Build.VERSION_CODES.JELLY_BEAN_MR2) {
bRet = doReplaceIntentForStartActivityAPILow(args);
} else {
bRet = doReplaceIntentForStartActivityAPIHigh(args);
}
if (!bRet) {
setFakedResult(Activity.RESULT_CANCELED);
return true;
}
return super.beforeInvoke(receiver, method, args);
}
doReplaceIntentForStartActivityAPIHigh這個方法也是將真Activity信息保存，然后用stubActivity來進行替換。
至于再換回來也是用的callBack，實際上DroidPlugin要比Small要更早的使用Hook callBack的方式
PluginCallbackHook.java
@Override
protected void onInstall(ClassLoader classLoader) throws Throwable {
Object target = ActivityThreadCompat.currentActivityThread();
Class ActivityThreadClass = ActivityThreadCompat.activityThreadClass();
/*替換ActivityThread.mH.mCallback，攔截組件調度消息*/
Field mHField = FieldUtils.getField(ActivityThreadClass, "mH");
Handler handler = (Handler) FieldUtils.readField(mHField, target);
Field mCallbackField = FieldUtils.getField(Handler.class, "mCallback");
//*這里讀取出舊的callback并處理*/
Object mCallback = FieldUtils.readField(mCallbackField, handler);
if (!PluginCallback.class.isInstance(mCallback)) {
PluginCallback value = mCallback != null ? new PluginCallback(mHostContext, handler, (Handler.Callback) mCallback) : new PluginCallback(mHostContext, handler, null);
value.setEnable(isEnable());
mCallbacks.add(value);
FieldUtils.writeField(mCallbackField, handler, value);
Log.i(TAG, "PluginCallbackHook has installed");
} else {
Log.i(TAG, "PluginCallbackHook has installed,skip");
}
}
PluginCallback.java
private boolean handleLaunchActivity(Message msg) {
try {
Object obj = msg.obj;
Intent stubIntent = (Intent) FieldUtils.readField(obj, "intent");
//ActivityInfo activityInfo = (ActivityInfo) FieldUtils.readField(obj, "activityInfo", true);
stubIntent.setExtrasClassLoader(mHostContext.getClassLoader());
Intent targetIntent = stubIntent.getParcelableExtra(Env.EXTRA_TARGET_INTENT);
// 這里多加一個isNotShortcutProxyActivity的判斷，因為ShortcutProxyActivity的很特殊，啟動它的時候，
// 也會帶上一個EXTRA_TARGET_INTENT的數據，就會導致這里誤以為是啟動插件Activity，所以這里要先做一個判斷。
// 之前ShortcutProxyActivity錯誤復用了key，但是為了兼容，所以這里就先這么判斷吧。
if (targetIntent != null && !isShortcutProxyActivity(stubIntent)) {
IPackageManagerHook.fixContextPackageManager(mHostContext);
ComponentName targetComponentName = targetIntent.resolveActivity(mHostContext.getPackageManager());
ActivityInfo targetActivityInfo = PluginManager.getInstance().getActivityInfo(targetComponentName, 0);
if (targetActivityInfo != null) {
if (targetComponentName != null && targetComponentName.getClassName().startsWith(".")) {
targetIntent.setClassName(targetComponentName.getPackageName(), targetComponentName.getPackageName() + targetComponentName.getClassName());
}
ResolveInfo resolveInfo = mHostContext.getPackageManager().resolveActivity(stubIntent, 0);
ActivityInfo stubActivityInfo = resolveInfo != null ? resolveInfo.activityInfo : null;
if (stubActivityInfo != null) {
PluginManager.getInstance().reportMyProcessName(stubActivityInfo.processName, targetActivityInfo.processName, targetActivityInfo.packageName);
}
PluginProcessManager.preLoadApk(mHostContext, targetActivityInfo);
ClassLoader pluginClassLoader = PluginProcessManager.getPluginClassLoader(targetComponentName.getPackageName());
setIntentClassLoader(targetIntent, pluginClassLoader);
setIntentClassLoader(stubIntent, pluginClassLoader);
...
Log.i(TAG, "handleLaunchActivity OK");
} else {
Log.e(TAG, "handleLaunchActivity oldInfo==null");
}
} else {
Log.e(TAG, "handleLaunchActivity targetIntent==null");
}
} catch (Exception e) {
Log.e(TAG, "handleLaunchActivity FAIL", e);
}
if (mCallback != null) {
return mCallback.handleMessage(msg);
} else {
return false;
}
}
至此兩種最經典的插件化方式分析完畢，之后我們再來看框架的具體使用心得
TBC。。
