iosandroid圖片

㈠ 安卓照片怎麼傳到蘋果手機

安卓照片傳到蘋果手機的方法。步驟如下。

如果您對將照片從Android傳輸到iPhone應選擇哪種方法感到困惑，那麼請比較所選方法的質量和速度。符合所有這些標準的工具是dr.fone工具包，它是一個全面的解決方案，專門用於解決所有與移動相關的問題和任務。

步驟1，下載並安裝dr.fone - 切換並啟動它。然後從主界面中選擇「切換」選項。

㈡ 如何優雅地在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，具體細節請看源碼