跨平臺移動應用開發之 Flex 的崛起

此文章由 周戈 (DarkStone) 原創, 發表日期 2013-08-19, 轉載請註明來源:

微博: http://weibo.com/dstech

博客: http://blog.sina.com.cn/dstech

QQ羣: 23477140

 

歡迎各位 ActionScript 同仁的大駕光臨, 我今天發佈的消息很是振奮人心, 爲此我這幾天很是亢奮,熱血沸騰.

 

開始前我先問你們兩個問題:

一個好的遊戲能被玩多久? 幾個月或者一年已經打破天了.

一個好的應用能被用多久? 幾年或者十幾年也很常見.

 

不適合閱讀本文的讀者: 打算用 AS3 開發 2D/3D 遊戲的相關人員.

AS3 開發移動平臺遊戲目前我仍是推薦用:

Starling + Feathers UI + Firefly + Away3D

所以若是你是這個範圍的人, 就不用浪費時間繼續閱讀下去了.

 

適合閱讀本文的讀者對象: 打算用 AS3 開發除遊戲之外跨平臺跨設備應用的相關人員.

 

對於那些懶得看徹底文的人, 這是個人一句話中心思想:

Flex 技術從如今開始從新崛起, 成爲跨平臺跨設備最高開發效率, 最易後期維護, 最佳的應用開發解決方案, Flex 開發者身價將從新暴增.

 

我本次演講主要分3部分:

1.    重大發現: Flex 4.10 + AIR 3.8 在 iOS 和 Mac 平臺的執行效率已接近 PC!

2.    爲何 Flex 是跨平臺跨設備的最佳應用開發解決方案?

3.    新手如何使用Flex, 以及開發移動應用要注意的問題.

 

1.   重大發現: Flex 4.10 + AIR 3.8 在 iOS 和 Mac 平臺的執行效率已接近 PC!

 

通過我在 iPhone 4, iPhone 5, iPad 3 和 Retina MacBook Pro 的親自實測, 我很高興的向你們宣佈:Flex 4.10 + AIR 3.8 在 iOS 和 Mac 平臺的執行效率已經接近 PC, 達到了一個里程碑的層次!

 

在 iPhone 4, iPad 之前(也就是 2010 年之前), PC 仍是主流的時候, Flex 是 PC 平臺最高效率的應用開發組件框架.

 

但在 iPhone 4, iPad 出現以後, Flex 雖然能夠在上面運行, 但執行效率很低, 跑起來很是卡, 後來Adobe 把 Flex 捐獻給開源社區 Apache 來維護, 因而 Flex 技術從它的巔峯時代直接滑落至谷底.

 

然而就在 Flex 開發者面臨窘境, 進退兩難的時候, 驚喜終於出現了! 最新的 Flex 4.10 + AIR 3.8 通過我這2天的實測, 性能從根本上獲得了提高, 即使是在 iPhone 4 這樣低配單核的機器上也能較流暢地運行, 在 iPhone 4S, iPhone 5 和 iPad 3 上運行則很是流暢.

 

我將咱們自行開發的產品作成 demo, 就在今天上午, 我當着全部同事的面, 演示了咱們的產品在Windows, Mac, iPhone 4, iPhone 5, iPad 3 上的運行效果, 你們一致認爲很理想, 徹底適用於產品級開發!

 

2.   爲何 Flex 是跨平臺跨設備的最佳應用開發解決方案?

 

首先, 選擇跨平臺的技術, 能夠極大提升產品開發效率, 下降維護成本, 這塊的好處你們都知道, 那麼目前主流的跨平臺技術, 我爲你們分析下利弊.

 

先來看HTML5 + JS +CSS3 + SVG (如下簡稱H5):

 

將來的 Web (瀏覽器領域)屬於H5, 而Flash Player 這樣的瀏覽器插件正在走向滅亡, 好比在移動設備的瀏覽器上 Flash Player 就已經死了.

 

雖然 H5 會統治整個 Web, 但咱們如今回頭看看整個IT市場:

 

◇ 現在PC已經不是主流設備.

◇ 現在的主流設備是移動設備, 好比智能手機, 平板電腦, 還有智能腕錶和智能眼鏡等.

 

那麼, 在 PC 時代已經衰落接近底谷的今天, 咱們做爲開發者, 重點應該放在長遠, 更有活力, 更有前景的移動平臺.

 

咱們就談談如今主流的移動平臺:

 

◇ 在移動設備上 B/S 架構的 Web 瀏覽器應用不是主流, 也成不了主流.

 

◇ 在移動設備上 C/S 架構的本地應用纔是主流, 你們可在移動平臺的應用商店下載和購買不少本地應用和遊戲, 但沒有人會去瀏覽器裏購買網頁的應用.

 

所以核心點在於咱們須要一門跨平臺跨設備而且適合開發本地應用的技術, 顯然 H5 徹底不適合擔當這個角色, 緣由:

 

◇ 第一, HTML5 + JS 這些語言沒有考慮本地應用的需求, 它們原生的 API 沒法直接調用各個平臺私有的功能, 好比 iOS 的 GameCenter, iCloud, Push Notification, Passbook 等等, 這會致使你想作的不少需求沒法輕易作出來. 而這個問題從長遠來說也不大可能獲得解決, 由於若是 H5 能夠隨意調用系統的私有 API, 那麼整個互聯網將更不安全, 如今的網頁病毒已經夠多了, 試想若是用戶進一個網頁, 網頁有權限把用戶的文件資料所有刪除, 那是什麼概念).

◇ 第二, JS 1.x 不是面向對象的腳本語言, 用於團隊開發大型項目就是個噩夢, JS 2.0 雖然會徹底面向對象, 但也遲遲沒有要發佈的消息.

◇ 第三, H5 的開發調試得在N個不一樣廠商的瀏覽器上分別測試, 瀏覽器廠商對 H5 標準的實現各自有所不一樣, 這個一直是 Web 開發人員至關頭疼的問題.

 

那麼到底哪門技術纔是跨平臺跨設備的最佳應用開發解決方案呢?

 

之前的答案是: 尚未(由於之前 Flex 在移動平臺執行效率很低).

如今的答案是: Flex! Flex! Flex!

 

之前在移動平臺上 AIR 虛擬機對 ARM 芯片和 iOS 系統的優化程度作得不好, 致使其 CPU 執行效率很低, 因而誕生了 Starling, Feathers UI, Firefly 等這類第三方基於 GPU 執行的框架來解決 AIR在移動設備上的性能問題.

 

但從 AIR 3.8 起, AIR 虛擬機對移動平臺 CPU 的執行效率, 相比之前我看到了天與地的區別. 若是你還在爲本身是一個 AS3 開發者感到迷茫, 甚至有些人以爲要轉行, 以爲沒搞頭, 那麼在 AIR 3.8 之前確實如此, 但如今這個格局已經完全改變了.

 

如今仔細談談 Flex 的組成: AS3 + MXML + CSS + FXG

 

◇ AS3 用於編寫邏輯層 (開發人員負責)
優點: 強類型面嚮對象語言, 利於團隊開發.

◇ MXML 用於設計皮膚層 (設計人員負責)
優點: 快速佈局應用皮膚, 強大的數據雙向綁定, 面向體驗的語法設計, 高級皮膚狀態綁定, 高度的可擴展性, 衆多的內置組件可用, 可迅速搭建應用程序原型.

◇ CSS 用於編寫樣式表 (設計人員負責)
優點: 在統一的地方管理全部界面的樣式屬性, 利於高效率的維護界面樣式, 高效率的切換整套界面皮膚.

◇ FXG 用於可複用的矢量素材 (設計人員負責)
優點: 用 XML 語言來描述矢量圖形, 具備高度的可讀性, FXG 可直接放在 MXML 裏當作標籤使用, 具備極其強大的可複用性和可擴展性.

 

Flex 的 MXML 相似 xHTML.
Flex 的 CSS 相似 Web 網頁的 CSS.
Flex 的 FXG 相似 Web 網頁的 SVG.

所以除了 AS3 自己比較專業之外, 其它環節相對容易, 徹底能夠培訓設計人員來分工.

除此之外, Flex 的重要特性還有:

 

◇ 內置大量桌面和移動平臺的經常使用組件, 好比 Button, CheckBox, Panel, ViewNavigator, SpinnerList 等等.

◇ 組件的 邏輯層 和 皮膚層 徹底分離, 這樣開發人員可來寫邏輯, 同時設計人員去作皮膚, 工做效率不言而喻.

◇ 一個 Flex 應用可同時部署到 Windows, Mac, Linux, iOS, Android 全平臺上, 還能部署到桌面系統的瀏覽器裏. 若是須要調用系統私有 API 則可以使用 ANE 作本地擴展(很是強大)!

◇ 用 Flex 部署的應用, 可根據目標設備屏幕的 dpi 自動縮放自身界面的元素大小以達到最佳效果,只須要將矢量素材作成 FXG, 在一個屏幕下完成正確的佈局, 就可實如今其它 dpi 屏幕下的界面自動縮放, 而不用爲了避免同 dpi 的屏幕來製做不一樣尺寸的相同素材.

 

好, 給點時間你們先提問, 還有一個代碼環節我將放在後面.

 

Q&A:

 

Q: MXML 寫組件皮膚? MXML有計劃瘦身嗎?

A: MXML 的優化關鍵在於編譯器, 全部的 MXML 都是由編譯器轉換爲 AS3 的類文件, 編譯器轉換過程當中的算法很重要, 它將決定 MXML 到 AS3 的代碼量和性能, 這一塊目前已經作得比較好了, 從編譯速度來看, 較之前有必定的提高, 間接能夠感受到編譯器的改進.

 

Q: 如今有幾個設計人員管你這些... 我遇到的設計基本上就是給你作個 UI 圖而後就交給你了.

A: 那是大家公司分工和培訓有問題. 我先後帶過3個團隊, 都是培訓美工寫 MXML 和 CSS 還有FXG 的, 培訓成本並不大, 邊作邊學2周左右就會了.

 

Q: 素材在 Flex 裏是如何管理的, 須要爲不一樣 dpi導出不一樣尺寸的相同素材文件嗎?

A: 我來談談關於素材這一塊的問題:

一旦你開始作移動應用, 你面臨的將是不一樣目標設備, 不一樣屏幕的 DPI 像素密度, 若是你的目標屏幕有 160 dpi, 264 dpi, 326 dpi, 480 dpi 等, 那麼你要是用 Photoshop 作的話, 一樣的一個小圖標, 你就得爲這些 dpi 導出不一樣尺寸的版本.

 

那麼, 通常的項目都會有上百個素材, 假設有100個圖標, 你就要導400個文件出來, 這樣的開發成本過高了, 效率過低了.

 

而若是你們把能用 Flash / AI 作的素材, 轉成並優化成 FXG 格式, 再放到 Flash Builder 裏面, 就能夠在 MXML 裏當作一個標籤來使用, 複用性極強, 每一個 FXG 其實就是一個 Class 類, 類的複用性強你們都知道吧.

 

而後, 在 Flex 裏, 有 applicationDPI 能夠設置(不過目前 RuntimeDPIProvider 有個小 bug), 用它就能夠爲不一樣的 dpi 自動縮放整個界面的元素:

換句話說, 假設你作了100個圖標素材, 你只須要把這100個圖標素材作成 FXG 格式, 而後佈局到你的 MXML 裏, 接下來正確設置你的 applicationDPI 和 runtimeDPIProvider, 你就能夠不用再改代碼,不用再改素材尺寸的狀況下, 支持全部不一樣分辨率, 不一樣 DPI 的設備, 僅這一點, 工做效率已是最高的了!

 

我今天上午給公司內部看的 demo 就是典型的例子:

咱們在 PC 上設計整個應用的界面, 用 FXG MXML 佈局, 這些界面和素材都是在 160 dpi 的屏幕上作好的, 而我輕易就把這個應用移植到了 264 dpi 的 iPad 3 上, 和 326 dpi 的 iPhone 4 / iPhone 5上, 還移植到了 220 dpi 的 Retina MacBook Pro 上, 而且效果都很完美, 徹底沒有失真.

 

Q: 界面被放大後會不會模糊?

A: 注意, 這樣放大後, 徹底不會模糊, 由於:

只要全部素材都是用 Flash / Ai 作出來的矢量圖, 矢量圖放大縮小是不會失真的, 將其轉成 FXG 以後, FXG也是矢量的, 更易於複用和維護. 其實放大後的 UI 在視網膜屏幕上反而更加清晰透徹, 看着很舒服.

 

Q: 問題來了, 矢量圖是已知的 CPU 殺手, 若是應用中不使用位圖, 請問爲何不少項目都須要導出位圖來改善渲染性能? 用 PS 導出位圖的目的就是爲了避免使用矢量圖.

A: 這也是我代碼要講的, 矢量圖能夠動態緩存成位圖來解決性能問題的, 等下我會仔細講的.

若是你用 PS 導出位圖, 那麼你就要爲不一樣 dpi 導出不一樣尺寸的位圖.

 

若是你用 FXG, 它自己是矢量的, 高可讀性的, 1個素材只用導出1個FXG, 而後 Flex 根據設備屏幕的dpi 動態放大全部矢量 FXG, 以保證清晰, 不失真, 同時, 你可利用 DisplayObject.cacheAsBitmap = true 將須要頻繁位移的顯示對象進行動態緩存, 將矢量圖緩存成標量圖, 從而必定程度上提升性能, 注意這個方法不能濫用, 濫用反而會致使性能降低.

 

Q: 請問cacheAsBitmap能提高多少性能? 我在byteArray.org上看到性能很低, cacheAsBitmap在Adobe官方工程師的測試, 會卡到 8 FPS.

A: cacheAsBitmap這玩藝不能瞎用, 要善用, 後面我會仔細講的. 何況 byteArray.org 上的測試是在 2008 年作的, 用的 playerglobal.swc 也是很舊的版原本編譯的, 還有測試環境是 Flash Player而不是 AIR 3.8.

 

Q: 我想知道您是怎麼測試的, 能把測試代碼公佈下嗎?

A: 我如今手上有的 demo, 是本身公司正在開發的產品, 不方便泄露, 但我有空能夠開發一個能證實我今天所說的一切的 demo, 到時候會提供安裝版的下載.

 

3.   新手如何使用Flex, 以及開發移動應用要注意的問題.

 

好, 接下來先手把手教你們怎麼搭建 Flex 4.10 + AIR 3.8 + Flash Builder 4.7 的開發環境.

先請你們收藏 Apache Flex 官方網站 http://flex.apache.org/.

去這個頁面把 Flex 4.10 的安裝器下載下來, 安裝到你的機器上http://flex.apache.org/installer.html

 

安裝好後運行 Apache Flex SDK Installer, 看到這個畫面, 不用修改, 直接 NEXT.

 

這時在你的 Flash Builder 安裝目錄的 sdks 目錄裏新建一個叫 4.10.0 的文件夾.

 

在 Flex SDK Installer 裏點 BROWSE 選中剛纔建立的 4.10.0 目錄, 以下圖所示, 點 NEXT.

接着選中全部的選項, 每項都有用的, 而後點 INSTALL.

 

等這個進度條所有走完之後, 會跳到下一個界面告訴你已完成, 屆時可關閉 Flex SDK Installer.

 

去這裏下載並安裝 Flash Player 最新的 Debugger 調試版
http://www.adobe.com/support/flashplayer/downloads.html

去這裏下載並安裝最新的 AIR 虛擬機
http://get.adobe.com/air/

關閉全部瀏覽器, 安裝好 Flash Player Debugger 和 AIR.

而後打開 Flash Builder 4.7, 進入菜單的 Windows -> Preferences -> Flash Builder -> Installed Flex SDKs, 點 Add... 將剛纔下好的 4.10.0 的目錄添加進去, SDK 的名字改成 Flex 4.10.0, 而後打上鉤,便可設爲默認SDK, 如圖所示:
而後點 Apply 和 OK.
 

接下來, 對於那些 Flash Builder 裏已有的 Flex 4 的項目, 對其點右鍵選 Properties, 檢查 Flex Compiler, 看是否是用的默認的 SDK, 顯示爲 Flex 4.10.0, 如圖所示.

若是發現是對的, 就可關掉這個窗口了.

 

若是你是 AIR 的項目, 進入到你的 -app.xml 配置文件.

將根標籤的命名空間改成 3.8

接下來, 找到 <renderMode> 標籤, 反註釋它, 而後設置爲
<renderMode>direct</renderMode>

注意, 這是最重要的地方, AIR 3.8 在 direct 渲染模式下, 大大優化了在 Mac 系統和 iOS 系統的性能, 大大提升了針對 CPU 的執行效率!

可是, AIR 3.7 和 3.6 還有之前的版本, 即使設置爲 direct 也沒有顯著性能的提高, 只能提高 GPU 的性能, 徹底沒有提高 CPU 的性能.

 

換句話說, 到了 AIR 3.8, <renderMode>direct</renderMode> 才真正作到了對 CPU 執行效率的巨大優化.

 

Q&A:

 

Q: 在 Windows 上面沒有優化?

A: 在 Windows 上, AIR 開不開 direct 渲染模式, CPＵ 的執行效率都很快, 沒有太大的區別.

 

反註釋 <requestedDisplayResolution> 標籤, 並將其設置爲
<requestedDisplayResolution>high</requestedDisplayResolution>

目前它僅對 Mac 系統的 Retina 顯示屏機器(例如: Retina MacBook Pro)有效, 當你開發 Mac 系統的本地應用, 你只須要把 requestedDisplayResolution 標籤設置爲 high, 應用運行時 AIR 會自動將 UI 界面用 4 個物理像素顯示１個邏輯像素, 意思是你的物理分辨率可能已是 2880x1800了, 但你的 AIR 程序的 API 告訴你, 你邏輯寬高仍是 1440x900. 獲得的結果就是, 在無需更改你界面任何代碼和矢量素材的狀況下, 完美支持視網膜屏幕!

 

這裏我再解釋下 <requestedDisplayResolution> 這個標籤, 即使你的目標機器不是視網膜屏幕(也就是 dpi <= 160), 那麼你將 requestedDisplayResolution 設置爲 high 也不會有任何影響, 它不會在標清屏幕上放大你的 UI 界面的.

 

requestedDisplayResolution 對 iOS, Android 程序無效, iOS, Android 上只能經過設置 Flex Application 標籤的 applicationDPI 和 runtimeDPIProvider 來縮放 UI.

 

那麼, 新項目該怎樣作呢, 新項目要作的操做跟上面的徹底同樣, 只不過 Flash Builder 4.7 有個 bug會致使新建 Flex 4.10.0 項目的時候, 編譯會出現問題, 我講下:

新建的 Flex 4.10 項目, 進入主 Application 的 MXML 以後, 要將根標籤的 layout="absolute" 屬性刪除掉, 不然不能經過編譯, 這是 Flash Builder 4.7 的已知 bug
你們新建項目時必定要記住這點.

 

Q: 物理像素和邏輯像素的區別, AIR 程序用 4 個物理像素顯示１個邏輯像素是什麼意思?

A: 物理像素就是顯示器實際的顯像管色點, 好比 15 寸 Retina MacBook Pro 的物理分辨率是2880x1800, 即物理水平像素數量是 2880 個, 物理垂直像素數量是 1800 個.

 

邏輯像素就是應用程序內部"自認爲"的虛擬像素, 它的尺寸不必定等於物理像素的尺寸.

用４個物理像素呈現１個邏輯像素, 至關於 1440x900 的邏輯像素, 水平和垂直像素各自擴大2倍, 獲得 2880x1800 的物理像素.

 

如今談談代碼優化這一塊, 如何善用 DisplayObject.cacheAsBitmap = true;

什麼地方該用它, 我建議你們要注意如下幾點:

1. 不要在大尺寸的顯示對象上用, 何爲大尺寸, 在標清屏幕上, 超過 500x500 的顯示對象最好不要用, 用了可能會更卡, 由於太吃內存.

 

2. 不要在內部有子顯示對象, 且子對象會頻繁變化座標和尺寸的顯示對象上用, 用了容易崩潰, 由於虛擬機要不停爲父顯示對象生成不一樣的緩存圖像, 多了容易內存溢出.

 

3. 全部上了濾鏡 filters 的顯示對象, 已經默認強行開啓了緩存, 而且沒法關閉這個緩存, 設不設置DisplayObject.cacheAsBitmap = true 都無所謂.

 

4. 在仔細審視過前３個要點以後, 若是能夠知足如下兩個條件, 就推薦用:

 

◇ 顯示對象尺寸較小, 而且可能會常常變化它自己(而不是內部子對象)的座標.

◇ 該顯示對象裏有複雜的內容, 好比文字, 圖片, 按鈕, FXG等等.

 

總之, 記住以上要點, 千萬不要處處寫 cacheAsBitmap = true 這樣的代碼, 那樣反而會很卡甚至崩潰.

 

Q: DisplayObject.cacheAsBitmap = true 是讓虛擬機來生成位圖緩存吧, 能否本身寫程序來生成？

A: 能夠, 但不推薦在 Flex 裏這樣作. 有人可能會以爲, 用 BitmapData.draw() 來手動生成矢量圖的緩存會更好一些, 確實從性能上這個比 cacheAsBitmap 要好, 但這樣作之後你的顯示對象就變成了一個位圖, 沒有了交互性.

 

好比你把一個含有按鈕的面板用 BitmapData.draw() 給緩存成位圖了, 用戶再點這個面板裏的按鈕就會沒有反應, 由於這個面板已經柵格化爲位圖了; 而對於 Flex 這種須要用戶隨時交互的應用來講,顯然是不合適的, 因此 Flex 用 cacheAsBitmap 就夠了, 它會全自動在後臺爲你作矢量圖到位圖的緩存, 而且保留矢量顯示對象的可交互性.

 

 

好了, 還有最後一個要講: applicationDPI 和 runtimeDPIProvider, 這個也是重中之重:

首先, 若是你是 Flex Desktop (桌面) 的 AIR 項目, 不要設置 applicationDPI 和 runtimeDPIProvider這2個屬性!

只須要設置 -app.xml 裏的
<renderMode>direct</renderMode>
<requestedDisplayResolution>high</requestedDisplayResolution>
就能夠了

 

<renderMode>direct</renderMode>這個無論你是什麼項目, 都設置爲 direct 就對了, 不管是Windows, Mac, Linux, iOS 仍是 Android.

而後你的開發所有在標清顯示器上作, 只要你的界面佈局在標清顯示器上是完美的, 那麼最終部署到視網膜屏幕上也會是完美的, 是由於

<requestedDisplayResolution>high</requestedDisplayResolution>

在起做用, 4個物理像素呈現1個邏輯像素還記得吧.

 

如今說移動項目, 若是你是 Flex Mobile (移動) 的 AIR 項目, 那麼
 <requestedDisplayResolution>high</requestedDisplayResolution> 是無效的, 設置它不會幫你放大界面 UI 的尺寸.

對於 Flex Mobile 項目, 咱們要設置的是 Flex Application MXML 裏的 applicationDPI 和runtimeDPIProvider 這2個屬性.

 

首先我講講 Application 類 applicationDPI 和 runtimeDPI 這2個屬性的關係

applicationDPI 指的是該應用程序原生是在什麼 dpi 下開發和測試的.

runtimeDPI 指的是運行環境的 dpi, 注意這個值不許, 它是由 runtimeDPIProvider 折算出來的.

 

Flex UI 的縮放因數 = Application.runtimeDPI / Application.applicationDPI

 

好比說, iPhone 4 實際是 326 dpi, 通過 runtimeDPIProvider 的默認實現類折算後Application.runtimeDPI 是 320 dpi.

 

那麼, Application.applicationDPI 設置爲 160 的話, 在 iPhone ４ 上實際的 UI 縮放比例就是 320/160 = 2 也就是２倍, 這是對的.

 

但 iPad 3 的實際 dpi 是 264, 通過 runtimeDPIProvider 的默認實現類折算後 Application.runtimeDPI是 240, 這就錯了!

 

runtimeDPI = 240 的話, applicationDPI = 160
這樣的話 UI 縮放就成了 1.5 倍而不是2倍, 界面佈局就會錯亂!

 

解決辦法很簡單, 咱們寫一個類, 假設其完整的包名類名是 com.test.CorrectRuntimeDPIProvider, 讓它繼承 mx.core.RuntimeDPIProvider 類, 並覆蓋
public function get runtimeDPI():Number 方法

 

咱們根據須要本身寫折算的算法, 主要從 flash.system.Capabilities 這個類提供的各項屬性裏獲取當前設備的真實信息, 好比可獲取當前設備是什麼操做系統, 什麼廠商, 設備名稱, 真實的屏幕物理dpi 等等, 而後本身根據須要正確實現折算的算法, 通常只要保證最終返回的 runtimeDPI 除以applicationDPI 後等於2就對了.

 

官方的折算算法是很弱智的, 在 iPad 3 這種 264 物理 dpi 的設備上會返回 240 的 runtimeDPI, 正確應該返回 320 以保證 320/160 = 2.

 

咱們應該棄用官方 classifyDPI() 方法的實現和對它的調用, 本身正確實現
public function get runtimeDPI():Number
這個方法

 

實現完成後, 在主 <s:Application> 標籤上面加上這樣的代碼就好了:
applicationDPI="160" runtimeDPIProvider="com.test.CorrectRuntimeDPIProvider" frameRate="30"

 

作 Flex Mobile 的 AIR 項目, 必定要注意這些點:

◇ 全部的開發和設計工做, 最好所有放在標清顯示器上作! 也就是代碼的編寫和素材的設計, 所有在標清屏幕上作.

◇ 全部的設計, 儘可能作矢量素材, 導出 FXG 並優化(FXG 的優化方法在這裏就不說了, 之後有空專門寫個博文教你們怎樣優化, 注意 FXG 代碼若是不優化的話, 直接使用會很不正常), 再放入 Flash Builder 裏, 在 MXML 裏引用 FXG 當作標籤使用.

◇ 全部的界面佈局, 以在標清顯示器下達到你想要的效果爲準.

◇ <s:Application> 標籤的 applicationDPI 永遠設置爲 160, 意思是當前應用是在標清屏幕上開發的.

◇ <s:Application> 標籤的 runtimeDPIProvider 應該設置爲一個你本身寫的類, 由於官方自帶的實現類太弱智, 不少狀況沒有考慮到位(官方之後可能會改進).

 

 

最後附上我整理的 AS3 和 Flex 官方教程和開發工具的連接:

 

學習使用 ActionScript 3.0
網頁版: http://help.adobe.com/zh_CN/as3/learn/
PDF版: http://help.adobe.com/zh_CN/as3/learn/as3_learning.pdf
(這是 AS3 語言的基本語法教程, 內容很少, 建議一口氣讀完)

ActionScript 3.0 開發人員指南
網頁版: http://help.adobe.com/zh_CN/as3/dev/
PDF版: http://help.adobe.com/zh_CN/as3/dev/as3_devguide.pdf
(這是教你 AS3 中各種 API 的使用, 內容不少, 注意不要全看! 目前只看 使用字符串 | 使用數組 | 使用 XML | 處理事件 | 顯示編程 這些最經常使用的內容, 其它的暫時不用看)

Flex 官方視頻教程
http://www.adobe.com/cn/devnet/flex/videotraining.html
(視頻內容是全英文的, 但很容易聽懂, 不過它裏面講的不少東西, 都不是解決問題的最佳方式, 所以,不要被這個視頻裏的內容先入爲主了, 只揀本身感興趣的視頻看下就能夠了)

Flex 開發 PC 應用教程
網頁版: http://help.adobe.com/en_US/flex/using/
PDF版: http://help.adobe.com/en_US/flex/using/flex_4.6_help.pdf
(這個教程只有英文版的, 而且內容很是多, 隨便看看就好了)

Flex 開發移動應用教程
網頁版: http://help.adobe.com/zh_CN/flex/mobileapps/
PDF版: http://help.adobe.com/zh_CN/flex/mobileapps/developing_mobile_apps_flex_4.6.pdf
(這個教程目前也是隨便看看便可)

AIR 開發本機擴展
網頁版: http://help.adobe.com/zh_CN/air/extensions/
PDF版: http://help.adobe.com/zh_CN/air/extensions/air_extensions.pdf
(利用 本機擴展, 就可以讓 Flex/Flash 的 AIR 應用程序調用各個平臺的獨立 API, 如調用 iOS 的iCloud, GameCenter 等, 此教程有興趣就看)

ActionScript 3.0 語言參考
http://help.adobe.com/zh_CN/FlashPlatform/reference/actionscript/3/
(這是 AS3 全部 API 的語言參考, 這個內容很是龐大, 更不用全看了, 你只用在學上面的教程時, 在這個地址查詢你感興趣的 接口和類的語言參考便可)

Apache Flex 語言參考
http://flex.apache.org/asdoc/
(這是 Apache Flex 最新的全部 API 語言參考, 只包含跟 Flex 有關的 API, 很是有用)

Flash Builder 開發工具下載
https://creative.adobe.com/products/flash-builder

Flash Player Debugger & PlayerGlobal 下載
http://www.adobe.com/support/flashplayer/downloads.html

AIR 虛擬機下載
http://get.adobe.com/air/

Apache Flex SDK Installer 下載
http://flex.apache.org/installer.html

如何成爲 Apache Flex 開源社區的一員, 參與到 Flex 將來版本的發展中
http://flex.apache.org/community-getinvolved.html

 

從如今起 Flex 將從新崛起, 由於它已是最佳的全平臺應用開發解決方案!