移動辦公，是企業協同產品的大勢所趨。但在實際使用過程中，對於同一個產品，可能不同企業對於其定位都不太一樣；另一方面，一個產品也難以完全符合不同企業的需求，此時就需要根據其訴求進行產品定製化。面對企業不同的個性化需求，解決思路往往也是不同的，這要求產品擁有一定的擴展能力，例如，最初通過打包配置項+後臺參數配置+應用跳轉的方式來進行自定義功能擴展；發展為支持通過內嵌一個擴展應用，如完成定製首頁的效果；後續發展為支持擴展自定義輕應用、小程序等插件，如為應用實現某定製協議的NFC卡識別能力；再進一步發展為支持配置嵌入原生代碼，如配置一個定製的原生首頁或實現一個統計步數的後臺服務等。聯繫品高雲家的小表妹（ID：pingaoyunzzm）瞭解更多。
然而，擴展的靈活性，也會同時給產品帶來更多的不確定性因素，即每個擴展應用都有讓程序崩潰的可能性，導致問題的定位變得更困難。例如，公安行業中使用的是定製安全系統的手機，並且面對的是複雜的內網環境，一旦程序出現問題，其故障排查通常需要大費周章。在這種情況下，如果能對系統日誌、網絡請求、使用內存等各方面進行監控，將有利於準確尋找問題根源。
聆客企業協作平臺（BingoLink，下簡稱“聆客”）是一款面向企業生態系統的雲端協作與開放平臺，可為企業開發者提供一站式的應用開發環境擴展和定製標準功能、集成和聯通第三方應用並構建全新業務單元，通過敏捷開發和快速迭代幫助企業實現全面信息化。本文將主要從技術的角度對聆客Android端開發的擴展能力和監控能力進行介紹。
本期大咖 >> 譚智慧
品高雲應用產品研發工程師，擁有多年豐富的移動化產品構建經驗。目前主要負責聆客企業協作平臺（BingoLink）的Android端研發工作，包括：操作系統新特性與兼容性的研究、產品體驗和性能的優化、產品功能的持續迭代（如：消息點對點加密、語音視頻聊天）等。
擴展能力
1. 聆客能利用打包平臺的能力達到擴展的效果，為企業自由組合不同的個性化版本。首先，需要在代碼中預留替換參數文件和資源文件夾，然後打包平臺並依據不同企業的設置按照預設規則進行參數和資源替換，最後執行編譯命令生成APK文件。這裡用簡單的流程圖介紹一下打包平臺中對於Android程序的執行流程：
- 界面配置：聆客的UI支持顏色、圖片、語言包以及界面的自由搭配。在Android的編譯過程中，AAPT對於資源的生成會遵循項目的依賴關係，我們可以利用生成的這個規則對於資源重複的情況做一個優先級處理，使打包最終效果為：所有的資源項都將優先使用打包配置的資源，其次再使用內置的代碼。
- 功能配置：在功能配置方面，聆客使用INI格式進行定義，該格式的優點在於定義簡單，便於打包人員或管理人員進行配置，降低人為造成的出錯概率。參數除了支持自定義以外，還包含當前界面的變量，例如群組名片擴展的功能會傳入當前群名片的ID，個人聊天擴展的功能菜單會傳入當前聊天對象的ID。
2. 通過自定義開發的方式達到擴展的效果，結合上述的功能配置，可以在聆客預留的擴展點嵌入自定義功能開發。
- 聆客為開發者提供了H5、輕應用、小程序、原生應用多種不同APP類型的接入和擴展，除了管理應用的安裝、更新和卸載外，還為接入應用提供了便捷的SSO單點登錄集成以及大量的原生API調用。
- 支持Native的擴展，開發者除了可以用內置的API以外，還能對Native層進行自定義擴展，比如對輕應用自定義Plugin、對小程序自定義Module和Component，甚至在首頁Tab內嵌一個自定義原生的Fragment。通過APP+Native的擴展，開發者可以實現各種不同需求的定製開發。
監控能力
監控接口請求
對主流的HTTP請求庫關鍵函數進行Hook操作，可以對整個APP使用這些庫發起的HTTP請求進行統一監控。這樣做的優點是，除了能監控平臺內發起的請求外，還能監控第三方開發者自己擴展的插件。聯繫品高雲家的小表妹（ID：pingaoyunzzm）瞭解更多。
該能力主要是通過ASM修改字節碼的方式實現的，通過自定義Gradle方式修改Dex生成的過程，在這個過程裡找到需要替換的Class類，再找關鍵函數並對其注入監控的代碼。
小技巧：注入代碼裡如果需要用到未公開的類，可以用Object代替。
監控全局日誌
很多Android開發者都知道手機直接通過數據線連接就可以通過ADB查看Logcat日誌，但在某些屏蔽了USB連接的操作系統，例如公安行業定製的安全系統裡，是無法進行數據線操作的，這時如果程序出現Bug，即便拿到手機也難以排查問題，該如何解決？辦法還是有的，在這個場景下我們就要繞過ADB能力，通過程序直接調用系統內置的Logcat命令工具收集日誌，自己實現對日誌的輸出控制檯和日誌的收集。
小技巧：Logcat執行會包括其他APP產生的日誌，而且該命令也沒有過濾參數，不過我們可以發現每行日誌都會包含進程ID這一規律，所以這裡調用命令時可以通過使用Grep Pid進行過濾，只保留該應用的日誌。
崩潰日誌收集
有時，出現一些偶現或出現概率低的崩潰會很難定位，加上平臺支持自定義的代碼擴展也會增加崩潰的可能性，而且出現崩潰時上述的全局日誌監控已經無法生效，因為Logcat的輸出是異步的，出現崩潰意味著進程將停止運行。不過幸好系統的API為開發者提供了這個時機的擴展：通過Thread提供的能力，捕獲所有線程中崩潰時出現的異常信息，平臺可以在崩潰時保存當前時間、手機型號、堆棧信息等信息，只要程序下次啟動時把崩潰日誌再發回來，Bug就原形畢露了。
內存異常監控
相信不少開發者都碰到過OutOfMemory的情況，平臺會增加內存溢出的可能性，但不僅平臺自身面臨著這種風險，上架的每一個應用都有內存洩露的風險，並且長時間打開應用不關閉還會有內存溢出的可能。當這種情況出現時，說明程序裡所有代碼都已經極為不穩定，每個對象的創建都有引起OutOfMemory崩潰的可能，此時上文提及的崩潰日誌已經基本沒什麼作用。因為堆棧裡顯示的是最後一次申請空間達到上限拋出的，但這往往不是引起內存溢出的罪魁禍首，也許甚至還令人疑惑：這點小操作怎麼可能就引起內存溢出呢？
那麼，遇到這種情況該怎麼辦？
面對這種情況，聆客的解決辦法是，基於上面的記錄崩潰時機判斷如果出現OutOfMemory異常，把這一刻的內存情況Dump保存下來，剩下的就是通過工具分析內存情況和享受解決Bug的過程了。聯繫品高雲家的小表妹（ID：pingaoyunzzm）瞭解更多。
界面卡頓監控
偶然出現的操作卡頓現象，這種體驗的優化是比較頭疼的——因為沒有錯誤日誌，讓人有種無從下手的感覺。聆客利用MainLoop類提供的能力，該類提供了一個日誌回調的方法讓開發者可以清楚知道主線程的調用過程，程序裡通過把每次調用的開始時間和結束時間作比較，耗時大的即為卡頓，把本次主線程的堆棧信息記錄下來，最後就可以根據卡頓時的堆棧信息來解決Bug了。
總結
綜上，聆客企業協作平臺的擴展能力能滿足企業的定製化需求，讓開發者實現更敏捷全能的開發；而監控能力則可以解決因集成應用多或擴展多樣性所導致的程序不穩定引發的問題排查困難，有利於開發者解決應用故障。
隨著聆客產品的持續發展，我們將不斷對各種各樣的用戶痛點進行分析與解決，例如安全性方面的應用加固、本地數據安全、應用防篡改和網絡防劫持等，還包括性能方面的消息數據量膨脹的優化、複雜佈局結構的優化、應用啟動速度優化以及節省流量和電量消耗等問題，敬請期待後續的專題技術分享。
聯繫我們
如想了解更多品高雲解決方案或索取產品文檔，請聯繫品高雲家的客服小表妹！添加她為好友，任何需求一鍵直達。
閱讀更多 品高雲 的文章
