Android面試17個知識點總結(jié)寶典
Android中的四大組件以及應(yīng)用場景
- Activity：在Android應(yīng)用中負(fù)責(zé)與用戶交互的組件。
- Service：常用于為其他組件提供后臺服務(wù)或者監(jiān)控其他組件的運行狀態(tài)。經(jīng)常用來執(zhí)行一些耗時操作。
- BroadcastReceiver：用于監(jiān)聽?wèi)?yīng)用程序中的其他組件。
- ContentProvider：Android應(yīng)用程序之間實現(xiàn)實時數(shù)據(jù)交換。
1、Activity的生命周期
生命周期：對象什么時候生，什么時候死，怎么寫代碼，代碼往那里寫。
注意：
- 當(dāng)打開新的Activity，采用透明主題的時候，當(dāng)前Activity不會回調(diào)onStop
- onCreate和onDestroy配對，onStart和onStop配對（是否可見），onResume和onPause配對（是否在前臺，可以與用戶交互）
- 打開新的Activity的時候，相關(guān)的Log為：
- Main1Activity: onPause
- Main2Activity: onCreate
- Main2Activity: onStart
- Main2Activity: onResume
- MainA1ctivity: onStop
異常狀態(tài)下的生命周期：
資源相關(guān)的系統(tǒng)配置發(fā)生改變或者資源不足：例如屏幕旋轉(zhuǎn)，當(dāng)前Activity會銷毀，并且在onStop之前回調(diào)onSaveInstanceState保存數(shù)據(jù)，在重新創(chuàng)建Activity的時候在onStart之后回調(diào)onRestoreInstanceState。其中Bundle數(shù)據(jù)會傳到onCreate（不一定有數(shù)據(jù)）和onRestoreInstanceState（一定有數(shù)據(jù)）。
防止屏幕旋轉(zhuǎn)的時候重建，在清單文件中添加配置：
- android:configChanges="orientation"
2、Fragment的生命周期
正常啟動
- Activity: onCreate
- Fragment: onAttach
- Fragment: onCreate
- Fragment: onCreateView
- Fragment: onActivityCreated
- Activity: onStart
- Activity: onResume
正常退出
- Activity: onPause
- Activity: onStop
- Fragment: onDestroyView
- Fragment: onDestroy
- Fragment: onDetach
- Activity: onDestroy
3、Activity的啟動模式
- standard：每次激活A(yù)ctivity時(startActivity)，都創(chuàng)建Activity實例，并放入任務(wù)棧；
- singleTop：如果某個Activity自己激活自己，即任務(wù)棧棧頂就是該Activity，則不需要創(chuàng)建，其余情況都要創(chuàng)建Activity實例；
- singleTask：如果要激活的那個Activity在任務(wù)棧中存在該實例，則不需要創(chuàng)建，只需要把此Activity放入棧頂，即把該Activity以上的Activity實例都pop，并調(diào)用其onNewIntent；
- singleInstance：應(yīng)用1的任務(wù)棧中創(chuàng)建了MainActivity實例，如果應(yīng)用2也要激活MainActivity，則不需要創(chuàng)建，兩應(yīng)用共享該Activity實例。
4、Activity與Fragment之間的傳值
- 通過findFragmentByTag或者getActivity獲得對方的引用（強轉(zhuǎn)）之后，再相互調(diào)用對方的public方法，但是這樣做一是引入了“強轉(zhuǎn)”的丑陋代碼，另外兩個類之間各自持有對方的強引用，耦合較大，容易造成內(nèi)存泄漏。
- 通過Bundle的方法進(jìn)行傳值，例如以下代碼：
- //Activity中對fragment設(shè)置一些參數(shù)
- fragment.setArguments(bundle);
- //fragment中通過getArguments獲得Activity中的方法
- Bundle arguments = getArguments();
3. 利用eventbus進(jìn)行通信，這種方法實時性高，而且Activity與Fragment之間可以完全解耦。
- //Activity中的代碼
- EventBus.getDefault().post("消息");
- //Fragment中的代碼
- EventBus.getDefault().register(this);
- @Subscribe
- public void test(String text) {
- tv_test.setText(text);
- }
5、Service
Service分為兩種：
- 本地服務(wù)，屬于同一個應(yīng)用程序，通過startService來啟動或者通過bindService來綁定并且獲取代理對象。如果只是想開個服務(wù)在后臺運行的話，直接startService即可，如果需要相互之間進(jìn)行傳值或者操作的話，就應(yīng)該通過bindService。
- 遠(yuǎn)程服務(wù)（不同應(yīng)用程序之間），通過bindService來綁定并且獲取代理對象。
對應(yīng)的生命周期如下：
- context.startService() ->onCreate()- >onStartCommand()->Service running--調(diào)用context.stopService() ->onDestroy()
- context.bindService()->onCreate()->onBind()->Service running--調(diào)用>onUnbind() -> onDestroy()
注意
Service默認(rèn)是運行在main線程的，因此Service中如果需要執(zhí)行耗時操作（大文件的操作，數(shù)據(jù)庫的拷貝，網(wǎng)絡(luò)請求，文件下載等）的話應(yīng)該在子線程中完成。
！特殊情況是：Service在清單文件中指定了在其他進(jìn)程中運行。
6、Android中的消息傳遞機制
為什么要使用Handler？
因為屏幕的刷新頻率是60Hz，大概16毫秒會刷新一次，所以為了保證UI的流暢性，耗時操作需要在子線程中處理，子線程不能直接對UI進(jìn)行更新操作。因此需要Handler在子線程發(fā)消息給主線程來更新UI。
這里再深入一點，Android中的UI控件不是線程安全的，因此在多線程并發(fā)訪問UI的時候會導(dǎo)致UI控件處于不可預(yù)期的狀態(tài)。Google不通過鎖的機制來處理這個問題是因為：
- 引入鎖會導(dǎo)致UI的操作變得復(fù)雜
- 引入鎖會導(dǎo)致UI的運行效率降低
因此，Google的工程師***是通過單線程的模型來操作UI，開發(fā)者只需要通過Handler在不同線程之間切花就可以了。
概述一下Android中的消息機制？
Android中的消息機制主要是指Handler的運行機制。Handler是進(jìn)行線程切換的關(guān)鍵，在主線程和子線程之間切換只是一種比較特殊的使用情景而已。其中消息傳遞機制需要了解的東西有Message、Handler、Looper、Looper里面的MessageQueue對象。
如上圖所示，我們可以把整個消息機制看作是一條流水線。其中：
- MessageQueue是傳送帶，負(fù)責(zé)Message隊列的傳送與管理
- Looper是流水線的發(fā)動機，不斷地把消息從消息隊列里面取出來，交給Handler來處理
- Message是每一件產(chǎn)品
- Handler就是工人。但是這么比喻不太恰當(dāng)，因為發(fā)送以及最終處理Message的都是Handler
為什么在子線程中創(chuàng)建Handler會拋異常？
Handler的工作是依賴于Looper的，而Looper（與消息隊列）又是屬于某一個線程（ThreadLocal是線程內(nèi)部的數(shù)據(jù)存儲類，通過它可以在指定線程中存儲數(shù)據(jù)，其他線程則無法獲取到），其他線程不能訪問。因此Handler就是間接跟線程是綁定在一起了。因此要使用Handler必須要保證Handler所創(chuàng)建的線程中有Looper對象并且啟動循環(huán)。因為子線程中默認(rèn)是沒有Looper的，所以會報錯。
正確的使用方法是：
- handler = null;
- new Thread(new Runnable() {
- private Looper mLooper;
- @Override
- public void run() {
- //必須調(diào)用Looper的prepare方法為當(dāng)前線程創(chuàng)建一個Looper對象，然后啟動循環(huán)
- //prepare方法中實質(zhì)是給ThreadLocal對象創(chuàng)建了一個Looper對象
- //如果當(dāng)前線程已經(jīng)創(chuàng)建過Looper對象了，那么會報錯
- Looper.prepare();
- handler = new Handler();
- //獲取Looper對象
- mLooper = Looper.myLooper();
- //啟動消息循環(huán)
- Looper.loop();
- //在適當(dāng)?shù)臅r候退出Looper的消息循環(huán)，防止內(nèi)存泄漏
- mLooper.quit();
- }
- }).start();
主線程中默認(rèn)是創(chuàng)建了Looper并且啟動了消息的循環(huán)的，因此不會報錯：
應(yīng)用程序的入口是ActivityThread的main方法，在這個方法里面會創(chuàng)建Looper，并且執(zhí)行Looper的loop方法來啟動消息的循環(huán)，使得應(yīng)用程序一直運行。
子線程中可以通過Handler發(fā)送消息給主線程嗎？
可以。有時候出于業(yè)務(wù)需要，主線程可以向子線程發(fā)送消息。子線程的Handler必須按照上述方法創(chuàng)建，并且關(guān)聯(lián)Looper。
7、事件傳遞機制以及自定義View相關(guān)
Android的視圖樹
Android中View的機制主要是Activity的顯示，每個Activity都有一個Window（具體在手機中的實現(xiàn)類是PhoneWindow），Window以下有DecorView，DecorView下面有TitleVie以及ContentView，而ContentView就是我們在Activity中通過setContentView指定的。
事件傳分發(fā)機制
ViewGroup有以下三個與事件分發(fā)的方法，而View只有dispatchTouchEvent和onTouchEvent。
- @Override
- public boolean dispatchTouchEvent(MotionEvent ev) {
- return super.dispatchTouchEvent(ev);
- }
- @Override
- public boolean onInterceptTouchEvent(MotionEvent ev) {
- return super.onInterceptTouchEvent(ev);
- }
- @Override
- public boolean onTouchEvent(MotionEvent event) {
- return super.onTouchEvent(event);
- }
事件總是從上往下進(jìn)行分發(fā)，即先到達(dá)Activity，再到達(dá)ViewGroup，再到達(dá)子View，如果沒有任何視圖消耗事件的話，事件會順著路徑往回傳遞。其中：
- dispatchTouchEvent是事件的分發(fā)方法，如果事件能夠到達(dá)該視圖的話，就首先一定會調(diào)用，一般我們不會去修改這個方法。
- onInterceptTouchEvent是事件分發(fā)的核心方法，表示ViewGroup是否攔截事件，如果返回true表示攔截，在這之后ViewGroup的onTouchEvent會被調(diào)用，事件就不會往下傳遞。
- onTouchEvent是***級的，在事件分發(fā)中***被調(diào)用。
- 子View可以通過requestDisallowInterceptTouchEvent方法去請求父元素不要攔截。
注意
- 事件從Activity.dispatchTouchEvent()開始傳遞，只要沒有被停止或攔截，從最上層的View(ViewGroup)開始一直往下(子View)傳遞。子View 可以通過onTouchEvent()對事件進(jìn)行處理。
- 事件由父View(ViewGroup)傳遞給子View，ViewGroup 可以通過onInterceptTouchEvent()對事件做攔截，停止其往下傳遞。
- 如果事件從上往下傳遞過程中一直沒有被停止，且***層子View 沒有消費事件，事件會反向往上傳遞，這時父View(ViewGroup)可以進(jìn)行消費，如果還是沒有被消費的話，***會到Activity 的onTouchEvent()函數(shù)。
- 如果View 沒有對ACTION_DOWN 進(jìn)行消費，之后的其他事件不會傳遞過來。
- OnTouchListener 優(yōu)先于onTouchEvent()對事件進(jìn)行消費。
自定義View的分類
- 對現(xiàn)有的View的子類進(jìn)行擴展，例如復(fù)寫onDraw方法、擴展新功能等。
- 自定義組合控件，把常用一些控件組合起來以方便使用。
- 直接繼承View實現(xiàn)View的完全定制，需要完成View的測量以及繪制。
- 自定義ViewGroup，需要復(fù)寫onLayout完成子View位置的確定等工作。
View的測量-onMeasure
View的測量最終是在onMeasure方法中通過setMeasuredDimension把代表寬高兩個MeasureSpec設(shè)置給View，因此需要掌握MeasureSpec。MeasureSpec包括大小信息以及模式信息。
MeasureSpec的三種模式：
- EXACTLY模式：精確模式，對應(yīng)于用戶指定為match_parent或者具體大小的時候（實際上指定為match_parent實質(zhì)上是指定大小為父容器的大小）
- AT_MOST模式：對應(yīng)于用戶指定為wrap_content，此時控件尺寸只要不超過父控件允許的***尺寸即可。
- UNSPECIFIED模式：不指定大小的測量模式，這種模式比較少用
下面給出模板代碼：
- public class MeasureUtils {
- /**
- * 用于View的測量
- *
- * @param measureSpec
- * @param defaultSize
- * @return
- */
- public static int measureView(int measureSpec, int defaultSize) {
- int measureSize;
- //獲取用戶指定的大小以及模式
- int mode = View.MeasureSpec.getMode(measureSpec);
- int size = View.MeasureSpec.getSize(measureSpec);
- //根據(jù)模式去返回大小
- if (mode == View.MeasureSpec.EXACTLY) {
- //精確模式（指定大小以及match_parent）直接返回指定的大小
- measureSize = size;
- } else {
- //UNSPECIFIED模式、AT_MOST模式（wrap_content）的話需要提供默認(rèn)的大小
- measureSize = defaultSize;
- if (mode == View.MeasureSpec.AT_MOST) {
- //AT_MOST（wrap_content）模式下，需要取測量值與默認(rèn)值的最小值
- measureSize = Math.min(measureSize, defaultSize);
- }
- }
- return measureSize;
- }
- }
***，復(fù)寫onMeasure方法，把super方法去掉：
- @Override
- protected void onMeasure(int widthMeasureSpec, int heightMeasureSpec) {
- setMeasuredDimension(MeasureUtils.measureView(widthMeasureSpec, 200),
- MeasureUtils.measureView(heightMeasureSpec, 200)
- );
- }
View的繪制-onDraw
View繪制，需要掌握Android中View的坐標(biāo)體系：
View的坐標(biāo)體系是以左上角為坐標(biāo)原點，向右為X軸正方向，向下為Y軸正方向。
View繪制，主要是通過Android的2D繪圖機制來完成，時機是onDraw方法中，其中包括畫布Canvas，畫筆Paint。下面給出示例代碼。相關(guān)API不是介紹的重點，重點是Canvas的save和restore方法，通過save以后可以對畫布進(jìn)行一些放大縮小旋轉(zhuǎn)傾斜等操作，這兩個方法一般配套使用，其中save的調(diào)用次數(shù)可以多于restore。
- @Override
- protected void onDraw(Canvas canvas) {
- super.onDraw(canvas);
- Bitmap bitmap = ImageUtils.drawable2Bitmap(mDrawable);
- canvas.drawBitmap(bitmap, getLeft(), getTop(), mPaint);
- canvas.save();
- //注意，這里的旋轉(zhuǎn)是指畫布的旋轉(zhuǎn)
- canvas.rotate(90);
- mPaint.setColor(Color.parseColor("#FF4081"));
- mPaint.setTextSize(30);
- canvas.drawText("測試", 100, -100, mPaint);
- canvas.restore();
- }
View的位置-onLayout
與布局位置相關(guān)的是onLayout方法的復(fù)寫，一般我們自定義View的時候，只需要完成測量，繪制即可。如果是自定義ViewGroup的話，需要做的就是在onLayout中測量自身以及控制子控件的布局位置，onLayout是自定義ViewGroup必須實現(xiàn)的方法。
8、性能優(yōu)化
布局優(yōu)化
1. 使用include標(biāo)簽，通過layout屬性復(fù)用相同的布局。
- <include
- android:id="@+id/v_test"
- layout="@layout/include_view" />
2. 使用merge標(biāo)簽，去除同類的視圖
3. 使用ViewStub來進(jìn)行布局的延遲加載一些不是馬上就用到的布局。例如列表頁中，列表在沒有拿到數(shù)據(jù)之前不加載，這樣做可以使UI變得流暢。
- <ViewStub
- android:id="@+id/v_stub"
- android:layout_width="match_parent"
- android:layout_height="wrap_content"
- android:layout="@layout/view_stub" />
- //需要手動調(diào)用inflate方法，布局才會顯示出來。
- stub.inflate();
- //其中setVisibility在底層也是會調(diào)用inflate方法
- //stub.setVisibility(View.VISIBLE);
- //之后，如果要使用ViewStub標(biāo)簽里面的View，只需要按照平常來即可。
- TextView tv_1 = (TextView) findViewById(R.id.tv_1);
4. 盡量多使用RelativeLayout，因為這樣可以大大減少視圖的層級。
內(nèi)存優(yōu)化
APP設(shè)計以及代碼編寫階段都應(yīng)該考慮內(nèi)存優(yōu)化：
1. 珍惜Service，盡量使得Service在使用的時候才處于運行狀態(tài)。盡量使用IntentService
IntentService在內(nèi)部其實是通過線程以及Handler實現(xiàn)的，當(dāng)有新的Intent到來的時候，會創(chuàng)建線程并且處理這個Intent，處理完畢以后就自動銷毀自身。因此使用IntentService能夠節(jié)省系統(tǒng)資源。
2. 內(nèi)存緊張的時候釋放資源（例如UI隱藏的時候釋放資源等）。復(fù)寫Activity的回調(diào)方法。
- @Override
- public void onLowMemory() {
- super.onLowMemory();
- }
- @Override
- public void onTrimMemory(int level) {
- super.onTrimMemory(level);
- switch (level) {
- case TRIM_MEMORY_COMPLETE:
- //...
- break;
- case 其他:
- }
- }
3. 通過Manifest中對Application配置更大的內(nèi)存，但是一般不推薦
- android:largeHeap="true"
4. 避免Bitmap的浪費，應(yīng)該盡量去適配屏幕設(shè)備。盡量使用成熟的圖片加載框架，Picasso，F(xiàn)resco，Glide等。
5. 使用優(yōu)化的容器，SparseArray等
6. 其他建議：盡量少用枚舉變量，盡量少用抽象，盡量少增加類，避免使用依賴注入框架，謹(jǐn)慎使用library，使用代碼混淆，時當(dāng)場合考慮使用多進(jìn)程等。
7. 避免內(nèi)存泄漏（本來應(yīng)該被回收的對象沒有被回收）。一旦APP的內(nèi)存短時間內(nèi)快速增長或者GC非常頻繁的時候，就應(yīng)該考慮是否是內(nèi)存泄漏導(dǎo)致的。
分析方法
1. 使用Android Studio提供的Android Monitors中Memory工具查看內(nèi)存的使用以及沒使用的情況。
2. 使用DDMS提供的Heap工具查看內(nèi)存使用情況，也可以手動觸發(fā)GC。
3. 使用性能分析的依賴庫，例如Square的LeakCanary，這個庫會在內(nèi)存泄漏的前后通過Notification通知你。
什么情況會導(dǎo)致內(nèi)存泄漏
1. 資源釋放問題：程序代碼的問題，長期保持某些資源，如Context、Cursor、IO 流的引用，資源得不到釋放造成內(nèi)存泄露。
2. 對象內(nèi)存過大問題：保存了多個耗用內(nèi)存過大的對象（如Bitmap、XML 文件），造成內(nèi)存超出限制。
3. static 關(guān)鍵字的使用問題：static 是Java 中的一個關(guān)鍵字，當(dāng)用它來修飾成員變量時，那么該變量就屬于該類，而不是該類的實例。所以用static 修飾的變量，它的生命周期是很長的，如果用它來引用一些資源耗費過多的實例（Context 的情況最多），這時就要謹(jǐn)慎對待了。
解決方案
1. 應(yīng)該盡量避免static 成員變量引用資源耗費過多的實例，比如Context。
2. Context 盡量使用ApplicationContext，因為Application 的Context 的生命周期比較長，引用它不會出現(xiàn)內(nèi)存泄露的問題。
3. 使用WeakReference 代替強引用。比如可以使用WeakReference<Context> mContextRef
4. 線程導(dǎo)致內(nèi)存溢出：線程產(chǎn)生內(nèi)存泄露的主要原因在于線程生命周期的不可控。例如Activity中的Thread在run了，但是Activity由于某種原因重新創(chuàng)建了，但是Thread仍然會運行，因為run方法不結(jié)束的話Thread是不會銷毀的。
解決方案
1. 將線程的內(nèi)部類，改為靜態(tài)內(nèi)部類（因為非靜態(tài)內(nèi)部類擁有外部類對象的強引用，而靜態(tài)類則不擁有）。
2. 在線程內(nèi)部采用弱引用保存Context 引用。
查看內(nèi)存泄漏的方法、工具
- android官方提供的工具：Memory Monitor（當(dāng)APP占用的內(nèi)存在短時間內(nèi)快速增長或者GC變得頻繁的時候）、DDMS提供的Heap工具（手動觸發(fā)GC）
- Square提供的內(nèi)存泄漏檢測工具，LeakCanary（能夠自動完成內(nèi)存追蹤、檢測、輸出結(jié)果），進(jìn)行演示，并且適當(dāng)?shù)慕庹f。
性能優(yōu)化
- 防止過度繪制，通過打開手機的“顯示過度繪制區(qū)域”即可查看過度繪制的情況。
- 最小化渲染時間，使用視圖樹查看節(jié)點，對節(jié)點進(jìn)行性能分析。
- 通過TraceView進(jìn)行數(shù)據(jù)的采集以及分析。在有大概定位的時候，使用Android官方提供的Debug類進(jìn)行采集。***通過DDMS即可打開這個.trace文件，分析函數(shù)的調(diào)用情況（包括在指定情況下執(zhí)行時間，調(diào)用次數(shù)）
- //開啟數(shù)據(jù)采集
- Debug.startMethodTracing("test.trace");
- //關(guān)閉
- Debug.stopMethodTracing();
OOM
避免OOM的一些常見方法：
1. App資源中盡量少用大圖。使用Bitmap的時候要注意等比例縮小圖片，并且注意Bitmap的回收。
- BitmapFactory.Options options = new BitmapFactory.Option();
- options.inSampleSize = 2;
- //Options 只保存圖片尺寸大小，不保存圖片到內(nèi)存
- BitmapFactory.Options opts = new BitmapFactory.Options();
- opts.inSampleSize = 2;
- Bitmap bmp = null;
- bmp = BitmapFactory.decodeResource(getResources(),
- mImageIds[position],opts);
- //回收
- bmp.recycle();
2. 結(jié)合組件的生命周期，釋放資源
3. IO流，數(shù)據(jù)庫查詢的游標(biāo)等應(yīng)該在使用完之后及時關(guān)閉。
4. ListView中應(yīng)該使用ViewHolder模式緩存ConverView
5. 頁面切換的時候盡量去傳遞（復(fù)用）一些對象
ANR
不同的組件發(fā)生ANR 的時間不一樣，主線程（Activity、Service）是5 秒，BroadCastReceiver 是10 秒。
ANR一般有三種類型：
1. KeyDispatchTimeout(5 seconds)
主要類型按鍵或觸摸事件在特定時間內(nèi)無響應(yīng)
2. BroadcastTimeout(10 seconds)
BroadcastReceiver在特定時間內(nèi)無法處理完成
3. ServiceTimeout(20 seconds)
小概率類型Service在特定的時間內(nèi)無法處理完成
解決方案：
1. UI線程只進(jìn)行UI相關(guān)的操作。所有耗時操作，比如訪問網(wǎng)絡(luò)，Socket 通信，查詢大量SQL 語句，復(fù)雜邏輯計算等都放在子線程中去，然后通過handler.sendMessage、runonUITread、AsyncTask 等方式更新UI。
2. 無論如何都要確保用戶界面操作的流暢度。如果耗時操作需要讓用戶等待，那么可以在界面上顯示進(jìn)度條。
3. BroadCastReceiver要進(jìn)行復(fù)雜操作的的時候，可以在onReceive()方法中啟動一個Service來處理。
9、九切圖（.9圖）、SVG圖片
九切圖
點九圖，是Android開發(fā)中用到的一種特殊格式的圖片，文件名以”.9.png“結(jié)尾。這種圖片能告訴程序，圖像哪一部分可以被拉升，哪一部分不能被拉升需要保持原有比列。運用點九圖可以保證圖片在不模糊變形的前提下做到自適應(yīng)。點九圖常用于對話框背景圖片中。
- 1、2部分規(guī)定了圖像的可拉伸部分,當(dāng)實際程序中設(shè)定了對話框的寬高時，1、2部分就會被拉伸成所需要的高和寬，呈現(xiàn)出于設(shè)計稿一樣的視覺效果。
- 而3、4部分規(guī)定了圖像的內(nèi)容區(qū)域。內(nèi)容區(qū)域規(guī)定了可編輯區(qū)域，例如文字需要被包裹在其內(nèi)。
android5.0的SCG矢量動畫機制
- 圖像在方法縮小的時候圖片質(zhì)量不會有損失
- 使用XML來定義圖形
- 適配不同分辨率
10、Android中數(shù)據(jù)常見存儲方式
- 文件（包括XML、SharePreference等）
- 數(shù)據(jù)庫
- Content Provider
- 保存在網(wǎng)絡(luò)
11、進(jìn)程間通信
- 操作系統(tǒng)進(jìn)程間通信的方法，android中有哪些？
- 操作系統(tǒng)：
- Windows：剪貼板、管道、郵槽等
- Linux：命名管道、共享內(nèi)存、信號量
Android中的進(jìn)程通信方式并不是完全繼承于Linux：
- Bundle
- 文件共享
- AIDL
- Messenger
- Content Provider
- Socket
12、常見的網(wǎng)絡(luò)框架
常用的http框架以及他們的特點
- HttpURLConnection:在Android 2.2版本之前，HttpClient擁有較少的bug，因此使用它是***的選擇。而在Android 2.3版本及以后，HttpURLConnection則是***的選擇。它的API簡單，體積較小，因而非常適用于Android項目。壓縮和緩存機制可以有效地減少網(wǎng)絡(luò)訪問的流量，在提升速度和省電方面也起到了較大的作用。對于新的應(yīng)用程序應(yīng)該更加偏向于使用HttpURLConnection，因為在以后的工作當(dāng)中我們也會將更多的時間放在優(yōu)化HttpURLConnection上面。特點：比較輕便，靈活，易于擴展，在3.0后以及4.0中都進(jìn)行了改善，如對HTTPS的支持，在4.0中，還增加了對緩存的支持。
- HttpClient：高效穩(wěn)定，但是維護(hù)成本高昂，故android 開發(fā)團隊不愿意在維護(hù)該庫而是轉(zhuǎn)投更為輕便的
- okHttp：okhttp 是一個 Java 的 HTTP+SPDY 客戶端開發(fā)包，同時也支持 Android。需要Android 2.3以上。特點：OKHttp是Android版Http客戶端。非常高效，支持SPDY、連接池、GZIP和 HTTP 緩存。默認(rèn)情況下，OKHttp會自動處理常見的網(wǎng)絡(luò)問題，像二次連接、SSL的握手問題。如果你的應(yīng)用程序中集成了OKHttp，Retrofit默認(rèn)會使用OKHttp處理其他網(wǎng)絡(luò)層請求。從Android4.4開始HttpURLConnection的底層實現(xiàn)采用的是okHttp。
- volley：早期使用HttpClient，后來使用HttpURLConnection，是谷歌2013年推出的網(wǎng)絡(luò)請求框架，非常適合去進(jìn)行數(shù)據(jù)量不大，但通信頻繁的網(wǎng)絡(luò)操作，而對于大數(shù)據(jù)量的網(wǎng)絡(luò)操作，比如說下載文件等，Volley的表現(xiàn)就會非常糟糕。
- xutils：緩存網(wǎng)絡(luò)請求數(shù)據(jù)
- Retrofit：和Volley框架的請求方式很相似，底層網(wǎng)絡(luò)請求采用okhttp（效率高，android4.4底層采用okhttp），采用注解方式來指定請求方式和url地址，減少了代碼量。
- AsyncTask
13、常用的圖片加載框架以及特點、源碼
- Picasso：PicassoSquare的網(wǎng)絡(luò)庫一起能發(fā)揮***作用，因為Picasso可以選擇將網(wǎng)絡(luò)請求的緩存部分交給了okhttp實現(xiàn)。
- Glide：模仿了Picasso的API，而且在他的基礎(chǔ)上加了很多的擴展(比如gif等支持)，支持圖片流，因此在做愛拍之類的視頻應(yīng)用用得比較多一些。
- Fresco：Fresco中設(shè)計有一個叫做image pipeline的模塊。它負(fù)責(zé)從網(wǎng)絡(luò)，從本地文件系統(tǒng)，本地資源加載圖片。 為了***限度節(jié)省空間和CPU時間，它含有3級緩存設(shè)計（2級內(nèi)存，1級文件）。Fresco中設(shè)計有一個叫做Drawees模塊， 方便地顯示loading圖，當(dāng)圖片不再顯示在屏幕上時，及時地釋放內(nèi)存和空間占用。
Fresco是把圖片緩存放在了Ashmem（系統(tǒng)匿名內(nèi)存共享區(qū)）
- Heap-堆內(nèi)存：Android中每個App的 Java堆內(nèi)存大小都是被嚴(yán)格的限制的。每個對象都是使用Java的new在堆內(nèi)存實例化，這是內(nèi)存中相對安全的一塊區(qū)域。內(nèi)存有垃圾回收機制，所以當(dāng) App不在使用內(nèi)存的時候，系統(tǒng)就會自動把這塊內(nèi)存回收。不幸的是，內(nèi)存進(jìn)行垃圾回收的過程正是問題所在。當(dāng)內(nèi)存進(jìn)行垃圾回收時，內(nèi)存不僅僅進(jìn)行了垃圾回收，還把 Android 應(yīng)用完全終止了。這也是用戶在使用 App 時最常見的卡頓或短暫假死的原因之一。
- Ashmem：Android 在操作 Ashmem 堆時，會把該堆中存有數(shù)據(jù)的內(nèi)存區(qū)域從 Ashmem 堆中抽取出來，而不是把它釋放掉，這是一種弱內(nèi)存釋放模式；被抽取出來的這部分內(nèi)存只有當(dāng)系統(tǒng)真正需要更多的內(nèi)存時（系統(tǒng)內(nèi)存不夠用）才會被釋放。當(dāng) Android 把被抽取出來的這部分內(nèi)存放回 Ashmem 堆，只要被抽取的內(nèi)存空間沒有被釋放，之前的數(shù)據(jù)就會恢復(fù)到相應(yīng)的位置。
不管發(fā)生什么，垃圾回收器都不會自動回收這些 Bitmap。當(dāng) Android 繪制系統(tǒng)在渲染這些圖片，Android 的系統(tǒng)庫就會把這些 Bitmap 從 Ashmem 堆中抽取出來，而當(dāng)渲染結(jié)束后，這些 Bitmap 又會被放回到原來的位置。如果一個被抽取的圖片需要再繪制一次，系統(tǒng)僅僅需要把它再解碼一次，這個操作非常迅速。
14、在Android開發(fā)里用什么做線程間的通訊工具？
傳統(tǒng)點的方法就是往同步代碼塊里些數(shù)據(jù)，然后使用回調(diào)讓另外一條線程去讀。在Android里我一般會創(chuàng)建Looper線程，然后Hanlder傳遞消息。
1***ndroid新特性相關(guān)
- 5.0：Material Design、多種設(shè)備的支持、支持64位ART虛擬機、Project Volta電池續(xù)航改進(jìn)計劃等
- 6.0：動態(tài)權(quán)限管理、過度動畫、支付、指紋等
- 7.0：分屏、通知消息快捷回復(fù)、夜間模式、流量保護(hù)模式等
16、網(wǎng)絡(luò)請求優(yōu)化
網(wǎng)絡(luò)請求優(yōu)化
- 能夠緩存起來的盡量去緩存起來，減輕服務(wù)器的壓力。例如APP中首頁的一些數(shù)據(jù)，又例如首頁的圖標(biāo)、文案都是緩存起來的，而且這些數(shù)據(jù)通過網(wǎng)絡(luò)來指定可以使app具有更大的靈活性。
- 不用域名，用 IP 直連，省去了DNS域名解析。
- 連接復(fù)用、請求合并、請求數(shù)據(jù)Body可以利用壓縮算法Gzip來進(jìn)行壓縮，使用JSON 代替 XML
網(wǎng)絡(luò)請求的安全性
這塊了解的不多。我給你說說我的思路吧，利用哈希算法，比如MD5，服務(wù)器給我們的數(shù)據(jù)可以通過時間戳和其他參數(shù)做個加密，得到一個key，在客戶端取出數(shù)據(jù)后根據(jù)數(shù)據(jù)和時間戳再去生成key與服務(wù)端給的做個對比。
17、新技術(shù)相關(guān)
RXJava：一個異步請求庫，核心就是異步。利用的是一種擴展的觀察模式，被觀察者發(fā)生某種變化的時候，可以通過事件（onNext、onError、onComplete）等方式通過觀察者。RXJava同時支持線程的調(diào)度和切換，用戶可以指定訂閱發(fā)生的線程以及觀察者觸發(fā)的線程。
Retrofit：通過注解的方式來指定URL、請求方法，實質(zhì)上底層是通過OKHttp來實現(xiàn)的。
