注意事項
解耦 業務邏輯多分層，模塊化，某一個功能點是一個小模塊
命名空間 類名和工程名加前綴，通知名和全局變量也要加前綴，避免發送通知混亂執行。
-
引入開源庫，不要直接引入開源庫，并把開源庫編譯進SDK中。
有兩種解決辦法：
可以修改開源庫的前綴和命名空間，改成自己的庫；
編譯自己的SDK,在別人引用時,一并引入需要的開源庫。
易用性 不要一個接口傳十幾個參數
不要直接將第三方庫打進SDK，或者將第三方庫重命名，以免沖突
-
做基本的檢查和測試
SDK 對外公布前應該進行基本的編譯檢查，不應該有編譯器警告存在。
-
文檔完整并且正確
文檔要跟隨著SDK及時修改和完善。示例代碼不要出現錯誤。
-
支持最新的CPU版本和新特性
CPU版本：SDK需要支持真機(armv7 arm64)、模擬器(i386 x86_64)
編譯特性：像Xcode10 iOS12發布的時候，蘋果不支持GCC編譯，需要SDK一定要支持clang編譯
像這次必須clang編譯，應該一開始就緊跟技術更新，及時更新，而不是讓集成庫的開發者去找臨時解決方案。
優秀的SDK標準
- 針對開發者用戶的標準
- 完備的功能
- 良好的接口規范
- 完備且及時更新的文檔
- 良好的技術支持
- 所用即所得，沒有小動作
- 及時適配和支持新特性
- 針對廠商開發者的標準
-
完善的日志上報功能
- 大數據上報和Crash上報功能便于發布者及時改善。
-
較好的架構和頂層設計
- 在設計SDK時需要對用戶場景做一定的假設，保護和規避，從而也對SDK開發者提出了更高的要求。
- 開發模式方面，不能像app一樣快速迭代發版，快速的迭代改進。SDK產品的受眾是公司開發者，他們更重視功能實用性和穩定性，沒有很大對已集成SDK做持續升級-這將消耗大量的時間回歸已穩定功能；在SDK開發階段，一定要進行很好的設計規劃，不然的話各版本功能間接口兼容性問題會凸顯。
- SDK的文檔在引導用戶集成的重要性。
沒有內存泄漏
常見的SDK沖突和錯誤
重復引用
- 引入相同的開源庫，導致重復引入；
在使用我們在使用 AFNetworking 的時候遇到了許多依賴方面的問題。因為有些第三方庫也使用了 AFNetworking 的靜態庫，如果兩個三方庫都使用了AFNetworking，并且集成到一個工程中時，他們之間就會發生沖突。
解決辦法有
- 修改命名空間和一些參數，可以帶前綴等方式
- 不將AFNetworking引入到sdk中。
- 將自己的sdk打成動態庫。
架構
- sdk架構問題，是否同時支持真機(armv7 arm64)、模擬器(i386 x86_64)；
路徑引入
- 報.h文件找不到，是因為路徑引入不對，朝這個方向努力。
以上是我集成移動端第三方庫和自己寫SDK的感想，哪里寫的有出入的，歡迎評論交流！
