繼續(xù)總結(jié)本司機(jī)在工作過程中涉及到的一些小知識(shí)點(diǎn)或小的技巧崔梗，其中有代碼片段，也有知識(shí)點(diǎn)蒜魄，經(jīng)驗(yàn)總結(jié)和分享场躯。因?yàn)楣ぷ鞅容^忙，真的沒法保證每天都有一篇公號(hào)文章發(fā)出踢关，所以標(biāo)題再叫“每天一點(diǎn)小知識(shí)”就不太合適了，因此改名為“小知識(shí)集錦”签舞。后續(xù)使用這個(gè)名稱柒瓣，繼續(xù)為大家總結(jié)各種小知識(shí)或技巧芙贫。
1、Drawable和Bitmap區(qū)別
Bitmap - 稱作位圖文件（Bitmap）磺平，擴(kuò)展名可以是.bmp或者.dib拐辽。位圖是Windows標(biāo)準(zhǔn)格式圖形文件，它將圖像定義為由點(diǎn)（像素）組成薛训，每個(gè)點(diǎn)可以由多種色彩表示仑氛，包括2乙埃、4介袜、8、16遇伞、24和32位色彩。例如鸠珠，一幅1024×768分辨率的32位真彩圖片秋麸，其所占存儲(chǔ)字節(jié)數(shù)為：1024×768×32/(8*1024)=3072KB。
位圖文件圖像效果比較好灸蟆，但是是非壓縮格式的，需要占用較大存儲(chǔ)空間炒考，不利于在網(wǎng)絡(luò)上傳送。jpg格式則恰好彌補(bǔ)了位圖文件這個(gè)缺點(diǎn)帘靡。
Drawable -是 Android平臺(tái)通用的圖形處理對(duì)象，它可以裝載常用格式的圖像测柠，比如 GIF、PNG轰胁、JPG，以及 BMP赃阀，另外還提供一些高級(jí)的可視化對(duì)象，比如漸變榛斯、圖形等。
2驮俗、Android編譯器一點(diǎn)知識(shí)
最近在調(diào)試一些開源項(xiàng)目時(shí)遇到如下報(bào)錯(cuò)，
Error:Jack is required to support java 8 language features. Either enable Jack or remove sourceCompatibility JavaVersion.VERSION_1_8.錯(cuò)誤解決
經(jīng)過在網(wǎng)上查找資料搪柑，找到一個(gè)知識(shí)點(diǎn)需要跟大家普及一下索烹。
2016 年 3 月，Google 向外界發(fā)布了 Android N 的預(yù)覽版的同時(shí)百姓，指出 Android N 增加了一項(xiàng)的新特性，這個(gè)特性是一項(xiàng)新的工具鏈垒拢，它與 Android 生態(tài)圈的所有開發(fā)者關(guān)系，即 Jack & Jill 編譯器的引入舱权。我們知道，Android一直依賴 Sun/Oracle 的 Java 編譯器達(dá)十年之久宴倍，而Google和Sun/Oracle一直在為Java的版權(quán)問題打官司，所以鸵贬，Google研發(fā)了自己的Java編譯器--Jack。Jack 是 Java Android Compiler Kit 的縮寫脖捻，它可以將 Java 代碼直接編譯為 Dalvik 字節(jié)碼阔逼，可以進(jìn)行 Minification, Obfuscation, Repackaging, Multidexing, Incremental compilation等工作嗜浮。它可以取代 javac/dx/proguard/jarjar/multidex 庫(kù)等目前已有的這些工具羡亩。
而Android N 7.0（API24）在對(duì)JAVA8的支持上危融，采用了新的編譯器。所以這個(gè)變異錯(cuò)誤的解決方法是在app的gradle文件defaultConfig?段中吉殃，增加如下聲明語句，
jackOptions {
? ? ? enabled true
}
即可解決問題瓦灶。
參考官網(wǎng)定義如下，
android {
? ...
? defaultConfig {
? ? ...
? ? jackOptions {
? ? ? enabled true
? ? }
? }
? compileOptions {
? ? sourceCompatibility JavaVersion.VERSION_1_8
? ? targetCompatibility JavaVersion.VERSION_1_8
? }
}
注意： 需要使用Android N 也就是API24
3贼陶、Canvas 和和 Paint 的關(guān)系
Canvas - 畫布巧娱。
我們可以看作處理工具，使用其提供的方法可以管理 Bitmap家卖、或Path 所在的圖形對(duì)象上荡，同時(shí)它可以配合 Matrix 矩陣類給圖像做旋轉(zhuǎn)、縮放等操作酪捡，以及可以進(jìn)行裁剪、選取等操作逛薇。
Paint - 畫筆疏虫。
可以把它看做一個(gè)畫圖工具，比如畫筆卧秘、畫刷。用它可以設(shè)置畫圖時(shí)的字體翅敌、顏色、樣式等治专。
4卖陵、插件化和熱修復(fù)的區(qū)別
這兩個(gè)概念對(duì)于新手來說张峰，比較容易混淆，這里簡(jiǎn)單介紹一下二者的區(qū)別鸥滨。
實(shí)際上，兩者的表現(xiàn)并不相同婿滓，而且差別也較明顯，雖然有些框架實(shí)現(xiàn)上可能有相同之處凸主，比如利用ClassLoad進(jìn)行hook等额湘。
插件化或者叫組件化的目的是為了減小模塊耦合，方便在項(xiàng)目體量變大之后實(shí)現(xiàn)更好地團(tuán)隊(duì)協(xié)作锋华。說白一些就是讓你把部分功能提取出來，放到插件里面毯焕，而不是一股腦都放到主APK里面，等你需要用到這個(gè)插件對(duì)應(yīng)的功能的時(shí)候再把它下載下來纳猫，這樣可以充分減少你主APK的大小。還有一個(gè)好處是可以靈活擴(kuò)展功能尚骄，比如版本迭代，引入新的功能倔丈。
熱更新或者熱修復(fù)主要目的是不用重新下載和安裝新的apk状蜗，使用戶可以在無感知的情況下修復(fù)線上的問題，避免了應(yīng)用在遇到問題后或者嚴(yán)重bug后頻繁發(fā)布新版本诗舰。
5、比較新和有權(quán)威的插件化框架
插件化或組件化：
DroidPlugin -- 360團(tuán)隊(duì)出品
質(zhì)量有保證，成功案例——360手機(jī)助手
Replugin -- 360出品
2017年06月30日開源边琉，360 公司幾乎所有的億級(jí)用戶量的 APP ，以及多款主流第三方 APP 变姨，都采用了 RePlugin 方案
Small--wequick推出的框架
輕巧的插件化框架厌丑，酷狗音樂等著名開發(fā)團(tuán)隊(duì)在使用。
Atlas--阿里框架
淘寶開發(fā)和實(shí)用的組件化開發(fā)框架怒竿。
VirtualAPK--滴滴
2017年6月3號(hào)開源，良好的兼容性耕驰，且入侵性較低，可以作為加載耦合插件方案是較好選擇饭弓。
除了以上，還有寫比較老一些的或者個(gè)人開發(fā)者框架如弟断，AndroidDymnamicLoader，dynamic-load-apk阀趴，CJFrameForAndroid冲秽，direct-load-api矩父。
6、比較有名的熱修復(fù)框架
Weex--阿里
不僅可以實(shí)現(xiàn)熱修復(fù)窍株，還支持跨平臺(tái)。
andfix（或hotfix）--阿里
2015年下半年開源后裸，提供了一種運(yùn)行時(shí)在Native修改Filed指針的方式，實(shí)現(xiàn)方法的替換微驶，達(dá)到即時(shí)生效無需重啟。
dexposed--阿里
阿里大部分App客戶端采用的熱修復(fù)因苹、線上調(diào)試能力的框架。
Sophix--阿里
2017年阿里新開源的框架凶杖，Sophix 可以說是博采眾長(zhǎng)，前面提到的Tinker及AndFix 都在某一方面存在缺陷智蝠。
Robust--美團(tuán)
Robust 兼容性與成功率較高，但是它與 AndFix 一樣奈梳，無法新增變量與類只能用做的 bugFix 方案。
QQ 空間超級(jí)補(bǔ)丁方案--騰訊
采用Dex分包機(jī)制實(shí)現(xiàn)颈嚼，讓修復(fù)后的類替換原有的類。
Tinker--騰訊
它是微信官網(wǎng)的Android熱補(bǔ)丁解決方案
7叫挟、UID和PID區(qū)別
UID是用戶ID。每個(gè)應(yīng)用程序只有一個(gè)抹恳。
Android中的UID和計(jì)算機(jī)不一樣署驻，計(jì)算機(jī)指的是每個(gè)用戶都具有一個(gè)Uid，而Android中每個(gè)程序都有一個(gè)Uid旺上，默認(rèn)情況下，Android會(huì)給每個(gè)程序分配一個(gè)普通級(jí)別互不相同的 Uid宣吱，Android規(guī)定只有Uid相同的組件才可以互相調(diào)用，因此同一個(gè)應(yīng)用下的Activity是可以互相調(diào)用的征候。
可以通過讀取文件data/system/packages.list來查看應(yīng)用對(duì)應(yīng)的UID杭攻。
也可以通過如下代碼獲取UID疤坝，
ActivityManager?am?=?(ActivityManager)?getSystemService(Context.ACTIVITY_SERVICE);
ApplicationInfo?appinfo?=?getApplicationInfo();
List?run?=?am.getRunningAppProcesses();
for?(RunningAppProcessInfo?runningProcess?:?run)?{
????if?((runningProcess.processName?!=?null)?&&?runningProcess.processName.equals(appinfo.processName))?{
????uid?=?String.valueOf(runningProcess.uid);
????break;
????}
}
PID是進(jìn)程ID。每個(gè)進(jìn)程對(duì)應(yīng)一個(gè)ID锅睛，但一個(gè)應(yīng)用可能會(huì)有多個(gè)進(jìn)程，因此應(yīng)用的PID并不是唯一的衣撬，它可能會(huì)有多個(gè)。
可以通過如下shell指令查看應(yīng)用對(duì)應(yīng)的PID具练。
ps|grep XXX
XXX表示程序的包名。
8哥遮、模擬產(chǎn)生點(diǎn)擊事件
有些同學(xué)不知道，在Android原生系統(tǒng)中有一個(gè)input工具眠饮，位于/system/bin目錄下，國(guó)內(nèi)大部分國(guó)產(chǎn)手機(jī)是保留這個(gè)二進(jìn)制可執(zhí)行文件的仪召，而有些手機(jī)卻將其閹割掉了松蒜。它的使用方法如下：
input keyevent xxx<按鍵名或者按鍵值>
xxx指具體的事件，如KEYCODE_BACK秸苗，表示一個(gè)返回鍵，對(duì)應(yīng)的值為3惊楼，再比如KEYCODE_HOME模擬一個(gè)home鍵。按鍵名或者值可以從官方文檔查詢檀咙，只要是以KEYCODE_開頭的都可以。
但是這個(gè)指令的執(zhí)行需要root權(quán)限才行弧可。
9、如何判斷activity是否已經(jīng)被銷毀
一般我們使用activity.isFinishing()方法來判斷activity是否已經(jīng)被銷毀殖演，若Activity被結(jié)束氧秘，這返回true，否則的話返回false丸相。但是在實(shí)際的項(xiàng)目中還是有問題，需要增加activity.isDestoryed()方法來判斷activity是否被銷毀膳算，但是isDestoryed()方法支持的最低版本為L(zhǎng)evel 17，因此這個(gè)方法也不是太靠譜涕蜂？
官方給出一個(gè)方法，
FragmentManager的API doc 中有這樣的定義：
/**
* Returns true if the final {@link?Android.app.Activity#onDestroy() Activity.onDestroy()}
* call has been made on the FragmentManager's Activity, so this instance is now dead.
*/
public abstract boolean isDestroyed();
因此可以借助FragmentManager對(duì)象來判斷机隙，即
if(fragmentManager.isDestroyed) return;
10、Opus文件格式
前一段時(shí)間協(xié)助遙控器端調(diào)節(jié)智能語音遙控器旭旭，需要將遙控器端用戶輸入的語音數(shù)據(jù)由遙控器的智能芯片通過藍(lán)牙BLE傳輸給盒子端，然后盒子端進(jìn)行解碼后用來識(shí)別持寄，從而控制盒子的操作。我們使用的這個(gè)芯片支持三種語音格式稍味，broadvoice，adpcm和opus這三種格式仲闽。于是對(duì)opus進(jìn)行了一下了解僵朗，以下內(nèi)容來自于網(wǎng)上。這里帶大家了解一下這種音頻壓縮格式验庙。
Opus編碼器 是一個(gè)有損聲音編碼的格式，由互聯(lián)網(wǎng)工程任務(wù)組近來開發(fā)的粪薛。Opus 格式是一種聲音編碼格式，并且是一個(gè)開放的格式违寿，使用上沒有任何專利或限制。它前身是celt編碼器藤巢。在當(dāng)今的有損音頻格式爭(zhēng)奪上，擁有眾多不同編碼器的AAC格式打敗了頗有潛力的Musepack才沧、Vorbis等格式迈喉，而在Opus格式誕生后温圆，情況有所變化。通過諸多的對(duì)比測(cè)試得运，低碼率下Opus完勝曾經(jīng)優(yōu)勢(shì)明顯的HE AAC，中碼率就已經(jīng)可以媲敵碼率高出30%左右的AAC格式澈圈，而高碼率下更接近原始音頻。
