- android 觸摸事件傳遞機(jī)制
時(shí)間傳遞的三個(gè)階段:
分發(fā)(dispatch) ----> 攔截(intercept) ---->消費(fèi)(consume)
在android 中擁有時(shí)間傳遞處理能力的類(lèi)有以下三種
Activity: 擁有dispatchTouchEvent 和 onTouchEvent兩個(gè)方法
ViewGroup: 擁有 dispatchTouchEvent , onInterceptTouchEvent, 和 onTouchEvent
View: 擁有dispatchTouchEvent 和 onTouchEvent兩個(gè)方法
234190-58b2ae8bc64282fc.png
- android view的繪制流程
android UI 管理系統(tǒng)層級(jí)關(guān)系
activity ->phoneWindow -> DecorView ->自己的布局
PhoneWindow 是android 系統(tǒng)中最基本的窗口系統(tǒng), 每個(gè)activity 會(huì)創(chuàng)建一個(gè), phoneWindow 是 activity 和 view系統(tǒng)交互的接口, decorView 本質(zhì)上是一個(gè)FrameLayout , 是activity 中所有的view的祖先
繪制會(huì)從根視圖ViewRoot 的 performTraversals()方法開(kāi)始
視圖繪制的過(guò)程分為三個(gè)步驟:
測(cè)量(Measure):
Measure操作用來(lái)計(jì)算view的實(shí)際大小, 測(cè)量流程是從performMeasure方法開(kāi)始的
重點(diǎn)關(guān)注三種測(cè)量模式:
UNSPECIFIED: 不指定測(cè)量模式,父視圖沒(méi)有限制子視圖的大小,子視圖可以是想要的任何尺寸,通常用于系統(tǒng)內(nèi)部,應(yīng)用開(kāi)發(fā)中很少使用
EXACTLY: 精確測(cè)量模式,當(dāng)視圖的layout_width 或者 layout_height制動(dòng)具體的數(shù)值或者match_parent時(shí)生效,表示父視圖已經(jīng)決定了子視圖的大小,這種模式下VIew的測(cè)量值就是SpecSIze的值
AT_MOST: 最大值模式,當(dāng)該視圖的layout_width或者layout_height指定wrap_parent時(shí)生效,此時(shí)子視圖的尺寸是不超過(guò)父視圖允許的最大尺寸的任何尺寸
布局(layout) :
layout 過(guò)程用來(lái)確定view在父容器中的布局位置,他是由父容器獲取子view的位置參數(shù)后,調(diào)用子view的layout方法并講位置參數(shù)傳入實(shí)現(xiàn)的
繪制(draw):
draw操作用來(lái)將控件繪制出來(lái),繪制的流程是從performDraw 方法開(kāi)始的,最終會(huì)調(diào)用到每個(gè)View的draw方法繪制每個(gè)具體的view,繪制基本上可以分為六個(gè)步驟:
步驟一: 繪制view的背景
drawBackground(canvas)
步驟二: 如果需要的話,保存canvas的圖層,為fading做準(zhǔn)備
canvas.getSaveCount()
步驟三: 繪制view的內(nèi)容
onDraw(canvas)
步驟四: 繪制view 的子view
dispatchDraw(canvas)
步驟五: 如果需要,繪制view的fading邊緣并恢復(fù)圖層
canvas.drawRect()
...
canvas.restoreToCount()
步驟六: 繪制view的裝飾(例如滾動(dòng)條)
onDrawScrollBars(canvas)
- android 的動(dòng)畫(huà)機(jī)制
android 3.0版本之前,可以使用逐幀動(dòng)畫(huà)和補(bǔ)間動(dòng)畫(huà)
3.0發(fā)布時(shí),引入了屬性動(dòng)畫(huà)
4.4的時(shí)候帶來(lái)了android.transition框架
逐幀動(dòng)畫(huà)(Drawable Animation):
他是利用人眼的視覺(jué)暫留效應(yīng)-----也就是光對(duì)視網(wǎng)膜產(chǎn)生的視覺(jué)在光停止作用后,仍會(huì)保留一段時(shí)間現(xiàn)象
實(shí)現(xiàn)逐幀動(dòng)畫(huà),就是由設(shè)計(jì)師給出一系列狀態(tài)不斷變化的圖片,開(kāi)發(fā)者可以指定動(dòng)畫(huà)中的每一幀對(duì)應(yīng)的圖片和持續(xù)時(shí)間,然后就可以開(kāi)始播放動(dòng)畫(huà)了,有兩種方式可以定義逐幀動(dòng)畫(huà),分別是XML資源文件和代碼實(shí)現(xiàn)
補(bǔ)間動(dòng)畫(huà)(Tween Animation)
補(bǔ)間動(dòng)畫(huà)是指開(kāi)發(fā)者無(wú)須定義動(dòng)畫(huà)過(guò)程中的每一幀,只需定義動(dòng)畫(huà)的開(kāi)發(fā)和結(jié)束這兩個(gè)關(guān)鍵幀,并指定動(dòng)畫(huà)變化的時(shí)間和方式等,然后交給系統(tǒng)進(jìn)行計(jì)算,通過(guò)兩個(gè)關(guān)鍵幀之間插入漸變值來(lái)實(shí)現(xiàn)平滑過(guò)度,,從而實(shí)現(xiàn)動(dòng)畫(huà)效果,主要由四種效果可以動(dòng)態(tài)組合,分別是:
透明度變化Alpha
大小變化Scale
位移變化Translate
旋轉(zhuǎn)變化Rotate
示例:
從上向下無(wú)限循環(huán)移動(dòng)
<?xml version="1.0" encoding="utf-8"?>
<set xmlns:android="http://schemas.android.com/apk/res/android">
<translate
android:duration="3000"
android:fillAfter="false"
android:fromYDelta="100"
android:toYDelta="550"
android:repeatCount="999999999"
android:interpolator="@android:anim/linear_interpolator" />
</set>
//開(kāi)始動(dòng)畫(huà)
scanAnim = AnimationUtils.loadAnimation(act,R.anim.scan_down)
iv_scan.startAnimation(scanAnim)
//停止動(dòng)畫(huà)
iv_scan.clearAnimation(scanAnim)
屬性動(dòng)畫(huà)(Property Animation)
過(guò)度動(dòng)畫(huà)(Transition Animation)
- Support Annotation Library 庫(kù)使用
注解庫(kù)
- Percent Support Library 庫(kù)使用
百分比控件庫(kù)
- Design Support Library 庫(kù)使用
比較新的控件庫(kù)
- NDK 開(kāi)發(fā)
ABI -> Application Binary Interface 應(yīng)用程序二進(jìn)制接口,android 平臺(tái)指.so文件
目前android系統(tǒng)支持7種不同的CPU架構(gòu),每一種CPU架構(gòu)對(duì)應(yīng)一個(gè)ABI,對(duì)應(yīng)android studio 中的目錄文件如下:
ARMv5->armeabi, ARMv7(從2010年起)->armeabi-v7a, x86(從2011年起)->x86 , MIPS(2012)->mips , ARMv8->arm64-v8a , MIPS6-> mips64, x86_64(2014年起)->x86-64
- Gradle 必知必會(huì)
共享變量----通用配置---aar函數(shù)庫(kù)引用---簽名和混淆配置 - 通過(guò)Gradle 打包發(fā)布函數(shù)庫(kù)到JCenter 和 Maven Central
- Builder 模式詳解
經(jīng)典的Builder模式
定義: 將一個(gè)復(fù)雜對(duì)象的構(gòu)建和他的表示分離,使得同樣的構(gòu)建過(guò)程可以創(chuàng)建不同的表示
經(jīng)典的Builder模式主要由四個(gè)參與者
1. Product: 被構(gòu)造的復(fù)雜對(duì)象, ConcreteBuilder 用來(lái)創(chuàng)建該對(duì)象的內(nèi)部表示,并定義他的裝配過(guò)程
2. Builder: 抽象接口,用來(lái)定義創(chuàng)建Product 對(duì)象的各個(gè)組成部件的操作
3. ConcreteBuilder: Builder接口的具體實(shí)現(xiàn),可以定義多個(gè),是實(shí)際構(gòu)建Product對(duì)象的地方,同時(shí)會(huì)提供一個(gè)返回Product的接口
4. Director: Builder 接口的構(gòu)造者和使用者
示例如下:
/* 定義: 將一個(gè)復(fù)雜對(duì)象的構(gòu)建與他的表示分離,使得同樣的構(gòu)建過(guò)程可以創(chuàng)建出不同的表示
**/
public class Product {
private String partOne;
private String partTwo;
public String getPartOne() {
return partOne;
}
public void setPartOne(String partOne) {
this.partOne = partOne;
}
public String getPartTwo() {
return partTwo;
}
public void setPartTwo(String partTwo) {
this.partTwo = partTwo;
}
}
interface Builder {
public void buildPartOne();
public void buildPartTwo();
public Product getProduct();
}
public class AConcreteBuilder implements Builder {
private String TAG = "AConcreteBuilder";
private Product product;
@Override
public void buildPartOne() {
System.out.println(TAG+ "buildPartOne: ");
product = new Product();
product.setPartOne("AConcreteBuilder--buildPartOne");
product.setPartTwo("AConcreteBuilder--buildPartTwo");
}
@Override
public void buildPartTwo() {
System.out.println(TAG+ "buildPartTwo: ");
// product = new Product();
// product.setPartTwo("AConcreteBuilder--buildPartTwo");
}
@Override
public Product getProduct() {
return product;
}
}
public class BConcreteBuilder implements Builder {
private Product product;
private String TAG = "BConcreteBuilder";
@Override
public void buildPartOne() {
System.out.println(TAG+"buildPartOne: ");
product = new Product();
product.setPartOne("BConcreteBuilder--buildPartOne");
}
@Override
public void buildPartTwo() {
System.out.println(TAG+"buildPartTwo: ");
product = new Product();
product.setPartOne("BConcreteBuilder--buildPartTwo");
}
@Override
public Product getProduct() {
return product;
}
}
public class Director {
private Builder builder;
public Director(Builder builder) {
this.builder = builder;
}
public void builderProduct(){
builder.buildPartOne();
builder.buildPartTwo();
}
public Product getProduct(){
return builder.getProduct();
}
}
@Test
public void builderTest(){
System.out.println("123");
Director director = new Director(new AConcreteBuilder());
director.builderProduct();
Product product = director.getProduct();
System.out.println(product.getPartOne());
System.out.println(product.getPartTwo());
}
變種Builder模式
可網(wǎng)上找個(gè)變種例子,一些開(kāi)源庫(kù)使用的就是變種builder模式,比如AlertDialog,Okhttp
- 注解
1.編譯時(shí)注解
2.運(yùn)行時(shí)注解
3.元注解
定義注解
注冊(cè)注解處理器
android的apt的注解插件
- ANR產(chǎn)生原因及定位分析
可通過(guò) /data/anr/traces.txt 目錄文件分析ANR
ANR的監(jiān)測(cè)工具BlockCanary函數(shù)庫(kù),StructMode
內(nèi)存監(jiān)測(cè)工具LoakCanary
ANR發(fā)生的原因:
1. activity 頁(yè)面響應(yīng)超過(guò)5s
2.broadcastReceiver 響應(yīng)超過(guò)10s
3.service 響應(yīng)超過(guò)20s
典型的ANR場(chǎng)景
1.UI線程存在耗時(shí)操作
2.UI線程等待子線程釋放某個(gè)鎖,無(wú)法處理用戶的輸入
3.動(dòng)畫(huà)的繪制需要大量的計(jì)算,導(dǎo)致CPU負(fù)載過(guò)重
- android 異步處理技術(shù)
Thread: 線程
在應(yīng)用層主要分3類(lèi)線程
1.UI線程,也是主線程
2.后臺(tái)線程(也是子線程)
3.binder線程(進(jìn)程之間的通信)
衍生順序:
Thread->HandleThread ->intentServer(服務(wù)線程)
->AsyncQueryHandler(在contentProvider中使用)
->Executor Framework -> AsyncTask ->loader
HandleThread 是一個(gè)集成了looper 和 MessageQueue的線程
- android 數(shù)據(jù)序列化方案研究
1.java中使用的Serializable ,主要應(yīng)用于磁盤(pán)和網(wǎng)絡(luò)中
原理: 使用java中的反射機(jī)制,在序列化過(guò)程中會(huì)創(chuàng)建多個(gè)臨時(shí)對(duì)象,很容易就觸發(fā)系統(tǒng)的回收機(jī)制,性能比較低, 也是對(duì)象轉(zhuǎn)換成字節(jié)的過(guò)程,反序列化就是字節(jié)轉(zhuǎn)化成對(duì)象的過(guò)程.
序列化過(guò)程: 先創(chuàng)建某種類(lèi)型的OutputStream(如 FileOutputSteam),接著將這些Outputstream封裝到一個(gè)ObjectOutputstream中,然后可以調(diào)用ObjectOutputStream 的writeobject方法,寫(xiě)完之后記得關(guān)閉各項(xiàng)
2.android 的 parcelable 序列化,android sdk 提供,操作的對(duì)象是內(nèi)存,速度較serialiable快很多,kotlin中可直接使用注解序列化
3.SQLDataBase ,sqllite數(shù)據(jù)庫(kù)
4.sharepreference 數(shù)據(jù)存儲(chǔ)
5.json
6.FlatBuffers 是google提供的序列化函數(shù)庫(kù),注重性能和資源的使用
- android Webview java 和 JS 交互
java調(diào)用js直接loadUrl
js調(diào)用java通過(guò)webSetting類(lèi)的諸多方法
- MVP,MVVM,MVC模式
MVC
view層,control層,model層,關(guān)系是個(gè)三角關(guān)系
MVP
是MVC模式的延伸和改進(jìn),view層-><-presenter層-><-model層
優(yōu)勢(shì):
1.如果界面發(fā)生改變,只需要改變view層
2.如果業(yè)務(wù)邏輯或者數(shù)據(jù)獲取方式改變,只需要修改model層
3.如果控制邏輯發(fā)生改變,只需要改變persenter層
4.業(yè)務(wù)的交互都是通過(guò)接口實(shí)現(xiàn)的,有利于新成員接觸代碼,也可根據(jù)事先定義好接口,功能交給不同的人開(kāi)發(fā)
劣勢(shì)
1.接口過(guò)多,代碼量,方法數(shù)增加
2.由于進(jìn)行了三層劃分,函數(shù)的調(diào)用棧變淺了,這對(duì)開(kāi)發(fā)人員的對(duì)代碼的認(rèn)識(shí)就變高了,如果開(kāi)發(fā)人員沒(méi)能分清楚那一層具體該負(fù)責(zé)哪些功能,那么就會(huì)造成代碼的亂入,mvp也就達(dá)不到充分解耦的目的.
MVVM
是MVP模式的延伸和改進(jìn): view層->viewModel層-><-model層
關(guān)鍵點(diǎn)在viewmodel,還引入了databinding的概念--以UI驅(qū)動(dòng)數(shù)據(jù)
- Databinding
UI驅(qū)動(dòng)數(shù)據(jù)
- 觀察者模式擴(kuò)展,事件總線
觀察者模式概念: 定義對(duì)象間的一種一對(duì)多的依賴(lài)關(guān)系,當(dāng)一個(gè)對(duì)象的狀態(tài)發(fā)生改變時(shí),所有依賴(lài)于他的對(duì)象都得到通知并自動(dòng)更新
原理
幾個(gè)事件分別是:
1.事件 Event
2.訂閱者 Subscrber
3.發(fā)布者 Publisher
4.總線 EventBus
publisher ---post Event--->EventBus ---event--->Subscriber1號(hào)
---event--->Subscriber2號(hào)
開(kāi)源實(shí)現(xiàn)庫(kù) EventBus
- 書(shū)寫(xiě)簡(jiǎn)單規(guī)范代碼
1.嚴(yán)格遵守java編碼規(guī)范
2.Android的一些命名規(guī)范
3.可以使用checkstyle 對(duì)項(xiàng)目的規(guī)范就行檢測(cè)
- 搭建自己的技術(shù)堆棧
APP整體架構(gòu)
較高的層次來(lái)講,一個(gè)app的整體架構(gòu)可以分為兩層,應(yīng)用層和基礎(chǔ)框架層
1.應(yīng)用層專(zhuān)注于行業(yè)領(lǐng)域的實(shí)現(xiàn),例如金融,支付,地圖導(dǎo)航,社交,他直接面向用戶,是用戶對(duì)產(chǎn)品的第一層感知
2.基礎(chǔ)框架層專(zhuān)注于技術(shù)領(lǐng)域的實(shí)現(xiàn),提供app公有的特性,避免重復(fù)制造輪子,他是用戶對(duì)產(chǎn)品的第二層感知,例如性能,穩(wěn)定性等
一個(gè)理想的App架構(gòu),首先應(yīng)該是支持跨平臺(tái)開(kāi)發(fā)的,其次應(yīng)該具有清晰的層次劃分,同一層之間模塊充分解耦,模塊內(nèi)部符合面向?qū)ο笤O(shè)計(jì)六大原則,最后應(yīng)該在功能,性能,穩(wěn)定性等方面達(dá)到綜合最優(yōu).
1659526289903.jpg
- 64K方法數(shù)限制原理和解決方案
APK本質(zhì)上是一個(gè)壓縮包,里面包含classes.dex是一個(gè)可執(zhí)行Dalvik字節(jié)碼文件,這個(gè).dex文件存放的事所有編譯后的java代碼,dalvik可執(zhí)行文件規(guī)范單個(gè).dex文件最多能引用的方法數(shù)是65536個(gè),這其中包含android framework,app引用的第三方函數(shù)庫(kù)以及app自身的方法
解決方案
使用MultiDex解決.俗稱(chēng)分包,就是將一個(gè)dex裝不下的方法分成多個(gè)dex裝
其實(shí)MultiDex是一個(gè)不得已而為之的方案,它本身并不是完美的,他會(huì)導(dǎo)致編譯非常的慢
在開(kāi)發(fā)階段優(yōu)化MultiDex的構(gòu)建
之所以MultiDex構(gòu)建如此緩慢,是因?yàn)闃?gòu)建系統(tǒng)需要經(jīng)過(guò)復(fù)雜的計(jì)算決定哪些類(lèi)要包含在主dex文件中,哪些類(lèi)可以包含在從dex中.為了解決這個(gè)問(wèn)題,減少開(kāi)發(fā)階段的構(gòu)建時(shí)間,我們可以在工程的主模塊的build.gradle文件中使用productFlavors來(lái)創(chuàng)建兩個(gè)flavor,一個(gè)是開(kāi)發(fā)階段使用的,一個(gè)是生產(chǎn)階段使用的,開(kāi)發(fā)階段的flavor 中,設(shè)置minSDKVersion 為21,這使得構(gòu)建系統(tǒng)使用ART支持的格式更快的生成MultiDex的輸出,生產(chǎn)階段的flavor中,設(shè)置minSdkVersion為應(yīng)用時(shí)機(jī)支持的最低版本號(hào)
- android 插件框架機(jī)制研究
為了解決APK隨著開(kāi)發(fā)周期的延長(zhǎng),需求的增多,APK的運(yùn)行會(huì)越來(lái)越緩慢,這時(shí)插件化框架應(yīng)運(yùn)而生,雖然google提出了MultiDex的方案,但我們都知道他并不是很完美.插件化框架的基本形式是將一個(gè)APK中的不同功能模塊進(jìn)行拆分,并大儒道不同的dex文件或者apk文件中,主工程只是一個(gè)空殼,提供了用來(lái)加載模塊dex或者apk的框架,使用插件框架的好處也有很多:
1.提升AS工程的構(gòu)建速度
2.提高應(yīng)用的啟動(dòng)速度
3.支持多團(tuán)隊(duì)開(kāi)發(fā)
4.在線動(dòng)態(tài)加載或者更新模塊
5.按需加載不同的模塊,實(shí)現(xiàn)靈活的功能配置
ClassLoader機(jī)制
android中的Classloader機(jī)制是用來(lái)加載dex文件,系統(tǒng)提供了兩個(gè)API可供選擇
1.PathClassLoader: 只能加載已經(jīng)安裝到android系統(tǒng)的apk文件
2.DexClassLoader: 支持加載外部的apk,jar,或者dex文件,,正好符合插件化的需求,所以有的插件化方案都是使用的DexClassLoader 來(lái)加載插件的APK中的.class文件的
開(kāi)源的插件框架
1.android-pluginmgr
2.dynamic-load-apk
3.DynamicAPK
4.DroidPlugin
5.Small
- 推送機(jī)制實(shí)現(xiàn)原理詳解
開(kāi)源實(shí)現(xiàn)
1.基于XMPP協(xié)議
2.基于MQTT協(xié)議
第三方平臺(tái)
百度,小米,極光,友盟等
自己實(shí)現(xiàn)推送功能
通過(guò)網(wǎng)絡(luò)套接字socket,他封裝了很多tcp的操作,對(duì)移動(dòng)端來(lái)說(shuō),一個(gè)推送的基本框架需要包括:
1.和服務(wù)端建立連接的功能
2.發(fā)送數(shù)據(jù)給服務(wù)端的功能
3.從服務(wù)端接收推送數(shù)據(jù)的功能
4.心跳包的實(shí)現(xiàn)
- APP瘦身經(jīng)驗(yàn)
1.優(yōu)化圖片資源占用的空間
2.使用Lint工具刪除無(wú)用的資源
3.利用gradle的配置,減少最后生成的apk包大小
4.重構(gòu)和優(yōu)化代碼
5.資源混淆
6.插件化
- android Carsh 日志收集原理與實(shí)踐
定義
java中常用的異常主要有兩類(lèi),一種是編譯時(shí)的異常(CheckedException),必須在編譯時(shí)期進(jìn)行處理,常用操作就是使用try..catch捕獲進(jìn)行處理.另外一種是運(yùn)行時(shí)異常(UnCheckedException),這類(lèi)異常在編譯時(shí)期是檢測(cè)不出來(lái)的,只有在運(yùn)行階段特定的情況下觸發(fā)才能檢測(cè)出來(lái).
原理
java API提供的全局的異常捕獲處理器 Thread.UncaughtExceptionHandler 處理器,通常情況下我們只需要實(shí)現(xiàn)這個(gè)接口,重寫(xiě)他的uncaughtException放,在該方法就可以讀取carsh的堆棧信息,注意一點(diǎn)要在app啟動(dòng)的時(shí)候注冊(cè)哦,不然他還是沿用的系統(tǒng)默認(rèn)的異常處理
- 函數(shù)式編程思想
RxJava,RxAndroid,Agera,這幾個(gè)函數(shù)式框架,都提現(xiàn)了Android的函數(shù)式編程
- 依賴(lài)注入在android的使用
優(yōu)勢(shì)
依賴(lài)注入讓開(kāi)發(fā)者可以編寫(xiě)低耦合的代碼,他解耦了依賴(lài)者和被依賴(lài)者,代碼易于單元測(cè)試
依賴(lài)注入(簡(jiǎn)稱(chēng) DI )也可以稱(chēng)為控制反轉(zhuǎn)(Inversion of Control) 簡(jiǎn)稱(chēng)IoC,IoC一般分為兩種類(lèi)型,一種就是依賴(lài)注入,另一種就是依賴(lài)查找
復(fù)雜的項(xiàng)目建議直接使用依賴(lài)注入框架,常用的依賴(lài)注入框架有
1.BufferKnife
2.RoboGuice
3.Dagger
- kotlin 在android中的使用
- react native 在 android中使用
- 在線熱修復(fù)方案
原理
線上的正式包APK稱(chēng)為宿主APK,補(bǔ)丁包稱(chēng)為補(bǔ)丁APK,線上出現(xiàn)問(wèn)題后,需在線下載補(bǔ)丁APK,使用補(bǔ)丁APK中的函數(shù)替換原來(lái)的函數(shù),從而實(shí)現(xiàn)修復(fù)bug的功能
熱修復(fù)框架
1.Dexposed 阿里巴巴開(kāi)源,支持android版本太低
2.AndFix 阿里巴巴開(kāi)源,純粹的熱修復(fù)框架
3.Nuwa QQ空間開(kāi)發(fā)團(tuán)隊(duì),基于classLoader加載dex文件實(shí)現(xiàn)熱修復(fù)
- 面向切面編程
AOP (Aspect Oriented Programming) 即面向切面編程
可以使用AspectJ進(jìn)行 android 平臺(tái)的切面編程
1.Hugo 插件
- FaceBook Buck 改造android 構(gòu)建系統(tǒng)
- 代碼優(yōu)化,圖片優(yōu)化,網(wǎng)絡(luò)優(yōu)化,電量?jī)?yōu)化,布局優(yōu)化
- android 混淆機(jī)制詳解
混淆的目的是為了保護(hù)自己的知識(shí)產(chǎn)權(quán),增加別人的反編譯難度
Android的混淆包括三種類(lèi)型:
1.java代碼混淆
2.Native (C 和 C++) 代碼混淆
3.資源文件的混淆
主要混淆還是在java代碼層,java代碼層的混淆一般依賴(lài)于proguard 或者 dexguard 工具,
proguard是免費(fèi)開(kāi)源的,但功能有限,dexguard是收費(fèi)的
proguard 特性
1.壓縮,優(yōu)化,混淆,預(yù)檢驗(yàn)
Android Studio 創(chuàng)建項(xiàng)目的時(shí)候默認(rèn)是使用Proguard 的,其中proguard-Android.text 是Proguard 默認(rèn)的混淆配置文件,位于 Android SDK 的 tools/proguard目錄中 ,項(xiàng)目根目錄下的 proguard-rules.pro文件也是編寫(xiě)混淆的文件
- android 反編譯機(jī)制
借助第三方的反編譯工具 APKTool
- 客戶敏感信息隱藏技術(shù)研究
- android 加固技術(shù)研究
加固的目的和混淆的目的其實(shí)是一致的,都是為了保護(hù)自己的知識(shí)產(chǎn)權(quán),防止反編譯,一些常用的第三方加固有:
1.梆梆加固
2.愛(ài)加固
3.迦娜
4.360加固
5.騰訊加固
6.百度加固等
- android 安全編碼
一些保證編寫(xiě)代碼安全的建議,如
1.WebVIew 遠(yuǎn)程代碼執(zhí)行
2.WebView 密碼明文保存
3.Android 本地拒絕服務(wù)
4.SharedPreference 全局任意讀寫(xiě)
5.密碼硬編碼
6.弱加密
7.PendingIntent 使用不當(dāng) 等
- android 調(diào)試工具 Facebook Stetho
- 內(nèi)存泄漏檢測(cè)函數(shù)庫(kù) LeakCanary
LeakCanary 檢測(cè)內(nèi)存泄漏的原理
RefWatcher.watch() 函數(shù)會(huì)為被監(jiān)控的對(duì)象創(chuàng)建一個(gè) KeyedWeakReference 弱引用對(duì)象, KeyedWeakReference 是 WeakReference 的子類(lèi),增加了鍵值對(duì)信息,后面會(huì)根據(jù)指定的鍵值key 找到弱引用對(duì)象
在后臺(tái)線程AndroidWatchExecutor 中,檢查 KeyedWeakReference 弱引用是否已經(jīng)被清除,如果還存在,則觸發(fā)一次 垃圾回收機(jī)制,垃圾回收之后,如果弱引用對(duì)象依然存在,說(shuō)明發(fā)生了內(nèi)存泄漏
- 基于Facebook Redex 實(shí)現(xiàn) APK的壓縮和優(yōu)化
- android studio 你所需要知道功能
1.Annotate git記錄代碼作者編寫(xiě)工具
2..ignore 插件
- android 單元測(cè)試框架簡(jiǎn)介
- android UI自動(dòng)化測(cè)試框架簡(jiǎn)介
- android 靜態(tài)代碼分析
- Jenkins+Gradle 搭建android 持續(xù)集成編譯環(huán)境
