栗子現場直播 千篇一栗
有很多簡單的道理,若不是被遺忘,不是察覺不到,就是知易行難。

2010年3月30日 星期二

Random RGB 技術討論

  1.0: jni
  由於 Android 內建的隨機數產生器完全是 Java code ,因此很慢。在 Nexus One 製造全畫面亂數,差不多要花 100ms 。
  但如果把這些功夫都利用 ndk 在 native 做,就會快很多。不過我沒認真計過,但至少快數十倍沒錯。

  1.0: synchronize
  system event 有時是會同時出現的。我之前試過在 emu 跑沒有 sync 的 Random RGB ,結果在跳入跳出畫面時,就出現大堆 Error 。好好把程序 sync 過後就沒問題了。

  1.5: ods to xml
  因為 i18n 要管理的字太多太煩,所以我就翻起很久以前的 Code Template 來用。
  http://github.com/luzi82/CodeTemplate
  這東東原理如何,我遲些才說。總之結果是,我可以很簡單用 OpenOffice ods 把 i18n 管理好。

  1.5: auto version
  Eclipse 不會自動 compile 你的 native C code ,那要手動完成。另外 Eclipse 不是每次都會自動把最新的 native lib 放入 apk,那需要手動的檢查。但如果只是一些很細微的修改,要檢查 apk 有沒有使用最新的 native lib 是很困難的。因此我在 native lib 上加了自動更新的 version ID ,在 About 中顯示,方便檢查。

  1.5.2: Timer drop
  在 Timer.scheduleAtFixedRate ,如果把 peroid 設定為 100ms ,它真的會儘量在一秒中做 10 次。如果 CPU 不夠快,它會把未完成的 loop 次數記下來。如果 CPU 每秒只能做 8 次,它每一秒都會把未完成的 loop counter 加 2 。Android會設法把未完成的 loop 次數完成,這個不好。
  幸好有 TimerTask.scheduledExecutionTime ,和現在的時間比較後就可以知道那個 loop 延遲了多少,和大約估計未完成的 loop 的積累情況。現在的做法是,如果某個 loop 延遲了 10ms ,就直接 return 了事,這樣就可以減少 loop 的積累。

  1.5.2: Engine.isVisiable()
  根據觀察,如果離開 Live Wallpaper , isVisiable 會先 return false ,然後 onVisibilityChanged 才會被發動。如果 redraw loop 要在 onVisibilityChanged 後才被關閉,那就可能會出現在 isVisiable=false 時也都進入 redraw loop 的情況。因此每次 redraw 都要先檢查 isVisiable 。

沒有留言: