Android-性能优化、UI优化、代码优化(1)

Android性能优化系列之布局优化- http://blog.csdn.net/u012124438/article/details/54564659

关于烂代码的那些事 － 为什么每个团队存在大量烂代码 http://mp.weixin.qq.com/s?__biz=MzAwMDU1MTE1OQ==&mid=403520625&idx=1&sn=c59f3944760a055ee7b6d1dda4431e0a&scene=23&srcid=01138qxBuGkMMdTiBO6FyrjG#rd

微信为啥这么省流量（技术宅入）http://mp.weixin.qq.com/s?__biz=MjM5ODYxMDA5OQ==&mid=400163013&idx=1&sn=911cf71925e2ba50d47955a713134acb&scene=21#wechat_redirect

Android UI性能优化实战 识别绘制中的性能问题-- http://blog.csdn.net/lmj623565791/article/details/45556391

Java中关于内存泄漏出现的原因以及如何避免内存泄漏（超详细版汇总上）-- https://mp.weixin.qq.com/s?__biz=MzA5MzY4NTQwMA==&mid=2650995848&idx=2&sn=8985414234aca4f97360cb1c6e71d15b&scene=0&key=7b81aac53bd2393d8aee53fe6a7be1c2154c82b7f5dd6bae906f1a454056621536a166c144867eb9de56cac20e570233&ascene=7&uin=MjAyNjIyNTc0MQ%3D%3D&devicetype=android-23&version=26031933&nettype=WIFI&pass_ticket=TUwnC9FHWHu6OL%2F2wKyY%2F8R8agD9Z1ZenGu8v1lc3W24YuXQxvQ2b0JIOl%2FJyC2m

  手机卡顿出现的原因：
1，布局过于复杂：xml布局文件可能存在深层嵌套或者组件过多；
2，重复绘制：一个界面的某一点可能在同一时间进行了多次绘制；
3，内存抖动：系统内存是有限的，系统经常会将不活跃的进程置入外存中就是常说的虚拟内存，当调用它时再把它从外存转入内存，内存外存转换频率过大就会导致内存抖动；
4，性能瓶颈： 任务过多且执行调度不够好；
5，历史问原因，老代码以及设计问题；
6，团队人众多员 ，存在过多的代码合并和插入问题；
7，个别程序员的渣代码

Android渲染为什么要选择16ms，60fps的帧率去VSYNC一次呢？
在UI执行动画或者滑动ListView的时候感知到卡顿不流畅。
为了能够实现60fps，这意味着程序的大多数操作都必须在16ms内完成。
12fps大概类似手动快速翻动书籍的帧率，这明显是可以感知到不够顺滑的。
24fps使得人眼感知的是连续线性的运动，电影胶圈通常使用的帧率，
低于30fps是无法顺畅表现绚丽的画面内容的，60fps来达到想要的效果，
超过60fps是没有必要的。
开发app的性能目标就是保持60fps，这意味着每一帧你只有16ms=1000/60的时间
  卡顿优化解决方案：
1，减低布局的复杂度；
2，单线程任务不要太多；
3，适当调度；
4，将一些计算分担给服务器端。

> Android编码规范

 1.java代码中不出现中文，最多注释中可以出现中文
 2.局部变量命名、静态成员变量命名
　　只能包含字母，单词首字母出第一个外，都为大写，其他字母都为小写
 3.常量命名
　　只能包含字母和_，字母全部大写，单词之间用_隔开
 4.layout中的id命名
　　命名模式为：view缩写_模块名称_view的逻辑名称
　　view的缩写详情如下
　　LayoutView：lv
　　RelativeView:rv
　　TextView:tv
　　ImageView:iv
　　ImageButton:im
　　Button:btn
 5.activity中的view变量命名
　　命名模式为：逻辑名称+view缩写
　　建议：如果layout文件很复杂，建议将layout分成多个模块，每个模块定义一个moduleViewHolder，其成员变量包含所属view
 6.strings.xml中的id命名
　　命名模式：activity名称_功能模块名称_逻辑名称/activity名称_逻辑名称/common_逻辑名称
　　strings.xml中，使用activity名称注释，将文件内容区分开来
 7.drawable中的图片命名
　　命名模式：activity名称_逻辑名称/common_逻辑名称
 7.styles.xml：将layout中不断重现的style提炼出通用的style通用组件，放到styles.xml中;
 8.使用layer-list和selector
 9.图片尽量分拆成多个可重用的图片
 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事件主动触发界面的更新
> Android UI优化 --  布局优化：merge,ViewStub,include
 1.layout组件化，尽量使用merge及include复用
 2.使用styles，复用样式定义
 3.软键盘的弹出控制，不要让其覆盖输入框
 4.数字、字母和汉字混排占位问题：将数字和字母全角化。由于现在大多数情况下我们的输入都是半角，所以 字母和数字的占位无法确定，但是一旦全角化之后，数字、字母       的占位就和一个汉字的占位相同了，这样就可以避免由于占位导致的排版问题。
 5.英文文档排版：textview自动换行时要保持单词的完整性，解决方案是计算字符串长度，然后手动设定每一行显示多少个字母并加上‘n‘
 6.复杂布局使用RelativeLayout
 7.自适应屏幕，使用dp替代pix
 8.使用android:layout_weight或者TableLayout制作等分布局
 9.使用animation-list制作动画效果
> UI 优化
这是因为人眼与大脑之间的协作无法感知超过60fps的画面更新。12fps大概类似手动快速翻动书籍的帧率，这明显是可以感知到不够顺滑的。24fps使得人眼感知的是连续线性的运动，这其实是归功于运动模糊的 效果。24fps是电影胶圈通常使用的帧率，因为这个帧率已经足够支撑大部分电影画面需要表达的内容，同时能够最大的减少费用支出。但是低于30fps是 无法顺畅表现绚丽的画面内容的，此时就需要用到60fps来达到想要的效果，当然超过60fps是没有必要的（据说Dart能够带来120fps的体验）。
有了对Android渲染机制基本的认识以后，那么我们的卡顿的原因就在于没有办法在16ms内完成该完成的操作，而主要因素是在于没有必要的layouts、invalidations、Overdraw。渲染的过程是由CPU与GPU协作完成.
  通过Hierarchy Viewer去检测渲染效率，去除不必要的嵌套
  通过Show GPU Overdraw去检测Overdraw，最终可以通过移除不必要的背景以及使用canvas.clipRect解决大多数问题。
Overdraw 的处理方案一：移除不必要的background
Overdraw 的处理方案二：clipRect的妙用

publicclassCardViewextendsView{

private Bitmap[] mCards = new Bitmap[3];

privateint[] mImgId = newint[]{R.drawable.alex, R.drawable.chris, R.drawable.claire};

 publicCardView(Context context) { 

super(context); Bitmap bm = null;for (int i = 0; i < mCards.length; i++) 

{ bm = BitmapFactory.decodeResource(getResources(), mImgId[i]); 

mCards[i] = Bitmap.createScaledBitmap(bm,400,600,false); } setBackgroundColor(0xff00ff00); }  

@Override

protectedvoidonDraw(Canvas canvas) {

 super.onDraw(canvas); canvas.save(); canvas.translate(20,120);

for (Bitmap bitmap : mCards) { canvas.translate(120,0); canvas.drawBitmap(bitmap, 0,0,null); } canvas.restore(); }

}

  减少不必要的层次：巧用Hierarchy Viewer

优化： http://www.2cto.com/kf/201411/348847.html
Android的官方文档中，有这么一句话：出于安全考虑，Hierarchy Viewer只能连接Android开发版手机或是模拟器