2. 抽象類別將所有複雜的溝通細節處理掉，使得ap的class撰寫變的單純許多。
3.母類別會有預設函數的實作，若子類別打算overrided該預設函數則當外部呼叫到該函數會優先呼叫子類別的實作的預設函數。
4. 在JMain類別中: Employee linda = new SalesSecretary("Linda Fan","Female")
5. EX3_01中的Person類別為一個抽象類別(Display()內容從缺)，相較之下Employee為一個具體類別，可以用來new出新的物件。
6. 4月26日從高老師第一本書第3章開始學習，第3章的內容可以先保留到熟悉android程式設計架構後再來review。
7. public abstract class Shape implement IGraph{ ... } 代表什麼意義？
8. 4月27日由4.2節開始研讀。
9. OnClickListener listener = new OnClickListener() { public void onClick(){...}}，為實作listener物件的OnClick 方法。
10. 4月28日由4.5節開始研讀。
11. 編譯kernel時，DMATEK LCD 480X272 FOR ET043002DH6 ---45pin/40pin 是否有差異?
12. Android系統燒寫過程： (1)燒寫u-boot (2)燒寫kernel (3)燒寫Android 檔案系統 (ramdisk-uboot.img、system.img、userdata.img)
13. 4月30日高老師的教材(Android編程36計)研讀先停在第四章。
14. android user space process 發現硬體not ready時，framework會去polling硬體，若硬體持續在not ready狀態下時，會將執行權交給其他的process，應此當實做不符合framework架構的process(使用blocking I/O)會讓framework狀況出現異常。
15. 每個AP均為一個物件對kernel而言為一個thread與一般standalone的AP為獨立的Process有所不同(猜測)。
16. 在android driver實作上，須減少使用system call而要多使用 sysfs 或 proc來存取driver (announces by Google)
17. 上層的java應用程式透過JNI與底層.so(c/c++ module)的sharelibrary做溝通。
18. 如何加入driver至android system(錄音檔1 45分)。
19. ../framework/base/core/java/ <= 對應上層java層(包含許多framework的類別)，當內建的class無法存取硬體時，可以擴充framework加入新的class進來讓別人來繼承使用。
20. ../framework/basr/core/jni/ <= 對應底層HAL層。
21. HAL Stub的工作往上符合HAL介面，往下去做與driver的溝通工作(open、read、write...)。
22. AP無法直接與Stub溝通，而是需要透過虛擬機，虛擬機往下會接到.so程式庫 => 需要修改jni目錄下的程式碼使so檔能夠與Stub做溝通。
23. android framework把driver整合的非常好 (相對於Qt)。
24. android porting 並非像過去的linux方式，只單純修改kernel即可(因為沒有整合driver與kernel的framework所以只需整理好BSP即可)。
25. android framework整合了特定的driver，去做porting，就不單純只是把kernel與BSP修改好而已，需要再考慮框架本身。
26. Android framework須考量3個層面； (1)driver是否需要用到android features (2)架構端的移植(Dalvik虛擬機負責執行procedure call 1.5Ver之後開始支持x86、armv4、armv5+、mips、coretex) (3)建立產品分支，預設為generic(反映框架只能擴充而不要去修改)。
27. 3份checklist: (1)driver (2)DalvikVM (3)product branch。
28. Porting技術面: (1)API相容(新的API在舊的框架上run) (2)產品分支 (3)框架修改 (4)Kernel的設定。
29. kernel可以分為vanilla與non-vanilla 版本。
30. 鼓勵將自己的driver移出做成patch在整合進vanilla kernel不須浪費時間去mantain自己的kernel。
31. 在Android下ap可以決定哪些部份需要做省電 <= 透過wavelock 提供的API在應用層進行操作。
32. Google提供Binder driver來做IPC的工作。
33. 應用層呼叫getSystemService()來存取硬體，由框架去new一個Service物件(物件的生成由框架負責，減少Ap的大小 <=> Java SE)。
34. 當框架去new一個object時，VM會去產生一個process，例如: 想畫圖，VM會去生成一個Surface的Process去抓到framebuffer的driver，同時框架也會生成一個Surface物件。
35. android share memory並非在兩個process之間換資料，而是
36. Activity(相當於main為ap的進入點)負責畫UI與處理使用者的輸入。
37. android ap 會被包裝成apk檔，執行起來每個apk檔對應一個Process(不管有多個activity)而其中會有activity的thread與Surface的thread，因此交換資料是在同一個apk檔中。
38. logcat 是負責產生訊息給console的driver，SDK Tools adb也可以讀取console 訊息。
39. PMEM為存取硬體的萬用解決方案，可以不必撰寫複雜的driver，只需查詢該硬體的I/O Memory 交由PMEM將所有的I/O Memory mapping到user space，ap只需透過HAL Stub 來存取硬體。
40. 傳統的driver寫作由於沒有PMEM的支持，必須寫很多Memory存取的程式。
41. logger.c是將自己註冊給misc，但misc依然使用了register_chrdev()，logger是間接透過misc與系統做註冊。
42. misc裡面堆放雜項的driver，假若driver不屬於usb、i2c、pci..等既有的類別，將該driver放置於misc中。
43. 分層註冊的目的在於避免數以萬計不同類型的driver向系統註冊。
44. logger.c中的排成機制實作需多研讀其架構。
45. program counter有可能會落在user space 或 kernel space。
46. adb daemon會透過socket讀取logger.c傳送的訊息。
47. 研讀sysfs與linux 2.6 kernel & driver 的關係(平田豐 p.401)。
48. linux kernel 2.6 將ioctl分做 : (1). unlocked_ioctl (2).compat_ioctl。
49. 大部分的embedded system均無swap partition所以沒有swap out 的現象，可以直接存取記憶體位址。
50. sleep_on的作用: (1).把process放置waitqueue節點 (2)將節點放入waitqueue (3)修改process狀態 (4)呼叫排程器。
51. 當宣告wait queue 於私有資料結構時，實作read / write system call遇到blocking狀態時，需自行手動進行排程，而不能呼叫sleep_on()。
52. 先open()再fork()一個child process()，此時兩個process會共用一個struct file 所以必須留意可重複進入的問題，ex: logger.c :190行與209行。
53. logger.c中的mutex與pthread programing中的mutex為相同的東西。
54. 下午2的錄音倒數20分鐘須反覆聆聽以了解當使用者點選icon啟動應用程式，所伴隨框架內部的行為模式！
55. zygote啟動 -> 執行VM -> 註冊 jni Table ->使用者按下icon -> 框架啟動activity -> activity 呼叫getSystemService() 去new xxxManager -> Manager會去new Service -> Service透過jni介面去存取底層的so檔(driver) -> 完成硬體存取的準備工作！
沒有留言:
張貼留言