① android加速度感測器去除重力影響
gravity初值可以是0，其實無所謂，不用太離譜，一個常數都行，通過多次迭代都會穩定到實際的重力值附近。這個循環的迭代，實際上是一個一階低通濾波，0.8應該是官方推薦的參數，但應該根據實際的需求可以適當調整，或者自己設計低通濾波。這里的低通濾波是這樣的，因為重力一直穩定不變，頻率很低，而其他方向的加速度不斷變化，頻率較高，所以用低通濾波可以將重力消減，但也不是絕對的去掉。
② androidUI卡頓原理分析及Vsync信號機制
一、UI卡頓定義
1、用戶角度：app操作界面刷新緩慢，響應不及時；界面滑動不夠流暢；
2、系統角度：屏幕刷新幀率不穩定，掉幀嚴重，無法保證每秒60幀，導致屏幕畫面撕裂；
二、UI卡頓常見原因分析以及處理方案
1、過度繪制：
原因：界面布局設計不合理或者過於復雜導致系統無法在16毫秒內完成渲染，view過度繪制導致CPU或者GPU負載過重，View頻繁觸發measure、layout操作，導致measure、layout累計耗時嚴重以及整個View錯誤的頻繁重新渲染；
方案：優化界面布局，使界面布局視圖扁平化，去除不必要的背景顏色，減少透明色的使用；
方案依據原理：盡量減少View在系統中measure、layout、draw的累計時間；
2、UI線程的復雜運算
原因：UI主線程運算耗時
方案：減少UI線程中數據運算，使用子線程處理耗時任務
3、頻繁GC
原因：（1）、內存抖動；（2）、瞬間產生大量對象，消耗內存；
方案：盡量避免在循環邏輯或者onDraw方法中頻繁創建新對象和使用局部變數；
三、android Vsync機制
1、什麼是Vsync ?
Vsync 是Vertical Synchronization(垂直同步)的縮寫，是一種在PC上很早就廣泛使用的技術，可以簡單的把它認為是一種定時中斷。而在Android 4.1(JB)中已經開始引入VSync機制，用來同步渲染，讓AppUI和SurfaceFlinger可以按硬體產生的VSync節奏進行工作。
2、Android屏幕刷新過程
Android系統每隔16ms發出VSYNC信號，觸發對UI進行渲染，屏幕的刷新過程是每一行從左到右（行刷新，水平刷新，Horizontal Scanning），從上到下（屏幕刷新，垂直刷新，Vertical Scanning）。當整個屏幕刷新完畢，即一個垂直刷新周期完成，會有短暫的空白期，此時發出 VSync 信號。所以，VSync 中的 V 指的是垂直刷新中的垂直-Vertical。
3、沒有使用Vsync的情況
可見vsync信號沒有提醒CPU/GPU工作的情況下，在第一個16ms之內，一切正常。然而在第二個16ms之內，幾乎是在時間段的最後CPU才計算出了數據，交給了Graphics Driver,導致GPU也是在第二段的末尾時間才進行了繪制，整個動作延後到了第三段內。從而影響了下一個畫面的繪制。這時會出現Jank（閃爍，可以理解為卡頓或者停頓）。這時候CPU和GPU可能被其他操作佔用了，這就是卡頓出現的原因；
4、使用Vsync同步
CPU/GPU接收vsync信號，Vsync每16ms一次，那麼在每次發出Vsync命令時，CPU都會進行刷新的操作。也就是在每個16ms的第一時間，CPU就會響應Vsync的命令，來進行數據刷新的動作。CPU和GPU的刷新時間，和Display的FPS是一致的。因為只有到發出Vsync命令的時候，CPU和GPU才會進行刷新或顯示的動作。CPU/GPU接收vsync信號提前准備下一幀要顯示的內容，所以能夠及時准備好每一幀的數據，保證畫面的流暢；
5、多級緩沖
Android除了使用Vsync機制，還使用了多級緩沖的策略來優化屏幕顯示，如雙重緩沖（A + B），當Display buffer A 數據時，CPU/GPU就已經在buffer B 中處理下一幀要顯示的數據了。
可是，當系統資源緊張性能降低時，導致GPU在處理某幀數據時太耗時，在Vsync信號到來時，buffer B的數據還沒准備好，此時不得不顯示buffer A的數據，這樣導致後面CPU/GPU沒有新的buffer准備數據，空白時間無事可做，後面Jank頻出
因此採用三級緩沖來解決系統對性能不穩定導致的卡頓
當出現上面所述情況後，新增一個buffer C 可以減少CPU和GPU在Vsync同步間的空白間隙，此時CPU/GPU能夠利用buffer C 繼續工作，後面buffer A 和 buffer B 依次處理下一幀數據。這樣僅是產生了一個Jank，可以忽略不計，以後的流程就順暢了。
註：在多數正常情況下還是使用二級緩沖機制，三級緩沖只是在需要的時候才使用；
③ 如何優雅地在Android上實現iOS的圖片預覽
原文博客鏈接
用過 iOS 的都知道，擬物理的回彈效果在上面非常普遍，因為這是 iOS 系統支持的一套 UI 框架，但是 Android 就沒有了，就拿圖片查看器來講，iOS 的效果就是感覺一張圖片被綁定在了彈簧裝置上，滑動很自然，Android 沒有自帶的圖片查看器，需要自己實現
市面上主流的圖片查看器都沒有回彈的效果，一部分原因是沒有這個需求，還有一部分是實現麻煩，這里講述一個個人認為最好的方案
一個圖片查看器，要求可以滑動 Fling，觸碰到邊界的時候回彈，有越界回彈的效果，支持雙指縮放，雙擊縮放
咋一看需求，應該好寫，滾動的時候用 Scroller 來解決，回彈效果直接用 ValueAnimator ，設置插值器為減速插值器來解決。看似簡單，但是因為是仿物理效果，中間牽扯到從滾動到回彈的時候（ Scroller 動畫切換到 ValueAnimator 動畫）的速度銜接問題，要看上去從滾動到開始回彈至結束沒有突兀，中間的特判邊界處理是很麻煩的，還要牽扯到縮放，所以不考慮這種方案
既然是要模擬現實中的物理效果，為何不在每一幀根據當前的狀態得到對用的加速度，然後去計算下一幀的狀態位置，這樣只要模擬現實中的物理加速度不就可以實現了嗎，那些邊界特判之類的就可以去見閻王了
方案確定完畢，接下來就是選定加速度的方程，要模擬彈簧的效果，拉力很簡單，用胡克定律嘛！ F = k * dx ，摩擦力呢？ Ff = μ*FN ? 這里推薦一個更加好的方案，借鑒自 Rebound 庫，這是 Facebook 的一個彈簧動畫庫，設定一個目的數值，它會根據當前的拉力，摩擦力，速度然後變化到目標值，加速度方程為
其中 tension 為彈性系數， friction 為摩擦力系數，為什麼讓摩擦力和速度成正比呢？如果摩擦力和速度成正比，那麼就不存在靜摩擦力，也就是不存在物體靜止情況下拉力小於摩擦力的情況（因為速度為0的時候，阻力為0，除非拉力為0），物體肯定會向目標地點靠近，遏制了物體摩擦力過大而無法達到目的地情況
為了方便接入各種 View ，設計一個 ZoomableGestureHelper 類
設計目的，我只需要知道視圖的大小邊界 (bounds) 和內部可滾動回彈的邊界 (innerBounds)，就可以通過計算得到一個新的轉換矩陣
對於物理狀態，需要一個類 SpringPhysicsState 來做存儲，裡麵包含了速度、拉力系數、摩擦力系數，不保存位置，因為位置是通過 getBounds 動態計算得到的
速度分解成水平方向和垂直方向，因為處理方法一樣，下面只講述垂直方向的計算
狀態1 ：其中一邊有越界
分析一下上圖中的位置，藍色部分為內部圖片，它被拖動越界了，此時的合力應該為 tension * dx - friction * v , v 為圖片在 y 軸方向上的速度，（ dx 和 v 都是矢量，我暫且設置向右和向下為正），之後就直接調用 invalidate(); ，就可以播放動畫了。
狀態2：兩邊都沒越界
此時因為兩邊都沒有越界，所以應該不存在拉力，可以認為此時 dx 為0，摩擦力需要注意下，因為可以支持滑動（ Fling ），所以此時的摩擦力要比之前越界回彈時候的摩擦力小，至於具體數值，文末會給出
狀態3：兩邊都超出
此時兩邊都超出邊界，藍色區域應該和紅色區域中心綁定，所以此時的 dx 為 dxBottom - dxTop （注意符號，因為 dx 為矢量，所以不能是 dxTop - dxBottom ）
縮放的方法和移動一致，設定 tension 和 friction ，邊界設定為外面紅色的框框，藍色區域無法某一邊充滿紅色區域的時候，有拉力，否則沒拉力，摩擦力一直存在，至於雙擊放大和放小，只需要在雙擊的時候給縮放狀態設置一個初速度，然後 invalidate(); ，搞定！是不是很簡單啊
時間這一個參數在計算中是非常重要的，這關繫到當前微分狀態的數值變化，假如用歐拉方法模擬速度和位置的變化， x' = x + v * dt ， v' = v + a * dt ，公式可以看出時間決定了動畫的快慢，為了接近現實物理時間，這里採用的時間單位為秒（計算機中常用的是毫秒）
確定了單位，還需要控制一下時間間隔的數值范圍，我們不能讓兩次 computeScroll 的時間間隔過於短或者過於長，這里採用的策略為固定每次計算時候的時間間隔，如果兩次 computeScroll 的時間間隔小於此時間間隔，那麼保存累計時間間隔，等待下一次 computeScroll ，直到大於等於固定的時間間隔，再用 while 循環一步一步的計算
結束判定是唯一的一個坑，因為計算機只是在 dt 時間內模擬速度和位移的變化，不是通過微積分計算的，存在誤差，比如歐拉方法 x' = x + v * dt 和 v' = v + a * dt 計算得到的 x' 和 v' 都是近似數值，把 dt 這段時間內的變化看成了勻變速運動
所以結束判定還需要設置一個閾值，當速度和偏移量小於此數值的時候，可以認定為達到了目的地
對於 ViewPager 的適配有些問題，如果在 Down 的時候 requestDisallow true 移動過程中到了左右邊界又 requestDisallow false ，此時 ViewPager 會有一個突變（ 突變可恥但有用 ），而且多指頭的時候可能會崩潰，這是 ViewPager 的 Bug，具體細節請看源碼
④ Android控制項RecyclerView和ListView的異同
Android是一個不斷進化的平台，Android
5.0的v7版本支持包中引入了新的RecyclerView控制項，正如官方文檔所言，RecyclerView是ListView的豪華增強版。它主要
包含以下幾處新的特性，如ViewHolder，ItemDecorator，LayoutManager，SmothScroller以及增加或刪除
item時item動畫等。官方推薦我們採用RecyclerView來取代ListView。
ViewHolder
ViewHolder是用來保存視圖引用的類，無論是ListView亦或是RecyclerView。只不過在ListView
中，ViewHolder需要自己來定義，且這只是一種推薦的使用方式，不使用當然也可以，這不是必須的。只不過不使用ViewHolder的
話，ListView每次getView的時候都會調用findViewById(int)，這將導致ListView性能展示遲緩。而在
RecyclerView中使用 RecyclerView.ViewHolder 則變成了必須，盡管實現起來稍顯復雜，但它卻解決了ListView面臨的上述不使用自定義ViewHolder時所面臨的問題。 RecyclerView.ViewHolder 被BaseAdapter使用，以將posiiton綁定到上面(可以通過API查看 RecyclerView.ViewHolder#getPosition() 方法)。
LayoutManager
我們知道ListView只能在垂直方向上滾動，Android
API沒有提供ListView在水平方向上面滾動的支持。或許有多種方式實現水平滑動，但是請想念我，ListView並不是設計來做這件事情的。但是
RecyclerView相較於ListView，在滾動上面的功能擴展了許多。它可以支持多種類型列表的展示要求，主要如下：
LinearLayoutManager ，可以支持水平和豎直方向上滾動的列表。
StaggeredGridLayoutManager ，可以支持交叉網格風格的列表，類似於瀑布流或者Pinterest。
GridLayoutManager ，支持網格展示，可以水平或者豎直滾動，如展示圖片的畫廊。
ItemAnimator
列表動畫是一個全新的、擁有無限可能的維度。起初的Android API中，刪除或添加item時，item是無法產生動畫效果的。後面隨著Android的進化，Google的Chat Hasse推薦使用 ViewPropertyAnimator 屬性動畫來實現上述需求。
相比較於ListView， RecyclerView.ItemAnimator 則被提供用於在RecyclerView添加、刪除或移動item時處理動畫效果。同時，如果你比較懶，不想自定義ItemAnimator，你還可以使用 DefaultItemAnimator 。
Adapter
ListView的Adapter中，getView是最重要的方法，它將視圖跟position綁定起來，是所有神奇的事情發生的地方。同時我們也能夠
通過registerDataObserver在Adapter中注冊一個觀察者。RecyclerView也有這個特性， RecyclerView.AdapterDataObserver
就是這個觀察者。ListView有三個Adapter的默認實現，分別是ArrayAdapter、CursorAdapter和
SimpleCursorAdapter。然而，RecyclerView的Adapter則擁有除了內置的內DB游標和ArrayList的支持之外的
所有功能。 RecyclerView.Adapter 的實現的，我們必須採取措施將數據提供給Adapter，正如BaseAdapter對ListView所做的那樣。
ItemDecoration
在ListView中如果我們想要在item之間添加間隔符，我們只需要在布局文件中對ListView添加如下屬性即可：
1 android:divider="@android:color/transparent"
2 android:dividerHeight="5dp"
View Code
有趣的是，RecyclerView在默認情況下並不在item之間展示間隔符。盡管Google的傢伙有意地將這個問題遺留給我們去自定義間隔符，但這
的確增加了開發人員的負擔。如果你想要添加間隔符，你必須使用RecyclerView.ItemDecoration類來實現。或者，你可以應用官方示
例中的 DividerItemDecoration.java 文件。
OnItemTouchListener
ListView通過AdapterView.OnItemClickListener介面來探測點擊事件。而RecyclerView則通過
RecyclerView.OnItemTouchListener介面來探測觸摸事件。它雖然增加了實現的難度，但是卻給予開發人員攔截觸摸事件更多的
控制許可權。
Others
ListView可以設置選擇模式，並添加MultiChoiceModeListener，如下所示：
1 listView.setChoiceMode(ListView.CHOICE_MODE_MULTIPLE_MODAL);
2 listView.setMultiChoiceModeListener(new MultiChoiceModeListener() {
3 public boolean onCreateActionMode(ActionMode mode, Menu menu) { ... }
4 public void onItemCheckedStateChanged(ActionMode mode, int position,
5 long id, boolean checked) { ... }
6 public boolean onActionItemClicked(ActionMode mode, MenuItem item) {
7 switch (item.getItemId()) {
8 case R.id.menu_item_delete_crime:
9 CrimeAdapter adapter = (CrimeAdapter)getListAdapter();
10 CrimeLab crimeLab = CrimeLab.get(getActivity());
11 for (int i = adapter.getCount() - 1; i >= 0; i--) {
12 if (getListView().isItemChecked(i)) {
13 crimeLab.deleteCrime(adapter.getItem(i));
14 }
15 }
16 mode.finish();
17 adapter.notifyDataSetChanged();
18 return true;
19 default:
20 return false;
21 }
22 public boolean onPrepareActionMode(ActionMode mode, Menu menu) { ... }
23 public void onDestroyActionMode(ActionMode mode) { ... }
24 });
View Code
而RecyclerView則沒有此功能。
總之，通過比較我們可以發現，RecyclerView充滿了大量的自定義功能，它可以用於實現復雜的列表或網格，但實現起來稍顯得復雜。