A. android 系统原生 API 实现分享功能
GitHub 项目地址：LocalShare-master
直接上图，这是一个典型的调用系统原生分享场景下的界面，相信大家应该都很熟悉。
那下面说一下遇到的一些问题，特别针对是 7.0 以后的系统，以及兼容一些主流 app 时遇到的坑。
前面说到分享文件时需要知道文件的类型，不然的指定类型为 / ，这样分享到某些 App 会因为无法判断文件类型而导致失败，所以最好先根据文件路径获取其文件类型。
使用这种方法获取文件类型，一定要注意 ContentResolver 获取返回为 null 的情况，不然空指针异常的崩溃率可能会让你笑不出来。实际测试中，发现在某些国产机型下，这个方法可以说直接是不可用，查询返回一直都是空，所以单纯依赖这一个方法会很不可靠。具体问题原因请看： What causes Android's ContentResolver.query() to return null?
下面按照第二条思路，按照文件头信息简单实现一个获取文件类型的例子：
// 获取文件Uri
要向在 MediaStore 中查询到文件，要不就是通知媒体库更新查询或则往里面插入一条新记录（会比较耗时）
可以参考我的另外一篇文章： Android 系统原生 API 实现分享功能（2）
参考： https://www.jianshu.com/p/1d4bd2c5ef69
B. android的sdk和api是什么意思
SDK就是Kit，工具箱嘛，IOS平台上就是XCode，一系列的工具组合在一起，比如你在编辑器里敲代码的时候它会自动补全代码，自动错误检查，你点一下Run，它会调用编译器来自动编译，编译完它会调用iPhone的模拟器来运行，这就是SDK，提供整套的开发工具供开发者使用。
OpenAPI就是网站提供的接口，比如你想开发一个围脖的手机客户端，你从哪里读取数据写入数据呢？总不能从Web版里调用吧？那里是一堆一堆的html代码啊，所以OpenAPI就是网站提供的接口，供开发者接入用的，比如聚合数据平台。
SDK (Software Development Kit)翻译成中文就是"软体开发工具组"
是用来帮一个 产品 或 平台 开发应用程式的工具组，由产品的厂商提供给开发者使用的。
通常是 某一家厂商 针对某一 平台 或 系统 或 硬体 所发布出来用以开发应用程式的工具组，
在这个工具包里面，可能包含了各式各样的开发工具，模拟器等。
例如：给 Android平台 使用的 Android SDK 就是用来开发 Android系统上面的应用程式。
API (Application Programming Interface)
翻译成中文就是"应用程式接口"，其实这样翻译不好，应该说是"程式沟通接口"。
翻译为接口，顾名思义就要沟通两个不同的东西用的，通常由一组函式库所组成。
在一个 同一个平台 下的 两个不同东西(程式 or 系统)，为了能取用对方的功能等等，
所以一个 X程式 写了一组函式，让 同一平台的其他程式 取用 X程式 的功能，
那组函式就可以说是那个 X程式 对外开放的 API。
例如：我要在 自己的网页 上加入 google map网页的功能，就使用 "google map API"
有时候 SDK(开发者工具包) 里也会带有些许 API 用来调用一些系统平台程式提供的功能
例如说：视窗显示，图形特效等等。
以下举一个实际例子来说明，调用系统程式功能的API 是怎麽一回事
开发Windows应用程式的SDK(开发者工具包) 里就包含 Win32 API
说明： Win32 API 是一个函式库，可以给Windows应用程式 调用 Windows系统的功能
在PTT看到有人问了差异性，我的看法是
SDK是用来开发某一个平台的程式的工具包，API 是让同一平台下的程式取用它的功能的函式库。
以及下面的评论
1.API 通常大家都不会弄错，的确就是以功能为导向的"方法"或"函式"清单，
看程式语言或平台而定( Methods, Functions... )，
而每个 API 主要都是为了达成某特定功能所设计的。
开发商可以为了不同平台，设计相同的 API 让开发者使用，
也可能会因应不同平台，制作不同的 API 让开发者使用。
2.当 API 数量够多功能够繁复并且可交互为用的时候，
( 例如为了达成某些功能，常需要同时引用某些 APIs 来完成 )
开发商就会为了开发便利，而预先撰写好一些组合好 APIs 的 API
供开发者使用，来统一有特定需求的开发者能有一致的开发与使用体验，
( 例如让使用"网路连线"的开发者不需自己处理网路的基础沟通信息，
与错误处理方式，使 API 在应用的时候有一定程度的便利性等 )
然后，也陆续发展出测试、除错工具，甚至是设计不同平台开发环境所需的套件，
尤其针对不同平台，更是设计了对应的工具来协助开发、除错；
SDK 名词之所以出现，俨然是为了汇整上述这些资源而诞生的，
我想也可以说成是 API 的包含者(直接使用)与应用者(以便加速开发)，
也因此可以说这两个是属于不同层级的东西...
C. Android各个版本的介绍
前言：笔者在面试的过程中，已经被问过不下三次，因此在这里分析一下。可能不够详细，请各位大佬多多包涵。
一、 版本对应的API 级别
API 级别：是对 Android 平台版本提供的框架 API 修订版进行唯一标识的整数值。
1 ，Android 4.4 API 级别是19；
2，Android 5.0 API 级别：21；
3，Android 5.1 API 级别：22；
4，Android 6.0 API 级别：23；
5，Android 7.0 API 级别：24；
6，Android 7.1 API 级别：25；
7，Android 8.0 API 级别：26；
8，Android 8.1 API 级别：27；
9，Android 9 API 级别：28；
10，Android 10 API 级别：29；
二、版本变更
注：只举一些常见的。
Android 4.4
1，文件的读写权限，长期对文件进行读写；
2，增加了webview组件；
3，打印框架，通过 WLAN、蓝牙或其他服务连接的打印机；
4，短信内容的提供，允许应用读写设备的短信和彩信；
5，NFC读取
6，沉浸式
7，透明系统状态栏
8，虚拟机的改变
Android 5.0
1，webview更新，增加了安全性和稳定性
2，录屏功能
3，camera2
4，多个网络连接
5，蓝牙低功耗
6，NFC增强
7，ART运行时取代了Dalvik成为平台默认设置
8，浮动窗口
Android 6.0
1，指纹身份认证
2，蓝牙触控笔并且改进蓝牙低功耗
3，4K显示
4，低功耗模式
5，USB连接授权与其他设备连接
6，APK验证更为严格
Android 7.0
1，增强了低功耗模式，可以监听到用户的行为
2，屏幕缩放
3，快速安装app
4，来电过滤
Android 8.0
1，自适应启动图标
2，增加了webview的安全性和稳定性
3，多显示器支持，可以一边聊天一边看视频
4，网络连接和 HTTP(S) 连接
5，蓝牙，兼容蓝牙5.0版本超过字节约60的限制
Android 9
1，WIFI RTT可以室内定位
2，DEX 文件的 ART 提前转换
Android 10
1，可折叠设备
2，5G网络
3，保护用户隐私
4，安全性
5，ART 优化
D. Android流畅度评估及卡顿优化
Google定义：界面呈现是指从应用生成帧并将其显示在屏幕上的动作。要确保用户能够流畅地与应用互动，应用呈现每帧的时间不应超过16ms，以达到每秒60帧的呈现速度（为什么是60fps？）。
如果应用存在界面呈现缓慢的问题，系统会不得不跳过一些帧，这会导致用户感觉应用不流畅，我们将这种情况称为卡顿。
来源于： Google Android的为什么是60fps？
16ms意味着1000/60hz，相当于60fps。这是因为人眼与大脑之间的协作无法感知超过60fps的画面更新。12fps大概类似手动快速翻动书籍的帧率， 这明显是可以感知到不够顺滑的。24fps使得人眼感知的是连续线性的运动，这其实是归功于运动模糊的效果。 24fps是电影胶圈通常使用的帧率，因为这个帧率已经足够支撑大部分电影画面需要表达的内容，同时能够最大的减少费用支出。 但是低于30fps是 无法顺畅表现绚丽的画面内容的，此时就需要用到60fps来达到想要的效果，超过60fps就没有必要了。如果我们的应用没有在16ms内完成屏幕刷新的全部逻辑操作，就会发生卡顿。
首先要了解Android显示1帧图像，所经历的完整过程。
如图所示，屏幕显示1帧图像需要经历5个步骤：
常见的丢帧情况： 渲染期间可能出现的情况，渲染大于16ms和小于16ms的情况：
上图中应该绘制 4 帧数据 , 但是实际上只绘制了 3 帧 , 实际帧率少了一帧
判断APP是否出现卡顿，我们从通用应用和游戏两个纬度的代表公司标准来看，即Google的Android vitals性能指标和地球第一游戏大厂腾讯的PrefDog性能指标。
以Google Vitals的卡顿描述为准，即呈现速度缓慢和帧冻结两个维度判断：
PerfDog Jank计算方法：
帧率FPS高并不能反映流畅或不卡顿。比如：FPS为50帧，前200ms渲染一帧，后800ms渲染49帧，虽然帧率50，但依然觉得非常卡顿。同时帧率FPS低，并不代表卡顿，比如无卡顿时均匀FPS为15帧。所以平均帧率FPS与卡顿无任何直接关系)
当了解卡顿的标准以及渲染原理之后，可以得出结论，只有丢帧情况才能准确判断是否卡顿。
mpsys 是一种在设备上运行并转储需要关注的系统服务状态信息的 Android 工具。通过向 mpsys 传递 gfxinfo 命令，可以提供 logcat 格式的输出，其中包含与录制阶段发生的动画帧相关的性能信息。
借助 Android 6.0（API 级别 23），该命令可将在整个进程生命周期中收集的帧数据的聚合分析输出到 logcat。例如：
这些总体统计信息可以得到期间的FPS、Jank比例、各类渲染异常数量统计。
命令 adb shell mpsys gfxinfo <PACKAGE_NAME> framestats 可提供最近120个帧中，渲染各阶段带有纳秒时间戳的帧时间信息。
关键参数说明：
通过gfxinfo输出的帧信息，通过定时reset和打印帧信息，可以得到FPS(帧数/打印间隔时间)、丢帧比例（(janky_frames / total_frames_rendered)*100 %）、是否有帧冻结(帧耗时>700ms)。
根据第2部分的通用应用卡顿标准，可以通过丢帧比例和帧冻结数量，准确判断当前场景是否卡顿。并且通过定时截图，还可以根据截图定位卡顿的具体场景。
如上图所示，利用gfxinfo开发的检查卡顿的小工具，图中参数和卡顿说明如下：
根据上面对gfxinfo的帧信息解析，可以准确计算出每一帧的耗时。从而可以开发出满足腾讯PerfDog中关于普通卡顿和严重卡顿的判断。
依赖定时截图，即可准确定位卡顿场景。如下图所示（此处以PerfDog截图示例）：
通过第3部分的卡顿评估方法，我们可以定位到卡顿场景，但是如何定位到具体卡顿原因呢。
首先了解卡顿问题定位工具，然后再了解常见的卡顿原因，即可通过复现卡顿场景的同时，用工具去定位具体卡顿问题。
重点就是，充分利用gfxinfo输出的帧信息，对卡顿问题进行分类。
了解了高效定位卡顿的方法和卡顿问题定位工具，再熟悉一下常见的卡顿原因，可以更熟练的定位和优化卡顿。
SurfaceFlinger 负责 Surface 的合成，一旦 SurfaceFlinger 主线程调用超时，就会产生掉帧。
SurfaceFlinger 主线程耗时会也会导致 hwc service 和 crtc 不能及时完成，也会阻塞应用的 binder 调用，如 dequeueBuffer、queueBuffer 等。
后台进程活动太多，会导致系统非常繁忙，cpu io memory 等资源都会被占用，这时候很容易出现卡顿问题，这也是系统这边经常会碰到的问题。
mpsys cpuinfo 可以查看一段时间内 cpu 的使用情况：
当线程为 Runnable 状态的时候，调度器如果迟迟不能对齐进行调度，那么就会产生长时间的 Runnable 线程状态，导致错过 Vsync 而产生流畅性问题。
system_server 的 AMS 锁和 WMS 锁 , 在系统异常的情况下 , 会变得非常严重 , 如下图所示 , 许多系统的关键任务都被阻塞 , 等待锁的释放 , 这时候如果有 App 发来的 Binder 请求带锁 , 那么也会进入等待状态 , 这时候 App 就会产生性能问题 ; 如果此时做 Window 动画 , 那么 system_server 的这些锁也会导致窗口动画卡顿。
Android P 修改了 Layer 的计算方法 , 把这部分放到了 SurfaceFlinger 主线程去执行, 如果后台 Layer 过多，就会导致 SurfaceFlinger 在执行 rebuildLayerStacks 的时候耗时 , 导致 SurfaceFlinger 主线程执行时间过长。
主线程执行 Input Animation Measure Layout Draw decodeBitmap 等操作超时都会导致卡顿 。
Activity resume 的时候, 与 AMS 通信要持有 AMS 锁, 这时候如果碰到后台比较繁忙的时候, 等锁操作就会比较耗时, 导致部分场景因为这个卡顿, 比如多任务手势操作。
应用里面涉及到 WebView 的时候, 如果页面比较复杂, WebView 的性能就会比较差, 从而造成卡顿。
如果屏幕帧率和系统的 fps 不相符 , 那么有可能会导致画面不是那么顺畅. 比如使用 90 Hz 的屏幕搭配 60 fps 的动画。
由上面的分析可知对象分配、垃圾回收(GC)、线程调度以及Binder调用 是Android系统中常见的卡顿原因，因此卡顿优化主要以下几种方法，更多的要结合具体的应用来进行：
在计算机和通信领域，帧是一个包括“帧同步串行”的数字数据传输单元或数字数据包。
在视频领域，电影、电视、数字视频等可视为随时间连续变换的许多张画面，其中帧是指每一张画面。
E. android6.0 sdk下载 android6.0 sdk官方下载地址
现在，谷歌也正式向开发者们放出了android6.0
SDK，其中最大的亮点就是开始支持API
Level
23，开发者们可以借此更好的利用安卓6.0的新特性，例如指纹检测与识别，节电模式等。
与此同时，android6.0也加入了更多的权限控制，确保用户隐私数据的安全。
如果你现在正在使用Android
Studio，那么直接在SDK管理器中下载即可，之后你就可以将正在进行的开发项目从“compileSdkVersion”升级到API
23，从而测试应用在安卓6.0下的表现。
最后，谷歌也宣布从今天起，Google
Play应用商店将正式接受基于API
23所开发的应用上架，届时，安卓6.0用户们也将真正感受到新系统的魅力。
绿茶软件园小编推荐阅读：
安卓6.0怎么样
android6.0概念视频欣赏
android
m新增了什么功能
android
m新增功能介绍
F. Android UI卡顿原因及解决办法
渲染机制介绍
为了分析UI卡顿，我们有必要理解一下渲染机制，这套渲染机制适用于绝大部分的屏幕渲染，其中包括Android手机等众多屏幕设备。
渲染的一些重要参数：
屏幕刷新理想的频率（硬件的角度）：60Hz
理想的一秒内绘制的帧数，帧率（屏幕刷新的角度）：60fps
这两个参数都是理想值，指代的都是同一个概念。实际情况中难免会比它们低。在60fps内，系统会得到发送的VSYNC(垂直刷新/绘制)信号去进行渲染，就会正常地绘制出我们需要的图形界面。Android手机进行绘制的时候，GPU帮助我们将UI组件等计算成纹理Texture和三维图形Polygons，同时会使用OpenGL---会将纹理和Polygons缓存在GPU内存里面。
其中，VSYNC：有两个概念
Refresh Rate：屏幕在一秒时间内刷新屏幕的次数----有硬件的参数决定，比如60HZ，即屏幕每秒刷新60次
Frame Rate：GPU在一秒内绘制操作的帧数，比如：60fps，
基本结论
要达到60fps，就要求：每一帧只能停留16ms。（大概就是1000ms/60 ~= 16ms刷新一次）
内存抖动是因为大量的对象被创建又在短时间内马上被释放。
瞬间产生大量的对象会严重占用Young Generation的内存区域，当达到阀值，剩余空间不够的时候，也会触发GC。即使每次分配的对象占用了很少的内存，但是他们叠加在一起会增加Heap的压力，从而触发更多其他类型的GC。这个操作有可能会影响到帧率，并使得用户感知到性能问题。
Android里面是一个三级Generation的内存模型，最近分配的对象会存放在Young Generation区域，当这个对象在这个区域停留的时间达到一定程度，它会被移动到Old Generation，最后到Permanent Generation区域。
Android每个16ms就会绘制一次Activity，通过上述的结论我们知道，如果由于一些原因导致了我们的逻辑、CPU耗时、GPU耗时大于16ms( 应用卡顿的根源就在于16ms内不能完成绘制渲染合成过程,16ms需要完成视图树的所有测量、布局、绘制渲染及合成 )，UI就无法完成一次绘制，那么就会造成卡顿。
比如说，在16ms内，发生了频繁的GC：
在第一个16ms内，UI正常地完成了绘制，那么屏幕不会卡顿。
在第二个16ms内，由于某些原因触发了频发的GC，UI无法在16ms内完成绘制，就会卡顿。
UI卡顿外部和内部常见原因
下面总结一些常见的UI卡顿原因：
1.内存抖动的问题
2.方法太耗时了（CPU占用）
1） CPU计算时间，CPU的测量、布局时间
2）CPU将计算好的Polygons和Texture传递到GPU的时候也需要时间。OpenGL ES API允许数据上传到GPU后可以对数据进行保存，缓存到display list。因此，我们平移等操作一个view是几乎不怎么耗时的 。
3） GPU进行格栅化
当我们的布局是用的FrameLayout的时候，我们可以把它改成merge，可以避免自己的帧布局和系统的ContentFrameLayout帧布局重叠造成重复计算(measure和layout)。
使用ViewStub：当加载的时候才会占用。不加载的时候就是隐藏的，仅仅占用位置。
CPU优化建议
针对CPU的优化，从减轻加工View对象成Polygons和Texture来下手：
View Hierarchy中包涵了太多的没有用的view，这些view根本就不会显示在屏幕上面，一旦触发测量和布局操作，就会拖累应用的性能表现。那么我们就需要利用工具进行分析。
如何找出里面没用的view呢？或者减少不必要的view嵌套。
我们利用工具：Hierarchy Viewer进行检测，优化思想是：查看自己的布局，层次是否很深以及渲染比较耗时，然后想办法能否减少层级以及优化每一个View的渲染时间。
我们打开APP，然后打开Android Device Monitor，然后切换到Hierarchy Viewer面板。除了看层次结构之外，还可以看到一些耗时的信息：
三个圆点分别代表：测量、布局、绘制三个阶段的性能表现。
1）绿色：渲染的管道阶段，这个视图的渲染速度快于至少一半的其他的视图。
2）黄色：渲染速度比较慢的50%。
3）红色：渲染速度非常慢。
GPU优化建议就是一句话：尽量避免过度绘制（overdraw）
一、背景经常容易造成过度绘制。
手机开发者选项里面找到工具：Debug GPU overdraw，其中，不同颜色代表了绘制了几次：
G. android api是什么东西怎么使用
做程序用的。