Android性能相关--经验篇

最新推荐文章于 2022-02-22 16:14:35 发布
最新推荐文章于 2022-02-22 16:14:35 发布
阅读量535 收藏 3
点赞数 1
分类专栏： Android质量管理 文章标签： android 性能 经验
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/xiaoru5127/article/details/73970026
版权

##基础知识

  • 底层触发回收机制时机：

GC_FOR_MALLOC 堆上分配对象时内存不足触发
GC_CONCURRENT 堆内存达到一定量（即快满了）时触发
GC_EXPLICIT 主动触发，System.gc、VMRuntime.gc或收到SIGUSR1信号
~
GC日志如下
D/dalvikvm（ 7030） ： GC_CONCURRENT feed 1049K，60% free 2341K/9351K ，external 3502K/6261K，paused 3ms 3ms
~
GC_CONCURRENT是GC类型，此外还有GC_FOR_MALLOC、GC_EXTERNAL_ALLOC、GC_HPROF_DUMO_HEAP、GC_EXPLICIT
feed 1049K 表示这次GC回收了多少内存
60% free 2341K/9351K 描述Heap内存的信息，本次回收后60%的Heap可用，存活对象大小为2341K，Heap大小为9351K
external 3502K/6261K 描述Native Momory信息（存放位图数据或堆外内存）， 表示已经分配了3502K内存，当分配到6261K的时候会触发下一次GC
paused 3ms 3ms 表示GC暂停时间

  • UI卡顿：60fps=1000ms / 16ms
    0~100 毫秒的延迟会让用户感知到瞬时的卡顿；
    100~300 毫秒的延迟会让用户感觉迟缓；
    300~1000 毫秒的延迟让用户感觉“手机卡死了”；
    1000 毫秒以上的延迟会让用户想去干别的事情

  • 硬件加速（GPU）的绘制效率远高于软件绘制（CPU），但存在以下缺陷：耗电高、某些接口不兼容、内存占用大（Open GL至少需要8M内存）

  • 引用（强软弱虚）
    软引用：垃圾收集器运行时可能会也可能不会释放软引用，但在保证虚拟机内存不足之时会清理它
    弱引用：与软引用的区别是，弱引用生命周期更短，且无论虚拟机内存是否不足都会被清理
    虚引用：只能用于跟踪即将对被引用对象进行的收集，在任何时候都可能被垃圾回收器回收

  • ANR：
    1.主线程5s内没有处理完输入事件
    2.主线程10s没处理完BroadCastReceiver.onReceive
    3.主线程在Service各生命周期函数时20s没处理完

ANR IN ：发生ANR的具体类
PID：发生ANR的进程，系统会在此时生成trace文件
Reason：当前ANR的类型以及导致ANR的原因
CPU usage：CPU的使用情况，在ANR发生前后都会产生一个CPU usage一共打印两次CPU使用情况

  • OOM：试图申请的内存+已分配的内存>虚拟机允许的最大内存
    内存泄漏：无用对象持续占用内存或得不到及时释放

案例：https://tech.meituan.com/oom_analysis.html

  • App闪退常见原因：NullPointer、OOM、数组越界、类型转换异常、数字转换异常、Activity/Service找不到、实体对象没有序列化等

  • Force Close常见原因：Error、OOM（内存溢出）、StackOverFlowError、RuntimeException空指针异常

  • Native 层Crash
    SIGILL 执行了非法指令、可执行文件本身出错、堆栈溢出等情况
    SIGABRT 调用abort函数生成
    SIGBUS 访问非法地址，包括内存地址对齐出错
    SIGFPE 算法运算错误，如溢出及除0等
    SIGSEGV 访问不属于自己的存储空间或访问只读存储空间
    SIGPIPE 管道异常，这个信号通常在进程间通信时产生

磁盘性能问题

性能瓶颈：磁盘的顺序读写基本速度都非常快了，问题基本都在随机读写

  1. 随机读因为没有预读（read-ahead）的优化性能差很多
  2. 随机写会造成大量的失效页和写入放大问题
  3. 数据库的性能问题，本质上也是IO性能问题

常见问题：

  • 卡顿
  • ANR
    • IO Wait很高的时候，很可能主线程执行了耗时IO操作
    • 大量的数据读写、数据库操作、硬件操作也可能造成ANR

Tips：写入放大情景：我们知道磁盘一块有512k，块中每页4k，当需要写入4k时系统恰好找到一个512k块中有一页4k的无效页。那么系统会将这512k块数据读出再擦除这512k块，之后再把读出的数据+要写入的4k数据写入这个512k的块中。这样原本的写入4k变成了【闪存读512k】-【缓存改4k】-【闪存擦除512k】-【闪存写入512k】。写入放大实验：1、正常写入1M文件，记录耗时。2、先用6k的小文件写满存储，再删除（系统标记为无效页，并未真正删除类似垃圾桶功能），这样保证存储中没有干净的存储块，最好写入1M的文件，记录耗时，两相对比。

工具推荐：

  1. Systrace：IO操作耗时过长问题
  2. Strict Mode：主线程IO问题
  3. IO Monitor：主线程IO问题、多余IO操作、Buffer过小问题
  4. SQL IO Monitor：主线程IO问题、数据库IO问题（全表扫描、不合理事务等造成）

优化建议：

  1. 通过缓存避免重复读写次数（变量保存、延迟写入等）
  2. IO操作、数据库操作尽量放入子线程
  3. ByteArrayOutputStream > ObjectOutputStream
  4. 合理设置Buffer大小
  5. 加解压 ZipFile + BufferedOutputStream；ZipInputStream适合网络数据解压、损坏压缩包解压、大量的小文件加解压
  6. 避免频繁开关数据库，数据库打开后等到真正不需要再关闭或应用退出再关闭
  7. Bitmap的加载，decodeStream + BufferedInputStream > decodeFile；decodeResource > decodeResourceStream
  8. SP的commit都是一次文件的打开读写关闭，尽量在必要时在进行；同时用apply代替commit
  9. 索引能加快查询速度，但同样能导致插入更新缓慢，需合理使用
  10. Buffer的读写每次的缓存数据使用8K，可以提供一定的效率

内存性能问题

性能瓶颈：

  1. OOM、Low Memory Killer会杀死进程，GC会导致App卡顿
  2. Activity泄露问题极为严重，通常有mContext间接引用造成、this$0间接引用造成、Activity直接引用造成

常见问题：

  • 内存泄露 OOM（Crash）
    • 随着功能的反复执行，Heap内存一直在持续增长。通常是内存泄露，适合用LeakCannary工具进行白盒测试分析
    • 每次启动应用后，Heap内存相比以前版本稳定增长。通常出现在启动后待机或使用某功能后，可能是由新功能及代码改动引入固定内存增长。使用用Heap Dump进行多版本或功能使用前后的对比
    • Heap Alloc变化不大，但进程的Dalvik Heap Pss内存明显增加。通常由于分配了大量小对象造成的内存碎片。
  • GC引起的卡顿
    • 大量的new临时变量或new Bitmap等大内存等操作需要注意
    • 代码执行时出现频繁GC，Heap Alloc内存大幅度波动。即内存抖动，通常是分配了许多临时变量或数组还有AsyncTask，随后被迅速回收。适合使用Heap Viewer/Allocation Tracker等工具查看具体分配的对象

工具推荐：

  1. top/procrank ：内存占用过大、内存泄
  2. meminfo ： Native内存泄漏、是否存在Activity/ApplicationContext泄漏、数据库缓存命中率低
  3. MAT/Finder/JHAT ： Java层的重复内存、不合理图片解码、内存泄漏
  4. libc_malloc_deBug_leak.so ： Ntive内存泄漏
  5. LeakCannary/StrictMode/LeakInspector ： Activity内存泄漏
  6. 腾讯APT ： 内存占用过大、内存泄漏
  7. GC Log from Logcat/GC Log 生成图表 ： 人工触发GC for Explicit而导致的卡顿，Heap内存不足触发GC for Alloc 而导致的卡顿
  8. Systrace ： GC导致的卡顿
  9. Allocation Tracer ： 申请内存次数过多和过大，辅助定位GC Log发现的问题
  10. chrome devtool ： HS的内存问题

优化建议：

  1. 使用轻量级的数据结构 ArrayMap、SparseArray
  2. 尽量避免使用Enum枚举（枚举最大优势是类型安全，但占用内存比普通定义常量大得多，可用注解来检查类型安全）；尽量避免基本类型的拆装箱（Integer、Long 、Float…）
  3. String的拼接使用StringBuilder
  4. 内存对象的重复利用：对象池；利用系统自带的资源；StringBuilder、StringBuffer
  5. 尽量不要再循环中创建大量的临时变量–内存抖动
  6. 引入SDK库和调用新的系统API需要考虑成本
  7. dex文件有很多优化空间，如仔细统计并调整dex文件的顺序往往能节约1M以上的dex mmap内存

【内存泄露】

  1. this$0 间接引用 导致 Activity内存泄漏；
    解决方案：在Activity关闭时在onDestroy中，解除内部类和外部类的引用关系或使用弱引用
  2. Thread 直接引用 导致Activity内存泄漏
    解决方案：使用完解除Thread和Activity的引用关系，即Thread使用完移除Activity或使用弱引用
  3. mContext 间接引用 导致Activity内存泄漏
    解决方案：使用后解除mContext引用或使用弱引用
  4. this$0 间接引用 导致Activity内存泄漏
    解决方案：用static来截断匿名类引用，或使用弱引用
  5. 匿名内部类/非静态内部类(尤其是放在Activity中的)：非静态内部类会持有外部类的引用，若非静态内部类的实例是静态的则其生命周期也是跟app一样长，导致外部类（尤其为Activity）无法释放
    解决方案：可将内部类置为静态类则不会持有外部类引用，或内部类设计成单例，传入资源用弱引用包裹，Context用ApplicationContext或用后置空
  6. 单例、Application的生命周期跟app一样长，要注意其所持有的对象无法释放。eg：单例对象持有Activity的mContext对象导致Activity无法释放。
  7. 非View类Context尽量使用ApplicationContext替代（startActivity、Layout.Inflation、Dialog必须使用Activity的Context）
  8. Timer、Handler、AsyncTask等异步操作，导致 Activity内存泄漏
    解决方案：onDestroy进行关闭，清除。handler为内部类会持有外部类（尤其Activity）的引用，而activity结束时若handler的消息还没处理完则导致内存泄漏【handler置为静态类，且内部若持有外部对象则置为弱引用WeakReference】
  9. 常驻内存问题，相同的图片保存一份，去重
  10. 避免静态变量持有大量数据引用。静态变量不会被回收，长期维持对象的引用阻止垃圾回收，如果持有对象是Bitmap等大数据对象就很容造成内存不足
  11. 注意资源/监听器/Cursor对象/Recerver对象/Sensor对象/File对象等的关闭、注销、移除，临时资源主动回收(加载后忘记释放的Bitmap、临时生成的Byte数组和文件缓冲区)。注意需要close后置空，并且注意try-catch中使用的资源在finally中进行关闭处理。

内部类的正确用法（Handler为例）

private static Class InnerHandler extends Handler{
	private final WeakReference<HandlerActivity> mActivity;
	public InnerHandler(HandlerActivity activity){
		mActivity = activity;
	}
	@Override
	public void handleMessage(){
		HandlerActivity activity = mActivity.get();
		if(activity != null){...}
	}
}

单例中使用Context的正确方式

public class SingleInstance{
	private Context mContext;
	private static SingleInstance sInstance;
	private SingleInstance(Context context){
		mContext = context;
	}
	public static SingleInsatance getInstance(Context context){
		if(sInstance == null){
			sInstance = new SingleInstance(context.getApplicationContext());
		}
		return sInstance;
	}
}

【图片优化】

  • 格式：WebP(Android4.0+才支持) > JPEG(不支持透明) > PNG
  • 图片压缩：ImageAlpha有损压缩、TinyPNG有损压缩、ImageOptim无损压缩
  • ARGB565/ARGB4444/ALPHA_8的使用
  • 改变图片大小：inSampleSize指数幂的缩放，inScaled、inDensity、inTargetDensity更为细致
BitmapFactory.Options options = new BitmapFractory.Options();
//inSample缩放
options.inSampleSize = 4;
//inScaled、inDensity、inTargetDensity组合
options.inScaled = true;
options.inDensity = srcWidth;
options.inTargetDensity = dstWidth;
BitmapFactory.decodeStream(is,null,optins);
  • inBitmap复用内存
  • 不用的使用recycle
  • 三级缓存

【WebView内存问题】
WebView一经加载其内存不可释放，除非进程死亡；而且WebView有很多坑可能导致应用崩溃。可将WebView放在一个单独的进程中，通过AIDL与主进程进行通信。WebView进程关闭即可销毁内存，但不宜每次退出都进行关闭，因为进程的启动和销毁也是耗时操作，每次进出都进行新建销毁进程会导致卡顿问题，需要有一个策略来处理。

CPU性能问题

性能瓶颈：

  1. CPU资源冗余使用，由于算法问题、重复查、排序、删除等浪费CPU资源
  2. CPU资源争抢，抢主线程的CPU资源，抢音视频的CPU资源，多线程平等互争资源
  3. CPU资源利用率低，主要在于磁盘IO、网络IO、锁操作、sleep操作等导致CPU无法得到有效利用，空跑。

常见问题：

  • 卡顿
    • 检查UI线程是否有可能有耗时的操作
    • overdraw 布局层数是否太多？
    • 动画是否层数太多？是否过于复杂？是否onDraw调用次数不合理频繁触发measure、layout、onDraw
  • ANR（Crash）
    • 查看CPU是否很忙，是否因为其他进程或子线程占用CPU时间片过多导致主线程时间片过少
    • 死锁、其他线程持有锁，导致主线程等待超时

工具推荐：

  1. adb命令

    adb shell top 列出进程的各种数据
    adb shell ps 处理进程的身份标识
    cat /proc/pid/stat 查看CPU信息
    adb shell dumpsys cpuinfo 获取PCU信息

  2. PerfBox ： FPS、Activity启动速度
  3. Systrace：分析绘制时流程导致的卡顿，能大约定位是GC、IO、贴图太大，还是没用ViewHolder的问题
  4. Traceview：能深入定位分析各种流畅度与时延问题，但时只能初步定位XML布局和OpenGL绘制的性能问题
  5. Trepn
  6. Gfxinfo/Slickr ： 定位硬件加速下的性能问题
  7. Hierarchy Viewer ： 定位XML布局导致的性能问题
  8. Tracer for Open GL/Adreno/UXTune ： 具体定位绘制性能问题
  9. Chrome DevTool ： 定位具体H5卡顿问题

优化建议：

  1. CPU资源争抢，减少非核心需求的CPU消耗，或降低非核心线程的优先级
  2. 优化算法，避免重复浪费CPU资源
  3. 将CPU消耗转换为GPU消耗（使用RenderScript、OpenGL来进行复杂的绘制）
  4. 使用合适的数据类型（int、float、long），使用合适的容器（ArrayMap、SparseArray、ConcurrentHashMap）
  5. 使用缓存和预处理来提升算法效率，(缓存提升效率其实是内存空间换时间)
  6. 使用多线程提高效率的时候注意选择合适的线程数

【流畅性–布局优化】

  • 尽量使用RelativeLayout和LinearLayout布局，不用AbsoluteLayout。考虑用RelativeLayout代替LinearLayout减少布局层次，同层级则建议用LinearLayout（性能略高）
  • include 重用布局，include使用其他属性的时候需要设置width、height属性
  • ViewStub view的延迟加载，推迟布局加载。当布局需要显示的时候才会去加载布局（布局的显隐我们经常用setVisible来搞定，其实用ViewStub的inflation来控制显示性能会好一些，但不适合需要进行显隐切换的布局）
  • merge 减少不必要的层级，多用来替代FrameLayout
  • 去掉多余的背景颜色（包括Activity背景灯），减少过度绘制
<item name="android:windowNoTitle">true</item>
<item name="android:windowBackground">@null</item>
  • 图标+文字的布局可以考虑TextView的compound drawables来实现，会比TextView+ImageView更高效一些
  • 使用layout_weight属性会导致LinearLayout绘制的时候需要被测量两次，影响性能，尤其在ListView/GridView的子Item中尤其明显。此外weight+weight_sum属性可以用来减少布局层数的情况下可以考虑使用。
  • 文字有多种样式可以考虑Html.fromHtml()和Spannable来实现，而不是写多个TextView拼接
  • 布局复杂导致层次多可以考虑用自定义ViewGroup来实现，可以考虑用LayoutAnimationController实现布局动画

【流畅性–ListView/RecyclerView优化】

  • 复用convertView，即HoldView的使用
  • 异步加载图片
  • 快速滑动时SCROLL_STATE_FLING不显示/加载图片或消耗资源较大的view，停止后处于SCROLL_STATE_IDLE和SCROLL_STATE_TOUCH_SCROLL再进行加载显示
  • item尽可能地减少使用控件和布局层次，尽可能地复用控件，这样可以减少ListView的内存使用，减少滑动时gc次数。ListView的背景色与cacheColorHint设置相同颜色可以提高滑动时的渲染性能
  • getView不做复杂的逻辑计算

网络性能问题

网络有三种状态 FullPower全力运行、Low Power低状态、Standby等待状态，特点：升到Full快，降下来慢
这里写图片描述

性能瓶颈：

  1. 业务成功率
  2. 业务网络延迟。DNS部分可以采用IP直连、域名重用、HttpDNS等方式；TCP短连接会导致每次连接都发生三次握手，可利用长连接
  3. 业务带宽成本。减少用户使用app的带宽成本，不必要的网络请求放在wifi环境下等策略

工具推荐：

  1. Wireshark – 网络性能问题分析定位
  2. fiddler – 主要针对Http，能模拟Http的错误和延时返回
  3. SPDY/HTTP2.0/QUIC – 网络协议，利用FastTcpOpen减少握手次数，利用UDP更好地适应网络抖动
  4. WebPageTest.org – 做web应用的数据上报，提供LoadTime、StartRender、SpeedIndex、DOM Elements等耗时
  5. ATC – 最专业的弱网络模拟工具，能模拟窄带宽、延时、丢包、损坏包、包乱序等情况

优化建议：

  1. Webview或一些实时性不强的网络采用网络缓存；
    解决方案：设置HTTP的Cache-control使得其保存资源文件；public/private/no-cache/no-store/max-age/max-stale
    然后设置HTTP请求时的缓存模式；LOAD_CACHE_ONLY/LOAD_DEFAULT/LOAD_CACHE_NORMAL/LOAD_NO_CACHE/LOAD_CACHE_ELSE_NETWORK
  2. 大数据网络传输可先进行压缩下载后再进行解压使用
  3. 调整服务器RcvBuffer的MSS优化【分片策略】，缓解网络延迟
  4. 超时和重试，单个请求设置超时时间，适当考虑失败重试。分片下载，下载失败只重新获取失败部分
  5. 可考虑避免DNS解析直接用IP
  6. 根据业务合并网络请求或预先获取网络数据
  7. CDN的使用
  8. 尽量合并非必要实时请求，控制请求的频率。
  9. 数据压缩：POST的Body采用GZip；请求头压缩采用SPDY和HTTP2.0直接 压缩

电量

组成App电量消耗各部分定义：
● CPU的电量消耗
● wake lock的电量消耗
● 数据传输的电量消耗
● WIFI运行的电量消耗
● GPS的电量消耗
● other sensors的电量消耗
● 蜂窝通信电量消耗
● 屏幕电量消耗
● 信号电量消耗
● WIfi电量消耗
● CPU空闲时电量消耗
● 蓝牙模块电量消耗

推荐工具：

  • adb shell dumpsys batteryinfo
  • PowerStat2.0（腾讯）
  • Battery Historian 2.0（Google 需要Android5.0以上系统）
    获取方式：
    adb shell dumpsys batterystats --enable full-wake-history
    adb shell dumpsys batterystats --reset
    adb bugreport > bugreport.txt
    将txt转成html可视化，historian.py从https://github.com/google/battery-historian下载
    python historian.py -a bugreport.txt > bugreport.html

优化建议：
1、网络方面
a、发起网络请求时机，把可以延迟执行的网络请求延后合并发起，减少网络Http建立次数
b、减少移动网络被激活时间和次数：发现返回数据相同时，延迟下次请求 时间。避免频繁间隔请求，采用批处理一次性请求。使用预存取技术提取获取一些数据避免后面频繁再次发起网络请求
c、数据处理：网络 传输进行压缩。进行大数据下载用GZIP下载。使用高效率的数据格式和解析方法，推荐JSON和Protobuf
d、慎用轮训方式去执行网络请求
e、减少推送消息的次数和频率
f、网络状态，处理具体业务前，养成判断当前网络 状态的习惯
2、界面相关
a、离开界面后停止对应的耗电活动
b、应用进入后台禁止异常耗电
3、定位相关
a、使用GPS后记得关闭
b、定位要求不高时用网络定位代替GPS定位
c、慎用持续定位
d、慎用被动定位

Android6.0之后的两种省电模式Doze 和 App Standby
Doze模式进入：未连接电源 + 屏幕关闭
Doze模式的五种状态：

  1. ACTIVE：手机处于激活状态
  2. INACTIVE：手机刚脱离激活状态
  3. IDLE_PENDING:IDLE预备态
  4. IDLE：空闲状态
  5. IDLE_MAINTENANCE：处理挂起任务
    IDLE状态下的限制：
    ● 断开网络连接
    ● 忽略Wake Lock
    ● 标准闹钟AlarmManager定时任务延迟
    ● 系统不会扫描热点WIFI
    ● 禁止同步工作
    ● 停止JobScheduler任务调度

Apk瘦身

Analyze Apk：将APK拖入Android Studio即可观察当前包的结构及各部分占用的大小
这里写图片描述

这里写图片描述

瘦身建议：

  • 资源压缩，字体压缩FontZip、解压库AndrodiUn7Zip
  • 利用Proguard来做代码混淆、除去冗余代码、无用代码冗余资源
  • 一般图片资源只做一套高清图，个别有问题再用9png解决，最后才会根据不同分辨率做不同的图的方案
  • 图片格式的选择以及压缩
  • redex 字节码优化，可以在优化包Size的同时提高字节码加载性能，提示App速度。主要优化项目有减少和压缩字符串、消除冗余代码、内联函数、Interdex（一种冷启动方法）
  • 对最终的Apk包进行7Zip极限压缩

启动速度

冷启动：App进程还没有创建的情况下启动App
热启动：App启动时，后台已有App进程（后台挂起），eg：按Home键退出App
温启动：介于冷启动和温启动之间，eg：系统由于某种原因回收App，用户重新启动App等

启动时间度量：
adb shell am start -W pkg_name/activity 打印【TotalTime】 应用启动耗时 ，包括 新进程启动、Applicaton初始化、Activity启动时间；【ThisTime】一般和Total Time相同，除非应用启动时开了一个透明的Activity做预处理再加载主Activity；【WaitTime】总的耗时，包括启动耗时和前一个应用Activity pause时间

优化建议：

  1. 做的初始化 工作尽量减轻，采用延迟加载、异步加载或懒加载（按需加载），attachBaseContext、onCreate中不做耗时操作
  2. Activity要进行 布局 优化；避免加载 或编码Bitmap，依赖Bitmap的View延迟更新 ；避免硬盘或网络操作 阻塞UI绘制；避免在UI线程 中进行资源初始化，可延迟或异步处理
  3. 为Activity设置windowBackground，在View加载完成前可以显示这张 背景logo

Android性能优化典范
http://hukai.me/android-performance-patterns/
http://hukai.me/android-performance-patterns-season-2/
http://hukai.me/android-performance-patterns-season-3/
http://hukai.me/android-performance-patterns-season-4/
http://hukai.me/android-performance-patterns-season-5/
http://hukai.me/android-performance-patterns-season-6/
Android内存优化之OOM
http://hukai.me/android-performance-oom/
Android性能优化之电量篇
http://hukai.me/android-performance-battery/
Android性能优化之内存篇
http://hukai.me/android-performance-memory/
Android性能优化之运算篇
http://hukai.me/android-performance-compute/
Android性能优化之渲染篇
http://hukai.me/android-performance-render/

xiaoru5127
关注
  • 1
    点赞
  • 踩
  • 3
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
Android性能优化--IO 优化（ IO基本知识：应用程序、文件系统和磁盘，三种IO方式及适用场景，多线程阻塞IO和NIO）
CallmeZhe的博客
06-24 4103
目录 I/O 的基本知识 1. 文件系统 2. 磁盘 Android I/O 1. Android 闪存 2. 两个疑问 疑问一：文件为什么会损坏？ 疑问二：I/O 有时候为什么会突然很慢？ 不同的场景使用不同的I/O方式 I/O 的三种方式 1. 标准 I/O 2. 直接 I/O 3. mmap 多线程阻塞 I/O 和 NIO 1. 多线程阻塞 I/O 2. NIO 小文件系统 常见不良现象 1. 主线程 I/O 2. 读写 Buffer 过小 3. 重复读 4
Android中的读写方式之IO读写
后知后觉的程序猿
10-07 1526
Android中保存数据的方式有多种，包括文件存储、SharedPreference键值对存储以及数据库存储等。其中，文件存储是源自Java技术的最基本的数据存储方式。对文件的操作，在Java中，自然需要借助流的概念来处理，即通常所说的I/O流（输入输出流）。 一、输入与输出，参照物是什么？ 经常说输入流和输出流，但是初学者经常搞不清楚哪个是输入流，哪个又是输出流。我们需要明白输入与输出是有参
［译］Android 性能典范：拯救计划
fumeidonga的博客
04-07 333
原文地址：http://mp.weixin.qq.com/s?__biz=MzA4MjU5NTY0NA==&mid=405608694&idx=1&sn=92940ebda7f7f7b53d22fbb79fc248f5&scene=0#wechat_redirect 前言 今天逛稀土时偶然看到hanks分享的一篇英文文章，粗略浏览便已觉得不错，因此翻译成中文，与君分享。
Android-java的io性能知识点
CoderLife9192的专栏
09-20 614
关于Bitmap，使用decodeStream代替decodeFile，并且传入BufferedInputStream类型的文件流，decodeResource同样存在这个问题，建议使用decodeResourceStream，性能优化的原因是增加了缓冲区，减少了磁盘io的次数     VSS Virtual Set Size 虚集合大小 Rss Resident Set Size 常...
android I/O Performance 的一些查看方法
热门推荐
Kevin的专栏
03-08 1万+
1，top信息查看IOW%    adb shell top -d 1 -m 10 - t            查看IOW的百分比是不是很高，说明值得怀疑，真正是不是IO的瓶颈还详细分析应用启动时间内的IO繁忙程度。 有是有IOW%达到80%系统y额不一定很卡，有是有10%系统也会觉得卡。因为IOW是前提条件是CPU空闲，且在等待这么多IO请求，所以相同条件下的IO， CPU空闲越多，百分比
Android SDK (SDK Platforms)-android-33-ext5.zip
最新发布
09-08
本篇将深入探讨"Android SDK (SDK Platforms)-android-33-ext5.zip"这个压缩包中所包含的知识点，以及其对Android 33版本的ext5扩展。 首先，Android 33是Android操作系统的一个新版本，它带来了许多新特性和性能...
android-studio-2021.3.1.17-windows.exe
10-21
本篇文章将详细解析“android-studio-2021.3.1.17-windows.exe”这一版本的Android Studio，主要面向Windows操作系统用户。 一、Android Studio简介 Android Studio是基于IntelliJ IDEA的，专为Android应用开发设计...
Android SDK (SDK Platforms)-android-33-ext4.zip
09-08
本篇将重点探讨"Android SDK (SDK Platforms)-android-33-ext4.zip"这一特定版本，以及其中包含的关键知识点。 "android-33"代表的是Android操作系统的一个特定版本，通常与Android版本号相对应。这里提到的"33...
AndroidBinder设计与实现-设计篇
02-26
Binder是Android系统进程间通信（IPC）方式之一。Linux已经拥有管道，systemVIPC，socket等IPC手段，却还要倚赖Binder来实现进程间通信，说明Binder具有无可比拟的优势。深入了解Binder并将之与传统IPC做对比有助于...
android-studio-2021.3.1.16-windows.exe
10-13
本篇文章将详细解析Android Studio Dolphin 2021.3.1.16这一Windows系统的正式版本，探讨其核心功能、新特性以及如何有效利用它进行Android应用开发。 首先，Android Studio Dolphin是Android Studio的第四个主要...
Android对IO进行读写操作实例
04-10
Android对IO进行读写操作实例
Android IO性能测试
愿有岁月可回首，且以深情共白头
02-22 2693
关于IO流程 参考Linux–IO介绍 一般情况下,read,write系统调用并不直接访问磁盘。这个调用仅仅是在用户空间和内核空间的buffer之间传递目标数据。举个例子,下面的write系统调用仅仅是把3个字节从用户空间拷贝到内核空间的buffer之后就直接返回了 write(fd,”abc”,3); 在以后的某个时间点上,内核把装着“abc”三个字节的buffer写入(flush)磁盘。如果另外的进程在这个过程中想要读刚才被打开写的那个文件怎么办?答案是:内核会从刚才的buffer提供要读取的数据,
安卓中的ＩＯ读取与写的简单操作
小龙
02-24 1878
安卓IO学习笔记，ＳＤ卡读取文本的简单操作和注意事项。
浅谈Android性能优化方案
王永迪的专栏
01-06 5173
经过前一阶段的调查，大概对性能优化已经有了初步的解决方案：  先给大家介绍一下性能优化指标以及部分方案：        一、性能优化六项指标：               性能、内存、稳定性、流量、电量、安装包大小；        二、背景 ---- Android程序卡顿产生原因：               1、Android系统低效
Android IO性能分析及排查
moxiouhao的专栏
08-22 7965
概述 Android得IO问题实际上就是探究Linux得IO问题。 本文主要是总结了网上各路大神得经验，写了一些实际操作中遇到得问题和解决方案。 最近在搞性能优化方面得研究，研究使用Soloπ得io占用对性能得影响问题时，偶然发现了机器上IO很频繁。老大说去看看为啥io那么频繁吧，于是乎…走上了一条不归路啊T.T。 内容 网上搜来搜去基本就那几篇东西，大部分都是转来转去。而且多是针对linux系统...
安卓平台IO特性分析
忠s
09-26 1504
背景 测试环境： 测试设备：Nexus5，32GB SanDisk INAND eMMC 4.51，无外挂SD卡。 操作系统：Android v4.4 IO监控软件：作者自己搞的BIOtracer 测试内容：     选取常用的14个软件，和4个系统功能。那么有18个应用场景和它们一些组合应用场景（电话、空闲和启动手机也简单认为是应用程序之一）。详细如下：
Android 11 引发的IO 性能下降问题分析 SDCardFS Vs FUSE
cmyperson的博客
08-31 4509
Sdcard vs External storage 在Android手机的早期，几乎所有设备都依赖于使用microSD卡进行存储。这是由于当时的手机出厂时内部存储容量很小。但是，至少与内部闪存可以读取/写入数据的速度相比，用于存储应用程序的SD卡通常无法提供出色的用户体验。因此，越来越多地将SD卡用于外部数据存储， 由于SD卡作为外部存储设备的泛滥，Android的存储命名约定基于以下事实：每个设备都有一个实际的物理microSD卡插槽。但是，即使在不包含SD卡插槽的设备上，/ sdcard标签仍..
【IO】【java的io读写，缓冲区是如何提高读写效率的】
盖世英雄
02-11 1361
据我了解，运用FileInputStream读写一段数据是一个字节一个字节的读取，如果有10个字节大小的文件，就要调用10次系统调用，每次将读取的数据赋值给变量，然后程序使用变量。缓冲区可以看作是一个放在内存中的数组，但是从硬盘中读取数据仍然要使用系统调用，系统调用的读取仍然是每次一个，只是每调用一次之后，将所得到的数据放入缓冲区中的，然后程序一次性使用10个数据。 我是这样理解的，但是不管用与...
使用Android-x86和VirtualBox构建高性能Android开发环境
"这篇文章主要介绍了如何使用Android-X86和VirtualBox构建高性能的Android开发环境，以解决Android原生模拟器性能低下的问题。作者提到Android模拟器由于模拟ARM架构和使用全系统模式运行，导致其运行速度较慢。而...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值