[AC]新・三國志大戰(暫)場測小感

一決定場測的日期之後，就開始瘋狂尋找LCC的票價。還好找得到來回6600全包的價格，衝動購票之下就成行了。
決定搭樂桃的原因：
.價格。
.20：55起飛，所以下班之後再衝到機場還來得及。
.05：55回程，多請個一小時假就可以無縫上班。
.還沒去過羽田機場。而且聽說免稅店開24小時。

到機場之後一下飛機的感覺：冷！(抖) 忘記查東京氣溫了，一件短袖就直接殺過去有點設想不周。
購買02：00到秋葉原的夜行巴士門票前往秋葉原。

處理住宿，購買排隊必需品，吃個飯，到sega秋葉原門前看，
已經有三個人在排隊了Orz... 凌晨4點耶...

然後就在寒風中發抖了4小時。排了一小時受不了想衝去買外套的時候，想起唐吉軻德只開到05：00...
沒救，萬念俱灰的狀況下，感謝旁邊的排隊隊友提供毛布，沒凍死在秋葉原。
08：00之後氣溫回升總算是得救了。

sega的staff也很準時的開店門。拿到了4號排隊券。 第一輪！
這時店前已經排了一百二三十人了...聽說4/26稼動的艦娘在場測的時候始發差點玩不到.
這時真心慶幸沒有去旅館休息到開店前，那筆者大概會暈倒在店門口.
都花機票錢特攻了，還沒玩到不就很悲慘嗎...

看到機台，心中再現好久不見的兔躍感。啊啊，大戰回來了。
在上機開始之前，staff會給魏蜀吳三個國家的起始套卡的列表，並詢問要以哪一套遊玩。
因為非常想玩無血開城，而且是唯一有伏兵的套卡，所以選了蜀國。玩完之後需要歸還套卡。
(新做好的卡片可以帶走)

機台的狀況：
主控台多了好幾個按鈕。上下左右確認取消，數字鍵盤... 還可以投錢。該不會可以直接買卡轉蛋抽到爽？
不過場測只會一直播教學動畫所以無法實際操作。

遊玩機台是兩台雙併成D順時針轉90度的圓弧型。上方(遊玩時不可能會去注意的螢幕)有3*2個螢幕。
目前只有顯示君主vs的功能。之後會怎樣不明。
主螢幕是36吋左右的螢幕，比戰國大戰的還要大。
感應的檯面跟戰國應該是同規格，比前作更長更寬，筆者玩的時候覺得卡有點難推到底。
(實際的size都沒有仔細測過所以聽聽就好。)
其他輸入裝置的部分：開始鈕(戰鬥中可以切換觀看將星效果列表)
，計略鎖定鈕(沒錯，計略鎖定鈕獨立出來了。所以筆者一直按錯...)，計略(紅鈕)，寶具開放鈕(藍鈕)
，滾輪，menu，輸出的卡片盒在框體的右下方。黑色的蓋子有點難辨認，有反映給sega rd的staff，建議改色。
因為禁止攝影，框體的圖請看三國志大戰的廣報推特。 
https://twitter.com/taisen_ko_ho


使用的ID卡是Sega專屬的NFC卡:Aime。
筆者第一次使用是Aime，還把卡拿出來碰，顯得有點拙。不過已經感動到無法分心，
只想著把面前的事情做好。
熟練的卡片玩家，是把aime卡放在塑膠卡盒的最後面，只要把卡盒擺在讀取機的上面即可。

Aime只要碰個一秒，等到確認音出現即可收好。也有防竊的效果。
另外也不需要打固定場次就必須買新的IC卡更換。

接著有十秒鐘的時間投錢。這限制跟前作一樣。日版是會有投幣口的開閉限制(只有在君主卡插入的時候可以投錢)，
當時台灣的機器並沒有這樣的限制。所以請先準備好硬幣才不會來不及投幣。
要在Aime辨認之前投幣應該也是可以。 第一場是200日幣，出一張卡片。

下一步：君主名的登錄。 場測版沒有軍師田中吵人起床的流程，（相信正式版應該會有）
直接開始輸入名字。規格跟前作一樣總共可以輸入6個字。
輸入完畢之後會詢問要不要看教學。按紅色鈕的話就進入教學頁。實際的時間我忘記了，好像有300秒可以看。
不過要看完全部的教學動畫可能是不太夠。也許之後會導入前作的訓練關卡。場測反正都是前作的死士...
我只看了新要素的部分：「將星」，「征壓率」，「法具/寶玉選擇」，「法具/寶玉成長」


模式選擇。場測版只能選全國對戰。

接著是登錄武將卡，一樣是90秒的時間。在此時擺放剛取得的套卡。
規格一樣是套卡的總武將cost為8。不過8顆cost的大球旁邊有兩顆小球，猜想可能正式版會有驚喜。
此版取消軍師卡的設計。對前作的軍師設計頗有微詞的玩家有福了。
決定之後開始找對手。場測版目前的設計是有可能會店內也是搜尋對象，所以有可能會出現店內對戰。
此規格不知道會不會確定。


對手決定之後開始佈陣。此時導入「征壓率」的設計。每位武將都有征壓能力的參數，最高為3。
所有武將的數值加起來成為征壓Rank，可以在登陸武將的時候看到。
請參考教學影片：

影片內的規格是合計6以上為A。可能會有S甚至是S+吧？這部分就不細談了。

征壓Rank的差距會影響佈陣範圍。如影片所示。 https://youtu.be/D7tiF0lCwZY?t=63
筆者遇過一場對手超優勢，開場征壓率就已經低到內亂表會開跑，
對手戰線壓在距離我方城前35%的地方...

布陣時一樣柵可以反擺，伏兵可以橫擺，可以擠卡等等... 這時開始發現卡片的出入城判定有點高。
要擺城外，大約要擺到感應盤上面的城內線，距離卡的1/3長的位置才會判定在城外。這部分不知道會不會調整。
因為影響城內出入操作習慣蠻大的。


布陣確定之後，會出現選擇給予武將「將星」的動作。「將星」是新要素。每位武將都有一個將星特技，
三個副將星特技。場測版的出卡狀況看來，每位武將的將星特技可能會不同。副將星特技也有可能會不同。
可能會變成轉蛋轉到爽。
總共可以給三位武將將星特技(大戰的設計是滿cost的牌組至少一定有三張卡，可能是以此規格為考量出發點)。
都是未確定規格。

接著是「法具/寶玉選擇」。有玩過三國志大戰2代的人可以把它想成是兵法+外傳。
先以軌跡球的上下滾動選擇法具，按紅鈕決定之後再上下滾動選擇寶玉。
寶玉外傳可以卡6顆，一次作用只能選擇兩顆(3點鐘方向跟5點鐘方向的兩顆)。
所以遊戲結束之後若是有完成新寶玉的話，寶玉的嵌入位置就要多考量了。


等對手也完成布陣就開戰。這次導入的是棋盤演變為場景的動畫。筆者還蠻喜歡的。一樣請參照公式場測戰鬥規則介紹影片。 

場測版的視點只有全場地俯瞰所以無法用滾輪移動視點。不知道之後會不會有前作的武將視點。
參數的部分就不多提，基本上跟前作差不多。大鐘一樣2.4秒，士氣好像調回4C一顆。
攻城條的速度明顯有變慢，對守方有利。不過我覺得這是為了要因應下面回提到的新要素，
也是筆者認為新作帶來的最大影響：征壓率。

相信有看過戰鬥規則介紹影片的前作君主們，一定會對於戰場略圖上面的紅藍色感到陌生。
這就是雙方的佔領狀態的表示。紅色為我方地盤。只要武將有跑過的地方就會成為佔領地。
假如中了征壓能力下降的妨礙計的話(場測的魏國武將「卞氏」有此技能)，在計略結束前會無法佔領地盤。
整體計算的征壓率在略圖的左下方有個百分比的數字。
地盤是以方塊為單位，所以征壓力只有1的武將在方塊的間隔線的位置移動的話，
佔領效率也可以是兩倍。小技巧...

內亂表開跑的條件可能之後會再調整。目前是低於35%會開跑。
每3C加一格。5格集滿的話會發生內亂，城血損傷約2Cost槍兵城門一擊。
影響不可謂不大。筆者在第一次玩的時候，其中ㄧ場就是被這一擊輸掉...
停止增加的條件是征壓率高於35%，開始減少的條件似乎是超過50%。

這個設計真應了西山P在大評定神戶場上提到的：「每一位武將都很重要。」
有利的條件：

• 人數(3枚/4枚牌組較為不利)
• 移動速度(馬兵塗地圖好用喔)
• 征壓能力(弓兵的征壓能力普遍較強)。
• 長效計略(魏武/蜀吳或是飛天，回復等等舞系)

也大大的影響了戰術。以前的沿地圖邊跑的習慣，現在又多一個可以搶地的好處。
武將不能亂撤退的概念也更加強固，因為一撤退對方就來佔地了。
現在又多一種戰術：只壓戰線不攻城... 宅宅勢力現在得出門應戰了。
可以想見的是減少和局可能，也減少高手對陣常常發生的城壁一擊微差勝負。
筆者相當喜歡這個設計。反過來說宅牌組可能會大量減少。
像前作的6柵反攻，最終兵器。只是這些特殊計略會不會出現在新作也不一定。
有點擔心的是高武/全馬/加速系計略會太有利。這部分就要看要怎麼調整了。
這次玩吳國的君主相信已經感受到了壓力...

另外，城壁跟城門的卡片位置判定也如之前城內判定般的不太一樣，需要重新適應。

戰鬥結束之後，依照輸贏結果會有三個選項：
贏的話可以不出卡續玩第二場。高手們省錢省很大。
另外兩個選項是2個credit續第二局出1張卡，跟3個credit續第二局出2張卡。
基本上除了第一個選項當然是最後一個選項嘍。遊戲卡要是真的照場測版的規格是
綁君主卡不能流通的話，那再多張也不嫌多啊...光是要抽到可用的牌組都是問題了。
個人是覺得應該不會綁定君主卡。要是綁定的話有兩張以上Aime的君主，
在整理卡片的時候就要非常小心。混到的話就慘了... XD
要是真維持這規格的話，SSQ...

遊戲結束之後會提醒出卡的地方，拿出剛印好的卡片，然後遊戲就結束了。
前作在取卡後是會要求接關，
場測版沒有。也是未確定規格。可確定的是卡片是在遊戲進行中印好的。
出卡的盒子，在遊戲中是鎖住的無法打開。也有個感應器感應卡片有沒有被拿走。
會不會有忘記拿的問題就不知道了。

最後來談談卡片的規格。跟前作卡片的規格比較如圖：

新卡較窄跟長。一次控8張卡的時候會比較不會那麼累了。 XD
折卡邊對於感應的影響不明。
筆者兩天共玩了三次，剛好抽到兩張樂進...(手氣背到不行)
可以應證同一位武將的將星跟副將星的特技有可能會不同。
R卡有加閃膜的跟沒有閃膜的，SR也可能沒閃膜？都是未確定規格。
另外，測試版的卡片純粹只能當做紀念，正式版是無法使用的。


離開機台，感動自然是不在話下。採用玩家的建議取消軍師卡，追求簡單操作，
增加戰略深度的征壓系統，
大戰的回歸既然已經確認，接著就是只能祈禱台灣能進。
要不然只好每個月買LCC飛去日本戰...

[PS4]魔女と百騎兵 Revival 雜感，通往白金之路的建議

因為很久沒碰2D參數膨脹遊戲了，偶而會有點想。
試玩了一下體驗版，整個遊戲的流暢度感覺上還不錯於是就買了。

一開始的階段，玩這個遊戲是很辛苦的。
尤其是Gcal這個徒增Loading的體力設計。對於喜歡填地圖的筆者來說根本就是苦行...
至少也要改成離開再進入同一關不用重新Load吧...

商店裡面沒有賣好的武器防具，只能靠敵人掉跟亂數寶箱。
攻擊的部分雖然可以靠技術補救，但是BOSS的防禦力只有在BOSS攻擊的動作時間內會降到打得痛的狀態，所以非得練攻擊閃躲不可。這導致BOSS通常是持久戰，Gcal耗光很正常。
雖然可以爆氣短期決戰(攻防力都乘倍)，但是爆氣的狀態2秒用掉1個gcal，通常一開始就爆氣的話會先把Gcal給耗光，然後不吃麵包就是死。調整戰略就成了課題。

至於武器的種類，直到最終期之前都是近距離災厄系(麻痺效果)觸台無雙。
近距離觸台打一次就是3連擊，加上災厄效果通常只要打兩下敵人就麻痺了。
然後準備一把古塔因應打擊之外無效的敵人即可。

防禦力只能靠等級跟防具補救。初期被Boss瞬殺很正常。
防具裡面的「裝飾」 更是一整個雷到幾乎無用...
直到PS4版的新要素：幻影之塔的鍊成設計的導入，在裡面可以打鍊成用的素材來加武器防具的能力，只靠20%左右的傷害減少，還是常常被瞬殺。

以上的不合理，對於不擅長動作遊戲的人玩真的是要命。
所以在ps4多了一個難度救濟的設計:casual模式。 可是只要切換過難易度之後，要是有存檔的話，該存檔在ending之前都拿不到某個銀獎杯。想拿白金獎盃的話就別切換了...

中期拿到Trick Screamer的Facet(把它想成是一種攻防style跟skill系統)之後，因為敵人在陶醉狀態下掛掉一定會掉寶的設定，成了參數調整遊戲。
攻擊力要調整在打敵人16下不會死，但是又不能不扣HP的範圍內。
打出LE等級的武器防具之後用愚者之石加滿等級就可以去打BOSS這樣的流程持續重複。

到了ending分歧，補完兩個一般end之後，朝最終end進行下去，要是沒啥練功的話會發現敵人的強度爆增(LV69起跳)。
這時建議先打幻影之塔。先以最低難度(獻出武器名的標記是1的武器，可以在塔右邊的商店買到)打完100階之後會出現地下階，這裡才算是幻影之塔真正的開始。

一樣是先給最爛的武器。因為打了還算是會痛，可以先在第一個地圖慢慢敲。
至少經驗值可以加比較快。建議先練Trick Screamer到99級。相信前面靠友愛技能挖寶很兇又愛用觸台的話，等級最高的通常是它。

在練級的過程中，有挖到LE等級的遠擊型觸台的話就留著，然後用打來的加攻擊力的素材
加滿攻擊力。

素材的等級區別：
砂->石->岩->珠。再配上基本的Rank(common/rare/epic/LEgend)。 珠只有在塔等級最強的時候才會掉，一開始先疊加攻擊力的紅砂紅石紅岩系列。有打到一次加兩種的更好。
建議加掉寶率的，減少Gcal消耗，減少體力消耗的都不錯。
只用加攻擊力1000 以上的做為鍊成素材，總之先以攻擊力超過1萬邁進。

有了攻擊力破萬的觸台之後，增加塔的難度到25左右。
再做一隻攻擊力約25000的觸台。


接下來就是直接獻出兩隻LE的Ω標記武器把塔的等級推到最強。(一般Rank的也可以，不過獻LE級的，敵人強度會比較低。)
然後開始挖可以加攻擊力4000以上，防禦力3000以上的紅珠翠珠，開始灌武器防具。

至少準備兩隻攻擊力4萬以上的遠距觸台就可以開始打了。會比較有效率。

以這樣的狀態開始攻略的話，筆者的攻略速度是每小時可以打10階(約50張地圖)。要打100階拿到金獎盃還是要花10小時... 其實相當煩人。

在途中還可以邊攻略邊做一隻最強觸台。做法如下：

• 鍊成回數留下1。前面8次 使用「LE焰之輝珠」疊加，第9次使用濃縮マナ珠，接下來一直用打來的LE武器跟魔紋變換石(這個在合成的時候不會增加練成回數)鍊成。
• 因為後來才發現critical乘倍的數值影響武器威力不小。同樣是武器威力40000左右的觸台，critical乘倍加到70的話威力可以差到兩倍... 做出這種狀態的武器的話也可以一揮就讓魔擊耐性的敵人掛掉...

攻略完幻影之塔之後再回來打最終關卡，boss在攻擊的時候輕輕一揮就死了。XD
導致last battle弱掉... 也許這邊要掛些限制會比較好。不過要是沒幻影之塔的話筆者已經無法想像會多難打了...尤其沒幻影之塔的狀態，最高副標的觸台是毒系的，也就是得被逼著用近接武器。

劇情的部分，交待時間順序先後的串聯的部分稍嫌不足。
到最後還是有些問號留下來是比較可惜的地方。有全語音已經讓我很驚訝了。
也有可能是預算不足導致有些地方刪掉？




最後再來談談一些令筆者印象深刻的「規格」。

• 被攻擊力0的硬直： 明明就不痛不癢為啥還要被彈開!?
• 大史萊姆的地灘水：明明就沒爬到的地方也會突然出現然後就判定，喜歡近距武器的玩家應該都頭痛過...
• 蜈蚣的死亡之嘴：打到hp為0翻白肚之後，靠近嘴部偶而會出現攻擊判定。
• 遠距觸台發出的火球不會上下坡：所以打坡上的敵人，一揮馬上火球就被牆壁吃掉，只好站在同高度打。
• 古塔的多方向攻擊：揮出去之後可以轉一下方向，偶而會命中其他方位的敵人。
• 地圖踏破率的計算：チョコラータ楼閣的踏破率計算真的是非常機車。要是跟筆者一樣陷入泥沼的話，把所有的跳躍通道都「雙向」走一遍看看。

地圖踏破率100％還是有漏ストマックストーン的話，通常是以下三顆：

•  アズ・ブロッケン山4合目北邊的第一個跳躍點，跳過去之後在往回跳會到一個島上。這島不算踏破率而且要往回跳才會發現可以到這裡。
•  セント・ドルチェ近郊起點的區壞的最右端有個可以跳確的點，跳過去有一顆。
• チンクエの林道，打過boss之後再回來boss的那個不算踏破率的區塊，最後面有一顆。

[安藤]android studio gradle builder finished with non-zero exit value 1 的魔咒

之前有嘗試要把sdk版本升級到20以上，但是遇到了gradle builder 的bug。

持續在使用的

android.packagingOptions {

    exclude 'META-INF/DEPENDENCIES'       

    exclude 'META-INF/NOTICE'       

    exclude 'META-INF/LICENSE'        

    exclude 'META-INF/LICENSE.txt'       

    exclude 'META-INF/NOTICE.txt'   

}

解決apache 裡面的幾個jar的duplicatefileexception的方法變成無效。目前尚無解決方案。

因此持續停留在19版。最近又試了一下升級，問題依然存在。

因為到了23版都還不修正，猜測是不打算修了要硬逼大家回去用httpurlConnection。


因為擔心版本越離越遠，哪天無法compile的話就慘了。
於是下定決心要把整個apache http溝通的部分全部修成native api。
好不容易修好要開始debug，更新sdk版本為23.0.1版後，又遇到gradle builder bug。

不知原因的，compiler所有檔案全部ok，但是在製作debug/run的apk的時候出現

Error:Execution failed for task ':app:dexDebug'.

>com.android.ide.common.process.ProcessException:org.gradle.process.internal.ExecException:
Process 'command 'java'' finished with non-zero exit value 1
* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output.




的問題。gradle還很好心的提醒可以加參數看debug print。
好了，第一步是要在android studio的哪裡加參數？依然是查google...
結果是加在這裡：

加了之後發現資料還是不足。試了幾小時之後突然想到降版本看看。
降到22.0.1之後發現訊息出來了。原來資料不足是sdk的bug... 這真的太扯... Orz
訊息如下：
最後確定是此問題：


Caused by: java.lang.NullPointerException
    at com.android.dx.cf.code.ConcreteMethod.<init>(ConcreteMethod.java:87)
    at com.android.dx.cf.code.ConcreteMethod.<init>(ConcreteMethod.java:75)
    at com.android.dx.dex.cf.CfTranslator.processMethods(CfTranslator.java:271)
    ... 26 more
...while processing <init> (Ljp/co/hogehoge/HogeActivity;)V
...while processing jp/co/hogehoge/HogeActivity$1.class

參考網站
http://qiita.com/developerwaiwai/items/0894b5c450b337a236ed
，解法真的是令人吐血。不過這應該是c語言工程師留下來的積弊... (在下就是)
if (true) -> if (Boolean.TRUE)
if (false) -> if (Boolean.FALSE)

這真的是令人無法接受的bug...   改完之後順利完成apk製作。

[Event] 2015/09/26 日本酒主義

鍵人對於日本酒可說是一竅不通。平常幾乎沒有在喝。最大的原因是鍵人在台灣看到的清酒都是以不合理的價格在做販售。怎麼可能去買勒...

為了多些經驗，還是參加酒展最快啦。
所以今年就多了這篇日本酒的參展紀錄。

老規矩，參展之前一定要吃飽飯。剛好展場在信義區附近，於是挑了這間開幕沒很久的新店：一幻來試試。台灣終於有甲殼湯的拉麵店，真的要高興一下。

圖上的是濃厚豚骨味增+叉燒。濃度沒有問題，只是豚骨的味道壓過甲殼湯，有點可惜。
下次改點原味試試。

喝日本酒當然要用日式杯。這次就由相聚一刻的Piyo豬口杯陪伴全程。
禁止酒駕分隔線禁止酒駕分隔線禁止酒駕分隔線禁止酒駕分隔線禁止酒駕分隔線禁止酒駕分隔線禁止酒駕分隔線禁止酒駕分隔線禁止酒駕分隔線禁止酒駕分隔線禁止酒駕分隔線禁止酒駕分隔線


週末的下午，場內相當熱鬧。


繞了一圈，想不到該喝哪款。逛到這攤，第一次的出征，「初陣」這酒名相當配。
所以就從這隻開始。感覺還不錯。沒有釀造味，清爽口感，純粹的米香。第一隻就有不錯的印象。


華吹雪是偏淡的口感。


男山的味道重，辣，有蘋果味，有尾韻而且是芋頭味。


雪の茅舍長在尾韻。


まんさくの花 純米大吟釀：尾韻不錯。偏辣。
まんさくの花 祭：酸度跟平衡。有點酸度的酒比較不會膩。


醉樂天：偏甘口。
古式 純造り：尾勁強。
春霞 華兆：尾勁強。


銀河鉄道の夜：多種味道混在一起，相當有趣的一款。


純米酒 初孫：鍵人判定本場次的MVP。 第一次讓我知道「生酛」的厲害的一隻。
香氣之重令人驚訝。一口就知道這隻就是不一樣...
酒本身的酸，甘，香，刺激辣感之外，熱，溫，冰不同溫度帶來的味道也不一樣。


香梅：辣，淡。



楯野川　出羽燦々33%：甘，酒體濃，偏辣。


山櫻：辣
笹の川　純米酒：淡。


威士忌 山櫻Cherry: 硝味，嗆辣，尾韻回甘。


穩：果香。
自然酒 純米吟釀：微酸，甘，微辣，果香，飽滿的感覺。印象相當好。







真野鶴 綠瓶：芭樂味，微辣，微酸。
真野鶴 紅瓶：芭樂味，微辣，微酸，還多了股豬油味。
真野鶴 純米1901號：比紅瓶的豬油味更重！
万穂　真野鶴：微甘。
+


辯天 純米大吟釀：尾韻有不錯的米香。


濃厚古酒(葡萄酒)：波特味www
喝到這邊已經不知酒味了。無評語的就請多包涵。


富成喜 純米吟釀：尾韻不錯。



白岳仙 五百万石：糖味。
白岳仙 山田錦：香氣。
白岳仙 純米大吟釀：酒精味較強，尾韻甘甜。


無濾過 一次火：淡，酸，甘味，飽滿。



梅申春秋(梅酒)：相當濃，甜而且有力。令人印象深刻。



整體來說只喝了5成的酒。實在是太多款了XD
其實也沒想到會這麼多... 而且清酒的味道差異並不是非常明顯。
結果就是味道比較特殊的出線。有找到自己喜歡的酒就是好事。
只是豬油味... Orz

[安藤]android將2MB的XML匯入DB，耗時由10分鐘 ->6秒的歷程

這次接到的任務是下載一個壓縮過的xml檔案，並灌入db裡面。
檔案下載之前已經寫好含db+cache管理功能的模組，zip也只要套個zipinputstream並預先分析zipentry是不是目標檔。
XML parser之前也已經用DOM格式寫好可以任意取text / attributes值的tool。
一切都是如此美好。



但是在遇到2MB的xml之後，完全變了調。
初次的完整執行，等了3分鐘開始不耐煩，以為跑進了無限迴圈。
開始加一些debug print，發現一直有在動，只好耐心等待。

等了5分鐘，真的等不下去，分析一下debug print，資料的重複性似乎很高，
有點擔心是不是會跑不出來。轉而步進分析，看看到底是慢在哪。

一開始步進，傻了...

  DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();
  DocumentBuilder db;
  try {
   db = dbf.newDocumentBuilder();
   InputSource ii = new InputSource();
   ii.setCharacterStream(is);
   Document doc = db.parse(ii);
   doc.getDocumentElement().normalize();
   return doc;
  } catch (ParserConfigurationException e) {
   // Auto-generated catch block
   e.printStackTrace();
  }

以上這幾行就要1分鐘(debug狀態)。 Orz
常用的doc.getElementsByTagName(...); 一call就是幾十秒在算。
心想這不是辦法。趕快找資料求救。咕狗：「android xml dom parse too slow」
直到看到了這一篇：

http://stackoverflow.com/questions/7224318/how-to-solve-the-xml-parsing-performance-issue-on-android
才知道DOM parser之慢... Orz （上面那篇的圖表必見。）


看來把parser改寫成SAX格式是在所難免。還好之前有寫過並不會覺得太難，只是SAX的循序走查方式，對付xml階層很深的格式的xml很難寫。
目標的XML只有兩層，資料都用attributes帶入，就不需要考慮這樣的問題。
(開始覺得設計目標資料格式的人一定相當有經驗。)

改寫成sax格式之後再跑，果然是快多了。一口氣從10分鐘降為3分鐘。
不過還是在需要做task管理的範圍。結果又花了點時間寫暫停跟續傳。

但是，想要加速的想法並沒有這樣就停止。
看起來問題應該不是xml了。那剩下的就是在db的存取上面。
繼續查資料... 咕狗：「android db insert too slow」

又看到一篇：
http://stackoverflow.com/questions/3501516/android-sqlite-database-slow-insertion

介紹只要把db.insert(...)
用下面的方法寫

db.beginTransaction();
db.insert(...);
db.setTransactionSuccessful();
db.endTransaction();

就可以爆速。於是加了那三行。3分鐘變成30秒。 (抖)

30秒已經是可以不需要暫停背景執行的射程目標。
接下來就是繼續努力看看是不是可以再縮。
因為目前都還是使用單筆插入，於是把焦點放到bulkinsert(...)上面。
得一次全抓完資料再寫入，需要比較大的記憶體，為了速度這時也不在意了，
全部放到ArayList<ContentValues[]>去。

bulkinsert一樣加上上面三行，改成bulkinsert之後，降為10秒！
之前寫的task管理的操作正式宣告作廢。 雖然是好事啦。

繼續努力。上面那篇文中還提到一個技巧：

private void insertTestData() {
    String sql = "insert into producttable (name, description, price, stock_available) values (?, ?, ?, ?);";

    dbHandler.getWritableDatabase();
    database.beginTransaction();
    SQLiteStatement stmt = database.compileStatement(sql);

    for (int i = 0; i < NUMBER_OF_ROWS; i++) {
        //generate some values

        stmt.bindString(1, randomName);
        stmt.bindString(2, randomDescription);
        stmt.bindDouble(3, randomPrice);
        stmt.bindLong(4, randomNumber);

        long entryID = stmt.executeInsert();
        stmt.clearBindings();
    }

    database.setTransactionSuccessful();
    database.endTransaction();

    dbHandler.close();
}

這是使用db的compile sql方式(加速處理，不需要每次都sql command parse)然後綁參數的強力技巧。但是因為這方法需要照欄位的資料型態綁參數，加上insert所指定的欄位，每一個欄位都必需要有資料，其實有點麻煩。不過...

之前寫過一篇關於db架構的文。
用這篇提到的方法架構的db，稍微小改寫一下，要取得欄位名稱跟欄位的資料型態是輕而易舉。
改寫成此法之後... 降為6秒。 應該沒招了。到此為止。



備註：

• 經由這次教訓之後，決心以後設計xml格式的時候，帶的參數一律用attributes帶。
• 日期建議直接以字串存取。在不考慮時區的處理，yyyy-MM-dd HH:mm:ss格式是最好用的。要比對最小單位為秒的時間也很簡單，直接使用大小於比對就好。
  轉成Calendar / date等等日期格式再parse出來存將會拖累速度。反正android的sqlite，所有資料都是string存放(連數字都一樣)...