App startup page optimization

Time:2021-5-1

There are many app startup pages that are still the same splash activity, and then jump to mainactivity. First, splash loads the data once, and then it loads the data after entering main, so you have to wait for two loads. What if the reverse is true

Here, mainactivity can be loaded first, and then spashactivity can be triggered. Of course, there are also defects. Some mainactivities may load a large amount of data, which will cause stuck before entering splash. Therefore, spashactivity is usually changed into spashfragment in the same layout

In this way, the default layout is the splash page, and then the data in main is loaded at the same time. After the completion of splash, main has been initialized completely, so it does not need to be loaded at the next time, and can be displayed directly. This step saves a lot of waiting time, which is much more practical and effective than other fancy optimization

 

The implementation is also relatively simple. Add a layer of layout to your original mainactivity layout

App startup page optimizationApp startup page optimization

View Code

Then the splash fragment is added to the container dynamically

 

In this way, the startup page displays the execution by default

Then close the startup page after loading the simulation data, and directly display the main activity layout after removing the splash fragment

App startup page optimizationApp startup page optimization

class SplashFragment : BaseBindFragment() {

    override fun layoutId() = R.layout.fragment_splash

    override fun providerVMClass() = SplashViewModel::class.java

    override fun initData(bundle: Bundle?) {
        binding.model = mViewModel
        //Simulate loading picture
        var count = 0f
        val mHandler = Handler(Looper.getMainLooper())
        val mRunnable = object :Runnable {
            override fun run() {
                count+=20
                binding.pbTime.setProgress(count)
                if (count >= binding.pbTime.getMax()) {
                    mHandler.removeCallbacks(this)
                    activity!!.window.setBackgroundDrawableResource(R.color.white)
                    //Remove startup page
                    activity!!.supportFragmentManager.beginTransaction().remove([email protected]).commitAllowingStateLoss()
                }else{
                    mHandler.postDelayed(this,500)
                }
            }
        }
        mHandler.postDelayed(mRunnable,500)
    }

}

View Code

If the load in mainactivity is too large, you should optimize your own startup loading process. Is it possible that the loading will not jam and save the loading time

github:https://github.com/1024477951/KotlinStrong

Recommended Today

Looking for frustration 1.0

I believe you have a basic understanding of trust in yesterday’s article. Today we will give a complete introduction to trust. Why choose rust It’s a language that gives everyone the ability to build reliable and efficient software. You can’t write unsafe code here (unsafe block is not in the scope of discussion). Most of […]