Android 启动优化——深入理解布局优化_android 异步inflate

  1. 渐进式加载
  2. 异步加载
  3. compose 声明式 UI

渐进式加载

什么是渐进式加载

渐进式加载,简单来说,就是一部分一部分加载,当前帧加载完成之后,再去加载下一帧。

一种极致的做法是,加载 xml 文件,就想加载一个空白的 xml,布局全部使用 ViewStub 标签进行懒加载。

这样设计的好处是可以减缓同一时刻,加载 View 带来的压力,通常的做法是我们先加载核心部分的 View,再逐步去加载其他 View。

有人可能会这样问了,这样的设计很鸡肋,有什么用呢?

确实,在高端机上面作用不明显,甚至可能看不出来,但是在中低端机上面,带来的效果还是很明显的。在我们项目当中,复杂的页面首帧耗时约可以减少 30%。

优点:适配成本低,在中低端机上面效果明显。

缺点:还是需要在主线程读取 xml 文件

核心伪代码

start(){
    loadA(){
        loadB(){
            loadC()
        }
    }
}

上面的这种写法,是可以的,但是这种做法,有一个很明显的缺点,就是会造成回调嵌套层数过多。当然,我们也可以使用 RxJava 来解决这种问题。但是,如果项目中没用 Rxjava,引用进来,会造成包 size 增加。

一个简单的做法就是使用队列的思想,将所有的 ViewStubTask 添加到队列当中,当当前的 ViewStubTask 加载完成,才加载下一个,这样可以避免回调嵌套层数过多的问题。

改造之后的代码见

val decorView = this.window.decorView
ViewStubTaskManager.instance(decorView)
            .addTask(ViewStubTaskContent(decorView))
            .addTask(ViewStubTaskTitle(decorView))
            .addTask(ViewStubTaskBottom(decorView))
            .start()

class ViewStubTaskManager private constructor(val decorView: View) : Runnable {

    private var iViewStubTask: IViewStubTask? = null

    companion object {

        const val TAG = "ViewStubTaskManager"

        @JvmStatic
        fun instance(decorView: View): ViewStubTaskManager {
            return ViewStubTaskManager(decorView)
        }
    }

    private val queue: MutableList<ViewStubTask> = CopyOnWriteArrayList()
    private val list: MutableList<ViewStubTask> = CopyOnWriteArrayList()

    fun setCallBack(iViewStubTask: IViewStubTask?): ViewStubTaskManager {
        this.iViewStubTask = iViewStubTask
        return this
    }

    fun addTask(viewStubTasks: List<ViewStubTask>): ViewStubTaskManager {
        queue.addAll(viewStubTasks)
        list.addAll(viewStubTasks)
        return this
    }

    fun addTask(viewStubTask: ViewStubTask): ViewStubTaskManager {
        queue.add(viewStubTask)
        list.add(viewStubTask)
        return this
    }

    fun start() {
        if (isEmpty()) {
            return
        }
        iViewStubTask?.beforeTaskExecute()
        // 指定 decorView 绘制下一帧的时候会回调里面的 runnable
        ViewCompat.postOnAnimation(decorView, this)
    }

    fun stop() {
        queue.clear()
        list.clear()
        decorView.removeCallbacks(null)
    }

    private fun isEmpty() = queue.isEmpty() || queue.size == 0

    override fun run() {
        if (!isEmpty()) {
            // 当队列不为空的时候,先加载当前 viewStubTask
            val viewStubTask = queue.removeAt(0)
            viewStubTask.inflate()
            iViewStubTask?.onTaskExecute(viewStubTask)
            // 加载完成之后,再 postOnAnimation 加载下一个
            ViewCompat.postOnAnimation(decorView, this)
        } else {
            iViewStubTask?.afterTaskExecute()
        }

    }

    fun notifyOnDetach() {
        list.forEach {
            it.onDetach()
        }
        list.clear()
    }

    fun notifyOnDataReady() {
        list.forEach {
            it.onDataReady()
        }
    }

}

interface IViewStubTask {

    fun beforeTaskExecute()

    fun onTaskExecute(viewStubTask: ViewStubTask)

    fun afterTaskExecute()

}

源码地址:github.com/gdutxiaoxu/… ViewStubTaskViewStubTaskManager**, 有兴趣的可以看看

异步加载

异步加载,简单来说,就是在子线程创建 View。在实际应用中,我们通常会先预加载 View,常用的方案有:

  1. 在合适的时候,启动子线程 inflate layout。然后取的时候,直接去缓存里面查找 View 是否已经创建好了,是的话,直接使用缓存。否则,等待子线程 inlfate 完成。

AsyncLayoutInflater

官方提供了一个类,可以来进行异步的inflate,但是有两个缺点:

  1. 每次都要现场new一个出来
  2. 异步加载的view只能通过callback回调才能获得(死穴)

因此,我们可以仿造官方的 AsyncLayoutInflater 进行改造。核心代码在 AsyncInflateManager。主要介绍两个方法。

asyncInflate 方法,在子线程 inflateView,并将加载结果存放到 mInflateMap 里面。

    @UiThread
fun asyncInflate(
        context: Context,
        vararg items: AsyncInflateItem?
    ) {
        items.forEach { item ->
            if (item == null || item.layoutResId == 0 || mInflateMap.containsKey(item.inflateKey) || item.isCancelled() || item.isInflating()) {
                return
            }
            mInflateMap[item.inflateKey] = item
            onAsyncInflateReady(item)
            inflateWithThreadPool(context, item)
        }

    }

getInflatedView 方法,用来获得异步inflate出来的view,核心思想如下

  • 先从缓存结果里面拿 View,拿到了view直接返回
  • 没拿到view,但是子线程在inflate中,等待返回
  • 如果还没开始inflate,由UI线程进行inflate
    /**
     * 用来获得异步inflate出来的view
     *
     * @param context
     * @param layoutResId 需要拿的layoutId
     * @param parent      container
     * @param inflateKey  每一个View会对应一个inflateKey,因为可能许多地方用的同一个 layout,但是需要inflate多个,用InflateKey进行区分
     * @param inflater    外部传进来的inflater,外面如果有inflater,传进来,用来进行可能的SyncInflate,
     * @return 最后inflate出来的view
     */
    @UiThread
    fun getInflatedView(
        context: Context?,
        layoutResId: Int,
        parent: ViewGroup?,
        inflateKey: String?,
        inflater: LayoutInflater
    ): View {
        if (!TextUtils.isEmpty(inflateKey) && mInflateMap.containsKey(inflateKey)) {
            val item = mInflateMap[inflateKey]
            val latch = mInflateLatchMap[inflateKey]
            if (item != null) {
                val resultView = item.inflatedView
                if (resultView != null) {
                    //拿到了view直接返回
                    removeInflateKey(item)
                    replaceContextForView(resultView, context)
                    Log.i(TAG, "getInflatedView from cache: inflateKey is $inflateKey")
                    return resultView
                }

                if (item.isInflating() && latch != null) {
                    //没拿到view,但是在inflate中,等待返回
                    try {
                        latch.await()
                    } catch (e: InterruptedException) {
                        Log.e(TAG, e.message, e)
                    }
                    removeInflateKey(item)
                    if (resultView != null) {
                        Log.i(TAG, "getInflatedView from OtherThread: inflateKey is $inflateKey")
                        replaceContextForView(resultView, context)
                        return resultView
                    }
                }

                //如果还没开始inflate,则设置为false,UI线程进行inflate
                item.setCancelled(true)
            }
        }
        Log.i(TAG, "getInflatedView from UI: inflateKey is $inflateKey")
        //拿异步inflate的View失败,UI线程inflate
        return inflater.inflate(layoutResId, parent, false)
    }

简单 Demo 示范

第一步:选择在合适的时机调用 AsyncUtils#asyncInflate 方法预加载 View,

object AsyncUtils {

    fun asyncInflate(context: Context) {
        val asyncInflateItem =
            AsyncInflateItem(
                LAUNCH_FRAGMENT_MAIN,
                R.layout.fragment_asny,
                null,
                null
            )
        AsyncInflateManager.instance.asyncInflate(context, asyncInflateItem)
    }

    fun isHomeFragmentOpen() =
        getSP("async_config").getBoolean("home_fragment_switch", true)
}

第二步:在获取 View 的时候,先去缓存里面查找 View

    override fun onCreateView(
        inflater: LayoutInflater, container: ViewGroup?,
        savedInstanceState: Bundle?
    ): View? {
        // Inflate the layout for this fragment
        val startTime = System.currentTimeMillis()
        val homeFragmentOpen = AsyncUtils.isHomeFragmentOpen()
        val inflatedView: View

        inflatedView = AsyncInflateManager.instance.getInflatedView(
            context,
            R.layout.fragment_asny,
            container,
            LAUNCH_FRAGMENT_MAIN,
            inflater
        )

        Log.i(
            TAG,
            "onCreateView: homeFragmentOpen is $homeFragmentOpen, timeInstance is ${System.currentTimeMillis() - startTime}, ${inflatedView.context}"
        )
        return inflatedView
//        return inflater.inflate(R.layout.fragment_asny, container, false)
    }

优缺点

优点

可以大大减少 View 创建的时间,使用这种方案之后,获取 View 的时候基本在 10ms 之内的。

缺点

  1. 由于 View 是提前创建的,并且会存在在一个 map,需要根据自己的业务场景将 View 从 map 中移除,不然会发生内存泄露
  2. View 如果缓存起来,记得在合适的时候重置 view 的状态,不然有时候会发生奇奇怪怪的现象。

总结

参考文章:Android - 一种新奇的冷启动速度优化思路(Fragment极度懒加载 + Layout子线程预加载)")

  1. View 的渐进式加载,在 JectPack compose 没有推广之后,推荐使用这种方案,适配成本低
  2. View 的异步加载方案,虽然效果显著,但是适配成本也高,没搞好,容易发生内存泄露
  3. JectPack compose 声明式 UI,基本是未来的趋势,有兴趣的可以提前了解一下他。

Talk is cheap. Show me the code

源码地址:github.com/gdutxiaoxu/…

总结

最后为了帮助大家深刻理解Android相关知识点的原理以及面试相关知识,这里放上相关的我搜集整理的24套腾讯、字节跳动、阿里、百度2019-2021面试真题解析,我把技术点整理成了视频和PDF(实际上比预期多花了不少精力),包知识脉络 + 诸多细节

还有 高级架构技术进阶脑图、Android开发面试专题资料 帮助大家学习提升进阶,也节省大家在网上搜索资料的时间来学习,也可以分享给身边好友一起学习。

一线互联网面试专题

379页的Android进阶知识大全

379页的Android进阶知识大全

网上学习 Android的资料一大堆,但如果学到的知识不成体系,遇到问题时只是浅尝辄止,不再深入研究,那么很难做到真正的技术提升。希望这份系统化的技术体系对大家有一个方向参考。

2021年虽然路途坎坷,都在说Android要没落,但是,不要慌,做自己的计划,学自己的习,竞争无处不在,每个行业都是如此。相信自己,没有做不到的,只有想不到的。祝大家2021年万事大吉。

roid开发面试专题资料** 帮助大家学习提升进阶,也节省大家在网上搜索资料的时间来学习,也可以分享给身边好友一起学习。

[外链图片转存中…(img-lGA2bv87-1718769249707)]

[外链图片转存中…(img-VYwVrdYG-1718769249707)]

[外链图片转存中…(img-gPh6muWs-1718769249708)]

网上学习 Android的资料一大堆,但如果学到的知识不成体系,遇到问题时只是浅尝辄止,不再深入研究,那么很难做到真正的技术提升。希望这份系统化的技术体系对大家有一个方向参考。

2021年虽然路途坎坷,都在说Android要没落,但是,不要慌,做自己的计划,学自己的习,竞争无处不在,每个行业都是如此。相信自己,没有做不到的,只有想不到的。祝大家2021年万事大吉。

### 优化 Android RecyclerView 的性能 为了提升 `RecyclerView` 的滚动流畅性和整体性能,开发者可以采用多种技术手段。以下是一些经过验证的优化策略。 #### 1. 使用 ViewHolder 模式减少 findViewById 调用 `RecyclerView` 内置了 `ViewHolder` 模式,它能够缓存视图引用,避免频繁调用 `findViewById()`,从而显著提高性能。通过在 `onCreateViewHolder` 中初始化视图并在 `onBindViewHolder` 中复用这些引用,可以有效降低 UI 渲染延迟。 ```java public class MyAdapter extends RecyclerView.Adapter<MyAdapter.MyViewHolder> { private List<String> mData; public static class MyViewHolder extends RecyclerView.ViewHolder { public TextView textView; public MyViewHolder(View view) { super(view); textView = view.findViewById(R.id.text_view); // 只初始化一次 } } @Override public MyViewHolder onCreateViewHolder(ViewGroup parent, int viewType) { View itemView = LayoutInflater.from(parent.getContext()).inflate(R.layout.item_layout, parent, false); return new MyViewHolder(itemView); } @Override public void onBindViewHolder(MyViewHolder holder, int position) { holder.textView.setText(mData.get(position)); // 直接使用已缓存的引用 } @Override public int getItemCount() { return mData.size(); } } ``` #### 2. 避免重复加载数据 —— 利用 setTag/getTag 标记状态 在 `onBindViewHolder` 中,可以通过 `setTag()` 和 `getTag()` 方法标记当前项是否已经完成数据绑定或资源加载。这样可以在视图复用时跳过不必要的操作,例如图片下载或复杂布局的重新计算[^3]。 ```java @Override public void onBindViewHolder(@NonNull MyViewHolder holder, int position) { MyItem item = items.get(position); if (holder.itemView.getTag() == null || !holder.itemView.getTag().equals(item.getId())) { loadImage(holder.imageView, item.getImageUrl()); holder.itemView.setTag(item.getId()); // 标记为已加载 } } ``` #### 3. 启用 ItemAnimator 并优化动画效果 默认情况下,`RecyclerView` 包含一个 `DefaultItemAnimator` 来处理添加、移除和更新条目时的动画。如果不需要复杂的动画,可以禁用以减少 CPU/GPU 开销;若需要自定义动画,则应确保其轻量且高效。 ```java recyclerView.setItemAnimator(new DefaultItemAnimator()); // 或者完全禁用动画 recyclerView.setItemAnimator(null); ``` #### 4. 使用 DiffUtil 实现高效的列表差异检测 当数据集发生变化时,直接调用 `notifyDataSetChanged()` 会刷新整个列表,效率低下。推荐使用 `DiffUtil` 来计算新旧数据之间的差异,并只更新变化的部分,这能显著减少不必要的绘制和绑定操作。 ```java DiffUtil.DiffResult diffResult = DiffUtil.calculateDiff(new MyDiffCallback(oldList, newList)); diffResult.dispatchUpdatesTo(myAdapter); ``` #### 5. 启用预加载与设置合适的 LayoutManager 缓存策略 `LinearLayoutManager` 和 `GridLayoutManager` 支持设置额外的预加载项数量(`setInitialPrefetchItemCount()`),提前加载即将显示的视图,有助于提升滑动体验。此外,还可以调整 `RecyclerView` 的缓存大小(如 `setItemViewCacheSize()`)来平衡内存占用与性能。 ```java LinearLayoutManager layoutManager = new LinearLayoutManager(context); layoutManager.setInitialPrefetchItemCount(4); // 提前加载 4 个 item recyclerView.setLayoutManager(layoutManager); ``` #### 6. 图片加载优化异步处理 对于包含大量图片的 `RecyclerView`,应使用 Glide、Picasso 等库进行异步加载,并启用内存/磁盘缓存机制。同时,在 `onViewRecycled()` 中取消未完成的加载任务,防止内存泄漏。 ```java @Override public void onViewRecycled(@NonNull MyViewHolder holder) { Glide.with(holder.imageView.getContext()).clear(holder.imageView); super.onViewRecycled(holder); } ``` #### 7. 减少布局层级与控件复杂度 简化每个 item 的布局结构,避免嵌套过多的 ViewGroup。使用 `ConstraintLayout` 可以帮助构建扁平化且灵活的界面,从而减少测量和绘制时间。 --- ###
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值