Android 界面滑动卡顿分析与解决方案(入门) 导致Android界面滑动卡顿主要有两个原因: 1.UI线程(main)有耗时操作 2.视图渲染时间过长,导致卡顿 目前只讲第1点,第二点相对比较复杂待以后慢慢研究. 众所周知,界面的流畅度主要依赖FPS这个值,这个值是通过(1s/渲染1帧所花费的时间)计算所得,FPS值越大视频越流畅,所以就需要渲染1帧的时间能尽量缩短.正常流畅度的FPS值在60左右,即渲染一帧的时间不应大于17ms. 先看一个例子: 见Video1,该应用通过一组URL加载

常说的主线程(UI线程)是什么? 当一个Android程序刚启动的时候,我们的android系统就会启动一个带有一个单一线程的linux进程.默认情况下,所有的组件比如Activity都运行在同样的一个进程和线程当中,这个线程就叫做主线程或者UI线程.也就是说,默认情况下,app启动的时候会创建一个线程,这个线程就叫做主线程.因为大部分功能是进行UI上的操作,所有也叫做UI线程. 关于为什么叫主线程请参考:Android 主线程之旅--PSVM(public static void main.

2.3编译Android源码 Android源码体积非常庞大,由Dalvik虚拟机.Linux内核.编译系统.框架代码.Android定制C库.测试套件.系统应用程序等部分组成,在编译Android源码之前,必须要先掌握Android源码的组成. 2.3.1Android源码目录结构 在Android源码中,按照不同功能代码被放在不同的目录下: 目录 描述 bionic 针对Android系统定制的仿生标准C库.链接器等所在目录,Android系统并没有使用Linux的glibc库,bioinc

一.android系统被分为4个层次:1.最下层的是linux核心,包括多个驱动程序,提供了操作系统应该具备的核心功能:2.在linux核心之上,包括两个部分,一部分是Android Runtime(包括Dalvik虚拟机,和Core Libraries相当于java中的jdk)和LIBRARIES:3.是Application Framework这一层,该层包括多个Android开发框架(即各种管理器,如资源管理器等):4.Aplication层(该层既是我们工作的领域app)二.基于组件的应

国庆节放假.搞了半个月都没有上班了,coding的时候一点都不在状态,本来这篇文章是在国庆节前写完的,可是由于自己的懒 惰,导致延期到国庆节,哎,这种习惯真心不好呀...不多说了以下来进入正题 之前我们解读了Handler机制,今天再来看一下AsyncTask类,由于这两个类使我们在Android进行耗时的操作的时候,不影响主线 程的情况下常常使用的两个类.我们先来看一下AsyncTask类源代码中定义的变量: private static final ThreadFactory sThread

WeTest 导读 干货!干货!或许可以是一种处理问题的新思路哟! 前言 我们知道android是基于Looper消息循环的系统,我们通过Handler向Looper包含的MessageQueue投递Message, 不过我们常见的用法是这样吧? 一般我们比较少接触MessageQueue, 其实它内部的IdleHandler接口有很多有趣的用法,首先看看它的定义: 简而言之,就是在looper里面的message暂时处理完了,这个时候会回调这个接口,返回false,那么就会移除它,返回true

前面两篇分别介绍了通过脚本和C代码读写/sys/class/gpio以控制GPIO.实际项目调试时经常还需要在Java代码里控制GPIO,其实现与C代码类似,唯一不同是Android权限.本文重点介绍Android6.0权限的配置并对在Java层控制GPIO的耗时做简单分析. 以高通平台为例,权限配置主要修改HLOS/device/qcom/sepolicy/common目录下的file.te.file_contexts和system_app.te三个文件. file.te修改如下, # GPI

1.必须要开子线程来操作耗时操作,android.os.NetworkOnMainThreadException new Thread(new Runnable() { @Override public void run() { // TODO Auto-generated method stub try { updateFile = Environment.getExternalStorageDirectory() + "/3530.jpg"; //downloadUpdateFil

在这里我申明一点,因为我是挂着VPN去YOUTOBE看的尚学堂的高明鑫老师讲的Android基础学习视频,有些东西他没有讲,而我也没办法,只能等两个星期后学校请老师来的时候进行询问,当然我也会将一些问题发布在博客里,希望有一些粗腿可以让我抱一下 在此次随笔中,我将讲一下用sleep进行的耗时操作,由于高老师在视频中也是一掠而过,我也只能讲一点点,先附上代码 button.setOnClickListener(new View.OnClickListener() { @Override publi

在实际应用中经常会遇到比较耗时任务的处理,比如网络连接,数据库操作等情况时,如果这些操作都是放在主线程(UI线程)中,则会造成UI的假死现象(android4.0后也不许放在UI线程),这可以使用AsyncTask和Handler两种异步方式来解决这种问题. AsyncTask(异步任务处理)在使用AsyncTask时处理类需要继承AsyncTask,提供三个泛型参数,并且重载AsyncTask的四个方法(至少重载一个). 三个泛型参数:1.Param 任务执行器需要的数据类型2.Progres

2017年6月13日 前言 前几日在改Bug时看到好多调试时用的日志语句都被一个日志开关控制着它的执行权.形如: if(Constants.LOG_TAG){ Log.d(TAG, "Initialize finish! index:" + idx); } 又为了方便日后遇到问题时的分析,还要加上很多类似的日志语句.这时突然很好奇“大量的”条件判断语句需要多消耗多少系统资源,以及不同的条件表达式占用系统资源的差异情况.为此,特意设计了一个简单的小实验,通过取多组不同环境下这几种情形的耗

前言 app启动耗时过长的话,无论你的app里面的内容多么丰富有趣,作为一个用户,首先是没有耐心去等待的,如果我是一个用户,我会这样想:这是什么垃圾公司出的什么烂app,再等2s不进来就卸载,黑人问号???还真是垃圾,还没出来;于是乎,长按拖拽卸载,一套带走... 从个人层面讲,是对研发人员能力的否定;从公司层面讲,就是对该公司的否定;诸如,这家公司出的app很垃圾,同类产品也不会优先选择.由此可见,app启动耗时首先决定着它的第一体验,快不快,流不流畅都是之后才看得到的;而对于app启动耗时的

No subscribers registered for event class com.test.MessageEvent import de.greenrobot.event.EventBus;  不是 org.....那个包 内存中要先有订阅者,然后发送者才能把信息发送到他那. A->B ,Activity A发送给B, 则B这个Activity要先有. 可以配置B为app的启动页面,然后跳转到A,则此时内存中AB都有(先有B,再有A),然后A发送消息给B,最终B的吐司能在A页面上看到,

测试从sd卡读1k大小的文件,再写1k大小的文件,由于处理耗时很短,所以循环500次,查看耗时:测试写1k大小的文件,直接在内存构造一个1k的buffer,将这个buffer直接写到文件,同样循环500次,查看耗时. 思路:首先读写文件,建立文件输入输出流,然后将读取的数据直接写入文件,打印时间戳,查看耗时:只写文件,新建一个1k的buffer,然后用文件输出流写入文件,打印时间戳,查看耗时. 直接上代码: package com.example.ghimtim.myapplication; i

作者:林基宗 Activity的启动速度是很多开发者关心的问题,当页面跳转耗时过长时,App就会给人一种非常笨重的感觉.在遇到某个页面启动过慢的时候,开发的第一直觉一般是onCreate执行速度太慢了,然后在onCreate方法前后记录下时间戳计算出耗时.不过有时候即使把onCreate方法的耗时优化了,效果仍旧不明显.实际上影响到Activity启动速度的原因是多方面的,需要从Activity的启动流程入手,才能找到真正问题所在. Activity启动流程 如果要给Activity的"启动&q

在开发当中,有时候可能界面嵌套较多,那么导致控件实例化增多,有时候会大大影响界面加载的速度,特别在viewpage中的时候,要是第一页里面要inflate一个控件比较多的页面的时候,就会影响整个Activity的启动速度,会有一定的延迟出现,影响用户体验. 解决办法其实非常简单,就是另开线程加载控件,让整个Activity先出来,等加载控件的线程加载完成之后再去刷新viewpage,就可以解决Activity加载延迟问题,最终的效果是没有数据的界面现出来,然后添加数据到控件.

private long mDrawnRealTime; 起点:mDrawnRealTime = SystemClock.elapsedRealtime(); 终点: long delay = SystemClock.elapsedRealtime() - mDrawnRealTime; // 差值 Slog.d(TAG, "do something after " + delay + " ms");

当textview的宽设置为wrap_content的时候,底层会调用checkForRelayout函数,这个函数根据文字的多少重新开始布局 因此将宽度设置为固定值或者match_parent的时候会大幅度减少绘制时间

内容概述 本文内容来自开发文档"Traning > Displaying Bitmaps Efficiently",包括大尺寸Bitmap的高效加载,图片的异步加载和数据缓存. Bitmap的处理和加载非常重要,这关系到app的流畅运行和内存占用,如果方法不当,很容易导致界面卡顿和OOM.其中的原因大致有: android系统对进程的内存分配限制,移动设备的配置较低. Bitmap会消耗很大内存.比如相机拍下的 2592x1936 像素的照片,以ARGB_8888 格式一次加载到

前言: 最近公司C轮融资成功了,移动团队准备扩大一下,需要招聘Android开发工程师,陆陆续续面试了几位Android应聘者,面试过程中聊到性能优化中如何避免内存泄漏问题时,很少有人全面的回答上来.所以决定抽空学习总结一下这方面的知识,以及分享一下我们是如何检测内存泄漏的.我们公司使用开源框架LeakCanary来检测内存泄漏. 什么是内存泄漏? 有些对象只有有限的生命周期.当它们的任务完成之后,它们将被垃圾回收.如果在对象的生命周期本该结束的时候,这个对象还被一系列的引用,这就会导致内存泄漏