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的性能問題一例

說明：

• 本文發佈於: gitee,github,博客園
• 轉載和引用請指明原做者和鏈接及出處.

正文：

• 信息系統實踐手記系列是系筆者在平時研發中前後遇到的大小的問題，其中比較典型的內容加以收集和分享。
• 信息系統實踐手記目錄：博客園(或查看源碼的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接口就須要作額外的研究，嘗試和優化。這對技術選型也是一個值得思考的例子。

END