layout: post title: 2016 04 25 信息系統實踐手記6 JS調用Flex的性能問題一例 key: 20160425 tags: GIS JS FLEX 技術選型 性能 API 調用 modify_date: 2016 04 25 信息系統實踐手記6 JS調用Flex的性能問 ...
layout: post
title: 2016-04-25-信息系統實踐手記6-JS調用Flex的性能問題一例
key: 20160425
tags: GIS JS FLEX 技術選型 性能 API 調用
modify_date: 2016-04-25
---
信息系統實踐手記6-JS調用Flex的性能問題一例
說明：
正文：
- 信息系統實踐手記系列是系筆者在平時研發中先後遇到的大小的問題，其中比較典型的內容加以收集和分享。
- 信息系統實踐手記目錄：博客園(或查看源碼的README.MD文件)
摘要：
- 此文描述了JS和FLEX（Flash）交互的一些經驗總結。
正文
在筆者實踐中，遇到有些情況下（比如開發地圖應用），客戶端的JS代碼往往要調用地圖引擎的API。
地圖引擎的API，有些是JS介面，那最方便，有些是FLEX編程介面的API（運行在Flash里），JS調用Flex性能有如下經驗。
比如客戶端是基於地圖的應用，用JS代碼調用FLEX的API介面，需要通過FLEX的語句在地圖上呈現（放置）2萬個對象（Object）。
- 方法A(較低效)：
- 在JS中，通過業務層得到N萬個設備的信息數據，諸如數組DEV[N0000]；
- 在JS中，將信息數據打包為hashmap(key -> value)；
- 在JS中，將hashmap數據結構從JS傳入Flex： JS --> Flex;
- 在Flex中，獲得傳入的hashmap結構，並迴圈顯示在GIS地圖上；
- 在Flex中，通過hashmap結構提供用key查value的服務：val = devicehashmap.get（key）；
- 性能評估&分析：
- 在步驟2，3，4中消耗了20秒左右，數據量是2萬個device；主要是步驟3較慢；
- 初步估計，JS中組成hashmap結構需要花費一定時間，但不多；可惜這種高級結構對JS/Flex兩側是個負擔，傳入的時候需要做必要的檢查和轉換，所以比較慢；
另外，考慮到JS/Flex相互調用結構比較複雜，如果傳遞高級結構，兩側系統容易在解析上不一致而會引起額外的開銷；
（備註：其實還嘗試過方法A的變種，就是在JS這裡啟動迴圈2萬次，每次將一條設備信息傳遞給Flex併在GIS地圖上顯示Object，雖然每次數據量極小，但是來回調用JS/Flex2萬次，效率更低下，所以也捨棄了，這裡就不再討論了）- 方法B（較好）：
- 在JS中，通過業務層得到N萬個設備的信息數據，諸如數組DEV[N0000]；
- 在JS中，將信息數據打包為長字元串String（帶約定結構/類似JSON）；
- 在JS中，將String從JS傳入Flex： JS --> Flex;
- 在Flex中，獲得傳入String，並解析還原為hashmap，並迴圈顯示在GIS地圖上；
- 在Flex中，通過hashmap結構提供用key查value的服務：val = devicehashmap.get（key）；
- 性能評估&分析：
- 在步驟3中消耗了1秒左右（其實是500ms左右），數據量是2萬個device；
- 初步估計，經典的數據結構String，在大多數系統中都能很好的互操作，並獲得最簡單的支持和解析（比如大都是bytes位元組數組，最後一個是標記，或者有一個小小的優雅的頭結構等等），所以傳遞String極大的降低了時間開銷。而對JS側，拼接String比組裝hashmap更快些；在Flex側，自己解析String組裝自己的haspmap（不是理解JS的hashmap結構）也很快。
總體上步驟1到5消耗在1秒左右，達到要求；
（備註：其實在嘗試幾種其他GIS引擎的時候，我們採用JS/API介面，就沒有遇到如上的問題，這其實對技術選型是很重要的。）
總結：
很多時候，開發一個系統，實現了A和B的互相調用和操作，只是達成而已。更多情況下實際應用場景必然有數據壓力和性能要求，而一旦上了性能，“可用”就不夠了，還要考慮“可行”；
從眾多的方法中找到切實可行的，才是最終目的。這其實要求對各種方法的理解和比對有深入的研究。但時間有限，經驗有限，人力有限，所以只能做代價有限的嘗試，並不斷優化，這可能也是迭代開發或敏捷開發比較提倡的吧。
性能優化我在之前的篇幅已經粗略的談到，只要有性能瓶頸，只要未達到物理（理論）可計算的性能邊界，就能找到合適的方法來優化。
另外，技術選型也很重要，對於目前我們接觸的幾個GIS引擎，支持JSAPI的都未出現類似問題，而非JS的API介面就需要做額外的研究，嘗試和優化。這對技術選型也是一個值得思考的例子。
