安卓基础随笔

性能和优化

一、如何对性能进行优化

个人认为性能优化主要分为两个部分
第一个部分UI视觉，第二个部分实际性能
1.UI视觉 ：
ui视觉就是肉眼可见的页面的刷新速度，比如打开一个app从空白到铺满手机屏幕的效率，或者是打开一个列表、详情页面，肉眼可见的展示速度，如果一个页面内容过多或者需要加载的数据过多，就可以考虑进行局部加载，首先铺满当前可见的一屏幕，然后在加载剩余的，其实分页加载逻辑就是一个很明显的例子。还有就是避免页面布局过于复杂，这个其实很考验UI设计的大局观，既要展示全面又不会让程序员过度绘制。
2.实际性能 ：
这个又要分为几个小点：
1).ui布局的过度嵌套，以尽可能精简的方式去绘制布局动一点脑筋
2).一些自定义的view，可能绘制过程定义了一些变量，因为draw刷新的速度会很高，在draw中创建变量不仅会严重增加内存消耗，还会导致绘制冗余过多，导致绘制的效率变慢，比如多次创建画笔。
3).还有一些比如提供的是处理数据能力的，比如说需要预加载模型的，模型加载和卸载耗时很严重，并且首次模型加载因为加载的缘故可能会更慢，为了保证能力的可用性可以以一个周期为基准，比如处理200条数据为一个周期然后进行加载和卸载模型；还有为了保证app体积的大小，可能会对模型不影响规格进行压缩bit的方式，或者说在app内模型会被压缩，这样首次解压内存就可能会耗费更长的时间，可以考虑缓存在本地，以后每次都依据本地cache的进行加载。
4).有些第三方或者耗时的东西为了图省事，会放在application中，或者在MainActivity的onCreate中都初始化，其实这样在首次打开app的时候会严重影响加载效率，体验极差，可以考虑延迟或者异步。
同时也引申了另一个问题，在加载耗时资源等时一定要区分首次加载还是切后台之后的二次加载，因为冷启动的原因，首次都会很慢，还有就是安卓生命周期做好判断，避免重复加载。
5).功耗，UI绘制特别的可以使用硬件加速绘制，但是一定要用在刀刃上，否则应用一打开手机就发烫只能被人卸载
6).时延打点用于后续分析，可能在不同的品牌手机、新旧程度、内存占用、当时使用开了多个应用情况都会导致你的应用时延的升高，时延打点可以根据异常情况进行分析整改，提升应用的能力
7).安卓前后台程序执行的速率差别极大，以相机获取流的速度来讲前台常规可能60-120ms一帧数据，在后台就可能达到几百ms一帧，一种是保护机制，一种也是安卓内存分配上造成的差异。处理复杂数据的时候就会出现严重的卡顿现象，可以考虑用C++取代原java复杂逻辑的实现，C++两个优点：1是执行速率快，可达到10+倍速；2内存占用低（当然处理内存要精细，要不然分分钟溢出给你看）

二、对于使用框架和代码架构的看法

以代码简练，框架方便好上手为基准：
其实一个新人入职到参与开发是需要一定时间的，老人可以快速定位bug，但是依然很难在原有框架上直接开发，这个成本就特别高。
以现有的框架来讲mvp、mvc、mvvm、还有一些设计模式，以公司项目体量为基准不必强求框架和设计模式，如果水平有限，你使用的所有模式都是给自己给别人挖坑，让人看的难以理解并且后续新增修改需要绞尽脑汁才能新增新的需求，你就等着被人骂吧。

代码以简洁有效有注释为基础，同一个项目大体格局不会有太多变化，可以很好地提取基类进行开发，因大同小异可以实现不同的继承来操作，有时间可以提纯自己的代码，你会发现大量冗余和细枝末节的crash。

设计模式使用的时候一定要增加文档，保障你的思维逻辑为后来者(包括自己)看的清楚理解的明白。

mvp浅述理解与操作：
对于新人来讲不必强求接口模式开发，完全的接口调用开销是一个页面要配置2N个奇奇怪怪的接口，可以简单理解为：
M—P—V ，即：
M：数据层面：只进行数据的获取
P：逻辑层面：执行V的需求，让M拿到数据并依据实际对数据进行加工回调给V，纯纯发消息和处理逻辑
V：页面展示：只做页面展示，其他的什么也不做

等做好了之后可以分别对M、P、V进行分别精炼：
M：可依据网络请求、本地数据存取等抽取，整合成基类继承或者工具类直接使用，加好中文注释
P：可以是详情页、列表页、首页展示类分为多个P基类，根据实际情况去继承，子类也可以有单独的硬逻辑，主打一个简练
V：加载布局、销毁、退出动画、标题栏、底部导航栏，都可以抽取，一个activity几十行就安排好了

还有一点，不是说你大方向搭好了MVP框架就可以随便写了，有一些获取数据或者UI处理方面也是包含了前中后这种逻辑的，要依据实际情况去拆分，不能写成一坨，举个栗子：

底部导航栏：一个应用成建制规格下，可能的功能：点赞、收藏、分享、复制、备注、移动、删除、更多。但是每一个页面可能只需要其中的几个，不能每一次都订制，这就需要一个专门的管理工具，还是以MVP为基准：

1.首先给对应功能定义action，后续以action-id提供功能、图片、文字。
2.主要是解耦，明确一个类别的作用

P：
1.针对V所属模块、类别、标志、或者就是V直接传相应的action和布局id，动态创建需要的数据链给V进行加载
2.action点击事件发送给对应的M，例如分享的M、收藏的M、点赞的M，(mvp都可以是一对多的形式，没有固定说必须要一一对应)
V：
1.提供一个布局占位展示P处理后的样式
2.提供点击时P所需要的数据
M: 如分享的M、收藏的M、点赞的M…能力保持独立
1.模块需求一对多：收藏只处理收藏、取消收藏的逻辑，但是可以给多个模块去使用，
2.多元化多对一：例如分享，可以给微信、支付宝、微博等等应用分享，他们的实现可能是大同小异的，

对于抽象出来的接口浅谈两句，接口不是为了抽出来好看，接口的主要意义是对类的约束