2024年鸿蒙最全你怎么看 App响应时间优化这事?,2024年最新阿里四轮面试

img
img

网上学习资料一大堆,但如果学到的知识不成体系,遇到问题时只是浅尝辄止,不再深入研究,那么很难做到真正的技术提升。

需要这份系统化的资料的朋友,可以戳这里获取

一个人可以走的很快,但一群人才能走的更远!不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人,都欢迎加入我们的的圈子(技术交流、学习资源、职场吐槽、大厂内推、面试辅导),让我们一起学习成长!

  • 1.懒加载
  • 2.分段加载(部分加载)
  • 3.预加载(数据、布局页面等)
2.2.1 懒加载

对于一些不常用或者不重要的数据、图片、控件以及其他一些资源,我们可以在用到时再进行加载。

1.数据懒加载

  • kotlin中的lazy标签:修饰val变量,程序第一次使用到这个变量(或者对象)时再初始化。
  • Map、List和SharedPreferences等大数据的延迟初始化。
private Map getSystemSettings() {
    if (mSettingMap == null) {
        mSettingMap = initSystemSettings();
    }
    return mSettingMap;
}

2.图片资源懒加载

  • 对于不常用的图片,可以使用云端图片的资源url来替代。
  • 对于非程序预置的图片(本地图片文件或者云端图片),用到时再加载。

3.控件懒加载

  • 使用ViewStub进行布局的延迟加载。
  • 使用ViewPager2+Fragment进行Fragment的懒加载。
  • 使用RecyclerView替代ListView。
2.2.2 分段加载

分段加载常见应用于大数据的加载,这里包括大图和长视频等多媒体资源的加载。做到用到哪,加载到哪,完全不必要等全部加载完才给用户使用。

1.大图的分段加载:对于大图,我们可以将其按一定尺寸进行切分,分割成一块一块的小瓦片,然后设定一个预览预加载范围,用户预览到哪里我们就加载到哪里。(就类似地图的加载)

2.长视频的分段加载:对于长视频,我们可以将其按时间片进行拆分,并设置一个加载缓存池。这样用户浏览一个长视频时,就可以快速打开加载。

3.大文件或者长WebView的分段加载:对于一些阅读类的app,经常会遇到大文件和长WebView的加载,这里我们也可以同理对其进行拆分处理。

2.2.3 预加载

分段加载常和预加载一起组合使用。对于一些加载非常耗时的内容,我们可以将加载时机提前,从而减小用户感知的加载时间。

预加载的本质是提前加载,这样这个提前加载的时机就非常的关键和重要。因为预加载时机如果太晚,几乎看不出效果;但是如果预加载的时机过早,有可能抢占其他模块资源,造成资源紧张。

那么我们何时可以触发预加载,预加载的时机是什么呢?下面我举几个简单的例子。

1.用户操作时。如果用户点击了第2章,我们就开始预加载下一章和上一章;用户上滑到了第3页,我们预加载第4页,用户下滑到第5页,我们预加载第4页.

2.应用空闲时。例如之前说的IdleHandler。或者在onUserInteraction中监听用户的操作,一段时间没有操作即视为空闲。

3.耗时等待时。对于一些常见的耗时操作,我们可以在其开始时,并行进行一些预加载操作,从而提高时间的利用率。例如Activity的创建比较耗时,我们可以在startActivity前就开始预加载数据,这样Activity创建完之后有可能数据就已经加载好了,直接可以拿来渲染。例如一些有开屏广告的app,可以在广告开始时,同步进行一些数据资源的预加载。

2.3 数据结构

  • 1.数据结构优化(空间大小、读取速度、复用性、扩展性)。
  • 2.数据缓存(内存缓存、磁盘缓存、网络缓存),分段缓存。这里可以参考glide.
  • 3.锁优化(减少过度锁,避免死锁),悲观锁/乐观锁。
  • 4.内存优化,避免内存抖动,频繁GC(尤其关注bitmap)
2.3.1 数据结构优化

不同的数据结构有不同的使用场景,选择适合的数据结构能够事半功倍。

1.ArrayList和LinkedList:

  • ArrayList:底层数据结构是数组,查询快、增删慢。
  • LinkedList:底层数据结构是链表,查询慢、增删快。

2.HashMap和SparseArray:

  • HashMap:底层数据结构是数组和链表(或红黑树)的组合,结合了ArrayList和LinkedList的优点,查询快、增删也快。但是扩容很耗性能,且空间利用率不高(75%),浪费内存。
  • SparseArray:底层数据结构是双数组,一个数组存key,一个数组存value。使用二分法查询进行优化,在数据量小(一百条以下)的情况下,速度和HashMap相当,但是空间利用率大大提升。
  • ArrayMap:底层数据结构是双数组,一个数组存key的hash值,一个数组存value。设计与SparseArray类似,在数据量小的情况下,可完全替代HashMap。

3.Set: 保证每个元素都必须是唯一的。

4.TreeSet和TreeMap:有序的集合,保证存放的元素是排过序的,速度慢于HashSet和HashMap。

可以看到,在不考虑空间利用率的情况下,HashMap的性能是不错的。

但是由于存在初始化大小和扩展因子对其性能有所影响,我们在使用时,尽量根据实际需要设置合理的初始化大小:避免设置小了扩容带来性能消耗,设置大了造成空间浪费。

因为HashMap的默认扩容因子是0.75,如果你实际使用的数量是8,那你初始化大小就设置16;如果你实际使用的数量是60,那你初始化大小就设置128。

2.3.2 数据缓存

对于一些变化不是很频繁的数据资源,我们可以将其缓存下来。这样我们下次需要使用它们的时候,就可以直接读取缓存,这样极大地减少了加载和渲染所需要的时间。

一般意义上的缓存,按读取的时间由快到慢,我们可分为内存缓存、磁盘缓存、网络缓存。

  • 内存缓存,就是存储在内存中,我们可以直接读取使用。而如果从界面渲染的角度,我们又可以将内存缓存分为Active(活跃/正在显示)缓存和InActive(非活跃/不可显示)缓存。
  • 磁盘缓存,就是存储在磁盘文件中,每次读取都需要将磁盘文件内容读取到内存中,方可使用。
  • 网络缓存,就是存储在远端服务器中,每次读取需要我们进行一次网络请求。一般来说,我们也可以将一次网络缓存请求到的数据缓存到磁盘中,将网络缓存转化为磁盘缓存,通过减少网络请求,来提升读取速度。

某种意义上来说,内存缓存、磁盘缓存和网络缓存,它们又是可以相互转化的,一般来说,我们会将网络缓存->磁盘缓存->内存缓存,进行使用,从而提升读取速度。

具体我们可以参考glide框架和RecyclerView的实现原理。

2.3.3 锁优化

锁是我们解决并发的重要手段,但是如果滥用锁的话,很可能造成执行效率下降,更严重的可能造成死锁等无法挽回的场景。

当我们需要处理高并发的场景时,同步调用尤其需要考量锁的性能损耗:

  • 能用无锁数据结构,就不要用锁。
  • 缩小锁的范围。能锁区块,就不要锁住方法体;能用对象锁,就不要用类锁。

那么我们具体应该怎么做呢?下面我简单讲几个例子。

1.使用乐观锁代替悲观锁,轻量级锁代替重量级锁。

利用CAS机制, 全称是Compare And Swap,即先比较,然后再替换。就是每次执行或者修改某个变量时,我们都会将新旧值进行比较,如果发生偏移了就更新。这就好比在一些无锁的数据库中,每次的数据库操作都会携带一个唯一的版本号,每次进行数据库修改的时候都会对比一下数据库记录和操作请求的版本号,如果版本号是最新的版本号,则进行修改,否则丢弃。

需要注意的是,CAS必须借助volatile才能读取到共享变量的最新值来实现【比较并交换】的效果,因为volatile会保证变量的可见性。

在Java中,JDK给我们默认提供了一些CAS机制实现的原子类,如AtomicIntegerAtomicReference等。

2.缩小同步范围,避免直接使用synchronized,即使使用也要尽量使用同步块而不是同步方法。多使用JDK提供给我们的同步工具:CountDownLatch,CyclicBarrier,ConcurrentHashMap。

3.针对不同使用场景,使用不同类型的锁。

  • 针对并发读多,写少的,我们可以使用读写锁(多个读锁不互斥,读锁与写锁互斥):ReentrantReadWriteLock,CopyOnWriteArrayList,CopyOnWriteArraySet。
  • 针对某一个并发操作通常由某一特定线程执行时,可尝试使用偏向锁(偏向于第一个获得它的线程)。
  • 针对存在大量并发资源竞争的场景,推荐使用重量级锁synchronized。
2.3.4 内存优化

内存优化的核心是避免内存抖动。不合理的内存分配、内存泄漏、对象的频繁创建和销毁,都会导致内存发生抖动,最终导致系统的频繁GC。

频繁的GC,必定会导致系统运行效率的下降,严重的可能会导致页面卡顿,造成不好的用户体验。那么我们应该着手从哪些地方进行优化呢?

  • 解决应用的内存泄漏问题。这里我们可以使用LeakCanary 或者 Android Profile 等工具来检查我们查询可能存在的内存泄漏。
  • 平时编码应当注意避免内存泄漏。如避免全局静态变量和常量、单例持有资源对象(Activity,Fragment,View等),资源使用完立即释放或者recycle(回收)等。
  • 避免创建大内存对象,频繁创建和释放对象(尤其是在循环体内),频繁创建的对象需要考虑复用或者使用缓存。
  • 加载图片可以适当降低图片质量,小图标尽量使用SVG,大图/复杂的图片考虑使用webp。尽量使用图片加载框架,如glide,这些框架都会帮我们进行加载优化。
  • 避免大量bitmap的绘制。
  • 避免在自定义View的onMeasureonLayoutonDraw中创建对象。
  • 使用SpareArray、ArrayMap替代HashMap。
  • 避免进行大量的字符串操作,特别是序列化和反序列化。不要使用+(加号)进行字符串拼接。
  • 使用线程池(可设置适当的最大线程池数)执行线程任务,避免大量Thread的创建及泄漏。

2.4 线程/IO

  • 1.线程优化(统一、优先级调度、任务特性)
  • 2.IO优化(网络IO和磁盘IO),核心是减少IO次数
    • 网络:请求合并,请求链路优化,请求体优化,系列化和反序列化优化,请求复用等。
    • 磁盘:文件随机读写、SharePreference读写等(例如对于读多写少的,可使用内存缓存)
  • 3.log优化(循环中的log打印,不必要的log打印,log等级)
2.4.1 线程优化

当我们创建一个线程时,需要向系统申请资源,分配内存空间,这是一笔不小的开销,所以我们平时开发的过程中都不会直接操作线程,而是选择使用线程池来执行任务。所以线程优化的本质是对线程池的优化。

线程池使用的最大问题就在于如果线程池设置不对的话,很容易被人滥用,引发内存溢出的问题。而且通常一个应用会有多个线程池,不同功能、不同模块乃至是不同三方库都会有自己的线程池,这样大家各用各的,就很难做到资源的协调统一,劲不往一处使。

那么我们应该如何进行线程池优化呢?

1.建立主线程池+副线程池的组合线程池,由线程池管理者统一协调管理。主线程池负责优先级较高的任务,副线程池负责优先级不高以及被主线程池拒绝降级下来的任务。

这里执行的任务都需要设置优先级,任务优先级的调度通过PriorityBlockingQueue队列实现,以下是主副线程池的设置,仅供参考:

  • 主线程池:核心线程数和最大线程数:2n(n为CPU核心数),60s keepTime,PriorityBlockingQueue(128)。
  • 副线程池:核心线程数和最大线程数:n(n为CPU核心数),60s keepTime,PriorityBlockingQueue(64)。

2.使用Hook的方式,收集应用内所以使用newThread方法的地方,改为由线程池管理者统一协调管理。

3.将所有提供了设置线程池接口的第三方库,通过其开放的接口,设置为线程池管理者管理。没有提供设置接口的,考虑替换库或者插桩的方式,替换线程池的使用。

2.4.2 IO优化

IO优化的核心是减少IO次数。

1.网络请求优化。

  • 避免不必要的网络请求。对于那些非必要执行的网络请求,可以延时请求或者使用缓存。
  • 对于需要进行多次串行网络请求的接口进行优化整合,控制好请求接口的粒度。比如后台有获取用户信息的接口、获取用户推荐信息的接口、获取用户账户信息的接口。这三个接口都是必要的接口,且存在先后关系。如果依次进行三次请求,那么时间基本上都花在网络传输上,尤其是在网络不稳定的情况下耗时尤为明显。但如果将这三个接口整合为获取用户的启动(初始化)信息,这样数据在网络中传输的时间就会大大节省,同时也能提高接口的稳定性。

2.磁盘IO优化

  • 避免不必要的磁盘IO操作。这里的磁盘IO包括:文件读写、数据库(sqlite)读写和SharePreference等。
  • 对于数据加载,选择合适的数据结构。可以选择支持随机读写、延时解析的数据存储结构以替代SharePreference。
  • 避免程序执行出现大量的序列化和反序列化(会造成大量的对象创建)。

2.5 页面渲染

下面是我简单列举的几点加快页面渲染的方法,相信大家或多或少都用过,这里我就不详细阐述了:

  • 1.降低布局层级、减少嵌套、避免过度渲染(背景)(merge,ConstraintLayout)
  • 2.页面复用(include)
  • 3.页面懒加载
  • 4.布局延迟加载(ViewStub)
  • 5.inflate优化(布局预加载+异步加载,动态new控件/X2C)
  • 6.动画优化(注意动画的执行耗时和内存占用,不可见时暂停动画,可见时再恢复动画)
  • 7.自定义view优化(减少onDraw、onLayout、onMeasure的对象创建和执行耗时)
  • 8.bitmap和canvas优化(bitmap大小、质量、压缩、复用;canvas复用:clipRect,translate)
  • 9.RecycleView优化(减少刷新次数,缓存复用)

其实想要全面掌握好 Android 性能优化的话,这些知识点你必须要有所了解,如: 内存优化、网络优化、卡顿优化、存储优化……等,为了让大家一次都可以了解全,所以将其整合成名为《Android 性能优化核心知识点手册》,大家可以参考下:

《APP 性能调优进阶手册》:https://qr18.cn/FVlo89

启动优化

内存优化

UI优化

网络优化

Bitmap优化与图片压缩优化

多线程并发优化与数据传输效率优化

体积包优化

深知大多数程序员,想要提升技能,往往是自己摸索成长,但自己不成体系的自学效果低效又漫长,而且极易碰到天花板技术停滞不前!


img
img

既有适合小白学习的零基础资料,也有适合3年以上经验的小伙伴深入学习提升的进阶课程,涵盖了95%以上鸿蒙开发知识点,真正体系化!

由于文件比较多,这里只是将部分目录截图出来,全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频,并且后续会持续更新

需要这份系统化的资料的朋友,可以戳这里获取

(https://img-blog.csdnimg.cn/direct/743b668910224b259a5ffe804fa6d0db.png)
[外链图片转存中…(img-jZZPuYee-1715730318015)]
[外链图片转存中…(img-kXT0ILc2-1715730318016)]

既有适合小白学习的零基础资料,也有适合3年以上经验的小伙伴深入学习提升的进阶课程,涵盖了95%以上鸿蒙开发知识点,真正体系化!

由于文件比较多,这里只是将部分目录截图出来,全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频,并且后续会持续更新

需要这份系统化的资料的朋友,可以戳这里获取

  • 24
    点赞
  • 20
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值