接觸android接近一個月，摸爬滾打實屬不易，加上又有諸多瑣事纏身，讓原本定下的計劃遲遲沒有完成。。

   對於基礎知識的急於求成，處於一種有一些功利化的學習心態，所以適時的複習顯得空前重要。。

  談談對安卓的理解，不論對錯，只對自己的理解做一些記錄：

    安卓於2006年左右就有這個想法貌似，後來在2008年的時候，安卓1.0問世（2008年發生的事情特別多），同時期釋出的移動作業系統還有ios，windowsphone。   之後勢如破竹，記得我2012年買了一個觸屏智慧手機，當時的安卓版本貌似是2.3來著。。。現如今，安卓已經到了8了。。   其實有幾個版本老是分不清，如android sdk版本，好像也叫做api版本，android 版本，avd版本等等。。   與之類似的還有  gradle的版本，以及gradle plugin的版本。。。  傻傻分不清楚。

    然後來說一下安卓開發，較早一兩年前，我那時候一直在用eclipse做實踐，曾經就用它來弄了弄安卓，照著網上的例子敲了敲一個計算器，但是由於當時零基礎所以並沒有社麼用。  不過配置的過程我是經過的，比如配置sdk，下一些eclipse的外掛，等等，當時覺得是十分的痛苦，現在則覺得十分繁瑣，而且由於牆的關係，不能得到很好的支援。   現在用的是idea的整合開發環境，並且2015年還是什麼時候吧，官方推薦使用的是 android sdk,是基於idea 的。   不得不說，確實方便了很多。   只需要取下載這個軟體，無腦下一步安裝。。 當然一些前提條件還是要有的，比如java環境，後續還需要gradle的支援，很多時候也離不開git。  總之不需要自己去配sdk,不需要自己去下一些整合環境的外掛，非常的爽快！    

   有利也有弊，利自然就是開發環境準備起來方便很多。  弊就是對開發的步驟反而陌生了，比如哪個模組負責什麼任務之類的。  舉個簡單例子，當連真機除錯的時候可能會出現一些莫名奇妙的問題，這時候就需要這些知識了。   希望每個人使用的時候都是完美的就好了。   在開發過程中，用到的依賴主要有：  sdk中的原始碼，它的構成類似於java，為開發提供先覺條件；   jdk中的lang包中的類或者介面，提供一些開發的基礎支援，因為android開發時基於java的。    整合環境下，對資原始檔的編譯引用，這個是整合環境做的，跟使用者沒有太大關係，但是又是必須的。  現在看來，它非常優美的實現了低耦合。。 

   程式寫完後，需要進行編譯。   java都要編譯為位元組碼，所以android自然也需要進行編譯。。   它的編譯是用過整合環境下的gradle外掛完成的。   gradle外掛的編譯應該是利用了第三方的編譯工具，因為maven編譯的時候也是依賴了第三方的編譯工具，它們是等價的。。   編譯完成後，形成的整個程式大小是很小的，也就是說，sdk(上百兆),jdk的一些相關類等 並沒有一股腦的被使用，它們提供的是一種生態。。      就像java編碼後一樣，他要到其他的地方執行，那麼宿主環境下必須具備jvm虛擬機器才行。   android是同樣的道理。。    

   所以在我們執行程式時候，有兩個途徑可選:   android虛擬機器，或者  真機。。。     虛擬機器和真機中提供了相應的宿主環境，我們安裝的程式安裝的只是針對於宿主適用的一小段應用程式。。     不得不說android虛擬機器太佔記憶體了，我有次除錯直接宕機，因為我本身電腦記憶體不是很大。  越高版本的虛擬機器越耗費記憶體。。     從另一個層面而言，真機中其實也是一個虛擬機器在執行程式碼，只是物理載體不一樣。。

   看java程式的時候，我們習慣於每次去尋找main函式所在的類，也就是預設的入口類。。   

   而在看android專案原始碼的時候，則應該從androidManifest.xml檔案入口，去找具有 MAIN動作的意圖過濾器，它所在的activity便是這個程式的入口。。   AndroidManifest.xml相當於android應用程式  與系統的通道。。。    它本身不算是原始碼，但是卻充當了這樣一個角色。。  找到了入口，接下來的事情則是順利成章的。    在我看的阿里雲播放器的例子中，使用了一個專案，多個模組的構成方式，所以gradle的使用也是需要專門去了解的，很強大，很優秀。

   由於android的出現時間，決定了它不論從設計模式方面，還是程式結構構成方面，都有顯著的優越性。。  android的開發大致可以分為兩個部分吧，檢視層，邏輯業務層。   它們二者會通過某種方式繫結，以達到業務目的。。   並且，它的是檢視實際方面是與物件關係呈現的，只要感興趣，就可以追到最底層的實現，同時經過這麼多版本的迭代，已經非常完善，使用方式也是比較固定的。  可以高定製化，也是它的巨大優勢，同時將之與業務邏輯分開，有利於解耦。。  

   android在開發的時候，大量用到了監聽器，回撥等等可以很好解耦的方式，使用起來也很方便，設計起來也很暢快。。所以它是更好的面向應用的開發方式我覺得。。

   android的基礎知識中，經常聽說四大元件，六大布局，五大儲存。。  我也去看過了一些，不過暫時還沒有。。  我想記錄的是自己平時遇到幾個類：

   activity:   代表一個視覺化檢視，代表螢幕的一屏。  具有自己的生命週期。  這些所有的生命週期方法就像具有很多的入口，通過系統的系統中斷呼叫應該是。。   每個activity 都要經過  oncreate()方法，通常要與檢視層繫結。

   Fragement，代表某一個部分檢視，通過onCreateView()初始化，也具有相應的生命週期。

   ViewGroup，繼承自View,子類有那幾個佈局。   它們是通過例項化方法來初始化的，就代表一個檢視。。 跟activity等有些區別。  不具備顯著的生命週期方法。  此外需要注意，可以自定義view,並且可以在view中就定義好一些初始化的事件，資料的繫結等等操作。。。

  Dialog，對話方塊，通過例項化方法呼叫，通過回撥方法關閉。。

===============================================================================================

   要記得理解基本就這麼多了。  接下來記一下阿里雲的這個視訊demo。因為隔兩天我又會忘了，又得花時間去重新看一遍。。

它的流程是這樣的：

    進入引導頁-》進入功能頁--->所有的卡片都具有點選事件-->點選後跳到相應的activity。   在這個過程中，從伺服器中請求一些測試資料.  對每個卡片的又相應的點選事件。  若點選房間，可以觀看直播，若點選直播，可以直播。。   這裡想說的是關於攝像頭的渲染。。   攝像頭的渲染都是通過父類完成的，子類完成的是相應的功能外觀的實現。。。   這個過程中，用到了很多的監聽器機制，另外這個專案是沒有對視訊進行推流處理的。。    大體的功能就這些，直播的功能也就這些。   基礎不夠直接上這個真是夠吃力的，希望過一段時間有所進展與突破。。