每日一问 | 关于 Activity 重建，值得探究的几个问题

问题1：会回收，写了个简单demo验证下。

MainActivity23有个button启动MainActivity24。MainActivity24不断增大内存会导致MainActivity23的onDestroy被执行。

class MainActivity24 : AppCompatActivity() {
    var byteArray= ByteArray(1)
    var count=1
    private val binding by viewBinding(ActivityMain24Binding::inflate)
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        binding.button10.setOnClickListener {
            addAndGetMemory()
        }
    }
   private fun addAndGetMemory(){
        byteArray= ByteArray(1024*1024*10*count)
        count++
        var runtime= Runtime.getRuntime()
        var maxMemory = runtime.maxMemory()
        var dalvikUsed=runtime.totalMemory()-runtime.freeMemory()
        log("maxMemory:${maxMemory/1024},dalvikUsed:${dalvikUsed/1024}")
    }
}

源码分析：API 版本30，Acvitity的问题应该是和ActivityThread和AMS有关系，从ActivityThread的main方法开始。

在ActivityThread的main方法中会新建ActivityThread实例，并通过attach方法和AMS产生联系。attach里面的BinderInternal.addGcWatcher会查看内存使用情况，当使用内存大于APP分配总内存的3/4时，就会触发ATMS去释放部分Activity

   private void attach(boolean system, long startSeq) {
        sCurrentActivityThread = this;
        mSystemThread = system;
        if (!system) {
            android.ddm.DdmHandleAppName.setAppName("<pre-initialized>",
                                                    UserHandle.myUserId());
            RuntimeInit.setApplicationObject(mAppThread.asBinder());
            final IActivityManager mgr = ActivityManager.getService();
            try {
               //ApplicationThread是ActivityThread和AMS沟通的桥梁
                mgr.attachApplication(mAppThread, startSeq);
            } catch (RemoteException ex) {
                throw ex.rethrowFromSystemServer();
            }
            // Watch for getting close to heap limit.
            BinderInternal.addGcWatcher(new Runnable() {
                @Override public void run() {
                    if (!mSomeActivitiesChanged) {
                        return;
                    }
                    Runtime runtime = Runtime.getRuntime();
                    long dalvikMax = runtime.maxMemory();
                    long dalvikUsed = runtime.totalMemory() - runtime.freeMemory();
                    if (dalvikUsed > ((3*dalvikMax)/4)) {
                        if (DEBUG_MEMORY_TRIM) Slog.d(TAG, "Dalvik max=" + (dalvikMax/1024)
                                + " total=" + (runtime.totalMemory()/1024)
                                + " used=" + (dalvikUsed/1024));
                        mSomeActivitiesChanged = false;
                        try {
                            ActivityTaskManager.getService().releaseSomeActivities(mAppThread);
                        } catch (RemoteException e) {
                            throw e.rethrowFromSystemServer();
                        }
                    }
                }
            });
        }

ATMS(ActivityTaskManagerService)释放Activity方法 ，把可以回收的Activty的放进candidates列表，然后在通过transaction执行DestroyActivityItem来回收Activity。

    public void releaseSomeActivities(IApplicationThread appInt) {
        synchronized (mGlobalLock) {
            final long origId = Binder.clearCallingIdentity();
            try {
                final WindowProcessController app = getProcessController(appInt);
                app.releaseSomeActivities("low-mem");
            } finally {
                Binder.restoreCallingIdentity(origId);
            }
        }
    }
    void releaseSomeActivities(String reason) {
        // Examine all activities currently running in the process.
        // Candidate activities that can be destroyed.
        ArrayList<ActivityRecord> candidates = null;
        if (DEBUG_RELEASE) Slog.d(TAG_RELEASE, "Trying to release some activities in " + this);
        for (int i = 0; i < mActivities.size(); i++) {
            final ActivityRecord r = mActivities.get(i);
            // First, if we find an activity that is in the process of being destroyed,
            // then we just aren't going to do anything for now; we want things to settle
            // down before we try to prune more activities.
           //如果有Activity出于finishing，可以暂时不处理了。
            if (r.finishing || r.isState(DESTROYING, DESTROYED)) {
                if (DEBUG_RELEASE) Slog.d(TAG_RELEASE, "Abort release; already destroying: " + r);
                return;
            }
            // Don't consider any activities that are currently not in a state where they
            // can be destroyed.
            // 处于这些状态的activity也不回收
            if (r.mVisibleRequested || !r.stopped || !r.hasSavedState() || !r.isDestroyable()
                    || r.isState(STARTED, RESUMED, PAUSING, PAUSED, STOPPING)) {
                if (DEBUG_RELEASE) Slog.d(TAG_RELEASE, "Not releasing in-use activity: " + r);
                continue;
            }

            if (r.getParent() != null) {
                if (candidates == null) {
                    candidates = new ArrayList<>();
                }
                //添加进待处理列表
                candidates.add(r);
            }
        }

        if (candidates != null) {
            // Sort based on z-order in hierarchy.
            candidates.sort(WindowContainer::compareTo);
            // Release some older activities
            int maxRelease = Math.max(candidates.size(), 1);
            do {
                final ActivityRecord r = candidates.remove(0);
                if (DEBUG_RELEASE) Slog.v(TAG_RELEASE, "Destroying " + r
                        + " in state " + r.getState() + " for reason " + reason);
                r.destroyImmediately(true /*removeFromApp*/, reason);
                --maxRelease;
            } while (maxRelease > 0);
        }
    }

ActivityRecode.java

生命周期方法调用这，Android 8以后有改动，不太明白怎么调用的可以去看看这篇文章

https://juejin.cn/post/6844904040266989576

boolean destroyImmediately(boolean removeFromApp, String reason) {
....
mAtmService.getLifecycleManager().scheduleTransaction(app.getThread(), appToken,
                        DestroyActivityItem.obtain(finishing, configChangeFlags));
....
}

还有个问题是通过BinderInternal.addGcWatcher添加的这个Runable何时执行的问题。可以通过BinderInternal源码发现，它运用了WeakReference和finalize的机制，WeakReference每次GC都会被回收，GcWatcher就会被调用finalize方法，然后执行上面添加的Runnable。在执行后再新建一个WeakReference供下次GC来重复运行该机制。

public class BinderInternal {
    private static final String TAG = "BinderInternal";
    static WeakReference<GcWatcher> sGcWatcher
            = new WeakReference<GcWatcher>(new GcWatcher());
    static ArrayList<Runnable> sGcWatchers = new ArrayList<>();
    static Runnable[] sTmpWatchers = new Runnable[1];

    static final class GcWatcher {
        @Override
        protected void finalize() throws Throwable {
            handleGc();
            sLastGcTime = SystemClock.uptimeMillis();
            synchronized (sGcWatchers) {
                sTmpWatchers = sGcWatchers.toArray(sTmpWatchers);
            }
            for (int i=0; i<sTmpWatchers.length; i++) {
                if (sTmpWatchers[i] != null) {
                    sTmpWatchers[i].run();
                }
            }
            sGcWatcher = new WeakReference<GcWatcher>(new GcWatcher());
        }
    }

    public static void addGcWatcher(Runnable watcher) {
        synchronized (sGcWatchers) {
            sGcWatchers.add(watcher);
        }
    }
    public static void forceGc(String reason) {
        EventLog.writeEvent(2741, reason);
        VMRuntime.getRuntime().requestConcurrentGC();
    }
}

还有个问题是怎么触发的GC？

看了一圈，上面的forceGc方法嫌疑比较大，在ActivityThread中也有关于GC的对这个方法的调用（不太严谨哈，不对请大神指正）。requestConcurrentGC是一个native方法requestConcurrentGC方法源码)，研究不动，去看调用forceGc的方法。在ActivityThread调用forceGc有两处，一个是handleLowMemory方法，一个是doGcIfNeeded方法

    final void handleLowMemory() {
        ArrayList<ComponentCallbacks2> callbacks = collectComponentCallbacks(true, null);

        final int N = callbacks.size();
        for (int i=0; i<N; i++) {
            callbacks.get(i).onLowMemory();
        }

        // Ask SQLite to free up as much memory as it can, mostly from its page caches.
        if (Process.myUid() != Process.SYSTEM_UID) {
            int sqliteReleased = SQLiteDatabase.releaseMemory();
            EventLog.writeEvent(SQLITE_MEM_RELEASED_EVENT_LOG_TAG, sqliteReleased);
        }

        // Ask graphics to free up as much as possible (font/image caches)
        Canvas.freeCaches();

        // Ask text layout engine to free also as much as possible
        Canvas.freeTextLayoutCaches();

        BinderInternal.forceGc("mem");
    }
    void doGcIfNeeded(String reason) {
        mGcIdlerScheduled = false;
        final long now = SystemClock.uptimeMillis();
        //Slog.i(TAG, "**** WE MIGHT WANT TO GC: then=" + Binder.getLastGcTime()
        //        + "m now=" + now);
        if ((BinderInternal.getLastGcTime()+MIN_TIME_BETWEEN_GCS) < now) {
            //Slog.i(TAG, "**** WE DO, WE DO WANT TO GC!");
            BinderInternal.forceGc(reason);
        }
    }

一：先看doGcIfNeeded，在GcIdler的queueIdle被调用，GcIdler是一个IdleHandler，Handler消息队列空闲时被调用，GcIdler在scheduleGcIdler方法中被添加进消息队列。当handler收到GC_WHEN_IDLE消息时执行scheduleGcIdler，发送这个消息的方法是processInBackground。processInBackground方法在AMS中被调用。

    void scheduleGcIdler() {
        if (!mGcIdlerScheduled) {
            mGcIdlerScheduled = true;
            Looper.myQueue().addIdleHandler(mGcIdler);
        }
        mH.removeMessages(H.GC_WHEN_IDLE);
    }
    public void handleMessage(Message msg) {
            switch (msg.what) {
                 case GC_WHEN_IDLE:
                    scheduleGcIdler();
                    break;
     }
     public void processInBackground() {
            mH.removeMessages(H.GC_WHEN_IDLE);
            mH.sendMessage(mH.obtainMessage(H.GC_WHEN_IDLE));
     }

AMS中performAppGcLocked调用了processInBackground，在这如果是进程的reportLowMemory为true，就会执行scheduleLowMemory。它就会发送LOW_MEMORY消息，去执行handleLowMemory方法，这就是forceGc第二个调用点。在performAppGcsLocked方法中会判断进程的优先级，如果比较低（ADJ值越大，优先级越低），或者进程是reportLowMemory，就会触发GC。ADJ优先级算法可以参考Gityuan大神的解读Android进程优先级ADJ算法。

    final void performAppGcLocked(ProcessRecord app) {
        try {
            app.lastRequestedGc = SystemClock.uptimeMillis();
            if (app.thread != null) {
                if (app.reportLowMemory) {
                    app.reportLowMemory = false;
                    app.thread.scheduleLowMemory();
                } else {
                    app.thread.processInBackground();
                }
            }
        } catch (Exception e) {
            // whatever.
        }
    }
    final void performAppGcsLocked() {
        final int N = mProcessesToGc.size();
        if (N <= 0) {
            return;
        }
        if (canGcNowLocked()) {
            while (mProcessesToGc.size() > 0) {
                ProcessRecord proc = mProcessesToGc.remove(0);
                //ADJ比200大，即优先级比它还低，或者reportLowMemory就通知GC
                if (proc.getCurRawAdj() > ProcessList.PERCEPTIBLE_APP_ADJ || proc.reportLowMemory) {
                    if ((proc.lastRequestedGc+mConstants.GC_MIN_INTERVAL)
                            <= SystemClock.uptimeMillis()) {
                        // To avoid spamming the system, we will GC processes one
                        // at a time, waiting a few seconds between each.
                        performAppGcLocked(proc);
                        scheduleAppGcsLocked();
                        return;
                    } else {
                        // It hasn't been long enough since we last GCed this
                        // process...  put it in the list to wait for its time.
                        addProcessToGcListLocked(proc);
                        break;
                    }
                }
            }

            scheduleAppGcsLocked();
        }
    }

在AMS的doLowMemReportIfNeededLocked方法中reportLowMemory被赋值为true。

 final void doLowMemReportIfNeededLocked(ProcessRecord dyingProc) {
            for (int i = mProcessList.mLruProcesses.size() - 1; i >= 0; i--) {
                ProcessRecord rec = mProcessList.mLruProcesses.get(i);
                if (rec == dyingProc || rec.thread == null) {
                    continue;
                }
                if ((rec.lastLowMemory+mConstants.GC_MIN_INTERVAL) <= now) {
                    rec.reportLowMemory = true;
                    rec.lastLowMemory = now;
                    mProcessesToGc.remove(rec);
                    addProcessToGcListLocked(rec);
                }
            }
  }
 final void appDiedLocked(ProcessRecord app, int pid, IApplicationThread thread,
            boolean fromBinderDied, String reason) {
      boolean doLowMem = app.getActiveInstrumentation() == null;
      if (doLowMem) {
           doLowMemReportIfNeededLocked(app);
      }
  }

有一种情况重建是在app运行过程中，切到设置将权限从允许状态改为禁止状态，这时app的所有进程都会重建，切回app时发现进程重建和栈顶的activity重建。会伴随一点时间的白屏。

观察了微信，没有白屏。有没有大佬知道微信这样是咋处理的。

目前发现有两种解决方法：

1、onCreate 中判断 savedInstanceState 是否为 null。在没有需求使用 savedInstanceState 的情况下，可以这么判断，因为 activity 重建时，安卓系统也会向 savedInstanceState 中传数据，比如 fragmentManager等等。但是如果有需求使用 savedInstanceState 存值的情况，那在判断 savedInstanceState 非空的同时，还需要判断是否有自身需求传入的 key。

2、 在Application 定义一个Boolean类型的属性，isKilled = true 默认为true， 注册 ActivityLifecycleCallbacks 回调，在onActivityCreated 方法，先判断activity 是否是Launch ，若是则将Application.isKilled 赋值为false。若不是Launch 判断 Application.isKilled 是否为true， 若是true 说明 Application 被重建了，这时候跳转到Launch并杀掉刚重建的Activity。

具体实现：自定义 PreventProcessKill 类，并实现 Application.ActivityLifecycleCallbacks 接口

class PreventProcessKill: Application.ActivityLifecycleCallbacks {
    companion object {
        const val TAG = "PreventProcessKill"
    }

    private var activityCount = 0

    override fun onActivityCreated(activity: Activity?, bundle: Bundle?) {
        Logs.e(TAG, "onActivityCreated activity=($activity) bundle=($bundle)")
        if (activity != null && activity is LaunchActivity) {
            if (activityCount == 0 || activity.isTaskRoot()) {
                Logs.e(TAG, "onActivityCreated set isKilled false ")
                MyApplication.isKilled = false
            }
        }
        if (MyApplication.isKilled) {
            Logs.e(TAG, "onActivityCreated isKilled == true, start restartApp")
            // 进程被杀死，重启app
            restartApp(activity);
            return;
        }
    }

    override fun onActivityStarted(activity: Activity?) {
        Logs.e(TAG, "onActivityStarted activity=$activity")
        activityCount++
    }

    override fun onActivityResumed(activity: Activity?) {
        Logs.e(TAG, "onActivityResumed activity=$activity")
    }

    override fun onActivityPaused(activity: Activity?) {
        Logs.e(TAG, "onActivityPaused activity=$activity")
    }

    override fun onActivityStopped(activity: Activity?) {
        Logs.e(TAG, "onActivityStopped activity=$activity")
        activityCount--
    }

    override fun onActivitySaveInstanceState(activity: Activity?, bundle: Bundle?) {
        Logs.e(TAG, "onActivitySaveInstanceState activity=($activity) bundle=($bundle)")
    }

    override fun onActivityDestroyed(activity: Activity?) {
        Logs.e(TAG, "onActivityDestroyed activity=$activity")
    }

    /**
     * 走启动流程
     */
    private fun restartApp(activity: Activity?) {
        val intent = Intent(activity, LaunchActivity::class.java)
        intent.flags = Intent.FLAG_ACTIVITY_CLEAR_TASK or Intent.FLAG_ACTIVITY_NEW_TASK
        activity?.startActivity(intent)
        activity?.overridePendingTransition(0, 0)
        activity?.finish()
    }
}

在 Application 中定义 默认为 true 的 isKilled 属性。

public class MyApplication extends MultiDexApplication {
    public boolean isKilled = true;
}

我认为第二种方法比第一种要好。

Android - 禁用权限后，进程被杀？

回复 Reginer

在基类onCreate中：

 if (savedInstanceState != null) {
            if (simpleRelaunchEnable()) {
                simpleRelaunch(savedInstanceState)
                return
            }
        }

 protected open fun simpleRelaunch(savedInstanceState: Bundle?) {
        //重启并清空任务栈
        val intent = Intent(this, PackConfig.getConfigModel().splashActivity)
        intent.addFlags(Intent.FLAG_ACTIVITY_CLEAR_TASK or Intent.FLAG_ACTIVITY_NEW_TASK)
        startActivity(intent)
        finish()

    }

可能不是很规范，但是能避免因为页面被回收导致的崩溃问题。我也观察过一些主流应用，页面被回收确实新新开页面的。

其实我已经不太关心activity生命周期了，jetpack解放了我