《30天，App開發從0到1》這本書我們已經用時15周分享了其中的大部分內容，今天，為大家節選的是本書的附錄精華部分——編碼優化。很多程式設計師都會遇到的問題，打好基礎，才能成為“大獅”！
1.彈出鍵盤優化處理
輸入框位於裝置螢幕下半部份的應用場景，config.xml 中的鍵盤彈出模式引數 softInputMode務必設定為 resize 模式，或者使用 UIInput 相關模組。
為了讓應用看起來更接近原生，儘量配置 config.xml 中的 softInputBarEnabled 引數來隱藏 iOS 鍵盤上面的工具條。也可以在 openWin 或 openFrame 的時候通過 softInputBarEnabled 引數來單獨指定。
2.專案字型優化處理
可以根據專案的需要引入外部字型，但是要控制外部字型檔案的大小，字型檔案不宜過大。
Android 上預設有 3 種字型:sans、serif 和 monospace，在開發人員不指定的情況下預設為sans，這 3 種字型在開發過程中都是通過字型名進行引用，系統會自動對應到內建字型檔案。但是對於外部的字型檔案，Android 上無法實現通過引擎配置後成為內建的字型檔案，只能通過 @ font-face 的方式在每個頁面中重複載入，每一個要使用外部字型的 Window 或 Frame 都要引入 一遍。如果字型體積過大會佔用大量記憶體，影響頁面的載入速度。
iOS 可以在 config.xml 檔案中進行外部字型檔案的配置，配置完成後就可以像系統內建字型 一樣在頁面中指定了，無需在每個 Window 或 Frame 中通過 @font-face 的方式引入。
3.同步/非同步邏輯優化處理
對於檔案、資料庫、偏好設定等操作推薦使用同步介面 ( 方法名增加 Sync 字尾 ) 來簡化程式碼的實現，以解決非同步 callback 層次過深的問題。
4.日誌列印優化處理
正式版本應關閉或刪除測試聯調時使用的 console.log 控制檯列印顯示方法，嚴禁正式版本出現供測試聯調使用的 alert 資訊。
可考慮封裝統一的日誌列印顯示方法在測試聯調時使用，方便控制日誌列印功能的開啟和關閉。測試聯調優先使用控制檯列印命令 console.log，避免或減少使用 alert 方法進行測試聯調， 防止正式版本有遺漏，彈出測試資料資訊。
5.使用者體驗優化處理
對於內容資料存在動態更新情況的頁面，應實現頁面下拉重新整理功能以保證使用者可以手動重新整理頁面資料。
根據業務場景優化使用者體驗，考慮實現對 app 進入後臺和回覆前臺的事件監聽和邏輯處理。 在異常處理邏輯需要顯示異常資訊時，根據異常的重要程式選擇使用 alert 或 toast 方式進行提示。 要注意 api.alert 會阻塞執行緒，強制使用者點選後程式才能繼續執行，適合在需要使用者明確確認的場景內使用。
視窗關閉處理是在開發過程中根據需要處理 Android 的 keyback 事件和 iOS 的回滑手勢。
Android 上要在 Window 中才能監聽到 keyback 事件，Frame 中無法監聽到 keyback 事件;
在 iOS7 以上的系統上可以在 openWin 的時候通過設定 slidBackEnabled 引數來實現是否支援回滑手勢關閉視窗的功能。
在後臺關閉非當前顯示頁面時，應設定 animation:{type:"none"}，關閉動畫效果方式，以免頁面關閉動畫影響當前顯示頁面的渲染，從而降低使用者體驗。
6.效能優化處理
儘量不對 Object 和 Array 擴充原型方法，有可能導致 iOS 系統的 App 閃退。同時避免不必要的 DOM 操作，瀏覽器遍歷 DOM 元素的代價是昂貴的。當一個元素出現多次時，將它儲存在一個變數中。
避 免 使 用 如 jQuery、jQuery Mobile、SenchaTouch、Bootstrap 等“ 重 型 框 架 ”。jQuery 和SenchaTouch 等框架的事件流設計思想及其內部文件模型會嚴重拖慢 UI 響應速度。同時，框架內部 Timer 不斷重新整理頁面，頻繁佔用 CPU/GPU 資源，會拉低頁面響應速度，嚴重影響使用者體驗。
也要儘量減少使用第三方樣式、指令碼庫或框架。擺脫對 $ 函式的依賴，轉變思想，養成自己動手的習慣。移動端對 HTML5、CSS3 和 ECMAScript5 的支援較好。如某些需求不得不使用 一些第三方指令碼時，應使用對移動端支援良好且目標性強、功能單一的框架。如 :api.js、zepto.js、swipe.js、doT.js 等。
預設樣式設定、DOM 操作和字串處理推薦使用 APICloud 前端框架(api.js 和 api.css)。
7.視窗切換優化處理
避免出現任何卡頓、閃屏、白屏等情況;要保證動畫效果流暢，不能出現丟幀的情況要理解並控制視窗好切與介面渲染之間的關係，要適時更新 UI，如果 Window 或 Frame 中所載入的靜態頁面內容過多，建議等動畫執行完畢再進行頁面的載入和渲染。無論是 Android 還 是 iOS 系統，在進行視窗切換的時候，如果窗體本身正在進行渲染(Window 或 Frame 所載入的 網頁沒有渲染完畢)，則會影響切換動畫執行的流暢性，出現卡頓或丟幀的情況。
建議在開啟 Window 或 Frame 的時候，如果所載入的靜態網頁不能快速的渲染完畢。為了不影響窗體切換動畫的執行，可以在切換動畫執行完畢後再進行動態資料的載入和介面的重新整理。