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是什麼東西怎麼使用
做程序用的。