app优化(uniapp优化)
本文目录一览:
Android App内存优化
内存优化就是对内存问题的一个预防和解决,做内存优化能让应用挂得少、活得好和活得久。
挂的少:
“挂”指的是 Crash,内存问题导致 Crash 的具体表现就是内存溢出异常 OOM。
活得好:
活得好指的是使用流畅,Android 中造成界面卡顿的原因有很多种,其中一种就是由内存问题引起的。内存问题之所以会影响到界面流畅度,是因为垃圾回收(GC,Garbage Collection),在 GC 时,所有线程都要停止,包括主线程,当 GC 和绘制界面的操作同时触发时,绘制的执行就会被搁置,导致掉帧,也就是界面卡顿。
活得久:
活得久指的是我们的应用在后台运行时不会被干掉。Android 会按照特定的机制清理进程,清理进程时优先会考虑清理后台进程。清理进程的机制就是LowMemoryKiller。在 Android 中不同的进程有着不同的优先级,当两个进程的优先级相同时,低杀会优先考虑干掉消耗内存更多的进程。也就是如果我们应用占用的内存比其他应用少,并且处于后台时,我们的应用能在后台活下来,这也是内存优化为我们应用带来竞争力的一个直接体现。
内存占用是否越少越好?
当系统 内存充足 的时候,我们可以多用 一些获得更好的性能。当系统 内存不足 的时候,我们希望可以做到 ”用时分配,及时释放“。内存优化并不能一刀切。
我们都知道,应用程序的内存分配和垃圾回收都是由Android虚拟机完成的,在Android 5.0以下,使用的是Dalvik虚拟机,5.0及以上,则使用的是ART虚拟机。
Android虚拟机Dalvik和ART
1、内存区域划分
详细请看以下两篇文章(建议全看):
java内存四大区_JVM内存区域划分
Android 内存机制
2、内存回收
垃圾收集的标记算法(找到垃圾):
垃圾收集算法(回收垃圾):
引用类型:强引用、软引用、弱引用、虚引用
对象的有效性=可达性+引用类型
JAVA垃圾回收机制-史上最容易理解看这一篇就够了
Android:玩转垃圾回收机制与分代回收策略
android中还存在低杀机制,这种情况属于系统整机内存不足,直接把应用进程杀掉的情况。
Android后台杀死系列:LowMemoryKiller原理
1、内存溢出
系统会给每个App分配内存空间也就是heap size值,当app占用的内存加上申请的内存超过这个系统分配的内存限额,最终导致OOM(OutOfMemory)使程序崩溃。
通过命令 getprop |grep dalvik.vm.heapsize 可以获取系统允许的最大
注意:在设置了heapgrowthlimit的状况下,单个进程可用最大内存为heapgrowthlimit值。在android开发中,若是要使用大堆,须要在manifest中指定android:largeHeap为true,这样dvm heap最大可达heapsize。
关于heapsize heapgrowthlimit
2、内存泄漏
Android系统虚拟机的垃圾回收是通过虚拟机GC机制来实现的。GC会选择一些还存活的对象作为内存遍历的根节点GC Roots,通过对GC Roots的可达性来判断是否需要回收。内存泄漏就是 在当前应用周期内不再使用的对象被GC Roots引用,造成该对象无法被系统回收,以致该对象在堆中所占用的内存单元无法被释放而造成内存空间浪费,使实际可使用内存变小。简言之,就是 对象被持有导致无法释放或不能按照对象正常的生命周期进行释放。
Android常见内存泄漏汇总
3、内存抖动
指的是在短时间内大量的新对象被实例化,运行时可能无法承载这样的内存分配,在这种情况下就会导致垃圾回收事件被大量调用,影响到应用程序的UI和整体性能,最终可能导致卡顿和OOM。
常见情况:在一些被频繁调用的方法内不断地创建对象。例如在View 的onDraw方法内new 一些新的对象。
注意内存抖动也会导致 OOM,主要原因有如下两点:
1、Android Studio Profiler
作用
优点
内存抖动问题处理实战
理解内存抖动的概念的话,我们就能明白只要能找到抖动过程中所产生的对象及其调用栈,我们就能解决问题,刚好Android Studio 的Porfiler里面的Memory工具就能帮我们记录下我们操作过程中或静止界面所产生的新对象,并且能清晰看到这些对象的调用栈。
选择Profile 中 的Memory ,选择 Record Java/Kotlin allocations,再点击Record开始记录, Record Java/Kotlin allocations 选项会记录下新增的对象。
操作完成之后,点击如图所示的红脑按钮,停止记录。
停止记录后,我们就可以排序(点击 Allocations可以排序)看看哪些对象或基本类型在短时间被频繁创建多个,点击这些新增的对象就可以看到它的完成的调用链了,进而就找找到导致内存抖动的地方在哪里了。
2、利用DDMS 和 MAT(Memory Analyzer tool)来分析内存泄漏
我们利用工具进行内存泄漏分析主要是用对比法:
a.先打开正常界面,不做任何操作,先抓取一开始的堆文件。
b.一顿胡乱操作,回到原来操作前的界面。主动触发一两次GC,过10秒再抓取第二次堆文件。
c.通过工具对比,获取胡乱操作后新增的对象,然后分析这些新增的对象。
DDMS作用:抓取堆文件,主动触发GC。(其实也是可以用Android Studio 的Profile里面的Memory工具来抓取堆文件的,但是我这边在利用Profile 主动触发gc 的时候会导致程序奔溃,也不知道是不是手机的问题,所以没用Android Studio的Profiler)
MAT作用:对堆文件进行对比,找到多出的对象,找到对象的强引用调用链。
以下是详细的过程:
步骤1.打开DDMS,选择需要调试的应用,打开初始界面,点击下图的图标(Dump Hprof File)先获取一次堆文件。
步骤2.对应用随便操作后,回到一开始的界面,先多触发几次GC ,点击下图的图标(Cause Gc)来主动触发GC,然后再次点击 Dump Hprof File 图标来获取堆文件。
步骤3.通过Android Studio Profile 或者 DDMS dump 的堆文件无法在MAT 打开,需要借助android sdk包下的一个工具hprof-conv.exe来转换。
格式为 hprof-conv 旧文件路径名 要转换的名称;
例如:hprof-conv 2022-04-13_17-54-40_827.hprof change.hprof
步骤4.把两份堆文件导入MAT,然后选择其中第二次获取的堆文件,点击 如图所示的 Histogram查看。
步骤5.点击下图图标,Compare To Another Heap Dump ,选择另一份堆文件。
6.会得出下图所示的 Hitogram 展示,我们主要看Objects 这一列。 如下图所示 “+ 2” 则代表前面两份堆文件对比,这个对象多了两个,我们主要就是要分析这些多了出来,没有被回收的对象。
7.加入我们从增加的对象中,看到了MainActivity ,则需要从一开始打开的Hitogram 展示里面找到这个对象的调用栈。如下图所示,搜索MainActivity
8.看到下图所示解雇,然后鼠标右键点击下图红色圈圈着的MainActivity ,选择 Merger Shortest Paths to Gc Roots ,再选择 exclude all phantom/weak/soft etc.references ,就可以看到这个MainActivity 对象的强引用链,至此我们就可以找到MainActivity对象是被什么引用导致无法回收了。
3、内存泄露检测神器之LeakCanary(线下集成)
自行学习了解,接入简单,使用简单,基本可以解决大部分内存泄漏问题。
github地址 :
学习地址 :
针对内存抖动的建议:
针对内存泄漏问题的建议:
针对内存溢出问题的建议(主要就是要减少内存占用):
建议参考:
深入探索 Android 内存优化(炼狱级别)
对于 优化的大方向,我们应该优先去做见效快的地方,主要有以下三部分:内存泄漏、内存抖动、Bitmap。完善监控机制也是我们的重点,能帮助我们对内存问题快速分析和处理。
参考:
深入探索 Android 内存优化(炼狱级别)
如何优化app的运行内存占用问题?
下面的方法可以优化app的运行内存:
1、内存资源紧张时释放内存
在应用生命周期的任何阶段 onTrimMemory() 回调方法都可以告诉你设备的内存越来越低的情况,
你可以根据该方法推送的内存紧张级别来释放资源.
2、使用优化后的数据容器
利用 Android 框架优化后的数据容器, 比如 SparseArray, SparseBooleanArray 和 LongSparseArray.
传统的 HashMap 在内存上的实现十分的低效因为它需要为 map 中每一项在内存中建立映射关系. 另外, SparseArray类非常高效因为它避免系统中需要自动封箱(autobox)的key。
3、使用保守的Service
如果你的应用需要使用 service 在后台执行业务功能, 除非是一直在进行活动的工作(比如每隔几秒向服务器端请求数据之类)否则不要让它一直保持在后台运行. 并且, 当你的 service 执行完成但是停止失败时要小心 service 导致的内存泄露问题.
4、当心抽象代码
通常来说, 使用简单的抽象是一种好的编程习惯, 因为一定程度上的抽象可以提供代码的伸缩性和可维护性. 然而抽象会带来非常显著的开销: 需要执行更多的代码, 需要更长时间和更多的运行内存把代码映射到内存中, 所以如果抽象没有带来显著的效果就尽量避免.
那么如何查看APP运行内存占多少?
手机查看运行内存的方法:
1.部分手机内置内存管理器/智能管理器,开启该应用可查看内存使用情况。
2.部分机器:长按Home键-进入任务管理器-RAM状态-查看即可。
提示:不同型号手机查看路径可能略有不同。

APP启动性能优化
一、浅谈APP启动性能优化原因
1、引起性能问题的原因
随着项目不断的快速迭代,往往会造成App启动卡慢现象,因为可能在App主进程启动阶段或者在主界面启动阶段放了很多初始化其他业务的逻辑,而这些业务落地可能一开始并不需要用到;
2、为什么要做启动速度优化
App启动卡慢会影响一个App的卸载率和使用率;
启动速度快会给人一种轻快的感觉,减少用户等待时间;
如果一个App从点击桌面图标到看到主界面花了10秒,请问你能接受么?忍耐不好的估计直接就卸载了,或者没等打开就直接Home键按出去,然后杀进程了;这样一来App卸载率提升了,使用率下降了。所以对于有大量用户的App来说,这些性能细节是很重要的;
APP启动性能优化工具的选择
作为APP的开发者,我使用的一直都是一款友盟+软件,U-APM 是友盟+推出的App稳定性监控、性能监控和云真机测试平台。通过轻量级的集成接入即可拥有实时、可靠、全面的应用崩溃、ANR、自定义异常等捕获能力,及卡顿、启动分析等性能能力,支持多场景、多通道智能告警监控,帮助开发者高效还原异常、卡顿用户的访问路径和业务现场,缩短故障排查时间。
二、分析怎么做启动优化
1、启动过程简单分析
App从点击桌面图标到我们看到App的主界面整个过程中经过了哪些步骤,哪些地方是我们可以优化的地方;
2、从启动过程找出优化点
App启动过程中我们优化的地方包括主进程启动流程和主界面启动流程,主进程启动就是Application的创建过程,主界面启动就是MainActivity的创建过程;
只需要分别对这两个部分进行优化即可:
Application中attachBaseContext最早被调用,随后是onCreate方法,尽量在这两个方法中不要有耗时操作;
三、启动优化步骤
1、Application中加入异步线程
是把不必要提前做的操作放到异步线程中去做,也就是我们经常做的异步加载;
2、主页面加入异步线程和延迟加载功能
与Application的优化思路一样,也是封装onSyncLoad和onAsyncLoad方法对现有代码进行一个分类,但是这两个方法的调用时机要晚一点,是在主界面首屏绘制完成的时候调用。这个步骤也需要new一个Thead,属于额外的开销,不过这不影响我们整体性能;
3、态加载布局:主布局文件优化
把主界面中不需要第一次就用到的布局全部使用动态加载的方式来处理,使用ViewStub或者直接在使用时动态addView的方式;
4、主布局文件深度优化
Activity在加载布局的时候,会对整个布局文件进行解析,测量(measure),布局(layout)和绘制(draw),所以设计简单合理的布局尤为重要。几个重要的优化如下:
减少布局层级
减少首次加载View的数量
减少过度绘制
5、页面功能的分模块化和懒加载
一个页面上有很多功能模块,最好每个功能模块都单独的分开,模块之间用接口进行数据沟通;
按需加载所需要的功能,不要打开一个页面都加载所有的功能;
加载完所需要的功能,如果是一次性加载不需要保持在内存中,尽快销毁掉,形成良好的习惯。
APP启动性能优化是一条持续之路,通过优化我们可以了解到影响启动性能的因素有哪些,这样我们平时在编码的过程中就会多注意自己的代码性能。开发者可利用友盟+U-APM对APP启动进行监控,另外友盟+U-APM还提供云真机测试能力,助力开发者从研发测试质量验收到线上问题复现排查,保障应用品质,提升测试效率。在云真机测试期间自动采集崩溃信息,提供详尽的崩溃报告协助筛查,真正实现监控测试全流程深度打通。
手机个人所得税APP优化了哪些功能?
一是优化申报表项目预填服务。
对于选择适用空白申报表申报综合所得的纳税人,我们在空白表的填报界面上,提供了纳税人可再次使用申报表项目预填服务的功能,更好满足纳税人需要。
二是优化社保费填写方式。
对灵活就业自行缴纳社保的纳税人,结合部分地区按月、季、年不同缴费情形,新增按季度或者年度填报的选项,让纳税人新增社保时更加方便。
三是优化增加提示提醒。
一方面,增加更多的服务提示提醒,帮助纳税人便利地办理年度汇算;另一方面,对填报减少收入或增加扣除、免税收入、减免税额的纳税人进行风险提示,提醒纳税依法如实申报,降低纳税人误填错填几率。
APP 优化 - 概述
不是我蛋疼,有的朋友可能真的大部分 APP 优化点都说不上来,当然也是 app 里面可以优化的东西多造成的,我也不可能都知道,写我自己的认识吧
这个可是大家都得会的了,每个 andorid 都需要的,app 启动优化的思路就是减少 application 和 launch activity 的创建耗时。但是往往这里都是我们进行初始化的地方,所以我们的优化思路如下:
详细请看我们文章:
APK 瘦身的思路不多,就是减少 png 适配文件,压缩 png ,使用 webp,svg 代替 png ,app 能自己画的尽量自己画,比如 shape,layer-list,drawable,svg
然后是只适配 ARM 架构 CPU,动态下发 so,jar,aar文件,使用 lint 去除无用资源,打包时不打没使用的文件进去
具体请看我的文章:
关于app优化和uniapp优化的介绍到此就结束了,不知道你从中找到你需要的信息了吗 ?如果你还想了解更多这方面的信息,记得收藏关注云尚网络www.ysfad.net。
发表评论




暂时没有评论,来抢沙发吧~