原文链接：https://blog.csdn.net/xiangzhihong8/java/article/details/96280254
6、屏幕适配
6.1、基本概念 屏幕尺寸 含义：手机对角线的物理尺寸 单位：英寸（inch），1英寸=2.54cm
Android手机常见的尺寸有5寸、5.5寸、6寸，6.5寸等等 ** 屏幕分辨率** 含义：手机在横向、纵向上的像素点数总和
一般描述成屏幕的”宽x高”=AxB 含义：屏幕在横向方向（宽度）上有A个像素点，在纵向方向
（高）有B个像素点 例子：1080x1920，即宽度方向上有1080个像素点，在高度方向上有1920个像素点
单位：px（pixel），1px=1像素点
UI设计师的设计图会以px作为统一的计量单位
Android手机常见的分辨率：320x480、480x800、720x1280、1080x1920
屏幕像素密度 含义：每英寸的像素点数 单位：dpi（dots per ich）
假设设备内每英寸有160个像素，那么该设备的屏幕像素密度=160dpi
6.2、适配方法 1.支持各种屏幕尺寸： 使用wrap_content, match_parent, weight.要确保布局的灵活性并适应各种尺寸的屏幕，应使用 “wrap_content”、“match_parent” 控制某些视图组件的宽度和高度。
2.使用相对布局，禁用绝对布局。
3.使用LinearLayout的weight属性
假如我们的宽度不是0dp(wrap_content和0dp的效果相同)，则是match_parent呢？
android:layout_weight的真实含义是:如果View设置了该属性并且有效，那么该 View的宽度等于原有宽度(android:layout_width)加上剩余空间的占比。
从这个角度我们来解释一下上面的现象。在上面的代码中，我们设置每个Button的宽度都是match_parent，假设屏幕宽度为L，那么每个Button的宽度也应该都为L，剩余宽度就等于L-（L+L）= -L。
Button1的weight=1，剩余宽度占比为1/(1+2)= 1/3，所以最终宽度为L+1/3*(-L)=2/3L，Button2的计算类似，最终宽度为L+2/3(-L)=1/3L。
4.使用.9图片
6.3、今日头条屏幕适配 参考链接：今日头条屏幕适配方案终极版
7、性能优化 参考链接：Android 性能监测工具，优化内存、卡顿、耗电、APK大小的方法 Android的性能优化，主要是从以下几个方面进行优化的： 稳定（内存溢出、崩溃） 流畅（卡顿） 耗损（耗电、流量） 安装包（APK瘦身） 影响稳定性的原因很多，比如内存使用不合理、代码异常场景考虑不周全、代码逻辑不合理等，都会对应用的稳定性造成影响。其中最常见的两个场景是：Crash 和 ANR，这两个错误将会使得程序无法使用。所以做好Crash全局监控，处理闪退同时把崩溃信息、异常信息收集记录起来，以便后续分析;合理使用主线程处理业务，不要在主线程中做耗时操作，防止ANR程序无响应发生。 ** （一）稳定——内存优化 （1）Memory Monitor 工具：** 它是Android Studio自带的一个内存监视工具，它可以很好地帮助我们进行内存实时分析。通过点击Android Studio右下角的Memory Monitor标签，打开工具可以看见较浅蓝色代表free的内存，而深色的部分代表使用的内存从内存变换的走势图变换，可以判断关于内存的使用状态，例如当内存持续增高时，可能发生内存泄漏；当内存突然减少时，可能发生GC等，如下图所示。
LeakCanary工具： LeakCanary是Square公司基于MAT开发的一款监控Android内存泄漏的开源框架。其工作的原理是： 监测机制利用了Java的WeakReference和ReferenceQueue，通过将Activity包装到WeakReference中，被WeakReference包装过的Activity对象如果被回收，该WeakReference引用会被放到ReferenceQueue中，通过监测ReferenceQueue里面的内容就能检查到Activity是否能够被回收（在ReferenceQueue中说明可以被回收，不存在泄漏；否则，可能存在泄漏，LeakCanary是执行一遍GC，若还未在ReferenceQueue中，就会认定为泄漏）。
如果Activity被认定为泄露了，就抓取内存dump文件(Debug.dumpHprofData)；之后通过HeapAnalyzerService.runAnalysis进行分析内存文件分析；接着通过HeapAnalyzer (checkForLeak—findLeakingReference—findLeakTrace)来进行内存泄漏分析。最后通过DisplayLeakService进行内存泄漏的展示。
（3）Android Lint 工具： Android Lint Tool 是Android Sutido种集成的一个Android代码提示工具，它可以给你布局、代码提供非常强大的帮助。硬编码会提示以级别警告，例如：在布局文件中写了三层冗余的LinearLayout布局、直接在TextView中写要显示的文字、字体大小使用dp而不是sp为单位，就会在编辑器右边看到提示。
（二）流畅——卡顿优化 卡顿的场景通常是发生在用户交互体验最直接的方面。影响卡顿的两大因素，分别是界面绘制和数据处理。
界面绘制：主要原因是绘制的层级深、页面复杂、刷新不合理，由于这些原因导致卡顿的场景更多出现在 UI 和启动后的初始界面以及跳转到页面的绘制上。
数据处理：导致这种卡顿场景的原因是数据处理量太大，一般分为三种情况，一是数据在处理 UI 线程，二是数据处理占用 CPU 高，导致主线程拿不到时间片，三是内存增加导致 GC 频繁，从而引起卡顿。
（1）布局优化 在Android种系统对View进行测量、布局和绘制时，都是通过对View数的遍历来进行操作的。如果一个View数的高度太高就会严重影响测量、布局和绘制的速度。Google也在其API文档中建议View高度不宜哦过10层。现在版本种Google使用RelativeLayout替代LineraLayout作为默认根布局，目的就是降低LineraLayout嵌套产生布局树的高度，从而提高UI渲染的效率。
布局复用，使用标签重用layout； 提高显示速度，使用延迟View加载； 减少层级，使用标签替换父级布局； 注意使用wrap_content，会增加measure计算成本； 删除控件中无用属性；
（2）绘制优化 过度绘制是指在屏幕上的某个像素在同一帧的时间内被绘制了多次。在多层次重叠的 UI 结构中，如果不可见的 UI 也在做绘制的操作，就会导致某些像素区域被绘制了多次，从而浪费了多余的 CPU 以及 GPU 资源。如何避免过度绘制？
布局上的优化。移除 XML 中非必须的背景，移除 Window 默认的背景、按需显示占位背景图片
自定义View优化。使用 canvas.clipRect() 帮助系统识别那些可见的区域，只有在这个区域内才会被绘制。
（3）启动优化 应用一般都有闪屏页SplashActivity，优化闪屏页的 UI 布局，可以通过 Profile GPU Rendering 检测丢帧情况。
（三）节省——耗电优化 在 Android5.0 以前，关于应用电量消耗的测试即麻烦又不准确，而5.0 之后Google专门引入了一个获取设备上电量消耗信息的API—— Battery Historian。Battery Historian 是一款由 Google 提供的 Android 系统电量分析工具，直观地展示出手机的电量消耗过程，通过输入电量分析文件，显示消耗情况。
最后提供一些可供参考耗电优化的方法：
（1）计算优化。算法、for循环优化、Switch…case替代if…else、避开浮点运算。 浮点运算：计算机里整数和小数形式就是按普通格式进行存储，例如1024、3.1415926等等，这个没什么特点，但是这样的数精度不高，表达也不够全面，为了能够有一种数的通用表示法，就发明了浮点数。浮点数的表示形式有点像科学计数法（.×10***），它的表示形式是0.×10，在计算机中的形式为 . e ±），其中前面的星号代表定点小数，也就是整数部分为0的纯小数，后面的指数部分是定点整数。利用这样的形式就能表示出任意一个整数和小数，例如1024就能表示成0.1024×10^4，也就是 .1024e+004，3.1415926就能表示成0.31415926×10^1，也就是 .31415926e+001，这就是浮点数。浮点数进行的运算就是浮点运算。浮点运算比常规运算更复杂，因此计算机进行浮点运算速度要比进行常规运算慢得多。
（2）避免 Wake Lock 使用不当。 Wake Lock是一种锁的机制，主要是相对系统的休眠而言的，,只要有人拿着这个锁，系统就无法进入休眠意思就是我的程序给CPU加了这个锁那系统就不会休眠了，这样做的目的是为了全力配合我们程序的运行。有的情况如果不这么做就会出现一些问题，比如微信等及时通讯的心跳包会在熄屏不久后停止网络访问等问题。所以微信里面是有大量使用到了Wake_Lock锁。系统为了节省电量，CPU在没有任务忙的时候就会自动进入休眠。有任务需要唤醒CPU高效执行的时候，就会给CPU加Wake_Lock锁。大家经常犯的错误，我们很容易去唤醒CPU来工作，但是很容易忘记释放Wake_Lock。
（3）使用 Job Scheduler 管理后台任务。 在Android 5.0 API 21 中，google提供了一个叫做JobScheduler API的组件，来处理当某个时间点或者当满足某个特定的条件时执行一个任务的场景，例如当用户在夜间休息时或设备接通电源适配器连接WiFi启动下载更新的任务。这样可以在减少资源消耗的同时提升应用的效率。
（四）安装包——APK瘦身 （1）安装包的组成结构 assets文件夹。存放一些配置文件、资源文件，assets不会自动生成对应的 ID，而是通过 AssetManager 类的接口获取。
res。res 是 resource 的缩写，这个目录存放资源文件，会自动生成对应的 ID 并映射到 .R 文件中，访问直接使用资源 ID。
META-INF。保存应用的签名信息，签名信息可以验证 APK 文件的完整性。
AndroidManifest.xml。这个文件用来描述 Android 应用的配置信息，一些组件的注册信息、可使用权限等。
classes.dex。Dalvik 字节码程序，让 Dalvik 虚拟机可执行，一般情况下，Android 应用在打包时通过 Android SDK 中的 dx 工具将 Java 字节码转换为 Dalvik 字节码。
resources.arsc。记录着资源文件和资源 ID 之间的映射关系，用来根据资源 ID 寻找资源。
（2）减少安装包大小 代码混淆。使用IDE 自带的 proGuard 代码混淆器工具 ，它包括压缩、优化、混淆等功能。 资源优化。比如使用 Android Lint 删除冗余资源，资源文件最少化等。 图片优化。比如利用 PNG优化工具 对图片做压缩处理。推荐目前最先进的压缩工具Googlek开源库zopfli。如果应用在0版本以上，推荐使用 WebP图片格式。 避免重复或无用功能的第三方库。例如，百度地图接入基础地图即可、讯飞语音无需接入离线、图片库Glide\Picasso等。 插件化开发。比如功能模块放在服务器上，按需下载，可以减少安装包大小。 可以使用微信开源资源文件混淆工具——AndResGuard。一般可以压缩apk的1M左右大。
7.1、冷启动与热启动 参考链接：https://www.jianshu.com/p/03c0fd3fc245
冷启动 在启动应用时，系统中没有该应用的进程，这时系统会创建一个新的进程分配给该应用；
热启动 在启动应用时，系统中已有该应用的进程（例：按back键、home键，应用虽然会退出，但是该应用的进程还是保留在后台）；
区别 冷启动：系统没有该应用的进程，需要创建一个新的进程分配给应用，所以会先创建和初始化Application类，再创建和初始化MainActivity类（包括一系列的测量、布局、绘制），最后显示在界面上。 热启动： 从已有的进程中来启动，不会创建和初始化Application类，直接创建和初始化MainActivity类（包括一系列的测量、布局、绘制），最后显示在界面上。
冷启动流程 Zygote进程中fork创建出一个新的进程； 创建和初始化Application类、创建MainActivity； inflate布局、当onCreate/onStart/onResume方法都走完； contentView的measure/layout/draw显示在界面上。
冷启动优化 减少在Application和第一个Activity的onCreate()方法的工作量； 不要让Application参与业务的操作； 不要在Application进行耗时操作； 不要以静态变量的方式在Application中保存数据； 减少布局的复杂性和深度；
8、MVP模式架构 8.1、MVP模式 MVP架构由MVC发展而来。在MVP中，M代表Model，V代表View，P代表Presenter。
模型层（Model）:主要是获取数据功能，业务逻辑和实体模型。
视图层（View）：对应于Activity或Fragment，负责视图的部分展示和业务逻辑用户交互
控制层（Presenter）:负责完成View层与Model层间的交互，通过P层来获取M层中数据后返回给V层，使得V层与M层间没有耦合。
在MVP中 ，Presenter层完全将View层和Model层进行了分离，把主要程序逻辑放在Presenter层实现，Presenter与具体的View层（Activity）是没有直接的关联，是通过定义接口来进行交互的，从而使得当View层（Activity）发生改变时，Persenter依然可以保持不变。View层接口类只应该只有set/get方法，及一些界面显示内容和用户输入，除此之外不应该有多余的内容。绝不允许View层直接访问Model层，这是与MVC最大区别之处，也是MVP核心优点。
9、虚拟机 9.1、Android Dalvik虚拟机和ART虚拟机对比 Dalvik Android4.4及以前使用的都是Dalvik虚拟机，我们知道Apk在打包的过程中会先将java等源码通过javac编译成.class文件，但是我们的Dalvik虚拟机只会执行.dex文件，这个时候dx会将.class文件转换成Dalvik虚拟机执行的.dex文件。Dalvik虚拟机在启动的时候会先将.dex文件转换成快速运行的机器码，又因为65535这个问题，导致我们在应用冷启动的时候有一个合包的过程，最后导致的一个结果就是我们的app启动慢，这就是Dalvik虚拟机的JIT特性（Just In Time）。
ART ART虚拟机是在Android5.0才开始使用的Android虚拟机，ART虚拟机必须要兼容Dalvik虚拟机的特性，但是ART有一个很好的特性AOT（ahead of time），这个特性就是我们在安装APK的时候就将dex直接处理成可直接供ART虚拟机使用的机器码，ART虚拟机将.dex文件转换成可直接运行的.oat文件，ART虚拟机天生支持多dex，所以也不会有一个合包的过程，所以ART虚拟机会很大的提升APP冷启动速度。
ART优点：
加快APP冷启动速度
提升GC速度
提供功能全面的Debug特性
ART缺点：
APP安装速度慢，因为在APK安装的时候要生成可运行.oat文件
APK占用空间大，因为在APK安装的时候要生成可运行.oat文件
arm处理器
关于ART更详细的介绍，可以参考Android ART详解
总结 熟悉Android性能分析工具、UI卡顿、APP启动、包瘦身和内存性能优化
熟悉Android APP架构设计，模块化、组件化、插件化开发
熟练掌握Java、设计模式、网络、多线程技术
免费获取Android进阶资料点击下方链接
https://shimo.im/docs/tXXKHgdjPYj6WT8d/
