Analyzing a complete sequence
Calls to one interface can have very different costs. Appending to a dynamic array usually writes one element, but a full backing array requires allocation and copying. Treating every call as the most expensive case overlooks restrictions on how frequently that case can occur.
Amortized analysis specifies an initial state and allowed operations, then bounds the total work of every permitted sequence. Dividing that bound by its length describes sequence-wide resource requirements without claiming that individual calls have equal costs.
References: [1]
Growth events and total copying
With capacity doubling, earlier copying events grow geometrically: 1, 2, 4, and so on. Their sum remains proportional to the final capacity. Starting empty and appending n elements therefore incurs O(n) total resizing work.
Under a unit-cost model for moving an element or reference, end insertion has amortized O(1) cost. A particular resizing insertion can still take O(n), so applications with strict pause requirements need more than this aggregate guarantee.
References: [1]
The bound depends on the policy
The guarantee depends on the implemented policy. Growing by one slot repeatedly can copy almost the whole array on every append. Shrinking immediately to the exact occupied size can likewise make alternating insertion and deletion expensive.
This averaging is not an expectation over random input. It bounds a permitted operation sequence and does not remove element shifts needed for insertion in the middle. Analysis should identify the operation model and distinguish amortized bounds from individual worst cases.