㈠ android webkit圖片解碼流程是什麼呢在看源碼的時候注意到再\external\webkit\WebCore\platform\image-d
不是，android中對圖片解碼是放在external裡面有個skia的第三方鄭罩粗庫。裡面封裝了它對jpg,png ,gif,bmp等圖片解碼的支持。這些圖片解碼悶旁時會用到external裡面的libjpg ,libgif,libpng等解碼庫。如果你需要支持tiff格式，也可以在里喊鎮面添加libtif 庫。同時修改skia裡面的部分代碼。如若需要具體方法，網路hi我
㈡ Android編碼解碼及其原理
本文摘抄至： chendong_ 的博客
本文用到ASCII表，Base64對照表請自行網路。
概念：編碼解碼就是使用特定的演算法轎帆，將數據進行處理，形成數據的另外一種表現形式，編碼後的數據可以使用解碼演算法還原出原始數據。
洞帆拆 Base64演算法可以將任意的位元組數組數據通過演算法生成只有（英文大小寫，數字，+，/）共64種字元的字元串數據；相當於將任意內容轉換為可見字元串表示。
也就是將不可見的數據轉換為ASCII碼數據，便於在Json和Xml中傳遞。
字元串String str = "0Aa";首先，原先每個字元是2個位元組16bit,對於英文來說前8個bit是0，也就是只有8個bit,現在是3個字元，3*8=24個bit需要顯示。
現在拼湊成是這樣的二進制串( 001100 000100 000101 100001)，將其轉化為Base64可以顯示的模式，需要每次取6位作為一個Base64字元,前兩位補0
這個例子已經很清晰的解釋了Base64的編碼過程，網上有人自己實現了Base64編碼的類，Android源碼也不難，這是編碼字元串看起來還是比較清晰的，我們也可以更本質一點
byte[] bs = new byte[]{1,10,20};這是一個byte數組，復習一下，1個byte是8個bit,可以表示的范圍 0-127之間，我們在調用Base64的函數時，本質也是在操作位元組數組，同樣的原理
Hex就是16進制，本質上是將位元組數組轉化為16進制，然後用字元串的形式表現出來，我們知道16進制的取值范圍就是在0-f之間，這樣就可以將無法顯示的位元組數組數據顯示出來。
原理方面比起Base64就簡單很多了，一個8bit的數據，也就是（xxxx xxxx）,每4個bit可以轉化為一個16進製表示，也就是8個bit會轉化為（00-ff）之間的16進制數字。
簡單說一下，&運算，兩者都為1結果才是1，b>>4&0xf取出高四位，b&0x0f取出低四位，舉個例子：
1、位元組是 b = 1010 1111
2、b>>4 b = 00001010
3、b>>4&0x0f 也就是 00001010&00001111 —-> 1010高四位取出來了，取得低四位原理一樣。後面的操作就是根據數據的大小轉換一下格式，因為拿到的數據是十進制的那麼范圍會在0-15之間，需要轉換為16進制的0-f.
相當於編納棗碼的逆運算，根據字元串每次取兩位，轉換成int，在進行移位將其拼成一個位元組，怎麼拼的？v = ((ih&0x0f)<<4)|(il&0x0f);
這一句，假設我們獲得的字元串最後轉化結果是10和5，也就是1010，0101。10<<4,結果是10100000，然後10100000 | 0101，|運算只要有1則為1，結果是10100101就完成了拼接工作。
Base64和Hex是比較常見的編碼方式，對比一下，Base64每3個位元組轉化為4個位元組，每個位元組浪費2bit,Hex編碼，每個位元組轉化為兩個位元組，每個位元組浪費4bit,所以說Base64更加節省空間，而且用起來簡單得多。
㈢ Android原生編解碼介面 MediaCodec 之——完全解析
MediaCodec 是Android 4.1(api 16)版本引入的編解碼介面， Developer 官網 上描述的已經很清楚了。可以配合 中文翻譯 一起看。理解更深刻。
MediaCodec的工作流程：
從上圖培冊可以看出 MediaCodec 架構上採用了2個緩沖區隊列，非同步處理數據，並且使用了一組輸入輸出緩存。
你請求或接收到一個空的輸入緩存（input buffer），向其中填充滿數據並將它傳遞給編解碼器處理。編解碼器處理完這些數據並將處理結果輸出至一個空的輸出緩存（output buffer）中。最終，你請求或接收到一個填充了結果數據的輸出緩存（output buffer），使用完其中的數據，並將其釋放給編解碼器再次使用。
具體工作如下：
MediaCodec的基本調用流程是：
1.初始化MediaCodec，方法有兩種，分別是通過名稱和類型來創建，對應的方法為：
2.配置編碼器，設置各種編碼器參數（MediaFormat），這個類包含了比特率、幀率、關鍵幀間隔時間等。然後再調用 mMediaCodec .configure，對於 API 19 以上的系統，我們可以選擇 Surface 輸入：mMediaCodec .createInputSurface，
3.打開編碼器，獲取輸入輸出緩沖區
獲取輸入輸出緩沖區在api19 上是以上方式獲取，api21以後 可以使用直接獲取ByteBuffer
4.輸入數據，有2種方式，一種是普通輸入，一種是Surface 輸入
普通輸入又可區分為兩種情況，一種是配合MediaExtractor ，一種是取原數據；
返回一個填充了有效數據的input buffer的索引，如果沒有可用的buffer則返回-1，參數為超時時間(TIMES_OUT)，單位是微秒，當timeoutUs==0時，該方法立即返回；當timeoutUs<0時，無限期地等待一個可用的input buffer，當timeoutUs>0時，
等待時間為傳入的微秒值。
上面輸入緩存的index，通過getInputBuffers()得到的是輸入緩存數組，通過index和輸入緩存數組可以得到當前請求的輸入緩存，在使用之前要clear一下，避免之前的緩存數據影響當前數據，接著就是把數據添加到輸入緩存中，並調用queueInputBuffer(...)把緩存數據入隊；
5.輸出數據
通常編碼傳輸時每個關鍵幀頭部都需要帶上編碼配置數據（PPS，SPS），但 MediaCodec 會在首次輸出時專門輸出編碼配置數據，後面的關鍵幀里是不攜帶這些數據的，所以需要我們手動做一個拼接；
6.使用完MediaCodec後釋放資源
要告知編碼器我們要結束編碼，Surface 輸入的話調用 mMediaCodec .signalEndOfInputStream，普通輸入則可以為在 queueInputBuffer 時指定 MediaCodec.BUFFER_FLAG_END_OF_STREAM 這個 flag；告知編碼器後我們就可以等到編碼器輸出的 buffer 帶著 MediaCodec.BUFFER_FLAG_END_OF_STREAM 這個 flag 了，等到之後我們調用 mMediaCodec .release 銷毀編碼器
流控就是流量控制。 為什麼要控制，就是為了在一定的限制條件下，收益最大化！
涉及到了 TCP 和視頻編碼：
對 TCP 來說就是控制單位時間內發送數據包的數據量，對編碼來說就是控制單位時間內輸出數據的數據量。
TCP 的限制條件是網路帶寬，流控就是在避免造成或者加劇網路擁塞的前提下，盡可配汪宏能利用網路帶寬。帶寬夠、網路好，我們就加快速度發送數據包，出現了延遲增大、丟包之後，就放慢發包的速度（因為繼續高速發包，可能會加劇網路擁塞，反而發得更慢）。
視頻編碼的限制條件最初是解碼器的能力，碼率太高就會無法解碼，後來隨著 codec 的發展，解碼能力不再是陵鍵瓶頸，限制條件變成了傳輸帶寬/文件大小，我們希望在控制數據量的前提下，畫面質量盡可能高。
一般編碼器都可以設置一個目標碼率，但編碼器的實際輸出碼率不會完全符合設置，因為在編碼過程中實際可以控制的並不是最終輸出的碼率，而是編碼過程中的一個量化參數（Quantization Parameter，QP），它和碼率並沒有固定的關系，而是取決於圖像內容。 這一點不在這里展開，感興趣的朋友可以閱讀視頻壓縮編碼和音頻壓縮編碼的基本原理。
無論是要發送的 TCP 數據包，還是要編碼的圖像，都可能出現「尖峰」，也就是短時間內出現較大的數據量。TCP 面對尖峰，可以選擇不為所動（尤其是網路已經擁塞的時候），這沒有太大的問題，但如果視頻編碼也對尖峰不為所動，那圖像質量就會大打折扣了。如果有幾幀數據量特別大，但仍要把碼率控制在原來的水平，那勢必要損失更多的信息，因此圖像失真就會更嚴重。 這種情況通常的表現是畫面出現很多小方塊，看上去像是打了馬賽克一樣，導致畫面的局部或者整體看不清楚的情況
配置時指定目標碼率和碼率控制模式：
碼率控制模式有三種：
碼率控制模式在 MediaCodecInfo.EncoderCapabilities 類中定義了三種，在 framework 層有另一套名字和它們的值一一對應：
動態調整目標碼率：
Android 流控策略選擇
下面展示使用MediaExtractor獲取數據後，用MediaMuxer重新寫成一個MP4文件的簡單栗子
㈣ 在Android系統中如何調用系統自帶的視頻解碼器
對需要用FF解碼的視頻類型去掉內頌賣悉配陵部解碼勾選
2.在外部解碼器中對所選視頻選擇FF解碼器即野乎可
㈤ Javaweb返回給Android客戶端json中文字元亂碼
JavaWeb的各種中文亂碼終極解決方法：
一、Servlet輸出亂碼
1. 用servlet.getOutStream位元組流輸出中文，假設要輸出的是String str ="測試中文"。
1.1 若是本地伺服器與本地客戶端這種就不用說了，直接可以out.write(str.getBytes())可以輸出沒有問題。因為伺服器中用str.getBytes()是採用默認本地的編碼，比如GBK。而瀏覽器也解析時也用本地默認編碼，兩者是統一的，所以沒有問題。
1.1 若伺服器輸出時用了, out.write(str.getBytes("utf-8"))。而本地默認編碼是GBK時(比例在中國)，那麼用瀏覽器打開時就會亂碼。因為伺服器發送過來的是utf-8的1010數據，而客戶端瀏覽器用了gbk來解碼，兩者編碼不統一，肯定是亂碼。當然，你也可以自己將客戶端瀏覽器的編碼手工調用下(IE菜單是：查詢View->編碼encoding->utf-8)，但是這種操作很爛，最好由伺服器輸出響應頭告訴，瀏覽器用哪種編碼來解碼。所以要在伺服器的servlet中，增加response.setHeader("content-type","text/html;charset=utf-8")，當然也可直接用簡單的response.setContentType("text/hmtl;charset=utf-8")。兩種的操作是一樣一樣的。
2. 用servlet.getWirter字元流輸出中文，假設要輸出的擾旦是String str ="測試中文亂碼"。
2.1 若寫成out.print(str)輸出時，客戶端瀏覽器顯示的將全是多個?????的字元，代表在編碼表中肯定就找不到相應的字元來顯示。原因是：servlet.getWriter()得到的字元輸出流，默認對字元的輸出是採用ISO-8859-1，而ISO-8859-1肯定是不支持中文的。所以肯定要首先要做的第一件事：是要將伺服器對象輸出字元能支持中文的。其次伺服器向客戶端寫回的響應頭要告訴客戶端是用了哪種編碼表進行編碼的。而實現這兩個需求，只需要response.setContentType("text/hmtl;charset=utf-8")。斗李族就搞定了。特別注意：response.setContentType("text/html;charset=utf-8")要放在PrintOut out = response.getWriter()代碼的前面，否則只是有告訴客戶端用什麼碼表編碼的功能，而伺服器端還是用ISO-8859-1編碼了。再特別提示下：在同一Servlet中的doGet或doPost方法中，不能既用response.getOutputStream又用response.getWriter，因為這兩種response的響應輸出位元組流與字元流是沖突的，只能用其一。
二、Servlet文件下載，中文亂碼情況。
關鍵是下載時響應頭 content-disposition中attachment;filename=文件名。這個文件名filename不能是含有中文字元串的，要用URLEncoding編碼進行編碼，才能進行進行http的傳輸。
三、Servlet的response增加addCookie，cookie中value的中文碼問題解決方法。若想將cookie中存放中文的值，必須用Base64編碼後，發給客戶瀏覽器端進入存儲。而下次客戶端瀏覽訪問是帶回來的cookie中的值，是經過Base64編碼的，所以需要用Base64解碼即可。 Base64編碼主要是解決將特殊字元進行重新編碼，編碼成a-b、A-B、0-9、+與/，字元52，10個數字與一個+，一個/ 共64個字元。它的原理是將原來3個位元組的內容編碼成4個位元組。主要是取位元組的6位後，在前面補00組成一個新的位元組。所以這樣原來的3個位元組共24，被編碼成4個位元組32位了。
四、獲取請求參數亂碼
GET方式的亂碼：
如<a href=」/demo5/servlet/RD2?name=中國」>CN</a>，空弊直接用request.getParameter得到的字元串strCN將會亂碼，這也是因為GET方式是用http的url傳過來的默認用iso-8859-1編碼的，所以首先得到的strCn要再用iso-8859-1編碼得到原文後，再進行用utf-8(看具體頁面的charset是什麼utf-8或gbk)進行解碼即可。new String(strCn.getBytes(「ISO-8859-1」),「UTF-8」);
㈥ 如何解決Android WebView出現的亂碼問題
1、webView.loadUrl()；
直接顯示網頁內容(單獨顯示網路圖片)，一般不會出現亂碼。
2、webView.loadData(data, "text/html", "UTF-8");
loadData主要被設計用來裝載URI格式的數據，它不能通過網路來載入內容。網上流傳的webview載入中文出現亂碼，多數是使用此方法。使用過程中主要有兩個問題：
（1）loadData不能載入圖片內容，如果想載入圖片內容或者獲得更強大的Web支持建議使用更強大的loadDataWithBaseURL.
(2) 許多實用loadData方法的朋友都遇到顯示亂碼的問題，那是因為編碼器設置錯誤導致的。我們知道String類型的數銷鎮據主要是unicode編碼，而WebView一般為了節省資源使用的是UTF-8編碼，所以我們在loadData的時候要告訴方法怎樣轉碼。即要告訴它要將unicode編碼的內容轉成UTF-8編碼的內容。有些朋友雖然在loadData的時候設置了編碼方式，但是還是顯示亂碼，這是因虧消粗為還需要為WebView的text編碼指定編碼方式。舉例如下：
WebView wv = (WebView)findViewById(R.id.webview) ;
wv.getSettings().setDefaultTextEncodingName(「UTF -8」) ;
wv.loadData(content, 「text/html」橋碰, 「UTF-8」) ;
注意為gb2312或gbk
（3）.網頁說明編碼格式
以上兩種方法是網上給的比較好的方法，但是我都試了下都沒有解決我的亂碼問題。 原來我是用LoadData方法來解析html的，但是據說這是官方的一個BUG，不能用來解析中文。所以繞其道而行之，採用loadDataWithBaseURL的方法，其中codeingType設置為utf-8就OK了。3、loadDataWithBaseURL如果單純顯示文字的話可以寫webView.loadDataWithBaseURL(null, string, "text/html", "utf-8", null);
如果要顯示圖片可以寫webView.loadDataWithBaseURL(baseUrl, string, "text/html", "utf-8", null);
其中baseUrl為你存儲照片的路徑，比如：