開發Android需要經歷些什麼樣的心酸？...不是說iOS開發不會有心酸事，一想到「天線門」、「TouchID出現又消失」.......，嘴角總是會不經意露出「爽快的微笑」。

看到Fushia出現（或每次有發展進度上新聞），總是一堆「疑似C++工程師」在那邊忍住笑意的說「Google要拋棄Android」了，——大家都有自己的辛酸事，大家都會覺得「別人過好爽」（像「Android的市佔率」跟「Java的物件導向好學習、好上手、好開發」），但事實上並不是。

開發Android有多心酸呢？
前面有提到：大型專案經常「最早的雛形成品開發很容易，但真正進入專案階段，就問題連連。」
為什麼？
到底會碰到些什麼情況？

（下面這個情況，雖然在這幾年沒再發生了，但我覺得挺經典的。）

在Android中，「活動」的內容可以自行設定，但如何啟動、如何初始化、如何卸載釋放，就必須要由系統來掌控。（這稱為生命週期。）
在Android4/5時，開發到一半，伴隨著專案規模成長，經常從天外跑出一個現象就是：請系統啟動某個剛完成、準備測試的特定功能，結果這個功能最後雖然啟動了，卻連續的執行了兩次初始化；不單單是連續執行了兩次初始化，事實上，這是兩個不同的「活動」，（同一個物件、不同實體，）但第一個活動初始化完成後就石沈大海了！（不是初始化了嗎？為何不執行回收釋放動作呢？）

所以如果雛形所確立的框架中，會在初始化執行某些功能，則這些本來計劃在初始化中執行的功能會非常不穩定。
例如要進行連線......本來只要執行一次，會變成執行兩次。

這問題不難修正。
問題在於專案管理結構：很多負責開發核心雛形的工程師不太願意承認「他寫好的雛型框架會發生這種事情」，即使承認了，進行的修正也未必適合所有正在進行中的專案，個別專案試用新的解決方案的成本可能會差異很大。

一個問題完之後是另一個問題...「為什麼不能承認、然後進行修正？」

這可能是因為他的工程師素養中並沒有「平行溝通」這種東西。

有個現象是：如果GoogleDev中寫了篇文章，（不管這文章是否權威、是否專業精準，）只要它有提到這個現象發生，這位工程師就有很高的機會承認「對！我寫的核心發生了這個現象。」
反過來說，如果GoogleDev沒有出現過類似的文章，那他面對這個問題的方式大概就會變成「聳聳肩，說：一定是某某工程師的程式碼有問題，請他自己檢查一下、Survey一下癥結就好了。」

這類工程師做事情大概就是簡單三個原則：「凡事都只認官方文件。」「凡事都只認權威的文章。」「盡可能花心思去精通這些管道釋出的文章，而不是認真培養程式建構的技能。」

先不要評論。
最初寫程式，有個DK和簡單的小作家能寫份「.txt」文件就夠了。
雖然DK偶爾會無法執行，但排除方式都挺一拍兩瞪眼的。

後來，開始有了IDE/專案建構工具/版控軟體........
解決問題的方式（可能性）開始極速倍增。
DK版本 x IDE版本 x 專案建構工具版本 x 版控軟體 x 防火牆設定 x …… ＝ 直接尋求別人的意見去解決你碰到的問題時可能會得到的答案數量。這些答案中超過一半都是錯的，剩下的一半答案幾乎都只是讓問題收到的錯誤訊息變得不一樣，（所以一樣是錯的。）

這些問題有個特性：解決方式通常沒有邏輯，無從推論，大概就是某個不可思議的參數、必須要使用某個特定不可思議的值。

如果身為工程師，工作和解決問題的方式不再是以「邏輯」、「結構」、或演算法之類的事情為主，而是要不停的在「別人提供的制式程序」中查找，那請問工程師還能叫工程師嗎？

甚至，習慣在這樣的環境下工作的工程師可靠嗎？

（本來想要在這篇文章中把Google裝來痛罵一頓，這樣才能更契合標題，但時間精力有限，還是明天吧！）