fuchsia test build...

ref: https://fuchsia.googlesource.com/manifest/+/master/README.md

因為還在初期的開發過程，所以每天 builod 的狀況可能會不一樣。

在 debian jessie 上 build.
一開始 go language 得的版本有問題。
缺了 UnsetEvn 和 StringCompare 這兩個 function
jessie 是 1.3, 測試 1.4 還是不夠，最後用 1.5 才 OK

go 環境很簡單，就 到 go 網站 download 安裝包，解開，follow READE 設定 GOROOT path 和 update PATH 就可以呼叫到正確的 go 版本。
然後繼續 follow 說明...

出現 native_viewport 不認識 MX_DISPLAY_FORMAT_RGB_565
發現是新版本的 display.h 變更了 constant 的名子，改叫 MX_PIXEL_FORMAT_RGB_565. 所以全部修改。

---

上面好像是 user program.
下面這個好像才是 OS.... https://fuchsia.googlesource.com/magenta/+/HEAD/docs/getting_started.md

fragement

fragement 可以視為 view 元件的一個擴展。
在 layout 的 xml 中可以擺放 fragment 元件。
然後再為 fragment 元件寫 layout, action handler

所以可以視為 "可以自訂內容的 view 元件"

既然是由 programmer 自己寫的元件，所以在 layout 中擺放時，fragment 區段就有一些規定，
像 name 就是實做那個 fragment 的 full class name

fragment 的 life cycle 跟一般 activity 有點類似。
也有自己的 layout

所以主要的 activity 把 自己的 layout view (包含 fragment的layout xml) 設定完畢後。
android 系統自然會知道 layout 內容，一一呼叫起對應的 fragment class

android application profiling with Android Device Monitor

tools -- android -- android device monitor

Device tab 會列出所有正在 run 的 process
選一下要 monitor 的 process
按下device tab 上的一個有紅點的 icon (Start Method Profiling)
出現 "Profiling Options"
選 Trace base profiling -- 因為想知道是那一個 function 花時間。
按下去以後，就開始 monitor 了，所以要趕快去操作 app,
花時間的部份都操作完後，案一下 device tab 剛剛那個變成黑點的紅點 icon (stop method profiling)

device tab 右邊會出現 ddmsXXXXXXX 的 profiling 結果。

上面是時間條，下面是 function 的顏色和總共花的時間。
找一個長的按下去就會繼續看該 function 裡面花的匙間，
然後找出時間最長的...
repeat...

• incl Cpu Time(%): Include caller & self
• Excl Cpu Time(%):
• Incl Real Time：
• Excl Real Time：
• Calls + Recur Calls / Total：function执行的次数，Call表示function call的次数，Recur Call表示recursive call 的次數
• Cpu Time / Call：每次执行函数所用的cpu time。
• Real Time / Call： 同上

systrace 好像更強

implicit declaration of function 'strict_strtoul

3.x 的 driver code 拿到 4.x build 出現..

 error: implicit declaration of function 'strict_strtoul' [-Werror=implicit-function-declaration]

然後kernel source 竟然找不到 strict_strtoul

然後..http://dpdk.org/dev/patchwork/patch/1911/

strict_strtoul() was just a redefinition of kstrtoul() for a long
time. From kernel version of 3.18, strict_strtoul() will not be
defined at all. A compile time kernel version check is needed to
decide which function or macro can be used for a specific version
of kernel.

也就說..直接用 kstrtoul 就好了。