有一台樣機，寄到終端客戶那裡出了問題，找到了我這裡來。
我不清楚樣機是怎麼出去的，誰寄出去的，測試了沒有，裝了什麼版本的程式，到**商那裡有沒有修改過。幸好現在人不多，問了兩個人，清楚了是在2023年十一月份寄給**商的。一般情況下，我們這邊出去的裝置都是測試過的。
這樣，出了問題，就有幾種可能性：
1. 我們自己的問題；軟體版本不對；或者沒有測試；或者寄出去的機器不對；這裡還存在乙個不確定的地方，就是硬體的版本不清楚，現在有兩個硬體版本。
2. **商在這個過程中的問題；
3. 客戶的問題；
我這個過程中，暴露出了我們的一些問題；如果一切正常，沒有任何問題。但是，在客戶服務還有前期生產過程中，暴露出的一些問題，值得思考：
1. 目前版本很多；微控制器韌體有兩個版本；作業系統韌體在不斷更新；應用程式也是不斷公升級；因為客戶對成本的要求，硬體也有很多差異。產品出去後，到客戶那裡，出了問題，要逐個排查（我剛才就確定了作業系統韌體版本號和應用軟體版本號，硬體版本沒有辦法檢測）。這個也是陳所說的，我們自己要不斷完善，某個版本和某個版本在一起一定能夠穩定工作。這樣就能夠減少技術支援的難度，技術支援只需要確定版本號就能解決問題，如果不行，就要寄回來分析原因，而不是在客戶那裡折騰。
2. 產品流向的控制；產品銷售出去一般有三種情況：零售的標準版本、批量的標準版本、以及根據客戶定製的個性化的版本（主要是硬體的定製）。今天這個客戶的裝置，我們同時有賣到另乙個客戶那裡，硬體不同；所以要確定是什麼原因；以其花這個時間，還不如直接讓版本來說話。之前，甚至出現過在零售市場發現我們賣個行業客戶的產品的情況。只有控制了產品的流向，才能明確技術支援誰來做。
3. 生產效率的問題；驗證硬體的可用性不需要安裝完整的程式。
4. 明確責任；如果解決了問題，要能夠明確是誰的責任。
解決的辦法。
1. 每台機器乙個唯一的id。
2. 要有一套系統，產品出去，中間的環節應有責任人。
客戶支援再好，不如讓客戶一步到位。每一次讓客戶寄回產品，就是對客戶信心的削弱。
我期望的系統：
1. 產品從燒入作業系統韌體開始控制。測試有記錄，有責任人；安裝的版本有記錄，有責任人。這些資料，都在伺服器中儲存。客戶在這個階段可以通過這套系統，了解我們產品的資訊。
2. 產品出去後，到**商**。**商寄出，也應有記錄。這樣，也是幫助**商管理客戶。
3. 產品出了問題，通過唯一的id號，就可以了解情況。
As 原始碼 沒有問題 在as中顯示亂了
最近更新了as的版本，老是會出一些小問題。第一次出現，import 的包全部爆紅了，但是 可以正常編譯，打包。這個比較好解決，解決辦法是 就可以解決問題了。今天又出現了類似情況，用了上面的方法無效，一看 大部分 全亂套了。檔案和檔案都不對應了。解決方法 關閉androidstudio重新命名專案資料...
落地敏捷典型問題 有了這些跡象，一定是出現了問題
有了這些跡象，一定是出現了問題 我們在周而復始的一次一次做迭代，提交新版本。但有一些跡象一旦出現，我們必須停下來，解決這些問題，否則將越來越糟。1.提交給客戶的質量是不能接收的，客戶很不願意公升級版本，因為會遇到無法預計的一些bug 2.給客戶提交新功能，需要越來越長的時間。這個問題有可能產生於 功...
python在客戶端中輸出現亂碼問題
解決辦法 print str html decode utf 8 問題原因 亂碼產生的原因是python在讀取時預設解碼方式是用作業系統編碼,如果和儲存時的編碼方式不一樣，就會出現亂碼 比如以下片段，檔案儲存格式是utf 8 coding utf 8 print 是 輸出亂碼 因為windows預設...