Android异步任务的使用方法_Linux编程_Linux公社-Linux系统门户网站
你好，游客
Android异步任务的使用方法
来源：Linux社区&
作者：renhui
上面的很多操作是不能直接放在ui线程上面的。当ui线程被阻塞5秒以上的时候应用会出现未响应的对话框过。当此现象出现的时候会直接影响用户的用户体验的。所以我们需要通过方法对异步任务或者操作进行相关的处理。在这里罗列出集中相关的处理方法：
首先我们最先想到的应该是使用Thread+Handler实现非UI线程更新UI界面，即在线程执行的时候通过发送message来通过Handler来处理和更新ui。 另外一种方法就是通过异步任务：AsyncTask来进行数据的处理，通过继承AsyncTask并重写相关的方法，比较重要的是就是doBackGround和onPostExecutor的重写。一个负责处理事务，一个负责更新界面。
基本上我们最开始想到的就是上面说的是这两个方法，其实还有两个方法，一个是通过service，另外一个就是通过IntentService来进行处理。
14.04 x64配置Android 4.4 kitkat编译环境的方法
Ubuntu 12.04搭建Android开发环境
Ubuntu 14.04 配置 Android SDK 开发环境
64位Ubuntu 11.10下Android开发环境的搭建(JDK+Eclipse+ADT+Android SDK详细)
Ubuntu 12.10 x64 安装 Android SDK
更多Android相关信息见 专题页面
本文永久更新链接地址：
相关资讯 & & &
& (04月06日)
& (02月23日)
图片资讯 & & &
　　　同意评论声明
　　　发表
尊重网上道德，遵守中华人民共和国的各项有关法律法规
承担一切因您的行为而直接或间接导致的民事或刑事法律责任
本站管理人员有权保留或删除其管辖留言中的任意内容
本站有权在网站内转载或引用您的评论
参与本评论即表明您已经阅读并接受上述条款求助，android多线程开发，如何控制线程定时刷新，并停止
[问题点数：32分]
求助，android多线程开发，如何控制线程定时刷新，并停止
[问题点数：32分]
不显示删除回复
显示所有回复
显示星级回复
显示得分回复
只显示楼主
相关帖子推荐：
2014年6月 移动开发大版内专家分月排行榜第一2014年3月 移动开发大版内专家分月排行榜第一
2014年11月 移动开发大版内专家分月排行榜第二2014年4月 移动开发大版内专家分月排行榜第二2014年2月 移动开发大版内专家分月排行榜第二
匿名用户不能发表回复！|
每天回帖即可获得10分可用分！小技巧：
你还可以输入10000个字符
(Ctrl+Enter)
请遵守CSDN，不得违反国家法律法规。
转载文章请注明出自“CSDN（www.csdn.net）”。如是商业用途请联系原作者。大家有哪些好的android开发习惯？
本人刚开始学习android开发，经过一段时间的学习感觉一些开发过程中的习惯也十分的重要，比如文件命名，代码的备份，注释等。由于没有人带，自己在这方面有很多坏的习惯。各位大神有没有什么经验来分享下吧
按投票排序
受一个朋友邀请来回答这问题，以上各位都回答得很不错，不过对于一个Android开发新手来说，能有更详细的答案那可能会更有帮助。以下内容是来自eoe的一个网友的回答，但现在已经找不回那个帖子，文字已经珍藏起来。感谢原著作者的。一、Android编码规范1.java代码中不出现中文，最多注释中可以出现中文；2.局部变量命名、静态成员变量命名：只能包含字母，单词首字母出第一个都为大写，其他字母都为小写；3.常量命名：只能包含字母和_，字母全部大写，单词之间用_隔开；4.layout中的id命名：命名模式为：view缩写_模块名称_view的逻辑名称view的缩写详情如下LayoutView：lvRelativeView:rvTextView:tvImageView:ivImageButton:imButton:btn5.activity中的view变量命名命名模式为：逻辑名称+view缩写建议：如果layout文件很复杂，建议将layout分成多个模块，每个模块定义一个moduleViewHolder，其成员变量包含所属view6.strings.xml中的id命名：命名模式：activity名称_功能模块名称_逻辑名称
activity名称_逻辑名称
common_逻辑名称strings.xml中，使用activity名称注释，将文件内容区分开来7.drawable中的图片命名命名模式：activity名称_逻辑名称/common_逻辑名称7.styles.xml：将layout中不断重现的style提炼出通用的style通用组件，放到styles.xml中；8.使用layer-list和selector9.图片尽量分拆成多个可重用的图片10.服务端可以实现的，就不要放在客户端11.引用第三方库要慎重，避免应用大容量的第三方库，导致客户端包非常大12.处理应用全局异常和错误，将错误以邮件的形式发送给服务端13.图片的.9处理14.使用静态变量方式实现界面间共享要慎重15.Log(系统名称 模块名称 接口名称，详细描述)16.单元测试（逻辑测试、界面测试）17.不要重用父类的handler，对应一个类的handler也不应该让其子类用到，否则会导致message.what冲突18.activity中在一个View.OnClickListener中处理所有的逻辑19.strings.xml中使用%1$s实现字符串的通配20.如果多个Activity中包含共同的UI处理，那么可以提炼一个CommonActivity，把通用部分叫由它来处理，其他activity只要继承它即可21.使用button+activitgroup实现tab效果时，使用Button.setSelected(true)，确保按钮处于选择状态，并使activitygroup的当前activity与该button对应22.如果所开发的为通用组件，为避免冲突，将drawable/layout/menu/values目录下的文件名增加前缀23.数据一定要效验，例如字符型转数字型，如果转换失败一定要有缺省值；服务端响应数据是否有效判断；二、Android性能优化
1.http用gzip压缩，设置连接超时时间和响应超时时间
http请求按照业务需求，分为是否可以缓存和不可缓存，那么在无网络的环境中，仍然通过缓存的httpresponse浏览部分数据，实现离线阅读。
2.listview 性能优化
1).复用convertView
在getItemView中，判断convertView是否为空，如果不为空，可复用。如果couvertview中的view需要添加listerner，代码一定要在if(convertView==null){}之外。
2).异步加载图片
item中如果包含有webimage，那么最好异步加载
3).快速滑动时不显示图片
当快速滑动列表时（SCROLL_STATE_FLING），item中的图片或获取需要消耗资源的view，可以不显示出来；而处于其他两种状态（SCROLL_STATE_IDLE 和SCROLL_STATE_TOUCH_SCROLL），则将那些view显示出来
3.使用线程池，分为核心线程池和普通线程池，下载图片等耗时任务放置在普通线程池，避免耗时任务阻塞线程池后，导致所有异步任务都必须等待
4.异步任务，分为核心任务和普通任务，只有核心任务中出现的系统级错误才会报错，异步任务的ui操作需要判断原activity是否处于激活状态
5.尽量避免static成员变量引用资源耗费过多的实例,比如Context
6.使用WeakReference代替强引用，弱引用可以让您保持对对象的引用，同时允许GC在必要时释放对象，回收内存。对于那些创建便宜但耗费大量内存的对象，即希望保持该对象，又要在应用程序需要时使用，同时希望GC必要时回收时，可以考虑使用弱引用。
7.超级大胖子Bitmap
及时的销毁(Activity的onDestroy时，将bitmap回收)
设置一定的采样率
巧妙的运用软引用
drawable对应resid的资源，bitmap对应其他资源8.保证Cursor 占用的内存被及时的释放掉，而不是等待GC来处理。并且 Android明显是倾向于编程者手动的将Cursor close掉
9.线程也是造成内存泄露的一个重要的源头。线程产生内存泄露的主要原因在于线程生命周期的不可控
10.如果ImageView的图片是来自网络，进行异步加载
11.应用开发中自定义View的时候，交互部分，千万不要写成线程不断刷新界面显示，而是根据TouchListener事件主动触发界面的更新三、AndroidUI优化
1.layout组件化，尽量使用merge及include复用
2.使用styles，复用样式定义
3.软键盘的弹出控制，不要让其覆盖输入框
4.数字、字母和汉字混排占位问题：将数字和字母全角化。由于现在大多数情况下我们的输入都是半角，所以 字母和数字的占位无法确定，但是一旦全角化之后，数字、字母的占位就和一个汉字的占位相同了，这样就可以避免由于占位导致的排版问题。
5.英文文档排版：textview自动换行时要保持单词的完整性，解决方案是计算字符串长度，然后手动设定每一行显示多少个字母并加上‘n‘
6.复杂布局使用RelativeLayout
7.自适应屏幕，使用dp替代pix
8.使用android:layout_weight或者TableLayout制作等分布局
9.使用animation-list制作动画效果
不请自来说点废话。肥肥做了四年 Android 开发，其中三年时间是在做各种中间件。我觉得首先是命名规范。命名规范这种东西每个人都有自己的风格，Google 也有自己的一套规范（多看看 Android 系统源码就明白了）。好的规范可以有效地提高代码的可读性，对于将来接手代码的小伙伴也是一件幸事。题主可以自行 Google 一下 Java （Android）命名规范，会由不少的博客介绍。其次是注释。严格来说这个应该属于命名规范的范畴。注释一方面是帮助自己记忆 ，另一方面是团队协作中的一个规范，特别是对于开发 API 的小伙伴来说，总不能天天被人跟在屁股后面问你这个接口是什么作用，你这参数是什么意思？好的注释配合好的命名规范，可以省去很多沟通上的成本。 注释至少要有如下几方面的内容：该接口（或类）的作用。注意写的应该是作用，而不是你做了什么；参数列表的各个参数说明；返回值的说明；如果有异常抛出，对抛出异常的说明；如果注释是在类上的，总得留个联系方式吧，免得以后出了问题都找不到原作者。当然了，如果类设计的过于让人蛋疼，我也可以联系到作者，约出来，打一顿的嘛。其他你认为有必要解释。再者是版本控制。就算是自己一个人写代码，版本控制也是有必要的。Git 也好，SVN 也好，都是有帮助的。版本控制一方面是对自己代码的一个备份，另一方面，如果想回滚到历史版本也是极有帮助的。所以最好能够熟悉一下 Git 或者 SVN 的使用。第四是名词表。这个应该属于肥肥自创。Android 是围绕四大组件特别是 Activity 和 Service 进行开发的，但是如果项目庞大，有多个 Activity 存在，那么记住每一个 Activity 的类名是很难得，但是记住每一个 Activity 的功能却相对容易。故而肥肥在带项目的过程中自创了名词表这一东东。记录了每一个模块、组件、甚至是每一个 Activity 的官方统一名称（比如，功能是作品列表的 Activity，名称就叫作品列表页，对应的类是 WorksListActivity），在沟通过程中，大家（包括测试人员等项目相关人员）统一说“作品列表页”。当时的初衷是解决测试团队的Bug 描述过于模糊（如果有多个列表页，测试人员往往会写列表页****问题）。第五是不要重复制造轮子。这个适用于代码层面以及业务层面。第六是千万不要饿着肚子写代码。先挖这个坑，吃了东西再找时间继续写。=========================刚才公司小伙伴在互换礼物，来晚了===================第七这一点应该不算是习惯，但是却需要每一个 Android 程序猿需要慎重再者慎重的地方---内存管理。Android 虽然延续了 Java 的垃圾回收机制，但是并不意味 Android 应用程序就不会出现内存问题。在 Android 中引起内存开销过大的往往是 BitMap 对象。BitMap.java实际上是 Skia 引擎中对图片处理部分的 Java 层代码而已（真正工作的是 C++层代码，通过 JNI 封装，最后提供 Java 层的接口），那么你创建 BitMap 对象实际上是创建了两部分内存，一部分是 Java 层的，就是
BitMap对象，Java 的垃圾回收会在合适的时机回收这一部分内存。另一部分是 C++层面的，也就是通过 JNI 调用 C++层的代码分配的那一部分内存。Java 的垃圾回收是不会回收这一部分内存的，所以如果不手动释放的话就容易引起内存问题。第八是千万不要阻塞用户主线程。用户主线程就是 UI 线程，主要负责 UI 的绘制（除 SurfaceView 外，其他 View 对象都是需要在 UI 线程中进程操作的）。为了保证 App 的交互尽可能的流程，请不要在 UI 线程中进行耗时操作（文件读写、Http 请求（4.0之前可以在主线程中发起）等）。否则会引起两种可能的问题：第一是造成用户交互极度不流畅，第二容易触发 ANR 的超时机制（UI 线程5秒，广播10秒）。第九是严格把控生命周期（Activity、Service、ContentProvider 等）。在每一个生命周期事件中，明确应该做什么不应该做什么是很有必要的，不然也会容易造成各种莫名其妙的问题（比如 onCreate 中使用了 onResume 中才初始化的对象）。第十是在使用 XML 文件进行 UI 布局时，应该尽量减少 Layout 的嵌套层级。Layout 的过度嵌套会造成渲染时资源开销过大的问题。写到这里突然不想写了。由于右手受伤的缘故，今天高强度的键盘敲击已经造成右手非常疲惫。等有时间的时候再写吧。==============日=============第一次在知乎上的得到这么多赞（竟然有24了），受宠若惊，决定继续补充前面的各种废话。第十一应该是资源文件的使用，资源文件包括图片、字符串、尺寸、颜色等等。在使用尺寸资源的时候应该尽量使用像素无关的单位，比如 dp 和 sp。而字符串资源（比如 Button 上显示的名称）也应该尽可能的抽离出来，使用 res/value 下的xml 文件进行维护。一方面方便日后管理，另一方面方便国际化。第十二多线程以及线程池的使用。前面说过应该尽量避免在主线程中执行耗时操作，那么多线程就变得很有必要。对于 Java 来说，线程的创建与销毁是非常占用资源的，线程的滥用（随手 new Thread 等）会造成 App 整体性能的下降。Java 提供了Executors的线程池方案，而 Android 自身也提供了AsyncTask 这样的异步任务方案（实际上也是线程池）。第十三 Java 的权限控制机制。Java提供了public, private, protected 三个访问权限修饰词，提供了以下四种访问权限控制机制：包访问权限；Public访问权限；Private访问权限；Protected访问权限；访问权限的合理使用可以有效地隐藏实现，避免将不必要的数据或接口暴露出来。第十四 final 和 static 关键字的合理使用。很多人觉得这是很基础的东西，但是 final 和 static 关键字的合理使用能够有效提升代码的执行效率，而不合理使用则后患无穷。第十五 Android 设备的内存资源是极度珍贵的，合理的使用、回收内存也是一种好的编程习惯。Java 对象的引用类型会影响到垃圾回收对象的时机。Java 有强引用、 软引用、 弱引用、虚引用，以及 Android 增加的 Lru 内存管理。建议题主了解一下这四种引用类型的特点以及 Lru 内存管理的具体实现。第十六 接口和抽象类。这是老生常谈的话题了，但却是永恒的话题。接口和抽象类的合理使用，可以增加代码的可维护性和扩展性。接口和抽象类也是各种设计模式的基石。第十七 软件设计的六大设计原则，即针对接口编程，不针对实现编程单一职责原则开放封闭原则里氏代换原则迪米特法则合成聚合复用原则第十八 统一项目的编码格式（推荐使用 UTF-8）。如果多人协作，这种举措显得尤为重要。由此引申出来的另外一个规范就是，规范统一命名风格，即团队中使用相同的命名风格。（感谢@ 的提醒。更新于日17:22:20）第十九 TextView（往往 TextView 派生子类同样适用）调用 setText 方法设置一个 int 型的数据，千万要将该值转为 String，否则在某些设备中它会默认去查询 R 文件中定义的资源第二十 使用友盟分享 SDK，需要执行分享的 Activity 请不要为该 Activity 设置android:process属性。比如你的 App 运行在 com.codingfish.test 进程，需要产生分享动作的Activity 设置 android:proces=":com.codingfish.hello" ，那么新浪微博就会出现你设置的分享内容没有显示的问题。该 Bug 已经提交给友盟的技术人员，但是 N 久没有得到修复。第二十一 上线之前一定要使用正式签名打包。某朋友公司 Android 的应用上架之前，负责打包上线的童鞋（新人，老人已离职，只有这一个Android）没有签名的概念，直接将 Debug 签名的 Apk 投放到渠道了，到现在还有一批设备没有替换回来。第二十二 在 Activity 中尽可能少的创建 Handler 对象，创建一个主线程 Handler，一个后台 HandlerThread 就可以了。第二十三 使用线程的地方尽量不要 new Thread，而是使用 AsyncThread 。第二十四 onCreate(Bundle savedInstanceState)
切记将super.onCreate(savedInstanceState);放在一切业务的前面。第二十五 创建了四大组件一定记得要在 AndroidManifest 文件中声明（当然 BroadcastReceiver 可以动态注册）。=============日补充==============刚才 Google 了一下，有一篇文章介绍的不错，肥肥做了一次伸手党，直接复制过来了。原文链接： 第二十六 为Activity声明系统配置变更事件
系统配置变更事件是指转屏，区域语言发生变化，屏幕尺寸发生变化等等，如果Activity没有声明处理这些事件，发生事件时，系统会把Activity杀掉然后重启，并尝试恢复状态，Activity有机会通过onSaveInstanceState()保存一些基本数据到Bundle中，然后此Bundle会在Activity的onCreate()中传递过去。虽然这貌似正常，但是这会引发问题，因为很多其他的东西比如Dialog等是要依赖于具体Activity实例的。所以这种系统默认行为通常都不是我们想要的。为了避免这些系统默认行为，就需要为Activity声明这些配置，如下二个是每个Activity必须声明的：&activity android:configChanges="orientation|keyboardHidden"&几乎所有的Activity都要声明如上，为什么Android不把它们变成Default的呢?第二十七
尽量使用Android的API 这好像是废话，在Android上面开发不用Android API用什么？因为Android几乎支持Java SE所有的API，所以有很多地方Android API与Java SE的API会有重复的地方，比如说对于文件的操作最好使用Android里面Context封装的API，而不要直接使用File对象：Context.openFileOutput(String); // no File file = new File(String)原因就是API里面会考虑到Android平台本身的特性；再如，少用Thread，而多使用AsyncTask等。第二十八
要考虑到Activity和进程被杀掉的情况
如了通常情况退出Activity外，还有Activity因其他原因被杀的情况，比如系统内存过低，系统配置变更，有异常等等，要考虑和测试这种情况，特别是Activity处理重要的数据时，做好的数据的保存。第二十九
小心多语言
有些语言真的很啰嗦，中文或英文很简短就能表达的事情到了其他语言就变的死长死长的，所以如果是wrap_content就可能把其他控制挤出可视范围； 如果是指定长度就可能显示不全。也要注意特殊语言比如那些从右向左读的语言。第三十
不要用四大组件去实现接口
一是组件的对象都比较大，实现接口比较浪费，而且让代码更不易读和理解； 另外更重要的是导致多方引用，可能会引发内存泄露。第三十二 用getApplication()来取Context当参数 对于需要使用Context对象作为参数的函数，要使用getApplication()获取Context对象当参数，而不要使用this，除非你需要特定的组件实例！getApplication()返回的Context是属于Application的，它会在整个应用的生命周期内存在，远大于某个组件的生命周期，所以即使某个引用长期持有Context对象也不会引发内存泄露。第三十三 主线程只做UI控制和Frameworks回调相关的事。附属线程只做费时的后台操作。交互只通过Handler。这样就可以避免大量的线程问题。第三十四 Frameworks的回调不要做太多事情仅做必要的初始化，其他不是很重要的事情可以放到其他线程中去做，或者用Handler Schedule到稍后再做。第三十五
要考虑多分辨率
至少为hdpi, mdpi, ldpi准备图片和布局。元素的单位也尽可能的使用dip而不要用px。第三十六
利用Android手机的硬键
几乎所有的Android手机都有BACK和MENU，它们的作用是返回和弹出菜单，所以就不要再在UI中设计返回按扭和菜单按扭。很多优秀的应用如随手记和微信都有返回键，他们之所以有是因为他们都是从iOS上移植过来的，为了保存体验的一致，所以也有了返回和菜单。但这不够Android化，一个纯正的Android是没有必须重复硬键的功能的。PS：多看看官方的 APIDEMO，多读一下 上的内容。肥肥上面的各种废话，题主基本都能在开发者官网找到。第三十七 最好的一个习惯，放到最后压轴吧。善用 Google 和知乎。PS： 鉴于 Android 官网和 Google 不能打开，肥肥还是顺便分享一个 hosts 文件吧，至于怎么用，不多说了吧？
===================上面的 hosts 已经废弃，下面的是最新的host 托管地址============
感谢这位前辈。
写一个抽象的BaseActivity.java，将初始化抽象为setContentView()、findViews()、getData()、showContent()这四个方法，所有的Activity都继承它：public abstract class BaseActivity extends Activity{
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
public void init(){
setContentView();
findViews();
getData();
showContent();
public abstract void setContentView();
public abstract void findViews();
public abstract void getData();
public abstract void showContent();
2. 方法返回值不返回null，返回空值，比如：public static List&String& getFolderFiles( String folderPath ){
List&String& fileList = new ArrayList&String&( );
if( TextUtils.isEmpty( folderPath ) ){
return fileList;
File file = new File( folderPath );
if( file.isDirectory( ) ){
File[] files = file.listFiles( );
if( null != files ){
fileList = new ArrayList&String&( );
for( File subFile : files ){
fileList.add( subFile.getPath( ) );
return fileList;
3. 在方法顶部做入参判断，入参异常直接返回，比如：public static List&String& getAssertsFiles( Context context ){
List&String& assertsFileList = new ArrayList&String&( );
if( null == context ){
return assertsFileList;
AssetManager assetManager = context.getAssets();
String[] files = null;
files = assetManager.list("");
assertsFileList = Arrays.asList( files );
} catch (IOException e) {
e.printStackTrace( );
return assertsFileList;
4. 使用List、Map而不是ArrayList、HashMap声明成员变量、作为返回值、作为入参等等，尽量用抽象而不是具体实现。5. 在任何时候不使用类的finalize方法释放资源；6. 在finally中关闭文件流、cursor等等；7. 封装一个DebugUtils类来管理程序中所有的打印：public class DebugUtils{
public static final String TAG = "Debug";
private DebugUtils( ){
public static void println( String printInfo ){
if( Debug.DEBUG_MODE && null != printInfo ){
System.out.println( printInfo );
public static void print( String printInfo ){
if( Debug.DEBUG_MODE && null != printInfo ){
System.out.print( printInfo );
public static void printLogI( String logInfo ){
printLogI( TAG, logInfo );
public static void printLogI( String tag, String logInfo ){
if( Debug.DEBUG_MODE && null != tag && null != logInfo ){
Log.i( tag, logInfo );
public static void printLogE( String logInfo ){
printLogE( TAG, logInfo );
public static void printLogE( String tag, String logInfo ){
if( Debug.DEBUG_MODE && null != tag && null != logInfo ){
Log.e( tag, logInfo );
public static void printLogW( String logInfo ){
printLogW( TAG, logInfo );
public static void printLogW( String tag, String logInfo ){
if( Debug.DEBUG_MODE && null != tag && null != logInfo ){
Log.w( tag, logInfo );
public static void printLogD( String logInfo ){
printLogD( TAG, logInfo );
public static void printLogD( String tag, String logInfo ){
if( Debug.DEBUG_MODE && null != tag && null != logInfo ){
Log.d( tag, logInfo );
public static void printLogV( String logInfo ){
printLogV( TAG, logInfo );
public static void printLogV( String tag, String logInfo ){
if( Debug.DEBUG_MODE && null != tag || null != logInfo ){
Log.v( tag, logInfo );
public static void printLogWtf( String logInfo ){
printLogWtf( TAG, logInfo );
public static void printLogWtf( String tag, String logInfo ){
if( Debug.DEBUG_MODE && null != tag && null != logInfo ){
Log.wtf( tag, logInfo );
public static void showToast( Context context, String toastInfo ){
if( null != context && null != toastInfo ){
Toast.makeText( context, toastInfo, Toast.LENGTH_LONG ).show( );
public static void showToast( Context context, String toastInfo, int timeLen ){
if( null != context && null != toastInfo && ( timeLen & 0 ) ){
Toast.makeText( context, toastInfo, timeLen ).show( );
public static void printBaseInfo( ){
if( Debug.DEBUG_MODE ){
StringBuffer strBuffer = new StringBuffer( );
StackTraceElement[ ] stackTrace = new Throwable( ).getStackTrace( );
strBuffer.append( "; class:" ).append( stackTrace[ 1 ].getClassName( ) )
.append( "; method:" ).append( stackTrace[ 1 ].getMethodName( ) )
.append( "; number:" ).append( stackTrace[ 1 ].getLineNumber( ) )
.append( "; fileName:" ).append( stackTrace[ 1 ].getFileName( ) );
println( strBuffer.toString( ) );
public static void printFileNameAndLinerNumber( ){
if( Debug.DEBUG_MODE ){
StringBuffer strBuffer = new StringBuffer( );
StackTraceElement[ ] stackTrace = new Throwable( ).getStackTrace( );
strBuffer.append( "; fileName:" ).append( stackTrace[ 1 ].getFileName( ) )
.append( "; number:" ).append( stackTrace[ 1 ].getLineNumber( ) );
println( strBuffer.toString( ) );
public static int printLineNumber( ){
if( Debug.DEBUG_MODE ){
StringBuffer strBuffer = new StringBuffer( );
StackTraceElement[ ] stackTrace = new Throwable( ).getStackTrace( );
strBuffer.append( "; number:" ).append( stackTrace[ 1 ].getLineNumber( ) );
println( strBuffer.toString( ) );
return stackTrace[ 1 ].getLineNumber( );
public static void printMethod( ){
if( Debug.DEBUG_MODE ){
StringBuffer strBuffer = new StringBuffer( );
StackTraceElement[ ] stackTrace = new Throwable( ).getStackTrace( );
strBuffer.append( "; number:" ).append( stackTrace[ 1 ].getMethodName( ) );
println( strBuffer.toString( ) );
public static void printFileNameAndLinerNumber( String printInfo ){
if( null == printInfo || !Debug.DEBUG_MODE ){
StringBuffer strBuffer = new StringBuffer( );
StackTraceElement[ ] stackTrace = new Throwable( ).getStackTrace( );
strBuffer.append( "; fileName:" ).append( stackTrace[ 1 ].getFileName( ) )
.append( "; number:" ).append( stackTrace[ 1 ].getLineNumber( ) ).append( "\n" )
.append( ( null != printInfo ) ? printInfo : "" );
println( strBuffer.toString( ) );
public static void showStrictMode( ) {
if (DebugUtils.Debug.DEBUG_MODE) {
StrictMode.setThreadPolicy(new StrictMode.ThreadPolicy.Builder()
.detectDiskReads().detectDiskWrites().detectNetwork().penaltyLog().build());
StrictMode.setVmPolicy(new StrictMode.VmPolicy.Builder()
.detectLeakedSqlLiteObjects().detectLeakedClosableObjects().penaltyLog().penaltyDeath().build());
public static void d(String tag, String msg){
if(DebugUtils.Debug.DEBUG_MODE){
Log.d(tag, msg);
public class Debug{
public static final boolean DEBUG_MODE = true;
8. 静态类的构造方法私有化，具体实例参见7；9. 没有必要用硬件加速的页面在AndroidMainfest.xml中将其关掉android:hardwareAccelerated="false"
10. 在没有使用到多点触控的页面，通过在主题中设置下列两个属性将多点触控关掉：&item name="android:windowEnableSplitTouch"&false&/item&
&item name="android:splitMotionEvents"&false&/item&
11. 定义一个防止视图重复点击的静态类，在需要做防止重复点击的地方加上该判断：public class BtnClickUtils {
private static long mLastClickTime = 0;
private BtnClickUtils( ){
public static boolean isFastDoubleClick() {
long time = System.currentTimeMillis();
long timeD = time - mLastClickTime;
if ( 0 & timeD && timeD & 500) {
return true;
mLastClickTime = time;
return false;
12. 在布局中使用LinearLayout的android:weight属性时，将view的android:layout_width属性设置为0dp；13. 涉及到APP的核心数据全部加密处理，在使用的时候解密；14. 如果你的IDE是Eclipse，用好这几个快捷键，爽歪歪滴：CTRL + SHIFT + OALT + SHIFT + MALT + SHIFT + SCTRL + OCTRL + /ALT + /CTRL + DCTRL + KALT + → 和 ALT + 左箭头CTRL + SHIFT + X 和 CTRL + SHIFT + YF5、F6、F7、F8F11CTRL + M还有很多很多，先就写在这里吧，希望对题主有帮助。再补一刀：如果题主有代码洁癖，很注重代码质量，可以详尽阅读SonarQube关于JAVA编码的规则：，如果条件允许，自己配置一下，每周通过Sonar运行一下自己的代码，以提高代码质量。一些开发中的细节问题可以参见我的博客：
上边说的好多都是个人习惯而已，说不上好和不好（比如抽象出基类，写一些抽象方法什么的。。。虽然大部分情况下适用，但是很有一些情况这种做法是十分不灵活的）。你去看GitHub上边的优秀开源项目，除了变量命名清晰外，也抽象不出什么统一规范（当然，写ListView善用viewholder做缓存这种人尽皆知的就不说了）抛开代码，要说有什么好习惯，我觉得有一点就是——一定全部用xml一点一点写静态界面，前边可视化部分只用来预览，千万别往里边拖控件。养成良好习惯，从初学做起。//分割线啊对了，安利一下，如果要是在意代码风格以及维护的话，《重构》这本书很不错。虽然是讲重构的，但是如果在初期就注意书中说的一些点的话，是能编写出质量非常高，可维护性非常高的代码的。当然，书中关于局部变量的控制的苛刻程度太高了，到了令人发指的地步。总之，还是很有裨益的。
我每次写一个新的Feature的时候，都会新开一个工程，然后把新功能的Demo测试完毕才加到我现在在写的工程里面。当然我觉得主要原因是我代码水平有限……我的队友们从来都是轻描淡写的在工程里面直接加东西……
说说应用层的开发：1，写代码前先在本子上画好大概的模块图，类图，能和同事讨论下最好。2，使用开源代码务必搞懂主要实现方式，以便填坑。3，应用内的资源要统一管理，如线程，缓存，网络，数据库，配置，设备事件监听等等，以便性能分析和维护。4，合理使用设计模式，做好UI之间，和业务以及数据层的解耦非常必要，以便应付产品汪（褒义词）的各种变化。5，管理好各种对象的生命周期，谁说Java不泄漏内存？来我泄漏给你看看。6，不要总是TODO，因为翔留下就留下了，还得写新的翔，等后来的童鞋来收拾，被人骂骂也不好。7，没事多看下Github，Android程序基本可以用一个个开源库搭积木搞出来，当然业务除外。也可以看看其他平台的库和各种框架，不要把自己局限在Android上。8，关于注释，尽量写未来自己还看得懂的注释，曾经阅读同事的代码，懂了之后留下一句注释，半年后再次阅读，感叹道，辛亏老子留了条注释，不然又看不懂了。9，代码风格团队要统一10，提高基本素质，做程序员，而不是Android程序员。Google下，有Github上的Android常用库和框架这样的文章。手机码字，见谅
看了楼上几位分享关于Android一些具体的问题技巧,我这里就不多说了来分享一下其他的东西.不仅仅是Andriod,其他的程序员同样适用.①一定要写笔记.你可以不写博客,但是一定要有笔记.好记性不如烂笔头.当然对于程序员来说,一个电子的笔记远远好与纸质的笔记②写博客.博客是附带品.但是你只有去写博客了,才知道别人的博客是怎么写出来了调查发现,写博客的程序员工资要搞那么5000+.博客也是你和别人交流技术的东西.别人可以从你文章中学习东西,你可以与别人交流.③尽量阅读英文文档,而不是有问题就百度.有问题问Strack Overflow④不要等别人告诉你这东西怎么用,那东西怎么学,只有自己去提前研究了,你才能更胜一筹.⑤保持不断学习
多写，不断重构
楼上各位多半是从代码本身的角度出发，我来说点其他的。好的代码是有共性的，不局限于android。那么首先你的的代码要在一定范围内可测，一定范围内意味着避免那些无意义的单元测试，测试代码不在于多，而在于它能在多大程度上加快你的重构速度以及代码稳健度。其次，结构要简单，最好几句话之内可以让新人理解最外围的结构。再次，要做好版本控制，善用git的绝技branching。最后，注释不求多但求精准。理想状态下，你的代码应该是自解释的，但对于一些比较复杂的逻辑，则需要清晰明了的注释。注意，一旦你开始写注释，你就要开始维护它，否则将适得其反。还有很多其他的懒得说了。还有一点要注意的，罗马不是一条建成的，所以别想着一上来就把代码写成完美作品，既不现实又浪费时间。你写代码要把握一个平衡，在大战略上要结构清晰，尽可能的解耦，但是具体到某个函数或类，你可以先写一些比较烂的代码把功能完成，然后再不断快速重构，前提是你有一定的单元测试做保镖。
@肥肥鱼的回答已经比较全且实用了，赞一个。补充一点，一定要看android设计规范。这个不仅涉及到了UI设计，在你开发过程中也会用到。比如，什么位置下的什么控件该使用多少dp(dip)的宽高、margin及padding，Google都已经设定好了，你照做就行。(这些设定在给出的时候都有合理的解释，比自己从视觉上去估计数值强多了)
工作时遇到问题都记下来，等到下班和周末自己研究透这些问题，然后写成文章放在
英语得先学好， 不然命名谁也看不懂Android Open Source Code， 多看， 多读代码规范上， 《重构遗留代码》 不错一份能加单元测试的代码， 才是好代码。
每一个app的第一个功能，一定要是强制升级
个人感觉最多的几点：1.命名规范和变量声明时机（包括成员变量的初始化时机）2.子线程的使用一定要考虑同步问题3.学会看log，习惯看log，学会打log方便调试我遇到很多刚写程序的人或者接手新项目，一出错就大喊，我艹有bug，什么情况？其实你先看下出错堆栈，对于android（基本说的是java）大多都是空指针，很好解的，不会的直接复制异常第一句百度或者其他方式搜索，先了解这是什么错误再研究为什么会产生，然后想怎么解决，到了解决的过程如果一点感觉没有可以其他熟练的人交流，这时一般不会太反感，顶多懒得帮你看说不知道，你自己看。4.多理解原理（包括流程，源代码等）刚开发，经常会有程序执行到哪了的疑惑，或者什么时候干什么比较合适android里各种事件基本都是回调（listener），广播以及message来交互，在你熟悉应用基本组成后就开始慢慢看各种生命周期，各种回调的时机。Activity（最常见了），Service，View（这个是最麻烦了），我也是2年菜鸟，加油吧！
《编写可读代码的艺术》}