⑴ android無線開發的幾種常用技術（阿里巴巴資深
完整的開發一個android移動App需要經過從分解需求、架構設計到開發調試、測試、上線發布等多個階段，在發布後還會有產品功能上的迭代演進，此外還會面對性能、安全、無線網路質量等多方面的問題。
移動App的產品形態各不相同，有的是內容類，有的是工具類，有的是社交類，所以它們的業務邏輯所偏重的核心技術有些差別，但它們都會用到一些常用的技術方案。今天我們就先來簡單介紹一下這些常用技術，以後會專門分專題來詳細介紹這些技術的原理和使用場景。
1. Multidex
在Dalvik虛擬機所使用的dex文件格式中，用原生類型short來索引文件中的方法數，也就是最多隻能有4個位元組65536個method，在打包apk的過程中會把工程所需要的全部class文件都合並壓縮到一個dex文件中，也就是說自己開發的代碼加上外部引用的庫的方法總數不能超過65535。
隨著業務邏輯的不斷增長，很容易就會超過這個限制，在編譯期間就會遇到這樣一個錯誤：
還好google官方給出了一個解決方案Multidex，它會把dex文件拆成兩個或多個，第二個dex文件叫classes2.dex，在Application實例化後會從apk中解壓出classes2.dex並將其拷貝到應用的目錄下，通過反射將其注入到當前的ClassLoader中。但是這個方案非但不能解決一切問題也不能直接拿來用，而要加入自己的一些改造，來解決NoClassDefFoundError、INSTALL_FAILED_DEXOPT等問題，以保證自己的dex被順利的載入流暢的執行。
2. Plugin
Multidex雖然可以解決方法數的限制，但隨著業務邏輯越來越多，apk的大小也變得越來越多，而且有一些功能並非全部用戶都想用的，所以會把一些功能模塊獨立出來做成插件，讓用戶可以按需下載更新，這樣既減小了包大小，又改善了用戶體驗。
插件類似於windows的dll文件，放在某個特定目錄，應用程序主框架會用LoadLibrary載入各dll文件，按插件介面去訪問插件。Android的插件技術也是這樣，利用一個進程可以運行多個apk的機制，用ClassLoader將宿主apk之外的類載入進來，插件的context可以通過createPackageContext方法創建。因為插件中的activity，service等組件如果沒有在AndroidManifest.xml中聲明將不能運行，所以需要預先在AndroidManifest.xml中聲明一個代理類（ProxyActivity），將這個ProxyActivity傳給插件，讓插件的activity也有訪問資源的能力。
3. Hot Patch
有時一些嚴重的crash bug或漏洞需要緊急修復，但有些用戶不會或不願意立即升級，而且頻繁升級，沒有特別的功能更新只是修復bug的升級，對活躍用戶是一種傷害。熱補丁就可以解決這樣的窘境，它是一種可以線上修復的技術方案，有動態改變方法的能力，一般大型的移動應用都會使用熱補丁來處理緊急事件。
Hot Patch可以通過hook來修改java的method，注入自己的代碼，實現非侵入式的runtime修改，或者採用正向編程，通過工具生成patch文件，通過jni bridge指向補丁文件中的方法。還有就是利用ClassLoader，在dex中查找class時，如果找到類則返回，找不到就從下一個dex文件中繼續查找，由此可以想到，在把問題修復後，可以單獨生成一個dex，通過反射插入到dexElements數組的最前面，這樣就能讓dalvik載入補丁里的類了。
4. Push通道
Push是移動App常用的一種無線技術，基礎是基於TCP的心跳機制，和客戶端維持一個長連接。用處是向客戶端推送消息，或者代替客戶端定時去從伺服器pull的策略，改為客戶端接收到push消息後再去pull。
如果每個應用都自己實現push通道的話，cpu就會不定時地經常被喚醒，耗電量達到難以容忍的程度，而且自己搭建push平台的成本也很大，實時性和效率也存在問題，一般都直接使用一些服務商提供的push方案，這些push平台一般都經過了優化設計，在跨平台和網路穿透性、長連接心跳包、多客戶端App鏈路復用、服務和連接保活等技術上做了優化。比如Agoo最初是淘寶無線事業部開發的push服務，在逐漸完善和支撐淘系其他app後，通過服務端容量、通訊協議優化、業務和開放能力的拓展改進後，與友盟等合作，開始向第三方提供推送服務。
5. 應用加固
一款熱門的移動app或游戲發布後會受到很多的關注，經常會遇到二次打包的盜版行為，破解者要麼修改游戲的資源文件、道具、分值甚至直接把訪問的站點指向自己架設的伺服器，損害了開發者的利益；要麼偷偷植入自己的惡意代碼，表面上看起來跟正版的app完全一樣，在後台卻盜取用戶隱私，植入木馬；要麼通過反向工程學習原app的核心技術，打破技術上的競爭壁壘。
為了防止被破解只通過混淆是遠遠不夠的，即使是在native層混淆也還是會被人熟練的反編譯，所以需要一套對apk的保護方案來反調試、防逆向和防篡改。一般的加固方法都是對原apk先進行加密，然後和殼合並生成新的apk。殼是用來解密apk的dex文件。當應用啟動時，殼先解密原apk，准備好自己定義的ClassLoader，然後獲取源程序中的Application名稱，通過反射找到正確的Application對象，運行它的onCreate方法，這樣原apk才能被真正運行。其他一些反調試的方法有針對反編譯工具，在源程序中加入一些無效的指令或無效的指針，引發反編譯工具的崩潰，還有就是加花指令，利用一些跳轉，堆棧操作等指令，讓破解者無法清楚地理解反匯編後的內容。
6. 其他
除了上述幾點外，在服務端還會涉及灰度策略、鏈路流量優化、動態更新配置、防DNS劫持等技術，在客戶端會涉及用戶埋點上報、在線監控、進程保活、H5和native混合開發、注入框架等。
⑵ 在Android中實現圖片銳化，中值濾波，變為黑白灰度圖。在java中可實現，但在Android中一些import 出錯。
有可能是兩個包有相同的方法，但功能和參數有所不同，要修改的是，你把所有import都刪除掉，再重新導包，按Ctrl+Shift+O快捷鍵，所需要的包就導進去了，如果有兩種選擇的時候，如果還有重復，那麼你可能有兩個相同屬性和方法的包在項目的Lib裡面的，只是版本不同，那麼你又把一個刪除。再編譯就OK了
⑶ 邊緣檢測，圖像模糊，灰度化和圖像去霧的基本思路是什麼呢 說出是需要改變哪些色彩空間的值。。。
我挨個說一下吧，也算給自己復習一下。
一 邊緣檢測
方法很多很多啊。
1 常用的是用各種邊緣檢測運算元對圖像進行卷積運算，計算出來圖像每個部分的梯度值，由於邊緣有突變的像素值，所以梯度大的地方很可能是邊緣。常見的有 sobel運算元等。
2 形態學運算，主要是針對二值化之後的圖比較高效，直接先膨脹再腐蝕，然後相減圖像就是邊緣。
3 canny演算法，這個用的很多，我也很喜歡，主要是用到強邊緣和弱邊緣進行區分。
4 通過識別feature進行識別，在邊緣不明顯的時候比較有效。
二 圖像模糊
這里你要知道一個概念，什麼是模糊呢？
咱們近視眼就是一個模糊，這個模糊就是眼睛的成像不能精確的成像在視網膜上吧？
你可以想像一下，其實這就是一個尺度變換的問題，你看一張報紙很清楚，但是從五十米外看你這張報紙（我們假設能看得到），就非常模糊，不能辨認吧？
我這里就引出這個模糊的概念：叫做高斯濾波，高斯濾波其實就是一個尺度變換。
我再打個比方吧，比如一個圍棋棋盤，黑線是黑線，棋盤是棋盤，即使黑線很細，你也能分清楚是吧？
但是如果你摘下眼鏡看呢？黑線變粗了是吧？黑線變暗了是吧？
其實真正原因是棋盤的信息進入了原本黑線的地方，而黑線也進入了棋盤的地方。
這就是濾波的魅力，可以使像素各個梯度變小，讓圖像的像素點之間的聯系沒有那麼強烈。。
既然引出高斯濾波，那就有其他的各種濾波，比如拉普拉斯濾波，中值濾波，均值濾波。
實際操作中應用的也都是運算元求卷積的方法。
三 灰度化
你看電視的時候應該知道，電視上的一個彩色點，其實是GRB顏色模式，就是綠紅藍三色。
對應這個RGB顏色模式，你可以通過對這三個顏色通道的值進行處理，比如我就定義 V=(R+G+B)/3。那麼這個V就包含了三種顏色的信息了吧？
但是一般的我們不直接用三個平均，而是由各個相應的系數相乘得到。
這是RGB顏色模式，但是如果你用到HSV顏色模式，問題就簡單多了。
什麼是HSV模式呢？你遙控器上可能有 色度 飽和度 亮度按鈕吧？
這個就是HSV模式，其中這個V 就是 亮度 value，這個就直接是灰度信息了。
四 圖像去霧
我對這個去霧的理解是，圖像增強。
也可以叫做是圖像銳化，這個過程正好和圖像模糊相對應。
模糊是讓梯度值變小，銳化就是讓梯度變大。
對應的方法也是響應的運算元進行濾波了。
而需要注意的是，銳化用的是高通濾波，模糊是低通濾波。
因為邊緣信息一般都是頻率高的信號。
視頻分析系統團隊
風之風信子